►
From YouTube: OpenSSF TAC Meeting (May 3, 2022)
C
C
B
D
B
E
B
B
G
G
H
B
B
As
usual.
This
falls
under
the
linux
foundation.
Antitrusts,
I
don't
have
a
slide
for
it,
but
you
all
know
what
I
mean
it's
up
on
the
website
and
the
agenda
is
linked
here
again
in
the
chat
for
folks
who
are
just
joining.
Feel
free
to
add
yourself,
add
comments.
We
sort
of
drury
is
our
note
taker
for
the
day,
but
we
often
end
up
having
a
little
like
a
side
dialogue
happening
either
in
the
zoom
chat
or
in
the
doc,
and
that's
totally
welcome.
B
E
Yes
and
on
my
phone
on
me,
but
I
would
have
the
countdown
timer
for
it,
so
it's
it's
gonna,
be
here
before
we
know
it
would
love
to
see
everyone
there.
This
is
a
add-on
event
to
the
open
source
summit.
North
america
and
I
did
do
some
investigation
into
what
the
virtual
experience
would
be
like
it's
going
to
be
the
exact
same
as
ossna.
E
So
as
you
go
to
register
for
open
source
summit,
north
america,
you
can
choose
to
register
either
for
an
in-person
ticket
or
a
virtual
ticket,
and
as
a
reminder,
if
your
company
is
a
member
of
the
linux
foundation
at
the
silver
level
or
above
you
can
get
a
discount
on
that
ticket.
So
you
can
reach
out
to
me
or
someone
on
the
events
team
to
hook
you
up
with
that
discount.
E
The
events
platform
for
virtual
is
going
to
be
excel
events,
and
you
will
receive
an
email
that
kind
of
describes
what
that
that
experience
will
be
like
for
you,
but
the
open
ssf
day.
Events
will
be
on
that
platform
as
well.
So
when
you
sign
up,
you
can
choose
to
add
openss
update
is
one
of
your
add-on
options
and
join
us
virtually
if
you
are
not
able
or
interested
in
joining
us
in
in
texas
in
person.
E
We
are
hopefully
going
to
finalize
and
put
up
the
schedule
this
week
we're
all
here.
Staff
are
at
in
scottsdale
at
an
all
hands
meeting
for
lf
employees,
so
we're
we're
gonna,
try
and
mark
miller
and
some
of
the
events
team,
and
I
are
going
to
try
and
find
some
time
to
to
do
that.
But
we've
got,
I
think,
a
really
great
set
of
speakers.
Many
of
you
we'll
be
we'll,
be
there
speaking,
so
very
grateful
for
everyone's
support
and
quick
response.
E
B
B
B
H
H
Maybe
it
might
be
useful
to
try
to
write
down
what
people
generally
are
actually
doing,
which
is
at
least
at
this
point
has
been
more
of
a.
If
you
showed
up
for
more
than
x
meetings,
then
you
can
you
can
vote,
I
mean
it
doesn't
have
to
be
that
process,
but
you
know
something
so
that
they
don't
have.
Everybody
doesn't
have
to
recreate,
but
I
mean
that's
up.
The
script
got
chrome.
G
C
And
so
I'm
trying
to
make
sure
he
doesn't
beat
up
the
other
cat
so
yeah
anyway.
Yes,
so
jason
from
ibm
jason
k.
He
and
I
were
working
on
a
first
draft
of
the
charter
for
the
vulnerability
disclosures
working
group
and
had
far
far
far
more
questions
and
answers.
I
believe
I
may
have
linked
to
that
in
the
tac
issue
for
getting
charters
for
everything,
and
while
we
have
a
lot
of
questions,
I
think
they
shouldn't
be
answered
by
individual
working
groups.
C
Frankly,
individual
working
groups
should
be
setting
out
their
charter
or
not
their
charter,
their
scope,
their
mission,
their
leadership
and
maybe
their
membership,
but
frankly
determining
that
membership
and
every
other
governance
thing
ought
to
be
determined
by
the
tech.
Here
is
how
we
do
working
groups,
here's
the
governance
for
working
groups
and
then
all
working
groups
essentially
inherit
that
and
then
they
add
on
their
own
special
sauce,
which
is
going
to
be
their
mission,
their
scope.
Things
like
that.
C
So
I
think
that's
actually
what
should
be
done
and
instead
of
having
all
of
the
working
groups
going
their
own
direction
because
to
start
for
the
vulnerability
disclosures
working
group,
I
went,
and
I
grabbed
the
charter
that
they
were
working
on
for
the
best
practices
work
group
because
hey
it's
the
krogfest
right.
But
if
nothing
else,
I
figured
that
would
give
us
some
sort
of
basis.
That
was
the
same,
but
we
ended
up
having
to
change
so
many
things
because
best
practices
hadn't
gotten
around
to
doing
some
of
the
edits.
C
Yet
either
no
no
honey.
Stop
it's
not
like
you're,
not
doing
anything
else,
and
I
really
think
we
ought
to
be
just
doing
this
all
in
one
spot.
If
we
could-
and
I
know
that
the
tack
is
very
busy
with
other
stuff,
but
we
really
have
to
set
the
foundation
now
for
the
rest
of
open
ssf
and
I'm
happy
to
help
with
that,
because
I've
already
taken
a
pretty
good
stab
at
it
jason
and
I
have
and
see
where
we
can
go
so.
B
What
you've,
what
I
was
hoping
to
get
out
from
that
the
work
that
the
two
or
three
or
more
of
you
have
been
doing
is
exactly
this
kind
of
feedback,
a
better
sense
of
what
things
the
working
groups
and
projects
have
in
common,
what
they
have
documented
so
far
and
what
should
be
decided
collectively,
sort
of
at
the
tax
level
to
normalize
across
projects
and
working
groups.
It
sounds
like
you
have
a
better
sense
of
that
now.
C
F
Up
now
is
my
line.
Yes,
very
briefly,
with
securing
software
repos,
we
got
the
charter
we
adopted
it.
We
made
a
small
edit.
There
was
a
confusing
snippet,
but
otherwise
more
or
less
as
it
came
in
the
can,
because
that
was
a
hard
requirement
to
become
a
working
group
in
the
first
place,
so
we
were
highly
motivated
to
get
it
across
the
line.
My
general
feedback
has
been
what
is
in
the
document
doesn't
resemble
the
day-to-day
operations
of
any
working
group
that
I
participate
in.
C
I
agree
to
that,
but
I
think
that's
the
sort
of
process
and
mechanism
that
the
tax
should
define
and
the
working
groups
use
and
then,
if
they
can't
reach
some
sort
of
consensus,
then,
and
only
then
should
it
be
bumped
to
the
attack.
But
I
from
what
I've
seen
in
the
working
groups,
it's
unlikely
that
things
are
going
to
get
to
that
stage.
B
B
What
is
either
needs
to
be
clarified
or
just
whole
cloth
added
or
removed,
but
you
know
what's
the
diff
and
then
bring
that
back
to
the
tack
as
a
set
of
recommended
changes
with
enough
notice
that
we
can
invite
several
of
the
other
working
group
chairs
to
come
to
that
discussion
specifically
say
hey
from
your
working
groups
perspective.
Will
these
changes
be
good
for
you?
Will
they
help?
You
know,
remove
the
paperwork
problem
that
is
not
fun
for
you
to
solve.
C
B
J
J
What's
being
done
and
and
we
you
know,
if
you
start
from
scratch,
you
have
to
reinvent
the
wheel
everybody's
like
oh,
why
do
you
have
to
do
this
again
and
I'm
the
first
one
to
say
that
and
and
it's
a
bit
like
with
the
rest
right
for
the
attack,
we
we
had
looked
into
inheriting
the
cncf
process
and
then
we're
like
oh
wow.
This
is
so
blown
out
for
us.
J
We
are
not
there
yet,
and
so
you
have
to
try
to
find
a
middle
ground
between
those
two
extremes
where
you
don't
want
to
start
from
scratch,
but
you
don't
want
to
inherit
something.
That's
so
big
and
heavyweight
that
doesn't
fit
and
seems
completely
out
of
line
with
what
we
are
doing.
One
aspect
there
is
an
issue
that
still
needs
to
be
really
settled
on
is
where
they're
working
groups
are
steering
committees.
I
know
there's
been
discussions
about
this
and
some
of
us
have
said
that
seems
to
be
definitely
heavy
weight.
J
I
know
of
one
working
group
that
does
have
a
steering
committee,
which
is
the
salsa
working
group.
They
actually
have
listed
it
on
the
on
their
website.
If
you
go,
salsa.dev
you'll
see
it
and
it
was
you
know,
but
but
there's
no
rule
about
how
you
know
what's
the
term
how
they
get
elected.
Of
course
they
started,
which
is
normal.
J
They
started
with
a
bunch
of
people,
were
there
to
get
things
started,
but
you
know
you
would
need
some
process
to
define
how
this
is
going
to
evolve,
moving
forward
right,
who
gets
to
be
nominated,
how
you
get
elected
and
also,
and
so
on.
None
of
this
exists
today
and
it's
not
clear
to
me
that
we
really
need
this
during
committee.
The
only
thing
that
I
know
they
do
is
they
have
some
internal
discussion,
although
I
don't
know
exactly
what
they
do.
J
Maybe
I
shouldn't
speak
about
this,
but
I
know
that
for
the
blog
post,
for
instance,
they
had
some
internal
discussion
among
the
steering
committee,
whether
it's
okay
or
not.
So
they
have
some
function
whether
this
needs
to
be
carried
on
or
it
could
be
open
to
the
group.
It's
not
clear
to
me,
but
so
there
are
a
few
issues
like
this
that
definitely
need
to
be
settled
on.
Otherwise
I
agree
with
what
vikki
was
saying.
I
think
working
groups.
J
J
So
the
more
we
can
kind
of
you
know,
standardize
things,
and
maybe
it
doesn't
have
to
be
prescriptive
and
be
like
this
is
your
charter?
That's
how
it
looks
like,
but
it's
like
hey.
If
you
don't
know
what
to
do
start
from
there,
and
maybe
you
can
have
some
deviation,
but
at
least
you
have
a
starting
point
which
I
think
has
to
be
fairly
small
answer
basic
questions
and
not
go
too
far,
and
what
I
have
advised
some
of
the
working
groups
I
attended
when
they
started
discussing.
B
Thank
you
or
not.
I
think
it's
important
to
have
some
degree
of
consistency
between
things
that
are
organizationally
the
same
type
of
thing
same
item,
so
any
working
group
should
have
some
common
norms
as
folks,
you
know
in
any
foundation
move
between
them.
Those
norms
are
really
helpful
to
know
what
you're
stepping
into
the
different
projects,
but
also
with
some
flexibility.
B
You
do
that,
thank
you
and
that's
a
nice
segue
to
the
rest
of
the
agenda
of
this
agenda
item
the
work
that
the
tax
started
now
several
meetings
back
on,
updating
our
terms
and
trying
to
actually
map
out
the
organizational
structure
of
the
openssf.
So
I
dropped
a
link
in
here
as
a
reminder
for
folks.
What
we
had
agreed
on
in
a
past
tac
meeting
was
to
work
in
a
branch
of
the
repository,
so
we
could
land
things
move
more
quickly
and
have
something
concrete.
B
There
are
still
several
patches
open
on
that
branch
which
we
had
wanted
to
discuss.
We
didn't
we
discussed
in
the
last
meeting
but
did
not
reach
a
resolution
or
I
didn't
feel
like
we
had
consensus
between
prs,
95
and
96.
We
had
an
email
discussion.
It
felt
close
to
a
consensus
there,
so
I
wanted
to
bring
that
back
up
and
see
if,
in
the
intervening
time,
folks
have
made
a
a
a
decision
or
have
a
clear
sense
on
p95
at
this
point
and
the
terminology
used
in
pr-95.
J
J
I
mean
so
actually
so
pr
95
tries
to
to
expand
from
the
structure
we
have
today,
where
we
have
working
groups
but
tries
to
segregate
the
term
project
mostly
from
working
groups
and
saying
projects
are
really
going
to
be
reserved
for
activities
that
are
focused
on
developing
software
and
and
and
so
then
there
are
other
activities
like
you
know.
The
one
that
I
keep
referring
to
is
the
great
mfa
distribution
project,
which
clearly
was
not
developing
software.
J
We're
distributing
tokens
to
you
know
key
maintainers,
and
so
this
in
this
in
this
proposal
would
be
renamed
sieg
right,
special
interest
groups,
and
there
are
so
there's
there
are
still
questions
about.
You
know
governance
as
to
whether
what's
happening
within
a
working
group,
you
know
like
ziggs
and
projects
are
under
the
governance
of
the
tag
or
the
work
parent
working
group,
but
that
can
be
decided.
You
know
as
a
different
issue.
J
I
am
all
for
consistency,
and
I
am
one
of
the
people
I
think
like
ava
and
others
who
actually
live
in
different
organizations
with
the
linux
foundation,
and
so
it's
kind
of
convenient
if
it
could
be
more.
You
know
in
line
with
everybody
else,
but
when
I
looked
at
the
detail
personally,
I
think
it's
it's
quite.
The
cost
is
really
high
because
we
even
have
like
the
repositories
names
you
know
of
wg
at
the
end,
and
it
means
you
change
this
and
all
the
clones
and
everything
is
broken.
J
It's
it's,
I'm
really
not
in
favor
of
that.
So
I
think
I
did
put.
I
think
it's
pr
98
now
which
shows
this,
what
it
would
look
like,
but
I'm
not
in
favor
of
it.
I
think
pr
95
is
the
way
to
go.
It's
the
most
in
you
know
less
disruption
from
what
we
have
today.
It
does
achieve
the
goal
of
clarifying
and,
and
just
so
people
understand.
The
key
aspect
of:
why
are
we
trying
to
separate
software?
B
They
look
at
the
project
progression,
something
as
sandbox
stage
incubating
stage
graduated
stage
for
a
software
focused
project
that
people
can
download
and
use
and
maybe
turn
into
a
product
that
has
semantic
value
to
the
consumers,
and
it
is
important
we
preserve
that,
at
least
in
some
way
that
we
make
clear
here
and
that
doesn't
have
any
mapping
to
non-software-focused
projects,
which
is
why
I've
been
advocating
for
using
a
different
term
for
those
and
that's
the
norm
across
other
linux
foundation.
Projects
as
a
whole.
J
J
It's
like
this
is
really
a
pain.
I
don't
know
that
anybody
would
like
living
in
that
world,
so
I
just
decided
okay,
that
has
no
future,
I'm
going
to
close
it,
but
I
think
the
one
thing
because
I
don't
think
dan
laurenk
is
on
the
call.
Is
he
because
he,
if
there
is
any
voice
kind
of
against
the
current
proposal,
it's
then
who
has
been
saying
we
should
so
so,
in
all
fairness,
I
just
want
to
express
his
opinion.
J
He
is
keep
saying
that
he
only
wants
us
to
define
the
top
level,
so
we
define
basically
the
working
groups.
It
doesn't
want
us
to
go
beyond
that,
so
we
don't
formally
define
what
a
sig
is.
We
don't
deal
with
their
project
life
cycle.
This
is
all
left
to
the
working
group.
If
you
will
which
handles
these
things.
As
you
know,
the.
B
Way
it
wants
and
having
seen
this
play
out
in
four
other
foundations
in
the
past
10
years.
My
concern
with
that
approach
is:
it
will
confuse
consumers
if
different
working
groups
have
different
norms
for
the
same
terminology.
People
cannot
look
at
the
open
ssf
as
a
consistent
body
and
trust
will
be
output.
B
It
and
thank
you
for
raising
it
for
clarity,
so
I'm
going
to
try
something
since
we
we
do
have
quorum.
There
are
five
tac
members
on
the
call,
I
believe,
that's
quorum.
Let's
try
and
take
a
vote
any
anyone
opposed
to
merging
pr95
and
adopting
these
these
terms,
as
described
here.
If
you're
opposed.
Please
speak
up.
B
B
C
C
B
Vicki
cool,
I
think
that
is
almost
the
end
of
that.
The
last
one.
If
folks
want
to
look
at
it,
I
had
dropped
a
link
in
here
to
a
a
sort
of
mermaid
chart
that
shows
what
the
organizational
structure
might
look
like.
It's
not
complete,
but
it's
a
visualization
of
if
we
merge
95
what
those
terms
look
like,
as
we
start
to
map
out
the
the
relationships.
B
B
L
Oh
yeah-
I
am
here
yes,
yeah
thanks,
so
I'm
coming
from
the
best
security
working
group,
so
we
have
a
draft
for
security,
best
practices
for
the
npm
ecosystem
and
we
just
have
a
draft
and
we
want
to
put
it
in
an
rfc
mode,
so
people
can
comment
and
voice
their.
You
know
their
feedback
and
everything
and
I'm
looking
for
a
way
to
advertise
this
rfc
period,
and
I
don't
know
what
the
best
way
to
do.
L
E
I'm
I'm
not
from
the
npm
ecosystem
per
sailor,
but
the
openjs
foundation
has
a
couple
of
groups
that
work
a
lot
with
the
mtm
team.
We
actually
have
a
slack
channel
in
our
community
for
npm,
community
development
and
feedback
and
stuff.
I
would
think
that
that
would
be
a
great
place
to
advertise,
in
addition
to
open
ssf
forums.
Of
course,.
B
I
would
also
suggest
reaching
out
to
some
of
the
npm
leads,
who
have
occasionally
joined
these
meetings.
I
know
they're
in
they
do
make
it
some
of
the
working
groups,
so
you
might
also
advertise
in
several
of
the
working
groups
and
ask
folks
there
yeah,
like
justin,
hutchins,
exactly
ask
folks
there
to
then
rebroadcast
that
that
call
into
other
lists,
I
think
making
making
the
invitation
to
share
explicit,
helps.
E
K
Yes,
so
just
wanted
to
brainstorm
with
this
group
on
how
we
can
like
involve
more
academia
or
academic
research
to
these
like
open,
ssf
like
right
now,
if
you
think
about
it
like
there,
isn't
any
involvement
so
just
wanted
to
brainstorm
with
the
group
on
what
could
be
a
process
around
it
like.
Should
it
be
individual
working
groups
bring
in
like
put
in
some
research
ideas
and
then
we
reach
out
or
should
we
have,
let's
say
a
proper
working
group
for
this
kind
of
research
just
wanted
to
brainstorm
with
the
group.
B
B
G
G
E
I
was
going
to
add
that
I
think
you
know
as
crow
points
out.
We
certainly
do
have
participants
from
academic
institutions
in
our
groups,
but
we
don't
have
that
documented,
very
well
like
how
those
folks
can
engage
with
us
and
and
maybe
a
low-hanging
fruit
step.
One
would
be
some
kind
of
documentation
for
the
research
participant,
the
academic
and
participant.
You
know
what
are
some
good
ways
to
get
involved
with
our
working
groups.
G
Just
real
quick,
I
mean
we.
I
think
it
would
be
interesting
to
offer
that
as
a
service,
that
we
have
connections
to
a
lot
of
communities.
So
if
an
academic
was
interested
in
doing
research
on
a
particular
topic,
we
could
help
facilitate
connections
pretty
easily
through
our
professional
and
foundational
connections.
K
B
H
Yeah
real
quick
in
my
copious
free
time.
I
actually
do
a
little
work
with
in
you
know,
teaching
at
a
university.
If
you
don't
mind,
I'm
gonna
go
reach
out
to
frank
nagle
at
harvard
and
all
of
research
and
see
if
they
have
some
ideas
on
this,
you
know
at
least
you
know
and
report
back
whatever
I
find
love
it.
Thank
you.
B
C
I
love
the
idea
of
some
guidelines
for
for
researchers,
kind
of
a
start
here,
sort
of
thing
to
just
make
everything
easier
for
them,
but
maybe
consider
having
a
slack
channel
where
some
various
members
of
the
community
hang
out
and
can
at
least
provide
pointers.
So
I
know
users
dash
academics
or
something
like
that
user
status
research.
But
that
means
something
else.
So
let's
not
go
there,
but
I
think
that
could
be
helpful.
C
B
I
see
we
have
two
agenda
items
jeff
thanks
for
adding
one,
that's
interesting.
I
haven't
seen
that
yet
and
cedendra.
I
know
you'd
like
to
discuss
the
the
persia
discussion.
I'm
happy
to
hold
some
time
for
that
to
give
it
about
10
minutes
right
now.
My
concern
to
be
up
front
is
with
all
the
work
that
we
were
just
talking
about.
You
know
the
changing
terminologies
pr
95,
I'm
not
sure
we're
going
to
have
a
framework
in
place
or
I
don't
feel
like.
B
I
I
So
I
was
going
to
take
this
opportunity
to
answer
some
of
those
questions
and
and
just
again
raise
the
raise
the
question
about
how
can
persia
be
part
of
open
sf,
and
I
understand
that
some
of
the
finer
details
need
to
be
ironed
out,
but
I
think
I
mean
from
where
I
see
we
have
what
what
we
need
for
perseusic,
and
so
I
think
it
might.
It
might
make
sense
to
talk
about
it.
B
I
D
So
get
involved
while
ball
signature
is
getting
set
up
just
a
couple
things
I
want
to
highlight
so.
First
of
all
I
want
to.
I
want
to
welcome
some
of
the
folks
who
who
are
interested
in
the
perseo
project
and
join
us
for
the
call,
so
we
have
chris
benson
and
eric
sedler
from
oracle
who
joined
the
tac,
call
and
they're
they're
interested
in
collaborating
on
the
the
persia
project.
D
So
thank
you
both
for
joining.
We.
We
published
the
full
presentation
from
last
week,
so
just
at
a
high
level,
what
we're
proposing
is
building
a
binary
distribution
network
to
solve,
specifically
the
problems
of
how
we
can
do
peer-to-peer
distribution
of
secure
libraries
and
also
how
we
can
do
multi-node
verification
of
source
builds
to
improve
the
security
of
open
source
libraries
that
are
being
used
as
dependencies
up
the
chain
for
for
large
corporations
and
what
we
wanted
to
a
couple.
D
One
thing
is,
I
think,
as
a
as
a
project,
we
highly
value
openness
and
transparency,
so
we're
making
sure
that
we
do
everything
in
the
open
as
part
of
published
meetings
on
the
open,
ssf
calendar
that
are
being
recorded
and
then
having
different
voices
from
companies,
including
docker,
deploy
hub,
ibm
and
other
companies
who
have
been
joining
us.
We
have
some
independent
folks
as
well,
who
are
joining
us
and
contributing
either
prs
or
or
code
or
ideas
for
the
project,
and
also
where
we're
also
another
important
goal
for
us
on.
D
The
project
is
to
make
sure
that
we
are
collaborating
and
working
together
with
other
openss
projects
like
six
store
and
other
ongoing
efforts.
So
I
think
this
is
also
something
which
we're
striving
to
do
is
to
build
a
project
which
is
well
integrated
with
the
overall
open
ssf
ecosystem
and
the
last
thing-
and
this
is
this-
is
why
we
want
to
go
through
the
q.
D
A
is,
you
know,
obviously
we're
driving
towards
having
a
an
initial
release
and
mvp,
which
folks
can
start
to
use
specifically
for
a
docker
use
case
around
the
project,
but
we're
open
as
well
to
input
and
feedback
from
the
tac
and
other
folks,
so
that
we
can
have
the
best
design
and
map
out
the
best
roadmap.
So
it's
a
project
which
aligns
with
the
open
ssf
goals
but
then
solves
some
of
the
larger
industry,
problems
which
we're
all
seeing
from
our
customers
and
and
in
the
security
ecosystem.
D
I
Thank
you
steve,
so
I
captured
a
few
because
they
cover
the
broad
set
of
questions.
But
every
single
question
that
was
asked
in
the
way
it
was
asked
is,
has
been
answered
in
a
dock
which
is
at
the
bottom
of
this
slide
deck
and
I'll,
throw
it
in
the
slack
channel
slack
channel
and
chat
as
well,
so
that
you
know-
and
this
is
by
no
means
end
to
the
conversation.
This
is
like.
Thank
you
for
these
questions.
I
Let's
talk
more
and
please
please
bring
all
these
kind
of
questions
to
us,
because
this
allows
us
to
sort
of
peel
through
the
the
layers
and
delve
deeper.
So
one
of
the
questions
was
is
persia
a
new
package
manager-
and
this
was
asked
in
a
in
a
couple
of
different
ways,
but
I
try
to
try
to
answer
this
at
a
high
level.
I
How
will
will
this
work
with
cli
such
as
docker?
Actually,
the
first
integration
that
we
have
we
have
built
is
is
to
be
transparent
so
that
you
can
still
continue
to
do
docker
while
persia
comes
in
the
background
and
provides
you
the
peer-to-peer
distribution
mechanism.
So
your
ci
cd
systems
don't
have
to
change.
There
is
no
single,
no
line
that
has
to
change
in
that
code,
because
that
is
from
our
experience
and
our
data,
that
is,
the
heavy
lift.
People
will
be
more
and
more
resilient
or
what
they
will.
I
What
we
see
as
being
done,
you
know
being
done
thousands
of
times
is,
is
verification
and
reading
that
that
blockchain
versus
writing
to
it
and
and
the
rights
we
would
like
to
control
it
or
through
only
the
trusted
or
trusted
registry
nodes
that
are
that
are
carefully
added
to
the
system
and
brian
and
brian
made
this
comment.
So
I
thought
it
was
really
apropos
to
the
discussion
and
there
are
a
couple
more
questions
I'll
cover.
How
about
you
know
how?
I
How
does
the
contribution
structure
look
like?
I
think
anyone
who
wants
to
join
the
team
and
has
enough
background,
has
and
has
been
on
boarded
will
get
a
get
merged
rights,
so
they
they
act
as
a
full
team
member.
This
npr's
they
approve
prs
and
review
prs,
but
for
anything
that
is,
that
is
production
grade.
People
are
given
permissions
based
on
based
on
what
they
need
like.
I
If
you
are
going
to
install
or
deploy
a
something
in
the
cloud,
then
we
will
give
you
permissions
to
operate
on
that
cloud
and
so
on,
but
it's
not
blanket,
but
it's
not
restricted
to.
You
know
privileged
members,
it's
it's
shared
with
with
all
the
companies
that
are
participating,
and
then
there
was
one
thing.
One
last
question
that
I
wanted
to
cover.
So
there
was
a
comment.
I
Actually,
it
said
that
oh
based
on
based
on
the
criteria
that
was
presented
in
in
the
prs
before
it
seems
like
persia,
is
qualifies
for
sandbox
project
and
I
think
the
same
as
well
like
persia
qualifies
for
sandbox
project,
because
it
satisfies
all
the
criteria
there
and
it
may
satisfy
more
criteria
for
a
as
part
of
being
the
incubation
project,
but
not
all
of
them.
So
we
don't
want
to
just
skip
steps
and
just
be
considered
for
incubation.
I
think
we
want
to
start
where
it
is
appropriate
to
start.
I
Do
the
sandbox
stuff
we'll
bring
we'll
bring
more
companies
on
board
they'll
use
it
in
production.
We'll
learn
from
that.
So
we
we
hope
that
we
have
an
mvp
early
sub
early
summer,
not
september
early
summer,
and
then
we'll
we'll
engage
with
companies
to
start
using
it
get
us.
You
know
real
life
feedback
and
move
forward,
and
so,
as
we
have
have
more
traction,
I
think
it
makes
sense
to
graduate
from
one
stage
to
the
other.
I
D
B
D
This
is
no
longer
the
case,
but,
for
example,
before
microsoft
purchased
npm,
it
was
like
a
denial
of
service
attack
across
against
the
whole
developer
community.
So
this
this
is
something
which
we
think
a
peer-to-peer
solution
does
solve
at
at
scale.
If
it's
well
supported-
and
I
think
something
else,
this
gets
to
another
question
which
was
about
the
bft
and
the
resource
utilization
of
it.
So
in
the
network
there
will
be
nodes
run
by
companies
such
as
the
the
member
companies
I
mentioned,
jfrog
docker
deploy
hub,
etc.
D
These
will
be
the
nodes
which
participate
in
consensus
for
the
bft
algorithm,
the
the
general
nodes.
So
if
you're,
if
you're
running
a
node,
mostly
for
distribution
purposes
or
just
to
pull
down,
builds
you'll,
be
able
to
access
and
read
the
the
the
chain,
the
the
full
immutable
transaction
history,
but
you're
not
participating
in
consensus,
so
the
set
of
nodes
participating
in
bft
will
be
very
limited
based
upon
the
number
of
member
companies,
but
you
can
think
it's
in
the
in
the
dozens
at
most,
you
know
100
at
scale.
D
L
L
D
At
the
same
time,
I
think
if
you,
if
you
look
down
the
road
five
years
or
more
in
the
future,
having
a
decentralized
system
for
distribution
has
a
lot
of
advantages
and
it
in
general,
it's
a
it's
a
technology
which
solves
this
problem
at
scale
and
without
single
points
of
failures
or
reliance
on
a
lot
of
funding.
A
decentralized
system
where
all
the
nodes
are
are
helping
with
the
distribution
is
highly
resilient
to
individual
companies
or
or
individual
nodes
going
down.
D
So
I
think
what
we're
doing
is
we're
we're
supporting
the
current
ecosystem,
even
from
other
efforts
we're
doing
at
jfrog,
but
then
building
a
system
which
we
believe
in
the
future
will
will
be
quite
scalable
and
reliable
to
to
support
that.
Did
you
have
a
did
that
answer
your
question
lauren
or
address
it.
B
A
A
There's
a
number
of
online
news
sources
that
are
picking
up
on
a
google
blog
about
a
contribution
of
a
scanning
technology
to
work
against
devastating
malicious
packages
and
google
in
the
open,
ssf
package.
Analyst
project
aims
to
reduce
security
risk
by
creating
developers,
crazy
package,
updating
schedules,
and
this
is
something
that
I
was
surprised
to
see
out
in
the
news.
A
But
I've
not
been
able
to
find
any
documentation
on
this
being
discussed
at
any
working
group
recently,
I
could
be
wrong,
but
I
asked
colleagues
to
check
as
well,
so
this
is
kind
of
concerning
to
me
because
this
is
sort
of
not
unlike
some
of
the
activities
of
about
a
year
back
when
things
were
loosely
structured
during
the
pandemic.
So
I
just
wanted
to
make
the
attack
aware
and
start
a
healthy
discussion.
C
Well,
abhishek
has
been
really
good
about
answering
some
questions
in
the
document,
so
we've
got
documented
answers
in
there.
So
thank
you
abhishek
for
that,
but
seeing
this
thank
you
jeffrey
for
bringing
this
to
our
attention
there,
and
but
this
brings
up
two
questions
number
one:
how
did
this
get
out
without
anyone
hearing
about
it?
C
Wd
charter
is
that
this
is
a
technical
thing
that
has
gone
out
into
the
world
and
the
tac
didn't
get
any
say
into
it,
and
the
tech
is
the
technical
advisory
committee
for
openssf
and
has
oversight
over
all
of
these
things.
So
we
got
to
figure
out
a
process
to
make
sure
that
when
working
groups
have
something
to
release
before
it
goes
out
in
the
wild
wild
world,
it
comes
through
the
attack
first.
So,
that's
something
that
I
think
is
a
great
thing
for
future
calls.
B
B
There
there
is
a
governing
board
level
committee,
so
it's
higher
up
in
the
org
chart
than
the
attack
chartered
to
address
and
release
policy
opinions
when
the
government
asks
for
an
opinion.
A
few
of
us
are
members,
but
it's
not
broadly
visible
here,
because
it's
a
governing
board
committee,
but
at
least
that
is
a
known
organizational
structure.
B
A
Well-
and
I
wanted
to
just
thank
you,
ava-
and
I
just
wanted
to
make
a
final
comment-
I'm
not
bringing
this
up,
because
I
I
want
the
tac
to
become
you
know,
upset,
or
I
want
folks
to
become.
You
know
punitive
about
this,
but
I
also
don't
want
to
assume
things
like.
Oh,
this
was
just
because
we
don't
have
marketing
staff
yeah.
This
time
is
a
highly
inappropriate
behavior
and
it
is
going
to
eventually
potentially
cause
significant
problems,
and
so
what
I'd
ask
the
tact
to
do?
A
Is
someone
to
take
an
action
item
to
to
do
some
due
diligence
against?
How
did
this
really
happen
because
david
wheeler's
not
with
us
on
the
call,
maybe
he
has
a
very
good
explanation
he
had
to
leave,
but
I'd
really
like
to
see
a
specific
action
item
taken
by
the
attack
to
investigate
this
on
a
you
know,
polite
and
professional
manner,
and
disclose
how
this
happens.
So
it
won't
happen
again.
K
B
We
are
at
we're
at
time
I'll
answer
that
quickly,
a
working
group
under
under
the
the
norms
of
most
open
source
foundations
and
other
linux
foundation
projects.
A
working
group
doesn't
have
authority
to
speak
for
the
entire
foundation
full
stop
in
the
confidential
competing
consortium.
The
tac
always
reviews
things
that
are
going
to
become
press
releases
and
represent
anything
that
will
publicly
represent.
The
technical
opinion
of
the
entire
foundation
goes
through
the
tac
for
approval,
because
the
tac
is
the
technical
oversight,
body
or
technical
advisory
body
of
the
foundation
it'd
be
like.
A
I
A
K
I'm
happy
to
get
it
more
structured,
so
totally
agree
with
it.
So
in
the
future,
if
you
feel
like
hey
all
the
product
releases
should
go
through
the
tech,
that's
totally
okay,
but
it
hasn't
been
in
the
past
and
if
you
feel
there
is
a
need
to
structure
that
we
can
definitely
do
that.
So
totally
agree
with
that.