►
From YouTube: OpenSSF Vulnerability Disclosures WG (March 21, 2022)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right,
I
would
like
to
welcome
everybody
to
the
march
21st
edition
of
the
open,
ssf's
vulnerability
disclosure
working
group.
I
am
crow.
I
will
be
our
tour
guide
for
today.
I
posted
a
link
to
our
agenda
in
the
chat.
If
you
have
any
opens
you'd
like
to
talk
about,
please
key
them
in
while
we
work
through
some
business.
B
A
C
D
Yeah
say
hello
as
well:
my
name
is
christine
abernathy
and
I
lead
the
open
source
program
office
at
f5.
So
we
just
recently
joined-
and
I'm
just
kind
of
here-
just
to
learn
more
about.
What's
going
on
in
the
different
working
groups,.
E
I'll
say
hello
as
well,
I'm
so
glad
to
hear
so
many
new
people
here,
my
name
is
paul
da
silva.
I've
been
with
ibm
a
long
time
currently
with
product
security
operations.
I
lead
the
source
code
disclosure
program,
as
well
as
the
secure
life
cycle
program,
I'm
here
to
to
help
and
learn
and
see
if
my
skills
align
with
the
the
ask
here,
excellent.
B
All
right
hi,
my
name's
olivia,
I'm
a
student
at
rit
and
I'm
hoping
to
do
an
independent
study
with
open
ssf
over
the
summer.
I'm
studying
computer
science
security
and
I'm
part
of
the
open
source
minor.
A
All
right
before
we
jump
into
opens,
I
have
two
business
matters
to
talk
about.
First
off
is
I
got
the
awesome
action
item
from
the
open,
ssf
technical
advisory
committee
to
go
review
their
backlog
and
try
to
remediate
a
bunch
of
issues,
and
one
of
those
issues
was
reviewing
the
working
group
charters.
A
So
I
would
love
it
if
I
can
assign
everybody
homework
over
the
next
week.
If
you
could
take
a
look
at
our
working
group
charter,
there's
a
link
there
provide
us
any
feedback
and
then
we
can
try
to
officially
get
that
ratified.
So
that
kind
of
procedural
item
is
taken
care
of
in
our
rear
view
window.
C
A
I
would
like
to
know
if
anyone
has
any
strong
feelings
about
what
is
worded
there.
The
charters
are
fairly
consistent
between
the
working
groups.
We
are
allowed
to
make
changes
if
we
want
to,
but
I
need
to
just
kind
of
as
a
point
of
order.
I
need
to
get
that
move
forward
because
I
slipped
through
the
cracks
over
the
years.
So
if
you
have
strong
feelings,
please
you
know
give
us
a
comment.
A
A
You
can
just
comment
there:
okay,
if
you
have
no
feedback
but
general
concurrence.
If
you
could
note
that
that'd
be
great.
G
Second
thing:
could
we
put
some
time
boxing
around
this,
so
we
don't
just
keep
saying
the
same
thing.
Every
two
weeks
saying
hey,
don't
forget
to
look
at
the.
A
A
So
if
the
group
in
general
agrees
to
that
I'll
send
out
a
doodle,
we
can
try
to
find
a
time
that
is
agreeable.
We
have
some
folks
from
europe
that
aren't
able
to
participate
that
would
like
to,
but
I
know
we
also
have
some
folks
from
the
west
coast
of
the
states.
So
that's
going
to
be
an
interesting
little
puzzle
to
work
out.
Does
anyone
have
any
feedback
on
that.
G
H
G
Seem
to
be
the
one
to
keep
having,
so
I
know
that
a
lot
of
us
participate
in
a
lot
of
other
cross
time
zone
things,
and
unfortunately,
that
means
that
we
have
certain
blocks
of
time
that
are
always
full
because
of
it,
as
I'm
sure
a
lot
of
you
know
so
on
the
west
coast,
our
mornings
are
always
blocks.
We
can
speak
with
people
in
europe
and
and
asia.
G
So
if
it
turns
out
that
we
do
have
people
who
wish
to
participate,
but
scheduling
doesn't
work
out,
would
it
make
sense
to
have
multiple
groups
for
different
time
zones?
I
don't
know
whether
that's
something
we've
considered
in
the
past.
A
That
is
an
option
for
us.
If
we
have
a
big
bifurcation
of
time,
we
could
potentially
split
things
up
into
focus
groups.
If
one
particular
group
want
to
work
on
a
special
project,
and
yes,
so
that
is
an
option.
A
If
we
wanted
to
have
two
sessions
that
becomes
a
bit
cumberplex
for
some
of
us,
but
we
can
work
that
out
and
what
I
would
do
before
we
make
any
changes
is
we
would
send
out
a
doodle
to
the
mailing
list,
give
everyone
time
to
vote,
what
times
worked
out
best
for
them
or
what
times
didn't
work
out,
and
then
we
would
try
to
find
the
best
consensus
for
a
time.
I
Yeah
thanks
rob
just
some
of
the
other
working
groups
alternate
every
other
meeting
to
make
it
a
bit
more
friendlier
to
asia
pack
versus
emea.
So
that's
another
option.
G
We
also
seem
to
would
have
some
confirmation
bias
going
on
with
asking
the
people
who
are
actually
able
to
make
it
to
this
call.
So
are
we
doing
the
outreach
in
on
the
mailing
list
or
slack
or
anything
like
that?
I.
A
I
will
be
doing
that.
Yes,
several
of
the
people
that
aren't
here
asked
me
to
change
the
time,
and
I
said
I
can't
do
that
without
getting
enough
folks
enough
critical
mass
to
do
that.
But,
yes,
I
will
plan
on
sending
it
out
to
the
mailing
list,
we'll
put
a
deadline
on
the
doodle,
but
it
sounds
like
we
have
some
options.
Also
put
so
I'll,
send
an
email
with
a
couple
suggestions
that
we've
detailed
here
alternating
times
two
different
meetings,
keeping
it
the
same
and
then
I'll.
A
Let
folks
kind
of
participate
in
that
and
then
we'll
do
a
doodle.
If
we
decide
we
want
to
do
a
meeting
time
change
and
that
might
also
inform
us
on
when
potential
alternating
times
might
work
out,
because
I
know
we
have
some
folks
from
australia
in
particular
that
aren't
able
to
participate
regularly,
especially
as
we
go
through
time,
zone,
changes
or
daylight
savings
changes.
G
So
the
past
few
calls
I've
been
letting
you
know
that
I'm
trying
to
get
that
I
am
getting
someone
from
spx
defects,
which
is
their
vulnerability
disclosure
type
thing
to
come
and
talk
to
us
about
what
they're
doing,
and
that
is
still
happening
just
very
very
slowly.
The
person
with
whom
I
was
speaking
apparently
went
on
vacation,
and
I
didn't
know
that
so
just
want
to
let
you
know
that
is
still
going
on,
but
it'll
happen
eventually.
A
C
You
and
just
to
clarify
olivia
is
not
my
student
and
she
works
on
stuff,
which
sounds
very
interesting,
but
I
think
she's
here
independently.
My
student
welcomes
me.
My
student
is
abby
who's,
not
really.
My
student,
the
student
of
a
close
collaborator
of
mine
abby,
is
also
here
I,
but
I
don't
think
she
introduced
herself
happy
if
you're
still
online.
Do
you
mind
speaking
up
and
introducing
yourself.
C
She
may
just
be
here
in
spirit,
but
not
in
person,
so
all
right,
so
I
guess
I'll.
Do
this
I'll
do
the
talking.
So
we
are.
This
came
from
an
idea
that
was
floated
around
in
the
other
working
group.
C
The
identifying
security
threats
and
mike
scovetta
was
the
one
for
those
of
you
of
you
who
know
him
who
brought
this
up
this
sort
of
recurring
pattern
of
observation
that
there
is
sort
of
an
ecosystem
of
security,
researchers
to
report
vulnerabilities
to
open
source
projects,
and
sometimes
those
reports
may
not
be
done
and
try
to
be
very
careful
with
the
wording
here
in
a
way
which
is
knowledgeable
or
respectful.
C
So
we
have
some
already
some
ideas
on
various
faulty
noises
for
what
type
of
which
specific
forms
does
bug
reports
take.
You
know
we've
gone
from
like
people
having
a
realistic
timeline
such
as
you
know.
I
reported
this
bug
a
week
ago.
Y
isn't
fixed
or
if
you
don't
pay
me,
I'm
gonna
go
in
public
with
these
or
is
to
an
extent
also
think
people
that
report
things
that
are
not
really
vulnerable
vulnerabilities
and
a
recurring
one,
for
example,
seems
to
be
hey.
Your
code
is
on
is
on
the
web.
C
You
know
for
reporting
this
on
open
source
project,
so
I'd
be
interested
a
in
any
idea
from
folks
about
what
we
should
be
looking
into
and
b.
If
you
know,
if
you
are
interested
in
talking
to
us-
or
you
want
to
propagate
this
information
to
anyone
who
may
be
interested
in
talking
to
us,
this
is
all
done
anonymously
and
you
know
you
won't
see
the
name
on
any
report
or
things
like
that.
But
you
know
the
conclusion
we
reach.
We
hope
to
be
able
to
help
the
community
with
them.
A
J
J
One
great
thing
about
us
studying
this
in
the
context
of
open
source,
though,
is
perhaps
we
can
create
some
kind
of
norms,
so
something
that
I've
talked
about
a
bit
in
this
group
in
the
past
has
been
wanting
to,
and
maybe
this
is
related
to
some
of
the
other
things
later
on
the
agenda
today,
but
wanting
to
have
a
bit
more
of
a
de
facto
standard.
J
J
Because
what
I'm
hearing
anecdotally
like
from
projects
but
from
vendors
too,
is
that
in
the
last
couple
of
years
as
more
people
have
gotten
into
bug,
bounty
there's
been
a
lot
of
lower
quality
reports
as
well,
where
someone
just
uses
some
kind
of
automated
tooling
and
they
like
try
to
shoot
a
bug
over
often
with
expectation
of
a
financial
reward
that
maybe
wasn't
as
normalized
in
the
past
as
well.
So
I
think,
there's
cool
work.
J
We
could
do
in
this
group
around
norm
setting
and
obviously
there's
people
here
that
work
like
in
cv
and
things
like
that.
That
are
better
informed
than
me.
That
might
be
able
to
point
us
toward
existing
work
in
this
space
that
we
could
perhaps
leverage,
I'm
not
sure,
but
I
think
setting
some
norms
setting
some
clear
demarcations
as
well
as
to
what
is
considered
acceptable
and
unacceptable,
because
I
think
that
a
lot
of
that
isn't
well
known.
K
Hey
this
is
kayla
hello
from
I
work
hacker
one
first
off.
I
think
it's
a
great
topic,
one
question
which
I'm
pretty
sure
the
answer
to
but
might
as
well
ask
this
is
you
you
would
be
mostly
interested
solely
interested
in
talking
to
open
source
projects
right?
Is
that
right,
lorenzo.
C
Well,
I
mean
we
have.
We
are
kind
of
looking
at
open
source
because
that's
it's
in
easier
access
paths,
but
you
know
we
think
this
happens.
Also
with
you
know,
in
the
commercial
incorporation
space-
and
you
know
we
are
not
sort
of
against
looking
at
that
space
too-
maybe
perhaps
less
of
interest
to
this
particular
group,
but
we're
certainly
you
know
the
the
phenomenon.
I
think
it's
pretty
universal
across
commercial
and
open
source.
K
Absolutely
okay!
So,
first
off
I
I'd
love
to
connect
at
some
point
and
get
you
connected
with
folks
on
on
our
team
that
we
might
be
able
to
hook
you
up
with,
because
I'm
sure
there's
lots
of
people
with
thoughts
on
this.
That
would
be
helpful
for
you
to
talk
with
and
then
also
are
you
looking
from
the
researcher
side
of
this
as
well,
or
are
you
focusing
mostly
on
the
receiver
of
the
vulnerabilities
first.
C
I'll
I
put
leave
my
email
address
in
the
meeting
menus
and
I
also
directly
reach
out
to
anyone
who
mentioned
to
be
directly
interested
during
the
meeting.
Okay.
Great.
Thank
you
very
much.
C
Oh
okay,
yeah,
I
didn't
know
you
were
from
wpi
too,
but
yeah
nice
too
nice
to
meet
someone
else.
Indeed,
yes,
nice,
to
make
your
acquaintance.
A
So
while
we
are
not
directly
as
part
of
our
next
project
kind
of
going
out
and
doing
a
survey
of
maintainers,
we
have,
as
a
group
collectively
talked
about
this
issue
in
the
very
recent
past,
so
much
so
that
we
as
jennifer
alerted
to
alluded
to
our
next
project,
is
trying
to
help
set
some
norms
and
accepted
practices
for
security
researchers.
A
C
C
A
Yeah,
we
definitely
have
recognized.
This
is
an
issue,
a
stressor
for
open
source
maintainers.
So
we
decided
last
year.
One
of
our
projects
was
creating
a
coordinated
vulnerability.
Disclosure
guide
for
software
maintainers
and
open
source
software
projects-
and
we
felt
a
next
endeavor
might
be
useful-
is
to
create
a
companion
piece
focused
on
security
researchers
to
try
to
help
lay
out
some
of
what
a
good,
behavior
or
acceptable
practice
is
within
open
source
and
trying
to
report
and
remediate
vulnerabilities.
A
I
put
a
link
in
the
agenda,
so
what
I
would
like
to
do
today
would
potentially
be
to
brainstorm
on
sections
or
kind
of
do
a
straw
man
of
what
areas
we'd
like
to
talk
about
and
what
you're
looking
at
in
the
google
doc
is.
I
copied
over
our
existing
document
cannibalized
a
couple
of
the
sections
and
some
of
the
words.
So
this
is
just
a
very
draft
starting
point
for
us
to
look
at
and
think
about
how
we
want
to
approach
this
problem.
L
Hi
I
got
a
couple
how
to
get
a
cd
number
also,
like
you
know,
not
only
how
to
get
a
cv
number,
how
to
get
a
cvn
number
in
the
face
of
potential
conflict
with
the
maintainer.
Like
you
know
what
the
processes
are
with.
What
processes
exist,
for
example
the
cv
appeals
process.
L
You
know
who
you
know
who
can
issue
cdes,
who
are
the
easy
cnas,
for
example,
like
I
really
like
using
snick
for
you
know,
but
what
the
pitfalls
of
using
various
different
cnas
may
be
stuff
like
that,
so
yeah,
I'm
also
happy
to
I'm.
Not
I
can't
write
it
or,
but
if
somebody
wanted
to
sit
down
and
have
a
conversation
with
me
like
I'm
more
than
happy
to
like
like
brain
dump,
that
into
a
section
that
could
get
written,
I
just
don't.
I
can't
do
the
writing
myself
necessarily.
A
To
kind
of
kick
start
ideas,
one
of
our
earlier
projects
was
kind
of
brainstorming
on
pain,
points
between
the
different
personas
within
open
source
software,
and
we
have
links
to
the
which
personas
was
it
the
security
we
have
the
maintainer
and
the
finder
personas.
So
a
developer
and
a.
K
So
I
think
one
thing
that
would
be
helpful
is,
even
though
it
seems
redundant,
would
be
a
really
high
level
overview
of
what
is
open
source.
You
know
it's
kind
of
like
that.
The
the
vulnerability
report
you
get
that
says,
hey
your
stuff
is
out
in
the
open.
It's
like
yes,
well,
it's
open
source,
just
a
an
explainer
for
researchers,
of
what
open
source
entails
and
even
a
description
of
you
know
the
of
the
folks,
the
community
who
work
in
open
source
so
that
same
to
kind
of
maybe
drive
up.
K
The
empathy
of
you
know
this
is
a
volunteer
group
that
is,
is
all
about
community
and
you
know
just
to
get
to
know
them
a
little
bit
so
get.
I
know
that
I
did
see
who
are
open
source
maintainers,
so
that
section
for
sure,
but
then
also
just
what
is
open
source.
A
And
what's
there
is
again
just
a
is
mud
on
the
wall
for
us
to
form
into
a
beautiful
piece
of
art.
So
it's
not
intended
to
be
the
final
product
and
then
I
think
that's
an
excellent
suggestion.
Kayla
jennifer.
J
This
is
pretty
basic,
but
it
I
feel
it's
often
missing.
So
what
types
of
things
should
be
included
in
that
initial
bug
report,
because
often
the
handshake
to
get
this
stuff
rolling
is
too
too
many
steps.
It
doesn't
need
to
be
this
way,
so
we
might
think
of
having
some
standard
things
that
we
recommend,
including
so
maybe
affected
systems
specifically
versions.
J
We
might
want
to
have
a
cvss
score.
I'm
not
sure
we
might
want
to
talk
about
like
have
them,
articulate
the
impact
on
the
system
in
terms
of
the
security
properties
rather
than
just
kind
of
spitting
out
a
finding,
and
one
thing-
that's
maybe
a
bit
more
controversial,
but
we
could
consider,
at
least
maybe
including,
is
some
suggestions
or
some
norm
setting
or
at
least
like
a
discussion
of
when
to
release
exploits
so
you
know,
would
it
be
considered
good
practice
to
release
an
exploit
on
the
day?
J
A
patch
goes
out
or
some
guidance
as
to
how
to
make
that
decision,
because
like
for
us
at
ncc
group,
for
example,
you
know,
sometimes
we
will
release
the
exploit
the
day.
Advisories
go
live,
but
sometimes
we'll
hold
on
to
them.
For
longer
and
it's
a
bit
of
a
nuanced
decision-
and
I
think
maybe
if
we
provided
more
of
the
like
here's-
the
things
to
think
through
when
making
this
choice
in
an
explicit
way,
that
could
be
helpful.
A
Thank
you
excellent
suggestion,
jennifer,
and
I
missed
a
couple
of
the
early
notes
of
what
you
things
you
wanted
to
put
into
the
example
of
a
report.
So
if
you
would
like
to,
I
have
notes
at
the
very
bottom
of
the
document.
L
Thank
you
just
a
tail
dovetail
off
of
that
one
biggest
suggestion
that
I
wish
I'd
known
beforehand.
I
think,
like
you,
know,
I've
done
this
long
enough.
I
wish
I'd
learned
this
earlier
sort
of
thing
write
your
disclosure
for
the
public
so
that
you
don't
have
to
rewrite
it
twice.
L
So,
if
you're,
the
same
disclosure
that
you're
potentially
going
to
use,
try
one
things
I've
learned
is
try
to
structure
your
disclosure
to
the
maintainer
such
that
that
same
information
is
the
same
information
you
can
provide
to
the
public,
because
then
you
don't
afford
the
disclosure
twice
and
then
the
end
user.
The
the
public
gets
the
same
information
that
you
disclose
to
the
end
to
the
maintainer,
and
that
saves
a
ton
of
time
when
you
do
the
final
public
disclosure
of
your
research.
L
Other
thing:
vulnerability:
disclosure,
disclosure
timelines.
Like
you
know
what
are
the
standards?
What
are
the
norms
around
vulnerability?
Displeasure
timelines,
you
know
without
getting
into
the
topic
of
what's
it
called
like
ethical
without
getting
into
ethics
like
these
are
the
norms
right,
like
you
know,
around
like
90
days,
45
days.
These
are
the
research
firms
that
use
45
days
of
these
terms
to
use
98.
J
I
do,
but
if
there's
anyone
else
with
something
to
share,
they
can
go
ahead
of
me
all
right.
The
other
thing
I
was
thinking
as
jonathan
was
speaking
as
well
was
not
just
some
guidance
around
timelines,
but
we
could
also
consider
tips
for
getting
patches
completed
written
so
that
was
very
inarticulate.
Let
me
try
again
guidance.
J
We
can
provide
around
incentivizing
or
encouraging
the
creation
of
a
patch
by
a
maintainer,
so
something
that
I've
found
is
very
effective
is
to,
and
it
tends
to
be,
like
my
last
resort,
hail
mary
thing:
when
people
are
being
unresponsive
or
whatever
is
to
offer
like
hey,
can
we
have
like
a
15
or
30
minute
phone
call
with
you
and
we
can
talk
through
the
phone?
We
can
talk
through
what
the
fixes
look
like.
J
We
can
answer
questions
so
if
we
can
give
tips
that,
like
from
our
experiences
we've
learned,
have
helped
get
patches
into
systems,
that
would
be
great
as
well.
A
Yes,
good
feedback,
jennifer
jason
asks
should
we
be
targeting
the
personas
at
our
github
repo,
yes
jonathan
and
we're
focusing
in
right
now
on
the
finder
and
maintainer,
but
there's
obviously
a
lot
of
additional
work.
We
could
do
to
talk
about
how
suppliers
might
better
work
with
upstream
maintainers
or
how
suppliers
could
work
with
finders
how
everybody
could
work
with
coordinators.
A
Any
other
feedback
ideas
what
we
might
want
to
incorporate
into
the
guide.
F
There
are
a
lot
of
attacks
out
there
that
really
don't
go
into
the
attack,
but
are
more
like
what,
if
kind
of
deals
and
those
can
be
time,
wasters
from
a
company
perspective.
A
J
J
I
mean,
I
guess
another
way
we
could
get
at.
What
we
might
want
to
include
in
this
could
be
thinking
about
the
problems
that
researchers
face.
So
are
there
other
problems
that
we've
not
tried
to
solution
yet,
and
could
we
outline
what
those
are
and
maybe
see
if
there's
things
we
could
put
into
this
guide
that
would
help
mitigate
some
of
those
problems.
A
J
A
So
I
had
actually
worked
on
this
with
crystal
from
hacker
one,
a
long
time
back.
A
H
It
might
be
adjacent
to
this
work
or
it
might
fit
really
well
within
it.
So
I
want
to
just
ask
the
question:
sometimes:
when
vulnerabilities
are
found,
they
are
actually
in
lower
level
dependencies.
H
You
know,
there's
a
vulnerability
in
a
service
or
an
api
or
a
project,
but
actually
it's
coming
from
a
dependency
of
that
or
a
piece
of
hardware
that
uses
something
like
that.
Possibly
some
guidance
would
help
in
those
situations
when
the
developer,
to
whom
the
issue
is
reported
then
has
to
go
coordinate
with
others
under
embargo,
to
figure
out
how
to
do
not
just
according
between
the
research
or
the
developer,
but
then
between
the
developer
and
in
other
projects,
companies
or
firmware
if
it
has
a
kind
of
dependency.
H
A
Jonathan
notes
in
the
chat
making
sure
that
you're
reporting
the
vulnerability
to
the
right
place,
trying
to
get
it
reported
fixed
as
close
to
the
root
cause
as
possible.
Yeah
absolutely.
F
Yeah,
what
about
having
a
database
of
companies-
and
you
know,
emails
to
reach
out
to
usually
it's-
you
know
pcert.company.com,
but
something
the
open
source
community
go
go.
Look
at.
I
found
something
in
xyz,
I
go
to
this
database
and
they
know
who
to
contact.
I
know
it's
not
possible
for
everything,
but.
L
Disclose.I
o
exists,
that's
some
that's
more
focused
for
companies,
but
that
is
what
the
goal
of
disclose.oh
that
project
is
kind
of
aiming
towards,
so
maybe
piggybacking
on
that
existing
database.
For
this
sort
of
that
card
sort
of
use
case
could
be
useful.
K
And
so
another
possibly
doesn't
need
to
be
stated,
but
I'm
not
sure
topic
would
be
if
just
out
calling
out
the
difference
between
a
bug,
bounty
and
a
vulnerability
disclosure
when
it
comes
especially
in
the
world
of
open
source
like
just
because
you're
disclosing
this
vulnerability
does
not
mean
that
you're
going
to
get
paid
for
that.
This
is
a
vulnerability
disclosure,
and
these
are
the
difference
of
those
and
just
just
explaining
what
that
means.
Just
in
case
they're
unaware.
A
J
Maybe
some
guidance
around
validating
the
correctness
of
to
whom
you're
reporting,
so
people
that
are
claiming
to
be
associated
with
a
project
that
aren't
or
we've
come
across
a
few
examples
in
the
last
year
or
so
of
like
fake
maintainer
emails
for
security
bugs,
and
I
don't
know
how
hard
or
easy
it
will
be
to
give
anything
too
prescriptive,
but
maybe
at
least
warning
researchers
like
here's,
where
you
should
probably
consider
to
be
like
the
authoritative
book
of
record
of
things
to
communicate
and
here's
when
it's
probably
a
little
bit
sketchier.
A
I
think
we
can
certainly
just
like
in
the
original
guide
we
can
just
provide
some
guidance
saying
here
is
how
typical
here's,
how
some
example
projects
are
set
up,
here's
how
they
are
contacted
and
how
you
can
go
in
and
check
that
might
be.
I
agree
with
ava.
It
might
be
a
little
too
deep,
but
if
you.
L
Jonathan,
did
you
have
your
hand
up,
sir?
You
did
to
tie
into
the
topic
of
what
is
a
like.
What's
interesting
in
a
bug
binding
program
number
one
with
this
closure
program,
the
pitfalls
of
agreeing
to
being
unintentionally
agreeing
to
a
non-disclosure
agreement
when
doing
vulnerability.
Disclosure,
because
you
disclos
take
an
example:
I've
disclosed
vulnerabilities
to
companies
and
you
try
to
send
a
vulnerability
report
about
open
source
software
and
you
send
their
send
them
into
an
email,
and
then
they
say
great.
Thank
you
for
sending
us
the
email.
L
Here's
the
hacker
one
submission
form
that
we
have
and
then
you
go
and
look
at
their
hacker
on
submission
form
and
the
policy
they
have
on
their
hacker.
One
submission
form
is
a
non-disclosure
policy
and
the
vulnerability
you're
trying
to
report
isn't
something
that's
open
source
and
it's
definitely
gonna
need
a
cve.
L
And
how
do
you
kind
of
navigate
that
around
like
hey?
I
want
to
disclose
this
vulnerability,
but
I
also
don't
want
it.
I
know
that
this
can,
I
can't
be
bound
by
an
nda
in
order
to
do
so
how
to
navigate
that
from
experience.
Also
happy
to
help
with
that
with
a
or
I
don't
know,
a
pair
writing
session.
C
Yes,
thank
you
very
much.
I
mean
I
would
say
this
is
extremely
interesting
and,
as
a
newcomer,
I
just
want
to
ask
for
my
own
understanding,
because
I've
been
skimming
all
this
document.
As
you
were,
posting
links,
is
there
anywhere
where
there
is
a
sort
of
a
set
of
agreed
upon
goals
or
intelligent
intended
audience
for
this
document,
because
I
was
hearing
people
proposing
many
pieces
and,
as
a
newcomer
have
a
bit
of
a
hard
time
piecing
everything
together.
A
This
is
our
very
first
time
ever
talking
about
this
project
as
a
group,
so
if
we
are
interested
in
laying
that
out
now,
I'd
appreciate
that
otherwise
I
probably
get
stuck
writing
that
down.
A
I
I
that's
definitely
something
we
need
to
do
is
to
kind
of
scope
out
precisely
who
we're
targeted
at
and
my
impression
is
we're
targeted
towards
the
researchers
at
this
point,
but
there's
a
lot
of
very
heavily
intertwined
issues
here.
A
I'm
casting
a
wide
net
right
now
and
we'll
get
into
editing
and
writing
in
the
future.
A
But
that's
not
to
say
if
there
is
an
idea,
that's
out
of
scope
for
this
document
that
we
couldn't
reuse,
that
for
some
other
project
down
the
road.
M
Thanks
I've
been
kind
of
trying
to
figure
out
how
to
say
word
this,
but
let's
give
it
my
best
shot.
So
one
of
the
one
of
the
things
I
was
thinking
about
is
kind
of
the
softer
and
fuzzier
aspects
of
vulnerability
disclosure
around,
and
I
guess
it's
building
a
little
bit
on
jonathan's
point
about
always
consider
the
fact
that
it's
going
to
be
public
and
writing
it
public.
First,
you
know
one
of
the
troubles
I
see
a
lot
is
the
thing
that
gets
circulated
in
the
media
is
not
the
vulnerability
disclosure.
M
It's
the
first
article,
that's
written
by
the
media
outlet
after
the
vulnerability
disclosure
and
those
articles
are
often
either
wrong
or
warped.
I
was
just
reading
a
vulnerability.
You
know
there
was
a
vulnerability
thing.
I
was
reading
that
was
floating
around
the
lines
yesterday
and
I
was
like
this
is
completely
bogus
and
I
went
and
looked
at
the
disclosure
that
the
person
writing
it
had
it
all
wrong,
so,
just
being
as
crystal
clear
as
you
can
in
the
disclosure
and
writing
it
for
kind
of
newbie
audience
point
of
view
type
of
thing.
M
A
Other
feedback
about
the
pro
ideas
for
the
project.
K
Question
sorry,
I
realized
harry
I'm
trying
to
raise
my
hand
and
I've
already
unmuted
myself,
so
I'm
clicking
around
anyways.
So
I
realized
that
I
would
like
to
get
some
more
feedback
from
teams.
My
my
teams
around
me.
I
know
that
that
was
something
I
should
have
been
working
on
the
past
two
weeks,
but
this
has
been
a
good
guide
to
help
me
think
structure
through
this
and
like
how
to
think
about
it.
So
if
we
want
to
go
back
to
our
teams,
go
back
to
our
networks
get
more
input.
K
A
A
How
would
we
like
to
organize
ourselves
and
collect
feedback
nikki.
G
I'm
a
big
fan
of
the
of
the
repo
and
the
issues.
I'm
really
glad
that's
the
way.
You
did
it
last
time,
that's
before
me,
but
that
makes
it
really
public
and
lots
of
people
who
can't
show
up
to
this
call
can
still
participate,
and
you
know
they
don't
have
to
deal
with
jumping
through
the
google
hoops.
G
A
Any
other
thoughts
about
making
a
repo-
I
think
it's
a
repo,
you
know
repo
or
it
could
just
be
adjacent.
I
don't
recall
specifically,
did
we
like
to
follow
that
process
like
we
did
last
time.
A
Everyone
fine
submitting
issues
and
prs.
A
Okay,
so
it
sounds
like
that
is
how
we
will
proceed
mark
a
decision
down,
and
so
I
I
will
take
the
ar
to
take
our
feedback
from
today
and
try
to
see
how
it
is
organized
and
then,
as
we
get,
that
repository
started,
I'll
put
the
outline
there
that
we
can
start
to
chew
on
some
more
and
potentially
start
adding
to
any
questions
or
comments
about
that.
G
A
quick
one
for
the
notes
so
you're
going
to
take
the
feedback
and
incorporate
it
into
the
document.
Then,
are
you
going
to
also
create
the
issue?
I'm
sorry,
I
missed
that
last.
A
No,
I'm
not
a
githubologist,
but
I
can
try
my
best.
A
I
will
take
the
feedback
from
the
notes
and
what
is
in
the
google
document
or
the
guide
right
now,
and
I
will
try
to
synthesize
that
into
a
workable
outline
of
topics
and
then
we
can
figure
out
mechanically
how
to
get
the
repository
up
and
running
with
the
right
rights.
I
might
have
to
go:
ask
jen
or
jory
for
assistance.
G
A
And
then
I
will
also
send
this
out
in
to
the
mailing
list,
so
again
feel
free
to
respond
there
with
additional
feedback.
Until
we
get
that
repository
staged
and
ready
to
go.
L
I
wrote
up
a
long
thread
like
a
year
ago
about
like
the
pitfalls
of
vulnerability
disclosure
in
when
I
was
chatting
with
people
in
the
in
the
get
up
security
lab
group,
and
I'm
trying
to
find
that,
because
if
I
can
find
that
I'll
send
that
off
to
you,
zero
I'll,
send
I'll
I'll.
Send
that
to
you.
To
I
mean
it's,
not
it's
unfiltered
and
also
like
not
necessarily
available
to
just
go
public,
but
it'll
give
some
like
I've
done
this
before
here.
L
All
the
pitfalls
that
I
had
that
I
I
had
written
up,
but
I
just
can't
find
it
currently
so
yeah
were.
L
Yeah
and
unfortunately,
the
github
security
lab
has
a
the
slack
has
like
a
you,
can't
view
messages
before
may
10th
2021
and
I'm
like.
Oh,
I
wish
I'd
snagged
that
because
I
spent
a
lot
of
time
writing
it.
Where
is
it
now
so
yeah?
I
just
can't
get
to
see
hey.
Can
I
get
access
to
that?
Maybe
potentially
so
yeah?
Okay,.
A
So,
look
for
a
barrage
of
emails
from
me
about
the
charter
about
the
potentially
moving
the
time
and
then
officially
kind
of
kicking
off
this
project,
so
I'll
send
out
at
least
three
mails
to
the
list
feel
free
to
respond
there
or
as
issues
as
relevant.
Like
for
the
charter,
we
have
a
issue.
Please
comment
there.
If
you
have
strong
feelings
about
it
and
with
that
I
will
adjourn
us.
I
want
to
thank
everyone
for
your
time
and
participation
today.
A
Great
conversation
very
excited
about
this
new
project
and
our
target
release
date
is
going
to
be
early
august,
to
try
to
motivate
us
to
run
forward
and
do
awesome
things
the
betterment
of
the
community.
So
thank
you
all
enjoy
the
rest
of
your
days.
Wherever
you
are
and
we'll
be
talking
very
soon
cheers.