►
From YouTube: Vulnerability Disclosures WG (February 8, 2021)
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
Okay
looks
like
we're
live,
so
welcome
to
the
open
source
security
foundation,
vulnerability,
disclosures
working
group
meeting,
it's
february,
8th
2021
I
and
welcome
everybody.
Let
me
let
me
share
my
screen
with
with
the
notes
and
the
agenda.
So
if
you
all
you
could
all
of
you
attending
today
could
ungrade
yourself
in
the
on
the
list
of
participants.
A
I
will
later
on
be
able
to
transfer
that
to
the
meeting
minutes
on
github,
and
I
noticed
we
have
a
few
folks
who
are
new
on
the
call.
So
if
you
could
introduce
yourselves
and
tell
them
tell
us
you
know
where
you're
from
and
what
what
got
your
interest
in
our
working
group.
B
Hi,
this
is
dan
middleton.
I
work
at
intel.
I've
been
poking
around
different
parts
of
openssf,
and
this
is
my
first
time
joining
today
saw
the
note
about
the
white
paper
and
thought
would
take
a
peek
in
and
see
what's
going
on
here.
C
Hey,
I'm
alexander
romero,
go
by
rairo,
same
same
sort
of
story
there,
as
well
also
with
intel.
A
C
D
Thanks
hi,
my
name
is
jonathan
laichu.
I
work
at
gradle
inc.
I'm
part
of
this,
I'm
a
security
software
engineer
there,
I'm
also
an
open
source
security
researcher,
so
I
have
been
doing
open
source
security
research
using
codeql
as
part
of
the
github
security
lab.
D
Probably
most
notably,
I
was
the
one
that
reported
the
giant
zoom
vulnerability
in
june
of
2019,
the
one
that
blew
up
in
all
the
media,
and
I'm
here
I'm
also
a
github
star-
and
I
I'm
here
because
of
the
link
in
the
the
google
blog
about
this
organization
and
some
of
the
discussions
there.
So
yeah.
A
Oh,
you
mean
the
google
blog
that,
like
the
one
with
the
goals
and
followed
by
the
osb
announcement,
okay,
okay,
so
just
for
just
for
the
context,
all
right,
some
welcome!
Is
there
anyone
else
who.
E
I'll
go,
my
name
is
james
johnson.
I,
let's
see
we
have
a
few
of
us
from
git
lab
I'm
on
the
vulnerability
research
team
at
gitlab
and
I've
been
following
the
emails
and
a
little
bit
about
what
the
working
group
has
been
doing.
But
I
haven't
directly
joined
myself,
and
so
this
is
me
directly
joining
and
wanted
to
participate.
F
I
have
a
big
interest
in
vulnerability,
vulnerability,
research
and
vulnerability
management,
particularly
being
on
the
tail
end
of
a
devsecops
when
it
kind
of
started
to
come
to
fruition
as
that
term
and
taking
care
of
vulnerabilities
for
multiple
people
and
understanding
how
they'd
be
whether
they
had
to
be
triage,
for
they
have
to
be
remediated
or
just
accepted,
and
I
was
one
person
managing
like
all
of
that,
which
was
not
fun
so
very
interested
to
see
kind
of
how
this
progresses
as
a
as
a
group.
A
Thank
you.
Is
there
anyone
else,
I'm
just
scrolling
the
the
list
of
attendees.
A
A
Sounds
like
that's
all
newcomers,
I'm
actually
quite
excited
that
we
have
so
many
new
folks
on
the
call
so
welcome
once
again.
So
some
of
you
were
kind
of
drawn
by
the
disclosures
white
paper
that
we
started
to
talk
about
the
last
time
we
met
and
I'm
definitely
I
definitely
want
to
spend
some
time
trying
to
organize
our
us
again.
A
You
know
in
working
against
that
goal,
but
there's
there's
one
like
organizational
thing
that
I
wanted
to
chat
with
you
about,
and
that
is
the
sort
of
leadership
of
this
working
group
and
the
transition.
So
I've
been
lucky
enough
to
kind
of
participate
and
lead
this
working
group
ever
since
it
was
formed
still
under
the
open
source
security
coalition.
A
A
So
I
thought
it's
probably
like
time
for
me
to
to
step
down
as
a
lead
and
pass
this
to
people
who
have
been
co-leaders
in
ever,
since
we
kind
of
formed
and
chris
was
kind
enough
to
step
forward
and
take
over
as
a
as
a
group
lead.
So
a
huge
shout
out
to
chris
and
sooner
and
I
think,
you'll
he'll
do
a
terrific
job
leading
this
group
for
what
it's
worth.
A
I
plan
to
stay
involved
as
much
as
possible
as
as
a
contributor,
so
I
am
I'm
not
leaving
not
leaving
too
too
far
so
a
round
of
applause
for
chris
for
stepping
up.
I
I
think
it's
really
awesome
that
that
we
have
someone
who
who
can
step
up
and
lead
the
group.
G
A
Agreed
yeah
and,
as
I
said,
I'm
I'm
not
I'm
not
going
anywhere
so
I'll
I'll
still
hang
around
all
right,
so
probably
chris
will
will
take
over.
You
know
logistics
and
scheduling
of
all
the
meetings
and
and
all
the
kind
of
fun
stuff
that
that
goes
into
putting
those
those
meetings
together.
It's
a
it's.
It's
not
a
hard
job
and
that's
also
like
it's
been
a
pleasure.
So
so
that's
cool
I
and
or
are
there
any
questions
about
that.
A
I'll
I'll
take
that
as
a
no
okay,
so
so
the
last
time
around
we
kind
of
started
to
chat
about
the
the
white
paper,
and
I
think,
when
I
originally
kind
of
proposed
the
idea,
just
to
just
a
little
recap
with
I
thought
about
doing
something
quite
comprehensive
and
building
on
all
the
knowledge
exchange
that
was
happening
here
in
this
working
group
in
those
calls
for
for
the
last
few
months.
A
But
during
the
discussion
we
had
the
last
time
it
was.
I
think
we
arrived
at
the
conclusion
that
that
would
be
what
would
be
more
valuable
would
be
a
white
paper.
A
That's
focused
on
open
source
maintainers
right,
so
so
we
wouldn't
do
as
like
an
epic
100
pages
long
thing
that
covers
you,
know
all
the
things
and
standards
and
workflows
in
open
source,
vulnerability
disclosure,
but
we
would
address
the
need
of
you
know
in
an
open
source
maintainer
that
wants
to
do
the
right
thing
when
it
comes
to
vulnerability
disclosure,
but
they
don't
quite
know
how
to
do
that
and
we
can
quickly.
We
can
discuss
that.
This
is
probably
like
the
vast
majority
of
open
source
maintainers.
A
A
lot
of
critical
projects
gonna
have
either
like
a
corporate
owner
or
you
know
there
are
people
from
organizations
that
know
how
to
do
this
or-
and
this
is
kind
of
my
experience
with,
for
example,
organizations
such
as
openjs
foundation
right,
there's
a
bunch
of
projects
under
under
that
foundations
that,
in
and
of
themselves,
have
like
different
vulnerability
disclosure
stories,
but
they
have
this
fallback
organization
that
will
help
if,
if
need
be-
and
this
is
also
something
that
I
see
is
happening
and
I'm
gonna
help
kick
start
some
of
that
in
in
the
node.js
community.
A
But
I
think
there's
still
like
a
lot
missing
in
terms
of
like
educating
open
source
open
source
maintainers,
how
to
you
know
how
to
publish
a
security
policy,
how
what
that
policy
should
contain
how
to
how
to
accept
vulnerability
reports?
How
to
you
know,
release
the
fixes
and
how
to
disclose
vulnerabilities
when
those
fixes
are
available,
how
to
do
coordinated
disclosure?
A
If,
if
that's
appropriate,
then
when
that
is
appropriate,
and
then
you
know,
if
you
have
a
fix,
you
have
a
vulnerability
like
do
you
just
put
it
out
there?
A
Do
you
publish
in
some
sort
of
machine,
readable
format,
so
sca
and
von
management
kind
of
vendors
can
pick
it
up
like
a
lot
of
those
things
I
think
is
fairly
nuanced
and
if
we
could
have
simple
actionable
resource
for
open
source
maintainers
to
read
and
adopt
the
practices,
I
think
I
think
that
would
move
the
needle
and
like
we,
that
would
be
progress,
because
in
in
this
working
group,
we've
had
a
tremendous
amount
of
information.
A
I
think
that's
mostly
living
in
our
meeting
meeting
notes
and
I
wanted
to
transfer
it
to
something:
that's
more
discoverable,
much
more
polished
and
therefore
much
more
useful
when
it
comes
to
like
coordination,
most
of
the
coordination
that
we're
doing
is
in
our
in
our
repo.
But
I,
since
this
is
a
project
in
and
of
itself,
it
looked
like.
I
have
enough
permissions
on
the
ossf
oregon
github
to
actually
go
and
create
a
project
which
I
did,
which
I
did
earlier
today.
A
It's
bare
bones:
there's
nothing
in
it,
not
a
single
issue,
not
a
single
pr,
it's
just
a
repo,
but
we
can
use
it
going
forward.
I
think,
to
to
disorganize
organize
ourselves.
We
can
also
use,
I
think,
github
projects
to
like
coordinate
our
own
work
in
in
developing
the
content
and
later
on,
probably
in
in
the
publication
process.
A
So
the
question
the
question
I
have
is
like
who's
interested
in
participating
because
I
think
there's
there
are
gonna,
be
a
few
opportunities
to
kind
of
contribute
and
collaborate.
I
think
the
like
the
primary
one
that
I'm
thinking
about
is
just
collaborating
on
the
content
and
putting
it
together,
but
there's
like
we
also
need
people
who
are
going
to
review
that
content
and
do
you
know
like
proofreading
and
later
on,
putting
it
into
a
format.
A
That's
gonna
be
suitable
for
publication
and
so
on
and
so
on.
So
I
expect
plenty
of
opportunity
for
everyone
to
kind
of
chime
in
and
and
do
some
work
around.
It.
G
I
I
Sorry,
as
I
say,
this
is
the
statement
you
know,
so
I
I'd
be
willing
to
to
help
and
contribute.
It
might
be
helpful
for
somebody
to
create
at
least
you
know
a
first
page,
especially
if
you're
not
going
to
use
google
docs
you're,
going
to
try
this
on
github
trying
to
start
with
an
empty
file
and
trying
to
merge
issues
on
an
empty
file
is
probably
not
a
winning
strategy,
so
you
might
want
to
either
start
with
google
docs
or
start
with
somebody
actually
having
something
to
to
to
edit.
I
I
Yeah,
I
think
that's
the
group
that
really
would
be
probably
most
receptive
for
here's,
a
short
doc.
It
tells
you
what
to
do
to
get
started
and
what
to
do
when
you
actually
receive
a
an
issue
and
I'll
note
that
for
the
ci
best
practices
badge,
the
main
thing
that
we
pressed
on
was
just
have
a
way
to
report
vulnerabilities
because
most
of
these
developers
don't
even
have
that.
There's
no
way
to
report
vulnerabilities
clearly
identified,
and
you
know
they
won't
even
do
that
because
they
don't
know
to
do
that.
A
Yeah
yeah
and
like
they
don't
like
people-
and
this
is
this-
was
like
an
interesting
experience
from
the
node.js
community.
Like
people,
don't
even
say
it's
like,
if
you
have
a
security
will
not
able
to
like
maybe
stay
away
from
the
public.
Backtracker
right
like
this
seems
like
a
no-brainer,
but
it
it
seems
to
be
something.
That's
that's
still
worth
reiterating
just
fyi.
I
J
I
D
I'm
still
pushing
on
github
to
try
to
get
them
to
be
able
to
make.
So
let
me
get
a
star.
I
have
a
couple
of
relationships
there,
I'm
still
putting
against
them
to
try
to
get
them
to
get
the
github
advisories
to
be
something
that
you
can
open
by
yourself
right
like
something
that
you
don't
need
to
have
an
admin
open,
but
you
can
open
it
as
a
security
researcher.
K
So,
just
to
echo
what
we
said
last
time
about
the
white
paper,
I
think
we
all
kind
of
decided
that
there's
definitely
multiple
different
opinions
about
you,
know
full
disclosure,
coordinated
disclosure,
etc,
etc,
and
that
when
we
write
the
white
paper
we
should
probably
just
say
you
have
options.
A
and
b.
A
G
I
wanted
to
say,
I'm
glad
to
participate
and
help
contribute
to
this
project.
Secondly,
I
think
this
is
an
opportunity
for
us
to.
We
have
a
couple
different
efforts
within
the
group
where
we've
talked
about
personas
and
pain
points,
and
I
think
that
can
help
inform
the
white
paper
itself
and
be
supplementary
resources,
and
then,
thirdly,
david
and
I
are
part
of
the
developer,
best
practices
working
group
within
the
open
ssf,
and
I
think
that
would
be
a
great
vehicle
once
this
group
decides
kind
of
what
we
want.
G
The
guidance
to
be
is
that
developer
best
practices
group
can
help
be
the
mouthpiece
and
vocalize.
This
is
a
good
practice.
We
feel
everyone
should
read
this
white
paper
and
you
know
consider
these
guidelines.
So
I
think
we've
got
a
lot
of
opportunity
here
to
get
some
cross-group
synergy
and
to
leverage
the
existing
materials.
We've
been
toiling
away
on
for
the
last
couple
months.
D
I
think
that
one
thing
that's
really
important
to
keep
in
mind
and
then
something
that
katie
masuris
when
I
chatted
with
her
pointed
out
to
me,
is
disclosure's
gonna
happen
right
it.
It's
not
gonna
necessarily
happen.
The
way
that
you
control
it
or
the
way
that
you
want
it
to
like
you
need
to
you
know
the
reality.
Is
you
kind
of
need
to
be
able
to
accept
it?
D
However,
it's
going
to
come
and,
like
you
know,
that's
really
hard,
culturally,
hopefully
for
some
organizations
and
so
like
whatever
suggestions
that
come
out
of
like
how
you
know
here
here
are
the
different.
Like
you
know,
disclosure
practices
that
you
can
you
want
to
enforce
on
your
project
like
the
reality
is,
I
think
that
needs
to
be
stated
up
front
is
like
you're
gonna
get
stuff
in
a
variety
of
different
ways.
You
need
to
be
okay
with
that
or
you
know
not,
but
you
you're
gonna
be
fighting
a
losing
battle.
G
And
I
think
it's
incumbent
upon
this
group,
when
we
write
this
white
paper
to
adopt
the
maintainer
developer
persona-
that's
who
we're
writing
for
not
for
a
persona
that
represents
our
corporations
or
groups
we're
from
we're
talking
about
open
source
developers.
These
are
some
options
and
recommendations.
We
have
for
everybody,
there's
a
lot
of
different
variability,
but
don't
try
to
instantiate
my
red
hat
policy
on
the
whole
community,
but
that
is
potentially
an
option.
Is
there
a.
I
I
actually
I
wouldn't
even
push
back,
I
don't
think
the
word
responsible
closure
disclosure
should
be
used.
It's
coordinated
disclosure,
even
microsoft,
which
coined
the
term,
has
recommended,
don't
call
it
response,
because
that
implies
that
that's
the
only
way
to
do
it.
I
actually
encourage
coordinated
disclosure
and
I
would
be
okay
with
the
doc
that
encouraged
coordinated
disclosure,
but
I
think
we
also
need
to
acknowledge
that
some
people
don't
like
that
and
I
think
a
little
thing
of
hey.
We
recommend
x,
if
you
don't
like
that,
then
here's
a
way
to
do
it
with.
I
L
Yeah,
I'm
just
observing
something
that
might
be
helpful
in
the
scoping,
I'm
hearing
on
the
conversation,
both
potential
for
white
paper
that
describe
resource
best
practices
and
the
like
for
operating
as
a
coordinator
when
you
are
an
open
source,
maintainer,
meaning
how
to
receive
vulnerabilities
from
others
and
how
to
coordinate
throughout
the
process,
it
will
probably
be
a
multi-party
process
as
part
of
that
coordination
function.
L
You
might
be
also
a
reporter
yourself,
especially
in
the
multi-party,
but
I'm
also
hearing
on
this
call
some
discussions
on
if
you
find
a
vulnerability
in
others,
other
people's
other
organizations,
sorry
code,
we
as
a
community,
the
open
source
community,
recommend
the
following
practices
as
a
reporter,
and
that
would
definitely
go
way
into
this.
L
The
the
much
harder
discussion
around
full
disclosure
and
the
likes,
I
think,
separating
these
two
elements
would
be
very
useful,
especially
when
it
comes
to
documenting
the
best
practices
and
that's
a
distinction
that
we
that
is
also
apparent
in
international
standards.
I
say
c29147.
K
L
One
of
the-
I
would
just
only
add
one
element
here:
one
of
the
biggest
at
least
items
we
are
seeing
from
an
open
source
discussion
on
the
policy
landscape
is
that
you
know
you
probably
have
noticed
this
as
well.
There.
There
are
emergent
regulations
now
seeking
to
require
organizations
to
have
that
point
of
contact.
It
really
is
apparent
in
iot
as
a
sector
and
embedded,
and
there
are
multiple
examples
within
industry
259,
which
is
now
becoming
the
backbone
of
that
cyber
security
movement
act.
It's
in
the
uk.
L
It's
really
it's
a
global
phenomena
and
the
question
is:
how
do
we
document
some
processes
for
open
source
maintainers
that
might
be
required
under
these
emerging
regulations?
Just
to
add
to
the
previous
point,
disclosure
is
going
to
happen,
but
now
you're.
Actually
you
know
there
are
specific
segments
in
that
specific
jurisdiction
that
are
going
to
require
you
to
at
least
have
that
external
facing
contact.
L
So
I
think
the
the
first
issue
of
combining
all
the
resource
on
assisting
the
community
with
best
practices
and
one
of
the
things
we
at
intel
might
try
to
do-
is
to
get
3113.
It's
a
you
know.
I
don't
know
if
you're
aware,
but
29147
and
our
tiers
on
the
call
was
made
available.
L
The
2014
version
was
made
available
because
of
many
efforts
of
art
and
others,
and
I
think
we
are
maybe
we
can
try
to
get
also
the
previous
version
of
31
on
one
available
as
well,
and
that
would
you
know
instead
of
paying
for
that
standard,
it
would
be
the
prior
version
of
it
would
be
widely
available.
I
think
that
will
really
progress
to
our
joint
understanding
of
best
practices.
D
The
one
thing
that
I
also
want
to
communicate
here
is
I've
run
into
a
lot
of
issues
around
disclosure,
a
security
researcher
running
into
problems
with
organizations.
So
one
of
the
things
that
exists
in
a
lot
of
the
bug,
bounty
programs
and
a
lot
of
hacker.
You
know
hacker
one
bug
crowd
all
those
ones.
D
Usually
participation
requires
accepting
the
organization's
disclosure
policy,
and
so
I
have
been
opting
to
avoid
hacker
one
and
blood
crowd
more
and
more
often,
and
trying
to
opt
for
email
or
forcing
the
organization
into
github
security
advisories,
because
I
don't
really
feel
comfortable
accepting
their
disclosure
policy
on
their.
You
know
like
basically
like
what
ends
up
happening
is
the
disclosure
policy
is,
if
you
you
know
like.
If
you
follow
all
these
rules,
including
our
disclosure
policy,
then
we
will
not
legally
pursue
you
right.
So
there's
elite,
there's
a
there's
a
basically
like
you're.
D
You
know
in
scope
for
our
disclosure
for
disclosing
a
vulnerability
for
us
without
it
being
like.
You
know
you
having
legal
proceedings,
go
after
you
as
long
as
you
conform
to
all
these
roles,
including
our
disclosure
policy,
and
that's
you
know
at
that
point.
I'm
just
like
you
know.
I
you
know
I
that
also
like
you
know
the
risk
of
dealing
with
bug,
crowd
and
like
potentially
getting
thrown
off
of
bug,
crowd
or
hacker
one
as
a
secured
researcher.
D
Because
of
you
know
your
need
to
hold
your
own
disclosure
policy
right,
use
your
own
disclosure
policy.
More
and
more
of
that
has
kind
of
led
me
to
kind
of
just
back
away
and
say
you
know
what
I'm
rather
use.
Email
I'd
rather
not
and-
and
then,
if
you
really
want
me
to
you,
have
to
up
front
agree
that
I
can
use
my
disclosure
policy
and
that
will
override
your
disclosure
policy
before
I'll
use
your
platform
to
disclose.
M
This
is
read
to
macro1,
jumping
in
here
we've.
This
has
come
up.
It's
a
very
small
number
of
cases
that
I
can
think
of
off
one
hand,
but
we're
always
happy
in
those
cases
to
work
with
the
researcher
and
work
with
the
organization
to
find
that
middle
ground
that
works
for
both
parties.
M
So
if
that
ever
is
the
case-
and
it's
speaking
for
hacker
one
here,
but
I'm
sure
background
can
do
the
same
thing
is
that
you
know
just
reach
out
to
to
support
and
we're
happy
to
help
coordinate.
That
I
mean
our
goal
is
basically
to
make
sure
that
vulnerability
gets
disclosed
and
gets
fixed.
M
L
So
ver,
I
would
just
add
very
quickly.
I
have
some
experience
with
that
language.
Some
of
you
on
the
call
might
know.
I
would
just
say
it.
The
one
of
the
things
that
we
can
document
or
we
can
consider,
including
in
the
white
paper
that
would
assist
with
some
of
these
issues,
is
just
distinguishing
distinction
between
the
bug,
bounty
and
a
mobility
disclosure
program,
which
is
a
very
big
basic
distinction.
L
But
when
it
comes
to
the
safe
harbor
issues
that
you're
just
mentioning
jonathan
academically
speaking,
that's
where
there
is
a
lot
that
news
comes
into
play.
So
actually
there
are
some
policy
documentations
that
recommend
to
have
both
right,
because
the
bug
bounty
in
terms
of
the
scope
of
the
surf
harbor
in
terms
of
the
language
would
necessarily
be
often
different
than
a
safe.
However,
you
would
include
in
a
vulnerability
disclosure
program
so.
D
Yeah
you
have
you
like:
they
only
have
a
bug
money
program
and
it's
private
right
and
so
like
all
of
their
bug,
money
program
and
you're
like
I
don't
want
to
disclose
to
your
bug
money
program.
That's
so
that,
like
a
lot
of
that,
I've
run
into
that
a
lot
of
a
lot
of
times
where
you
you
get
driven
towards
the
broadband
program,
which
has
this
fixed
policy
and
you're
like
I'm
willing
to
give
up
the
bounty
in
order
to
disclose
this
and
have
a
cbe
assigned
like.
A
Right,
that's
why
I
think
we
kind
of
need
to
nail
down
some
audience
for
this
white
paper,
because
I
think
a
lot
of
those
considerations
are
for
like
bigger
projects
that
have
were
just
sorry
to
be
blunt,
but
that
care,
I
I'm
not
sure,
like
how
nuanced
can
we
get
about
the
disclosure
policy
with
you
know
an
individual
developer,
that's
just
maintaining
their
own
project
right.
A
We
like
the
probably
like
what
we
want
to
do
is
enable
that
process
to
function
at
all
and
for
security
researchers
to
a
be
able
to
disclose
at
all
and
not
just
chase
individual
people
and
have
kind
of
have
witnessed.
My
fair
share
of
you
know:
security,
researchers
or
people
helping
them
in
kind
of
open
source,
bug,
bounty
programs
just
chase
people
and
try
to
find
maintainers
yeah,
but
all
all
of
this
is
kind
of
very,
very
relevant.
A
So
what
I
thought-
and
this
is
kind
of
to
get
back
to
david's
point-
is
we
should
probably
start
with
you
know
putting
together
some
sort
of
like
a
you,
know,
scope
or
table
of
contents
for
the
white
paper,
and
then
we
would
be
able
to
that
way.
We
would
be
able
to
nail
down
like
which
aspects
which
elements
of
the
whole
process
we
we
want
to
cover
right.
A
Does
that
sound
like
a
like
a
reasonable
next
step,
or
do
we
need
to
do
some
more
brainstorming
around
like
okay,
which
persona
in
using
the
lingo
we've
been
using
for
the
last
couple
of
meetings
which
persona
and
which
use
cases
do
we
want
to
address
by
publishing
the
the
white
paper.
K
I
mean,
I
think
we
pretty
much
had
nailed
it
down
last
time
as
it
was
going
to
be
a
maintainer
persona
and
who
was
at
the
bottom
of
the
maturity
scale
and
was
like.
Where
do
I
start,
and
I
mean
for
a
starting
point
for
our
group.
That
seems
like
a
really
good
goal
to
me
and
then
obviously
we
want
to
do
more
white
papers
later
that
build
on
the
different
personas
and
maturity
levels,
but
I
mean,
unless
other
people
think
there's
a
more
valuable
one
to
start
with.
N
I
you
know,
I
think,
if,
if
is
maybe
start
of
the
paper,
with
an
introduction
to
the
sort
of
the
personal
use
kits
or
the
like,
we
had
to
find
personalized.
This
introduces
the
maintainer
role.
I
can
also
help
build
sort
of
build
the
fundamentals
for
the
rest
of
the
papers
as
well
so
sort
of
define
the
purple,
not
necessarily
define
all
the
person
on
us,
but
maybe
introduce
them
in
some
way.
O
I
think
this
could
be
a
separate
documentation,
because
imagine
that
later
we
have
white
papers
for
different
personas.
Are
we
going
to
include
all
the
personas
there
too,
or
if
a
maintainer
goes
and
reads
this
white
paper?
Do
they
really
care
about
learning
all
the
different
personas
at
that
moment,
or
they
prefer
reading
through
it
and
finding
out
what
they
need
to
do.
N
I
don't
necessarily
think
we
need
to
include
all
of
them,
but
just
say
that
we
have
defined
sort
of
personas,
and
this
is
the
maintainer
persona
not
necessarily
going
to
deep
detail
about
all
of
them.
D
Is
there
a
goal
of
a
higher
level
sort
of
so?
Like
you
know,
for
example,
there
are
some
people
that
really
want
to
dive
into
licensing
right,
but
then
get
up
also
has
to
choose
a
license
kind
of
like
high
level.
Like
you
know,
here's
a
drop
down
here,
like
the
high
level,
like
ups
and
down
sides
of
this
particular
choice
that
you've
made
like
I
feel
like
there's
some
like,
especially
for
the
people
that
are
like
I
just
want
to
get
coding
or
something
like
that
like
there's
or
like.
D
I
don't
really
want
to
do
a
deep
dive
into
this
very
complicated
topic
right,
arguably,
like
can
you
give
me
like
a
high
level
like
what
decision
can
I
make
here
at
a
high
level,
understand
the
simple
implications
at
like
the
simplest
set,
and
I
can
like
make
that
decision
and
like
run
with
it.
I
Yeah,
I'm
fine,
for
example,
with
we
would
recommend
coordinated
disclosure,
not
everyone
agrees,
here's
some
literature
and
basically
for
at
least
the
first
version.
You
know
making
it
simple
as
possible
short
as
possible
and
if
there's
a
later
version
that
goes
with
more
options.
That's
great.
I
do
like
the
idea
of
you
know,
choose
your
own
adventure.
If
we've
got
the
time
to
do
it,
but.
A
Yeah,
I
also
think
like
like
learning
a
lesson
from
like
the
software
industry.
Like
scope
creep
is
real,
so
we
could
go
like
at
length
exploring
different.
You
know
fine
points
of
of
the
whole
process,
but
I
think
it's
like
nailing
down
a
use
case
in
doing
it.
Well
is,
is
probably
going
to
be
will
make
us
will
make
this
very
valuable
resource.
That
doesn't
mean
we.
A
We
need
to
ignore
like
more
advanced
in
more
advanced
issues,
because
I
think
there's
like
potentially,
we
could
think
of
like
other
types
of
content
that
we
could
publish.
That
will
allow
people
who
are
more
advanced
and
further
in
their
journey.
Like
explore
those
finer
points
and,
like,
frankly
speaking,
I
think
we
we've
had
a
lot
of
that
kind
of
content
captured
in
this
working
group
already
which
like
when
we
started
like.
A
I
think
I
I
heard
from
from
a
few
of
you
that,
like
you,
you
know,
everyone
comes
with
their
own
perspective
and,
being
here
and
exchanging
experiences
was
like
eye-opening
for
a
lot
of
people,
and
I
think
we
could
capture
that
and
publish
that
in
some
in
in
some
form,
and
actually
it's
like
this
is
something
I
also
said.
The
last
time
I
was
like
we
probably
didn't
have
enough
of
a
representation
from
the
security
research
community
so
like
it's.
A
I
actually
only
now
realized
that
kind
of
jonathan
gonna
maybe
will
help
us
close
that
gap
in
terms
of
like
the
composition
of
the
group
and
having
all
the
all
the
perspective
and
all
the
personas.
Can
I
hear
present
at
this
virtual
table
so
that
everyone
like
we
can
get
a
complete
and
fair,
fair
contribution
from
from
all
the
from
all
the
roles.
D
If
there's
anybody
that
knows
anybody
at
the
project
zero
day
or
security
lab
or
some
of
the
labs,
it
might
be
appreciated
to
like
reach
out.
If
you
have
any
contacts
there
and
say
hey
like
because
I
mean
I
can
I
can
I'm
happy
to
offer
my
insights
but,
like
you
know,
there's
other
people
that
have
been
doing
this
way
longer
than
I
have
so.
A
Yeah,
I
I
don't
know
anyone
at
google
project
zero,
but
I
definitely
have
contacts
at
the
github
security
lab
yeah.
That's
a
good
point.
G
I'll
reach
out
to
matt
linton
at
google
to
get
some
gpz
folks
at
least
cc'd.
D
Katie
masseurs
is
also
a
great
resource
for
her
time
is
not
free,
so
yeah
she's
she's,
very,
very
busy.
A
lot
of
different
things.
K
K
Katie
mazuris
camo,
she
has
very,
very
pink
hair.
You
would
recognize
her
okay.
J
G
And
specific
to
the
maintainer
finder
persona
interaction
crystal
and
I
sat
down
for
several
hours
and
kind
of
worked
through
the
pain
points
there,
which
is
again
it's
a
artifact
in
our
get
repo.
If
someone
wants
to
review
that
and
comment
and
collaborate
on
it,
we'd
be
great
to
kind
of
more
fully
develop
that
and
identify
you
know.
Maybe
we
need
to
have
more
finder
mate
personas.
We
need
to
have
an
academic
versus
a
professional
versus
a
community
person
if
that's
valuable,
but
we
started
catalog
that,
in
the
pain
points,
documents.
A
Right
would
it
make
sense,
because
we
still
haven't
done
it?
We
still
haven't
moved
content
from
google
docs
to
to
github.
Would
it
would
it
make
it
easier
to
do
this
work
if
it
was
on
github
in
one
place,
because
I
think
the
I
can
add
the
value
there
is
not
so
much
in
in
the
format
itself,
but
just
having
it
all
in
one
place.
G
A
Yeah,
because
what
I
did,
I
have
a
pr
open
here
that
uses
jason's
persona
briefs
like
it's
literally
stolen
or
copied
from
his
slides.
So
I
could
merge
that
source
yeah.
So
he
granted
us
a
permissive
license
to
use
those
furizonas
he
by
the
way
expressed
interest
in
contributing
to
this
white
paper,
which
is
great.
A
So
what
I
can
do
is
I
can
merge
this
pr
and
then
we
can
start
documenting
those
pain
points
as
independent
like
markdown
files
here,
which
would
be,
I
think,
a
step
in
a
good
direction,
and
here
in
this
disclosures
white
paper
reba.
What
I
can
do
is
I
can
create
an
issue
later
on
to
kind
of
kick
off
the
the
scoping
or
you
know,
coming
up
with
the
table
of
contents
and
people.
A
D
Out
of
curiosity,
so
you
know
I
mean
so
I
asked
katie
this
like
do
you?
Do
you
treat
somebody
who
does
bug
bounty
research
differently
than
you
know
like
from
from
her
perspective
like
right?
Do
you
treat
somebody
differently
from
a
bug,
bunny
researcher
differently
from,
like
you
know,
an
academic
or
security
researcher,
and
here
you
know
her
mindset
is
like
they're.
They
basically
operate
as
the
same
person.
I
I'm
I'm
I'm
confused
what
the
mentality
is
here
around
like
from
a
person
who's
receiving
a
report.
D
What
is
the
different,
like
you
know,
is
your
reaction
different
to
these
different
kinds
of
people
like?
Do
you
handle
the
vulnerability
differently?
What's
what's
the
so
you
know,
I
see
the
this
kind
of
is
like
a
useful,
like
you
know,
from
a
conceptual
standpoint
in
terms
of
like
maybe
this
group
capturing
this,
but
from
a
maintainer's
perspective
like
you
know,
there
is
an
end
goal
of
disclosure.
D
Hopefully,
in
any
of
these
and
like
you
know,
you
should
be
bountying
any
of
them
or
offering
you
know
if
you
have
a
bounty
right,
you
shouldn't
be
like
well,
this
person's
a
an
academic
researcher,
not
a
bug,
monty
hunter
like
we
don't
we
don't
find
it.
We
don't
dante.
Those,
like
you
know,
I
feel
like
they're.
The
treatment
on
the
maintainer
side
in
open
source
or
company
receiving
these
reports
is
generally
the
same
and
should
be
considered
the
same
or
not
not
quite
yeah,
jonathan.
H
J
Probably
not
probably
not
for
an
intro,
an
intro
document,
probably
not
at
all,
I
I
would
observe
that
developers
do
care
about
the
more
detailed
personas
because
it
helps
them
handle
the
reports,
but
not
in
an
intro
doc.
I
don't
think.
I
Yeah,
if
I
can
jump
in,
I
think
one
difference
is
some
people,
it's
way
more
important,
that
they
get
credit,
but
I
don't
think
for
this
intro
we
need
to
emphasize,
you
know
just
tell
maintainers
if
they,
unless
they
tell
you
otherwise
give
credit,
it's
not
fair.
Otherwise,
so
you
know
as
long
as
we
emphasize
the
give
credit
part,
I
don't
think
we
need
to
go
into
grand
detail.
B
A
Yeah,
so
so
like
this,
I
guess
we
don't
have
to
capture
everything
in
the
release.
We
can
like
maintain
them
online
like
an
faq,
we
can
evolve
that's
kind
of
the
companies
of
the
white
paper
or
you
know,
maintain
a
knowledge
base
or
like
publish
a
v2
in
of
the
white
paper
in
some
time.
So
I
get,
I
guess
what
I'm,
what
I'm
getting
at
is
it's
like
trying
to
be
perfect
and
cover
everything.
A
I
should
not
necessarily
stand
in
the
way
of
of
making
progress,
because
I
think
having
something
released
is
better
than
having
like
working
for
a
year
towards
like
a
perfect,
perfect
and
all-encompassing
resource.
J
J
D
I
let
me
see
if
I
can
find
this
real
fast
one
of
the
things.
So
this
is
a
slight
deviation
from
the
topic
of
of
persona.
Is
that
okay,
okay?
So
one
of
the
things
that
I've
run
into
as
an
issue?
Quite
a
bit
is
so
I
had
this
like
I've
been
dealing
with
this
issue
with
the
apache
foundation.
Vulnerability.
D
D
Disclosure
is
a
a
lack
of
respect,
one
way
or
the
other
right
like
that,
that
that
dynamic
in
that
relationship
that
plays
out
between
the
researcher
or
the
voter,
the
person
reporting
the
vulnerability
and
the
person
and
and
and
the
people
receiving
the
report
because-
and
I
think
that,
like
fundamentally
one
of
the
like
the
the
things
that
is
is
is
is
important
to
understand,
is
for
a
security
researcher.
D
The
easiest
thing
for
them
to
do
is
drop
an
o
day
on
twitter
and
then
hand
it
to
like
you
know,
snick
sack
or
you
know,
white,
all
these
other
organizations.
That
say
here:
please
do
disclosure
for
me
right.
Here's,
the
here's,
the
information,
it's
public
right,
but
there's
a
there's,
a
certain
level
of
respect
that
the
person
who's,
disclosing
the
vulnerability
privately
is
is
providing
you
know
providing
to
both
the
users
and
the
maintainers
right
and
and
but
you
know,
one
of
the
things
that
that
that
falls
apart.
D
A
lot
of
the
cases
is
the
maintainer
is
not
responding
to
the
reporter,
like
they're
they're
internally
having
the
discussion,
but
they
don't
like
respond
to
the
reporter
or
they
don't
interact
with
the
reporter
or
like
they
don't
give
the
updates
the
reporter,
and
so
what
the
reporter
is
fielding
feeling,
like
is
hey,
like
I
put
all
in
all
this
extra
work
to
disclose
to
you
privately
try
to
facilitate
disclosure
right.
Do
this,
like
you
know,
go
the
long
way
around
to
you
know
it's
more
work
for
me
and
I
don't
you
the
re.
D
The
reporter
doesn't
feel
respected
by
the
maintainers,
because
there's
no
communication
about
the
vulnerability.
There's
no
discussion,
there's
no
like
hey
we're
up
or
like
even
like
hey
like
you
know.
Three
of
us
are
sick
and
can't
deal
with
this
right
now
like
we
will
get
back
to
you
next
week,
right
like
even
the
simple
stuff,
and
so
I
think
that
is
part
of
this
white
paper.
D
Conveying
that,
like
you
know,
treating
the
person
like
a
human
and
also
like
the
reporter,
like
a
human
and
also
like
you
know
communicating
like
updates
of
like
you
know,
life
has
gotten
in
our
ways
like
people
can
be
understanding,
but
if
you
just
like
you
know,
don't
communicate
for
a
month
two
months
people
get
upset
and
then
they
look
at
their
email.
They're
like
this
was
dealt
with
three
months
ago.
I'm
not
like
I'm
just
gonna
drop
this
as
a
no
day,
because
it's
easier
right.
D
So
I
think
that
that
component
of
like
I
I
don't
know
if
there's
a
better
word
but
respect
is
the
best.
You
know
kind
of
way
of
communicating
that
that
need
of
that
back
and
forth.
In
order
for
these
relationships
to
be
successful,.
K
I
think
if
you
could
take
a
look
at
the
reporter
persona,
we
did
cover
that
as
a
pain
point
where
the
lack
of
just
being
updated
and
kept
in
the
loop.
We
definitely
pointed
out
as
a
problem,
so
it
would
be
really
valuable
if
you
could
give
that
a
look
for
sure.
A
Yeah,
but
I
I
I
think
we
kind
of
recognize
that
the
problem
is
real
and
I
think
I
personally
would
love
to
see
that
covered
in
the
white
paper,
because,
like
sometimes
the
developers
may
treat
this
those
reports
as
sort
of
noise,
especially
when
the
impact
of
the
report
well,
the
reported
vulnerabilities,
maybe
not
immediately
kind
of
obvious
to
someone
who's,
not
a
security
expert.
A
So
I
think,
like
fostering
that
that
collaborative
nature
of
disclosure,
I
think
would
be,
would
be
quite
important
because,
like
oftentimes
like
maintainers,
are
not
security
experts,
so
they
might
not
immediately
recognize
like
what
what
the
impact
is.
So
I
think
it's
like
kind
of
building
that
mutual
patience
and
collaboration
is
yeah.
That's
super
important.
H
I
think
one
of
the
really
basic
things
that
people
could
do
that
we
suggested,
including
was
just
adding
a
holding
statement
like
just
respond.
You
know
a
lot
of
people
want
to
respond
after
they
have
all
the
information
and
they
they're
kind
of
waiting
to
do
that,
and
they
don't
realize
that
it's
more
effective
just
to
respond
and
say
hey,
I'm
going
to
be
able
to
look
at
this
in
two
weeks
like
or
whatever
your
time
frame
is
just
being
upfront
about
that
and
more
responding
quickly.
D
D
A
A
Just
just
you
know
just
a
hunch,
though
yeah,
but
I
would
definitely
like
to
see
a
section
in
the
white
paper
that
covers
like
what
happens
in
the
period
where
the
vulnerability
is
actually
being
fixed
right
because,
like
we,
we
talk
a
lot
a
lot
about
reporting.
A
We
talk
a
lot
about
disclosure
after
the
fix
is
available,
the
release
is
out
there
and
then
what
do
we
do
and
we're
even
debating
the
sequence
of
those
events
is,
is
something
that
causes
like
heated
debates,
but
what
happens
in
potentially
quite
a
long
period
of
time
where
someone
is
actually
working
on
the
vulnerability,
and
you
know
getting
researcher
involved
and
maybe
testing
some
of
the
fixes
and
stuff
like
that.
I
think
that's
that's
quite
important
for
us
to
address.
I
Yeah,
I
think
in
many
cases
it's
it's
a
process
of
gradual
understanding.
Frankly,
for
both
sides
I
mean
the
the
initial,
the
initial
thought
of
the
developers.
Oh
I'll
just
do
x
and
no
that's
actually
that's
a
symptom.
It's
not
the
underlying
problem,
whereas
the
reporter
may
not
understand
the
broader
context
that
the
developer's
working
in
so
I
I
agree,
you
know
encouraging
some
sort
of
dialogue
so
that
it,
you
know,
there's
a
working
fix
that
works
within
both
the
application
and
truly
fixes
the
problem.
D
I
think
security
devices
are
github.
Security
advisors
are
great
for
this,
because
not
only
do
they
you,
you
get
the
communication
back
and
forth,
but
there's
also
like
an
act
because
the
the
the
private
like
fix
is
encoded.
Like
you
know,
the
the
the
the
pull
request
of
like
the
fix
is
encoded
in
that
process.
D
The
researcher
also
gets
a
visibility
into
like
the
actual
fix
process
and
like
the
communication,
any
pull
request,
like
you
know,
reviews
that
are
going
on,
like
all
of
the
discussion
that
goes
on
around
that
it
all
becomes
like
you
know,
you
feel
involved
and
like
it's
important
right,
yeah.
G
We
also
need
to
be
aware:
our
recommendations
need
to
be
tool
agnostic
if
we
have,
if
a
particular
vendor
or
project
has
a
great
process.
We
can
refer
to
that
hey
for
an
example,
look
at
the
github
activities,
but
we
represent
a
larger
scope
and
we
need
to
remain
agnostic
and
neutral
in
that
regard.
I
D
I
think
that
the
two
other
things
that
have
broken
down
here
around
disclosures
that
I've
run
into
are
one
that
I'm
trying
to
with
google,
where
they
didn't
run
the
cve
disclosure
body
by
me,
and
it
ended
up
being
completely
wrong.
So
they
published
a
cve
that
completely
missed
the
mark
on
in
terms
of
actually
accurately
describing
the
vulnerability
and
the
way
that
you
mitigated
it
and
the
other
one
that
I've
seen
is
not
involving
the
like,
not
pointing
this
care
researcher
at
the
commits
that
actually
fix
it
to
like.
G
D
Yeah,
I
think
the
other
thing
that's
important,
and
this
is
like
very
weird,
because
I
just
communicated
like
you
want
to
do
that.
The
other
part
of
it
is
that
their
their
needs
like
it's
weird,
because
there's
also
no
expectation
of
that
happening
too
right.
It's
like
here
here
it
is
you
want
it,
but
like
we,
you
know,
because
it's
open
source
right
you,
you
can't
rely
upon
those
things
happening
as
a
you
know,
because
the
researcher
has
given
you
something
you
know.
D
Unfortunately,
it's
dropped
a
vulnerability
in
your
lap,
right
and
and
so
great
if
they
want
to
collaborate
awesome
if
they
just
drop
the
ball
on
you,
you
know:
how
do
you
deal
with
that.
G
Well,
I
care
about
the
maintainers
in
this
group.
It's
great
that
there
are
researchers
and
they
have
concerns.
The
point
of
this
foundation
is
to
support
open
source
development.
So
I
would
like
to
recommend
to
developers
it's
a
great
practice
if
you
collaborate
on
the
final
fix
now,
if
we
want
to
again
spin
off
something
focused
on
researchers
like
if
you
work,
if
you're
collaborating
with
a
bad
maintainer,
here's
some
things
you
can
try
or
some
recourse.
That's
like
that's
great.
G
I
don't
know
that's
that
should
be
the
tight
focus
of
us
thinking
about
these
external
personas.
I
want
to
focus
on
the
developer
maintainer
because
that's
the
advice,
that's
who
I
have
control
over.
That's
the
community
I
live
in
and
I
want
to
help
them
be
successful
and
if
a
vendor
or
a
researcher
bug
bounty
person
gets
benefit
out
of
that
and
can
elaborate
great.
But
I
care
about
the
developer.
I
Group,
I
do
think
it's
important
to
note
that
if
a
researcher
you
know
talks
with
a
maintainer
and
a
maintainer
won't
do
anything
after
a
period
of
time.
I
think
it's
fair
for
both
the
researcher
and
the
developer
to
understand
that
the
next
step
is
public
disclosure
and
the
end,
and
you
know
so
I
I
think
that
can
help
both
parties
and
the
users
frankly,
as
well.
A
Right
so
so
the
next
step
is,
I
think
I
will
create
that
issue
in
the
white
paper
repo.
A
So
we
could
continue
the
discussion
about
the
scope
because,
like
before
we
go
into
into
actual
content
development,
I
think
it's
kind
of
necessary
for
us
to
agree
on
the
scope
and
I
think,
as
a
part
of
that
process,
we're
gonna
identify
a
bunch
of
things
that
we
think
are
important,
but
the
white
paper
is
not
the
right
place
for
them
and
I
would
like
to
see
those
things
like
documented
somewhere,
like
that,
the
things
that
we
explicitly
left
out
of
scope
so
later
on,
we
could
like,
after
the
white
paper
has
been
published.
A
We
can
get
back
to
them
and
see
what
what
we
can
do
with
them.
Yeah
backlog
is
the
bright
technical
term
for
that
alrighty.
So
I'm
gonna.