►
From YouTube: SLSA Meeting (October 20, 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).
A
A
All
right,
we
got
a
lot
on
the
agenda
today,
so
I'm
gonna
kick
things
off.
Let
me
share
my
screen.
B
Okay,
you
you,
you
press
the
share
screen
the
green
button.
A
Yeah,
anyway,
here's
a
link
to
the
meeting
notes
feel
free
to
throw
your
name
in
the
attendees
list
and
tell
all
your
all
your
friends.
They
could
be
here
too
oops.
Let
me
start
in
a
so
welcome
everyone
to
our
salsa
working
group
meeting.
I
I
finally
figured
out
the
the
zoom
recording
and
got
access
to
it
so
posted
the
last
meeting
in
the
open,
ssf
youtube
channel.
A
So
I
think
there
was
a
demo
last
time
a
lot
of
people
were
looking
for
that
so
feel
free
to
check
out
the
the
last
meeting,
and
then
we've
got
a
bunch
of
stuff
on
the
agenda
today
and
I
think
the
first
thing
is
ezra
and
trishank.
You're
gonna
talk
about
what
you
talked
about
at
kubecon.
C
Yeah,
I
think
the
idea
was
just
to
quickly
present
just
to
follow
up
on
michael's
awesome
demo.
The
last
time
just
wanted
to
show
related
ideas.
How
you
can
do
things
differently,
azra.
How
should
we
do
this?
Should
we
should?
C
C
Let's
say:
google
meat
has
got
a
very
nice
way
to
share,
only
select
apps,
okay,
there
we
go
yeah,
I'm
sorry
if
some
of
you
have
already
seen
the
stock
and
but
for
the
benefit
of
those
who
didn't
azra,
and
I
just
want
to
talk
in
santiago.
C
If
he's
here,
we
just
want
to
talk
about
what
we
call
the
state
of
the
art
of
supply
chain
security,
as
it
is
now
how
you
can,
and
we
particularly
the
reason
I
bring
this
up-
is
to
follow
up
in
michael's
demo
and
talk
about
how,
when
you
put
together
technologies
like
this
part
of
the
thing
that
I'm
personally
curious
about,
is
what
will
we
grade
the
salsa
level
of
this?
I
think
it'll
be
a
good
acid
test
for
salsa
to
see
you
know
we
give
this
level
one
level
two
level
three.
C
Is
it
a
2.5?
You
know,
I
think
it'll
be
an
interesting
test
case
so
anyway,
the
story
is
that
datadog
wanted
to.
You
know
we
have
the
agent
right,
so
datadog
is
a
monitoring
company.
To
put
it
in
a
nutshell-
and
we
have
this
thing
called
the
agent
that
you
install
in
the
infrastructure
and
then
the
integrations
are
kind
of
like
add-ons
for
the
agent
okay,
and
so
we
wanted
to
decouple
the
integration
from
the
agent
they
used
to
be
shipped
together,
every
six
weeks
kind
of
like
chrome.
C
So
how
do
you
do
this?
Well,
you
use
ci
cd
right,
you
ship
the
integration
separately
from
the
agent
great.
So
what
can
go
wrong
with
the
with
the
previous
state
of
the
dr
most
of
the
time?
Nothing
everything's
good
99.999,
whatever
percent
you
know
sla
is
problem,
is
what
happens
if
your
developer
key
gets
compromised
or
your
source
code
can
source
code
repository,
gets
compromised
or
your
ci
cd
or
your
registry
registry
used
to
run
the
ci
cd
jobs
key
and
file
service?
I
think
you
get
the
idea.
C
C
So
the
lesson
is
we:
we
can't
prevent
a
compromise,
but
we
can
make
it
compromise
resilience
and
you
know
kind
of
like
the
old
medieval
fort,
where
you
build
layers
upon
layers,
a
guy
looking
outside
says.
You
know
he
sees
the
alligators
in
the
mode
and
guys
with
flame
droves,
maybe
even
a
nuclear
weapon,
and
he
says
forget
about
it.
I'm
gonna
go
for
easier
targets.
C
So
how
do
you
do
this
well?
Well
azra,
santiago,
and
I
claim
that
you
can
do
this
with
three
pieces
of
technology
called
in
toto
tub
and
six
door
respectively
and
they're
all
very
complimentary
technologies
that
when
you
put
it
together,
you
get
a
very
strong
hold
kind
of
like
a
non-linear
sum.
Actually,
the
sum
is
greater
than
the
yeah.
The
hole
is
greater
than
the
sum
of
the
parts.
Okay,
so
the
too
long
didn't
read
this:
I'm
not
going
to
go
through
all
the
details.
C
We
don't
have
the
time,
I'm
not
trying
to
hijack
the
talk
yet
the
the
meeting
here
to
do
a
full
sales
pitch,
but
the
idea
is
that
I'm
not
even
making
any
money
from
this
directly
but
anyway
in
toto,
is
kind
of
like
the
intoto.
Is
the
technology
that
you
use
to
secure
the
supply
chain
right.
I
think
we're
all
familiar
with
it
here.
You
use
it
to
you
kind,
you,
okay,
here's!
How
intero
basically
works
you.
You
sign
the
input
and
output
of
every
cicd
step.
That's
it!
C
That's
all
you
need
to
know,
and
then
tuff
will
give
you
the
artifact
signing
and
the
key
distribution
and
rotation
and
all
that
good
stuff.
So
you
do
a
packaging
compromise,
resilient
packaging
of
all
your
entota
metadata,
as
well
as
your
artifacts,
and
then
you
add
sigstor.
On
top
of
that
now
you
have
a
permanent
immutable
ledger
for
recording
the
end-to-end
history
of
every
single
artifact
that
you've
ever
made.
You
can't
even
lie
about
it
if
you
wanted
to
so
so.
C
The
metaphor
is
kind
of
like
vaccines
to
to
kind
of
drive
it
home
in
toto
is
kinda
like
pfizer
or
moderna
or
jnj
or
noahvx,
or
whoever
comes
next
and
says.
Here's
how
I
made
my
vaccines,
here's
how
much
mrna
I
use
how
much
lipid
shells,
whatever
you
get
the
idea
and
then
tuff
is
kind
of
like
the
fda
saying.
C
Why
should
you
trust,
pfizer
and
modena
or
gng
or
novo
x,
in
the
first
place
and
then
finally,
six
stores
kind
of
like
the
cdc
saying,
recording
the
end
to
end
history
of
every
single
vaccine?
You
give
it
a
lot
number
and
the
expiry
date
and
whatnot
and
you
can
see
okay.
This
is
exactly
how
how
everything
was
made.
If
something
went
wrong
now
you
have
a
permanent
record
of
it
and
I
don't
want
to
go
into
the
details.
C
This
is
this
is
about
as
far
as
we
should
go
and
if
you're
interested
in
details,
you
should
please
see
our
our
our
recorded
talk
when
it
comes
out
at
supply
chain
security
gone
last
last
week,
azra.
Why
don't
you
take
it
away
from
from
here
please
and
show
us
your
awesome
demo.
This
is
actually
working
live
in
practice.
D
All
right,
so
I
am,
I
wonder
if
I
can.
Okay
sorry
screen
sharing
is
confusing
on
zoom.
So
what?
Basically,
I
guess
the
demo
is
kind
of
is
showing
this
whole
like
process
of
uploading.
I'm
sorry,
I'm
still
trying
to
figure
out
sharing
screens
right
now.
Yes,
I
think
yeah.
I
think
I
got
it,
but
so
I
wish
I
could
pause
this
like.
I
don't
think
I
can
do
this
demo,
like
with
yeah.
I
don't
know
if
I
can
pause
a
gif
on
the
browser,
probably
not
all
right.
D
I
have
no
way
of
playing
gif,
so
what
I
kind
of
want
to
show
is
like
discoverability
of
like
record
and
tough
metadata
on
like
on
a
demo.
Basically,
what
we
have
here
is
that
the
data
dog
mechanism
did-
I
hear
something:
okay,
whatever
so
the
way
that
datadog
works
is
that
there's
a
check
for
each
of
the
integrations
that
downloads
the
tough
metadata
and
does
verification
and
then
pulls
in
the
verified
metadata
into
a
like
local
repository
and
so
on.
D
The
other
side
of
like
datadog,
doing
like
tough
metadata
updates
so
like
issuing
a
timestamp
every
day,
or
so.
I
think
what
it
also
does.
Is
it
uploads
that
tough
metadata
to
record
directly
and
so
record
has
support
for,
like
just
taking
in
a
piece
of
tough
metadata
associated
with
a
route
verifying
that
that
route
signed
that
metadata
and
then
putting
it
in
the
log
and
then
what
you
can
do
from
the
verifier
downloader
side,
which
I
think
now
the
demo
is
actually
running,
that
portion
of
this
it's
verifying.
D
D
I
have
more
trust,
I
guess
in
my
remote
repository,
because
I
know
it
is
also
like
non-falsifiably
in
this
log
as
a
piece
of
tough
metadata,
so
that
recourse
search
right
there
is
searching
based
on
the
root
which
is
associated
with
that
particular
piece
of
tough
metadata,
and
so
you
can
verify
that
it's
in
the
log
and
you
kind
of
have
some
assurance
over
okay.
I
know
that
datadock
has
been
uploading
a
history
of
these
timestamp.jsons,
that's
kind
of
the
demo.
D
All
I'm
doing
here
is
like
verifying
the
shots
of
the
two
timestamps
match
up
with
the
one
so
like
the
one
that
is
in
the
log
versus
the
one
that
you
just
downloaded.
Does
that
make
sense.
C
Yeah
we're
very
cool
azure
thanks.
I
should
I
should
have
mentioned
exactly
how
the
setup
works
here
too,
and
maybe
maybe
ask
follow-up
questions
to
the
audience.
Let
me
let
me
just
quickly
share
my
screen
and
then
we'll
we'll
call
this
over.
I
just
want
to
end
with
a
few
questions
here.
So
sorry,
I
should
have
mentioned
how
this
how
this
works
in
practice.
How
we
do
this
for
the
agent
integrations
is
that
so
this
is
what
our
in
dodo
supply
chain
basically
looks
like.
C
We
have
this
three
steps:
okay,
there's
four
steps.
Implicitly
in
todo.
Does
this
thing
called
inspection
at
the
end,
the
first
step
is
our
developers
sign,
so
the
integrations
are
basically
just
python
packages.
Zip
files
they're
wheels
wheels,
are
just
zip
files
containing
python
source
code.
Luckily
we're
not
compiling
any
source
code
here,
so
we
don't
need
to
worry
about
reproducible
bills,
so
our
developers
sign
python
source
code
with
your
ub
keys.
C
So
even
if
you
know
someone's
sitting
on
a
laptop
trying
to
get
them
to
sign
malicious
stuff,
they
would
notice
because
well
there's
a
few
things
protecting
them.
One
is
the
keys,
are
generated
and
trapped
right
generated,
and
you
have
to
sign
everything
using
the
ubc,
so
you
can't
even
run
away
with
the
signing
key.
The
second
thing
protecting
is
every
signing
operation
requires
a
touch
operation
on
the
ub
key.
You
literally
have
to
touch
it.
C
So
there's
a
there's,
a
very
tight
race
condition
that
that
that
attackers
have
to
do
to
manage
to
convince
them
to
sign
up
something
malicious,
and
even
then
you
can
do
things
like
you
require
two
or
more
developers
to
sign
off.
On
the
same,
you
need
a
collusion.
Basically,
so
you
set
the
bar
for
compromise
very,
very
high
anyway,
so
developer
sign
off
source
code,
okay
using
the
ub
keys,
and
these
are
all
linked
files.
These
are
just
attestations.
Links
are
just
special
cases
of
in
dodo
attestations.
C
Now,
if
you're
familiar
with
attestation
but
not
links,
and
then
we
have
the
ci
cd,
I
want
to
talk
about
so
there's
a
reason
why
I'm
bringing
this
up
so
cicd?
Basically
too
long
didn't
read:
we
checked
that
it
proved
the
same
source
code
from
github
that
developer
signed
and
then
puts
it
in
the
zip
file
that
I
was
talking
about,
and
then
this
guy
signs
everything
using
tough
metadata
wraps
it
all
together.
You
know
nice
that
fda
seal
of
approval
kind
of
thing
and
at
the
end
the
agent
will
un
the
agent.
C
So
I
don't
have
to
trust
my
ci
cd
at
all.
In
fact,
I
don't
use
any
trusted
hardware
here.
I
don't
need
to
really
really
tighten
the
ci
cd.
This
is
why,
but
this
is
why
I'm
bringing
on
the
context
of
salsa.
Do
I
really
need
trusted
hardware
in
my
ci
cd,
it's
nice,
but
it
doesn't
actually
get
me
stronger
security
guarantees.
C
I
claim
because
my
route
of
trust
is
in
the
developers,
so
this
is
something
I
want
us
to
talk
about,
also
which
salsa
does
focus
in
source
requirements,
but
sometimes
I
feel
like
there's
a
lot
of
emphasis
on
build
and,
and
I'm
trying
to
make
the
argument
that
if
you
set
it
up
right,
if
you
trust,
if
you
place
your
emphasis
of
trust,
your
root
of
trust
in
the
source,
you
don't
really
need
to
worry
too
much
about
your
bill
environment,
and
I
claim
that
that
should
be
one
of
the
last
few
pieces.
C
You
work
on,
maybe
salsa
levels
304.
So
that's
one
thing
yeah
and
then
we
don't
need
sorry
good.
E
Okay,
I'm
sorry,
I
was
just
gonna
ask
if
that
was
true
for
languages
where
you
can't
effectively
recover
the
source
from
the
final
archive
right,
like
python's,
somewhat
unique
a
special
case
there
right
so
for
something
like
go
right
does.
Would
that
same
assertion
hold
in
your
opinion.
C
This
is,
this
is
true,
that's
a
good
point
yeah,
so
for
something
like
go
or
something
compile
binaries
you're
going
to
do
you're
going
to
need
to
do
something
like
what
solarwinds
did
right,
different
pipelines
literally
compiling
the
same
thing,
and
then,
if
there's
no
collusion,
hopefully
you
get
at
the
same
hash
and
bitcoin
core.
Also.
Does
this
yeah
you're
right
you're
right?
That's
a
good
caveat!
Yes,
but
my
point
is
you
still,
you
still
need
to
check
what
developers
are
doing.
This
is
something
that
I
feel
that
people
miss
it's
very
important.
C
F
Yeah
thanks
a
lot
trishan.
I
I
I
think
I
need
to
like
look
at
the
details
more
and
think
about
more
to
like
actually
map
it
to
the
requirements.
One
thing
I've
been
thinking
about.
I've
talked
to
some
of
you
about
this
and
it's
never
really
connected,
but
I'll
bring
up
anyway.
Salsa
kind
of
has
two
separate
pieces.
One
is
when
you
have
a
package
linking
it
back
to
the
source
and
two
is
properties.
F
How
you
know
the
source
is
okay
around,
like
two
part
of
your
view
and
there's
version
control
and
strong
identities.
It
seems
like
that
what
you
describe
here,
at
least
the
build
part
because
effectively
it's
a
no
op
build
like,
and
I
think
we
might
have
that
in
the
in
the
dock.
F
That,
like
you
said,
if
you
have
a
no
op
build,
it
is
trivial
like
you,
trivially
satisfy
all
the
build
requirements,
because
there
is
no
build
right
like
the
fact
that
zipped
up
you,
the
client
unzips
it
so
so
it
undoes
that
information.
So
you
don't
need
to
do
it.
So,
in
my
opinion,
all
those
would
be
satisfied
by
that
aspect.
F
As
matt
said
like,
I
think
it
would
only
it
only
works
for
us
the
special
case
here,
where
you're
distributing
source
packages,
it
doesn't
work,
for,
I
think,
probably
the
large
majority
of
packages
that
have
any
sort
of
compilation,
but
but
yeah,
I
think
the
you
know
it's
also
four
has
a
requirement
two-party
review.
That
is
not
well.
I
guess.
If
you
have
two
people
sign
off,
you
could
satisfy
the
two-party
review
aspect
using
that
that
mechanism.
G
G
I
guess
I
guess
an
outstanding
question
like
if,
like
this
approach
works
in
some
cases
where
you
can
have
the
client
sort
of
undo
the
packaging
operation
and
verify
the
source
directly,
that
does
seem.
That
does
seem
helpful,
but
it
it
does
put
the
burden
on
the
clients
to
be
able
like
they
then
need
to
know
how
to
undo
those
those
those
those
transformations
which
might
be
different
from
like
from
like
package
to
package
like
for
python,
it's
x
for
maven.
It's.
Why?
G
G
The
build
entry
point
that
it's,
what
they
that's,
what
they
they
expect
and
that
the
sources
come
like
come
from
an
appropriately
leveled
source
control
system
and
that
that
setup
could
work
for,
I
believe,
for
for
for
all
types
of
artifacts,
even
those
that
aren't
that
aren't
trivial,
trivially,
sort
of
reversible.
C
Right
so
to
answer
a
question
there
yeah,
so
so
so
good
going
to
mark's
point
yeah.
The
thing
I'm
curious
about
is:
what
do
we
do
about
pipelines
like
like
mine
here,
for
example,
where
it
has
some
in
it
borrows
some
in
it
meets
some
properties
of
some
salsa
levels,
but
not
necessarily
all
of
them.
It's
kind
of
like
a
weird
mix
and
match
right.
So
I'm
kind
of
curious
how
we
would
tackle
something
like
that.
That's
one
two
to
answer
your
question:
tom
one
is
so
the
internal
layout.
C
Actually
you
can
specify
down
to
the
nail
exactly
how
clients
should
verify
you
should
do
the
inspection
at
the
end.
So
I
yeah
I
I
do
agree
they'll
be
different
for
go.
You
might
want
to
check
that
the
hashes
from
two
different
pipelines
match
and
maybe
for
like
things
like
python
or
php
or
perl,
you
do
the
you
do
the
kind
of
simple
check
that
I
was
talking
about.
But
the
point
is
that
developers
can
specify
this
actually.
G
So
so
maybe
the
first
question
like
how
like
like?
How
do
you
get
this
this
this
pipeline
in
into
salsa?
G
I
think
I
think
that
in
some
part
like
that
boils
down
to
like,
where
is
the
salsa
provenance
generated
and
signed,
and
I
think
what
you
could
do
is
like
currently,
where,
where
you
have
the
the
the
agent
unpacking
the
wheel,
verifying
the
source
code
came
like
came
from
the
developers
that
that
that,
like
that,
might
be
a
good
opportunity
within
an
organization
to
have
to
have
some
sort
of
lockdown
and
secure
system
that
that
does
that,
and
then
it
emits
the
salsa
provenance
that
says
hey
this.
G
This
thing
is
good.
I
think
that's
how
some
of
the
I
want
to
say
in
one
of
your
proposals
mark
you
suggest
that,
like
that,
the
salsa
province
could
be
generated
directly
by
the
builder,
which
is
necessary
in
like
some
cases,
but
you
could
also,
in
other
cases,
have
the
have
some
external
entity
look
at
logs
that
the
builder
produces
and
generate
the
provenance.
H
Sorry
really
quickly
so
like
there
are
binary
compilation
steps
in
construction
of
a
lot
of
wheels.
So
I
don't
think
the
operation.
C
C
Sorry,
but
I
think
I
understand
the
gist
of
his
questions.
Yes,
python
wheels
are
generally
not
not
just
source
packages,
you
do
have
binaries
in
them
and
I'm
aware
of
a
python
effort
to
deterministically
compile
this
package.
I
don't
have
the
url
handy
right
now,
but
I'll
share
it
with
the
group,
perhaps
in
the
community,
meaning
not.
But
yes,
yes,
it
is
true.
C
F
Yeah,
I
think
like
in
terms
of
I'm
sorry,
I
didn't
mean
to
cut
you
off
yeah
in
terms
of
like
next
steps,
I
think
probably
would
be
good
is
if
we
could
try
to
figure
out
somehow
to
document
like
in
more
details
than
the
abstract
requirements,
like
case
studies
or
things
that
we
think
meet
salsa.
I
know,
there's
an
issue
open
right
now
that,
or
is
a
pull
request,
maybe
either
way,
unlike
how
to
do
it
on
github.
F
I
think
those
type
of
things
of
like
case
studies
would
be
useful
to
give
people
more
like,
instead
of
them
having
to
synthesize
everything
themselves,
they
could
kind
of
see.
Oh
well,
I
could
do
it
like
this.
I
could
do
it
like
that.
I
think
that
would
be
good.
D
Yeah
mark,
can
I
ask
a
quick
question:
what
is
the
do?
You
have
any
idea
how
to
like
of
that
reference
of
how
to
do
it
on
github.
F
There's
a
let
me
I'll
paste
in
the
chat
that
there's
a
issue
open
issue.
I
think.
D
Okay,
awesome
yeah,
we've
been
gotcha
yeah.
F
A
I
F
A
I
Okay,
great
okay,
yeah,
okay,
so
a
couple
weeks
ago
we
talked
about
merging
the
tactile
provenance
and
the
salsa
provenance
so
that
we
could
just
have
one
that
would
work
for
everyone.
So
this
is
basically
a
proposal
for
v2
and
it
makes
a
few
changes
and
I
think
this
format
should
work
really
well
for
both.
So
I
don't
know
how
like
in
in
detail.
I
People
want
me
to
go
right
now,
but
basically,
like
the
two
biggest
changes,
I
think
is
that
we
have
replaced
what
was
formerly
defined
in
material
with
something
called
config
source.
So
config
source
is
no
longer
a
pointer.
I
It
actually
will
inline
entry
point
uri
and
digest
so
instead
of
pointing
to
a
material,
it
could
point
to
anything
even
if
it
wasn't
in
a
material
which
works
better
for
the
tekton
case
and
in
general.
I
think
removing
the
pointer
probably
just
makes
more
sense
as
well
and
then
the
other
kind
of
bigger
changes.
We
added
a
section
called
build
config,
which
would
basically
include
like
the
steps
that
were
actually
executed
during
the
build
so
insect
on.
I
It
would
be
like
the
steps
in
your
cloudbuild.yaml
and
the
reason
that
we
wanted
to
include
this
is
because
at
like
lower
salsa
levels
in
techcon
right
now,
we
actually
can't
really
set
to
find
a
material
or
necessarily
point
to
the
exact
task
that
was
run
so
kind
of
our
next
best
option
is
to
just
put
all
the
information
for
each
step
that
was
run
so
that
people
can
kind
of
recreate
the
yaml
themselves
from
the
provenance
and
then
kind
of
a
smaller
change.
I
We
renamed
recipe
to
invocation,
just
kind
of
seems
to
like
sit
a
lot
better
with
people,
but
invocation
will
still
kind
of
include
config
source,
which
used
to
be
define
a
materials
environment
just
the
same
as
it
was
before,
and
parameters
which
we've
renamed
from
arguments,
but
basically
comprises
of
the
same
stuff,
and
the
final
change
is
to
add
in
a
high-level,
build
type
uri,
which
will
basically
determine
like
the
format
of
invocation,
build
config
and
materials.
I
So
it
would
look
something
like
this
or
somehow
stop
sharing
oops.
I
So,
basically
the
changes
I
just
mentioned,
but
again
we
keep
builder
id,
as
it
was
add
in
the
still
config,
which
would
include
all
the
steps
that
were
actually
executed
during
the
build
rename
recipe
to
invocation
and
replace
to
find
a
material
with
this
config
source
rename
arguments
with
parameters
just
because
I
think
the
word
makes
a
little
bit
more
sense
for
a
lot
of
people,
and
then
we
have
this
build
type
uri,
which
will
basically
indicate
to
people
what
the
format
of
like
build.
Config
and
materials
would
be.
C
Interesting
thanks
could
you
I
think
it
would
be
helpful
to
show
how
this
compares
to
tech.
So,
are
you
saying
that
this
alliance
with
tacton
right
now.
I
C
I
So
this
is
the
current
tecton
providence
format.
So
basically,
what
we
have
is
like
this
section
recipe,
dot
steps,
which
was
the
main
thing
that
we
added,
and
this
would
basically
turn
into
what
bill
config
is
in
the
proposal
where
we
just
like
put
in
all
the
information
of
each
container.
That
was
run
everything
that
was
passed
in,
so
people
could
like
recreate
the
tectonic
ml
if
they
needed
to
materials,
pretty
much
matches
up
invocation
will
switch
and
parameters
are
kind
of
the
same.
I
We'll
pre,
we'll
just
have
to
make
a
change
to
start
using
the
source,
config
the
config
source,
that's
in
the
proposal
and
add
in
the
environment
again.
If
we
need
to.
F
So
one
thing
that
I
I
ask
that
if
you,
if
you
have
any
opinions
on
this,
it's
good
to
get
this
now
because
we're
you
know
we
picked
the
original
names.
I
think
only
a
couple
of
the
folks
here
were
involved
in
the
original
design.
Several
of
the
things
that
priya
changed
were
because,
like
like,
she
wasn't
the
only
one
who
had
confusion
around
like
what
recipe
meant,
and
so,
if
there's
anything
more
that
like
just
is
kind
of
continuing
source
of
confusion
or
that
could
be
named
better.
E
I'm
curious
whether
there's
been
any
whether
there
are
any
sort
of
third
attempts
at
this
in
the
wild
that
we
might
consider
engaging
with.
Or
I
don't
know.
Maybe
such
a
thing
does
not
exist
yet,
but
just
as
a
you
know
something
to
sort
of
compare
this
with.
L
Yeah,
so
so,
not
particularly
an
actual
attestation
format
per
se,
but
nick's
derivation
output
looks
very
similar
to
this
sort
of
thing,
and
it's
probably
worthwhile
to
also
take
a
look
at
because
it
does
include
sort
of
the
stuff
like
what
were
the
inputs.
What
were
the,
what
was
the
build
are,
what
was
the
the
build
script?
What
was
the
build
apparent?
What
were
environment
variables
and
so
on?
So
it
might
be
worthwhile
to
also
take
a
look
there
as
well.
F
Cool,
so
that's
actually
one
thing
I
I
want
to.
I
don't
want
to
spend
a
lot
of
time
on
it,
but
if
people
have
thoughts
on
like
how
we
do
changes
like
this
right
now,
it
has
a
dash
alpha
suffix.
I
was
thinking
that
that
could
be
a
signal
that
it's
unstable
and
like
no
one
should
be
relying
on
this
until
we
finalize
it
and
remove
the
suffix
that
way,
we
could
kind
of
continue
to
have
a
period
where
we
could
bundle
changes.
F
So
we
don't
have
like
constant
breaking
of
changes,
but
we
could
bundle
it
into
like
when
we
released
two
we
could.
We
could
have
something
else,
but
I
don't
know
if
folks
have
a
few,
because
that
would
also
allow
us
to
submit
it.
Have
people
be
able
to
look
at
it
review
and
fix
things
before
finalizing,
given
that
we
don't
have
like
a
update.
G
So
I
I
think
an
example
is
that,
like
so
internally
at
google,
we
are
having
people
start
to
start
to
implement
0.1,
and
if
we're
going
to
make
changes,
then
we
need
to
like
point
them
at
the
next
thing
that
they
should
do
and,
like
I
think
it's
just
like
is
like
0.2
going
to
keep
evolving
or
like
should
this
just
be
submitted
as
like
0.2
now,
if
any
changes
come
in,
then
there's
0.3,
then
there's
0.4.
G
I
think
that
the
only
issue
is
that
that
doesn't
give
any
indication
of
like
any
sort
of
completeness
like
when
we
take
0.1.
We
thought
okay,
this
is
fine.
For
now
we
don't
have
anything
else
pending,
but
I
don't
know
if,
if
0.2
is,
is
there
yet.
K
I
think
I
have
another
question
here,
which
is
at
what
point
we
should
be
doing
a
version
one
like
so.
Let's
say
we
merge
all
these
changes
and
do
people
think
it's
a
good
time
to
do
that
or
do
people
feel
it's
a
long
way
to
version
one?
That
would
be
another
question
because,
like
we
did
a
version,
one
with
salsa
right,
bringing
it
to
a
state
so
that
it
proves
people
like
hey,
this
is
stable
start
using
it.
So
we
might
want
to
do
the
same
thing
for
salsa
provenance
right
to
make
sense.
F
Trishang
said
in
the
comments,
I
agree
that
I
I
feel
like
the
zero
point
is
a
nice
indicator,
because
we
don't
have
any
real
implementations
of
people
doing
this.
I
think
it's
a
good
to
let
early
implementers
know
you're
doing
something
early
and
you're
going
to
have
to
change
later.
I
think
a
1.0
would
be
some
sort
of
long,
some
sort
of
indication
of
long-term
support,
and
I
don't
feel
like
we're
there
yet
because
it's
not
been
battle
tested
enough.
At
least
personally,
I.
K
F
Yeah,
the
other
I
had
briefly
in
the
notes,
because
now
that
we
do
have
several
implementations,
there's
like
that,
I
think
there's
something
there's
something
in
tecton:
there's
various
provenance
generators
there's
something
and
a
couple
in
total
implementations
how
we
keep
track
of
these
and
kind
of
update
them
as
we
go.
I
I
don't
have
any
experience
doing
this
in
the
open
source
world.
L
Yeah
agreed,
one
thing
I
just
wanted
to
point
out
is
yeah
yeah,
so
from
the
cncf
side
right
we
are
building
out
that
reference
architecture,
building
out
the
reference
implementation
and
we
do
plan
to
say,
hey
assuming
you
follow
all
the
rules
in
the
reference
architecture.
This
is
your
general
sort
of
salsa
level
that
the
artifacts
that
are
being
produced
should
be,
and
so
we'd
love
to
be
able
to
kind
of
like
link
to.
However,
you
wanna,
however,
we
to
kind
of
show
that
off.
F
Anyway,
we
could
probably
discuss
that
on
you
know
offline.
We
could
shall
we
move
on
to
the
next
topic.
A
M
Hey
I'm
on
the
call,
hi,
hello,
hello,
everyone.
I've
just
put
a
link
into
the
chat
as
well.
It's
also
in
the
community
meeting
notes
for
those
who
want
to
see
it
there
so
hi
everyone
for
those
who
don't
know
me,
I'm
from
a
company
called
projects
by
if
we
helped
build
up
the
current
source.dev
sites.
M
I
was
based
on
research
with
a
chunk
of
potential
social
users
and
other
people
across
the
open
source,
various
people
across
the
open
source
community
to
work
out
what
people
wanted
there
we're
just
planning
to
do
some
more
updates
over
the
time
frame
through
to
early
december
starting
within
the
next
week
or
two.
M
The
document
just
contains
an
overview
of
what,
where
what
we're
planning
to
do
at
this
point.
So,
firstly,
there's
going
to
be
updates
to
the
solstice.website
design,
so
visual
presentation
branding
some
better
illustrations
to
support
some
of
the
key
messages
and
use
cases
and
the
new
threat
threats
diagram.
Although
now
the
threats
diagram
was
in
the
operation,
salsa
video,
which
I
think
starts
later,
I'm
worried
about
changing
that
because
of
the
the
operation
source
of
video
is
important
to
the
community.
M
I
know
that
the
looking
at
some
content
around
the
steering
committee
and
community
activity
and
we'll
be
contacting
you
to
get
some
input,
various
members
of
the
community
to
get
inputs
for
that,
the
looking
at
the
salsa
ladder
themselves
motivation
ladder
and
how
that
can
be
incorporated
and
made
more
public
through
the
web
presence,
as
well
as
in
the
github
reposing
issues
where
it's
being
discussed
at
the
moment.
I
know
that's
discussed
at
one
of
the
previous
community
meetings,
the
I'm
going
to
be
measuring
this.
M
If
that
happened,
the
desired
effect
of
communicating
the
concepts
cleanly
helping
inform
people
and
helping
increase
adoption
of
bringing
more
people
in
to
take
advantage
of
the
great
work
you're
doing
while
understanding
things
like
the
the
caveats
the
mark
just
mentioned
around.
This
is
in
this
early
stage
of
development
and
adoption
by
various
people,
just
to
make
sure
we're
communicating
those
things
nice
and
clearly
the
obviously
all
of
the
work
we're
doing
will
go
through
the
standard
governance
processes
we'll
go
through
as
pull
requests.
M
Now
we
can
also
present
back
at
subsequent
community
meetings.
If
that
would
be
useful
as
entrant
steps,
we
can
do
that
there,
let's
say
as
well
as
through
the
github
repo,
so
we're
happy
with
those
things
and
we're
also
obviously
also
happy.
I
still
have
to
share
the
google
document.
Everyone
should
have
edit
rights.
I
can
handle
I'll
handle
the
spam
on
that
myself.
M
But
the
do
you
feel
free
to
leave
comments,
suggestions
or
to
contact
myself
or
dev
deb,
morgan
appropriately,
who's
actually
on
holiday
this
week.
So
I'm
standing
in
for
him
with
any
comments,
suggestions,
ideas
or
how
you'd
like
to
get
involved
and
we'll
work
that
into
our
planning.
As
we
get
the
team
up
and
running,
I
spoke
fairly
fast
covered
a
bit
around,
but
hopefully
the
document
is
fairly
self-explanatory
as
well,
and
I'm
up
for
questions
or
I'll
go
back
on
news.
A
Yeah,
I
think,
whenever
you
want
to
come
present
or
update
a
community
or
could
use
community
feedback
just
put
yourself
in
the
agenda,
I'm
looking
forward
to
new
new
improvements
to
the
site,
thanks
peter
all,
right,
let's
see
a
couple
more
items
left
next
is
matt.
We're
gonna
talk
about
build
his
code
issue,
there's
a
link
in
the
in
the
dock
for
the
issue.
I
guess
number
188
in
the
repo.
E
Yeah,
so
there
was
some
discussion
on
the
issue
as
well,
but
just
I
think,
the
wording
in
isolation.
I
found
somewhat
confusing
sort
of
as
a
line
item
and
effectively.
I
think
what
it
comes
down
to
is
concern
around
at
higher
salsa
levels.
The
configuration
coming
in
as
the
input
being
used
to
effectively
validate
itself
right.
E
I
think
you
know,
I
think
the
issue
sort
of
spelled
out
how
some
of
the
different
aspects
of
salsa
are
intended
to
sort
of
complement
each
other
and
work
together
to
achieve
some
of
those
things.
But
I
think
we
may
want
to
find
ways
to
clarify
some
of
those
things
sort
of.
E
If,
if
they're
being
looked
at
in
a
more
a
la
carte
fashion,
then
I
need
all
of
the
salsa
three
things
to
achieve
this
thing
so
that
it's
clear
what
what
things
folks
might
be
giving
up
as
they
you
know,
drop
one
thing
or
another
thing,
and
even
that
may
be
somewhat
context-sensitive
right.
E
I'm
reminded
of
sort
of
what
trishank
was
bringing
up
at
the
beginning,
with
sort
of
some
things
being
trivially,
verifiable,
sorry,
trivially
non-falsifiable,
because
you
can
sort
of
reverse
the
output
to
get
back
to
the
inputs,
so
so
yeah.
I
don't
know
how
much
we
want
to
talk
about
this
mark
trishank.
Do
you
want
to
talk
about
any
parts
of
this.
F
Yeah,
I
think
I
think,
that's
a
really
good
point.
Matt
I
had
also,
I
think,
talked
to
some
other
folks
about
the
same
thing.
F
One
aspect
of
it
like
because
he
said,
like
you
know
the
code
config
evaluates
itself,
I
think
there's
an
unspoken
thing
that
needs
to
be
documented,
which
is
that
some
of
the
requirements
like
the
project
owner
or
whatever
we
want
to
call
it
like
the
software
owner
can
do
right,
switching
to
a
new
build
system
or
making
a
build
reproducer
or
something
like
that,
and
then
other
things.
F
The
build
platform
has
to
provide
like
the
isolation
between
builds
and
like
proper
protection
of
the
signing,
keys
and
things,
and
there's
this
unspoken
or
this
unwritten
principle
that
we
need
to
document
which
is
around
kind
of
reducing
the
trust
base.
That,
like
we
are
well.
One
thing
is
that
we're
kind
of
mapping
from
build
back
to
the
source.
I
think
trishank
mentioned
that
in
his
his
slide
too.
F
Of
the
principles,
another
principle
is
that
we
shouldn't-
or
at
least
in
my.
F
That
we
should
discuss
and
agree
upon
this
group
is
that
we
don't
want
to
trust
like
the
the
million
developers
out
there,
but
maybe
we
trust
a
couple.
Small
organizations
like
if
you
trust
github
actions
to
do
your
build
or
travis
or
whatever
your
system
is,
or
a
system
of
reproducible
builds
or
whatever
reason,
but
we're
kind
of
we
want
to
kind
of
explicitly
enumerate
what
the
trust
base
is
and
shrink
that
as
much
as
possible.
C
But
that
is
not
what
you're
actually
going
to
use
at
the
end
of
the
day
to
verify
your
artifact,
because
the
thing
that
should
be
establishing
trust
for
what
you
say
cd
looks
like
is
not
those
yaml
files,
but
the
in
total
layout
that
I
was
talking
about
earlier
now,
I'm
not
sure
yet
vezr
is
the
salsa,
have
a
place
for
layout
files
yet
or
are
we
so
far
doing
at
a
station
so
far,
basically
the
equivalent
link
files,
but
no
layout
yet,
did
I
miss
something.
N
F
That's
you're
right,
that's
unspecified
right
now
we
had
been
calling
that
policy
layout
in
total
layout
was
kind
of
one
way
of
evaluating
policy,
and-
and
I
think
the
thing
that
entoto
in
particular
brings-
is
the
ability
to
kind
of
sign
and
distribute
a
policy
that
someone
else
can
evaluate,
and
how
do
you
know
that
it's
like
a
legitimate
policy
that
still
has
to
be
worked
out
originally
in
the
in
one
of
the
very
early
drafts
we
had
stuff
around
policy,
it
was
confusing
and
we
couldn't
agree
on
it.
F
G
Yeah
well-
and
I
I
I
tried
to
talk
about
that,
some
in
in
joshua
and
my
talk
on
on
on
salsa,
but
I
think
that
I
disagree
with
with
with
the
point
that
the
yaml
files
aren't
aren't,
aren't
important
what
like
what?
G
What
what
we're
trying
to
do
with
like
having
the
attestations
reference,
the
the
the
yaml
files
and
then
have
the
policies
say
which
which
ammo
files
are
are
are
acceptable,
is
to
provide
the
ability
for
users
to
look
at
a
policy
file
and
say
and
and
like
immediately
understand
and
immediately
understand,
like
what
what
is
appropriate
and
one
of
the
like
one
of
the
issues
with
like
simply
having
simply
having
at
the
stations
record.
Every
single
step
that
occurred
in
a
ci
cd
pipeline
is
that
an
end
user
who's.
G
G
What
having
end
user
policy
focused
around
the
focus
around
the
build
instruction
specification,
which
is
what
the
yaml
file
is
and
having
that
specification
stored
in
source
control
that
requires
two-party
review
is,
is,
is
that
then
they
can
say
one
which,
which
source
rico
is
this
they
can
go
and
they
can
look
and
like
they
can
look
at
that
file
and
and
like
get
an
idea.
Okay,
like
is
this
the
like
curl
cloud,
build
yaml
and
like
do.
G
I
trust
the
build
system
that
produced
this
attestation
that
says
that
artifact
with
hash
xyz
came
like
came
from
like
was
built
in
accordance
with
like
these
instructions,
because
the
end
user
doesn't
care
about
all
of
those
details
and
they
can't
like
they're,
not
really
in
a
position
to
say
if
they're
correct,
but
but
I
think
that,
as
as
as
you've
outlined
and
as
we've
discussed
like
that,
there
is
a
place
for
for
that.
For
for
what
entotle
is
doing
with
with
the
layouts.
G
C
Yeah,
yes,
yes,
where
I
would
disagree,
is
that
so
the
definition
of
build
pipeline
is
important,
but
you're
missing
two
two
pieces
of
information
there,
one
is
it's:
it's
not
it's
not
so
the
way
internal
attestations
assign
internal
policy
files
the
way
the
way
mark
puts
it
would
be
signed.
That's
the
difference
between
these
yamls
and
the
policy
or
layout
files
is
that
one
is
immutable
right,
cryptographically.
C
This
is
what
the
shape
of
your
pipeline
is
supposed
to
look
like
and
who's
supposed
to
use.
What
keys
in
the
first
place,
I
think
those
crucial
and
that
crucial
information
is
missing
from
the
ammo
files
which
don't
get
me
wrong.
I
think
super
important.
Yes,.
G
Right
and,
and
so
the
yellow
file
is
like
just
a
part
of
it
that
like
in
the
talk
we
discuss,
how
how
how
policy
file
should
should
specify
should
specify
which,
which
yaml
file
is,
is
the
policy
file
specifies
which
yaml
file
should
should
should
have
been
executed
in
the
policy
file
also
specifies
which
builder
should
have
been
used
and
that
builder
maps
to
some
set
of
keys.
A
All
right,
I
had
to
step
away
to
grab
a
sweatshirt.
Were
you
saying
we're
ready
to
cover
the
last
couple?
A
Always
yeah,
okay
cool?
So
I
added
on
here
there
was
an
open,
ssf
tac
meeting
for
those
folks
on
the
call
who
haven't
seen
the
open,
ssf
has
kind
of
re-uh
revamped
itself
and
now
there's
a
new
structuring
of
the
governing
board
and
there's
premier
members.
Now
that
are
paying
money.
The
first
year
of
existence
covet
hit
and
it
was
sort
of
free
for
members
to
join
anyway.
They
are
looking
now
for
for
budget
proposals
for
projects
so
things
that
projects
might
need.
A
So
I
think
for
salsa,
maybe
a
couple
of
things
or
maybe
some
some
help
with
the
website
is
one
possibility.
If
community
feels
like
that's
important,
schwag
is
another
fun
one
that
we
could
put
together
some
some
t-shirts
with
the
with
our
fun
goose
and
the
salsa
dress
on.
A
So
I
don't
know
all
the
details
david
actually
might
know
more
than
me
looks
like
he's
on
the
call
now,
if
he's
anything,
to
share,
if
there's
any
timelines
or
deadlines,
we
need
to
be
aware
of
to
get
those
proposals
in
or
and
how
these
are
being
shaped,
but
just
wanted
to
throw
that
out.
There.
O
I
I
I
can
quickly
answer,
which
is
I
I
don't
have
a
deadline,
but
I
have
an
end
deadline.
You
can
work
back.
We
would
like
to
summarize
some
things
for
at
least
the
starting
of
the
session
discussion
at
the
november
5
governing
board,
but
that
means
that
we've
got
to
get
ideas
and
I
think
the
idea
is
we're
good.
You
know
brian,
and
I
are
probably
going
to
collate
all
these
ideas
to
at
least
begin
that
discussion.
O
I
don't
think
it
has
to
be
resolved
november,
5
necessarily,
but
you
know
we
we'd
like
to
at
least
start
collecting
those,
so
I
I
would
think
by
next
week.
We'd
want
to
get
some
of
those
ideas
and
I
I
would
say
just
posting
all
mailing
on,
like
the
various
mail
working
group
mailing
lists,
I
intend
to
send
out
an
email
later
today,
begging
for
suggestions.
O
O
Start
posting
and
we'll
start
collecting
and
at
least
to
start
that
discussion.
A
Cool
yeah-
I
don't
know
if,
like
infrastructure
credits,
is
something
this
project
needs
yet,
but,
like
things
like
that,
are,
I
think,
on
the
table.
So
so
look
out
for
the
email
from
david
and
we
can
try
to
collect
some
things
if
there's
anything
and
then
pass
it
up
to
the
to
the
governing
board
intact
for
decision
and
then
the
last
thing
I
had
on
the
agenda.
We
we
heard
a
couple
mentions
of
this
of
peter
in
case
folks,
haven't
seen
it
yet
there's
operation,
salsa
video.
A
This
was
quite
a
fun
project
that
I
somehow
got
talked
into
priya.
The
star
of
our
show
is
on
the
call
and
talked
to
us
earlier
today.
Definitely
check
it
out.
It
was,
you
know,
a
fun
way
for
us
to
try
to
help,
explain
salsa
more
broadly,
to
you
know,
broader
audiences,
to
help
drive
awareness.
I
do
think
peter.
A
I
do
think
that
I
actually
don't
know
how
much
work
it
is,
but
the
screen
was
a
green
screen,
so
we
can
swap
out
the
diagram
if
need
be,
and
you
know
I
think,
sort
of
some
of
our
original
goals
doing
this
was
to
really
drive
into
like
the
threats
and
and
try
to
try
to
build
out
the
video
series
that
way.
Of
course,
these
are
very
expensive
to
make.
A
O
A
A
So
I
think
it's
up
to
like
6
000
views
now
too,
which
is
pretty,
which
is
pretty
good
cool
all
right.
I
think
we're
about
out
of
time.
Next
week
we
have
a
presentation
from
the
microsoft
folks
on
a
project,
that's
called
skim
and
then
a
couple
and
then
josh
and
trishank
have
a
topic
for
artifact
signing
key
distribution,
and
I
think
someone
suggested
maybe
doing
a
deep
dive
on
the
nyx
stuff.
So
maybe
that'll
come
in
too,
but
feel
free
to
add
other
things.
A
We
might
have
time
for
a
couple
more
topics
if
folks
want
to
add
them.
So
all
right,
thank
you,
everyone
and
we
will
catch
up
in
a
few
weeks.
O
Thank
you.
Will
someone
post
the
links
to
the
to
this
gathering,
because
I
wanted
to
see
this
demo
that
I
missed
earlier.
A
Yeah,
I
am
finally
figuring
out.
Zoom
light
gives
eight
files
when
you
record
a
session,
and
now
I
finally
have
access
to
the
zoom
account,
and
then
I
have
to
figure
out
which
video
it
is
and
then
and
then
I'll
get
it
uploaded
to
the
to
the
open,
ssf
youtube
channel.
O
A
Yeah,
I
I'll
send
it
I'll,
send
a
link
in
the
slack
when
I,
when
I
do
that,
and
then
I
try
to
add
a
link
back
to
the
note
stock
too,
for
the
recording.
So
oh
awesome
that
would
be.