►
From YouTube: SLSA Meeting (September 22, 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
Yeah
I'd
be
happy
to
meet.
Do
you
want
to
like
set
up
the
initial
communication
around
that
that'd
be
great.
A
A
A
B
Cool
any
other
topics
or
mark.
Do
you
want
to
jump
into
your
your
demo
next.
A
A
Okay,
I'll
take
that
so
I
matt
smozo
and
I
have
been
excuse
me
still
recovering
from
gold,
putting
an
like
an
end-to-end
demo
together
for
salsa
on
showing
like
the
idea
of
how
the
things
come
together,
so
that
is
generating
province,
uploading
provenance
somewhere,
something
checks.
The
provenance
verifies.
The
hashes
displays
information,
make
some
sort
of
policy
decision.
A
I
I
don't
know,
I
don't
think
it
matters
too
much
exactly
what
the
details
are,
but
just
we
want
something
to
show
this
to
have
some
actual
code
and
something
to
work
with.
So
we
have
something
to
build
off
of.
A
We
are
we're
still
looking
at
the
very
early
design
stages
and
like
don't
even
have
like
public
code.
Yet
that's
that's
really
working
and
we're
still
kind
of
hashing
through
some
of
the
difficult
problems.
But
if
anyone
is
interested
in
like
working
on
this
or
contributing
or
let
us
know,
I
think
once
we
get
a
little
further
along
we'll
put.
C
A
The
the
main
thing
that
matt
and
I
had
just
to
give
like
a
status
update
that
matt
and
I
just
discussed
earlier
today-
was
the
notion
around
like
just
kind
of
like
how
all
the
pieces
work.
I
don't
think
we
have
to
get
it
right
on
the
first
try,
but
I'd
like
to
try
to
get
something
working.
A
If
we
just
have
some
sort
of
storage
system
where
provenance
is
keyed
by
hash
and
anyone
can
upload
providence,
we
have
the
situation
that
we
actually
ran
into
internally
in
google,
which
is
that
you
might
have
one
hash
that
has
a
bunch
of
different
entries
like
in
some
cases.
You
could
even
have
millions
of
entries,
especially
if,
like
people
are
doing
this,
maliciously
intentionally
uploading
a
bunch
of
garbage
for
a
good
cash.
So,
let's
take
php
for
the
example.
A
A
We
want
to
kind
of
show
the
idea
so
anyway,
that's
what
we're
looking
at
trishanks.
C
It's
a
solvable
problem
right
and
and
there's
one
way
that
we
plan
to
is
joshua
nicole.
I
believe
he
is
there's
one
way
that
joshua
and
I
are
planning
to
write
about
a
datadog
we're
using
this
thing,
called
tough
to
uniquely
associate
a
set
of
attestations
with
artifacts.
C
A
C
Yeah
good
question:
in
fact,
let
me
let
me
let
me
show
my
screen
just
so
you
can
take
a
look
me
trying
to
hand
wave
about
it.
Oops
can
I
share
my
screen?
Is
it
okay,
kim.
C
So
if
you
take
like
this
wheel,
for
example,
it's
a
binary
and
then
we
can
put
something
called
custom
metadata
and
tap
where
we
can
say:
here's
the
in
total
root
layout
you
use
and
then
here
all
the
attestations
you
can
find
the
classic
link
files.
As
for
who's
allowed
to
sign
this
file,
that's
up
to
you
to
define.
C
C
Right,
so
what
you
would
in
the
beginning,
if
you
okay,
let
me
put
it
this
way
in
the
beginning,
so
in
this
case
we
can
trust
machines
because
and
I'll
get
to
why
so
in
the
beginning,
if
you
only
have
a
bunch
of
attestations
right
associated
with
the
link,
I
mean
associated
with
the
artifact,
and
you
don't
have
the
layout
and
you
trust
machines
to
so
machines
do
sign
this
file.
So
what
can
happen
here
so
good?
C
Exactly
machines
can
give
you
a
unique
association
between
attestations
and
artifacts,
but
that
gives
you
no
reason
necessarily
to
trust
the
machine.
So
how
do
you
double
check
the
machine?
Well,
in
this
case,
we
also
associate
the
the
rules
of
the
game,
the
the
root
layout
file,
as
it's
called
in
in
dodo
that
lets
you
find
out
that
the
machine
is
trying
to
trick
you.
In
other
words,
it
tells
you
why
these
attestations
are
trustworthy
in
the
first
place.
C
Or
in
your
case,
I
think
I'm
not
sure
whether
salsa
is
attaching
root
layouts,
yet
I'm
not
sure
about
this.
So
if
it's
at
this
sorry
go
ahead.
Oh
sorry,
I
didn't
mean.
A
So
my
my
concern
is
not
so
much
like
the
security
and
the
crypto
part
of
it
like,
like
the
authorization
part
but
more
of
the
storage
and
lookup
when
like
when.
A
Not
today,
that's
not
a
problem,
but
like
the
problem
that
I'm
thinking
about
is
when
we
have
an
artifact
like
file
with
hash
73
c7.
When
someone
goes
to
verify
it,
how
do
they
find
these
attestations
right
right
here
is
millions
and
millions
and
millions
of
them.
How
do
they
sift
through
them
and
not
have
to
do
an
operation?
That's
you
know
of
n,
for
the
number
of
attestations
that
anyone
in
the
world
has
ever
uploaded.
E
Yeah
and
I'm
sorry,
I
would
use
the
like
raised
hand
feature,
but
I'm
in
a
meeting
room
that
doesn't
have
that.
So
I
I'm
I
mentioned
something
in
the
note
stock,
and
that
is
I'm
wondering
if
we
should
standardize
on
the
osv
method,
where
they
have
this.
E
This
affected
package
field
that
includes
the
the
ecosystem
and
then
the
package
name
within
that
that
that
ecosystem,
at
least
as
a
starting
point
and
like
like
potentially,
we
would
need
to
like
further
refine
it,
but
like
at
least
being
compatible
with
with
osv
seems
like
it
would
have
some
advantages.
C
Yeah,
like
I
said
there
are
many
ways
to
solve
this
problem.
In
fact,
it's
something
that
might
be
easier
to
start
with
right
now,
so
I'm
just
showing
one
way
that
we
did
it
one
way
is
to
use
stuff.
Basically
someone
someone
has
to
be
responsible
for
securely
signing
and
distributing
this
right
could
be,
could
be
the
salsa
project
in
this
case,
just
just
to
show
the
example,
I
think
a
simple
solution
for
now
would
be
using
maybe
sigstor.
C
So
what
you
do
is
you
record
the
attestations
first
individually
on
six
star,
I'm
just
brainstorming
here,
I'm
not
sure
whether
this
would
work,
someone
from
sixth
or
correct
me
if
I'm
wrong.
What
you
do
is
you
record
the
attestations
first
on
on
on
on
recur
right
and
then
you
associate,
and
then
you
record
the
artifact
itself
and
part
the
metadata
for
the
artifact
permanently
recorded.
Now,
no
one
can
change.
It
is
what
attestations
you're
supposed
to
look
for
for
it.
Also
and
now
you
have
log
log
n
lookup
right,
it's
very
efficient.
F
So
the
the
attestations
live
alongside
the
artifact,
typically
in
the
registry
right.
What
goes
in
recore,
I
think,
is
just
the
record
of
things
like
the
ephemeral
certificate
issuance
right.
C
Now
the
question
really
becomes
so
I
think
wrecker
can
can
solve
this
weaker
record.
Sorry,
someone
correct
me
if
I'm
wrong
but
wrecker
can
can
can
store
the
at
the
stations
and
can
associate
artifacts
with
other
stations
yeah
exactly
a
record
so
wrecker.
Now.
The
problem
I
think,
boils
down
to.
Why
should
you
trust
the
other
stations?
How
do
you
know
which
keys
you're
supposed
to
use
for
the
attestation.
G
So
that's
actually
something
I'm
chatting
with
some
folks
on
now.
I
know
that
at
least
the
some
of
the
sorry,
not
out
of
the
signature
spec,
can
sort
of
refer
to
an
identifier
for
the
key,
so
it
can
give
a
hint
around
what
key
you
should
be
actually
looking
for,
but
I
think
that's
I
know
from
my
perspective,
one
of
the
big
open
questions
is
who
has
that
set
of
you
know
who
is
who
who
is
providing
the
set
of
t
for
the
end
user
of
like
hey?
G
E
So
I
was
just
trying
to
to
to
look
it
up.
I
think,
there's
I
think,
there's
a
salsa
issue
related
to
this
question.
I
like,
like,
I
personally,
see,
see
a
couple
of
different
options.
One
is
if
we
follow
like
like
a
ca
searching
model,
you
could
have
the
the
open
ssf
could
have
like
four
different
keys.
One
one
for
each
salsa
level
and
like
open
ssf
could
could
could
theoretically
sign
anyone's.
C
E
As
as
as
like,
l1
and
l2,
and
then
for
like
l3
and
l4,
maybe
there's
some
process
that
people
need
to
go
through
like
a
security
evaluation
whatever
and
then
once
once
like,
open
ssf
is
happy
they
could
like
like
they
could
sign
those
they
could
sign
those
keys
for
for
folks
and
then
the
end
user
doesn't
need
to
care
about
the
specific
keys
that
the
builder
uses,
but
instead
they
just
need
to
root
their
trust
in
whatever
opens
as
open
ssf
says,
and
of
course
it
could
be
any
one.
E
It
doesn't
have
to
be
open,
ssf
or
could
be
open,
ssf
and
like
like,
like
other
orgs,
the
same
way
that
browsers
have
have
have
like
built-in
roots
routes
that
they
trust.
Another
option,
like
just
to
start,
is
like
just
set
up
a
github
repo
and
let
people
check
in
their
their
their
keys
there.
E
F
Just
to
make
sure
I
understand
right
so
in
in
a
model
like
six
stores,
where
you've
got
things
like
full,
the
full
co
route
right
with
the
equivalent
of
this
being
being
at
something
like
having
a
full
seo
route
for
each
salsa
level.
And
then
you
know,
as
you
know,
vendors
or
whoever
sort
of
established
that
they're
producing
things
conformant
with
a
particular
salsa
level,
they
can
become
a
trusted
delegate
of
the
folso
route.
For
that
salsa
level.
Is
that
does?
Is
that
sort
of
in
line
with
what
you
just
said.
H
Yeah,
can
I
I
have
this
like.
I
want
to
jump
in
on
both
of
what
you
both
are
saying.
So
I
have
this
like
six
or
trust
allegations
that,
like
I
am
proposing
that
we
add
in
delegations
into
our
tough
route
for
six
store
which
contains
information
about.
H
You
know
the
full
co
cert
that
we
trust
and
the
recoil
keys
that
we
trust
and
so
on,
and
so
the
proposal
in
specific,
like
adding
these
delegations,
what
they
could
do
is
either
they
could
delegate
to
another
project's
root
of
trust
or
they
could
delegate
to
exactly
what
you
I
don't
know
which
room
you
are.
So
I
don't
know
what
your
name
is,
because
your
phone
room
right
now,
but.
H
Tom,
okay,
so
exactly
what
tom
was
saying,
we're
like
we
could
add
delegations
for
levels
and
then
those
delegations
would
contain
your
trust
so
and
because
route
signing
repository
like
our
six
store,
tough
route
lives
on
a
github
repo,
like
all
that
could
be
automated
with
pull
requests.
So
the
idea
is
that,
like
we
would
have
like
a
sort
of
acme
style
challenge
too,
even
for
like
the
project
allegations
where
like.
H
If
we're
delegating
trust
to
a
certain
project
over
some
name
space
and
a
repository,
we
say:
okay,
you
know,
go
sign,
you
know
blah
challenge
and
put
it
on
your
repository,
okay,
cool.
We
trust
you
to
distribute
artifacts
there
and
and
the
associated
keys.
So
that's
my
like
strumming
proposal
about
it,
but
I
don't
think
I
like.
H
I
would
love
to
hear
if
someone's
super
familiar
with
the
salsa
side
of
this,
what
they
think
of
like
doing
something
like
that,
and
I
probably
will
get
a
demo
of
what
I
think
it
looks
like
on
like
a
toy
repository
that
you
could
set
up
for
like
salsa
levels
and
and
yeah
I'll
distribute
it.
A
So
I
so
how
for
this
or
any
other
system
like
how
does
this
work?
A
If
you
have
something
like
a
a
ci
platform
like
github
actions
or
google
cloud,
build
or
azure
pipelines,
or
whatever
circle
ci,
which
is
one
entity
that
we
trust,
but
then
it's
multi-tenant
and
it
has
millions
of
different
users
and
I'm
we
would
probably
want
to
trust
each
of
those
different
users
differently,
but
so,
for
example,
if
we
want
to
trust,
let's
say
github
actions
to
do
the
build,
because
we,
for
whatever
reason,
have
analyzed
it,
we
say
their
architecture
is
good
enough.
A
A
How
do
we
kind
of
sift
through
that?
That's
that's
my
question
like.
Would
they
all
be
signed
with
the
same
key,
whether
it
be
some
sort
of
delegation
model.
F
Absolutely
I
I
expect
it
would
depend
significantly
on
how
you
were
using
something
like
actions
right,
and
so
I
mean
one
one
conceivable
way
well
in
my
in
my
head
right
would
be
if
github
could
effectively
analyze
an
action,
and
you
know
deduce
that
it
might
qualify
for
a
higher
level
of
salsa
that
then,
when
it
does
the
interaction
with
something
like
full
co2d
certificate
issuance.
Maybe
it's
hitting
their
trusted
delegate
of
full
co
and
based
on
the
workflow,
that's
being
run
and
it's
you
know,
satisfaction
of
a
particular
salsa
level.
F
It
you
know
signs
it
with
the
appropriate
route
for
the
appropriate
salsa
level
for
that
workflow.
But
you
know
that
I
think
it
would
depend
a
lot
on
what
you
put
into
your
actions
right
so
like
for
salsa
for
hermetic.
I
don't
even
think
there's
a
I
don't
know
of
a
way
of
doing
that
in
actions
today,
so
you
know
I
I
think
it
would.
You
would
have
to
effectively.
F
You
know
configure
your
workflows,
I
think,
based
on
these
levels-
and
you
know
I
think
that
would
affect
the
route
that
something
like
a
github
trusted
delegate
would
then
sign
with.
But
that's
the
picture
in
my
head.
F
E
I
I
I
might
actually.
I
might
actually
disagree
with
that.
I
I
so
I
think
it's
important
to
say
that,
like
I
don't
think
of
like
I
don't
think
of
of
the
signature
over
the
providence
as
like,
meaning
that
this
thing
that's,
I
that
the
providence
identifies
is
like
necessarily
trustworthy.
E
So
much
as
as
the
signature
like
if
the
signature
comes
comes
from
a
salsa
level,
four
builder,
then
then
you
know
that
what
is
in
the
providence
is
accurate,
and
then
you
still
need
to
compare
that
provenance
against
some
some
some
specific
policy
for
some
specific
use
case
to
to
to
know
if
that's
acceptable,
and
so,
if
we
can
trust
that,
like
github
actions
is,
is,
is
configured
such
that
the
provenance
always
reflects
reality,
which
is
like
this
is
exactly
what
github
actions
did.
E
Then
it
shouldn't
matter
if
if
a
thousand
different
projects
can
can
can
like
create
whatever
provenance
they
want
because
or
apartment,
they
can't
create
whatever
providence
they
want.
They
can
only
create
provenance
that
that
that
says
this
is
the
github
actions
workflow
that
that
that
was
run.
It
was
run
from
from
from
this
source
repo
and
like
produced
this
thing
with
this
output
like
that
should
be
true.
That
should
be
true
sort
of
regardless
of
of
of
who
of
who
does
it.
F
I
think
what
you're
saying
is
sort
of
a
meta
level
right
like
okay.
Yes,
the
control
plan
was
salsa
level
four,
and
it
basically
is
asserting
things
with
a
high
degree
of
confidence.
That
does
not
mean
that
the
the
workflow
that
was
run,
the
things
coming
out.
The
other
side
are
also
level
four.
But
the
statement
that
is
being
made
is:
is
that
what
you're
saying
the
nuance.
E
Yes,
so
like
at
the
very
least
when
I
think
about
when
I
think
about
making
decisions
about
an
artifact
that
that
a
couple
different
things
come
into
play,
one
one
is
the
builder
level,
which
is
what
github
actions
would
would
have.
Another
is,
is,
is
the
source
control
level,
and
that,
and
and
and
for
that,
that
matters
like
like
did
the
repo
have
like
two-party
review
required?
Did
the
repo
meet
all
the
level
four
source
requirements
and
then
further
there
are?
E
There
are
more
requirements
about
the
build
specifically
like?
Is
it
using
config
as
code
like?
Was
it
run
in
the
hermetic
way,
because
you
could
easily
see
that
github
might
have
a
flag
where,
like
people
can
say,
hey
my
build,
isn't
hermetic,
so
you
know,
let
me
do
whatever
I
want
and
that's
certainly
not
going
to
be
a
salsa
level.
4
artifact
right.
D
We
haven't
really
said
anything
about
like
disaggregating
levels
between
sets
of
requirements.
We
don't
have
separate
source
and
build
levels.
I
think
at
the
moment
we're
still
talking
about
a
single
level,
but,
what's
being
alluded
to
is
like
I,
I
think,
picking
out
the
properties
of
a
build
system
like?
D
Is
it
isolated,
right,
multi-tenant,
single
tenant
and
having
that
be
sort
of
established
so
that
downstream
consumers
policy
evaluators
could
say
you
know
all
of
these
boxes
are
checked
but,
like
you
know,
the
source
repo
wasn't
two-party,
so
this
is
gonna
have
to
be
l3
yeah,
so
establishing
sort
of
a
common
set
of
build
properties
which
is
effectively
the
like
build
level
you're
talking
about
the
like
max
build
sorry,
the
max
level
a
build
can
qualify
for
if
running
on
this
platform,
yeah,
I
think
is,
is
something
that
could
be
done
in
a
repo
could
be.
D
G
So
one
thought
so
as
somebody
who's,
mostly
as
a
consumer
of
a
lot
of
this
data.
That's
coming
in
you
know
to
say:
hey,
you
know.
Yes,
this
thing's
salsa,
I
know
one
of
the
big
things
for
us
is
is
more
along
the
lines
of
did
the
person
you
know
did
a
did
a
key
that
I
trust
sign
this
thing.
A
lot
of
the
other
details
are
kind
of
less
important
for
us,
obviously
long
term.
We
do
want
to
sort
of
say
yes,
assuming
you
know.
G
Github
is
reporting
all
the
right
information,
and,
assuming
that
you
know
the
cic
dis,
ci
cd
systems
are
secured
a
certain
way.
You
know
now
we're
going
to
be
you
know,
but
but
for
us
a
lot
of
it's
it's
about.
Trusting
like
you
know
what
developers,
what
organizations
and
so
on
do
we
trust
to
sort
of
be
giving
us
these
things
to
be.
G
You
know
giving
us
these
artifacts
and
a
lot
of
those
other
things
matter
a
little
bit
less,
because
I
I
know
for
for
one
of
the
big
challenges
right
is:
how
deep
do
you
go
with
these
things
right
like
are.
We
are
we
gonna
start
attesting
to
like
the
operating
system
needs
to
have
certain
controls
around
it
before
we
trust
the
ci
cd
system
and
so
on.
D
G
Yeah
and
and
for
what
it's
worth
probably
by
next
week,
I'll
have
a
sort
of
a
full
end-to-end
demo
of
this
sort
of
thing,
with
oci.
G
So
storing
literally
all
the
sort
of
stuff
in
you
know,
say
I
know
that
doesn't
help
out
with
some
of
the
package
stuff
but
sort
of
doing
everything
and
including
the
materials
themselves
as
signed
blobs
inside
of
oci
and
then
and
all
that
sort
of
stuff
and
using
tecton
and
using
oppa
to
actually
validate
that
the
the
ad
state,
as
well
as
being
able
to
audit
the
the
the
blobs.
If
anybody
was
sort
of
interested
in
the
next
couple
of
weeks.
A
A
I
think
that's
that's
the
best
in
parallel,
we'll
try
to
come
up
with
something,
because
I,
what
I
want
to
do
out
of
this
is
like
have
some
motivation
for
when
we
talk
to
other
package
ecosystems
to
show
them
how
it
would
work
for
this
particular
ecosystem
and
say:
look
here's
like
the
top
here's
several
top
end
packages,
here's
how
it
actually
works
just
to
kind
of
like
iron
out
the
kinks,
because
I
know
from
experience
internally
within
our
company
when
we
went
to
different
organizations
and
said
like
hey,
we
wanted
you
to
make
these
invasive
changes
to
your
system.
A
E
A
B
Cool
any
other,
any
other
comments
on
that
mark
or
no,
I
think.
A
Basically,
what
will
will
come?
I
suspect
what
we'll
do
for
our
first
version
that
feel
free
to
pick
up.
If
you
disagree
is
just
like
do
something
that
just
works
like
what
it's
not
going
to
solve
the
real
problems,
just
throw
something
together
to
show
the
idea,
and
then
we
could
kind
of
like
fix
pieces
as
we
go,
because
my
interest
is
getting
something
kind
of
working
as
soon
as
possible.
Even
if
it's
like
unwieldy.
B
Sounds
good,
I
think
that
is
that
is
all
we
have
today.
There
is
oh
yeah.
Wait
there.
There
is
a.
There
is
a
another
topic.
I
think
tom
you
want
to
discuss
is
about
the
different
providence
formats.
We
did
just
publish
a
blog
post
on
the
google
security
blog.
I
can
add
the
link
to
the
meeting
notes
and
it
brought
up
some
questions
on
sort
of
feedback
on
the
different
providence
formats
and
the
requirements
around
providence
format.
So
tom,
do
you
wanna.
E
Sure
so,
basically
it
it
sort
of
centers
around
the
salsa
requirement.
E
I
think
it's.
The
providence
is
available
requirement
that
says
that
the
providence
should
be
salsa
provenance,
the
that's
the
salsa.dev,
slash
provenance
format,
but
it's
just
should,
and
I
and
in
the
blog
post
going
up,
it
is
saying
that,
like
hey
like,
like
distrolus,
is
like
salsa
level
two,
we
meet
these
these
these
requirements
and
in
fact
it
is
producing
provenance,
but
it's
not
salsa
providence.
It's
a
tecton,
specific,
specific
format.
It
does
have
everything
that
is
strictly.
That
is
strictly
required
and
that's
definitely
an
advantage.
E
I
like,
I
think
my
concern
is
that
if
we
want
to
have
an
ecosystem
that
is
compatible
and
like
everything
just
works,
that
it
would
be
ideal
if,
if
everyone
were
using
the
same
province
format,
because
otherwise
policy
evaluation
points
need
to
understand
each
specific
builder's
providence
format
which
which
makes
scaling
hard,
and
so
I
guess
I
wonder
like,
should
we
be
more
forceful
than
should
in
the
requirements
or
should
we
have
any
messaging
like
really
really?
E
Please
please
please
produce
the
salsa
the
salsa
providence,
I
think,
as
an
aside
michael,
I
think
you
mentioned
in
slack
that
you
are
working
on
getting
tecton
to
produce
the
salsa
that
the
salsa
problems.
G
Yeah,
so
so
on
that
note,
it
might
just
be
as
simple
as
taking
the
chains
and
just
converting
it.
You
know,
or
or
otherwise
just
generating
that
as
another
consequence
of
another
task
or
something
like
that
right
and
and.
E
And
I
should
also
say
that,
like
we,
that
the
in
toto
bundle
format
does
does
require
that,
like
that,
like
readers,
ignore
anything
that
they
don't
understand
or
ignore
things
that
they
don't
care
about.
So
it
would
so
it's
actually
very
easy
for,
like
tekton
to
to
to
produce
both
the
tecton
providence,
which
can
have
which
can
have
a
ton
of
detail
and
can
be
very
specific
to
to
to
tecton
and
then
also
include
the
salsa
providence,
which
will
be
sort
of
more
sort
of
more
generic
and
consumable
by
anyone.
F
To
at
the
risk
of
asking
a
dumb
question,
have
we
looked
at
like
reconciling
the
thing
chains
did
and
the
thing
that
salsa
currently
is
to
figure
out
like
you
know
why
it
might
have
gone
off
and
done
something
different
from
salsa
in
the
first
place,
because
I
honestly
that
format
made
a
lot
more
sense
to
me
when
I
first
saw
it
than
the
salsa
one
did.
But
you
know
that's
just
my
you
know
personal
preference
and.
E
Biases,
so
my
my
understanding
and
anyone
that
knows
better
can
correct
me
if
I'm
wrong,
this
sort
of
came
out
of
what
was
eventually
resolved
with
the
configures
code
or
the
build
as
code
requirement
that,
like
wound
up
getting
getting
clarified
in
in
in
salsa
and
or
pardon
me,
the
build
as
code
and
the
build
instructions
requirements
that
currently
techton
does
not
support,
build
as
code
and
that
and
the
old
requirements
sort
of
implied
that
you
had
to
use
buildus
code
and
that
you
had
to
specify
a
specific
entry
point
that
was
that
was
stored
in
in
source
control.
E
So
so
the
new
requirements,
I'm
sort
of
clarify
that
at
salsa
level
that
up
to
salsa
level.
Two
that
you
don't
need
to
use,
build
this
code.
And
then
you
can
just
just
record
the
the
the
build
instructions.
And
that's
that's
sort
of
the
major
difference
is
that
the
tech
time
provenance
sort
of
records,
the
build
instructions-
and
there
are
many
of
them
and
the
and
the
salsa
providence
does
does
let
you
do
that
in
the
in
the
arguments
field.
E
But
it's,
but
it's
sort
of
it's
sort
of
generic
and,
like
builder
specific,
but
that
what
we
would
like
is.
We
would
like
people
to
use
build
as
code
so
that
they
can
simply
have
a
single
entry
point
which,
like
points
to
the
file,
that
defines
the
instructions
that
that
that
got
executed,
because
that
makes
policy
evaluation
a
lot
easier.
Instead
of
having
your
policy
say
like
like
these,
like
20
steps
must
have
been
followed,
must
have
been
followed
exactly.
F
So
so,
but
a
lot
a
lot
of
the
times
that
file
is
written
by
humans,
not
machines.
The
the
analogy
I
like
to
point
out
is
package.
Json
versus
packet
block
right,
take,
for
instance,
github
actions
right
you
reference
things
at
particular
versions,
but
you
don't
have
commit
sha's
checked
in
for
every
action
that
you're
evaluating
and
what's
coming
out
of
chains
is
you
know
not
the
sort
of
tags
that
are
appearing?
You
know
in
the
for
the
for
the
steps
that
are
run.
F
F
E
I
think
that
I
would
argue
that
the
that
the
config
file
number
one
in
addition
to
saying
hey
was
this
like
it
was
this
file
that
was
that
was
executed,
that
it's
also
referenced
in
the
materials
and
that
it
should
have
the
specific
commit
sha
of
of
of
that
file
and
then
that
the
that
the
containers
used
in
the
build
those
those
could-
and
I
don't
know
if
mark-
has
any
other
thoughts
here.
Those
could
simply
be
be
referenced
in
the
materials
section
as
like
hey.
E
I,
like,
I
used
these
like
10
different
containers
here
here
here
they
are.
F
F
E
I
think
that
I
that
I
might
not
be
not
be
entirely
understanding
like
what
like
what
we're
asking
for
is
like
not
the
machine
generated
file
that
we
want
users
to
to
to
provide,
but
rather
like,
like
the
cloudbuild.yaml
which
the
user
wrote
in
order
to
set
up
their
ci
cd
pipeline,
that
they
were
writing
anyways
to
sort
of
to
sort
of
automate
their
build.
F
Right-
and
so
my
point
is
that
I
would,
I
would
wager
that
the
vast
majority
of
cloud
build.gamils
reference
images
by
tags
and
I'm
saying
that
that
is
insufficient
to
evaluate
policy
against,
because
you
do
not
have
the
digest
of
those
things.
So
you
do
not
do
not
know
what
those
pointed
at
at
the
point
that
the
build
executed
right,
whereas
what
chains
is
producing,
is
the
resolved
digests
at
the
shaws
that
they
were
executed
at,
which
are
immutable
references
right.
F
A
I
I
think,
I
think,
the
intention
of
this
so
first
of
all
the
source
of
province,
it's
a
0.1
there's,
certainly
improvements
to
be
made.
I
think
particularly
around
naming
like
invocation
versus
recipe
and
other
things
like
that
could
be
ported
over.
So
I'm
not
trying
to
argue
that,
like
everything
that
went
into
the
salsa
one
is
correct
and
everything
jane
said
it
was
wrong.
So,
first,
the
intention
of
the
salsa
providence
is
actually
to
resolve
all
those
version
ids.
A
So
when
you
like
all
at
least
at
salsa
4,
when
you
have
a
fully
hermetic
build,
any
input,
artifact
would
be
identified
by
hash.
So
you
would
know
all
of
the.
I
don't
know
that
equivalent
change,
but
for
like
github
actions,
all
of
the
actions
that's
used,
plus
everything
that
was
fetched
you
have
like
where
it
was
fetched
from
like
with
the
pearl
or
something
like
that
and
a
hash.
A
So
I
think
that's
the
same
in
both,
I
believe
the
main
difference
between
the
tecton
chain's
provenance
was
in
an
intended
use
case
with
the
salsa
one.
Our
intended
use
case
when
we
wrote
it
as
tom
said,
is
to
try
to
minimize
the
amount
of
information
that
you
need
to
check
the
idea
being
if
you're
using
github
actions,
and
you
have
the
yaml
file.
A
If
someone
executes
that
in
a
faithful
builder
on
github
actions-
and
it
will
do
the
right
thing
unless
you
have
like
some-
I
mean
it's
doing-
ssl
and
everything
like
that.
So
it's
it's
pretty
difficult
to
inject
bad
behavior
when
github
actions
is
actually
injecting
that,
because,
like
the
the
has
has
reviewed
that
full
configuration
and
we
and
like
the
policy
would
be
like
did
it
did
you
actually
build?
Did
you
kick
it
off
from
the
right
step,
because,
like
you
trust
the
builder
will
actually
execute
all
the
steps
correctly.
A
That's
like
the
model
that
we
were
thinking
of
with
the
chains,
and
you
could
argue
with
that
and
I'm
happy
to
discuss
that.
But
with
the
chains
model,
I
think
the
questions
that
they
wanted
to
answer
were
different
was
not
like
what
kicked
it
off,
but
rather
what
were
the
individual
steps,
so
I
could
go
inspect
them
without
having
to
fetch
the
source
repo.
Basically,
they
want
to
take
some
information
from
the
source
repo,
possibly
with
runtime
information
and
embed
it
in
the
provenance.
So
it's
all
there.
A
If
that's
one
of
the
scripts,
then
you
would
possibly
be
able
to
detect
that
now.
I
have
a
question
of
like
well.
Why
are
you
just
recording
the
first
level
of
step
if
the
step
is
running
back
script?
You're,
not
inspecting
that
and
let's
go
pull
down,
but
but
I
think
that
was
that
was
like
the
main
difference
of
an
intention.
E
Yeah,
I
so
I
think,
to
the
to
the
other
point
that,
like
users
wouldn't
want
to
like
write
a
build
script
that
that
that
anchored
every
step
at
a
particular
hash
that,
like
they
want
to
use
tags.
E
I
I
like,
I
completely
agree
like,
like
the
users
want,
want
to
use
tags,
and
I
think
that
the
other
thing
that
the
other
side
of
that
is
that
for
for
for
salsa
policy
at
least
how
how
we
plan
to
to
use
it
at
google
that
users
will
also
have
to
write
the
policy
that
they
that
they
that
they
accept
and
like
users
will
will
will
want
to
be
able
to
like.
And
so
users
can
like
easily
say
this.
E
This
yaml
file
from
from
from
this
repo
is,
is
what
should
have
been
executed,
and
you
don't
want
them
to
have
to
say
these.
These
these
10
steps
add
like
these
10
different
docker,
digests
right.
G
So
what
one
quick
thing
on
the
way
that
we've
been
approaching
it
here
is
so
I
think
I
largely
agree
with
you
on
that
one
where
we're
sort
of
taking
it
as
the
attestation.
G
You
know
we're
taking
at
some
level,
but
then
there's
a
secondary
thing,
which
is
we
could
always
go
back
and
audit
right.
We
could
always
go
back
and
sort
of
validate
hey.
You
said
these
materials
prove
these
things,
I'm
trusting
your
signature
that
that's
true,
but
on
a
regular
basis,
you
know
out
of
band.
G
I
can
go
back
and
audit
that
and
if
I
find
that
hey
something
doesn't
seem
right,
I
can
go
back
and
invalidate
you
know:
hey
you're,
signing
stuff
that
I
don't
you
know,
I
don't
trust,
but
the
big,
the
key
thing
there
being
at
least.
Obviously
this
works
for
us,
because
you
know
most
of
the
stuff
we're
doing
with
salsa
is
for
signing
our
own
internal
artifacts.
G
But
it's
it's
anyway,
just
wanted
to.
You
know
just
wanted
to
say
that
that
I
think
that
sort
of
thing
seems
important,
because
I
agree
like
you
know
we
can
go
as
recursive
as
we
want
right
in
validating
all
these
things,
but
at
a
certain
level
we
do
want
to
get
that
high
level,
quick
thing
that
we
can
check
and
then
on
an
ongoing
basis.
We
can
continue
to
sort
of
audit
or
have
other
third
parties
sort
of
add
their
signature.
G
A
I
think,
maybe
maybe
the
take
away
from
this
discussion,
which
is
what
matt
said
originally,
which
is.
We
should
probably
go
through
and
look
at
how
to
resolve
the
differences,
and
if
we
could
come
up
with
a
format
that
works
for
both
that's
probably
better
than
having
two
slightly
different
formats
right
and
also,
if
there's
ways
that
we
could
change
the
salsa
provenance
to
make
it
more
readable.
Because,
like
matt
said,
you
know
initially
the
techton
one
connected
better
with
him
like
we
should.
We
should
fix,
fix
that.
F
I
I
mean,
and
if
there
are
other
ones
out
there
right
like
it,
it's
it's
worth
sort
of
trying
to
rationalize,
because
I
totally
agree
that
trying
to
around
standardized
around
a
common
format
that
more
folks
can
get
behind
is
is
more
valuable
than
right
everyone
going
their
own
direction
and
having
to
write
policy
against
you
know
a
million.
D
The
recipe
field
like
there
is
a
sort
of
inbuilt
like
customization
bit
in
the
current
salsa
providence,
which
you
could
definitely
put
prescriptive
versus
sort
of
descriptive
sort
of
images
of
the
build,
not
images
representations
of
the
build.
So
I
I
don't
think,
there's
there's.
D
E
E
I
I
was
just
going
to
to
mention
that
that
and
an
argument
for
for
having
multiple
different
formats,
which
is
supported
by
by
which
is
supported
by
the
bundle,
is
that,
like
I
can
imagine
a
scenario
where,
where,
where
we
say
you
should
produce
the
salsa
provenance
and
then,
if
you
want,
you
can
produce
builder
specific,
very
detailed
information
as
well.
E
My
view
was
that
the
salsa
provenance
should
should
should
provide
enough
information
to
to
to
evaluate
some
like
some
set
of
properties
generically
between
all
between
all
builders,
and
if
you
want
to
do
more,
more
more
detailed
things
like
look
for
curl
bash.
E
Like
like
look
for
potential
misconfigurations
in
like
a
specific
builder
that
that's
a
great
use
case
for
also
producing
this,
like
detailed
record
sort
of
tailored
to
to
to
your
build
system,
and
luckily
you
can
produce
both
of
those
attestations
at
the
same
time,
you
can
stick
them
in
an
in
total
at
the
station
bundle
and
like
propagate
them
and
like
propagate
them.
Together.
F
You
can
also
do
something
like
have
a
mechanism
for
folks
to
extend
the
core
schema
with
like
url
prefix
fields,
or
something
like
that
where
it
enters
into
territory
where
they
are,
you
know,
defining
their
schema,
so
I
can
have
you
know:
mattmore
dot,
io,
slash
whatever,
and
my
tools
sort
of
define
the
schema
for
that
extension
so
that
you
yeah
yeah
so
but
like
I,
I'm
wondering
what
that
sort
of
common
bit
is
because
you
know
with
you
know:
chains
went
in
a
completely
different
direction.
F
Clearly
the
extensions
were
not
enough
for
what
they
were
trying
to
do.
So
you
know
define
what
we
think
is
the
common
ground,
and
then
you
know
show
examples
of
how
you
would
use
the
extensions
to
cap
capture
some
of
the
other
stuff,
I
think,
would
be
helpful.
B
That
I'd
be
curious
if
there
are
other
people
that
are
trying
to
trying
to
implement
like
the
salsa
that
might
have
more
feedback
to
you
on
the
formats.
G
I
will
probably
have
feedback
in
the
next
couple
of
weeks,
I'm
just
starting
to
implement
some
of
it
now
cool.
D
F
Yeah
I
mean,
I
think
that
as
part
of
the
exercise
right,
having
lots
of
examples
of
how
folks
are
using
this
and
extending
it
to
capture,
you
know
metadata
that
they
want
represented
outside
of
that
core
set.
I
think
will
be
super
helpful
to
avoid
talking
past
or
stuff
like
that
as
well.
So.
B
Cool
we're
gonna
get
kicked
out
of
here.
So
any
last
minute.
B
E
That
sounds
like
a
good
topic
for
next.
The
next
meeting,
yeah
yeah.
G
If
you're
interested,
though
I'm
currently
doing
it
out
of
band
specifically
because
it's
not
as
far
as
I
can
tell
not
not
included,
but
I
I
am
I'm
doing
something
similar,
but
just
sort
of
using
salsa
and
then
separately
also
including
s-bomb
validation,.