►
Description
Meeting notes: https://docs.google.com/document/d/1-f6m442MHg9hktrbcp-4sM9GbZC3HLTpZPpxMXjMCp4/edit#heading=h.pujncb7gxv4f
A
A
C
My
name
is
Aditya
I'm
familiar
with
some
of
the
people
in
this
meeting,
and
but
I
haven't
been
to
one
of
these
before
my
name.
I
am
a
PhD
student
at
NYU,
one
of
the
maintainers
up
in
total
and
I
heard
that
some
of
the
work
we're
doing
on
the
internal
side
of
things
was
becoming
relevant
to
this
group.
So
Senator
come
by.
D
E
A
F
G
F
H
A
A
I
Hey
everybody,
so
the
great
artifact
repository
stick
meetings
have
been
running
along
smoothly
and
we
have
been
actively
discussing
funding
it
through
Alpha,
Omega,
I,
guess:
Michael
Scott.
Do
you
want
to
take
or
Amir
do
you
do
either
of
you
want
to
provide
any
updates
or
thoughts
to
The
Wider
working
group
about
the
direction
of
the
great
artifact
repository
audit.
J
Sure
happy
to
everybody,
I'm,
Mike,
I,
think
what
we're
at
least
my
thoughts
have
been
kind
of
circling
around
have
been.
You
know:
ecosystem
like
systemic
Parts,
systemic
parts
of
Open,
Source
ecosystems,
meaning,
for
example,
like
the
ruby
gems
infrastructure,
the
ruby
gems,
like
like
the
gem
like
client-side,
whatever
parts
of
that
are
service
server
service
side
running
within
the
infrastructure.
These
things
are
all
like,
almost
by
definition,
the
most
critical
parts
of
like
the
Ruby
ecosystem
and
similar
for
every
other
ecosystem.
J
Alpha
has
a
mandate
of
like
going
after
and
proactively
like
engaging
and
trying
to
help
be
as
secure
as
they
can.
The
very
most
critical
open
source
projects.
You
could
argue
that
infrastructure
is
not
an
open
source
project,
but
it
supports
it.
So
it's
good
enough
we're
we're
I
I,
think
if
and
we're
recording
this
so
I
should
have
my
my
factory,
but
I
believe
that
the
engagement
that
we
have
with
psf
includes
a
an
audit
of
some
sort
of
of
Pi
Pi,
so
we're
kind
of
or
already
in
that
game.
J
So
the
idea
here
is,
you
know
instead
of
running
the
great
repository
audit
as
a
separate
thing.
We
rely
on
this
working
group
and
perhaps
critical
projects
and
perhaps
best
practices
actually
now
that
I
think
about
it
to
kind
of
come
up
with
the
you
know.
You
know
if
we
could
just
do
one
a
quarter
like
what
would
the
first
one
be?
What
would
the
second
one
be?
What
would
the
third
one
be?
You
know
what's
in
scope,
what's
out
of
scope?
I
know
like
on
the
list.
J
There
was
some
discussion
over
like
the
Drupal
plug-in
ecosystem.
Is
that
important
enough
large
enough
critical
enough
to
be
on
this
list
like?
Where
does
that
fall?
I'm
sure
that
there
were
there
were
really
interesting
edge
cases.
Yarn
is
yarn
a
you
know.
Is
it
just
well
most
people
use
npm,
so
like
no
or
is
yarn
widely
used
well
enough
that
it
it
should
bump
up
over
some
others.
Obviously
we
have
limited
funds
too,
so
we
can't
do
everything.
J
J
Yeah
yeah
right,
so
you
know
the
question
is
like:
is
that
necessary?
Should
we
just
wait
for
that
until
we
get
the
first
Parts
done,
I
I
think
we
should,
but
I
I
certainly
would
love
this
group
to
help
guide
me
and
guide
AO
in
the
types
in
the
how
to
structure
these
engagements
to
maximize
the
maximize
the
benefit
for
all,
and
certainly
I'm,
super
cognizant
of
the
fact
that
a
lot
of
these
ecosystems
are
not
corporate
backed
and
therefore
don't
have
like
piles
of
funds
to
do
a
lot
of
this
work.
J
So
as
part
of
this,
we
want
to
make
sure
that
we
reserve
enough.
So
that
way,
if
you
know,
X
issues
were
found
scanning
an
ecosystem
and
they're
like
well
great
world.
Just
volunteers-
and
this
is
like
38th
on
our
list-
we
can
say
well,
we
can
pay
to
get
those
things
done
because
they're
really
important
to
us.
J
J
This
is
just
my
it's
how
I
feel
today
we
we
are
going
to
be
chatting
I,
think
we
said
next
week
to
kind
of
put
a
little
bit
more
more
rigor
behind
it
and
have
a
you
know,
kind
of
a
commitment
that,
like
we
really
it
are
all
in
on
this
expect.
The
answer
will
be
yes,
but
we
gotta.
You
should
have
that
conversation
and
then
come
back
to
this
group
and
say
so
in
a
few
weeks.
A
B
Yes,
Michael
at
the
there
was
a
couple
of
types
of
discussion,
the
last
meeting,
I'm,
not
sure
if
you
had
a
chance
to
catch
up
on
one
was
initially
the
scope
had
been
envisioned
as
infrastructure
and
code
base,
and
now
with
pen,
testing
and
Red
Team
exercises
we're
looking
to
sort
of
add
on
this
idea
of
like
testing.
What
policies
are
in
place,
particularly
around,
like
maybe
like
password,
resets
or
other
sort
of,
like
account
recovery
procedures.
B
There
are
other
ways
of
testing
policies
in
place,
but
in
particular,
I
was
thinking
of
something
like
not
that
we
would
do
a
sock,
2
audit,
but
something
akin
to
that
framing
where
we
say
hey
here,
are
the
list
of
policies
that
we
would
expect
a
registry
to
have
in
place.
Do
you
have
those
policies
and
then,
let's
randomly
sample
some
examples
of
when
the
policy
should
have
been
followed
and
then
see
if
it
was
followed
or
not?
B
Let's
do
it,
but
we
actually
already
have
some
information
about
where
there
are
gaps
and
security
capabilities
for
existing
large
Registries,
and
so,
if
we
think
there
might
be
funding
available,
we
might
also
consider
going
to
that
and
sort
of
putting
together
a
prioritized
list
of
like
filling
in
those
known
gaps
from
the
survey.
This
group
already
did.
J
E
William
yeah
also
sorry
for
the
microphone
issues
earlier.
Hopefully,
this
is
much
better
yeah
I
was
just
gonna
say
so,
as
for
some
context,
trailer
bits
has
two
audits
planned
both
for
Pi
Pi,
which
I
know
Seth
already
knows
about,
and
then
we
also
have
one
planned
for
Homebrew,
and
so
these
are
both
if
everything
goes
smoother.
These
will
both
happen
this
summer,
and
so
hopefully,
I
mean
both.
E
Those
reports
will
definitely
be
public,
and
so
we
can
definitely
share
those
here
and
those
it
may
help
me
AKA,
guiding
reference
for
for,
like
we've
done
similar
audits
in
the
past
since
awesome
yeah
in
terms
of
like
what
we
find
and
also
how
we
issue
that
ends
to
these
open
source
projects.
That's
limited
resources.
I
That's
awesome:
what's
the
what
tends
to
be
the
scope
of
the
audit?
Is
it
the
hosting
infrastructure
server?
Is
it
the
client
as
well?
Are
you
looking
at
source
code?
Are
you
looking
at
running
systems?
Are
you
including
stuff,
like
the
CDN
that,
like
is
host
like
I,
mean
you
know
the
infrastructure
like
for
behind
the
server?
If
you
just
test
that,
but
you
don't
test
it
in
the
context
of
the
CDN
that
it's
running
behind,
then
you
may
miss
like
cash
poisoning,
vulnerabilities
and
stuff,
like
that,
so
what
yeah?
What
is
the?
I
E
For
these
two,
the
scope
is
just
limited
to
the
code
base
of
the
package
index
itself
and
then
and
then
some
infrastructure
around
it
so
for
Homebrew
we're
going
to
be
looking
at
the
way.
So
it's
Homebrew
is
sort
of
unusual
that
it
uses
entirely
code
of
actions.
It
has
no
other
server
side
State.
You
can
only
use
kind
of
action,
just
given
packages
for
delivery,
and
so
because
of
that
we're
going
to
focus
the
infrastructure
on
it.
There
primarily
on
how
it
uses
of
actions
and
how
it
uses
different
packages.
E
But
we
won't
probably
dive
further
into
whether
those
Services
themselves
are
vulnerable,
say
cash,
poisoning
and
then
on
pipei
side,
we're
going
to
focus
primarily
on
Warehouse
the
code
base
for
Pipi,
but
also
we're
going
to
spend
a
bit
of
time
looking
at
kamitage,
which
is
Warehouses,
kubernetes
deployment,
infrastructure
setup
and
like
scaffolding,
so
both
of
those,
but
we
also
probably
won't.
We
probably
will
not
look
at
fastly
or
any
other
city
and
stuff
for
warehouse
and
idea.
I
Splitting
right
is
one
of
those
vulnerability
that
only
really
appears
when
you're
looking
at
how
the
inner
CDN
interplays,
with
the
the
backing,
server
and
stuff
like
that,
like
those
are
the
kinds
I
want
to
realize
that,
like,
if
you're,
just
looking
at
the
source
code
and
you're
running
it
locally
on
your
own
machine
and
testing
against
that
you're
going
to
miss
the
ones
that,
like
when
you're
running
in
the
live
system.
These
are
the
vulnerabilities
that
can
also
appear.
E
E
I'm
not
sure
if
we've
done
artifact
servers
before
we've
done
a
lot
of
Open
Source
audits.
Before
so,
we
were
involved
in
the
kubernetes
audit
that
the
open,
ssf
I
believe
was
doing
ssf
funded
in
2019
or
2020.,
and
we've
done
audits
of
openssl,
curl,
wolf,
SSL
and
another
large
packages
in
the
past.
E
B
I
I
C
A
A
I
A
I
But
if
you
have
not
seen
the
document,
the
great
artifact
repository
audit
document,
it's
linked
in
the
chat,
I'd
love
your
insights
and
feedback
on
that
and
then
I
will
Post
in
the
slack
channel
the
link
to
the
set
of
tests.
There's
two
tabs,
both
the
red
team
engagement,
things
we
want
to
be
explored
and
the
and
the
pen
test
things
we
want
to
be
explored
and
if
you
have
things
that
you've
thought
of
or
that
you
think
should
also
be
added.
I
J
Yeah,
if
I
can
make
one
more
suggestion,
real,
quick,
let's
I
I
would
like
to
use
this
working
group
as
the
funnel
point
so
that,
for
instance,
we
don't
we
would
not.
We
should
not
be
engaging
Home
Group
to
do
a
security
audit
and
even
in
small
organizations,
I
I
would
be
afraid
of
starting
out
two
threads
where
we're
just
not
aware
of
the
other,
so
I'll
coordinate
through
this
anything
that
comes
out
through
AO,
but
I'll.
D
A
B
That's
right!
That
was
me.
Let
me
out
through
my
attack
on
here,
so
we
had
quite
a
bit
of
success
with
adding
build
prominence
to
the
npm
registry.
It's
been
a
little
over
two
months
and
over
a
thousand
packages
have
gone
and
added
build
provenance
and,
in
addition
to
open
source
maintainers
we've
been
talking
to
other
maintainers
of
Registries
about
what
this
would
look
like
in.
B
What
sort
of
implementation
issues
came
up
during
our
adventure
and
what
sort
of
design
trade-offs
we
made,
or
in
particular
like?
Why
did
we
choose
to
emphasize
so
I
believe,
machine
identity
and
really
de-emphasize,
developer
identity
and
we've
seen
rfcs
for
build
provenance
in
the
rubygems
ecosystem
and
the
rust
ecosystem
get
a
little
Tangled
Up
in
this
question
of
like
what
do
we
do
about
developer
identity,
so
I
had
written
a
document
sort
of
describing
build
provenance
at
a
high
level.
What
sort
of
implementation
questions
came
up?
B
How
we
addressed
them
with
the
idea
that
other
registries
could
use
this
as
sort
of
a
as
a
reference
stock
or
a
a
rallying
point,
and
so,
instead
of
having
these
conversations
one-on-one
individually
and
kind
of
evolving
the
story
over
time
having
it
written
down
in
one
place
that
we
could
Point
people
at.
So
if
they
were
interested
in
adding
those
capability
to
their
ecosystem,
they
would
have
a
starting
place
and
we
haven't,
we
haven't.
B
We
haven't,
in
other
venues,
published
a
lot
of
information
about
how
npm
build
provenance
was
implemented.
The
CLI
part,
of
course,
is
open
source,
but
the
registry
is
not,
and
so
I
think
it's
helpful
to
have
some
high-level
description
of
some
of
the
design
decisions
and
implementation
there.
So
I
shared
this
with
a
few
folks
who
I
had
these
one-on-one
conversations
with,
including
working
group
co-chair
and
Dustin
Ingram,
and
he
asked
that
I
open
up
a
pull
request
in
the
repository.
A
E
A
E
B
B
C
B
B
A
I
think
we
would
want
to
probably
effectively
give
it
a
month,
and
that
would
be
this
sort
of
Emir
friendly
version
of
the
working
group
and
the
Apec
friendly
version
of
the
working
group
to
have
be
brought
up
to
speed
on
it
and
then,
basically,
we
can
just
go
and
I've
always.
This
working
group
is
a
little
unusual
in
that
we
have
an
explicit
list
of
committee
members,
so
we
can.
We
can
basically
just
Round
Up
some
LG
TMS
to
adopt
it.
I
think
that
would
be
fine.
E
This
is,
this
is
mostly
tangible,
digital,
but
I
want
to
bring
it
up
in
this
context,
because
it
is
a
generalized
of
using
this
generalized
form.
We
were
looking
at
adding
six
door
to
Homebrew
as
well,
and
Homebrew
is
kind
of
an
unusual
case,
because
it
doesn't
have
many
Publishers.
It
only
has
one
publisher
itself,
just
The,
Homebrew,
CI
and
I'm,
currently
working
on
the
technical
proposal.
E
For
that,
so
I
think
I'll
probably
show
that
the
next
working
group
since
I
don't
want
to
drop
it
at
the
end
of
this
meeting.
But
just
to
put
on
everybody's
play,
that's
something
that
we
think
could
probably
be
an
instantiation
of
the
standard
and
I
think
would
be
of
interested
people
in
this
group.
A
A
A
So
it's
something
we
discussed
in
the
past,
it's
kind
of
good
that
we
have
a
concrete
example
to
coalesce
around
like
the
publish
event,
I
think
and
the
push
event
will
be
like
the
two
really
big
ones
to
start
with,
and
we
can,
we
can
work
from
there.
Oh
and
you
know
authorship
at
her
station
as
well.
G
I
like
to
add
really
quickly
and
the
to
as
a
caveat,
this
is
super
pie
in
the
sky
and
to
be
clear,
there's
no
work
that
I
know
of
that's
going
here,
but
I
do
like
thinking
about
attestation
as
separate
from
Providence
and
like
a
lot
of
other
things
that
we
can
attest
to
Beyond
Providence.
Some
of
the
ones
that
are
top
of
mind
to
me
are
things
like
malware
scanning
and
a
testing
to
the
malware
scan
code
review
is
one
that
I
actually
think
could
be
really
interesting
to
be
clear.
G
I,
don't
personally
have
time
to
do
this
and
I
don't
think
my
team
does
but
I
think
that
that's
like
an
incredible
opportunity
for,
like
third
parties
or
consultancies,
to
build
out
an
index
of
attestations
about
hey,
we've,
actually
reviewed
this
code
for
my
Google
peers.
I
know
you've
done
a
lot
of
work
around
like
hey.
Here's
like
our
island
of
Open
Source
that,
like
we
run
internally
or
we
validate
it
internally
and
that
kind
of
stuff
can
be
attested
too
as
well.
G
There
is
pretty
important
and
anytime
there's
a
delay,
people
freak
out
and
think
that,
like
something's
broken,
and
we
don't
necessarily
want
to
introduce
a
huge
delay
between
publish
time
and
actually
getting
it
live
on
the
registry.
That's
something
that
we
want
to
make
super
fast.
So
we
don't
want
to
necessarily
have
something
like
malware
scanning,
be
like
in
the
critical
path
and
be
synchronous,
but
people
could
buy
a
policy
based
on
their
risk.
J
If,
if
that
is
directionally
interesting
to
this
group,
I'm
happy
to
put
more
effort
into
it,
we're
trying
to
drive
it
through
AO,
but,
like
everybody,
it's
you
know
more
things
to
do
than
we
can
do
even
to
the
point
that
if
other
folks
would
like
to
contribute
like
it's
all
open
source
and
the
the
you
know
it.
It
does
specifically
say
things
like
ice
scan
this
for
antivirus
on
this
date
and
nothing
was
found.
D
A
A
C
Yeah
I
just
want
to
say
that
the
internal
framework
as
a
whole
is
precisely
targeting
that
space
miles.
We
recognize
you
know
the
distinction
between
the
attestation
framework
itself
and
the
different
predicates
of
which
provenance
is
one
and,
as
a
matter
of
fact,
we
have
an
open,
PR
right
now
that
I'm
trying
to
drive
forward.
That's
introducing
things
like
a
code
review
at
a
station
and
dependency
review,
attestations
and
things
like
that.
C
So
where
currently
we're
looking
at
something
like
the
craft
project
but
I
also,
you
know
totally
love
to
incorporate
something
like
cargo
wet
in
there
and
and
so
on.
And
the
idea
is
that
once
we
have
all
of
these
predicates
wetted-
and
you
know
part
of
the
attestation
framework,
then
I
personally
love
to
see
everyone
organization
sharing
the
results
of
any
of
their
internal
audits
using
the
United
Stations,
and
things
like
that.
A
I
think
this
is
this:
is
the
working
group
for
exactly
that
kind
of
coordination?
We
really
do
want
to
ensure
that
there
is
a
a
Common
Language
and
a
common
framework
when
I
was
at
my
previous
employer.
One
of
my
sort
of,
and
me
serious
goals
was
to
prevent
my
colleagues
in
infrasec
from
having
to
run
more
than
one
monitor.
A
A
K
K
We
donate
to
open
ssf,
and
this
work
group
was
like
the
the
sponsor
for
that.
So
I
I
came
here
back
to
to
give
some
updates
and
then
I
would
drop
some
links
on
on
the
chat
here.
So
the
first
thing
is
we
moved
from
VMware
organization
the
projects
report
stories,
and
now
there
is
a
Aristotle
organization
in
GitHub,
where
our
report
stories
are.
This
is
the
first
thing
that
I
want
to
share.
K
The
second
thing
is
that
we
about
our
roadmap,
that
we
are
really
really
close
to
our
first
beta
version
that
we
call
minimum
working
version
related
to
tough
what
it
will
be
able
to
do.
It's
Health
administrators
will
be
able
to
add
that
facts
or
targets
how
they
they
call.
It
also
do
some
really
important
maintenance.
For
example,
do
the
metadata
predate
rotation
of
keys
everything
on
that?
So
we
are
very
close
to
that.
K
As
we
are
very
close,
we
also
submitted
together
with
Lucas
from
New
York
University,
that
is
a
tough
maintainer.
We
we
created
the
draft
PR
to
Pipi
using
our
stuff.
We
had
a
work
before
that
that
we
try
to
to
use
the
new
python
Turf
and
before
that
wheel
and
also
had
did
some
work
on
that.
So
this
PR
is
a
draft
using
the
the
the
beta,
almost
better
version,
because
why
I
say
almost
better
because
you
have
three
components:
two
of
those
components
are
about
already
one.
K
It's
missing,
some
of
the
small
features
that
we
are
about
to
merge,
so
everything
is
in
review
now
so
soon
we'll
have
that,
and
this
PR
is
a
a
suggestion
for,
for
example,
for
Pipi
adopting
our
stuff
as
the
tough
infrastructure,
so
as
a
service
yeah.
So
one
more
update
now
it's
some
something
that's
interesting.
There
was
in
openness
as
open
source,
Summit
North
America.
K
There
was
a
very
cool
presentation
from
Marina
and
Aditya,
that's
here
in
the
call,
and
they
used
our
stuff
as
the
the
tough
repository
implementation
for
that.
So
I
would
like
to
share
this
for
it's
about.
In
total,
but
our
stuff
was
there,
so
very
nice
presentation
and
I
need
to
say
also
that
it
was
very
useful
for
us
because
it
gave
us
some
kind
of
feedback.
So
we
have
already
some
new
features
Blended
to
our
stuff.
Then
you
can
go
because
my
designer
stuff
was
started
with
focusing
pep458
for
Pipi.
K
So
when
I
was
watching,
this
presentation,
I
had
some
ideas
for
new
features
that
then
we
can
really
go
beyond
pep458
design,
but
also
implementing
pep
480
and
giving
more
flexibility
for
our
staff
user
to
design
the
metadata
delegations.
So
this
will
be
a
very
cool
and
the
last
one
that
would
be
that
I
want
to
do
here.
It's
a
yeah,
we'll
be
presenting
in
at
Aero
python
this
year,
a
presentation
about
pep458
a
solution
not
only
for
pipei.
K
Then
we
will
demonstrate
this,
of
course,
Pipi
using
Warehouse
using
our
stuff,
but
we
go
also
to
share
another
kind
of
repository.
That's
not
related
to
let's
say
package
only
because
when
to
to
show
how
our
stuff
can
be
agnostic
about
which
kind
of
artifact
you
want
to
protect
using
curve
so
yeah.
Those
are
my
updates
for
our
stuff
products.
I
will
be
back
here
soon
for
more
updates.
Of
course,.
A
K
K
K
So
then,
when
I,
when
one
of
our
tries
to
implement
pep
458
in
Warehouse,
we
had
the
idea
to
detach
all
the
tough
services
from
the
warehouse
and
creating
a
tough
repository
as
a
service,
in
the
way
that
others
could
benefit
from
that
not
only
Pipi
but
other
any
kind
of
repositories
that
could
that
they
want
to
use
the
pet
458
design.
So
the
pad
for
private
design
has
a
explicit
definition
about
roles,
delegations
and
keys.
How
it
will
be
used
to
sign
these
metadata.
K
Then
we
started
the
the
idea
of
our
stuff
was
on
top
of
that,
of
course,
now
we
are
already
planning
going
beyond
that.
That
our
stuff
can
be
more
flexible
in
not
not
only
to
to
approach
the
pep
for
private
design,
but
the
users
can
have
flexibility
to
design
their
metadata
delegations,
not
sure
if
I
was
clear
enough.
Sorry
for
that,
I.
B
There's
a
quick
comment:
there
I
think
this
is
great.
You
know
the
PKA
is
a
notoriously
hard
problem
and
tough
appears
to
be
a
really
elegant
solution
for
ensuring
people
can
reliably
check,
assigned
material
from
package
Registries
and
be
able
to
survive
some
sort
of
incident
where
those
keys
might
be
made
to
be
rotated.