►
From YouTube: SLSA Tooling Meeting (January 27, 2023)
Description
Meeting notes: https://docs.google.com/document/d/15Xp8-0Ff_BPg_LMKr1RIKtwAavXGdrgb1BoX4Cl2bE4/edit#heading=h.yfiy9b23vayj
C
So
I'll
be
out
there,
mostly
on
behalf
of
tax
security,
so
I
actually
have
a
talk
on
behalf
of
like
I'll,
be
talking
about
supply,
chain
stuff
and
what
we've
been
doing
in
tag
security
for
supply
chain
cool,
my
company,
I,
won't
be
I,
won't
have
doesn't
have
any
talks
out
there,
but
but
I
will
also
there's
a
bunch
of
other
meetings
and,
and
you
know,
potential
customers
and
all
that
good
stuff.
Yeah.
A
C
A
C
Yeah
feel
free
to
add
your
name
and
anything
you
want
to
add
to
the
agenda.
I
only
have
one
minor
thing
on
the
agenda
still
trying
to
kind
of
I
know
a
lot
of
folks,
as
people
have
mentioned.
A
lot
of
folks
who
are
Hands-On
keyboard
Engineers
tend
to
not
attend.
You
know
these
sorts
of
meetings
and
so
a
lot
of
the
folks
who
are
maintainers
of
some
of
the
projects.
C
Some
of
it's
just
because
some
of
the
projects,
some
of
the
maintainers
or
some
of
the
salsa
projects,
are
out
on
the
west
coast,
and
this
time
is
way
too
early
for
them,
and
some
folks
are
actually
one
of
the
other
main
painters
he's
actually
out
in
Japan,
and
it's
like
11
p.m.
There
or
something
so
that's
also
difficult.
C
So
we're
gonna,
try
and
maybe
reach
out
and
figure
out
like
better
way
like
a
better
time
that
works
for
everybody,
because
we
do
want
to
see
if
we
can
get
some
of
the
maintainers
of
some
of
these
projects
on
it
doesn't
have
to
be
all
the
time
but
like
even
just
like
once
a
month
to
be
on
this
call.
So
that
should
sync
up
on
some
of
the
things
that
we're
that
we're
looking
to
do:
okay,.
C
C
B
B
C
C
B
C
Right
yeah,
so
somehow
I
guess
like
at
the
end
of
the
year.
Something
happened
with
the
open,
ssf
stuff
and
it
locked
everything
it
locked.
The
calendar
invited
locked
the
got
it
all
right
or
rather
expired,
the
calendar
invited
whatever
cool.
So
the
only
thing
on
the
agenda
was
so
I
wanted
to
provide
a
little
bit
of
an
update.
I
spoke
to
the
software
repos,
our
securing
software
repos
group,
the
APAC
group,
not
the
emba
group,.
C
Right
so
what
was
gonna
say
so
I
spoke
to
the
protecting
software
repos
group
on
Wednesday,
about
if
there's
interest
among
the
various
ecosystems
like
npm,
Pi,
Pi,
Jam,
ruby,
gems
and
so
on,
made
in
central
for
starting
to
develop
either
or
a
set
of
like
practices
on
how
to
how
to
store
and
distribute
or
I
think
actually
more
distribute.
The
story
doesn't
really
necessarily
matter
but
how
to
distribute
salsa
packages.
B
B
I
would
more
think
about
sort
of
the
schema
for
Distributing
these
attestations,
because
that's
where
I
think
it
can
get
a
little
bit
hairy
like
as
an
example
in
npm,
we're
going
to
rely
on
the
six
door
bundle
format
which
allows
us
to
capture
certificate
chains
and
other
cryptographic
materials,
or
at
least
like
the
public
part
of
it
used
during
the
signature
time.
So
for
a
verifier,
they
get
everything
served
to
them
up
front
and
they
only
need
to
have
like
root
certificates
and
intermediate
certificates
or
public
keys.
B
So
the
bundle
itself
is
sort
of
self-contained
like
the
provenance
is
there
and
the
public
part
of
all.
The
keys
is
also
there
and
some
other
proofs
like,
for
instance,
add
bundle
order,
entry
from
a
record
that
sort
of
proves,
or
at
least
shows
the
promise
of
the
or
artifacts
artifact
signature,
transparency
and
other
parts.
B
So
it's
like
it's
a
fairly
big
piece
of
data:
it's
not
just
the
actual
provenance
itself
so
and
and
I
know
from
other
parts
that
I
don't
think
they
are,
or
maybe
they
are
looking
into
use,
the
bundle
I'm
not
sure
like.
But
for
me
at
least
that's
what
I
think
the
biggest
discussion
would
would
be
yeah.
C
That
that
makes
sense,
I
hadn't,
even
I,
forgot
about
the
the
bundle
piece
some
of
us
have
just
been
using
the
which
we,
which
comes
with
its
own
set
of
things.
So
there's
the
there's
the
bundle,
because
there's
also
we've
mostly
been
using
Json
the
just
the
Json
lines
dizzy
envelope
stuff.
But
we
recognize
that
not
like
that's,
not
flexible
enough
to
do
everything
and
so
yeah.
So
there's
the
bundle,
that's
a
so
is
that
fully
ironed
out
and
accepted?
Or
is
that
still
being.
B
It
is
accepted
as
currently
it's
released
under
0.1.0
version
like,
but
it's
I
mean
it
has
gone
through
a
fairly
deep
reviews.
I
would
say
it's
definitely
stable
or
reliable
enough
to
start
use.
We
know
of
some
future
changes
that
are
coming,
but
when
we
have
no
idea
and
as
an
example,
even
though
it
is
like
a
six
door
bundle,
it's
inherently
not
tied
to
six
store.
You
can
rely
on
whatever
a
pki.
You
would
like
to
like
any
certificate.
Authority
will
work.
Narc,
3161,
timestamping
service
is
totally
gonna
work.
B
B
Confidence
in
the
signature,
like
as
an
example,
an
array
of
counter
signatures
from
a
timestamping
Authority
or
a
bunch
of
Rico
service
servers
that
witnessed
and
accepted
and
and
when
transparent,
with
the
signatures
and
are
generic
like
way
of
specifying
hey
here,
is
a
certificate
Authority
that
was
used
to
give
me
a
signing
certificate
Etc.
So
it's
not
you're,
not
forced
forced
to
use
sigstore
by
using
the
bundle,
but
obviously
it
sort
of
came
from
the
direction.
We're
supporting
the
the
different
Services,
that's
offered
by
the
six
star
ecosystem.
C
C
So
there's
a
few
things
one,
and
this
was
stuff
that
I
know
I've
already
talked
with
some
of
the
Homebrew
folks,
and
some
of
the
other
people
is
largely
some
ecosystems.
So
I'll
put
this
out,
so
some
ecosystems
are
actually
rather
different
interest
at
different
levels
between
ecosystems,
so
some
have
have
said
they
want
to.
You
know,
be
involved
in
developing
a
spec
standard.
C
Some
have
said
so.
Let
me
just
hold
on
some
want
to
be
involved
in
developing
a
to
be
involved
in
developing
a
stacker
standard.
Someone
want
to
be
involved
in
implementing
what
others
decide
right
and
don't
want
to
themselves
be
they're
like
hey
look.
We
don't
have
enough
time
and
yayada,
but
if
somebody
comes
in
and
says
you
use
this
library
or
use
this
spec,
we
will
do
that
some
and
then
some
largely
want
to
be
left
out.
C
So
there's
some
folks
who,
who
more
or
less
said,
hey,
look
we're
not
going
to
prevent
others
from
let's
say
generating
this
stuff,
but
we're
not
going
to
support
it
directly
and
so,
for
example,
Homebrew
in
particular
seem
to
indicate
that
you
know
they're
like
look.
We
don't
want
to
get
involved
in
in
any
of
that,
there's
a
few
folks
who
indicated
they
might
want
to,
but
more
from
just
like.
If
you
just
you
know
like
we're,
you
know,
they're,
not
making
any
guarantees
on
anything.
They're.
C
Just
sort
of
saying
here
is
a
place
where
to
look
up
extra
metadata
and
they
are
okay,
with
sort
of
pointing
potentially
pointing
people
to
that
sort
of
thing.
But
beyond
that,
they're
not
going
to
really
support
some
of
that
and
there's
a
few
others
that
seem
to
indicate
like
yeah,
probably
not
so,
there's
like
three
levels
or
you
know
there,
between
the
ecosystems
I,
believe
that
major
ecosystems,
like
your
your
gems,
your
npm,
your
Pi,
Pi
and
so
on.
C
They
seem
interested
in
being
involved,
there's
a
few
other,
smaller
ones
that
seem
to
maybe
not
wanted
to
sort
of
implement
what
others
decide,
but
not
get
involved
on
some
of
the
other
stuff
and
then
yeah
some
of
the
other
ones
once
again
I.
This
is
mostly
just
peering
through
the
from
some
folks
who
are
involved,
but
are
not
represented
representatives
of
those
ecosystems,
but
I've
heard
like
Homebrew
Gen
2,
a
few
others,
probably
just
you
know,
they're
like
hey.
B
C
Oh
yeah,
yeah,
no,
no
I
know
that
yeah
yeah
and,
in
fact,
I
just
yeah
I'm,
totally
on
board
with
folks
supporting
the
bundle
I
just
I
too
much
too
many
things
going
on.
It's
it's
hard
to
keep
keep
track,
actually
give
me
one
second
I
just
need
to
make
sure
I
tell
somebody
that
we
need
to
support
the
bundle.
C
Yeah,
so
the
other
thing
to
take
a
step
back,
some
folks
had
brought
up
like
even
Beyond
talking
about
the
API,
a
couple
of
things
of
like
whatever
we
do
looking.
You
know
this
is
coming
from
Jacques
from
who's,
who
he's
not
a
representative
of
gems,
but
he's
you
know
he's
like
hey,
based
on
my
experience,
working
with
gems
and
doing
this,
this
kind
of
the
other
thing
they
said.
You
know,
there's
probably
some
principles
that
that
we
want
to
have
in
there.
C
B
That
just
a
comment
as
well
like
this
is
definitely
something
we
have
been
discussing
from
npm
and
npm's
perspective
as
well
and
I
think
we
were
discussing
this
last
Friday,
like
sort
of
the
proposed
API
format
we
have,
and
basically
it
is
like
a
simple
URL
with
the
package
naming
version
in
it.
So
it's
like
super
easy
to
cap
cache
or
whatever
caches
that
might
be
like
either
a
c
in
a
CDN
or
something
in
front
of
it
or
back
of
it.
B
A
C
C
But
that
leads
to
other
issues
because
then
it
becomes.
Then
you
have
to
download
the
package
plus
everything,
and
then
you
have
to
unpack
it
and
then
compare
hey
is
the
thing
I.
Just
is
the
extra
bit
in
this
terrible?
Actually,
what's
you
know,
you
know
to
do
the
do
the
hashes
line
up
and
it
becomes
kind
of
a
mess
compared
to
just
sort
of
saying,
hey,
I
I
have
this
I
I
can
check
the
checksum
or
whatever,
and
then
when
I
download
the
package.
C
Path
for
finding
for
finding
the
various
Providence
documents,
so
another
thing
that
was
brought
up
a
little
bit
was
to
potentially
get
additional
input
and
feedback
is.
We
might
just
want
to
say
this
is
at
API
that
could
just
download
arbitrary
metadata
documents
so
that
we
don't
have
to
say-
and
here
is
a
separate
API
for
downloading
s-bombs
and
here's
a
separate
API
for
downloading
security
scans.
This
is
just
an
API
for
downloading
those
things
and
I
think
the
thing
that
folks
have
brought
up
is
they
just
want
to.
C
A
lot
of
folks
are
starting
to
come
in
with
batch
requests,
as
you
had
sort
of
mentioned
of,
like
I,
want
to
download
all
s-bombs
related
to
for
the
the
entire
life
cycle
of
this
package,
because
I
want
to
be
able
to
see
what
has
changed
over
time
and
you
know
see
hey
this
previous
version
was
using
this
package
and
then
this
new
version
seems
to
be
using
a
typo,
squatted
version
of
that
same
package.
What
happened?
C
C
I
have
like
four
slides,
just
kind
of
talking
about
the
high
level
stuff
to
the
emea
group,
because
the
APAC
group
there's
only
like
six
people
on,
but
the
emaa
group
I
know
tends
to
have
like
15
or
20
people
on
at
least
they
said,
there's
a
lot
more
folks
and
so
I'm
gonna
show
off
to
some
of
them.
Just
try
and
get
some
feedback
and
get
some
input
there.
Yeah
and
also
people
seemed
interested
in
hey.
C
C
I,
don't
want
to
pick
on
Brendan
Mitchell,
but
yeah,
as
you
know,
like
hey
the
more
complicated
the
more
API
nouns
and
verbs
there
are
and
yeah
yeah
before
you
know
it.
It
becomes.
You
know
a
year
or
something
like
that
before
anything
can
get
decided
on.
I
think
the
thing
that
we're
trying
to
say
is
hey,
keep
it
dead,
simple
and
and
hope
for
the
best
and
hope
certain
types
of
people
don't
end
up
being
like
hey.
Well,
no,
no,
we
can't
do
this.
C
In
the
last
yeah,
so
yeah
I'm
I
am
yeah.
I
am
very
prepared
for
that.
I
do
think.
I've
noticed
in
the
community
a
little
bit
which
seems
to
have
worked
largely
is
sometimes
you
ask
for
forgiveness,
as
opposed
to
permission
like
oh
yeah,
the
the
spec
isn't
completely
done,
but
we
implemented
something
based
on
a
draft
of
the
spec
and
before
you
know
it
after
the
spec
just
becomes
the
spec,
because
everybody
like
well.
This
thing
supports
it,
which
I
also
know
is
kind
of
a
it's.
C
A
A
I
was
just
kind
of
bootstrapping
and
just
like
kind
of
like
going
from
the
ground
up
around
just
a
simple
signature
on
a
python
wheel,
uploading
the
the
python
wheel
up
to
like
a
private
Pi
Pi
registry,
but
then
I
can't
upload
the
signature
today
to
the
private
python.
You
know
Pi
Pi
registry,
so
I
had
to
upload
the
signature
somewhere
else
so
like
being
able
to
have
that
all
kind
of
like
in
somewhere
consistent
would
be
very
helpful.
So
it.
D
Just
because
I've
missed
a
bunch
of
these,
probably
every
other
one
of
them.
When
you
talk
about
making
an
API
spec
a
lot
of
what
we
talked
about
is
trying
to
generate
artifacts
generate
Source
provenance
on
something
that's
already
pushed
up
to
package,
repo,
npm
or
CI
images
pick
wherever
they
are
each
one
of
those
has
their
own
completely
distinct
apis.
You
know
nothing,
nothing!
You
can
work
with
there
are
you
proposing
making
us
another
repository
or
where
you
want
business.
C
So
this
is
and
Frederick
tell
me
if
I'm
off
base
here
with
how
npm
plans
to
do
this
is
potentially
this
could
just
be.
Who
requests
right?
You
have
the
request
to
gems
pip
whatever
for
your
actual
package
but
separately.
There
is
a
rest
API
that
various
groups
can
run
that
you
could
just
sort
of
say.
C
If
somebody
is
downloading
this
thing,
they
would
just
take
this
data
regarding
their
package,
the
version
yayada
to
a
rest
API
and
be
able
to
pull
down
additional
metadata
and
with
the
idea
here
that
most
likely
gems,
Pi
Pi
Etc,
would
run
this
API
and
once
again
they
could
implement
it.
However,
they
want
to
as
long
as
it
sort
of
meets
the
spec
and
the
idea
would
be
potentially,
let's
say,
tip.
For
example,
I
go
in
and
let's
say
the
PIP
CLI
either
has
a
plug-in
or
the
new
version
of
pepcli
supports
this
API.
C
You
can
go
and
say:
okay,
great
I
run.
You
know,
pip
install
dash,
dash
check,
salsa
or
whatever
great
it
goes
and
like
looks
up,
you
know,
based
on
pip
install
requests
or
whatever.
That
is
okay.
What's
the
latest
requests
cool
check?
The
you
know
check
that
API.
Okay,
yes,
I
pulled
down
the
salsa
cool,
pull
down
the
package
check
the
two.
Oh,
it
looks
good
or
whatever,
but
the
idea,
at
least
from
my
opinion
and
I,
want
to
get
other
folks.
C
C
It's
like
no,
no
everything
should
still
work,
but
if
folks
now
want
to
do
the
additional
piece
of
checking
the
s-bomb
checking
the
salsa,
it's
just
a
separate
API
request
to
this
other
thing
and
in
addition
to
that
right
like
if
other
folks
are
like,
hey
look,
I,
don't
want
to
run
this
thing,
but
if
you
want
to
run
it
great,
then
you
could
do
something
like
check.
You
know
check.
Salsa
here
is
the
API
to
actually
check
the
salsa
or
whatever
I
think
that's
kind
of
the
thing
we
want
to.
C
We
want
to
do
and
yeah.
We
don't
want
to
change
the
package
API
for
everybody,
because
we
recognize
that
everybody's
going
to
want
to
do
it
their
own
way,
yeah
yeah,
but
but
for
the
metadata
I
think
that
might
be
a
little
simpler.
Oh
Frederick
I
know
she
posted
some
stuff.
Do
you
want
to
talk
about
how
npm
is
looking
at
it?
Yeah.
B
Sure
so
I
mean
yeah
I've
posted
an
example
URL
how
it
may
look
like
in
this
in
the
chat,
so
that's
sort
of
the
simplest
API
we
are
going
after
and
probably
not
implemented
us
now,
but
for
managing,
let's
say
s-bombs
or
volume
scans
or
whatever
might
be
like
the
way
we're
thinking
it
about.
It
would
probably
be
like
a
clear
parameter
to
filter
by
predicate
type.
B
Everything
would
still
be
packed
like
you
know
this
envelope,
so
it
would
be
consistent
and
consistent
for
for
the
verified
to
unpack
and
understand
what
everything
is
as
part
of
publishing.
We
are
currently
doing
it
together
with
when
you're
publishing
the
package,
like
it's
sort
of
just
an
extra
attribute
that
gets
along
in
the
upload
requests.
So
there
is
still
like
a
single
call
to
publishing,
but
that
I,
don't
think,
is
as
important
like
the
read
part
IES,
but
I
think
is
more
interesting
because,
like
yeah
sure
whoever
fires
and
things
like
that
policy
engines.
D
Are
you
looking
to
take
you
back
on
top
of
our
existing
apis
or
is?
Is
this
like
npm
has
to
add
this
new
API
here?
Let
me,
let
me
give
you
the
reason
for
the
question
that
might
help
explain
this.
A
lot
of
this
reminds
me
a
little
bit
of
notary
version,
one
where
they
basically
came
up
with
a
separate
API.
You
had
to
query
to
verify
signatures
of
container
images.
D
The
API
included
things
like
the
image
name
in
there
and
it
was
a
separate
server.
You
had
to
run
separate
ports
all
that
kind
of
stuff
and
to
me
never
adopted
it.
There
are
multiple
issues,
I'll
dig
into
all
of
them,
but
at
least
one
of
them
was
hey.
We've
got
to
query
the
separate
API.
We
can't
move
the
images
and
images
very
frequently
do
move.
D
That
might
not
be
quite
the
same
as
what
what's
face
in
other
package
ecosystems,
where
things
don't
move
as
much,
but
that
was
one
of
the
challenges
they
ran
into
where
people
want
to
move
the
images,
but
they
could
copy
the
signature,
because
the
signature
was
hard
code
to
only
go
with
that.
One
name
and
just
separately
running
another
separate
server,
separate
API
people
had
a
query,
was
a
challenge,
and
so
that
was
one
of
the
big
efforts
behind
a
lot
of
what
was
going
on
with
Thursday
I.
D
B
B
It
would
be
fairly
easy
to
just
have
another
column
where
you
can
sort
of
squash
in
this
attestation
data,
so
I
think
or
at
least
I
hope
it
shouldn't
be
as
challenging
and
for
moving
packages,
and
things
like
that,
I
don't
think
it's
supported
in
npm
to
to
move
a
package
like.
If
you
would
like
to
sort
of
transfer
ownership,
you
would
pretty
much
have
to
open
up
a
new
scope
and
then
redeploy
in
as
part
of
that
deployment.
B
B
Can
have
what's
I
would
say
unscoped
packages
and
then
you
can
claim
a
specific
scope
and
then
you
can
publish
your
packages
under
that
scope.
So
as
an
example,
just
to
pick
like
a
pretty
big
scope
would
be
like
payable
and
under
the
Babel
landscape
namespace,
you
have
or
label
scope.
You
have
a
bunch
of
packages
that
debate
the
organization
owns
and
managed.
So
it's
it's.
Both
I
would
think
that
most
big
packages
are
names
in
names.
B
D
B
Thanks
I
think-
or
at
least
my
my
assumption
would
be
that
it's
more
common
for
organizations
to
run
private
OCR
Registries
than
running
node
Registries,
but
I,
don't
know
like
there
are
players
around
that
are
offering
this
as
a
service.
Github
for,
for
instance,
would
be
one
I
know
like
architecture
and
a
bunch
of
others.
So
what
I'm
kind
of
hoping
is
that
a
lot
of
vendors
look
into
those
offerings?
Instead,
where
sort
of
everything
is
coming
out
of
the
box.
D
C
Yeah
I
I
think
yeah
I,
think
that
should
be
an
interesting
one
as
well,
because
when
thinking
about
this
I
was
thinking
about
the
J
frogs
and
the
sonotypes
and
and
those
folks
when
talking
to
some
of
them
and
how
they've
currently
been
handling
it,
thus
far,
they've
just
sort
of
said.
Oh,
we
just
have
a
repo
like
since
in
artifactory
and
soda
type
Nexus,
you
could
just
sort
of
have
a
flat
file
repo
as
well,
and
we
just
sort
of
say:
oh
yeah
yeah,
like
either
we
have
a
flat
file.
C
That's
just
you
know,
sits
right
next
to
the
package
or
we
have
a
flat
file
in
a
separate
repo,
and
we
have
some
scripts
to
sort
of
verify
those
two
things
I
think.
From
that
end,
it
would
be
interesting
to
also
get
some
of
their
input
on
it.
To
make
see
how
simple
this
would
be
right,
like
I,
do
think
that
if
we
make
something
like
a
the
simplest
bit
of
the
spec,
just
be
here's
what
the
path
should
look
like.
A
Yeah-
and
maybe
this
is
kind
of
a
little
bit
of
what
I
was
talking
about
with
what
I
was
doing
with
trying
to
just
do.
Signatures
for
a
wheel
file
in
Python,
like
I,
had
to
host
my
python
wheel
in
Pi,
Pi
private
registry
right,
but
then
I
had
to
host
the
signature
in
basically
a
flat
file,
generic
storage,
and
then
you
know,
for
my
end,
users,
I
just
have
a
shell
script
where
they
curl
both
of
those
things
and
compare
with
cosine
right.
A
The
work
is
really
where
that
install
and
and
it's
expecting
it
to
get
that
thing
right
so
like
I,
think
that's
where
the
rubber
meets
the
road
specifically.
Does
that
make
sense,
I
think
that's
where
it
all
comes
together.
Yeah
making
it
flat
is
easier,
obviously
like
you're,
eluding,
Michael,
so
yeah.
C
Yeah
I
mean
I,
like
I.
Do
think
that
there's
and
once
again,
I
don't
want
to
get
too
deep
into
like
the
like
implementation
right.
But
I
can't
imagine
right
where
there
is
a
set
of
musts
right
like
you
must
support
this
sort
of
pathing
and
then
there's
probably
a
bunch
of
should
or
coulds
that
are
maybe
more
like
batch
style.
Like
hey
look,
you
you
say:
hey
look.
We
can't
support
that
because
you
know
we're
gonna
get
slammed
hey,
that's
fine!
C
You
just
need
to
support
the
flat
file,
stuff
or
whatever
I
think
even
just
sort
of
something
like
that
is
is
probably
okay
for
for
most
folks
and
I'm.
Also
thinking
about
some
of
this
when
I
start
to
look
at
like
some
folks
have
like
the
back
stuff,
I
think
is
going
to
be
useful,
because
a
lot
of
folks
have
begun
to
ask
questions
of
there's
no
way
to
batch,
collect
a
bunch
of
s-bombs
for
stuff
like
research
purposes,
and
a
lot
of
folks
are
getting
very
they're
like
hey.
C
I
have
to
go
through
a
list
of
you
know
and
I
I
get
that
this
is
all
to
some
extent.
This
is
also
the
the
the
why
list
images
inside
of
a
reap
inside
of
a
oci
registry
is
usually
disabled
for
all
public
prep
histories
like
so
that
people
don't
go
around
crawling.
All
images
actually
Brandon
probably
has
a
better
like
I
assume
it's,
because
they
don't
want
to
get
slammed
with
a
ton
of
like
you.
D
C
C
Yeah
that
that
actually
is
something
that,
if
you're
running
a
private
repository
you
probably
now
have
to
deal
with,
which
is
just
you
know,
npm
it's
it's
not
a
big
deal,
but
you
could
imagine
if
somebody's
running
an
artifactory
with
thousands
and
thousands
of
packages,
some
of
those
packages
might
be
scoped
to
different
teams
and
then
yeah.
So,
okay,
so
that's
actually
it's
good
that
you
I
hadn't,
even
considered
that
I
just
assumed
it
was
more
of
like
don't.
D
I'm
sure
there's
some
of
that,
but
every
time
you
make
a
query
and
say:
I
want
to
pull
the
Alpine
image
from
Docker
Hub
Docker
Hub
sent
you
over
their
authentication
server
and
says.
Give
me
an
Access
token.
That
gives
you
the
rights
to
access
the
Alpine
Repository
for
just
a
pull
request
and
or
a
pull
query,
and
so
they
that's
part
of
the
API
going
back
and
forth,
and
so
the
the
scoping
around
the
one
that
says
list
all
repositories.
It
basically
have
to
say
list
every
Raw
Story.
C
C
C
All
right
does
anybody
actually
know
anybody
else
who
might
be
interested
from
any
of
these
groups?
I
know.
We've
we've
spoken
to
briefly
the
trail
of
bits,
folks
who
I
know
are
working
on
some
of
this
for
for
pip,
and
this
was
a
few
months
ago,
and
this
is
before
we,
you
know
we
were
thinking
through
this
sort
of
idea
and
it
might
make
sense
to
sort
of
ping
them
and
say
hey.
This
is
something
we're
thinking
about.
C
Also
I
think
that
I
don't
know
what
spokes
thoughts
are
on,
including
the
s-bomb
like
groups,
or
you
know,
other
sorts
of
groups.
You
might
be
interested
or
we
should
kind
of
come
to
them
with
here's
something.
That's
relatively
done.
Do
you
want
to
add
in
I
just
I
recognize
like
this
morph
of
a
practicality
standpoint,
the
obviously
the
more
people
that
are
involved,
the
more
reasonable
discussions.
I
mean,
there's
the
more
discussions
there
are
and
the
more
reasonable
objections
there
are,
but
at
the
same
time
it's
like
hey
great.
C
We
have
a
steering
committee,
It's
relatively
lightweight,
you
know,
lots
of
minor
revisions
are
stuff,
are
super
easy
to
get
in
and
stuff
like
you
know,
implementations
are
super
simple.
To
kind
of
you
know,
we've
been
able
to
kind
of
get
a
lot
of
tooling
out
there
really
quick,
because
of
that
sort
of
lightweight
touch,
so
I'm
curious,
if
folks
have
have
thoughts
about
who
else
should
be
included.
A
D
I
was
just
looking
back
through
some
of
the
old
notes
and
seeing
exactly
what
the
scope
of
this
group
is
because
I
feel
like.
If
you
try
to
scope
it
too
much
when
we
want
to
handle
all
the
distribution
of
salsa
artifacts
you're,
going
to
run
into
exactly
we're
running
into
now
that
npm.
Does
it
one
way
or
cim
just
a
different
way
pip.
Does
it
their
own
way
and
it
becomes
a
fractal
issue
where
everybody's
doing
something
slightly
differently
and
we're
trying
to
write
a
spec
that
tries
to
cover
the
world.
C
For
us
to
define
something,
if
other
people
want
to
do
something
different
great,
that's
fine
like
we're,
trying
not
to
be
I,
think
prescriptive
in
it
too
much,
but
the
idea
would
be,
at
least
in
my
opinion.
Npm
is
already
done
most
of
the
work.
There's
probably
a
couple
things
in
here
that
we
might
just
want
to
say:
hey.
Does
it
make
sense
to
maybe
broaden
this
a
little
bit
or
restrict
this
a
little
bit
more
and
provide
that
sort
of
feedback?
C
And
then
largely
just
say:
hey,
let's:
let's
do
this
maybe
have
salsa
have
you
know
like
npm
is
going
to
have
and
I
don't
know
if
npm
is
open
sourcing,
the
actual
implementation
or
or
whatever
of
of
that
thing,
but
to
either
you
know,
take
that
implementation
or
build
a
separate
sort
of
hey
here's,
how
anybody
can
run
a
salsa.
You
know
a
a
salsa
metadata
repository
and
it's
just
a
you
know,
I'm
sure,
since
everything
we've
done
so
far
is
mostly
in
go
I'm
sure
it'll
be
some
simple.
C
Go
sort
of
you
know
API,
and
you
know
these
are
the
sorts
of
things
and
and
I
think.
That's
kind
of
the
thing
here
like
because,
because
one
of
the
things
that
was
kind
of
brought
up
in
some
of
the
other
salsa
meetings
was
just
a
lot
of
folks
are
asking
these
questions
and
they're
just
like
how
should
I
do
this
and
so
there's
two
separate
pieces?
One
is
at
the
highest
level
we
should
probably
have
a
set
of
here
are
some
reasonable
practices
you
should
do
like.
C
For
example,
please
don't
package
the
attestation
alongside
the
package
itself,
don't
package
it
up
with
the
actual
artifact
in
a
way
that
it
becomes
difficult
to
figure
out.
What's
what
what's
the
salsa
and
what's
the
you
know,
I
mean
that
sort
of
thing
there's
some
other
basic
things
that
that
would
be.
You
know
like
like
with
some
of
this
stuff
is
like
hey.
C
If
you
can,
another
best
practice
is
try
and
make
it
easy
for
folks
to
download
just
the
salsa
attestation,
because
in
many
cases
they're
going
to
want
to
have
the
salsa
attestation
first
run
it
through
some
policy
before
determining
whether
or
not
they
should
download
the
package
right
and
like
some
basic
things
like
that,
some
basic
best
practices,
then
probably
something
like
hey
here-
is
an
imp.
You
know
here
is
a
spec
that
hits
those
best
practices,
and
here
is
maybe
I
know
in
open
ssf.
D
D
It
almost
feels
like
the
the
direction
of
making
these
slices
and
delegations
and
I
make
the
tooling
fits
better
with.
Let's
talk
about
how
we
do
all
of
those
for
npm
sort
of
how
we
do
all
of
those,
for
you
know
each
of
the
different
package
ecosystems
out
there,
and
that
way
we
can
say
these
are
kind
of
the
best
practice
guiding
principles
for
all
of
these
things
that
we're
trying
to
do,
but
not
restricted
and
saying
we're
just
doing
the
salsa
attestations
across
the
board.
You
know
cut
slice
it
differently.
Yeah.
D
D
D
You
know
the
the
salsa
metadata,
all
that
can
just
be
a
different
media
type
and
then,
under
that
inside
the
blob.
That's
for
that
team
to
fight
out
and
argue
and
figure
out,
yep
the
the
sauce
team
can
go
to
and
sort
out.
Okay.
This
is
how
we
want
to
format
our
metadata.
All
we
care
about
is
the
media
type
there.
At
that
point,.
D
Oh,
there
are
too
many
things
going
on
right
now
that
just
really
complicate
that
question
yeah,
I
I,
don't
think
it
solves
the
problem
where
we
already
have
npm,
we
already
have
Pi
Pi.
We
already
have
all
these
other
package
ecosystems
out
there
and
I
feel
like
the
place
where
you
go
and
pull
down
your
Linux
image,
for
you
know,
Debbie
impact
or
something
like
that.
It
makes
sense
to
keep
all
the
metadata
with
the
package
itself,
wherever
that
packaging
care
system
is-
or
at
least
alongside
of
it,.
A
C
Yeah
and
just
to
be
clear,
like
I,
would
love
it
if
everybody
did
that
and
I
know
that
there's
some
folks
who
have
been
I
don't
know
looking
to
cash
things,
and
you
know,
put
things
into
stuff,
and
then
you
know
generating
like
hey
here,
is
the
backing
store
in
the
backing
stores,
oci
and
then
whatever
the
AP
like,
because
at
the
end
of
the
day,
oci
is
more
of
the
backing
store
than
anything
right
it.
You
could
still
have
an
API
in
front
of
it.
That
is
whatever
right.
C
B
D
Yeah,
the
real
complications
is
that
you're
stepping
into
the
landman
hill,
whatever
it
is
right
now
that
we're
we've
got
an
internal
debatable
or
not
we're
going
to
make
the
artifact
manifest.
Anyway,
it's
been
following
that
that
we
standardized
whether
we're
actually
going
to
release
that
right
now
or
not.
So
the
the
way
that
people
have
previously
been
shipping
artifacts
would
still
work
which
issue
to
ship
them
as
an
image
manifest.
But
there's
a
lot
of
debate
right
now
and
other
ways
we
can
ship
things
and
I
think
the
generic.
C
Yeah
yeah
I
do
think
if
everybody
was
doing
the
ocipes,
it
would
simplify
well,
it
would
simplify
a
lot
of
things
on
the
consumption
end
and
it
would
simplify
a
lot
of
things
the
tooling
and,
and
that
sort
of
thing
it
would
just
there's
the
trade-off
of
now
everybody
from
the
production
end
of
like
hey
the
folks
who
run
npm
the
folks
who
run
pipe
pi
and
so
on.
Now
they
have
to
like
it's
like
well.
This
is
a
significant
amount
of
of
work
on
their
end.
D
I
mean
they:
they
already
have
package
repositories
for
their
stuff.
I,
don't
want
to
replace
their
work
if
they've
already
got
something,
that's
there.
So
that's
where
I
take
the
step
back
and
say
as
much
as
I
am
representing
all
this
stuff
over
CI
I'm,
also
not
trying
to
overtake
all
the
other
projects.
B
C
Yeah
but
I
know
that's.
One
of
the
things
we
had
talked
about
a
couple
of
months
ago
in
this
group
was
like
Hey,
would
folks
be
interested
in
taking
some
of
the
oci
stuff
and
just
kind
of
running
forward
with
that,
because
that
will
make
things
a
lot
easier.
But
then
it
just
becomes
this
thing
of
well
you're
you're
asking
a
lot
of
package.
C
C
D
C
Yeah
I
mean
we
still
have
folks
who
I
mean
I,
have
seen
a
lot
of
folks
who
still
argue
that
Python
3
is
one
of
the
worst
decisions
ever
made
and
there's
elements
of
I
I
get
it
at
the
same
time,
I'm
a
little
worried
if
you're
running
code.
That
is
very
obviously
vulnerable
to
all
these
sorts
of
things
that
are
15
years
old.
Unless
those
things
are
literally
like
it's
a
self-enclosed.
You
know
system
that
you
know
nobody
actually
has
access
to
Great
sure
yeah,
keep
it
running.
C
D
C
I
know
we're
at
time
I
think
this
gave
us
I'm
gonna
write
up
some
additional
things.
Put
it
into
probably
a
Google
doc
would
love
to
get
folks
thoughts
on
these
things.
I
probably
want
to
push
this
out
to
the
salsa.
Maybe
specification
and
salsa
positioning
folks
as
well
as
just
like
the
the
biggest
piece
is
more
of.
Should
we
push
this
ahead
like?
Should
we
push
the
standardization,
or
is
this
like
a
a
sicipating
task
here
right,
like
anyway,.