►
From YouTube: OpenSSF Vulnerability Disclosures (April 19, 2023)
A
A
A
B
A
Oh,
no,
no,
no,
no
I'm
glad
for
you
to
have
less
work
as
long
as
I
don't
have
any
work
so
now,
I'll
I'll
try
to
give
a
give
a
hand
here,
I
think
the
real
problem
we're
going
to
have
is
lack
attack.
We've
got
more
information
than
can
possibly
within
the
time.
So
do
you
remember
offhand
how
much
time
we
have.
B
A
B
C
C
B
B
D
B
A
E
G
B
B
H
I'll
say
a
quick
intro,
I'm
Brian
Russell
I've
been
in
some
of
the
other
open
ssf
meetings,
I
work
with
Alpha
Omega
and
I
work
as
a
product
manager
at
Google,
mainly
here
to
to
talk
about
some
of
the
vulnerability
disclosure
policies
that
Jonathan's
going
to
go
over.
So
thank
you
for
having
me
you're.
D
B
All
right
well,
thank
you
friends.
If
you
have
any
items
you'd
like
to
discuss
today,
please
type
them
into
the
opens
section.
Do
we
have
any
of
our
sub
projects
here
that
wanted
to
give
a
brief
update?
If
not,
we
have
some
notes
below
if
you
scroll
down,
but
does
anyone
here
want
to
talk
about
the
awesomeness
of
their
little
project,
Maybe.
B
All
right,
I
would
all
I
would
strongly
encourage
everyone
if
you
are
able
we
hold
this
call
once
a
month
during
APAC
timeout
time
zone.
So
if
you're
in
APAC
or
west
coast
of
the
states
or
South
America,
you
have
the
opportunity
to
interact
with
our
friends
in
Australia
and
that's
where
the
osv
crew
lives.
Out
of
so,
if
you're
curious
and
talking
about
osv
we'll
be
talking
a
lot
more
with
those
friends
in
the
future,
so
I
would
put
endorsement
for
that.
B
Awesome
and
then
another
one
of
our
cigs
is
open
Vex.
We
just
recently
adopted
them.
They
meet
every
other
Monday
at
3,
P.M
Eastern.
So
if
you're
curious
about
trying
to
find
ways
to
share
vulnerability
information
across
the
ecosystem,
that's
another
great
place.
You
can
participate
all
right.
Let
us
start
our
esteemed
member
Dr,
David
wheeler
has
something
he
would
like
to
discuss
with
us.
Take
it
away,
sir.
A
Okay,
so
so
I
am
moving
around
the
idea
of
having
a
Linux
Foundation
wide
vulnerability,
disclosure
policy.
This
is
you
know,
reporting
vulnerabilities
to
a
Linux,
Foundation
project.
Vast
numbers
do
but
there's
nothing
that
says
on
the
top:
hey
we,
the
LF
like
like
vulnerability,
reporting
I
mean
we
do,
but
there's
nothing.
We
can
point
to
I
I
did
do
a
blog
post
earlier,
but
that
that
talked
a
little
bit
about
this,
but
a
blog
post.
A
Well,
it's
you
know
it's
an
interesting,
it's
not
something
that
people
are
going
to
be
easily
finding.
So
this
is
not
a
done
deal
within
the
LF,
but
I
put
in
some
stuff
about
the
kinds
of
things.
I
think
it
should
say,
and
I
just
want
to
sound
out
some
folks
once
I
can
get
something
to
a
more
stable
State
I
want
to
share
it.
A
Oh,
you
can
see
the
text
here.
If
you
find
a
vulnerability
in
software
developed
by
an
Ella,
Foundation
or
project,
please
report
it
directly
to
that
Foundation
or
project,
using
whatever
they
have
we'll
link
off
to
some
I
mean
number
of
folks
already
have
such
things,
and
if
a
project
doesn't
State
Hunter
how
to
report
a
vulnerability.
You
know
report
to
the
foundation
that
contains
the
project.
A
If
there
is
one
if
it
doesn't
make
it
clear,
then
ask
them
to
fix
to
change
their
process,
to
make
it
obvious
and
then
I
have
some
stuff
about
hey
if
they
don't
respond
after
someday
sometime
re-transmit
several
times,
and
you
know,
but
please
give
everybody
a
chance
to
fix
them,
and
you
know
there
was
a
question
about
how
to
handle
things
that
are
archived.
Basically,
there
are
projects
which
you
know
they're
not
being
maintained
anymore.
A
A
Finally,
this
is
really
appealed
to
projects
of
Foundations.
We
ask
everybody
to
make
it
easy
for
reporters
to
report
our
vulnerability
and
be
ready
to
receive
the
results,
and
this
is
where
especially,
you
guys
come
in,
because
oh
look,
hey,
there's
some
guidance
that
could
help
you
do
that,
and
you
know
talking
about
SEC
security
at
your
domain
at
security.md
file
and
GitHub
private
reporting,
as
things
you
might
do,
is.
E
A
In
fact,
thank
you
for
asking,
because
the
next
line
was
is
basically
hey
at
one
time
there
was
a
discussion
right:
hey,
let's
have
a
generic.
If
you
don't
know
where
else
a
report
report
here,
but
then
I'm
realizing
that
that's
great.
That
sounds
great
for
the
researcher,
but
then
the
next
step
is
oh.
Where
does
it
go?
A
We're
not
going
to
know
better
than
the
researcher
frankly,
and
so
we
do
have
a
security
at
linuxfoundation.org
email
address,
but
we've
decided
to
limit
that
only
to
the
Linux
Foundation
infrastructure,
things
like
DNS
names
and
and
the
web
and
the
main
LF
website
where
we
do
need
somebody
for
those
and
and
those
aren't
actually
part
of
any
particular
project
or
Foundation
or
anything
else.
So
you
know
scoping
it
that
way.
So
for
anything,
but
my
expectations
that
most
reports
are
going
to
be
about
specific
projects.
A
A
D
David,
do
you
have
a
one
concern
that
I
have
is
do?
Is
there
a
central
Repository
of
LF
owned
domains
right
like
or
like
IP
ranges,
or
something
like
that
that,
like
we
can
say
this
is
in
scope
or
because
because,
if
you're
saying
like
LF
owned
right,
especially
when
you're
talking
about
public
services
running
on
the
internet,
if
you
can't
Define
what
that
is,
you
can't
give
permission
over
it
or
you
know
right,
like
a
researcher,
you
can't
say
we
provide
protections
against
all
LF
owned
things.
D
D
A
B
D
A
Well,
actually,
I
don't
know
that
we
need
to
do
the
sub
foundations.
I
think
what
we
have
to
do
is
work
with
LF
infrastructure.
That's
actually
one
of
their
main
tasks
is,
you
know,
is
keeping
track
of
domain
names,
so
I
think
probably
what
would
have
to
do
is
we
have
to
we
we'd
have
to
ask
we.
You
know
we
could
ask
lfit
to
create
and
maintain
a
list,
but
that,
but
that's
the
only
way
I
can
think
of
doing
that.
B
So
a
few
points
in
the
future
if
our
OSS
cert
idea
gets
funded,
that's
something
potentially
that
that
organization
could
help
out
and
be
that
routing
function,
assist
with
that
security
at
lf.org,
potentially
right,
that'll
track
down
the
maintainers,
and
then
I
wanted
to
note
that
this
is
not
identical,
but
is
somewhat
related
to
our
next
conversation
that
Luigi's
going
to
talk
about.
Where
he's
talking
about
a
similar
concept
for
everything
underneath
the
openssf
umbrella.
A
A
So
we
do
want
to
give
Safe
Harbor
to
those
who
are
trying
to
be
helpful,
but
we
do
want
do
not
want
to
give
a
safe
harbor
to
those
who
are
basically
flying
a
false
flag.
So
the
text
we're
going
to
have
to
write
is
going
to
be
I'll
have
to
be
a
lot
more
subtle,
I.
Think
I,
don't
know
exactly
what
that's
going
to
be.
I
know
what
the
goal
is.
I
think
it's
achievable,
but
that's
that's
something
that
is
a
current
discussion
ongoing.
We
may
come
back
and
need
your
help.
B
I
wasn't
transitioning
off.
I
was
about
to
ask
the
group
what
comments
and
thoughts
they
have?
Oh
sorry,
specific
to
Safe,
Harbor
I,
know
the
lady
that
helped
build
disclose.io
and
has
worked
internationally
around
Safe
Harbor
legislation,
a
meat.
So
if
you're
interested
I
could
help
include
her
in
the
conversation
because
she
has
a
lot
of
experience
talking
about
Safe
Harbor,
and
perhaps
she
has
some
language
that
the
LF
legal
team
might
find
agreeable.
B
J
My
thoughts
are
really
on
the
other
side,
being
on
grumpy
old,
open
source
developer.
Thinking
about
all
these
projects
that
you
don't
even
have
a
proper
list
on.
Are
they
prepared
to
receive
this
I
like
Rob's
idea
of
having
a
an
OSS
intermediary
there,
because
my
experience
is
that
it's
easier
to
write
this
kind
of
text
and
publish
for
an
open
source
project
than
to
actually
implement
it
and
handle
vulnerabilities
in
a
proper
way.
A
A
Absolutely
already
doing
this,
the
smaller
ones
are
not
necessarily
ready,
but
I.
Think
my
my
view,
frankly
is
the
goal
is
to
get
them
ready
and
simultaneous
with
this.
Although
this
is
not
your
guys's
problem,
I
intend
to
work
with
LF
management
to
basically
try
to
get
all
our
projects
ready
for
such
things,
and
it
doesn't
have
to
be
sophisticated.
It
can
be
as
simple
as
you
know,
if
it's
a
one-person
project
turn
on
GitHub
private
reporting
and
you
know
get
ready
if
somebody
reports
something
yo.
J
Yeah,
but
the
problem
I
I
was
stumble
into
is
a
culture
problem.
I
spent
10
years
in
the
asterisk
open
source
project
and
we
were
proud
of
every
CBE
we
published
and
all
the
mitigation
we
did
in
the
asterisk
project,
but
now
I'm
in
other
projects
where
there's
some
sort
of
culture.
We
can't
change
where
a
CV
is
never
reported,
fixes
are
committed
in
dirty,
commits
and
yeah,
but
we
have
a
security
policy.
That's
very
proper.
C
A
A
A
A
They
all
do
agree
that
they
want
to
receive
vulnerability
reports
and
they
want
them
it's
fixed
as
quickly
as
possible
and
that's
the
goal
whether
or
not
a
cve
is
assigned
I'm
going
to
leave
that
to
the
individual
projects,
because
people
disagree
on
whether
or
not
that
is
a
worthy
thing
to
do.
But
you
know
what
I'm,
not
if
they
get
found
and
fixed.
A
B
K
Yeah
I
mean
I
can
understand
the
concern
about
the
policy
and
the
process
that
can
be
through
different
things.
It
can
happen
often,
but
I
foreign
should
be
good
enough
and
we
can
start
and
we
can
see
how
the
process
work,
and
if
we
see
that
we
can
improve
part
of
the
process,
we
can
definitely
work
on
it.
In
addition,
it
is
a
good
lesson
for
us
for
the
open
source,
Community
guests.
We
can
learn
something
bright
and
share
what
we
have
left.
This
can
be
definitely
a
good
experiment.
K
We
want
to
do
it
correctly.
Honestly,
it's
I
mean
I
work
on
security
policy
and
security
report
and
communication
with
the
community
of
the
researcher
or
in
general
over
three
years.
So
I
think
that
we
can
do
it.
I
know
that
sometimes
we
can
have
some
conflict
that
can
happen,
but
nothing,
that's
a
good
communication
and
some
good
Improvement
cannot
be
fixed,
so
I
am
not
so
concerned.
Even
if
I
can
understand
why
people
say
having
a
security
policy
and
having
a
security
process
is,
are
two
different
things.
L
Okay,
so
I
just
wanted
to
kind
of
echo
from
the
like
running
the
the
internet.
Bug
Bounty,
which
is
you
know,
a
bug,
binding
program
that
supports
open
source
vulnerabilities
that
that
we
run
one
of
the
things
well.
The
main
requirements
that
we
have
in
place
for
projects
that
are
enrolled
is
that
they
have
an
open
channel
for
vulnerability
reporting.
L
You
know
cbss
or
anything
like
that,
because
there
are
also
projects
that
are
very
much
against
that,
so
the
requirements
that
we
have
in
place
is
just
that
there
is
some
form
of
security
advisory
by
the
project.
That
says
this
is
the
vulnerability.
This
is
the
fix.
It
was
a
security
issue
and
that
this
is
published
in
one
way,
shape
or
forms
for
some
projects.
That's
a
blog
post
for
some
projects.
That's
a
cve,
it's
a
distro,
it's
one
of
those
other
aspects.
L
A
Yeah,
if
I
can
respond,
real
quick
I
actually
agree
that
those
are
good
ideas,
I'm,
not
sure
I'm,
going
to
get
that
to
be
honest
and
I
would
rather
get
people
again.
Report
problems
fix
them
now.
I
I
you'll
note
that
it
report
this
guidance
is
going
to
wreck,
encourages
people
to
use
the
guidance
from
this
group.
The
best
practices
badge
work,
for
example.
A
We
can
always
try
to
add
that
later,
but
right
now,
what
I'm
concerned
about
primarily
is
the
potentially
very
long
delays
between
I
heard,
there's
a
problem
and
getting
something
reported
to
somebody
who
can
do
something
about
it
and
to
the
extent
that
we
can
make
some
sort
of
legal
Safe,
Harbor
I
think
is
a
good
plan
dudes
that
we
can
manage
and
I
see
both
Jonathan
and
crook.
So
I
will
be
quiet.
D
D
No
I
I
do
recognize
that
it
has
happened.
I
just
want
to
I.
Just
wanna
put
it
out
there
that
the
simplest
thing
for
a
security
researcher
to
do
is
nothing
like
the
least
legal
risk.
They
assume
is
to
do
nothing
the
if
they
want
to
see
it
get
fixed
and
they,
the
you
know,
the
second
safest
thing
for
them
to
do
is
anonymously
drop
it
on
paste
bin
or
something
like
that.
Right,
like
there
is
just
like
from
a
legal
risk
perspective
right.
D
D
That
being
said,
so
so
that's
like
the
base
that
we're
working
from
so
in
the
safe
harbor
language
that
we're
crafting.
We
have
to
be
sure
that
we
are
not
setting
a
set
of
constraints
that,
like
you,
have
to
follow
these
rules
exactly
or
Safe
Harbor
doesn't
apply
right
and
that's
if
you
read
a
lot
of
Safe
Harbor
documents
and
a
lot
of
things
that
legal
dot
companies
put
out
there.
It's
you
must
follow
all
of
these
rules
if
you
don't
follow
these
rules
to
the
letter.
D
If
you
go
outside
the
scope
of
these
rules,
if
you
disclose
in
a
way
that
we
don't
agree
with
or
if
you
do
these
things
out
of
out
of
what
in
some
way
that's
not
compatible.
Safe
Harbor
does
not
apply
to
you,
and
that
is
a
a
risk
and
something
that
that
some
people
don't
choose
to
engage
in.
Because
of
that,
because
they're
those
guard
rails,
that
legal
is
setting
up,
still
exposes
the
researcher
to
risk
right.
A
A
That
that's
what
I'm
looking
for
I,
don't
care
about
the
format
that
I'm
looking
for
the
making
sure
because
I
agree
with
you,
that's
that's
important
and
by
the
way,
I
think
we
can
totally
do
that.
I
think
we
can
say
that
hey!
You
know
the
the
goal
here
is
to
not
help
the
attackers
but
to
help
the
Defenders,
and
you
know,
work
from
there.
So
I
think
that's
totally
doable
and
yes,
I
completely
agree.
That's
important.
E
B
Day,
job
I
am
glad
to
assist
in
kind
of
figuring
out
a
comms
plan
and
thinking
up
some
ways.
We
can
get
the
word
out
to
the
different
LF
projects
to
help
encourage
awareness
and
participation,
and
now
I
would
like
to
transition
to
Luigi's
topic,
which
is
again
related.
It's
about
a
reporting
policy,
but
this
one
is
specific
to
the
open,
SSS
and.
B
A
K
K
We
need
to
agree
about
the
search
cover.
Honestly
I
would
prefer
the
first
version
that
have
a
safe
harbor,
and
if
this
means
to
wait
to
two
weeks
one
more
month,
we
can
wait
two
week
one
month,
I,
don't
think
it
is
a
problem.
At
the
same
time,
I
know
that
Linux
Foundation
is
working
on
similar
policy
and
maybe
we
want
to
be
aligned
with
the
leaders
Foundation,
but
this
is
an
internal
problem.
So
I
think.
K
Let
me
correct
me
if
I'm
wrong,
but
we
can
stay
in
touch
with
the
Linux
Foundation
Council
and
see
if
we
can
be
aligned
to
publish
our
policy
and
their
own
policy.
But
from
my
perspective
the
policy
is
more
or
less
really.
I
am
collecting
comments
at
the
moment
and,
except
for
the
safer,
ever
I
think
that
we
agree
on
the
scope
list.
K
K
At
the
moment,
we
want
us
to
implement
a
security
policy
server
document,
another
way
for
the
security
Community
for
the
student
subject
to
report
the
houseful
liabilities,
but
in
the
future.
If
we
agree
on
how
we
want
to
share
Secret
in
Open
Access,
open
ssfl,
we
can
also
introduce
a
pgp
without
no
particular
issue,
and
yes.
E
D
E
K
Well,
technically,
technically,
it
should
be
for
the
email
yeah,
because
if
we
I
mean,
but
if
we
I
mean
if
we
Define
a
procedure,
if
we
Define
a
procedure,
we
can
give
a
pgp
to
every
project
or
maintainer
project.
It's
not
a
problem.
The
main
issue
that
I
see
at
the
moment
is
that
we
don't
have
a
standard
way
to
share
secret
like
a
pgp
and
it's
very
easy
to
lose
them
or
I
am
very
good
to
lose
them
so
without
the
password
and
then
on
our
organization,
password
manager
or
similar
approach.
D
D
Should
we
choose
but
like
ultimately,
I,
don't
necessarily
I
had
a
conversation
with
somebody
about
a
pgp
before
and
and
the
line
that
he
said
to
me
was
I,
don't
want
to
talk
to
anybody
who
wants
to
use
or
needs
to
use
pgp
to
communicate
with,
like
yeah
I,
don't
know
like
I
I.
You
know,
that's
a
that's
a
strong
opinion.
I
know
maybe
for
some
people
but
I
I,
honestly,
don't
see
it
as
a
as
a
massive
Blocker
in
any
capacity.
D
K
K
B
A
Yeah
I
mean
if,
if
somebody
wants
to
make
pgp
available
sure,
but
I
I
mean
we've
had
decades
to
try
to
make
pgp
usable,
it
hasn't
worked,
there's
no
evidence,
it
will
ever
work.
I,
don't
recommend
pgp
at
all.
If
the
goal
is
to
encrypt
the
emails,
may
I
suggest
something
called
MTA,
STS
and
similar
they're
built
in
now.
They
do
hop
to
hop
encryption
you're
already
using
it
all.
Your
emails
are
encrypted.
D
G
A
But
but
basically
increasing
the
email
systems
are
all
supporting
hop
to
hop
encryption
using
either
start
TLS
or
mtasds,
which
me
you
know
and,
and
the
last
hop
IMAP.
You
know
you
use
encrypted
IMAP,
so
well
IMAP
with
TLS,
and
so
yes,
it's
hop
to
hop.
It's
not
end
to
end,
but
it's
encrypted
on
each
stage
and
for
most
folks
that's
good
enough
and,
more
importantly,
they
don't
have
to
figure
out
how
to
use
a
clunky
tool.
That's
too
hard
to
use
and
I
think
that's
more
important.
Information
is
hard,
but.
K
K
Maybe
in
some
countries
in
the
world
you
want
to
encrypt
your
tax
data,
but
at
the
same
time
I
can
understand
why
we
don't
want
to
start
with
a
pgp
and
I
am
not
asking
this
just
that
it
is.
Sometimes
people
want
to
at
least
to
see
it
even
if
they
don't
use
it,
and
this
is
the
main
reason
why
I'm
not
so
I,
don't
think
it
is
a
blocker,
because
if
people
use
the
people
in
community
really
use
pgp,
we
can
think
to
implement
it.
K
B
B
So
that
is
something
I
think
we
should
consider
as
an
option,
because
we
don't
want
to
exclude
any
researcher
or
any
anyone
within
the
community
that
prefers
that
method,
so
to
make
it
an
option
in
the
future
and
I
like
the
fact
that
it's
not
a
part
of
the
1.0
release,
any
other
conversations
about
the
openssf
inbound
policy
and,
again,
please
comment
on
the
document.
We
can
talk
in
slack.
We
have
a
lot.
Let's
continue
this
conversation,
if
we
don't
have
any
further
comments
today.
A
B
B
D
D
D
There
is
also
well
predominantly
with
the
out
and
within
Alpha
Omega,
the
concept
of
vulnerabilities
that
are
getting
reported,
outbound,
and
so
this
is
the
policy
for
oh
fine,
David,
yeah,
okay,
so
this
is
for
the
outbound
vulnerabilities
being
reported,
so
this
has
been
run
by
legal
Mike
Dolan
and
he
has
red
penned.
It
and
I
want
to
go
through
his
feedback
and
I
was
hoping
to
do
that
in
this
meeting
with
people
live
that
seem
like
fine
Chrome.
D
D
That's
like
my
high
level
concern,
but
I
also
see
it
as
like
the
the
intention
of
of
renaming
things
like
you
know,
using
proper
nouns
to
to
Define
things
right
like
the
time
limit
right,
so
it
no
longer
reads
in
my
opinion
as
what
humans
would
read,
but
more
what
lawyers
would
read,
and
it's
not
really
my
intention,
especially
given
that
this
is
not
necessarily
intended
to
be
a
legal
document.
That's
intended
to
be
a
policy
for
you
know.
B
D
Yeah,
so
the
policy
is,
is
this
is
a
policy?
The
process
is,
you
know,
you
know
like
I,
don't
want
to
build
a
policy,
a
process
document,
because
the
process
is
like,
in
my
mind,
more
like
prescriptive
of
a
flow
of
things.
How
things
will
occur
right-
and
this
is
more
like
this-
is
how
we
will
do
things.
I,
don't
know.
Brian
you've
have
better
insights.
Brian
bellendorf
you've
brought
better
insights
into
this
and
lf's
legal
perspective.
Do
you
want
to
share
anything
here.
M
Just
that
what
what
can
come
across
as
legally
is
is
sometimes
also
referred
to
as
Precision
and
and
I.
Wouldn't
I
appreciate
wanting
to
come
up
with
a
policy
that
feels
approachable,
that
that
feels
very
Pro
hacker
Pro.
We
want
to
do
the
right
thing
for
for
everybody
and
and
comes
across
well
at
the
same
time,
if
this
is
a
standard,
we're
being
asked
to
hold
ourselves
to
right
and
and
hold
ourselves
to
others,
I
think
being
precise,
using
standardized
terminology
makes
sense
and,
as
curb
says,
there's
other
stuff.
M
You
can
hang
off
this
like
the
definition
of
a
process,
an
easy
ingest.
You
know
here's
a
form
for
submit
that
that
is
the
more
approachable
side
of
it.
So
I
worry
less
about
the
legalese
I.
Don't
want
to
be
insensitive,
though,
to
your
concerns,
because
you've
you've
touched
a
lot
more
researchers
and
and
developers
on
these
topics
than
I
have
so
that's
all.
I
can
add.
M
D
Right,
I
I,
just
okay,
so
from
the
perspective
of
someone
who's
reading
this
document
with
the
legal
changes
and
you
are
receiving
a
vulnerability
report
from
the
Linux
Foundation
or
from
the
open
source
security
Foundation
right
does
the
legalese
or
the
Precision
and
the
less
kind
of
gentleness
to
it,
come
across
as
aggressive
to
a
maintainer
who's.
Reading
this
for
the
first
time.
D
B
In
my
current
position,
I
work
with
lawyers
every
hour
of
every
day.
So,
from
my
perspective,
what
Mike
is
suggesting
is
very
common
that
actually
what
I
would
expect
I.
This
looks
like
kind
of
suggestions,
I've
seen
on
every
other
kind
of
policy
type
document
I've
seen
throughout
my
life,
so
I
I,
don't
personally
see
anything
objectionable,
doing
a
quick
skim,
but
again
the
perspective
of
a
security
researcher
is
a
little
different
than
mine.
You
know
my
my
main
background
is
Enterprises
and
this
all
makes
sense
to
me.
B
I
see
exactly
where
Mike
is
coming
from
on
these
statements
and
again
it's
the
the
real
reason
behind
his
comments
is
precision
because
you
know
a
capital.
P
policy
is
a
thing
that
the
foundation
can
be
held
accountable
to
and
he
wants
to
make
sure
that
everybody
is
equally
represented
and
protected.
F
B
That's
an
excellent
suggestion.
Nicole
you
have
alternative
documents,
you
could
write
a
blog,
saying,
hey,
look
at
this
awesome
thing
we're
doing,
and
then
you
could
use
more
layperson
language,
it's
just
again
depending
on
you
know,
targeting
that
specific
audience
you're
reaching
out
to.
But
you
know,
capital
P
policy
has
certain
meanings.
D
There
is
not
to
make
a
final
pass
of
this
document
and
see,
if
there's
anything
else,
and
then
hopefully
we
can
hopefully
after
LF
has
has
reviewed
it.
Our
elk
legal
will
give
them
a
chance
to
re-review
it
before
that
meeting,
and
then
we
can
pass
it
off
to
the
attack
after
that.
So
does
anybody
after
this
meeting
wanna
pop
on
a
call
and
go
through
these,
like
review
like
review
points
more
directly,
immediately
one-on-one
I.
D
D
B
B
I
Cool
so
I
just
had
I
had
a
quick
one,
which
is
actually
as
part
of
some
of
the
these
conversations
on
autofix.
And
how
do
we
find?
How
do
we
find
the
maintainers
and
it's
like?
Oh
well,
it's
somewhere
in
the
text
of
a
security
MD
that
you
have
to
read
and
that
works
well
once
it
doesn't
work
well,
when
you
have
a
thousand
of
these
and
just
the
fact
that
there
is
actually
no
standard
like
there's
like
37
different
standards,
it
does
so.
I
I
It's
like
here's,
the
contact,
it's
an
email,
sorry
and
then
you
can
do
whatever
you
want
with
it.
After
that,
so
proof
of
concept,
I
wrote
I'm
very
happy
to
just
give
that
to
open
ssf
or
whatever
it
shouldn't
be
maintained
by
like
me,
personally,
I'm
hoping
that
by
next
week
it's
like
packaged
as
a
you
know,
just
a
pip
install
thing
right
now.
I
It's
a
couple
different
ecosystems
that
leverages
libraries,
I
o
I,
think
I'm
going
to
add
depths.dev,
since
they
just
released
it
an
API
and
then
it'll
crawl
through
GitHub
and
look
for
security
MDS
in
different
directories,
and
it
all
sorts
of
stuff
like
that.
So
does
this
seem
like
a
terrible
idea
to
anybody
that,
like
we
should
not
be
doing
or
that
someone
has
already
done,
and
it's
like
if
I
would
have
just
looked
harder.
I
would
have
found.
B
For
traditional
vendors
Mike,
there
have
been
a
couple
efforts
from
first
to
do
something
similar:
okay,
that's
not
going
to
be
applicable
to
like
Upstream,
but
anything
that's
managed
by
a
vendor.
There
would
be
I
can't
recall.
I
could
look
it
up,
but
basically
it's
a
similar
idea
like
a
security
dot
text
file
on
a
web
page.
That
would
have
all
this
short
information
like
to
report.
K
K
Sometimes
they
have
documents,
but
you
don't
know
where
they
have
so
I
think
it
is
a
very
good
way
to
proceed
and
I
like
it,
because
I
mean
I,
invest
time,
sometimes
to
find
the
right
contact
to
write
maintainers
and
if
they
don't
have
a
security.md,
but
maybe
they
have
other
documents
that
are
not
Linked
In.
The
repo.
B
D
You
know,
apache's
implementation
has
their
own
jira
instance.
If
you're
trying
to
report
to
all
these
different
projects
at
scale,
you
have
to
create
logins
for
every
single
one
and
then
you're
suddenly
dealing
with
having
to
automate
creating
logins
and
stuff
like
that,
and
it's
if
that,
like
diminishing
returns
right
like
it's
totally.
I
Agree,
just
I
may
have
not
looked
hard
enough
and
in
the
right
representative
places,
but
in
every
place
that
I
found
a
contact,
it's
been
it.
Basically,
it's
been
email
or
like
a
web
form,
so
I
haven't
had
the
case
where
someone
said
the
only
way
to
report.
This
is
to
create
a
jira
instance
for
security
issues
for
regular,
bugs
I've
seen
that
a
lot
but
for
security,
there's,
usually
a
a
shortcut.
D
D
G
As
I
was
going
to
mention
the
same
thing
in
my
experience,
I've
having
to
do
Mass
reportings,
a
lot
of
companies
will
just
Outsource
it
to
hacker
one
and
then
or
something
similar,
and
it
does
create
a
roadblock.
But
an
audit
Trail,
which
David
said,
is
not
a
requirement
to
have
an
audit
Trail
yep
I
was
just
gonna.
Add
my
two
cents
to
that.
Yeah.
I
I
mean
at
the
end
of
the
day,
like
we'll
see
in
practice.
So
if
we
have
a
thousand
vulnerability
report
and
we
can
get
800
of
them
done
through
easy
means
and
there's
200
that
we
have
to
like
manually,
do
the
thing:
well,
it's
better
than
doing
it
for
200
than
a
thousand,
and
we
just
know
that.
That's
like
the
the
pain
of
of
of
reporting
stuff,
you
know,
I,
would
just
we'll
give
it
a
shot.
L
If
I
could
just
jump
in
here,
real
quick
I
think
you
know
being
at
hacker
one.
You
know
you.
Never
you
never
address
the
situation
until
all
of
a
sudden,
it's
here
and
so
I
think
the
idea
of
mass
in
Mass
vulnerability,
report,
high
quality,
vulnerability
reporting.
You
know
it's
it's
it's
we're
talking
about
it
because
it's
up
and
coming
so
maybe
that's
something
that
could
be
discussed.
Michael
like
if
you
want
to
reach
out
or
if
anyone
else
wants
to
reach
out
about
you
know.
L
D
No,
sorry
every
other
Wednesday,
because
that
is
an
area
that
we're
discussing
our
plan
for
the
future.
Moving
forward
for
most
organs
is
to,
at
this
time
encourage
them
to
enable
github's
private
vulnerability
reporting,
which
now
has
an
API
to
let
us
report
via,
but
I,
know
that
that's
not
that
doesn't
plug
into
a
lot
of
corporate
disclosure
programs,
and
so,
if
there
is
a
way
we
could
do
this
with
hacker
one
or
something
like
that.
D
If
you
disclose
in
a
way
that
like
if
you,
if
you
want
to
disclose
a
vulnerability,
a
lot
of
them,
State
like
you,
can
only
disclose
with
permission
and
stuff
like
that,
and
so,
if
we
we
would
I.
Don't
think
that
as
a
group,
we
would
be
willing
or
able
to
accept
those
terminal
that
terminology
carp
launch
without
a
carve
out
that
hey
the
work
that's
been
performed
under.
This
is
known
to
not
going
to
be
disclosed
and
and
and
companies
that
are
accepting.
That
have
to
have
to
be
aware
of
that
and
accept
that.
K
Yeah
now
I
want
just
to
say
that
one
can
be
not
the
right
example.
Sometimes
because
there
are
private
company
and
volatility
are
on
the
infrastructure
and
we
are
talking
about
open
source.
So
probably
the
policy
are
less
stick.
I
know
that
some
company
want
to
have
the
control
also
on
the
open
source
projects
and
disclosure
about
the
opposite
products.
But
maybe
we
are
just
lucky
I,
don't
know.
D
Yeah
the
policies
tend
to
be
for
the
infrastructure,
and
then
they
also
add
open
source
in
scope.
Maybe,
and
then
it
just
becomes
something-
that's
very
overly
restrictive
because
they're
they're
talking
about
their
infrastructure
and
it's
a
toss
in
afterwards-
and
it's
like
this,
this
world
of
no
disclosure
does
not
work
for
open
source
when
you're
publishing
stuff
right,
it
needs
to
be
a
cve.