►
From YouTube: OpenSSF Vulnerability Disclosures (April 5, 2023)
A
A
A
D
D
A
All
right,
Roger,
dodger
I,
wanted
to
just
briefly
highlight
for
everybody.
The
open
source,
Summit,
North
America,
is
coming
up
here
in
May
and
we
had
a
fairly
substantial
representation
from
this
working
group
and
other
kind
of
Affiliated
working
groups
and
sigs.
So
if
you
are
going
to
Vancouver
I
strongly
encourage
you
to
pop
back
into
any
of
these
sessions
and
say
hello
to
your
brothers
and
sisters
that
are
given
fighting
the
good
fight
and
talking
and
helping
educate
the
community.
A
Speaking
of
the
open
source
Summit,
there
is
a
European
Edition
coming
up.
The
call
for
papers
is
open
until
May
it's
going
to
be
held
in
Spain
this
year.
So
if
anyone
is
interested
in
submitting
papers,
if
you
would
like
assistance
from
the
group,
we
did
last
time
around.
We
kind
of
did
some
abstract
feedback.
A
D
A
All
right,
we
have
a
couple
updates
on
our
sub
projects
for
the
cert
Sig,
that
is
still
under
review
by
the
governing
board.
I
have
seen
a
very
nice
presentation
that
LF
staff
put
together
kind
of
summarizing
the
plan,
making
it
more
executive-y,
and
we
are
a
topic
on
the
docket
for
the
GB
meeting
tomorrow.
So
hopefully
we
will
either
start
to
get
some
feedback
on
the
Sig
plan
or
potentially
people
that
are
interested
in
funding
it
or
we'll
get
some
feedback
that
it's
a
terrible
idea,
we'll
see.
A
For
the
auto
fix,
Sig
did
Jonathan
pop
on.
He
has
not
yet
I'm
sure
he'll
be
here
soon.
He
talked
about
the
vulnerability
disclosure
policy
that
the
Alpha
and
Omega
project
is
has
proposed.
That
many
of
us
here
have
provided
feedback
on
the
attack.
Yesterday
we
didn't
have
Quorum.
It
was
also
a
lame
duck
session
because
we
had
a
new
tack
elected
and
then
there
will
be
a
couple
more
folks,
appointed
by
the
governing
board
later
this
week.
B
A
A
Underneath
this
working
group
we
had
our
first
call
Monday,
pretty
good
participation,
so
we're
just
kind
of
strategizing
on
how
we
want
to
get
the
industry
to
start
using
more
Vex
how
we
can
work
with
other
communities
like
scanners
and
whatnot
so
and
big
topic
conversation
was
a
logo
so
that
the
team
is
busily
hurting
out
getting
bar,
napkins
and
pencils
and
scrambling
down
ideas
that
we
will
eventually
have
a
logo
for
the
Sig.
Eventually,
everyone
is
welcome
to
come,
participate
and
you'll,
hear
more
information
about
that.
A
A
So
far,
it's
predominantly
been
the
osv
crew
they're
located
in
Australia,
and
the
three
of
us
had
a
nice
chat
talking
about
the
project.
So
if,
when
that
video
is
up
and
running,
if
you're
curious
to
kind
of
hear
a
status
from
Oliver
and
Andrew,
you
can
see
the
video
and
kind
of
their
big
thing
is
their
goals,
for
the
upcoming
future
are
how
they
can
get
wider
adoption
of
osv
and
then
how
to
get
better
integrated
into
this
working
group.
So
any
thoughts
and
ideas
we
have
around
that.
A
E
A
A
The
osv
team
yeah
we
have
links
to
them
in
our
git
repo
and
I'll
post,
a
link,
there's
a
link
at
the
repo
at
the
very
top
of
this
agenda
and
I
they
have
their
own
slack
Channel
as
well,
which
I
will
get
posted.
Let
me
see
here
what
is
you
know?
Their
slack
Channel
osv
schema
is
their
slack
Channel
good
crew
they've
been
affiliated
with
this
group
for
a
while,
and
it's
just
because
of
the
time
zone.
It's
just
challenging.
So
again
anyone
that's
interested
in
having
a
6
p.m.
A
A
E
A
E
Yeah,
but
you
know,
but
I
I
just
talked
to
somebody
else
who
has
a
security
policy
where
they
include
here's.
How
to
write
secure
code
here
is
how
we're
we're
going
to
run
our
build
environments
and
Harden
them,
and
that's,
presumably
not
what
we're
going
to
cover
so
I
just
want
to
make
sure
the
title
and
the
contents
match.
F
Hi,
everyone
yeah
I,
don't
think
that's
true,
but
maybe
I'm
on
yeah
I'm
on
my
I'm
on
my
phone
I,
don't
have
a
good
keyboard.
Let
me
see
here
there
are
one
or
two
other
disclosure
policy
sort
of
threads
going
on
I.
Think
one
is
for
inbound
to
the
open,
ssf
or
no,
no
sorry,
I
lied.
One
is
outbound.
If
we,
if
you
open,
ssf,
find
something
yes
I
try
to
make.
F
G
A
F
H
A
H
E
E
A
E
E
Okay,
so
two
items
and
I
tried
to
slip
them
in,
hopefully
in
the
right
place.
In
this
channel
number
one
is
GitHub
private
reporting.
This
is
pull
request:
number
47
on
the
open
source
software
vulnerability
guide,
so
basically
GitHub
to
the
relief
of
many
of
us
who
have
been
begging
for
many
years
and
I
and
I
do
want
to
I
I
I
say
that
but
I
don't
want
to
I'm,
not
trying
to
besmirch
our
GitHub
friends.
So
thank
you
actually
GitHub.
E
So
basically,
GitHub
has,
for
various
reasons,
been
very
concerned
about
adding
the
ability
to
do
private
reporting
of
vulnerabilities
on
GitHub
projects.
However,
I
think
it's
very
important
and
they
have
finally-
and
they
have
announced
that
formerly
it's
in
beta
but
I
I,
don't
I,
think
zero
people
expect
it
to
go
away,
and
you
know-
and
so
basically
it
means
that
for
a
lot
of
works,
it
suddenly
is
much
much
easier
to
accept
vulnerability
reports
than
it
has
been
before.
E
E
It's
important
to
me
that
this
get
added
soon,
because
I,
there
are
other
things
cooking
in
the
works,
but
we're
gonna
we're
we
we
plan
to
refer
to
this
guide,
but
this
needs
to
be
part
of
the
guide.
For
that
to
make
any
sense
is
everyone?
Okay,
with
adding
this
I
mean
it's,
it's
not
a
mandate,
Thou
shalt,
but
it's
a
recommendation
too
and
I
think
that's
reasonable.
A
E
A
E
Yeah
we'll
get
that
fixed
I
have
no
idea
how
in
the
world
that
would
have
happened.
Okay,
so
sorry
about
that
all
right,
yeah,
so
so
we'll
get
that
fixed
later
all
right.
So
if
I
may
indulge,
if,
if
I
may
indulge
I
have
one
more
request
from
the
group
I'm
revealing
a
little
bit
but
hey
what
the
heck
we're
all
friends
here
right
there
we
go
so
I
and
a
couple
of
the
people
are
are
okay.
First
of
all,
let
me
make
it
clear.
E
This
is
not
a
done
deal,
but
I
have
been
pitching
that
there
be
an
LF
wide
policy
that
every
LF
foundation
and
LF
every
LF
project
have
a
be
able
to
accept
vulnerability
reports
and
have
some
and
for
dealing
with
them.
To
me,
that's
not
controversial.
That
said,
LF
in
historically
at
least,
has
been
rather
reticent
to
put
too
many
requirements
on
all
foundations
and
projects,
because
you
know
the
little
tiny
project
where
there's
no
funding
and
what
there's
one
you
know
of.
E
Maybe
two
people
is
really
different
than
say:
kubernetes
or
Linux
kernel,
and
just
there's
such
a
variety
of
projects
that
there's
a
reticence
to
try
to
impose
pose
too
much
generally,
but
I
think
this
is
a
case
where
it,
it
just
seems
like
if
there's
something
we
can
say
so.
The
I
have
shared
with
you
kind
of
draft
text
that
I
intend
to
include
as
part
of
a
general
telling
people
hey.
If
you
find
a
vulnerability
in
open
in
projects,
here's
how
to
do
and
then
oh,
by
the
way.
E
Much
of
this
is
cribbed
from
the
work
of
this
group,
and
we
briefly
cite
some
other
things
of
the
opennesses
have
done
has
done.
I
would
love
to
know
since,
since
this
is
primarily
about
vulnerability,
disclosure,
I'd
love
to
know,
does
this
make?
Do
you
think
this
kind
of
thing
would
make
sense
for
everybody.
C
So
I
have
seen
policies
like
this.
I
was
actually
just
this
morning,
working
with
the
airline
foundation
on
creating
their
first
vulnerability
disclosure
policy
for
like
their
whole
ecosystem
of
which
they're
using
our
maintainer
guide.
For
just
so,
we
don't
know,
love
it:
okay,
okay,
yeah,
so
they're
they're
doing
it
in
such
a
way
that
kind
of
like
a
last
resort,
if
you
can't
reach
any
maintainers
like
we
will
handle
this
and
and
that's
the
the
way
they're
scoping
their
policy.
E
Oh,
although
it's
not
an
explanation,
because
the
paragraph
I
copied
in
is
part
of
a
larger
dock,
the
current
intention
is
that
we're
going
to
have
a
security.
Well,
we
actually
already
have
security
at
Linux
foundation.org,
as
basically
the
the
backstop
for
everything
in
the
LF
we're,
but
we're
telling
people
don't
use
that
unless
you
can't
find
anything
else,
because
we
don't
want
Linux
kernel
reports
to
go
there.
We
don't
want
open
that.
You
know
we
want
go
to
this
specific
project.
E
E
F
Try
yeah
yeah
sure
so
the
LF
as
a
backstop
last
resort.
Yes,
if
I've
got
a
security
issue
and
I'm
looking
where
to
report
it,
if
I
find
you
know,
obviously
a
program
or
project
a
foundation,
a
large
distributor
that
will
handle
it
great,
go
there.
If
there's
nothing
else,
security
at
Linux,
Foundation
could
catch
such
reports
and
the
scope
would
be
something
that
is
sort
of
in
the
LF
umbrella
in
some
way,
or
is
it
sort
of
any
open
source
whatsoever?
Yeah,
okay,
LF?
E
E
E
F
Sorry
understood
I
wanted
to
sort
of
check
on
that
I'm
I,
don't
know
if
it's
quite
accurate
to
say
that
the
openness
OSS
search
was
sort
of
considering
this
idea.
I
have
been
considering
it
in
a
couple
of
organizations,
I'm
part
of
to
look
at
sort
of
a
report.
You
know
a
capability
of
really
Last
Resort
sort
of
for
the
internet,
much
less
for
open
source.
F
So
just
curious
I
want
to
make
sure
that,
if
I,
if
something
like
that
moves
forward,
it
is
not
tripping
over
other
people
who
are
already
doing
it
so
I'm
good.
Thank
you.
Lf
makes
sense.
That's
a
very
appropriate
scope.
I
think
for
this.
This
piece
of
work
anyway,
I'm
I'm,
a
proponent
of
that
being
all
the
backstops
that
we
can
find
in
appropriate
places,
so
yeah
I
agree.
Thank
you.
A
E
Yeah
now
now
for
for
the
for,
for
the
security
at
Linux
Foundation,
the
expectation
is,
we
would
immediately
route
it
to
whoever
in
the
LF
is,
is
involved.
To
be
honest,
the
primary
one
or
thing
that
we're
expecting
that
to
be
used
for
is
for
LF
infrastructure.
Like
you
find
a
vulnerability,
foundation.org
website
right,
the
LF
linuxfoundation.org
isn't
actually
a
project.
It's
you
know
it's
an
organizational
site,
and
so
there
isn't
a
project
to
report
to
so
what
the
heck
do
you
do?
Well,
here
you
go.
E
E
You
know,
so
we
just
want
to
make
sure
there's
a
way
to
report,
and
you
know
what,
if
this
broader
OS
open
source
software
thing
gets
some
a
report
and
they
find
out
it's
a
Linux
Foundation
project,
but
they
can't
figure
out
how
to
report
it
to
there.
We
would
tell
them.
Well,
here's
the
generic
Linux
Foundation
report
used
to
sell
it
to
us
and
we'll
we'll
track
it
down.
E
Thank
you.
Thank
you,
yep
I
I,
my
right
now.
My
expectation
is
that
I
haven't
really
tried
to
push
us
up.
The
flagpole
yet
is
I.
Can't
imagine
anyone
complaining
about
the
idea.
It's
more
a
cultural
thing.
This
is
you
know,
just
you
know
we
we
don't.
We
don't
enforce
lots
of
yeah
I
got
that,
but
these
are
you
know.
We
still
need
to
do
it
anyway,
so
and
I
think
that's
actually
often
a
problem
with
some
of
these
security
things
is,
you
know
it's.
F
E
E
My
current
plan
is
to
try
to
get
the
it
folks
to
do
with
all
the
hard
work,
but
if
I,
if,
if
I
can't
manage
to
Slough
off
all
the
work,
then
I
and
some
other
folks
may
actually
have
to
do
some
more
work.
But
you
know
you
you
try
to
make
sure
other
you.
You
get
everybody
else
to
do
all
the
hard
work
where
possible.
E
A
H
I
J
I
What
else
the
autofix
working
group
is
still
meeting
GitHub
announced
last
week,
the
addition
of
an
API
for
maintainers
to
read
from
GitHub
security
advisories
that
have
been
published
or
sorry
that
are
being
worked
on.
This
is
the
repository
ones.
So
these
are
the
private
reports
and
coming
down
the
pipeline,
hopefully
over.
The
next
two
weeks
is
an
API
to
allow
security
researchers
to
open
private
vulnerability
reports
via
an
API
instead
of
having
to
do
Sofia
button
clicky
things
on
GitHub.
I
A
All
right
with
that,
then
we
will
adjourn
for
the
day.
Thank
you
all
for
your
time
and
attention
participation
as
you
have
feedback
on
any
of
the
items
we've
talked
I've
tried
to
wherever
possible,
linked
to
the
issue
in
the
agenda,
and
you
know
we
have
a
slack
and
email
list
if
anyone's
interested
in
engaging
with
the
group.
Thank
you
everybody
and
enjoy
the
rest
of
your
day.
Cheers
foreign.