►
From YouTube: SLSA Meeting (August 12, 2022)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right,
we
can
probably
get
started,
as
others
kind
of
join
a
little
later
looks
like
we're
missing
most
of
the
the
google
team
outside
of
well.
The
google
open
source
security
team
today,
so
they
might
have
a
conflict,
but
we
can
probably
get
started
here.
A
So
just
as
a
reminder,
this
meeting
is
being
recorded
and
will
be
uploaded
to
youtube
at
some
point.
After
and
also
your
participation
in
this
meeting
is
an
agreement
to
abide
by
the
open,
ssf
code
of
conduct.
A
Okay,
cool!
Well,
you
know
usually
before
we
start
ask.
If
there's
any
new
folks
who
want
to
introduce
themselves
right
now,
there's
one
new
person.
B
Yes,
I
can
start
so
hi
everyone,
I'm
fredrik
skogman,
I'm
working
with
github,
so
working
on
the
package
security
team,
which
is
mainly
focused
around
certain
areas
of
supply,
chain
security.
B
A
Cool
cool
yeah
glad
to
have
you
and
in
fact,
actually
the
first
item
on
the
agenda
is
gonna,
be
this
so
yeah
just
as
to
go
through
the
agenda
just
very
quickly.
So
the
agenda,
you
know,
usually
what
we've
been
doing,
is
just
kind
of
having
any
initial
discussions
at
first
and
then
we're
kind
of
going
through
and
starting
to
really
try
and
build
a
classification
and
identifying
different
security
tools
in
the
whoops
in
the
in
the
space
for
in
the
salsa
space.
A
We're
also
trying
to
identify
gaps
where
things
hit.
What
level
is
it
something
that
is
generates
the
provenance?
Is
it
something
that
you
know
is
a
builder
that
kind
of
thing,
and
then
you
know
identifying
where
there
could
be
gaps
and
blah
blah
and
then
figuring
out
where,
where
this
team
should
prioritize,
you
know
so
both
from
a
reach
out
perspective,
as
well
as
like
a
hands-on
keyboard.
A
lot
of
the
folks
who
join
these
meetings
are,
you
know,
also
hands-on
keyboard
engineers
and
so
where?
Where
can
we?
A
Actually,
you
know
begin
to
prioritize
some
of
that,
as
we
begin
to
move
towards
salsa
1.0,
but
first
off
wanted
to
sort
of
throw
it
over
to
you
frederick,
a
little
bit
to
talk,
maybe
a
bit
about
some
of
the
mpm
stuff.
You
know
and
based
on
you
know
what
we
said.
Maybe
anything
that
kind
of
related
to
tooling
and
that
sort
of
thing.
B
Sure
so
I'm
not
sure
everyone
is
aware:
maybe
they
are
but
hopefully
are
but
yeah.
So
this
week
this
monday,
to
be
exact,
we
open
up
our
rfc
against
npm
to
offer
a
way
to
create
salsa
at
the
stations
for
your
npm
builds
and
the
primary
way
of
doing
so
for
us
would
be
to
do
it
via
some
crc
the
system.
B
So
you
would
have
like
total
automation
for
everything,
of
course,
and
that
has
part
of
some
really
good
discussions
around
this
and
obviously
for
us.
B
Big
questions
that
we
are
let's
say
facing
or
looking
into
is
exactly
how,
for
instance,
the
provenance
generation
would
be
so
as
an
example,
we
have
been
looking
a
lot
at
the
github
salsa
provenance
generator
from
the
google
open
source
security
team
so
and
that
sort
of
I
think,
ties
in
as
well
with
some
of
this
discussions
in
the
rfc
like
how
does
this
play
along
with
sort
of
the
concept
of
a
trusted
builder?
B
B
In
short,
I
think
that's
where
we
are
like
there's
still
some
discussions
going
on
and
sort
of
trying
to
feel
like
the
interest
from
the
community,
how
it's
being
received,
like,
I
think,
mark,
also
added
a
comment
like
we
probably
should
frame
it
better
in
terms
of
what
are
the
exact
values
that
the
maintainers
are
getting,
because
now
it's
kind
of
more
focused
to
the
consumer
side.
So,
for
instance,
what
value
are
the
npm
users
getting
by
this?
B
Obviously
they're
getting
value
in
in
terms
of
that,
they
can
verify
that
this
packet
was
built
on
a
sort
of
automated
system.
We
can
sort
of
cryptographically
bind
the
source
code
repository
toward
to
this
package,
which
is
not
something
we
can
do
today
so
yeah,
a
lot
of
things
are
are
happening
there
and
the
only
thing
I
can
say
so
far
is
like
the
response
has
been
great.
B
It's
it's
a
lot
of
interaction
from
the
community,
so
I'm
I'm
really
glad
it's,
as
we
have
said,
like
it's
kind
of
pushing
the
limits
of
github
pull
request
view
like
it's
starting
to
be
a
little
bit
slow,
sometimes
so
super
short
intro
on
that,
like
I'm,
I'm
happy
to
discuss
more
like
eggs
or
concrete
questions
like
I
was
talking
a
little
bit.
Maybe
I
can
mention
with
michael
earlier,
like,
for
instance,
we
might
need
to
do
a
better
job
in
terms
of
advocating
salsa
and
explaining
what
it
is.
B
C
Yeah
I
I
was
going
to
make
that
I
didn't
make
it
publicly
in
a
pull
request,
but
I
think,
like
a
probably
in
in
the
intro,
it
might
be
valuable
to
mention
salsa
as
like
a
background
because
effectively
this
is
doing
salsa
for
npm
right.
It's
like
addressing
those
threats.
I
don't
think
it's
like
sufficient.
C
I
think
there's
probably
more
work
to
do,
particularly
in
policy,
which
is
one
of
the
comments
I
brought
up,
and
maybe
we
could
talk
about
that
today,
like
ideas,
but
it
seems
I
talked
to
other
people
also
on
the
call
we
spoke
he
and
I
spoke
earlier
and
it
seems
like
this
is
great
necessary
foundation
and
then,
like
you
know,
as
the
next
step,
maybe
we
could
have.
B
Yeah-
and
I
think
that
it
has
been
discussed
in
in
in
the
pull
request-
like
probably
between
you
and
philip
and
potentially
some
others
like
how
would
we
communicate
the
canonical
repository
for
a
given
package
like
if
it's
just
let's
say
encoded
inside
npm,
an
anniversary
that
have
npm
credentials,
might
actually
change
that,
so
it
might
go
undetected?
Could
we
do
something
too
for
style
like
where
we
only
detect
changes
and
alert
on
that
or
yeah?
It's
a
lot
of
different
questions.
B
There's
because
at
least
my
personal
view
is
like
it
would
be
very
hard
for,
let's
say
a
random
consumer
to
keep
track
of
a
list
of
top
posts
package
and
source
code.
Repository
does
not
scale,
and
it's
not
sort
of
something
you
can
do
and
try
to
build.
You
know
policies
around
that.
I
think
we
need
to
have
something
more,
let's
say,
centralized
or
some
other
way
of
detecting
when
something
is
changing.
C
Yeah
one,
I
don't
know
if
we
want
to
get
into
the
details
now,
so
anyone
feel
free
to
like
say:
let's
show
this
and
move
to
something
else,
but
one
of
the
things
that
like
pizza
and
I
and
others
had
discussed
and
which
I
mentioned
briefly
in
the
pull
request,
is
some
because
I
think
did
were
you
the
one
who
commented
no
someone
else
like
the
notion
of
like
displaying
a
warning
when
the
provenance
changes
a
possible
kind
of
follow-on
to
that
could
be,
for
example,
putting
the
expected
source
repo
in
the
package
log
file,
and
so
that
would
effectively
say
all
future
updates
are
expected
to
come
from
this
repo,
and
if
that
changes,
that
would
be
a
significant
event
that,
like
effectively
you'd,
have
to
make
a
another
commit
to
accept
right,
like
your
team,
would
all
be
saying
we
accept
from
this
repo.
C
You
could
also
imagine
an
organization
like,
let's
say,
a
large
company
as
we
ingest
npm
packages.
Maybe
we
have
our
own
mirror.
You
could
do
the
same
thing
on
every
ingest
like
every
time
you
do
an
update.
You
you
make
you
make
sure
that
the
thing
doesn't
change
and
if
it
does
change
you
make
you
know,
some
central
team
would
make
a
decision
of
whether
it's
okay,
because
you
kind
of
have
the
problem
like
you,
don't
want
all
the
developers
like
having
these
things.
C
And
maybe,
if
we
find
that
it
is
happening,
there
could
be
a
way
for
like
safe
changes.
Like
let's
say
you
do,
move
like
you
rename
your
repo
and
so
that
piece
of
information
or
you
change
providers
you,
you
went
from
like
github
to
get
lab
or
something
like
that.
If
you
have
control
of
both,
you
could
maybe
have
like
a
pointer
or
something
that,
like
kind
of
somehow.
A
C
Like
this
is
a
safe
thing,
because
the
same
party
controlled
both
commits
sort
of
like
when
you
do,
like
those
dns
type
of
verification
like
to
show
that
you
own
a
domain.
Something
like
that.
But
anyway,
those
are
just
kind
of
some
ideas
on
how
how
we
could
do
that.
B
Yeah-
and
I
think
it's
interesting
that
you
mentioned
the
dns
thing,
because
I
think
you
mean
like,
for
instance,
when
you're
asked
to
put
up
a
specific
text
record
with
a
let's
say,
a
cryptographic
hash.
I've
had
sort
of
a
similar
idea
in
terms
of
like
create
this
branch,
and
then
you
have
like
a
uuid
created
by
the
repository,
and
then
you
create
that
branch.
And
then
you
can
prove
that
you
are
sort
of
in
control
over
the
source
code
repository.
D
C
A
Yeah
this
is
yeah.
This
is
awesome
yeah.
I
think
there's
definitely
a
lot
there
that
I
think
we
should
oh
mark.
A
Oh
yeah,
no,
I
was
just
gonna,
say
yeah,
I
mean
I
think
that
there's
probably
there
like
there's
some
tools
that
are
already
actually
out
there.
That
might
be
able
to
help
here,
there's
some
tools
that
I
know
that
are
being
built
out
around.
You
know
some
of
these
things
to
kind
of
like
you
know
where
you
might
have
additional
sort
of
records
for
these
sorts
of
things
right
where
it's
like
hey.
We
know
that
this
person's
in
charge.
You
know
this
key-
is
in
charge
of
this
repo.
A
So
if
they
sign
a
thing,
then
you
know
maybe
that
hey
it's
it's
changed
or
whatever.
There's
there's.
Definitely
a
lot
of
things
kind
of
moving
along
on
that
end,
but
I
think
this
is
is
a
real,
real,
concrete
use
case
here
that
I
think
you
know,
as
we
kind
of
continue
on
with
some
of
the
stuff
that
we're
looking
at,
can
definitely
help
sort
of
shape
where
the
the
tools
should
go.
A
That
was
it
mark.
C
B
Yes,
it's
deliberately
kind
of
loose
on
that,
then,
because
we
think
it
would
create,
let's
say
too
much
put
it
unnecessary
discussions.
I
think
we
are
more
interested
now
in
kind
of
by
getting
buy-in
of
the
concept
so
yeah
for
for
public
npm
packages.
They
will
definitely
be
stored
on
record
because
we
will
rely
on
that
to
publish
actually
two
at
the
stations
one
build
at
the
station
and
one
released
at
the
station
from
the
registry.
B
Pretty
much
saying
hey,
I
actually
approved
publish
for
this
package,
and
otherwise
we
will
store
the
data
station
certificate
and
everything
like
that
in
the
npm
register
itself.
So
it
could
be
sort
of
queried
in
banned
as
part
of
getting
package
metadata
exactly
how
we
are
still
kind
of
working
on,
because
I
think
the
average
number
of
dependencies
for
an
npm
package
is
700.
So
we
need
to
have
a
pretty
efficient
way
of
dealing
with
that,
for
instance,
hitting
recourse
700
times
per
dependency
would
not
scale
so
but
yeah.
B
We
are
working
on
that
and
related
to
that.
I
opened
an
issue
against
cosine
in
terms
of
trying
to
standardize
a
format
on
how
to
ship
this
envelope
certificate
and
the
recruiter
together,
because
now
you
I
mean
yeah
in
cosine,
with
oci
manifest
you
can
sort
of
you
can
make
it,
but
that's
sort
of
where
tied
to
container
and
signature
and
sort
of
the
oci
format.
B
So
what
I
would
like
to
see
as
well
is
sort
of
a
format
that
could
be
reused
across
multiple
ecosystems,
and
there
is
a
similar
initiative
for
capturing
blog
signatures
from
cosine,
and
I
think
the
thing
the
way
we
are
proposing
it.
We
can
actually
accommodate
for
their
needs
as
well.
So
probably
we
can
have
like,
let's
say
one
more
flexible
data
format
for
for
capturing
and
signatures
and
other
data
as
well
coming
from
cosine.
B
So
so
our
proposal
probably
will
look
something
like
the
data
format
in
the
issue,
and
then
that
would
be
sort
of
queryable
and
postable
to
the
npm
registry
and
and
once
we
get
more
traction
of
this,
we
will
of
course
make
everything
public,
because
we
would
like
other
package
system
as
well
to
be
able
to
implement
the
same
interfaces.
So
we're
not
trying
to
lock
down
anything
like
that.
It's
more
like
we're
trying
to
get
community
buy-in
as
a
whole
on
this,
not
just
from
npm,
but
also
from
six
store
and
other
players.
C
Yeah,
I
I
agree,
I
think
that's
a
good
model
also
because
you
don't
want
to
add
like
another
just
for
reliability.
You
don't
want
to
have
to
add
another
like
failure
domain
right,
if,
if
you're
already
relying
on
the
npm
storage
system,
then
if
you
store
it
there
then
you're
not
having
to.
B
Exactly
and
that's
for,
for
the
signing
part
or
the
publishing
part,
it
has
only
been
sort
of
raised
as
a
potential
concern
like
hey.
You
are
starting
to
rely
on
on
a
third
party
here
to
sort
of
gate
publishing
is
that
bad
and
we
don't
think
it
is
like
public
good
six
stories
aiming
for
three
nines.
If
I'm
not
mistaken,
and
I
think
that's
sort
of
pretty
good
like
you
can
republish
it,
it's
definitely
much
worse
to
depend
on
that
during
install.
C
Agreed,
I
I
don't
know
how
much
time
I
want
to
spend
here,
but
one
other
thing
I
was
just
kind
of
curious
about
much
much
longer
term
is
reproducible
builds.
I
think
someone
brought
it
up
on
the
thread
on
the
rfc,
because
if
you,
if
a
significant
number
of
npm
packages
are
reproducible,
then
effectively,
you
could
like
not
have
to
trust
any
particular
vendor,
and
even
you
could
build
it
on
your
local
machine
and
then
just
have
the
rebuilds
happen
on
various
services.
Have
you
thought
about
that
at
all.
B
B
So
it
is
a
bit
complicated
and
you
also
have
post
install
hooks,
which
means
that
after
you
have
done
npm
installed
for
a
dependency,
it
can
actually
execute
a
script
so
yeah
we
have
thought
about
it,
but
I
probably
can't
give
you
a
better
answer
right
now.
In
terms
of
that,
it's
complicated,
I
would
say.
A
So
I
know
for
at
least
some
packages
it's
mostly
source
in
is
package
out,
so
for
those
I
think
it's
a
little
easier,
but
I
I
do
think
that
there's
also
something
that
that
probably
needs
to
make
sure
that
is
is
definitely
sorted
out
in
the
provenance
is
those
sort
of
install
script
pieces
because
I
know
that's
kind
of
one
of
one
of
the
common
attack.
A
Vectors
is
hey,
I
you
know,
run
a
script,
steal
your
secrets
and
you
know,
and
so
I
think
we
want
to
make
sure
that
you
know
it's.
Those
are
those
sorts
of
things
are
included
in
the
provenance.
So
if
we
ever
need
to
go
back
in
audit,
we
can
go
and
say.
Oh,
this
is
weird.
This
is
not
the
install
script.
I
thought
it
was
going
to
be
or
whatever
but
separately.
A
I
don't
want
to
change
topics
too
much,
but
I
know
that
one
of
the
things
that
was
also
sort
of
kind
of
as
we
started
going
through
there
there's.
Definitely
this
thing:
that's
starting
to
grow
in
the
tool
it
from
a
tooling
perspective
for
salsa
is
how
do
we?
A
How
do
we
start
to
build
this
sort
of
web
of
trust
around
builders
right?
So,
like
hey,
I
probably
trust
github
actions
as
a
tool
to
build
my
stuff.
I
trust
you
know.
Github
has
a
lot
to
lose.
If
they're,
you
know
not
secure,
whereas
you
know
mike's
personal
builder,
that
he's
running
on
his
laptop,
probably
not
right,
but
at
the
same
time
we
we
might.
You
know,
as
this
kind
of
begins
to
evolve
like
there
could
be
also,
you
know,
different
open
source
groups
that
are
like
hey
look.
A
Github
actions
is
not
going
to
work
for
us
because
we
need
builders
on
arm
and
we
need
builders
that
do
this
and
the
other
thing-
and
this
is
kind
of
slightly-
goes
beyond
necessarily
just
purely
the
npm
thing,
but
I
think
npm
thing
is
sort
of
opening
up
the
bigger
picture
for
how
this
might
just
work
for
other
packages
and
software
in
general.
A
So
I
was
wondering
if
you
had
sort
of
given
thought
of
like
what
federation
might
look
like.
If
you
know
somebody
said
great,
we'll
we'll
use
github
as
the
oidc,
but
we
still
want
to
be
able
to
say
great.
This
system
is,
you
know,
represented
here
as
github.
Somebody
has
attested
that
that,
let's
just
say
service
account,
it
actually
represents.
A
B
So
yeah,
I
think,
you're
mentioning
a
few
interesting
things,
because
our
thinking
has
gone
sort
of
beyond
just
github
actions.
We
have
kind
of
fought
up
in
the
in
the
terms
of
like,
let's
say,
npm
or
open,
ssf
or
whoever
it
might
be
kind
of
providing
a
set
of
let's
say,
audited
and
trusted
reusable
workflow,
which
sort
of
take
takes
it
beyond
just
being
able
to
build
on
github
actions.
B
You
actually
have
a
workflow
that
you
typically
won't
have
access
to
and
try
to
sort
of
think
of
policies
around
that
so,
for
instance,
npm
or
some
other
organization
could
say,
hey
these
five
reusable
workflows
in
github
and
these
three
orbs
in
circle
ci
and
these
reusable
pipelines
in
github,
for
instance.
Those
are
sort
of
trusted
and
npm.
Officially
will
only
trust
those
for
let's
say
if
you
are
adding,
let's
say
the
the
highest
security
flag.
B
So
those
that
is
sort
of
one
way
we
that
we
have
thought
about
it
like
and
obviously
we
will
sort
of
work
with
other
providers
in
terms
of
creating
those
sort
of
reusable
build
components
where
it
might
be.
You
know,
orb
or
something
else.
B
I
think
that's
sort
of
the
first
step
that
we
have
been
thinking
about
and
I
think
it's
kind
of
vague
in
the
rfc,
but
that's
sort
of
what
we
are
probably
going
to
aim
for,
because
I
think
that
simplifies
policy
writing,
because
we
know
so
these
builders
are
doing
for
the
correct
things
when
it
goes
beyond
that,
for
instance,
as
you
mentioned,
like,
let's
say,
jenkins,
build
form
running
somewhere.
B
We
haven't
talked
too
much
in
detail
right
now.
We
have
been
kind
of
focusing
around
the
ci
system
that
sort
of
are
capable
of
producing
their
own
json
web
tokens
or
open
id
connect
id
tokens,
mainly
because
we
are
kinda
sort
of
piggyback
on
the
capabilities
provided
by
full
cio.
B
So
I
think
that's
sort
of
where
we
are
now.
We
are
definitely
open
to
more
suggestions
in
terms
of
let's
say,
yeah,
a
kind
of
example
you
you
gave
on
a
jenkins
for
or
or
some
tecton
cluster
that's
trusted,
and
we
have
some
entity
that's
sort
of
interested
in
attesting
to
it
in
in
some
kind
of
way
we
won't
prob,
I
mean
to
take
the
other
extreme.
We
probably
won't
deny
anyone
to
publish
whatever
provenance
they
have
and
so
because
I
still
think
a
lot
of
the
policies
will
differ
for
different
consumers.
B
For
instance,
a
large
corporation
might
have
their
reusable
workflow
managed
by
their
policies
in
github,
and
they
are
trusting
that
so
so
I
don't
think
we
should
take,
let's
say
too
tight
or
make
it
too
tight,
because
we
can't
understand
what
the
customer's
policies
might
look
like,
but
we
can
aim
for
open
source
and
say
hey.
These
are
what
we
think
are
good
builders
for
running,
let's
say
a
random
open
source
project.
But
then
again
you
cannot
write
as
you
wish,
because
you
in
the
end
know
what
you
would
trust.
A
Cool
yeah
yeah.
I
just
wanted
to
throw
that
out
there,
because
I
know
one
of
the
conversations
from
the
open
ssf
side
is
potentially
via
their
alpha
omega
project,
hosting,
let's
say
a
techton
cluster,
or
something
like
that
with
the
right
policies
and
yaya
and
potentially
building
open
source
tools.
You
know
that
you
know
something
like
github
actions
is
just
not
adequate,
for
you
know
like
some
sort
of
complicated
custom
sort
of
thing,
yeah.
B
I
mean
the
rendering
concept
here
is
obviously
something
that
has
been
sort
of
criticized
in
in
this
pull
request
and-
and
I
think
for
now
we
are
kind
of
looking
at
what
options
do
we
have
right
now
and
what
options
would
we
have?
Let's
say
in
the
near
future,
which
I
think
would
be
a
circle
and
gitlab.
A
Cool
any
oh
mark.
C
Yeah,
I
I
think
it
kind
of
circles
back
to
the
reaper.
In
my
mind,
the
reproducible
build
thing
that
if
there
is
concern
around
you
know
having
to
trust
any
one
vendor,
I
think
reproducible
builds
and
establishing
a
convention
around.
That
seems
like
a
promising
path.
I
don't
know
if,
if
anyone's
done,
like
research
on
like
in
practice,
how
many
packages
are
reproducible,
I
know
we
did
some
in
for
python
and
of
the
top
hundred
by
download.
C
Someone
was
able
to
reproduce
like
a
good
fraction
like
70
percent
or
something
like
that,
which
is
a
pretty
big
chunk
and
that's
like
with
no
work
at
all
from
the
maintainer
side.
So
if
there's
like
a
large
number
of
ones
that
are
trivial,
as
michael
said
or
like
straightforward
or
like
use,
standard
tools
or
ones
where,
like
the
maintainer
is
like
super
like,
oh,
I
don't
want
to
use
any.
You
know
a
commercial
vendor
if
they
put
in
the
work
to
make
it
reproducible.
C
B
One
thing
that
we
have
sort
of
discussed
briefly
is
that
yeah
I
mean
you
have,
let's
say,
install
scripts
or
sorry
post
install
hooks
and
you
have
other
things
that
can
execute
as
part
of
a
build.
We
have
just
have
like
super
brief
discussions
in
in
terms
of
like
is
the
problems
generator
somehow
could
sort
of
sort
of
intercept
and
potentially
attest
that
this
package
did.
That
did
not
run
any.
B
Let's
say
script
coming
from
outside
of
the
repository
as
an
example,
and
we
haven't
sort
of
got
into
the
weeds
yet
but
kind
of
discussing
like
would
that
be
possible,
but
that's
something
we
can
rely
on
and
potentially
sort
of
add
some
information
that
is
signed
that
could
be
trusted
and-
and
I
think
that
would
help
sort
of
taking
it
to
a
state
where
it
can
be.
Reproducible,
reproducible,
buildable,.
A
Yeah,
actually
that
was
something
I
was
just
about
to
ask
there
because,
like
I
think,
when
it
came
to
reproducible
builds,
it's
always
been
about
the
package.
But
if
the
package
itself
on
installation
is
not
necessarily
deterministic
right
like
it
could
be
doing
an
unbounded
set
of
things
on
installation,
you
know
that
could
obviously
I
think
that
that's
an
interesting
one
to
to
sort
of
think
about,
because
yeah
a
lot
of
package
managers,
just
sort
of
say,
yeah.
No,
no,
you!
A
You
can
only
install
these
files
in
these
places
and
that's
all
it
does,
and
then
I
know,
for
you
know:
good
use
cases
like
hey
npm,
maybe
goes
out
and
also
does
like
a
gcc,
and
you
know,
compilation
of
another
thing
or
or
pulls
down
some
other.
A
A
I
think
that
that's
an
interesting
thing
that
I
don't
think
we
had
considered
in
salsa
of
like
what,
if
the
the
artifact
that's
being
built
itself,
if
it's,
let's
say
a
package,
if
that
sort
of
does,
if
it's
installation
isn't
you
know,
it
can't
be
reasoned
about
easily.
B
Yeah
and
that's
something
I
think
we
probably
should
start
to
take
sort
of
to
discussion
to
the
npm
cli
team
as
well
to
kind
of
see
what's
happening
there
like
or
there's
something
from
from
their
perspective,
that
they
can
do,
for
instance,
but
yeah.
I'm
not
aware
of
then.
Let's
say
we
real
discussions
happening
here.
C
I
a
quick
follow-up
on
the
earlier
question
around,
like
certification
of
builders,
part
of
the
rfc
was
around
having
like
some
sort
of
verified
badge
within
the
website.
Would
that
can
you-
and
you
also
said
like
people
could
upload
whatever
provenance?
I
I
fully
support
that.
Actually,
I
fully
support
both
things
is
the
notion
that
npm
would
maintain
some
list
of
builders
that
get
the
verified
badge
and
other
ones
would
basically
just
be
called
unverified
or
something
like
that.
B
I
can't
give
you
let's
say
complete
or
or
authoritative
answer
here,
but
my
intention
or
my
understanding
is
that
if
we
see
a
provenance
from
something
trust
by
let's
say
fulso,
we
we
give
you
this
verified
badge.
It
doesn't
have
to
come
from,
let's
say
a
trusted
builder
or
a
reusable
workload,
it's
more
like
if
we
see
signed
provenance
by
an
authority.
We
trust
we
give
you
the
signed
bench.
That's
my
understanding,
but
I'm
not
100.
C
Yeah
because,
like
the
you
know,
the
part
of
salsa
is
having
it's
not
a
boolean
thing,
but
a
system
of
levels
of
like
how
trustworthy
it
is,
and
so
that's
maybe
some
worth
something
to
think
through
a
bit
more
of
like
what
level
like.
Is
it
if
it's
just
signed
by
anyone
with
an
oidc
that
provides
no
dc
token?
Is
it
something
where
there's
some
like
guarantee
that
it
can't
be
forged
and
somehow
level?
Three?
C
I
also
by
the
way,
filed
a
a
github
issue
in
the
salsa
repo
asking
whether
we
would
consider
like
the
effectively
the
the
the
option,
one
where
the
npm
client
does
the
generation
of
the
providence,
whether
that
would
meet
salsa
3
or
not.
C
B
Yeah
so
yeah.
That
is,
I
think,
it's
an
interesting
sort
of
topic
to
to
bring
up,
and
our
thinking
has
been
very
much
around
kind
of
what
you
mentioned
like.
How
would
the
provenance
be
generated
and,
for
instance,
would
you
be
able
to
to
falsify
buy
something
of
it
and
yeah?
B
I
think
it
resonates
very
well
with
sort
of
this
signed
badge,
because
if
we
are
too,
let's
say
sloppy
in
in
terms
of
verification
of
that
it
might
give
the
consumers
a
false
sense
of
security,
because
they
are
seeing
this
badge
and
and
like
let's
say
the
difference
between
salsa
level,
2
and
salsa
level.
3
is
something
we
have
kind
of
discussed
as
well,
because
our
intention
was
to
take
take
it
to
salsa
level
3.
B
But
my
personal
opinion
is
that
we
as
npm
or
github,
cannot
attest
because
of
their
flexibility
in
the
npm
build
commands.
We
can
give
you
the
platform
and
you
as
a
maintainer
can
say:
hey
here's
the
proof
that
my
repository
does
only
let's
say
build
from
sources.
Insider
repository,
so
I
can
say
we
are
salsa
free
by
virtue
of
this
thing
being
signed
by
gita,
but
github.
B
C
A
Cool
any
other
questions
otherwise
or
topics
regarding
that,
otherwise
we
can
kind
of
move
on
to
some
of
the
gap
identification
stuff
as
long
as
as
well
as
sort
of
just
identifying
where
we
should
be
prioritizing.
A
Cool
so
a
lot
of
good
stuff
there.
So
let
me
just
quickly
share
my
screen.
D
A
So,
just
a
for
those
who
are
new
or
those
that
you
know
just
as
a
reminder,
you
know,
we've
been
sort
of
filling
out
sort
of
current
tooling
and
gaps
looks
like
naveen
isn't
on,
but
he
was
going
to
sort
of,
I
believe,
create
start
to
create
kind
of
like
a
mapping
for
some
of
this
stuff
so
that
we
can
start
to
kind
of
see
you
know
one
is
we
have
different
categories
of
tools,
you
know
build
in
production,
distribution
and
discovery,
verification
and
decisioning,
so
that's
kind
of
like
the
policy
stuff.
A
We
also
wanted
to
kind
of
maybe
just
highlight
some
of
the
training
or
you
know
push
on
the
other
tool
providers
to
provide
more
as
far
as
like
getting
started
and
then
also
different
things
like
you
know,
other
tooling,
that
is
related,
but
not
necessarily
directly
in
salsa
so
stuff,
like
hey
s-bomb,
you
know
that
if
we're,
let's
say
assuming
we're
keeping
the
two-person
pr
at
some
level,
you
know
hey
what
sorts
of
things
like
from
from
that
end
like.
A
How
do
we
verify
that
those
sorts
of
things
some
other
tools
there
and
then
also
like
what
are
tools
that
currently
exist
today
that
especially
builders
that
might
be
that
might
have
gaps
or
are
otherwise?
You
know,
potentially
big
tools
like
jenkins
and
like
hey
jenkins,
is
still
not
going
away.
So
have
folks
thought
about
this.
I
believe
I
I
was
at
some
meeting
or
other,
I
think,
was
at
the
cd
foundation.
Somebody
is
making
a
couple
of
jenkins
plugins
to
try
and
track
salsa
providence.
A
There's
some
open
questions
because
of
jenkins
sort
of
security
model,
whether
like
how
how
much
they
can
kind
of
get
there.
But
that's
something
that's
being
sort
of
discussed
and
there
was
like
you
know.
Billboard
was
another
one,
but
if
there's,
if
other
folks
have
additional
tools,
you
know
feel
free
to
put
in
there-
and
you
know
next
week-
hopefully
we'll
have
some
sort
of
better
mapping,
whether
it's
in
a
google
sheet
or
actually
like.
I
guess
we're
gonna
push
it
into
github
but
yeah.
A
So
we
have
a
bunch
of
tools
here.
We've
been
identifying.
Some
of
the
gaps
want
to
kind
of
continue
through
identify,
maybe
some
more
gaps
and
maybe
just
identify
where
some
folks
wanted
to
focus
focus
their
effort
on
sound
good.
Anything.
A
D
A
Feel
free
to
add
stuff
as
well,
but
so
probably
makes
sense
to
split
this
up
into
both
service
and
software,
because
some
of
these
things
are
hey,
the
github
generator
only
works
on
github
actions.
So
well.
I
guess
it
could
work
potentially
on.
A
A
Cool
any
other
sorts
of
things,
any
other
categories
or
gaps
or
anything
like
that.
Otherwise,
we
can
move
straight
to
prioritization.
A
For
my
design,
internet-
oh
so
yes
yeah!
This.
B
A
I
think
you're,
aware
of
yeah
yeah,
so
just
for
that
one,
hopefully,
by
early
next
week,
we'll
have
fix
the
recore
bug
which
right
now
there's
a
bug
in
record
that
doesn't
actually,
if
you
have
an
attestation
that
doesn't
actually
include
the
signature
with
the
attestation.
It
includes
the
key
and
includes
like
essentially
a
stamp
that
hey
this
was
signed,
but
it
doesn't
actually
include
the
signature
which
makes,
unless
you're
literally
keeping
the
signature
alongside
the
package,
which
obviously
that's
the
ideal
situation.
A
But
if
you're
not
there's
no
way
to
actually
verify
it
from
the
recoil
side,
so
that
should
hopefully
be
fixed
by
part.
The
salon,
by
mostly
parth
in
the
next
couple
of
days.
B
Sending
sorry
when
you're
sending
a
dc
envelope
with
a
yes
station,
yes
yep.
A
Yep
so
that
should
hopefully
be
sorted
out
and
then,
in
addition
to
that,
there
is
a
pull
request
that
I've
had
open
since
january.
That
also
actually
adds
that
as
a
cosign
command.
So
you
could
do
like
cosign
a
test
blob
and
you
know
it
will
output
it
as
a
file
as
well
as
output
it
to
recore.
A
C
Other
gaps
or
areas
should
there
be
a
category
on?
I
don't
know
if
this
is
tooling
or
like
adoption,
but
like
integration
into
systems
like
npm.
C
You
know
I
mean
like
there's:
there's
the
build
support,
distribution
of
provenance
and
root
and
and
discovery
and
root
of
trust
and
all
those
things
all
right
reaching
into
the
package
manager
and
then
verification
at
use.
Time
like
kubernetes,
is
kind
of
fundamentally
different
than
integration
npm,
because
npm
is
about
one
specific
package,
whereas
kubernetes
is
like
an
environment
of
where
multiple
packages
are
used.
A
Yes,
so-
and
it
probably
maybe
makes
sense
to
sort
of
maybe
have
it
stated
both
ways
then
like
hey,
one
is
oci,
but
then
one
is
the
tools
that
consume
oci,
and
so
one
is
like
npm
as
the
package
manager.
Like
sorry,
one
is
npm
as
a
package
registry
might
contain
this
information
and
then
the
other
is
the
tooling
that
can
then
pull
that
down
and
verify.
Or
do
you
think
that
we
should
just
sort
of
take
this
and
move
it
down
to
something
like
package
integration.
C
C
D
Yeah
yeah,
I
think
again
this
when
we're
talking
about
the
package
managers.
I
think
it
would
be
really
useful
to
have
a
generic
discovery
mechanism
for
attestations,
because
we
don't
really
want
every
package
ecosystem
to
have
to
implement
these
that
for
themselves.
D
If
there
is
a
general
public
that
we
can
use
of
soldier
salsa
adam
stations
for
artifacts,
it
makes
more
sense
for
them
to
integrate
against
that
than
it
does
for
everyone
to
generate
their
own
mechanism
for
doing
that
and
so
yeah.
I
think
I'd
like
to
try
and
focus
on
on,
as
I
said
before,
try
and
focus
on
discoverability
for
attestations
before
we
kind
of
charge
into
doing
outer
station
verifications
in
package
managers.
A
So
yeah
there's
a
couple
things
there.
One
is
ideally
like
just
to
be
clear
like
ideally,
we
should
have
package
managers
that
can
support
it,
but
I
do
think
that
it's
not
it's
not
a
deal
breaker
and
it's
also
not
necessarily
like
something
we
should.
You
know
rely
on
in
the
short
term
right
because,
like
as
multiple
people
are
kind
of
pointed
out
in
the
comments
it's
it
just
makes
a
lot
of
things
easier.
A
If,
like
hey,
when
I
pull
down
the
package,
I'm
also
pulling
down
the
associated
attestation,
I
don't
need
to
make
a
bunch
of
different
requests,
but
with
that
said,
some
of
us
between
google
kusari
purdue
university
and
some
other
folks
are
building
some
of
that
out
now,
to
kind
of
like
go
through
scan
record
scan,
oci
and
package
registries
pull
all
of
those
attestations
into
something
that
is
queryable,
so
you
can
maybe
make
some
of
those
requests
and
then
also
do
stuff.
A
Like
hey,
I
pulled
in
the
package,
and
maybe
the
package
is
like
essentially
like
a
flat
pack
and
it's
everything
cool.
I
pulled
in
an
attestation
for
the
actual
building
of
the
flat
pack
and
then
I
pulled
in
attestations
transitively
for
all
the
things
that
that
pulled
in
you
know
and
included
in
there,
which
which
could
be
useful.
But
I
think
that's
gonna,
take
some
time
to
build
out
mark.
C
Because,
like
you
could
show
value
and
you
could
buy
progress
without
having
to
get
like
on
board
and
you
could
kind
of
prove
out
ideas
without
actually
making
like
major
changes,
but
then
simult
like
we
will
also
want,
I
think,
an
integration
into
specific
into
all
the
ecosystems,
because
without
that,
I
don't
think
you
could
get
like
the
reliability
and
security
you
need,
like
we
talked
about
before,
like
having
provenance
stored
within
npm,
is
valuable
for
a
reliability
perspective
because,
like
you,
don't
have
to
rely
on
this
like
additional
service.
C
D
I
think
that's
true,
but
yeah
I'd,
like
you
know,
even
if
it's
just
a
specification
of
where
a
companion
file
lives,
red
lives
perspective
to
its
to
the
actual
package,
I
mean
that
might
be
enough
to
start
with
is
just
saying:
okay,
if
you
have
an
attestation
or
a
given
package,
it
will
be
called
this
and
it
will
be
co-resident
if
that
would
be
enough
to
get
started
and
get
all
the
package
managers
kind
of
with
able
to
do
something
fairly
straightforward
straight
away,
and
so
we
can
start
the
experimentation.
D
Now
we
could
just
say
if
you've
got
a
package
called
nokogiri.gem,
your
attestation
will
be
called
nokogiri.intoto.jsonl
and
it
will
be
in
the
same
directory,
something
like
that
and
we
could
just
make
that
kind
of
a
not
even
a
standard.
Just
overall
people
could
start
integrating
against
that
and
package
managers
could
start
using
it.
So
it
doesn't
have
to
be.
You
know
this
big
glorious
transaction.
D
B
In
the
linked
issue,
or
that
we
talked
about
where
we
were
talking
about
how
to
distribute
certificate,
rick
or
bundle
and
and
and
this
envelope
I
kinda
alluded
to
as
well
like-
I
think
the
follow
up
on
that
should
probably
be
to
sort
of
define
or
try
to
at
least
define
like
a
query
model
for
it.
So
we
can
have
sort
of
good
interoperability
between
different
package
managers,
so
each
one
doesn't
look
and
feel
the
same.
B
Sorry
look
and
behave
very
differently
because
I
think
in
the
end,
the
actual
transactions
are
most
likely
fairly
trivial,
for
instance,
upload
something
against
a
specific
shot.
I
just
download
here's
a
list
of
shot
digests
where
I
would
like
to
see
at
stations
for
so
I
think
in
the
end,
it
shouldn't
be
too
controversial
to
try
to
define
or
standardize
an
api
around
it
as
well.
D
Sense:
okay,.
A
A
Okay,
so
now
I
guess
we
can,
with
the
rest
of
the
time
we
can
just
sort
of
go
over,
maybe
where
people
want
to
focus
their
time
on
or
if
there's
anything
that
like
and
to
be
clear
like
outside
of
like,
where
should
this
group
focus
its
its
efforts
on
right
now
is
kind
of
the
the
goal
here
right,
like
a
lot
of
us,
are
kind
of
probably
related
to
some
of
these
projects
at
some
level
or
another.
A
But
where
do
folks
think
is
like
just
generally
like
hey?
This
is
a
big
gap
and
as
we
move
towards
1.0,
it
has
to
be
addressed.
C
I
guess
I
can.
I
don't.
C
Effort,
let's
say
it
takes,
but
would
be
the
packaging
ecosystem
thing
like
it's
great,
that
npm
is
effectively
kind
of
going
first
and
setting
an
example
for
the
builders.
We
have
an
example
like
the
github
actions
thing
of
like
here's,
how
we
could
do
it
and
then
so
that
allows
us
to
kind
of
replicate.
C
We
don't
yet
have
an
implementation
of
like
how
this
would
work
in
a
real
packaging
ecosystem,
and
so
that,
I
think,
is
a
kind
of
a
big
gap,
particularly
around
the
policy
piece,
because
even
in
the
rfc
that
it
doesn't
really
address
that
piece
of
like
how
do
you
ensure
that
it's
built
from
the
right
source
repository?
C
I
don't
know
if
that's
to
me
in
my
mind,
that
is
the
biggest
gap.
That's
like
unclear
of
how
it
would
work.
B
Yeah,
I
would
probably
be
inclined
to
agree
that
sort
of
the
story
around
verifying
it's
the
canonical
repository
for
this
package
is
it's
a
big
issue
for
us
like,
as
we
mentioned
earlier,
the
thing
what
I
think
the
best
we
can
do
is
say
this
is,
let's
say,
a
trusted
builder
by
npm,
and
so
you
can
at
least
trust
it,
but
is
it
actually,
let's
say
the
canonical
repository
for
it
yeah?
We
can't
really
tell
you
about
that.
Yet.
A
So,
just
to
kind
of
maybe
quickly
go
through
then
so
I
mean
it
does
sound
like
for
the
most
part,
we
have
a
lot
of
stuff
from
the
build
and
production
side
that
can
at
least
generate
salsa
provenance
relatively
reliably.
There
might
be
a
couple
of
gaps
here
and
there
on
exactly
what
level
these
things
can
reach,
but
that
seems
to
be
maybe
doesn't
sound
like
potentially
a
huge
priority
then
compared
to
maybe
some
of
the
stuff
here
around
like
a
lot
of
folks
are
mentioning
hey.
A
If
I
can't
discover
the
the
the
provenant
you
know,
if
I
don't
know
where
the
providence
lives,
then
or
if
I
don't
have
access
to
the
province
or
whatever,
how
good
is
it
for
me?
I
like
what
good
is
it
to
me?
A
So
it
sounds
like
maybe
something
like
this
is
important,
as
especially
with,
and
then
some
of
the
other
things
I
think
are
related,
like
that's
been
kind
of
brought
up
before
is
like
how
do
I
know
what
identities
I
should
be
trusting,
there's
potentially
that
sort
of
like
web
of
trust
as
well
of
like
hey,
you
know
if
it's
going
through.
A
Let's
say
npm
here
are:
maybe
certain
things
that
some
you
know,
I'm
just
gonna
you
know
like
here
are
the
100
core
packages
that
npm
itself
is
saying:
hey,
we
think
they've
done
the
right
things
or
somebody,
a
third
party,
google,
says
yep.
We
think
they
did
the
right
things
or
something
like
that.
I
don't
know
how
we
want
to.
Like
kind
of.
I
think
that
sort
of
thing
is
a
big
gap
of
like
how
do
we
describe
that
and
how
do
we
kind
of
talk
through
the
you
know?
A
How
do
we
sort
of
figure
some
of
those
things
out
for
the
verification
piece?
I
know
that
there
is
a
good
deal
of
like
policy
managers
or
sorry.
You
know
admission
controllers
policy
managers
that
are
starting
to
do
these
sorts
of
things,
but
that
can
also
go
in
and
like
a
lot
of
these
can
arbitrarily
read
json
so
you're,
just
like
okay,
great
I've
been
at
a
station.
A
Here's
a
you,
know,
here's
this
thing
and
I
can
look
at
you
know
here-
are
the
list
of
trusted
builders
and
assuming
that
the
person
on
the
other
side
is
not
lying
to
me,
then
you
know
if
I
know
if
I
see
that
it
was
built
with
this
builder
and
I
trusted
okay,
that's
something
that
I
include
in
the
thing
that
I'm
seeing
actually
maybe
that's
a
gap
then,
and
keep
me
honest
here-
is
this
sort
of
like
how
it
integrates
then,
with
the
package
ecosystem
of.
A
If
I
want
to
run
npm
install,
I
should
be
able
to
have
you
know,
and
I
don't
honestly
remember
the
mpm
config
file,
but,
like
my
global
npm,
config
file
might
have
a
policy
associated
with
it.
Saying
hey.
You
know,
like
only
look
for
things
that
have
salsa
2
and
that
have
these
list
of
trusted
builders,
otherwise
don't
allow
it
to
install
that,
and
I
don't
think
that
sort
of
thing
is
is
really
kind
of
being
addressed
here,
and
some
of
the
stuff
in
here
are
like.
A
I
think
a
lot
of
things
in
here
at
least,
are
very
specific
to
sort
of
like
you
want
to
install
something
to
kubernetes,
okay,
cool.
This
is
how
we
look
we'll
pull
down
the
container,
and
this
is
how
we
look
at
it
and
so
on.
So
that
seems
to
be
a
big
gap
and
then
the
other
stuff,
I
think
is,
is
you
know
we
don't
need
to
really
worry
about
right
now.
Mark.
C
Yeah,
it
seems
like
the
coming
back
to
use
cases
if
we
think
about
there's
like
third
party,
particularly
open
source
use
cases
and
then
first
party
a
lot
of
the
things
there
like
kyberno
and
gatekeeper
or
more
findersync
focused
on
first
party
code
of
like
how
do
I
ensure
that
my
code
was
built
according
to
my
processes
and
you
kind
of
know
what
the
policy
is,
whereas
with
the
packaging
ecosystem,
and
maybe
that's
one
way
to
slice,
it
is
more
around
the
like
a
third-party
code
of
like
I
don't
even
know
what
the
source
repository
was
supposed
to
be,
and
how
do
I
manage
trust
from
like
all
these
other
external
parties.
A
C
A
Oh
sorry,
yeah.
I
think
that
that
that
that's
a
good
point
I
I
will
sort
of
caveat
a
little
bit
of
that
like
so
so.
Keeverno
can
still
be
used.
For
example,
if
people
are
publishing
their
their,
let's
say
an
oci,
their
publishing
their
images
in
oci
and
and
their
attestations
in
oci.
You
can
say
great
here-
are
the
list
of
keys.
I
trust
like
so.
A
For
example,
we
do
this
with
fresca
right
where
we
say
we
trust
code
coming
from
the
tecton
team
signed
by
the
tekton
key
right,
and
so
we
don't
allow
like.
If
we
pull
in
a
random
techton
and
it's
not
signed
by
the
tecton
team,
you
know
we
don't
actually
run
that,
even
though
it's
technically
third
party
code-
and
so
we
we
can
do
that
a
little
bit
there.
But
I
think
you
do
bring
up
a
good
point
because
there's
also
stuff
of
hey.