►
From YouTube: OpenSSF Vulnerability Disclosures (May 1, 2023)
A
So,
while
we're
waiting
for
the
larger
group,
so
I
would
still
like
to
wrap
up
the
Linux
Foundation
wide
thing
and
what
I'm,
what
I'm
thinking
might
be
a
good
I,
don't
realize
we're
on
recording
for
incoming
vulnerability
reports.
What
I'd
like
to
do
is
maybe
just
quickly
Cobble
together
some
sort
of
Safe
Harbor
statement
based
on
existing
materials.
That's
generic
and
then
send
it
to
legal
to
get
that
reviewed
and
beat
up
and
so
on.
A
A
A
E
B
B
A
A
B
F
B
B
D
B
A
B
B
D
A
G
Well,
so
so
in
a
formal
document
right
you
take
that
you
take
words
like
that
out,
typically,
normally
all
that
stuff
out,
you
follow
it
up
with
a
sentence.
You
or
you
say
this
will
happen
within
seven
days
or
with
the
following
exceptions,
and
then
you
note
those
like
I
I,
don't
like
what
what
that
was
like
typical,
normally
all
that
stuff.
That's
too
much!
That's
too
much
gray
for
a
formal
document.
A
A
A
Yeah,
the
the
problem
we've
got
is
that
you
know
there's
many
cases
where
we've
got
an
attacker,
but
it's
not
known
to
the
to
most
attackers
and
the
and
if
we
disclose
to
everyone
we're
causing
much
more
harm
by
letting
all
the
attackers
know
when,
in
fact,
it's
a
very
small
subset
of
attackers
who
are
exploiting
something
sure
so
the
overall
goal
I
mean
I.
Think
of
this
as
an
integration
problem
you're
integrating
over
time.
Yes,
you
are
trying
to
minimize
the
total
area
of
damage.
Yep.
F
Yeah
totally
agree
and
I
get
the
trade-off.
All
I'm
suggesting
is
that
we
keep
the
flexibility,
because
we
don't
know
what
the
integration
is
going
to
look
like
before
that
event
happens
exactly
some.
Some
of
them
are
evident
clear
evidence
of
public
exploitation.
Everyone
already
knows:
why
are
we
going
to
wait
five
days
to
disclose?
F
That's
I
want
to
just
be
sure
that
we
can
act
accordingly
in
that
situation
and
to
your
point
David,
if
right,
if
it's,
if
we
know
there's
a
little
bit
stuff
going
on
but
but
disclosing
it
publicly,
would
really
open
the
floodgates
too
soon
and
off
the
integration
curve.
Yes,
we
should
hold
off
for
up
to
seven
days.
No,
no
argument
there
I
just
want
the
policy
to
allow
both
ends
of
the
equation.
F
A
G
A
D
B
You've
been
working
in
disclosure
for
a
long
time
and
I've
spoken.
I
spoke
to
Madison
about
this
during
the
last
call
too
David's
perspective
proposal
here.
Is
that
the
unusual
circumstances
be?
You
can
deterministically
determine
that
the
attack
that
there's
only
a
single
attacker
with
knowledge
of
the
vulnerability.
F
I,
what
I'm
suggesting
is
that
the
way
we
write
the
policy
we
allow
ourselves
the
ability
to
in
David's
terms
right
create
that
integration
whatever
function
for
that
case
as
it
goes
and
I
I
would
I
would
not
I
would
never
probably
say
deterministically,
there's
only
one
attacker
who
knows,
but
there
could
be
few.
We
could
expect
that
there
are
few
I
would
fully
agree
that
a
premature
public
disclosure
increases
the
area
of
damage.
F
F
Okay,
well
here,
I
think
literally
Within
within
seven
within
seven
days.
I
think
actually
addresses
my
issue
letter
of
the
law.
You
know
zero
zero
minutes
is
within
seven
days
and
seven
days
within
seven
days.
So
back
back
when
we
wrote
this
at
cert
CC
we
kept.
We
did
not
explain
much,
but
it
was
a
much
easier
policy
to
maintain
when
you,
when
you
keep
it,
keep
it
less
less
words
but
I'm
not
saying
we
should
right.
We
said
here
just
that
yeah
anyway,
so.
F
B
Or
the
problem
with
putting
a
rash
every
single
vendor
will
argue
that
they
need
more
than
seven
days
right.
There
will
be
no
vendor
that
will
be
like
well
in
our
case
seven
days,
you
know
you
disclosing,
prior
to
there
being
a
fix
is
going
to
protect
like
every
single
vendor
is
going
to
argue
that
and
the
the
I
I.
B
A
Yeah
all
right
I
have
added
a
new
paragraph
below
okay,
because
you
know
I
actually
completely
agree
with
Jay
that
you,
if
you're
going
to
have
an
exception,
you
need
to
explain
the
rationale
the
the
wind
is,
that
exception.
I
had
some
text
earlier,
I,
don't
know
what
happened
to
it,
so
I've
I've
put
in
some
different
texts.
Maybe
this
will
be
more
acceptable.
The
exception
is
in
cases
where
we
can
determine
that
the
overall
damage
to
users
will
be
less
if
more
than
seven
days
are
granted.
F
G
G
If
you
take
longer
time
or
something
like
that
right
that
something
should
come
back
to
say
well,
it
could
provide
us
a
reason,
provide
us
with
reasoning,
for
you
know
or
or
there
should
be
some
type
of
Reason
provided
for
the
except
for
the
notification
to
take
longer
right.
I
I
mean
I.
Think
with
that
with
that
wording,
that's
what
that
opens.
It
opens
up
to
to
requiring
that
additional
information.
B
A
A
C
B
There
are
so
many
places
you
can
have
arguments
sure
and
and
I
I
I
struggle
with
the
the
thing
that
I'm
struggling
with
is
giving
another
place
for
a
maintainer
to
an
engage
in
an
argument
with
you
in
the
vulnerability
disclosure
process
he's
exhaust.
It
sounds
as
the
reporter
to
be
another
point
to
exhaust
and
wear
you
down
as
the
reporter.
A
Right,
the
problem
is,
of
course,
that
it's
actually
not
the
we're
trying
to
optimize,
frankly,
not
for
the
reporter,
but
for
the
end
user
right.
We're
trying
to
minimize
damage
to
end
users
now
I
agree
that
if
you
overwhelm
the
reporter
too
much,
that's
also
going
to
cause
long-term
harm.
The
end
users.
F
A
B
A
A
B
A
B
B
C
B
B
B
G
F
B
C
A
F
F
B
B
H
H
I
H
C
A
B
Zero
day,
okay,
yes,
you
believe
that
more
urgent
action
is
appropriate.
The
public,
the
publication
date
for
a
zero
day
will
be
accelerated
to
within
seven
days
of
the
notice
date,
with
one
exception
described
below.
We
offer
an
exception
for
cases
where
we
did
determine
that
will
there
will
be
less
overall
damage
to
users
if
more
than
seven
days
are
granted.
This
would
typically
be
because
there
is
evidence
that
widespread
exploitation
is
unlikely
maintainers
merely
requiring
more
time
to
fix.
B
B
The
reason
for
this
special
o-day
designation
is
that
for
each
day,
an
actively
exploited
vulnerability
remains
undisclosed
to
the
public
and
unpatched
more
devices
are
accounts
to
compromise.
Seven
days
is
an
aggressive
time
limit
and
maybe
too
short
for
some
maintainers
to
update
their
software,
but
should
be
enough
time
for
maintainers
to
publish
advice
about
possible
mitigation
such
as
temporary,
disabling
Services,
restricting
access
or
contacting
the
retainer
for
more
information.
C
D
I
A
Okay,
that's
the
logic
of
this.
Now
you
can
argue
that
maybe
that's
not
right,
but
I,
actually,
don't
I,
don't
think
we
should
care
whether
or
not
it's
obsolete,
because
people
say
it
that
they're
not
going
to
maintain
and
then
they
get
a
report
and
then
they
change
their
mind.
So
I
I,
don't
I
I
think
we
should
just
you
know,
follow
the
process
and
and
ignore
that
it's
less
helpful.
A
If
they,
if
they
reply
to
us
and
say
we're
not
going
to
fix
it,
I
think
that's
already
covered,
isn't
it
if,
if
they
express
you
know
if
we
do
not
see
receive
any
engagement,
well,
yeah,
we
already
say:
if
we
do
not
receive
an
engagement
that
infirms
their
intention,
we
were
reserve
the
right
to
explore
to
disclose
that
point.
So,
basically,
if
they
say
nah
we're
not
going
to
fix
it.
A
Yeah
I
guess:
according
to
this
logic
we,
but
but
it's
not
getting
but
yeah
it.
Basically
it
says
that
35
days
at
that
point
because
they've
we
have
not
received
any
engagement
that
says
they're
going
to
fix
it.
They've
actually
said
they
won't,
but
I
guess
that
then
it's
still
just
within
the
35.
there's
an
argument
for
that
I
guess
they
could
change
their
mind,
but.
A
A
A
B
A
B
G
D
G
Right
there
with
you,
I
know
these
organizations
they're
running
they're,
running
some
type
of
crazy
application
that
can
only
be
run
on
a
legacy
OS
of
some
sort
on
some
type
of
Bastion
host
somewhere.
That
only
connects
one
time
once
every
five
years
to
receive
something
or
other,
and
that
is
the
one
time
when
somebody
decides
to
introduce
something
something
crazy.
So
yes,
careful,
they'll,
reach
out
and
say:
hey,
hey,
hey,
hey,
hey,
hey
I'm,
trying
to
be
as
as
clandestine
as
I
can.
When
I
talk
like
this
now
come
on.
Jeff.
E
G
A
H
F
B
A
F
B
The
word
risk
implies
a
a
reducing.
The
amount
of
risk
is
reducing
the
amount
of
chances
for
damage
to
action,
damage
to
actually
occur
right
versus
right,
so
you're,
reducing
the
the
potential
for
the
damage
to
occur.
If
you're,
reducing
versus
reducing
the
damage
occurring
right,
it's
like
you're,
you're,
abstracting,
one
step
away
and
so
risk
in
and
of
itself
is
kind
of
nebulous
right.
A
I
think
in
this
case
it
doesn't
matter
because,
when
you
say
overall
damage
to
users,
as
I
said,
you're
Integra,
you
are
doing
a
sum
of
all
the
of
all
the
damages.
Some
of
them
will
have
damage.
Some
of
them
will
not,
which
basically
encapsulates
the
likelihood
so
I
I.
Think
if
you,
if
I
was
doing
calculus
I'd,
say
these
two
equations
have
the
same
answer.
If
you
sum
up
all
the
damage
or
you
compute,
the
expected
damages
for
each
and
you
sum
up,
it's
the
same
thing
it's.
What
is
what
are
you
expecting?
F
B
Consistent
with
it,
so
so,
okay,
so
this
is
the
reason
that
I'm
kind
of
bringing
this
up
right,
sure
country
a
builds
nuclear
bomb
country
B,
builds
a
nuclear
bomb
right
they're
both
planted
at
one
another.
There
is
a
lot
of
risk
there,
but
because
both
of
them
have
nuclear
bombs,
one
at
each
other,
less
likely
that
they're
going
to
actually
shoot
it
at
one
another.
Well,
that
lowers
the
risk
sure
it
lowers
the
risk,
but
the
risk,
the
the
exist.
B
The
existence
of
country
a
having
built
bomb
outside
of
the
context
of
both
countries
having
bomb
is
right.
It
has
to
do
with
there's
a
certain
amount
of
like
the
risk
is
like
the
potential
for
a
thing
to
happen.
The
actual
thing
that
could
the
thing
actually
being
likely
to
happen,
May
like
Risk,
is
so
nebulous
that
it
has
to
do
with
the
probability
of
the
risk
occurring
and
that
probability
may
be
one
percent,
but
yeah.
F
A
B
F
You
don't
care
about
yeah,
it's
yeah
I
mean
it's
damaged,
yeah
and
it
again
I'm,
I
I,
don't
think
it.
The
word
all
I'm
really
asking
this
is
more
of
an
editorial
position
than
a
a
debate
on
risk
risk
versus
consequence
versus
threat
versus
you
know
probability
I
think,
there's
still
probabilities
involved,
someone's
still
going
to
choose
to
attack
or
not
a
lot
or
a
little
one
person
doing
it
a
lot
one
person
you're
doing
to
one
key
place,
there's
a
lot
of
factors:
I
I
for
this
policy.
F
I,
don't
think
it
matters
the
choice
of
word.
But
again,
unless
we
mean
different
things,
different
points
in
the
policy.
Let's
say,
then
damage
is
fine.
They've
wrote
damage
this
morning,
but
we
have
harm
somewhere
else,
which
is
a
synonym
great
risk
down
below,
which
is
a
different
word.
So
just
because
this
is
true,
we
can
just
pick
yeah.
C
B
F
Don't
care
okay
and
then
I.
The
reason
I
also
brought
it
up
is
I
went
as
David
was
talking
about
the
integration
of
the
minimizing
damage
for
users.
I
went
and
thought
we
should
just
have
that
sentence
somewhere.
I
put
it
up
at
the
top,
but
it's
actually
already
sorted
down
here
and
I
threw
it
back.
I
put
it
in
again
more
clearly
we
can.
This
is
sort
of
covered
by
reducing
risk
for
the
ecosystem
and
soft
Landings,
but
I
thought
we
should
just
State
this.
Clearly.
F
This
is
a
little
different
than
you
know.
We're
just
just
just
doing
this
to
get
researchers
to
do
what
we
want
or
we're
just
just
just
just
just
doing
it
for
maintainers
if
we
are
really
doing
it
for
everyone,
let's
be
clear
about
that
and
I
think
that's
a
great
thing
to
say,
but
maybe
that's
not
our
position
here.
So
that's
when
I
wrote
the
word
risk
and
then
I
thought
what
did
we
say
elsewhere
we
said
damage
we
said
harm.
F
A
B
B
Okay,
so
the
reason
a
policy
like
this
exists
is
to
two
things
right.
It's
you
use
the
action
where,
where
this
policy
actually
gets
used
and
has
to
get
deployed,
creates
a
precedent
that
shows
main
maintainers,
that
they're
failing
to
act
will
necessarily
result
in
negative
Downstream
consequences
to
their
end
users
right.
So
it's
not
about
respecting
the
interests
of
researchers
and
maintainers.
It's
it's
it's!
This
policy
is
not
just
for
the
one
vulnerability,
but
it
is
for
all
future
vulnerabilities
beyond
the
point
where
you
actually
have
to
exercise
it.
F
F
H
H
C
B
A
A
B
H
B
A
B
C
F
B
B
B
B
A
B
B
A
A
B
H
H
A
D
B
Okay,
so
yes,
we
are
respecting
maintainers
researchers,
less.
The
the
policy
Point
again
is
to
protect
users
through
its
application
over
the
long
term
right.
It
is
not
necessarily
about
as
applicability
in
a
single
case
and
that
that
that
mindset
is
also
what
researchers
see
right.
The
researcher
mindset
is
this
policy
is
not
just
for
this
one-off.
C
B
B
B
B
A
The
footnote,
where
what
footnotes
are
invisible
in
a
lot
of
browsers?
If
you
have
a
footnote,
it's
like
it
doesn't
exist.
So
if
you
want
a
footnote,
you
really
it
has
to
be
for
text,
you
don't
care
about
I,
don't
I
recommend
not
having
footnotes
in
the,
because
this
is
going
to
become
HTML
and
then
the
HTML.
No
one
will
see
it.
It's
going
to
go
Mark
day
it's
going
to
become
markdown
but
yeah
even
worse,
yes,
but
markdown
becomes
HTML
and
then
then
we'll
see
it.