►
From YouTube: SLSA Meeting (November 2, 2021)
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).
B
Yeah
happy
wednesday
so
kim,
who
usually
facilitates
the
meetings,
is
says,
she's
going
to
be
either
late
or
might
not
be
able
to
make
it
at
all.
I
guess
I
I
sort
of
noticed-
and
I
guess
I
volunteered
to
facilitate
for
today,
unless
somebody
else
wants
to
take
it.
But
okay,
I
guess
we
can
give
it
like
another
minute
or
so
for
a
few
more
folks
to
join,
and
then
we
can
get
started.
Sound
good
sounds
good
thanks.
A
Also
for
the
audience:
that's
here:
full
disclosure
for
me
after
secure
supply
chain
con,
my
workload
increased
about
50,
but
that
should
end
soon.
So
I
should
go
back
to
being
able
to
review
things,
but
I've
been
useless
in
the
salsa
front
for
a
little
bit.
So
sorry
about
that.
B
Yeah,
I
think
that's
the
same
case
for
a
lot
of
us
a
whole
lot
of
follow-ups,
a
lot
of
good
stuff
coming
out
of
the
supply
chain,
security,
con
and
kubecon.
A
All
right
all
right,
tweet
thanking
everyone
for
the
contributions.
B
All
right
cool-
I
guess
we
can
get
started
here.
Okay,
so
yep!
This
is
the
bi-weekly
sort
of
salsa
community
meeting.
We
have
a
couple
of
things
on
the
agenda,
but
before
getting
into
that
wanted
to
sort
of
reach
out
and
see,
is
there
anybody
on
the
call
who
sort
of
knew
wants
to
introduce
themselves?
C
Hi,
I'm
naveen,
I
work
in
the
oasis
of
scorecard
contribute
a
lot
over
there.
Also,
the
scorecard
obviously
wants
to
become
salsa
compliant
and
also
interested
in
salsa.
That's
the
reason.
I'm
here
thanks.
C
D
F
I'm
emmy
ivy
and
I
work
at
red
hat,
so
I'm
the
senior
manager
for
the
software
supply
chain
security
team
with
all
under
product
security,
I'm
the
lead
for
that
and
the
vested
interest
in
software
supply
chain.
So
I'm
excited
to
be
here.
B
All
right,
I
guess
I'll,
take
that
as
a
okay
cool,
so
first
off
priya
with
regarding
the
v
0.2
work.
G
Yeah
pretty
much
just
the
question
that
I
wrote
in
there
just
wondering
when
we
can
turn
in
the
draft
into
like
an
official
release,
because
then
I
can
get
started
actually
writing
code
and
making
the
required
changes
in
text
on
chains.
B
So,
for
the
other
folks
I
do
know
we
had
discussed
regarding
the
steering
committee
like
there
would
be
some
sort
of
like
level
of
voting
or
something
like
that,
just
to
kind
of
say,
hey.
Yes,
we
have
a
you
know
we
have
a
new
release
or
whatever
I
don't
remember
exactly
what
we
had
all
sort
of
agreed
on.
There.
H
Yeah,
I
don't
think
we
had
like
agreement
on
like
specifically
for
this,
like
that,
you
know
the
format
changes.
I
don't
think
we
have
a
process
because,
like
we
did
the
initial
release
and
just
tagged
it
and
then
so.
This
is
the
first
time
it's
come
up,
because
it's
the
second
one
I
guess
we
could
like.
H
We
could
kind
of
err
on
the
side
of.
Should
we
vet
these
more.
These
changes
more
carefully
and
you
know
kind
of
do
more
review
at
the
for
slower
releases,
or
should
we
err
on
the
side
of
better
to
get
stuff
out
and
let
people
try
it
and
and
even
if
it's
not
perfect,
because
it's
a
zero
point
x
release,
and
so
we
could
fix
it
later.
I
don't
know
if
folks
have
thoughts.
I
Yeah,
I
think,
given
how
new
salsa
is
and
how
relatively
few
systems
are
implementing
it.
If
this
is
a
significant
improvement
that
it's
worth
worth
making
a
release
sooner
and
it
seems
like
a
reasonable,
like
a
reasonably
good
set
of
changes
that
improves
the
format
that
wouldn't
be
worth
sitting
on
for
too
long.
So
I
don't
know
necessarily
that
we
should
cut
a
release
tomorrow,
but
I
think
it
might
be
worth
trying
to
set
a
date.
We
should
aim
for
and
encouraging
feedback
in
the
interim.
If
we
don't
get
any
then.
J
Mark
was
there
some
changes,
you'd
or,
I
think
was
microsoft.
You
saw
who
you'd
be
talking
to
about
changes.
Was
that
meant
to
go
in
the
like
this
iteration
of
the
draft,
or
would
that
be
more
long-term.
H
I'll,
let
me
paying
them,
I
don't
know
if
any
of
the
folks
are
here
like
william
or
david,
if
you're
here,
let
me
ping
them.
I
suspect
this
would
be
for
a
future
revision.
H
H
We're
at
the
point
now
where
I
think
they
need
to
write
up
like
a
concrete
proposal
and
we
could
get
review
and
kind
of
have
the
community
agree
on
it,
because
it's
still
like
kind
of
fleshing
out
ideas
in
our
heads,
but
but
I
I
don't
think
we
should
block
on
that
unless
they
have
one
particular
thing.
They're
like
oh
this,
this
looks
good
or
not
so
I'll
ping
them,
but
I
I
also
agree
with
joshua
that
I
would
lean
toward
just.
Let's
just
call
this
v2.
H
Unless
anyone
has
feedback-
and
please
review
it,
if
you-
and
maybe
let's
say
we
do
a
release
on
like
monday
tentatively,
so
that
would
be
a
deadline
for
anyone
who
get
feedback
in.
I
I
was
going
to
say
we
should
try
and
do
a
better
job
of
announcing
on
slack
and
my
mailing
list
when
there's
like
concrete
things,
we
want
feedback
on.
I
don't
think
everyone's
following
the
github
project,
but
maybe
a
few
more
folks
are
following
mailing
lists
and
slash
channels
that
might
be
prompted
to
provide
some
feedback.
A
And
for
what
it's
worth
at
this
stage
in
the
project,
without
many
stakeholders,
it's
probably
better
that,
from
my
opinion,
that
we
are
on
the
side
of
faster
releases,
gives
people
a
sense
of
urgency
instead
of
thinking
I
can
get
around
to
it,
which
doesn't
really
help
anyone
at
this
point
in
time.
B
Yeah,
I
agree
as
well
on
that
front
right
working
for
a
big
bank
and
I
think,
even
us,
we're
kind
of
like
hey.
We
would
much
rather
have
more
frequent
releases
because
we
recognize
that
with
a
lot
of
the
supply
like
if
the
supply
chain
work
was
fairly
standardized
and
and
hardened
already,
then
I
can
imagine
yeah.
We
want
to
make
sure
that
you
know
releases
are
are
more
clearly
vetted,
but
we
recognize
that
that
pretty
much
throughout
the
space.
B
H
Sounds
great
I'll
take
an
action
item
to
to
send
the
announcement
later
today
and
also
put
together
something
to
document
our
like
this
particular
point.
So
so
we
know
for
when
it
comes
up
next.
B
Yep
sounds
good.
I
So
the
this
was
just
in
the
same
vein,
I
suggested
with
sending
things
to
nameless
and
selection,
just
basically
a
request
for
some
feedback
on
this
issue,
whether
whether
we
think
we
should
be
recommending
signing
like
signing
of
artifacts
with
salsa,
we
reckon
in
a
similar
way
to
that
we
recommend
but
don't
require,
reproducible
builds
at
salsa
level.
I
Four,
I
think
it
makes
sense
to
recommend
but
not
require
signing
artifacts
and
the
main
rationale
there
is
that
in
an
ideal
world
you
know,
you'll,
have
your
source
for
providence
and
you'll
be
able
to
make
your
use
policy
decisions
based
on
that
sense
of
provenance
and
due
to
the
the
provenance
information
and
the
fact
that
the
attestation
is
signed,
you
get
something
like
a
detached
signature,
but
the
ecosystem's
a
long
way
from
that,
but
there
are
places
which
support
signing
today,
and
so
the
recommendation
to
sign
artifacts
provides
some
value
in
the
nato.
A
Some
of
the
questions
around
this
solved
by
something
like
the
criticality
score,
because
I
know
there's
discussion.
The
thread
about
the
value
of
signing
like
some
mentors,
have
no
value
really
or
limited
others
have
a
lot.
Is
this
just
something
that
could
be
accounted
for
in
a
model?
So
we
don't
have
to
really
worry
about
yeah
about
the
fine
details
at
a
high
level.
I
I
think
yeah
I
mean
I
think
so
I
the
current
the
current
requirements,
don't
say
anything
about
signing,
despite
requiring
we
that
folks
sign
their
attestations.
So
I
think
the
the
general
philosophy
of
signatures
is
like.
I
There's
there's
probably
value
in
providing
more
guidance
around
the
value
of
a
signature,
but
I'm
not
sure
it's
directly
related
to
this
discussion
and
that
we
don't
do
that
for
attestations
today,
although
we
have
an
issue
to
try
and
recommend
some
effectively
pki
for
scientific
stations.
D
I
No,
I
don't
think
so.
I
mean
my
train
of
thought
in
proposing.
This
was
effectively
that,
like
some,
so
I
I
work
on
and
in
open
source,
so
everything
I
think
about
is
open
source
ecosystems
and
some
open
source
ecosystems
support
package
signing
today.
So
you
know
pipeli,
for
example,
has
a
very
well
hidden
feature
that
you
can
sign
the
packages
you
upload
and
where
those
features
exist.
I
Doing
some
actually
signing
your
packages
is
better
than
not.
Arguably,
although
I
think,
and
maybe
the
ultimate
outcome
of
this
discussion,
given
the
comments
that
has
made
is
that
there's
too
many
like
too
many
thorns
here
to
even
make
it
worthwhile
recommending
effectively
and
that's
a
reasonable
outcome
as
well.
I
just
wanted
to
reason.
D
I
asked
is
that
broader
discussions
about
supply
chain
securing
supply
chains
usually
include
something
about
s-bombs.
I'm
I'm
not
actually
a
particularly
big
fan
of
them,
because
I
don't
think
a
lot
of
people
when
they
consume
software
actually
check
the
s-bomb.
But
it's
you
know
conceptually
where
you
know
one
sort
of
idea
is
you
know
you
sign
all
the
constituent
parts
you
sign
the
whole
whole
mess,
but
then
it's
like.
Is
anyone
actually
checking
these
things?
D
I
mean
it's
one
of
those
those
practices,
that's
like
you
can
go
through
in
a
lot
of
effort
to
do
it
and
then,
as
it
as
you
know,
kind
of
as
you're
alluding
to
have
a
lot
of
value.
So
you
can
kind
of
argue
yourself
either
way
so
anyway,
that
that's
helpful.
Thank
you.
D
I
guess
I
don't
have
a
particular
point
of
view
about.
You
know
signing
artifacts
from
that
sort
of
standpoint
unless
it's
the
ultimate
thing
that
you
know
there
are
tons
of
artifacts
as
a
part
of
the
build
process
that
you
aren't.
Necessarily,
I
don't
think
I'd
want
to
sign
all
the
dottos
that
you
know
cascade
out
of
a
build.
D
On
the
other
hand,
you
know
the
signing
software
at
the
at
the
end
of
the
process
is
actually
probably
pretty
valuable
and
almost
universally
in
in
some
fields
probably
practiced,
but
anyway,
as
you
said,
making
it
required
might
be
challenging.
B
So
my
my
two,
oh
sorry,
go
ahead,
no
go
ahead!
Okay,
so
so
my
two
cents
on
on
a
lot
of
this
is
so
at
least
looking
at
sort
of
salsa
and
the
attestations
versus
the
actual
artifacts
themselves
is.
I
think
that
they're
kind
of
doing
two
separate
things,
the
salsa
sort
of
attestations,
at
least,
in
my
view
at
least
the
way
I've
seen
it
is
sort
of
you
are
you
know,
establishing
provenance.
You
are
sort
of
doing
a
high
level
overview
of
hey.
B
These
sorts
of
steps
happened,
but
they're
not
really
talking
about
what
happened
in
an
individual
step
per
se,
and
that's
where
I
think
the
signing
of
the
artifact
really
does
make
sense
is
you're
kind
of
saying:
hey
this
identity
right
this
system.
Whatever
did
this
thing,
and
I
am
signing
the
output
of
that
thing
and
salsa
is
more
like
a
testing
that
hey
in
this
given
workflow,
I
am
saying
that
these
things
happen
usually
in
something
like
this
order.
B
So
that's
kind
of
the
way
I've
been
viewing
it.
It
sort
of
kind
of
goes
ties
into
sort
of
the
like
in
toto
side
of
things
as
well,
right,
where
in
toto
is
sort
of
a
flow
of
things,
whereas
it's
not
really
making
much
of
an
argument
about
what
is
happening
in
an
individual
step,
and
so
that's
why
I
do
think
signatures
of
some
of
those
things
is
still
important
right
like
I
I
you
know
as
an
example
like
I
care
about
that.
K
One
thing
I
think
is
worth
reminding
ourselves
is
that
if
we
think
about
how
signing
used
to
be
done,
we're
going
to
go
down
a
path
where
it's
it's
convoluted,
it's
hard
key
management
and
all
that,
and
so
we're
going
to
shy
away
from
it.
But
if
we
look
at
new
ways
of
doing
it,
where
we
can
automate
a
lot
of
it
and
by
that
and
not
only
I
mean
like
signing
but
also
verifying
like,
if
all
of
that
could
be
more
transparent,
then
there
we
do.
K
We
can
reach
a
point
where
there's
no
reason
not
to
sign
because
it
becomes
trivial
both
to
sign
and
verify
in
the
you
know
in
the
in
the
supply
chains,
and
then
why
not
signal.os
I
mean
it
doesn't
really
matter
I
mean
you.
Could
you
can
make
an
argument
about?
You
know
cpu
cycles
and
storage
space
and
all
that
and
and
it's
a
fair
argument,
but
conceptually
we.
We
I'd
like
to
reach
a
point
where
basically
it's
all
signed,
because
it's
it's
so
simple
to
do
it
and
to
verify
it
automatically.
J
I
think
it
might
be
useful
to
come
from
the
prior
of
if
we
can
advocate
for
less
pki.
That
might
be
better,
I
think
in
the
general
case,
does
a
person
coming
in
and
you
know,
trying
to
apply
salsa
really
gain
a
lot
from
just
trying
to
sign
something
somewhere.
J
H
You
have
your
so
one,
maybe
to
continue
matt's
thought
I
had
in.
In
my
opinion,
I
think
it
would
be
valuable
not
to
recommend
necessarily
it
should
be
signed,
but
rather
describe
the
properties
that
we
want
out
of
it
like
what.
What
is
the
signing
trying
to
accomplish
so
like
it's
also
just
signing,
doesn't
do
any
good
unless
there's
verification
down
the
line.
H
H
I
think
there's
a
lot
of
reasons
why
signatures
are
used,
but
that
that's
something
I
would
like
to
kind
of
work
out
be
before
going
on
the
requirement
and
then
signing
that
would,
I
think,
both
indicate
you
know,
or
that
would
lead
us
toward
like
what
type
of
signing
suffices
and
what
doesn't
and,
in
case
there's
like
alternate
solutions
that
achieve
the
same
purpose.
I
I
Request
I
mean
the
the
nucleus
of
the
idea,
for
me
was
really
just
ex.
There
are
existing
places
where
signing
is
supported
and
people
are
starting
to
look
at
adopting
salsa.
So
should
we
be
recommending
that
they
use
that
existing
signing
support
when
it's
not
possible
to
like
pip,
install
something
and
make
sure
that
it
has
or
to
you
know
at
use
time
verify
the
self
of
provenance
right.
That's
a
a
manual
step
today.
E
So,
in
addition,
I,
I
might
also
shut
a
light
here,
so
I
have
been
working
on
some
code
signing
things
in
the
last
year
and
what
I
figured
is
that
some
some
pieces
of
software
basically
require
you
to
do
code
signing
so.
Let's
say
you
are
shipping,
a
windows
application
or
you
are
shipping,
an
android
app.
E
These
usually
require
you
to
to
have
code
signing
in
place.
Otherwise
you
get
these
nagging
windows,
but
we
also
figured
that
indeed
pki
key
management
is.
Is
the
the
complex
thing
like?
How
do
you
deal
securely
with
with
these
secrets,
because
adding
code
signing
and
then
not
having
good
practices
to
deal
with
the
secrets?
That's
of
course,
also
yeah,
basically
the
reducing
the
security
of
the
supply
chain.
E
So
so
there
we.
We
also
did
a
lot
of
research,
so
I
also
shared
it
already
in
the
in
this
ticket.
We,
we
did
an
small
proof
concept
with
spiffy
and
volt
to
get
rid
of
this
initial
secret
and
how
to
manage
that.
E
But
we
also
figured
that
different
ecosystems
have
different
tools
already
available,
and
these
tools
require
you
to
use
x509
pki
certificates,
for
example,
for
for
windows
code
signing,
but
but
other
ecosystems
like
signing
a
git
commit
requires
you
to
do
gpg
so
also
there
we
were
looking
more
into
like
okay.
How
can
we
leverage
the
existing
ecosystem,
the
existing
tool,
landscape
and,
and
then
yeah?
How
do
you
combine
and
integrate
those
things?
E
So
I
I
do
think
artifact
signing
should
be
recommended,
but
we
should
also
see
how
we
can
lower
the
barrier
for
for
people
to
to
adopt
it
in
a
secure
way,
so
by
using
the
existing
tools,
because
that's
what
they
are
usually
already
using.
L
The
signing
and
how
to
make
it
one
the
meaning
of
it,
the
semantic
meaning
of
what
that
stunning
means
more
valuable,
so
very
often
signing
is
you're
assigning
a
snapshot
in
time,
whether
it
is
you're
signing
a
built
artifact
when
it's
due
to
like
a
code
signing
that
you're
then
going
to
submit
to
somewhere
else
or
you're
going
to
distribute
that,
and
it
could
be
verified
that
it
is
what
it
is,
and
the
other
kind
is
very
often,
then
the
the
signing
of
you
know
some
sort
of
a
source
distribution-
or
you
know
some
other
artifact,
but
to
make
it
actually
work
for
the
supply
chain
right.
L
You
don't
necessarily
want
to
just
have
a
signed
thing
somewhere
in
the
chain
which
you
really
want
to
be
signing.
Is
the
links,
the
things
that
map
from
one
part
of
the
chain
to
another
part
of
the
chain,
so
to
be
able
to
say
from
this
right
from
this
set
of
source
from
this
set
of
environments
from
this
sort
of
build
systems.
L
I
then
produce
this
other
thing,
and
so
it
is
the
chain
the
mapping
between
like
where
we
started
and
the
the
product
I'm
going
to
distribute,
and
if
that
is
the
kind
of
action
that
is
signed
and
that's
what
the
semantic
meaning
of
the
signing
is
from
that
you
can
build
an
entire
chain.
E
Yeah
so,
for
example,
let's
say
I'm
now,
depending
on
on
a
whole
bunch
of
dependencies,
but
those
tools
currently
do
not
have
code
signing
things
in
place.
So
I
basically
trust
things
by
by
manually,
verifying
things
or
things
like
that,
comparing
the
checksums
and
eventually
we
produce
an
artifact
that
that
has
signed.
E
That
is
signed
so
from
from
that
perspective,
as
long
not
everyone
is
doing
the
signing,
you
will
have
to
combine
it
with
other
things.
L
Yes,
and
in
a
world
where
you
have
a
lot
more
kind
of
reproducibility
in
builds
right,
then
you
you
all.
You
wouldn't
even
necessarily
have
to
sign
that
output,
because
it's
reproducible
right,
but
that's
not
the
world.
We
live
in.
It's
not
everything's,
not
going
to
perfectly
reach
that
goal,
and
so
what
is?
What
do
you
end
up
needing
to
do
is
to
sign
the
action
that
any
ci
or
build
system
performed,
which
is
that
I
started
with
x
and
I
produced
y.
L
B
So
I
I
do
want
to
just
put
a
little
bit
real
quickly.
One
thing
that
I
think
is
is
something
that
I
think
the
and
tell
me
if
I,
if
folks
think,
I'm
off
base
here,
it
sounds
like
the
big
thing
that
potentially
you
want
to
say
from
a
signature
standpoint
like
the
attestations
make
sense,
but
there's
also
an
element
of
hey.
B
I
have
an
identity,
and
this
identity
did
a
thing,
and
I
want
to
show
that
that
identity
did
a
thing
by
you
know,
saying:
hey
like
an
easy
way,
is
potentially
saying
that
identity
signed
that
thing.
So,
like
the
image
builder
signed
the
image,
the
s-bomb
generator
signed
the
s-bomb
and
to
be
clear,
I
think
it's
it's.
You
still
want
to
have
that.
You
know
the
provenance
standpoint
where
you
want,
where
you're
signing
the
links
between
them,
but
you
also
still
want
to
say:
hey.
B
The
links
are
also
only
as
good
as
what
the
steps
themselves
did
like.
If
a
step
lied
to
you
right,
the
the
the
signing
of
the
links
between
them
is
still
going
to
indicate
that
you
know
he's
not
going
to
provide
any
additional
guarantees.
I
guess
is
my
point
there.
Oh
sorry,
john,
you
have
your
hand
up.
M
Oh
yeah,
it
was
up
a
little
bit
earlier
for
one
of
the
things
I
kind
of
forgot,
what
triggered
it,
but
there's
this
thought
that
hey
signing
and
verifying
is
important,
and
maybe
it
should
be
a
requirement,
and
it's
also
maybe
it
shouldn't
be.
I
think,
what's
really
important
is
explaining.
Why
and
for
me
it's
like
a
just
use
a
farm-to-table
analogy
like
there's
a
great
episode
in
portlandia
people.
Go
they
want
to
go
like
I
don't
know,
eat
an
omelet
in
a
restaurant
and
software
supply
chains
is
like
basically
tracking.
M
You
know
the
entire
providence
of
that
artifact,
whether
it's
an
omelette
or
a
binary.
You
know
all
the
way
down
to
the
chicken
little
worker
node
that
produced
that
artifact,
the
farmer
that
managed
that
chicken
and
sent
it
to
the
farmer's
market,
the
chef
that
picked
it
up
at
the
the
farmer's
market
and
put
it
in
the
refrigerator
and
stored
it
at
the
right
temperature.
M
And
each
of
those
steps
is
like
a
you
know,
a
can
be
signed
and
attested
that
this
was
done
by
this
particular
identity
and
and
so
all
the
way
to
the
the
server.
That
brings
you
the
plate
of
food.
You
know,
has
an
assigned
and
a
testable
identity.
That's
saying
I
am
a
server
that
works
in
this
restaurant.
M
I'm
not
just
somebody
randomly
off
the
street
who
picked
up
this
plate
to
bring
it
to
you,
your
table
and
swap
these
omelettes
with
like
quail
eggs
instead
of
chicken
eggs,
or
you
know
something
more
malicious,
like
arsenic,
infused,
omelets
and-
and
so
I
don't
know
if,
like
making
it
a
requirement,
is
going
to
be
easy
because,
as
you
all
are
talking
here
about
the
complexities
of
signing
infrastructure
and
the
various
implementations,
we're
going
to
have
a
lot
of
like
debate
over
that.
I
think
it's
really
just
important
to
talk
about
like
hey.
M
B
No,
I
think
that
there's
a
good,
really
good
thing
there
about.
I
think
it's
just
about
what
identities
performed,
what
actions
right
and-
and
you
know,
making
sure
that
you
know
that's.
I
think
one
of
the
things
that
that's
really
important
there.
You
know
you
have
the
links
between
the
things,
but
you
also
care
about
the
identities,
because
then
you
can
always
go
back
and
say
yeah
like
if,
if
the
farmer
right
like,
if
the
farmer
you
know,
sold
something
bad
to
somebody,
you
can
go
back
and
say:
hey.
M
M
California,
like
regulations,
they
have
a
whole
track
and
trace
program,
and
so
they
have
supply
chain
for
cannabis,
distribution,
growth
and
sales
and
whatnot,
and
it's
really
interesting
to
see
that
in
a
non-tech
industry
take
place
like
a
really
robust
supply
chain
that
causes
a
lot
of
pain
for
those
individual
business
owners,
but
overall,
is
is
really
interesting
to
to
reason
about.
I
don't
know
I
just
all
I
was
trying
to
say
is
like
it's
really
hard
to
get
really
into
the
weeds
of
implementations
for
like
salsa
level.
M
Four
requires,
like
you,
know,
certain
implementations
of
certain
signatures
for
for
provenance,
verification
or
whatnot,
because
at
the
end
of
the
day
you
just
want
to
solve
it,
but
you
don't
necessarily
want
to
tell
people
how
to
solve
it.
You
know,
because
to
each
their
own
in
a
lot
of
different
situations,
but
yeah.
H
So
one
thing-
maybe
I
could
try
to
recap
the
conversation
two
things
I
I
heard
from
the
conversation
one
it
seems
like
people
are
using
signing
for
a
couple
different
purposes,
which
kind
of
reiterates
my
request
to
like.
Let's
clarify
the
purpose
of
what
we're
trying
to
achieve,
and
then
digital
signatures
are
kind
of
one
mechanism
to
do
that.
H
Another
thing
that
I
think
is
not
explicit
right
now,
but
we
should
agree
on
either
now
or
I
suggest.
Actually
maybe
we
we
discuss
this
at
the
next
meeting,
because
it's
we
already
have
other
things
on
the
agenda,
but
what
is
salsa
trying
to
achieve?
H
H
So
there
you
only
at
least
again
in
my
mind,
you
only
need
to
worry
about
mutations,
as
opposed
to,
like
you
know,
did
so
and
so
verify
did
they
test
it
did
they
do
other
things,
at
least
that's
what
is
in
my
head
and
what
I
think
is
documented,
but
that
doesn't
have
to
be
the
case,
and
so
I
think
we
could
either
that
might
be
a
topic
for
a
future
meeting
of
like
should
salsa
cover
other
properties
than
integrity.
A
H
So
the
the
review
piece
is
there
as
a
proxy
for
did
like
the
did.
The
organization
that
owns
the
software
did
they
agree
to
it
and
that's
like
a
hard
to
define.
So
we
could
approximate
that
by
saying
two:
you
know
responsible
parties
have
agreed
to
it,
and
so
therefore,
no
individual
has
the
ability
to
tamper
with
it,
but
colluding
made
still
ability.
So
it's
less
an.
H
Goal
is
just
around
protecting
from
tampering
other
like
I
was
I've
been
thinking
of
this
as
other
aspects
of
quality
like
vulnerability,
scanning
code
quality,
there's
like
the
whole
osf
osf
scorecards
projects
has
like
a
lot
of
these
different
properties
like
was
it
tested,
etc?
You
could
layer
on
top,
but
the
first
like
this
also
would
provide
the
baseline
of
integrity
of
like.
Is
this
even
the
legitimate
software,
and
are
we
talking
about
the
same
thing?
I
I
B
H
H
Yeah,
this
is
just
a
brief
kind
of
announcement.
In
case
you
didn't
happen
to
be
following
all
of
the
github
commits.
I
wrote
up
a
it's
a
work
in
progress
and
it's
not
fully
fleshed
out
a
list
of
detailed
threats
and
mitigations
that
we
hope
salsa
to
cover
it's.
The
format
is
not
particularly
readable.
I
so
again
any
suggestions
for
improvement.
H
There
would
also
be
welcome,
but
the
idea
is
that
I
want
to
kind
of
give
like
the
nitty-gritty
detail
of
like
what
are
all
of
the
different
threats
that
we
want
to
address
and
if
you
scroll
down
a
little
bit,
I
could
just
talk
about
a
couple
of
quick
examples.
H
If
you
go
down
a
little
bit
further,
so,
for
example,
like
someone
directly
submits
without
review
that
a
single
person
has
the
ability
to
modify
the
code
and
the
mitigation
at
level,
it's
also
level
four.
Is
that
there's
two-party
review?
H
It
would
be
great
for
folks
to
review
this
I'd
love
for
us
to
get
feedback
on
this,
improve
this
flesh
it
out,
and
I
think
this
will
help.
H
The
intention
is
both
to
help
us
as
we
develop
the
salsa
requirements,
to
make
sure
that
the
requirements
really
do
meet
our
objectives
and
cover
all
the
cases
and
also
document
which
cases
we're
not
covering,
because
there's
some
things
that
we
list
is
out
of
scope,
and
it
also
helps
like
based
on
our,
like
my
experience
within
my
company,
of
implementing
this,
when
we
you
go
to
some
team
and
have
them
implement
something
like
let's
say,
a
build
system
that
they're
going
to
implement
it.
H
It
helps
them
to
know
like
here
are
all
the
things
that
you
need
to
protect
against
and
so,
rather
than
like,
you
need
to
check
this
box,
but
they
kind
of
get
a
better
model
of
what
they're
trying
to
achieve.
So
that's
my
little
spiel
on
this.
So
if
you're
interested
I'd,
love
to
have
feedback
or
or
a
pull
request
to
improve.
B
Oh,
if
you're
talking
you're
you're
a
mute.
M
Got
you
yeah,
I
have
like
just
short
immediate
feedback
would
be
like
I
love
it.
I
would
love
if
it
was
like
a
a
list
of
those
threats
like
a
b
c
d,
e,
f,
g
and
stuff,
and
you
could
click
on
a
the
table.
You
could
click
on
that
button
like
and
then
expand
the
the
threats
there.
You
know
so
like
each
header
like
source
integrity
and
availability
click
on
it
boom.
It
drops
down
all
the
threats
in
that
category.
M
There's
also
like
some
ux
people.
I
would
love
to
plug
in
here,
but
they're
kind
of
like
they're
cool
people,
but
they
also
need
to
make
a
living.
So
I
don't
know
if
there's
a
budget,
that's
allocated
for
this
type
of
work,
but
there's
like
some
some
great
technical
people
out
there
that
might
be
able
to
contribute,
and
I
can
send
them
your
way
as
like
a
github
issue,
but
but
yeah.
M
H
B
If
that
oh
mark
did
you
did
somebody
just
delete
it?
There
was
a
yeah.
H
B
Oh
okay,
so
I
guess
next
up
is:
is
my
my
quick
update?
So
if
I
do
this,
so
the
secure
software
factory
stuff
is
more
from
the
cncf
is
more
or
less.
At
this
point
ready
for
comment,
some
email
should
be
going
out
to
various
folks
in
the
community.
We
should
be
sending
out
some
additional
details,
but
we
are
looking
for
sort
of
additional
feedback
on
this.
B
You
know
areas
we
do
talk
about
a
little
bit
about
salsa
in
here,
but
we
do
want
to
kind
of
you
know
see
where
we
can
tie
in
in
the
future
where
we
can
tie
in
further
with
some
of
the
salsa
stuff
and
where
we
can.
Potentially,
you
know
collaborate
further,
because
one
of
the
things
that
we
want
to
be
able
to
do
at
some
point
is
be
able
to
say,
hey
the
secure
software
factory
artifacts
that
are
going
through
it
as
long
as
you're.
B
Following
all
these
rules,
then
the
best
practices
that
are
that
are
in
there.
We
would
expect
you
to
be
producing
salsa
level
x,
artifacts,
something
like
that
and
along
with
that
is
the
secure
software
factory
reference
implementation,
which
is
still
being
worked
on.
B
This
is
based
on
a
lot
of
the
demos
that
a
lot
of
different
folks
had
done
like
prio,
with
chains
and
and
some
of
the
other
books
in
the
community
and
we've
kind
of
started
to
standardize
around
some
of
it
and
we're
trying
to
build
out
an
actual
sort
of
tool
that
you
know
hey.
This
is
a
sorry
it's
a
set
of
tools
that
should
be
able
to
sort
of
produce.
B
You
know
high
high
low
salsa
artifacts
because
of
all
those
things
and
then
can
also
be
integrated
with
easily
with
admission
control
for
actually
sort
of.
You
know
verifying
that
you
know
for
something
like
a
production
release.
Only
salsa
level
artifacts
with
all
the
right
attestations,
go
into
production,
that
sort
of
thing,
and
so
we're
also
looking
for.
B
You
know
how
we
can
better
collaborate
with
salsa
to
figure
out
a
how
we
can
generate
attestations,
better
and
and
how
we
can
integrate
with
that
and
then
also
you
know
just
different
ways.
We
can
sort
of
collaborate
on
that.
B
So
for
the
for
the
actual
doc
yeah
comments
on
the
doc,
if
it
hasn't
been
opened
for
just
general
comment
right
now,
I
believe
in
the
next
couple
of
days
it
will
be
and
I'll
I'll
keep
folks
up
to
date
in
the
various
slack
channels
and
various
mailing
lists
and
and
so
on,
and
then,
as
far
as
the
actual
this
code
over
here
feel
free
to
create
issues
feel
free
to
to
do
this
it.
This
will
fall
under
at
some
point.
B
The
cncf
projects
there's
just
probably
a
lot
of
bureaucracy.
We
need
to
go
through
in
order
to
get
it.
You
know
officially
part
of
the
cncf
but
yeah
that
that's
kind
of
so,
if
it's
regarding
the
sort
of
reference
implementation,
the
sort
of
prototype
implementation
that
we're
building
out
feel
free
to
put
it
in
the
github
issue
and
so
on.
If
it's
regarding
the
document
put
it
in
the
document
and
then
also
we,
we
have
meetings
every
thursday
regarding
the
cncf
supply
chain,
working
group.
B
Cool
okay,
next
up
marco,
the
providence
action.
E
Yes,
so
we
we
recently
started
looking
into
generating
some
provenance
and
seeing
how
we
can
be
salsa
level
one
compliant,
and
then
we
found
the
example
somewhere
on
the
salsa
repositories
and
we
we
took
that
example
and
we
basically
further
structured.
The
code
also
got
more
acquaintant
like
what
what
is
really
in
such
a
such
a
provenance,
for
how
does
it
work
and
based
on
that?
We
we
added
another
feature
that
allows
you
to
generate
provenance
based
on
an
existing
github
release.
E
So
if
you
look,
for
example,
in
inside
the
the
ci
workflow,
which
is
also
in
this
repository,
you
will
see
that
we
are
generating
a
github
release
using
go
releaser
and
then
in
the
next
job.
In
this
pipeline,
we
use
this
cell
subprovidence
action
to
generate
the
provenance
for
this
release.
E
So
what
we
are
looking
into
right
now
is
how
we
can
do
the
same
for
the
docker
images
we
are
releasing
and
in
this
case
I'm
releasing
to
the
the
github
docker
registry
as
well,
to
docker
hub
to
to
also
experiment
with
what.
If
I'm
releasing
docker
images
to
different
registries,
how
do
I
generate
the
provenance?
Will
I
include
provenance
for
everything,
or
will
I
only
include
provenance
for
the
release
to
that
specific
registry,
and
that's
where
we
are
struggling
a
bit
two
hours
ago.
E
I
also
had
a
call
with
trishank
too,
to
get
some
feedback
from
him,
as
I
know
him
from
previous
projects
in
the
past
and
yeah.
I
I
also
noticed
some
of
the
discussions
and
the
issues
with
the
materials
and
the
index
point
of
2d
to
the
in
material.
So
what
if
you
have
a
build,
that
is
using
multiple
repositories
and
how
to
handle
that,
so
we
will
come
back
with
some
more
details
and
github
issues
to
to
share
our
findings
and
yeah.
It
would
be
great
to
to
have
some
feedback
on
this
action
as
well.
H
Thanks
I'll
definitely
take
a
look
what
it
would
be
great
if
you
could
look
at
the
the
v
0.2
proposal,
which
is
linked
up
higher
in
the
in
the
the
meeting
notes,
because
the
the
draft
0.2
because,
like
like
you
mentioned
like
referencing,
the
materials
was
one
of
the
things
that
we
hopefully
made
better
in
the
next
version,
and
so
being
that
you
have
experience
like
using
that
schema
and
you
kind
of
know,
you
know
what
things
did
you
find
confusing?
H
What
were
the
rough
edges
if
you
have
any
suggestions
for
improvements
or
just
even
just
identify
problems
that
you
had,
it
would
be
great
to
you
know,
to
take
a
look
at
0.2
and
maybe
make
changes
there.
E
B
All
right
so
mark
back
to
you.
H
Yeah
we're
so
with
within
google.
We've
been
we're
doing
like
annual
planning
for
the
next
year.
I
I
don't
know
if
you
know
in
your
organizations
when
you
do
planning
for
work,
so
we're
trying
to
think
about
like
what
are
our
priorities
for
the
next
year.
We
also
still
have
an
outstanding
agenda
or,
like
outstanding
item,
to
add
a
roadmap
to
the
website.
H
I
just
want
to
raise
this
issue
now
in
case
these
are
some
early
ideas
or
to
see
in
people's
minds
to
start
thinking
about
it
for
next
time.
On
like
what
we'd
like
to
work
on
and
prioritize
over
the
next
year,
one
like
the
current
thinking
on
our
side
is
that
we
would
pick
one
ecosystem,
open
source
ecosystem,
maybe
python
and
python
package
index.
H
If
that's
you
know,
if
the
python
community
is
amenable
to
that,
and
I
try
to
fully
onboard
onto
salsa
so
have
the
notion
of
secure
builds.
My
thinking
is
probably
through.
Reproducible
builds
because
there's
just
general
agreement
that
reproducible
builds
are
a
good
thing,
and
I
have
some
notion
of
like
policies
and
to
actually
protect
and
both
to
detect
and
prevent
the
attacks
that
we
list
in
the
salsa
threats.
So
that's
again,
kind
of
early
thinking,
none
of
it
is
committed.
H
None
of
it
is
kind
of
even
widely
agreed
within
my
org
yet,
but
I
just
wanted
to
kind
of
see
this
as
these.
This
is
like
one
thing
that
we
could
we
could
do
and
if
anyone
has
other
thoughts
on
what
we
could
do
as
a
group
for
over
the
next
year
or
it
doesn't
even
have
to
be
a
year
if
even
if
it's
a
shorter
timeline
like
the
next
couple
months
or
quarter,
or
something
like
that,
that's
great
too.
I
Presented
a
couple
of
meetings
ago,
the
like
a
reference
architecture
mark
was
the
thought
that
you
would
develop
that
as
part
of
this
focused
effort
to
establish
also
within
an
ecosystem.
H
Yeah
and
matt
swozo
who's
on
the
call
has
been
working
on
that.
I
think
he
he's
getting
close
to
be
able
to
give
it
give
a
demo.
I
I
think
like
we
would
is
at
least
on
for
me
that
not
fully
fleshed
out
like
do.
We
have
like
a
separate
architecture
or
do
like
we
just
make
this
as
part
of
python.
H
It's
it's
not
not
clear
yet,
but
hopefully,
matt
should
have
something
soon
that
that
he
could
like
present
to
show
like
how
kind
of
all
the
pieces
end
to
end
work,
to
show
the
concepts,
even
if
it's
not
necessarily
like
secure
or
providing
a
lot
of
value,
at
least
to
show
the
concepts
and
then
from
there.
H
We
could
work
it
into
like
the
idea
for
2022
would
be
to
actually
like
do
this
for
real
in
one
ecosystem,
and
then
you
know
in
the
future,
as
we
have
more
resources
available,
we
could
then
take
that
and
and
go
to
other
ecosystems
as
well
feel
free
to
matt.
If
you
want
to
talk
more
about
that.
B
B
You
know
sorry,
sorry,
I
should
say
container
images
and
those
sorts
of
things,
but
we'd
be
interested
in
seeing
how
we
can
kind
of
also
work
together
to
kind
of
get
a
high
level
of
salsa
for
using
cloud
native
tools
to
generate
something
like
cloud
native
artifacts
like
container
images.
B
K
Yeah
regarding
the
python
community,
I
think
I
like
the
idea
a
lot.
I
just
think
it's
worth
noting.
I
was
looking
at
it
recently
from
a
slightly
different
angle,
more
from
the
like
purely
signing
side.
So
it's
I
need.
I
need
to
check
how
it
really
maps
to
salsa,
but,
for
instance,
there
is,
there's
been
a
pep,
a
python
enhancement
proposal
in
floating
around
and
not
making
much
progress.
K
Pep
458,
I
believe,
to
enable
the
python
package
index
as
a
tough
repository
and
that
hasn't
materialized,
it's
sort
of
stuck
and
it's
been
stuck
for
a
while.
So
just
a
fair,
I
think
it's
a
fair
warning
to
say,
like
I
think,
there's
there
is,
there
is
good
intentions
on
the
python
community.
I
think
it's
something
that
they've
come
around
to
thinking
is
a
good
idea,
but
you
can
see
the
pep
was
created
in
2013
and
if
you
look
at
a
conversation
on
the
on
the
forums,
it
hasn't
moved.
K
I
think
in
a
year
so
like
having
a
tough
repository
having
python
the
package
index,
even
just
you
know,
being
in
a
tough
repository,
seems
like
a
starting
point.
That
would
be
necessary
for
a
lot
of
other
things
to
be
able
to,
you
know,
know
to
have
compromise,
resilience
and
stuff
like
that.
So
again,
I
need
to
check
out
maps
to
salsa,
but
I
have
just
a
small
word
of
warning
here.
I
Yeah,
I
want
to
talk
to
that
briefly,
given
my
name's
on
the
screen,
and
that
is
that
there
is,
there
is
a
bunch
of
like
effectively
funded
work
happening
in
the
python
space
around
stuff
that
is
related
to
and
how
so
overlaps
with
like
salsa.
So
I
I
I
think
it's
worth.
I
Being
cognizant
of
that
before
we
plan
to
invest
in
python
specifically
effectively
like
I
don't
know
how
google
shows
python,
but.
H
Yep
sounds
good,
and
again
this
is
I
I'm
this
isn't.
Does
I
didn't
mean
to
say
that
like
google
has
chosen
this,
but
rather
I
am
putting
together
plans
now
to
to
get
agreement.
I
just
kind
of
picked
python
as,
like
an
example
not
yeah.
I
don't
mean
to
represent
anything
as
like
one
way
or
the
other
sure.
From
my
perspective
for
salsa,
it
doesn't
really
matter
so
much
whether
it's
python
or
go
or
rust
or
or
anything
else.
H
I
Yeah
yeah
for
those.
I
completely
agree
with
that
assertion
that
having
an
ecosystem
be
able
to
demonstrate
salsa
and
to
end
would
be
a
major
step
for
salsa.
I
just
wanted
to
make
sure
that
we
be
careful
not
to
effectively
invalidate
existing
work
or
compete
with
other
people
who
are
investing
in
this.
J
M
I
hope
for
2022
priorities.
We
have
like
a
list
of
successful
implementations
of
salsa
and
across
I
don't
know.
Maybe
this
already
exists
of
like
projects,
maybe
not
big
ones
like
python
and
girling,
but
like
even
little
bitty
projects
like
not
just
proof
of
concept
projects,
but
like
open
source
projects
used
by
the
community
and
and
like
a
list
that
shows
like
hey
these
people
integrated
this
level
of
salsa
and
here's
how
they
did
it
as
like
a
testimonial.
M
You
know
kind
of
thing
that
others
can
learn
from
to
help
build
that
network
effect
of
like
this
is
what
all
the
cool
kids
are
doing.
You
should
do
it
too
it's
hard
at
first,
but
follow
these.
You
know
steps
and
and-
and
you
can
be-
salsa
verified
at
certain
levels,
so
just
a
thought:
keeping
track
of
of
projects
that
are
attempting
this
to
go
down
this
road
and
publicizing
the
success
stories.
B
All
right
cool,
so
we
have
two
minutes
left
in
the
meeting.
Any
other
quick
comments.
Threads
topics
for
next
obviously
feel
free
to
put
the
once,
or
rather
for
next
meeting,
put
things
in
the
agenda
yeah,
any
other
quick
comments
or
anything
else.
Otherwise,
we
can.
B
Folks
see
everybody
in
two
weeks.