►
B
So
I,
normally
let
you
carry
forth
on
this
call,
but
so
many
of
the
things
I'm
doing
are
involving
vulnerability
disclosure
that
I
figure
I
need
to
be
on
this
Gathering
tube,
so
love
it.
No
I
think
we
are
as
far
as
the
presentation
for
Vancouver
I'm
sure
it
can
be
improved.
But
at
this
point
I
think
we've
got
we.
We
have
something
that
actually
is
worth
sharing.
So
I
sent
you
my
proposal
for
how
we
could
we
could
you
know
hand
off
stuff,
I,
don't
know
if
you
think
that's.
D
B
D
E
D
B
B
B
D
D
D
B
I
I
will
say
significant
parts
of
the
Tech
Community
I
think
move
much
more
towards
the
direct
because
I
think
in
part,
because
I
mean
with
computer
software.
You
can't
you
know
you,
you
can't
hint
and
suggest
either
there's
a
patch
or
there
isn't
the
advantage
of
real
thing
of
physical
things
and
software
is
that
you,
it
doesn't
matter
how
much
you
hint.
D
C
D
B
D
It
is
so
that
was
I
believe
Luigi's
proposal
where
he
has
kind
of
the
creating
a
security
MD
and
having
that
inbound
policy
Noah
we're
getting
a
lot
of
wind
noise,
he
might
be
able
to
mute
for
us
for
a
moment.
That'll
be
groovy.
Thank
you,
sir,
but
yeah
he
admit
he
had.
Has
that
and
we,
the
idea,
I
guess
once
we
get
the
words
done,
we
probably
should
route
that
up
to
the
tack
to
maybe
get
that
fast
track
to
see.
If
we're
interested
in
having
that.
H
C
Sorry,
it's
a
it's
a
bit
windy
I'm,
trying
to
relocate
okay,
I'm,
a
security
researcher,
I
work
at
the
University
of
California,
Santa,
Barbara
and
I'm.
Also
a
postgraduate
researcher
at
the
open
University
in
the
UK,
and
my
research
focuses
on
security
and
maintainability,
specifically
how
developers
are
going
to
respond
to
vulnerability,
disclosures
and
large,
open
source
go
projects.
C
D
Yes,
well
great
welcome.
Welcome,
welcome.
We
love
folks
that
have
any
kind
of
interest
in
vulnerabilities
here:
researchers,
vendors,
maintainers,
all
Stripes.
Just
to
give
you
a
few
brief
updates.
The
OSS
assert
Sig
is
still
waiting
for
a
governing
board
review.
We
were
supposed
to
talk
about
it
last
week
at
the
GB
governance
call,
but
that
the
call
was
canceled
just
lack
of
Quorum.
So
ideally
we'll
talk
about
it
next
Thursday
to
see
if
we
can
get
kind
of
a
more
formal
review
of
the
mobilization
plan.
D
Rewrites
I
did
work
with
Amanda
from
the
Linux
foundation
and
we
submitted
the
cert
for
funding
consideration
by
the
tech
Sovereign
fund.
So
that's
another
Avenue
to
potentially
provide
some
resources
to
that
effort
and
I
know.
Our
friends
here
in
the
states
at
sisa
were
quite
interested
when
I
described
the
initiative
to
them,
so
we'll
see
how
that
progresses
within
the
foundation
and
what
kind
of,
if
we
get
any
feedback
or
participation,
any
questions
about
the
cert.
D
Cv
dot
CBD
guide
for
consumers,
I'm
still
soliciting
contributors
to
start
that
effort,
I
started
an
outline
and
it
should
it's
linked
through
that
issue
and
then
there's
a
document
if
anyone's
interested
in
contributing
and
collaborating
on
that
once
I
get
somebody
else,
a
couple
somebody
else's.
Hopefully
we
can
start
writing
that
guide,
and
that
would
be
our
third
guide.
D
D
H
H
H
E
H
So
there's
been
a
lot
of
discussion
about
the
private
disclosure
requirements
here
and
how
we
are
requiring
people
to
do
disclosure
of
vulnerabilities,
and
so
this
is
the
flow
that
I
wrote
or
put
into
a
thing
yesterday
after
the
meeting
at
a
high
level.
It
encapsulates
this
idea
that
so
Madison
you'll
enjoy
this
I've
come
up
with
a
new
term
for
private
vulnerability,
reporting
it's
and
it's
it's
supposed
to
be
generic
enough
to
be
not
applicable
to
any
platform.
H
So
if
the
repository
host
supports
pmpvr,
which
is
github's
the
only
one
that
does
then
yes,
then,
if
the
issues
are
enabled,
then
you
create
an
issue
if
they
don't
have
pmpvr
enabled
you
request
that
they
enable
it.
You
wait
up
to
35
days
if
they've
enabled
at
that
point,
then
you
go
through
this
step
and
you
record.
F
H
H
This
way,
let's
try
yeah
and
if
that
works,
then,
if
you,
if
you
get
a
result,
then
you,
oh,
my
God
thanks
man,
you
send
an
email
with
the
patch
if
the
patch,
if
the
email
is
all
bounced,
you
just
open
a
pull
request.
Otherwise
you
wait
90
days
if
it's
fixed
Finn,
but
if
you
can't
find
an
email
or
all
the
emails
bounce,
you
create
a
public
pull
request.
That's
the
current
high
level
proposal.
You
got
a
hand
up
there.
D
C
B
E
B
H
This
is
intended
for
automated
pull
request,
generation
and
GitHub
is
supporting
the
ability
to
automatically
create
a
pull
request.
I
don't
know
if
we
want
to
just
open
a
patch
file
or
submit
a
patch
I.
Guess
that's
better
than
nothing.
Is
there
any
I?
Guess
if
there's
an
API
for
it
and
it's
better
than
nothing,
then
maybe
maybe
it's
sufficient
yeah.
B
B
H
B
H
E
D
B
B
B
I
mean
it
looks
like
it
will
tell
me,
but
I'll
actually
have
to
like
sit
and
read,
which
is
beyond
my
Google
flu
I
actually
have
to
read
something,
but
it
looks
like
there's
information
available.
If
we
sat
down,
we
could
answer
that
question.
Well,
that's
interesting!
So
let
me
how's
this.
Let
me
put
that
there
I
at
the
very
least
I
think
we
ought
to
look
at
it
to
look
at.
B
E
B
E
B
G
H
H
E
H
E
H
This
is
the
proposed
by
I.
Think
most
of
you
guys
read
the
message
I
sent
into
the
slack
Channel
and
if
you
didn't
and
then
I
so
I
had
a
chat
with
Michael,
no
McDonald
Mike
Dolan,
and
we
basically
took
this
document
that
I'd
originally
written
with
the
working
group
and
we
heavily
modified
it
to
make
it
two
documents.
The
first
document
is
hey.
H
The
open
source
security
Foundation
is
adopting
a
policy
for
outgoing
vulnerability
reports
and
then
the
other
document
is
here's
the
policy
anybody
can
use
it
so
we're
basically
creating
a
vulnerability,
reporting
or
vulnerable
outbound
vulnerability,
reporting
policy
that
anybody
with
any
named
organization
can
option
can
choose
to
adopt.
So
any
research
group,
any
anybody-
and
that
is
this
one
down
here-
the
model
outbound
vulnerability
disclosure
policy,
yes,
okay,
cool,
so
we
had
some
comments
from
David
David.
You
wanted
to
switch,
will
to
May.
B
B
Really:
okay,
all
right
so
I,
I
I,
don't
know
exactly
what
Mike
I'm
I'm
sure
what
Mike's
thoughts
were
on
the
subject
we
haven't
talked
about
this
I.
Here's
my
concern,
I,
don't
mind
in
general,
saying
normally
it
would
be
seven
days,
I'm
a
little
afraid
of
making
it
always
seven
days,
no
matter
what
it
is
true
that,
if
it's
already
being
exploited,
that
is
bad
but
I,
guess
what
I,
what
I'm
going
in
is
there's
an
interesting
paper.
B
I
think
it
was
by
Crispin
Cohen
years
back,
which
talked
about
the
trade-offs
I
thought
was
actually
very
interesting.
He
viewed
it
as
a
calculus
problem
where
you're
integrating
over
time.
You
know
so
so.
Basically,
if
you
think
of
vote
exploitations
as
the
act
as
the
y-axis
and
to
the
end
time
is
the
x-axis.
B
B
What's
more,
we've
had
way
too
many
experiences
where
developers
Rush
a
patch
and
the
result
is
frankly
worse
because
it
doesn't
solve
the
problem,
but
think
of
people
think
it
solves
the
problem
and
there's
only
so
much
time
in
the
day
to
install
another
patch,
and
so
all
too
often
what
happens
is
the
patch
is
bad
people
install
the
patch,
they
think
it's
fixed,
yeah
or
the
fixed
introduces
new
vulnerabilities?
Yes,.
B
A
H
H
D
And
think
about
this
from
the
customer
perspective
every
time
there's
a
a
warning
or
an
advisory,
they
have
research
to
do
and
then
every
time
there's
a
patch
they
have
to
pause
operations
and
test
and
then
roll
that
out.
So
if
you're
doing
that
multiple
times
in
a
row,
they're
going
to
be
forced
into
multiple
outages
and
then
like-
let's
say
this
affects
like
a
hyperscaler
like
Google
or
AWS:
they
are
they
or
Azure
they
dislike
rebooting.
D
B
Right
and
I'm
not
saying
that
you
I
mean,
sadly,
people
make
mistakes,
that's
why
we
have
vulnerabilities
and
sadly,
sometimes
the
fixes
will
have
mistakes,
but
pressuring
people
to
do
them
in
a
rush.
Job
increases
the
odds
of
a
bad
fix
and,
in
addition
now
so
that
that's
the
problem
from
the
fixing
side
there's
also
the
problem
from
the
attack
side.
It's
true
as
soon
as
there's
an
announcement
to
users,
they
can
start
to
take
some
steps,
like
maybe
turn
off
the
computers,
but
the
the
problem
is
well.
B
B
So
as
soon
as
you
announce
to
the
world,
it
means
that
all
the
attackers
know
and
if
all
the
attackers
know,
but
there's
very
little
The
Defenders
can
do
that's
successful,
you're
making
it
worse.
So
my
pitch
is
yes
clearly,
you
need
to
be
have
a
far
more
accelerated
time
frame,
I'm,
even
okay,
with
seven
days
as
the
default
I.
Just
don't
want
to
have
a
policy
that
says
it
must
be
seven
days.
I
I
would
prefer
you
know
seven
days,
but
you
know
convince
us.
B
G
H
B
B
H
D
Two
things
I
endorse
the
alteration
from
will
to
May.
It
gives
you
more
flexibility.
You
may
always
select
that
it's
seven
days,
but
you
might
not,
and
then
you
you
point
to
GPZ
GPZ
is
they
have
a
methodology?
It
is
controversial
amongst
many
within
the
industry.
It's
a
way
to
do
it.
You
know
they
seem
very
happy
with
it,
but
it
is
not
necessarily
the
best
way.
It's
a
way.
B
Yeah,
so
so
the
the
so
the
the
problem
is
the
bottom
one
just
says:
Hey
extreme
cases,
but
I
think
in
the
case
of
a
zero
date,
there's
an
additional
construct
that
doesn't
apply
to
the
others.
You
know,
as
soon
as
you
have
active
exploitation.
You
now
have
a
race,
it's
not
just
a
race
for
Discovery,
it's
a
race,
you
you,
you
are
damage,
is
occurring,
and
so
now
you're
trading
off
the
damage
occurring
versus
the
you
know
telling
out
to
the
world.
Well,.
B
D
Just
a
denial
of
service
and
the
service
Falls
over
and
then
automatically
restarts
yeah.
It's
annoying,
but
you
know
is
this
something
that
affects
you
know
the
safety
and
life.
That's
a
different,
different
impact
and
again
that's
why
I
prefer
the
flexibility
of
May
and
you
you
could
always
select
that
yeah,
but
at
least
with
the
May
that
gives
you
the
chance
to
weigh
other
mitigating
factors.
B
Yeah,
so
what
what
I?
What
I'm
proposing
is
basically
saying
normally
within
seven
days,
and
then
it
says
this
and
then
adding
text
that
says
this
publication
time
for
zero
days
may
be
longer
than
seven
days.
If
we
independently
determine
that
a
longer
time
is
much
more
likely
to
be
less
harmful
overall
to
all
users
of
that
software.
You
know
and
that's
a
a
lengthy
sentence.
We
can
probably
shorten
it
down,
but
you
know
basically
giving
the
idea
of
you
know.
H
Mean
that
is
the
expectation
is
the
the
the
the
the
the
seven
days
if
the
if
the
developer
that
is
developing
the
fix
does
not
believe
that
they
can
get
a
fix
out
in
seven
days,
which
is
totally
feasible.
We,
this
deadline
at
least
gives
them
a
deadline
by
which
they
need
to
have
mitigating
factors
communicated
to
The
Wider
public
yeah.
B
H
B
H
B
That
is
if
it's
a
buffer
overflow
and
you
can't
fix
it
in
seven
days,
what
the
heck's
wrong
with
you.
Of
course
there
are
if,
but
of
course
you
know
if,
if
you're
European,
you
may
be
on
your
two-week
vacation
yeah
and
you
and
there
is
no
contacting
you
but
but
the
problem
is
not
all
attacks
are
buffer
overflows
I
mean
meltdown
inspector,
we're
still
working
on
it.
Oh.
H
B
H
H
H
The
seven
day
thing
is
the
reason
that
the
seven
days
exists
not
only
from
the
perspective
of
getting
the
information
disclosed
to
maintainers,
but
it
sets
a
standard
for
the
industry
that
is
vulnerabilities
being
exploited
in
the
wild,
are
bad
and
we
need
to.
We,
as
an
industry,
need
to
be
able
to
react
to
these
things
quickly.
H
But
so
how
do
you
get
the
visibility
into
knowing
that
vulnerability
is
being
actively
exploited?
Is
because
you
have
some
sort
of
monitoring
or
you've
been
told
about
it,
but
that
person
that
was
told
about
it
has
found
out,
usually
because
they
have
some
sort
of
monitoring,
so
they
are
actually
being
actively
exploited
by
that
attack.
C
C
C
H
The
other
thing
called
you're
saying
or
sorry,
not
Chrome,
the
other
thing
you're
saying
David.
Is
it
attackers
don't
give
up
their
methodologies
the
the
problem
that
exists
in
that
understanding?
Is
you
don't
you?
You
may
get
visibility
into
the
attacker.
That
is
attacking
you,
but
you
have
no
idea.
You
don't
have
visibility
into
the
entire
internet.
You
don't
you
can't
know
how
widely
that
vulnerability
is
actively
being
used.
You
only
have
the
screen
this,
the
snapshot
that
you
have
right
and
so
how?
B
B
I
would
be
unsurprised
if
they
could
at
least
share
okay.
I
see
this.
Do
you
also
see
this,
which
is
a
very
different
kind
of
question?
You're,
not
asking
them
to
reveal
anything
that
they
know
privately
other
than
just
widespreadness,
but
anyway
my
fundamental
Point
Jonathan
is
really
is
really
a
simple
change,
don't
make
it
must
make
it
you
know
typically
or
normal
or
should
but
make
it
clear,
there's
an
out.
B
That's
all
make
it
clear
that
it
can
be
more
than
seven
days,
even
though
that's
the
not
the
norm
and
why
you
might
do
long
and
and
the
the
rationale
for
choosing
one
against
the
other
and
then,
if
it
turns
out
that
in
practice
you
never
do
more
than
seven
days.
Yeah,
that's
fine,
but
at
least
give
yourself
the
out,
because
policies
that
over
are
over
constrained
tend
to
be
more
of
a
problem
than
a
solution.
I
don't
want
the
policy
to
be
the
problem.
H
When
I,
when
I
spoke
to
Mike
Dolan,
he
was
his
his
his
reaction
was
wait.
Why
are
you
waiting
at
least
seven
days
like
that's?
You
should
be
moving
faster
than
that
right,
like
if
it's
actively
exploited
his
reaction
was.
This
should
be
moving
faster
than
that,
like
you,
you
should
be
making
it
an
upper
limit
and
I.
B
B
It
is
obviously
true
that
sometimes
an
attacker
finds
an
attack
and
they
tell
everybody
else
and
suddenly
everybody
else
is
getting
attacked,
but
in
a
number
of
other
cases
we
get
information
where
it's
only
been
done
once
the
attackers
are
trying
to
hide
that
they
may
not
use
it
again
till
next
month.
Well,
let's
give
them.
Let's
make
sure
that
they
fix
is
the
right
fix.
Then
Madison.
F
H
We
are
focused
predominantly
on
this
is
an
actively
exploited
zero
day
and
the
the
discussion
is
if
we
discover
that
the
vulnerability
is
under
active
exploitation.
Basically,
it's
a
no
day.
Do
we
make
the
the
seven
day
dead?
Do
we
make
the
seven
day
deadline
a
hard
upper
limit
or
a
soft
upper
limit
for
how
long
before
we
are
required
to
to
to
make
the
details
of
the
vulnerability
public
as
the
reporter.
F
I
would
look
at
it
from
like
a
benefit
standpoint
at
that
point.
Who
is
it
that
you're
trying
to
help,
which
is
end
users
right
so
from
a
safety
perspective
like,
in
my
opinion,
we
can
assume.
We
should
just
safely
assume
that
attackers
already
have
this
information
right.
All
of
these
attackers
have
this,
because
that
is
the
safest,
safest
starting
point
for
us
to
go
from
right.
So
the
only
people
who
don't
have
this
information
are
the
users
are
the
ones
who
are
being
disservice
right.
F
B
My
experience
is
colored
by
places
where,
in
particular,
I
used
to
work
with
the
US
Military,
and
there
are
absolutely
attacks
which
you
know,
which
are
no
public
or
Arch,
are
known
and
then
being
exploited,
but
are
not
known
by
most
attackers
and
in
fact,
I
would
say
that
we
are
moving
increasingly
to
this
world
because
there
are,
we've
now
got
a
huge
number.
I
mean
you
know.
Nso
group
is
just
one
now
of
a
large
number.
A
H
A
B
H
E
B
H
B
No,
it's
it's
much
simpler.
If
you,
if
you
only
see
it
once
and
you
never
see
it
anywhere
else,
even
in
places
where
you
would
expect
to
see
it,
it's
probably
hidden
it
you
can.
You
can
detect
some
of
it
simply
by
by
usage
patterns.
If
it's
rare,
even
in
places,
you
would
expect
it.
It's
probably
not
widely
known
yet.
F
F
My
perspective
was
also
right
intended
to
be
like
from
a
theoretical
standpoint
right
like
that
is,
that
is
my
Foundation
from
where
I,
where
I
would
start
thinking
about
it.
Obviously,
by
no
means
do
all
the
stackers
actually
have
everything
and
like
I,
fully
amcognizant
of
of
government
and
Military
limitations
from
my
past
life
too,
very
much
so
so.
E
F
It's
I
I
like
to
operate
from
an
assumption
that
you
know
if
this
is
being
exploited.
The
attackers
who
the
attackers
who
are
likely
to
exploit
this
at
least
or
the
ones
who
care
enough
likely
have
this
information
or
could
be
sharing
it
amongst
themselves
right
so
who
do
I
want
to
help
the
users
so
sharing
this
now
or
later?
What
is
the
impact
for
them
is
typically
how
I
think
about
it.
At
least
so.
H
What,
if
we?
Okay?
What
if
we
leave
this
policy?
The
Oda
policy
as
is
and
amend
the
publication
date
based
upon
moving
based
upon
extreme
circumstances,
to
include
a
call
out
for
highly
targeted
attacks
like
the
detection,
is
that
the
vulnerability
the
O
day
is
being
exploited
in
a
highly
targeted
attack.
B
H
B
E
H
B
Okay
statement
still
stands:
sometimes
you
have
the
data.
Sometimes
you
don't.
If
you
have
the
data,
then
you
should
use
it.
If
you
don't
have
the
data
well,
you're
gonna
have
to
make
your
best
estimate
based
on
what
information
you
do
have,
but
I
wouldn't
assume
you
never
have
this
data,
that's.
That
seems
like
a
scratch.
The
other
way.
B
B
H
B
H
I
I
Who
are
we
trying
to
serve
here
by
disclosing
and
you
know,
are
we
serving
The
Defenders?
What
can
the
Defenders
do
about
this?
If
there
are
no
mitigations
and
there
are
no
patches
you're
going
to
have
an
initial
Spike
where
even
more
bad
people
know
about
the
vulnerability,
therefore,
are
more
likely
to
exploit
it.
I
H
B
Yeah
and
I
argue
sometimes
because
it
depends
on
what
the
mitigation
is.
I
I
do
agree,
actually
it's
quite
legitimate
that
the
mitigation
may
be
turn
off
your
computer
until
it's
time,
but
for
many
systems,
that's
not
really
a
practical
mitigation,
and
then
that
comes
back
to
my
argument
once
again
with
I,
you
know:
I
got
it
accelerated
time.
Frames
are
often
good.
H
Can
I
just
quote
from
their
thing
just
real
quickly?
Okay,
it
does
so
their
question.
The
question
they're
answering
is:
doesn't
disclosing
a
vulnerability
when
there's
no
fix
endanger
users.
The
answer
is
counterintuitive
they're
intuitive
at
first
disclosing
to
a
small
number
of
unfixed
vulnerabilities.
Doesn't
meaningfully
increase
or
decrease
attackers
capability?
Our
deadline
based
disclosures,
have
a
neutral,
short-term
effect
on
attacker
capability.
We
certainly
know
there
are
groups
of
individuals
that
are
waiting
to
use
public
tax
to
harm
users
like
exploit
kit
authors.
H
We
also
know
that
the
cost
of
turning
a
typical
project,
zero
vulnerability
report
into
a
practical,
real
world
attack
is
non-trivial.
Since
project
zero
typically
discloses
only
one
part
of
the
exploit
chain.
Attackers
need
to
perform
substantial
additional
research
and
and
development
to
complete
the
exploit
and
make
it
reliable
any
attacker
with
the
resources
and
technical
skills
to
turn
a
bug
into
a
bug
report
into
a
reliable
exploit
chain
would
usually
be
able
to
build
a
similar
explore
bullet
chain.
H
Even
if
we'd
never
disclose
the
bug,
they
would
never,
they
would
either
have
the
ability
to
find
and
exploit
their
own
ode
vulnerabilities
or
have
access
to
a
range
of
other
interchangeable,
bugs
EG
other
unfixed
undisclosed
bugs
when
the
past
weeks
or
months.
Also,
the
window
of
Expo
of
exposure
between
disclosed
between
the
disclosure
and
effects
being
released
is
very
small.
H
I.E
a
patch
usually
arrives
short
term
after
the
disclosure
is
missed
if
the
attacker's
risk
of
detection,
the
and
the
attacker's
risk
of
the
detection
increases
rapidly
from
the
point
of
disclosure
for
any
attackers
that
are
willing
to
exploit
publicly
disclosed
bugs,
despite
the
increased
risk
of
or
failure
of
detection,
there
currently
seems
to
be
two
alternative
options
that
are
preferred
for
their
cost.
Effectiveness
one
wait
for
disclosed
bugs
that
require
only
a
small
amount
of
additional
research
and
development
design
flaws
and
or
bug
logic
bugs
or
other
easily.
H
H
Disclosures
or
our
normal
post
patch
disclosure
in
terms
of
The
observed
rates
of
opportunistic
reuse
by
attackers.
If
most
bugs
are
fixed
in
a
reasonable
time
frame,
I.E
less
than
90
days,
then
we
are
only
enforcing
the
deadline
on
a
very
small
number
of
unvicted
cases.
If
and
if
disclosure
disclosing
a
handful
of
unfixed
vulnerabilities
doesn't
substantially
help
the
attackers
in
the
short
term,
but
it
does
lead
to
a
demonstrated
long-term
benefit
of
shortening
patch
timelines
and
more
frequent
patching
Cycles.
H
Then
it
would
follow
that
a
deadline
based
disclosure
policy
is
good
for
the
overall
security.
So
at
a
high
level
they
are
arguing
that
having
a
disclosure
policy
like
this,
where
you
have
some
vulnerabilities
going
over
the
deadline,
those
that
missed
that
deadline,
set
a
precedent
in
the
industry.
That
is
a
forcing
function
to
encourage
others
in
the
future
to
handle
these
vulnerabilities
within
the
time
frame
that
you
have
established
in
policy.
G
So
really
quick
to
add
from
the
developer
perspective
on
this,
knowing
about
a
zero
day,
even
if
there
isn't
a
fix
available,
does
give
you
more
options
so,
whether
that's
ripping
out
the
dependency
that
you're
using
or
turning
off
the
service
like
that,
won't
be
applicable
for
every
scenario.
But
it
can
still
be
really
helpful,
even
if
there
is
no
fix
available.
G
B
C
C
I
I
like
to
not
disagree
with
David
I,
also
wanted
to
agree
with
Josh
that
I
I
think
also
from
a
developer
perspective.
It's
a
bit
of
a
culture
shift
that
you're
like
and
also
as
a
parent
when
I
enforce
rules.
The
children
are
aware
these
rules
will
be
enforced.
We
better
change
our
behavior
and
I.
Think
it's
the
culture
shift
to
get
the
developer
community
in
general
to
respond
more
seriously
to
vulnerability
disclosures.
B
B
My
argument
is
because
it's
complex
and
challenging
that
it
would
be
important
to
have
an
exam,
a
an
option
for
longer
now,
as
far
as
taking
them
seriously
I
I,
you
know
I'm,
sorry,
you
can
take
vulnerabilities
very,
very
seriously
and
be
unable
to
produce
any
meaningful
fix
in
seven
days,
even
if
I,
even
if
I
had
even
if
I
exclusively
did
only
did
that
and
nothing
else
there
are.
You
know
if
it's
a
design
change
to
a
system.
B
I
may
not
be
able
to
do
it
in
a
week
and
the
reality
is
that
most
the
times
when
somebody
gives
me
a
surprise,
job
I
have
other
work
and
obligations,
I'm
committed
to
I,
Can't,
Do
It,
full
time.
Other
organizations
have
the
same
problem:
30
employees
and
they're
all
busy.
Oh
sorry,
Crow
is
that
you
no.
D
That
was
an
incredibly
complex
problem
and
back
at
the
time,
I
worked
at
a
fashionable
hat
company
and
the
scope
of
the
software
we
had
to
support
was
about
12
years.
So
we
had
to
go
back
in
time
to
do
things
and
we
had
a
substantial
amount
of
Enterprise
customers
that
ran
the
global
economy
on
very
old
software.
D
That
Linus
and
Greg
and
crew
were
not
supporting
and
when
came
time
to
help
develop
fixes
for
the
melty
ghost
we
actually
had
to
call
people
out
of
retirement,
because
parts
of
the
the
colonel
back
in
the
day
were
written
in
assembly
and
no
one
had
that
skill
set.
So
it
took
a
substantial
amount
of
time
and
then
for
those
developers
that
wrote
the
code
like
10
years
ago
for
them
to
remember
what
the
hell
happened
and
unlearn
10
years
of
more
modern
software
development.
So
it
took
a
while
to
unwind.
D
So
there
are
some
problems,
sometimes
that
are
very
complex
and
people
are
legitimately
working
on
it
and
again,
that's
why
I
advocate
for
the
use
of
the
word
may,
instead
of
will,
because
there's
always
going
to
be
Corner
cases,
there's
always
going
to
be
very
tricky
things
that
require
additional.
You
know,
firefighters,
to
hop
in
that
requires
time.
B
H
H
B
B
H
Know
I
know,
but
but
if
you
give
them
the
out,
then
they
or
you
give
it
to
them
like.
If
you
say
this
is
the
policy
and
you
don't
you
don't
explicitly
State
the
out,
then
you
don't
have
to
argue
them
with
them
about
their
out,
like
you
give
that
you
can
you
put
the
May
in
there
and
like
we
get
the
flexibility,
but
we
don't
want
to
have
to
have
like
fix
the
vulnerability.
Don't
argue
with
me
about
it.
H
E
A
B
H
E
H
B
B
E
B
H
E
B
D
And
I
I
will
advise
you
again
Jonathan,
let's
assume
positive
intent,
that
most
developers
take
pride
in
their
work
yeah.
They
want
their
software
to
be
renowned
and
praiseworthy,
and
so
they
aren't
necessarily
trying
to
dodge
out
of
something
they
just
might
not
have
the
training,
the
tools,
the
experience
or
the
resources.
No.
H
D
H
What
happens,
I
have
died,
I
have
already
been
using
Google's
policy
right,
and
so
it's
basically
this
but
extra
so
I
have
already
face
the
enemy
and
dealt
with
it,
and
that's
why
I'm
fighting
for
the
things
that
I'm
fighting
for,
because
I'm
like
I've,
used
Google's
policy
I've
run
into
these
problems.
It's
yeah.
H
B
B
E
D
E
D
H
D
Yeah
very,
very
there's
a
small
handful,
so
we
need
to
think
about
maybe
talking
with
Jennifer
or
we
develop
our
own
little
comps
plan.
We
could
do
you
know
out
to
mailing
lists.
We
can
notify
and
slack
there's
a
lot
of
different
ways.
We
can
communicate
just
so
people
are
aware
and
understand
what
the
expectations
are.
H
H
D
D
H
H
This
is
so
okay,
so
again,
I
just
to
clarify
this
is
intense.
I
think
this
will
end
up
being
two
separate
documents:
they'll
be
the
bottom
one
which
will
be
like
this
is
a
policy
anybody
can
adopt
the
top
one
is.
We
are
adopting
this
policy
and
those
will
be
two
separate
things.
One
will
reference
the
other
I
love
it
by.
H
E
B
And
I
and
I'm
I'm
probably
going
to
want
to
do
something
like
that
for
some
of
these
stuff,
but
quick
FYI
I'm
in
the
throes
of
trying
to
work
out
an
LF
wide
policy
for
in
incoming
vulnerability
reports,
which
will
basically
say,
go
follow
the
foundation,
slash
projects,
policies,
so
it
it
doesn't
replace
the
open
ssfs.
It
basically
makes
it
so
that
people
more
likely
to
find
it.
Yes,.
D
H
H
D
H
I,
don't
know
yes,
so
so,
but
I
know
that
some
of
the
language
in
there
was
very
U.S
Centric
I,
don't
know
of
anybody
that
has
come
up
with
a
an
incoming
disclosure
policy
that
is
global.
But
given
that
you
CA,
you
have
to
waive
permissions
to
a
bunch
of
laws
that
are
disparate
and
so
like
what
at
a
certain
point
people
have
started
doing
is
just
saying
we
consider
these
actions
to
be
permitted
under
whatever
definition
of
your
law
is
like.
H
D
D
D
And
so
there's
a
lot
of
interesting
nuances.
I
love
the
idea
of
trying
to
find
some
type
of
Safe
Harbor
language.
That
would
be
great
because
again
we're
trying
to
have
the
free
flow
of
communication
and
trying
to
get
things
fixed
quickly,
but
we
have
to
understand
that
everybody
that
finds
something
there's
potential
restrictions
supposed
to
be
aware
of
that.