►
Description
Meeting notes: https://docs.google.com/document/d/1-f6m442MHg9hktrbcp-4sM9GbZC3HLTpZPpxMXjMCp4/edit#heading=h.pujncb7gxv4f
B
A
C
A
C
B
E
B
E
F
That
sort
of
like
helps
other
people
who
might
be
maintaining
software
repositories,
and
then
there
were
some
excellent
points
that
you
know.
We
can't
assign
things
to
different
software
repositories,
and
everyone
is
short
on
time.
So
you
know
things
in
particular
that
are
high
impact
and
low
effort.
F
I
think
we're
still
talking
about
that
approach
and
where
it
might
or
might
not
work,
but
that
got
me
thinking
about
other
ways.
Those
sort
of
those
two
topics
coming
together,
ways
that
we
can
help
other
other
software
repositories,
deliver
meaningful
security
improvements,
and
this
wonderful
pattern
that
the
python
software
foundation
and
pipei
have
of
writing
up
sort
of
like
individual
chunks
of
improvements
that
could
then
be
funded
and
then
once
funded
delivered.
F
But
I
am
very
interested
in
continuing
to
talk
about
ways
that
we
can
turn
dollars,
maybe
from
the
open,
ssf,
maybe
from
other
entities
into
meaningful
security
improvements,
and
this
is
this
is
sort
of
one
example,
I
think
of
ways
to
do
that,
but
I'm
also
open
to
other
people
getting
feedback
about
why
that
approach
might
or
may
not
work
for
them.
Or
you
know
if
people
if
people
need
help
with
the
documentation
or
if
they
need
help
connecting
to
funding
resources,
trying
to
figure
out
how
to
facilitate
that.
E
So
we
did
this
a
while
back
when
we
were
looking
for
various
opportunities
to
get
funding
and
basically
just
came
up
with
a
list
of
all
the
kind
of
biggest
nice
to
have
projects
that
you
know,
volunteer.
Maintainers
are
probably
not
going
to
be
able
to
fix
because
they
need
some
dedicated
experienced
work
over
a
long
period
of
time.
E
E
E
E
I
think
it'd
be
important
to
make
sure
that
you
know
any
list.
That
is
a
list
of
fundable
improvements.
Has
buy-in
from
you
know
the
folks
that
maintain
that
ecosystem
right
so
I,
don't
think
you
know
I,
don't
think
me
making
a
list
of
things
that
rubygems
should
should
definitely
get
funded,
make
sense,
but
I
think
with
with
support
from
everyone
in
these
ecosystems.
That
probably
would
be
useful.
E
E
I
would
be
really
you
know
like
as
a
maintainer
of
another
ecosystem
that
is
kind
of
interested
in
this
I
would
like
to
hear
a
couple
things
I'd
like
to
hear
like
how
much
work
was
it?
How
long
did
it
take?
You
know
how
many,
how
many
of
all
how
many
engineer
hours
was
it
roughly
like
anything
that
you
would
do
differently
or
any
challenges
in
the
rollout?
That
kind
of
stuff
I
think
would
be
really
interesting
to
hear
from
any
ecosystem.
That's
already
implemented
it.
C
Yeah
and
that's
and
that's
kind
of
the
point
I
was
I
was
getting
at
Dustin.
Is
that
I
think
there's
certainly
a
place
for
you
know
for
ecosystem
fundables
and
I
I
heartily
encourage
that.
I
also
think
that
there's
perhaps
some
issues
that
we
in
this
working
group
can
identify
that
are
cross-cutting,
and
so,
for
instance,
you
know
funding,
for
if
we
wanted
to
bring
tough
to
a
specific
ecosystem
would
be
you
know,
kind
of
scoped
to
that
ecosystem.
C
If
we
wanted
to,
you
know,
invest
in
documentation
or
process
or
tooling
or
whatever
it
is
for
all
tough
implementations,
and
then
that
could
be
cross-cutting
and
I'll
table
it
for
a
moment.
But
I
I
do
have
some
some
specific
fundables
in
in
mind.
I
I
assume
that
at
the
end
of
this
this
bullet
point
we
can
throw
out
a
couple
of
like
specifics,
not
necessarily
work
through
them,
but
but
you
know
just
kind
of
kick
the
ball
around
as.
E
C
A
It
just
sounds
to
me
well
I,
shouldn't
say
just
it
sounds
to
me
like
there's
a
sort
of
a
latent,
fundables,
Matrix
or
vulnerable's
table
lurking
in
the
wings.
For
this
with
you
know,
one
dimension
being
things
we
would
like
to
fund
and
the
other
dimension
being
ecosystems
that
have
or
have
not
been
able
to
achieve
that
thing
we
could
use
the
survey
as
a
as
a
jumping
off
point
in
that
regard.
A
F
The
feedback
that
I
gave
to
Jonathan
on
the
great
repository
audit,
which
I
would
be
remiss
to
not
repeat
here,
is
that
often
often
we
kind
of
have
these
Grand
plans,
but
it's
like
we,
we
sort
of
need
one
ecosystem
to
buy
in
and
say
like,
yes
we're
interested,
and
then
it
certainly
certainly
we
could
create
that
table.
But
you
know
in
in
order
in
order
for
any
of
those
pieces
to
be
delivered,
it's
it's
it's,
the
classic
sort
of
like
two-sided,
Marketplace
problem
right.
F
Maybe
this
is
me
thinking
too,
like
tactically
and
pragmatically,
but
what
I
would
really
like
to
see
us
identify
a
particular
ecosystem
who
would
sort
of
be
interested
in
going
through
this
exercise
either
either?
For
you
know
just
one
or
two
things
that
are
sort
of
like
top
of
mind
for
them
or
or
something
like
what
the
pipi
did,
which
is
sort
of
like
a
more
comprehensive
like
almost
like
a
road
map
of
something
I
could
endure
for
a
couple
of
years.
E
I
think
the
other
thing
that's
been
really
nice
to
have
here
is
kind
of
prior
art
right,
I,
think
that
would
be
make
a
lot
of
these
more
attractive
to
funders.
If
they
see
oh,
like
python,
ecosystem
wants
to
do
build
an
stations,
and
it's
already
been
done
in
npm,
and
it
was
successful
to
some.
You
know,
based
on
some
Metric
or
you
know,
it
exists.
Right
is
already
somewhat
proven.
I.
B
C
Yeah,
so
so
Jacques
I
think
I
think
sounds
like
overall.
It's
it's
a
good
idea
to
try
to
reuse
as
much
as
we
can
right
and
to
be
able
to
point
to
past
experiences
and
to
honestly
just
let
people
cut
and
paste
where
they
can.
Instead
of
having
to
write
these
things
from
from
scratch,
but
I
I
think
all
Echoes
Zach's
point,
which
is
we
shouldn't,
you
know
and
I.
Don't
think
this
is
what
you
were
saying,
but
we
shouldn't
block
improvements
in
one
ecosystem
on
having
a.
A
E
C
Awesome
cool
well,
then
not
to
get
not
to
get
too
into
the
weeds,
but
but
Zach
if
you're
interested
in
also
experimenting
with
process
around
more
cross-cutting
stuff.
I
I
have
a
proposal
in
mind.
Long
long
story,
short
and
I
can
I
can
give
more
context
of
this
later
and
in
in
any
kind
of
fundable
document.
C
E
F
Speaking
of
build
provenance
like
we,
we
can't
talk
about
other
things
like
we
can
talk
about
two-factor
authentication.
We
can
talk
about
detecting
malware,
but
it
is
a
bit
of
a
Hot
Topic
these
days,
I.
So
the
there
we
go,
I,
I
guess:
I
have
the
next
agenda
item,
which
is
about
Dockers,
build
attestations.
I
was
delighted
and
surprised
to
see
this
announcement.
F
They
are
making
use
of
in
Toto
attestations
with
salsa
predicates,
which
I
think
is
a
great
idea
and
I
hadn't
I
hadn't
seen
people
talk
about
it.
Much
I
hadn't
encountered
anyone
from
Docker
who
was
working
on
this,
and
so
in
case.
Other
people
were
similarly
unaware
that
this
was
something
they
were
working
on.
I
wanted
to
share
it
with
this
group
as
I.
Think.
A
lot
of
us
on
this
call
are
are
fans
of
in
Toto
attestation
documents
with
salsa
predicates.
E
F
Yes,
so
and
I'm
never
sure
how
much
background
to
give
and
these
sort
of
things,
but
just
to
make
sure
we're
on
the
same
page
in
the
in
the
process
of
publishing
an
npm
package
with
attestations.
There's,
there's
two
sets:
there's
the
build
attestations
which
are
sort
of
well-defined
in
total
document
with
salsa
predicates
and
then
there's
the
publish
attestation,
which
we
sort
of
took
cues
from
the
in
total
project,
but
sort
of
like
made
up
what
information
we
thought
should
be
contained
in
a
published
attestation.
F
I
I
did
not
I'm
not
like
steeped
in
in
the
in
the
work
and
the
thinking
behind
the
publish
at
that
station.
So
certainly
we
should
talk
about
this
more
when
Frederick
or
Philip
Harrison
are
here,
but
but
we
are
absolutely
interested
in
going
through
a
more
rigorous
process
of
talking
about
what
should
be
in
that
published
attestation
with
people
outside
of
npm
and
ensure
that
whatever
documents
and
standard
and
predicates
that
we
settle
on
are
something
that
is
widely
applicable.
D
E
F
D
E
A
A
Was
just
going
to
say,
I
I
have
a
thing
coming
out,
which
is
that
it
looks
like
notary
actually
delivered
something.
I
I
saw
a
picture
on
Twitter
of
a
big
announcement
at
AWS
re
invent
which
they
did
something
based
on
notary
and
I'm
like
oh,
is
that
still
going
so
I
I
wonder
how
much
internal
drama
there's
going
to
be
at
Docker
and
I?
Don't
know
if
that's
gonna
have
any
influence
I'm
so
glad
this
is
recorded.
That
I
put
that
out
there
in
the
world.
D
C
Yeah
I
think
I.
Think.
Another
important
point
to
note
is
that
my
understanding
is
that
there's
a
generic
mechanism
for
attaching
things
to
container
images
and
the
specific
formats
are
an
artifact
of
the
build
tooling
here,
and
so
it
would
be
I
think
pretty
straightforward
to
extend
the
build
to
only
to
produce
things
in
different
formats
or
like
the
the
attachment
mechanism,
seems
generic
enough
that
I,
don't
I,
wouldn't
view
the
specific
types
that
are
on
the
table
today
as
permanent
or
unique.
F
E
E
Foreign
cool
all
right,
so
this
one
is
mine,
so
I
was
what
I'm
curious
about
is
if
folks
are
aware
of
cargo
vet
and
if,
if
there's
any
sort
of
Interest
or
has
been
any
interest
in
your
ecosystem
of
bringing
it
to
your
ecosystem,
so
the
background
for
anyone
that
is
not
familiar
with
cargo
vet.
This
is
some
project
out
of
Mozilla
to
essentially
audit
third-party
dependencies
sort
of
somewhat
standardized
way.
So
the
idea
is
your:
your
team
consumes
some
some
third-party
dependencies.
E
B
E
So
I
think
trishank
kind
of
actually
read
my
mind
here,
a
little
bit
so
a
I'm
curious.
You
know
with
your
ear
to
the
train
tracks.
Have
you
heard
any
kind
of
interest
in
this
or
does
anything
like
this
sort
of
already
exist
in
your
ecosystem
and
then
B?
Yes,
does
it
make
sense
to
think
about
standardizing
this
in
some
way.
E
A
A
long
time
ago
we
saw
that,
let
me
think
we
very
Loosely
and
vaguely
and
yeah
the
main.
The
main
concern
was
that
it
was
like
GitHub
based.
Ideally
it
would
go
through
a
transparency
log
and
the
other
question
that
was
raised.
I,
don't
think
I
ever
had
a
satisfactory
answer
is
how
do
I
put
this
politely?
A
A
lot
of
companies
will
be
a
little
trepid
about
attaching
their
name
to
a
public
statement,
but
something
is
good
or
not
so
would
need
some
ref
on
an
open
source
license
on
their
test
station
itself.
To
say
no
warranty,
you
know
don't
see
me
if
you
rely
on
my
statement,
then
something
bad
happens
because
otherwise
nobody's
going
to
contribute
these.
G
Yeah
I
think
that
brings
up
an
interesting
point
too,
because
I
think
one
of
the
ideas
is
that
you
have
this
accountability
system.
Where
folks,
like
we
mean
trusted
Bettors
if
their
betting
isn't
found
to
be
bad,
but
I
think
it's
hard
to
Define
what
that
means,
because,
like
we
discover
new
vulnerabilities
and
stuff
changes,
yeah.
A
It
also
argued
that
you
would
essentially
need
subjective
statements
right
like
in
the
sense
that
there
is
an
identity
that
is
asserting
or
attesting
something,
and
that
your
trust
as
a
query,
a
querying
agent
depends
in
part
on
who,
as
well
as
what
and
I
think
that's
going
to
be
true,
no
matter
what,
but
also
in
practice.
Probably
what
will
happen
is
we'll
wind
up
congregating
about
certain
common
like
there
will
be
some
shelling
points
right
in
in
this
universe,
where
people
sort
of
converge
from
a
policy
that
everyone
follows.
A
You
know
like
pretty
much
everybody's
going
to
be
like
I
trust,
GitHub
and
Google
100
to
not
up
good
luck
with
that
guys.
So
I
think
it's
a
good
idea.
I
think
I.
Think
it's
important
because
otherwise
we
have
to
replicate
that
labor
over
and
over
and
over
right
it.
It
turns
the
defensive
problem
into
it's
still
a
collective
action
problem,
but
it's
like
building
offense.
You
know
if
somebody
doesn't
build
their
segment
of
the
fence.
A
E
A
E
D
Oh
I,
don't
think
this
this,
but
thanks
yeah,
I,
think
I.
Think
it's
important
ever
since
I
saw
a
cargo
wet
I'm
like
this
is
a
brilliant
idea,
but
it'd
be
nice
if
we
could
standardize
it
so
that
we
could,
we
could
literally
wet
it
the
same
way
so
to
speak
across
ecosystems.
So,
just
like
with
the
publisher
station
I,
guess
that's
going
to
be
my
tune
for
the
next
few
meetings.
Let's
standardize
this
and
that.
C
I'll
answer
no,
but
I
I
think
maybe
there
that
points
to
a
useful
follow-up,
which
is
someone
should
read
it,
but
then,
but
then
also
we
we
could
reach
out
to
the
in
Toto
folks
and
see
if
they
have
any
thoughts
on
how
best
to
do
this.
Because
because
my
my
assumption
is
that
their
familiarity
with
the
ecosystem
will,
will
you
know
point
to
getting
the
format
more
right
than
I.
G
A
E
F
E
I'm
going
to
judge
by
the
lack
of
discussion
and
talking
about
it
probably
just
makes
sense
to
everyone
and
so
probably
something
we're
thinking
about
cool.
So
we
have
Marina's
going
to
reach
out
to
the
internal
folks
and
so
I
think,
let's
try
and
make
an
effort
to
read
item
nine
with
our
next
meeting
anything
else
about
cargo,
better
stations.
A
A
We
know
sort
of
main
problem
with
nature.
Is
that
it's
containers?
That's
all.
It
does
and
I
think
the
absence
of
a
transparency
log
makes
it
much
less
attractive
than
it
would
otherwise
be,
but
I
just
you
know.
As
I
said
this
flew
across
my
radar
very
briefly.
Today,
I
don't
have
much
context,
but
it's
kind
of
interesting
because
I'd
sort
of
forgotten
about
notary
because
it
it
had
sort
of
turned
into
you,
know
the
Quest
for
El
Dorado.
A
F
F
A
F
A
A
A
A
A
E
E
E
B
F
E
Getting
back
to
2fa,
we
can
move
down
in
a
second
I,
wanted
to
add
support
for
2fa
mandate
rollout.
So
you
know
I,
don't
know
if
folks
have
seen,
but
pipei
is
going
to
do
this
by
the
end
of
2023
for
for
everyone,
and
so
there's
just
a
lot
of
work
that
has
to
go
into
you
know,
announcing
it
and
making
all
the
changes
to
support
it.
That
kind
of
thing
definitely
a
potentially
fundable
project
for
some
some
ecosystems,
we're.
F
I
was
I
was
going
to
blow
out
the
scope
by
suggesting
we,
we
like
even
have
like
a
higher
group
of
categories
which
is
like
well
and
then
inspired
by
the
not
comprehensive,
but
maybe
medium
thought
out,
threat
modeling
that
npm
did
there
were
lots
of
people
posting
what
they
thought
were
threats
to
npm
online
and
then
posting
what
they
thought.
Our
mitigations
were
to
those
things
and
then
posting
on
what
they
thought.
F
The
effectiveness
of
those
imagined
mitigations
were
so
we
decided
to
write
them
down
in
one
place,
and
so
this
may
or
may
not
be
a
helpful
framework,
but
you
know
kind
of
like
bucketing
and
thinking
like
okay.
Well,
how
are
we
preventing
account
takeover?
How
are
we
preventing
people
from
submitting
malicious
or
otherwise
like
confusing
content?
F
A
A
Related
to
that
is
the
supply
chain
taxonomy,
which
was
originally
in
a
paper
by
the
folks
who
wrote
the
backstabbers
knife
kid
or
knife
collection.
I
can't
remember
the
exact
title
now,
which
had
a
very
elaborate
attack
tree
very
elaborate,
like
hundreds
of
hundreds
of
leaf
nodes
and
that's
been
adopted
by
the
end
users
working
group
and
it's
still
evolving,
still
being
worked
on
so
for
Source
material
in
terms
of
parts.
A
E
E
E
F
A
Yeah
Resurrection
attacks
rubygems
has
a
a
daily
job.
I
can't
remember
these
exact
details,
but
it
hits
an
API
that
provides
a
list
of
expired
domains
based
on
the
domains
that
exist
in
the
database.
It
says
these
ones
have
expired
and
it
locks
that
account.
Basically,
it
forces
them
to
reset
the
account.
A
A
E
B
E
Even
need
intervention
by
a
human
but
yeah
I
think
the
workflow
is
sort
of
like
yeah
publishing.
This
I
think
there
was
some
interest
in
doing
this
with
osv,
but
I
think
the
the
scope
was
a
little
bit
different
there,
because
OC
is
really
primarily
concerned
with
the
vulnerabilities
and
malware
kind
of,
but
doesn't
exactly
fit
in
that
bucket,
and
also
the
volume
is
quite
different
right.
Over
vulnerability
is
somewhat
somewhat
rare
and
malware
definitely
isn't.
C
G
B
E
F
We're
always
very
careful
in
the
npm
documentation
or
other
content
to
not
say
that
a
package
is
secure
just
because
it's
published
Providence
but,
of
course
having
those
verifiable
links
to
source
code
and
build
instructions,
enable
malware
detection
techniques
that
would
not
otherwise
be
possible.
Yeah.
A
That's
that's
what
I
always
thought
right
like
as
as
more
and
more
parts
of
the
overall
package
lifecycle
become
available
in
the
transparency
log
right,
it
becomes
easier
and
easier
to
detect
a
suspicious
pattern
and
to
to
investigate
further.
It's
really
just
about
prioritizing,
and
my
motto
that
I
keep
repeating
is
make
the
attacker
move
in
the
open,
because
they're
gonna
have
to
do
all
these
things
anyway.
C
E
Level
of
recommendations
of
things
that
software
repository
should
do,
and
then
maybe
the
next
step
after
that
is
working
with
individuals
in
those
ecosystems
to
make
a
list
of
fundables
I
mean
I
really
like
the
funnels
thing.
I
think
it
works
a
lot
better
if
it's
sort
of
owned
by
the
individuals
who
will
be
overseeing.
F
F
Salsa
has
had
such
a
Monumental
shift
in
the
way
that
people
think
about
supply
chain
security,
and
that's
because
it
was
a
framework
that
you
know
wasn't
too
complex
was
written
and
pretty
easy
to
understand
language,
at
least
in
my
opinion
and
and
I
was
able
to
kind
of
like
shape
and
frame
people's
thinking
and
I.
Think
there's
an
opportunity
for
this
group
to
do
the
same
for
software
repositories.
E
C
So
then,
maybe
AI
on
that
is
I
can
take
it
and
just
file
an
issue
in
our
in
our
repository
and
link
to
a
bunch
of
source
material
that
that
could
possibly
be
useful,
including
probably
this
this
brainstorm.
We
just
had
a
bunch
of
stuff
throughout
the
I.
Think
this
note
stock
is
like
200
Pages
or
something
it's
82,
but
like
yeah
I,
think
I
think
that
yes,
let's
track
doing
that,
because
I
think
it's
a
great
idea.