►
From YouTube: SLSA Meeting (April 14, 2022)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
A
And
let
me
also
make
sure
I
post
thing
here
so
for
folks
feel
free
to
put
your
attendance
in
there.
A
So
I'm
looking
at
the
agenda.
The
only
thing
on
the
agenda
for
today,
actually
I
realized,
is
brendan.
Lum
has
something
I
think,
there's
a
couple
other
things
I'm
going
to
add
on
to
the
agenda
real
quick.
I
doubt
brendan
lum
will
be
on
to
demo.
I
know
he
just
got
sick
and
so
he's
not
feeling
very
well,
so
I
don't
think
he'll
be.
Actually.
This
is
something
given
that
we've
been
talking
about
this.
We
can
probably
I
can
at
least
talk
to
some
of
it.
A
B
C
Did
we
ever
get
the
negative
levels
announced.
B
C
Yes,
please
it
was
released
april
1
with
all
that
implies.
I
can't
take
any
credit,
but
I
did
have
a
great
laugh.
C
A
All
right:
well,
we
can
get
started
all
right.
Actually
I
don't
remember
kim
mobile.
How
do
you
usually
introduce
it?
Do
you
ask
for
folks
anybody
new
has
joined
us.
B
A
Anybody
new
to
the
group
who
wants
to
introduce
themselves.
F
I'm
newish
I'm
isaac.
I
joined
google
last
month
working
with
brandon
and
michael
windsor
and
others
you've
probably
seen
before.
G
I'm
I'm
also
a
new
guy,
I'm
simon
kent.
I
also
joined
the
team
last
month.
Although
I've
been
with
google
for
quite
a
while,
I
will
be
working
with
isaac
and
code
so
great
to
meet
you
all.
H
J
All
right,
this
is
part
I've
been
to
some
of
these
meetings
so
but
and
other
ones
other
open
source
meetings,
but
basically
been
applying
a
lot
of
the
salsa
into
you,
know,
techton,
and
a
lot
of
other
tools
out
there
so
glad
to
be
here.
K
This
is
sector
from
here
we're
having
another
parameters
of
cloud
native
foundation
and
generally,
I
think,
with
joshua,
so
he's
coming
to
this
meeting,
and
then
I
get
the
information
but
he's
sick,
oh
well,
and.
L
Hi
this
is
naveen.
I
contribute
to
other
control
security
foundation,
projects
and
yeah
to
contribute
over
here.
Thanks.
M
A
All
right
cool
a
lot
of
new
folks
glad
to
see
it
brendan.
Do
you
want
to
take
it.
D
Yeah
I
can
start
so.
I
wanted
to
share
a
little
bit
about
some
things
that
I've
been
investigating
and
and
talk
a
little
bit
about
a
blog
post,
so
I've
been
working
on
and
maybe
share
it
with
a
couple
folks,
it's
still
like
kind
of
half
baked.
So
just
a
little
bit
of
background
recently
I've
been
diving
into
s-bomb
quite
a
lot,
especially
with
spd-x.
D
I
entered
the
goal
of
what
I'm
doing
is
trying
to
see
what
the
destiny
overlapped
and
see
that
youtube
s
moments,
also
and
hopefully
kind
of
document.
A
little
bit
of
you
know
how
how
the
two
relate,
and
maybe
we
can
seek
out
some
synergies
that
we
can
collaborate
radon.
D
So
as
part
of
this
is
maybe
I'll
share.
My
screen.
D
So
this
is
like,
as
you
can
see,
this
document
still
being
edited,
but
I
can
probably
share
with
a
couple
couple
folks.
But
basically
the
point
of
this
argument
is
to
kind
of
talk
a
little
bit
about.
You
know
how
salsa,
as
former
kind
of
usually
seen
as
two
different,
two
totally
different
concepts
or
two
different
areas:
one
on
supply
chain
security,
one
on
vulnerability
management,
but
they
kind
of
have
some
synergies.
D
It
talks
a
little
bit
about
certain
certain
overlaps
in
terms
of
what
we've
seen
in
s-bomb,
starting
to
kind
of
take
into
consideration
the
build
metadata,
which
is
essential
to
create
a
complete
s-bomb.
So
we
talk
about
how
you
know:
good
build
provenance
and
good
metadata
is
essential
for
s-bombs
as
well,
and
then
we
talked
a
little
bit
about
some
of
the
requirements,
such
as
like
authenticity,
slash
provenance
and
distribution
or
s-bomb
documents.
D
What
we
see
as
well
with
salsa
and
then
we
talk
a
little
bit
about
integration
points,
and
you
know
the
difficulty
of
like
being
able
to
adopt
this
across
the
ecosystem.
And
you
know
both
s
bomb
and
salsa.
Do
do
have
that
that
that
the
difficulty
in
terms
of
needing
to
to
to
implement
this
across
many
different
tools,
so
yeah,
that's
kind
of
just
like
expired
synergies.
We
kind
of
try
and
draw
some
ideas
of
what
we
can
do.
D
One
is
you
know:
maybe
we
can
take
down
the
salsa
concepts
and
also
integrate
them
into
s-bomb.
This
we've
been.
We
recently
started
as
pdx
build
profile
group.
So
we're
talking
about
this
and
the
idea
is
maybe
we
can
take
some
of
the
salsa
providence
fields
and
include
them
in
the
spdx
definition,
potentially
also
being
able
to
make
references
to
salsa
providence
documents
from
the
s1
documents
as
well,
and
I
think
that
we
are
that
we
kind
of
throw
that.
D
So
you
know,
maybe
because
there
is
overlap
and
the
functional
requirements.
You
know
we
can
look
on
similar
solution,
name
for
solution
distribution.
All
you
know
problems.
D
We
can
just
use
in
total,
as
well
kind
of
just
to
to
scope
down
the
problem
space
scenes,
since
these
two
documents
are
kind
of
used
in
a
similar
context,
and
so
the
idea
that
you
know
maybe
salsa
if
we
focus
our
our
efforts
on
making
the
salsa
tooling,
we
could
use
the
salsa
metadata
and
maybe
augment
it
a
little
bit
to
be
able
to
better
generate
s-bombs.
So
instead
of
you
know
implementing
salsa
as
bomb
for
every
every
tool-
and
this
is
something
I
export
with
mark
on
monday.
D
Maybe
you
know:
salsa
can
be
augmented
with
a
little
bit
more
metal
data
that
it
can
be
used
to
generate
s4
information,
so
we
can
focus
efforts
on
just
integrating
salsa
into
the
build
tools.
D
D
Yeah,
so
that
is
pretty
much
the
blog
post.
I
I
think
the
wanted
to
kind
of
give
a
heads
up
on
on.
You
know
what
are
some
of
the
ideas
that
we
that
I've
been
looking
at
and
we've
been
talking
about
and
to
get
some
feedback
as
well.
I
think
we
are
looking
to
publish
this
blog
post
in
the
next
couple
of
weeks.
D
D
That's
not
decided
yet
yeah
we're
difficult.
It
would
either
be
in
the
google
blog
post
or
there's
also
one
okay,
yeah.
D
Yeah,
I
think
we're
going
to
leave
that
to
tech,
writer's
discretion.
C
D
Yeah
so
yeah,
I
think
in
in
the
spdis
we're
talking
about
making
references
to
this
also
documents,
so
you
can
kind
of
like,
given
the
s
bomb,
you
can
look
at
the
source
of
provenance
and
be
able
to
make
policies
and
stuff
like
that
and
I'll
meet
michael
and
talk
a
little
bit
more
about
this.
We
started
working
together
together
with
santiago
as
well
to
start
talking
about
maybe
some
kind
of
analysis
and
kind
of
like
mapping
these
things
together.
A
Yeah
yeah
we
we
were,
we
briefly
started
talking
about
some
of
that
just
around
like
hey,
now
that
we
have
all
these
great
salsa
attestations.
How
do
I
go
and
ask
questions
of
my
supply
chain?
I
think,
is
sort
of
the
thing
we're
trying
to
start
to
figure
out
and
in
a
way
where
you
know,
given
all
the
challenges
of
stuff.
A
Like
you
know,
I
might
have
access
to
all
the
open
source
stuff,
but
there
could
also
be
vendor
information
where
a
vendor
might
only
be
giving
me
some
information,
but
not
everything,
and
how
do
you
know
what
sorts
of
things
can
we
do
there
and
there's
also
a
thing
of
from
like
my
project?
Might
trust
these
things,
but
not
those
things
and-
and
how
do
I
kind
of
you
know
know
what
treat
sorry?
A
How
can
I
trust
different,
both
different
data
sources,
as
well
as
different
identities
in
generating
the
salsa
stuff
and-
and
I
I
think
it's
it's
interesting-
it's
it's
an
interesting
challenge.
There.
N
Speak
up,
I
really
like
the
direction
brandon,
you
guys
are
kind
of
going
with
that
kind
of.
Like
david
was
saying
you
know
it's
not
a
requirement
of
salsa.
However,
that
makes
it
really
attractive
for
me
to
think
about.
You
know
having
that
interoperability
together
with
these
two
things
that
you
know
we
probably
should
be
doing
so.
I'm
really
keen
to
see
this.
A
Yeah,
so
I
think
that's
that's
true
and
I
think
there's
also
a
second
piece
of
it,
which
is,
I
think,
the
s
bomb
is
one
really
big
important
piece,
but
I
think
over
time,
we'll
start
to
see
the
same
thing
beyond
s-bomb
right
like
how
can
we
just
sort
of
link
salsa
attestations
with
all
sorts
of
additional
supply
chain
metadata
because,
like
for
example,
I
know
there's
a
lot
of
great
work
coming
out
of
like
scorecard
and
and
I'm
blanking
on
the
name
of
the
new
one,
where
I
can
self-identify
the
governance
of
my
project
and
and
it
would
be
useful
to
start
to
see
like
hey.
H
I
don't
know
if
this
is
the
time
to
bring
it
up,
but
one
of
the
challenges
that
we're
seeing
is
this
idea
of
the
sort
of
the
false
positives
in
all
of
this.
It
could
be
very
disruptive
across
supply
chain
and,
if
there's
anything
we
can
do
to
help
reduce
some
of
that
noise
would
be
quite
helpful.
So
we've
spoken
to
the
folks
at
sbdx
and
now
in
salsa
as
well.
H
You
know
anything
that
could
just
help
and
again
it's
not
it's
a
common
problem
across
many
different
domains,
threat,
modeling,
so
on
and
so
forth,
but
even
code
scanning.
But
if
there's
a
way
that
we
can
bring
that
down
a
little
bit,
maybe
push
it
as
early
as
possible
to
the
point
of
attestation
and
look
for
certain
variables
or
factors
that
we
think
are
necessary.
Something
along
those
lines,
I
think,
would
be
helpful
thanks.
D
O
Yeah,
so
I
think
this
was
just
mentioned
kind
of
very
briefly
a
second
ago,
but
you
know
one
of
the
approaches
that
we're
starting
to
look
at,
and
you
know
I
I
see
a
lot
of
common
faces
in
here
from
some
of
the
other
working
groups
in
open
ssf.
O
But
you
know
some
of
the
things
I
mentioned
in
the
best
practices
group,
as
well
as
the
tooling
group
is
really
starting
to
look
at
as
we
build
out
not
only
picking
tools
but
really
starting
to
think
about
best
practices
and
frameworks,
for
that
is
the
question
really:
should
a
standard
for
best
practices
be
the
incorporation
of
the
salsa
framework
as
a
key
differentiator
for
assuring
that
your
sdlc
process
is
fully
as
secure
as
it
can
be.
I
mean.
O
Certainly,
there
are
other
processes
and
things
that
you
can
incorporate,
but
it
starts
to
provide
that
that
focus,
especially
since
you
know,
a
lot
of
people
have
come
out
with
some
key
metrics
and
discussions
on
just
how
few
people
how
few
developers
are
actually
trained
in
the
context
of
security.
O
Having
a
framework
like
this
and
helping
developers
to
adopt
a
better
posture
from
the
beginning
allows
for
a
more
secure
application,
not
just
infrastructure.
So
you
know
internally
we're
starting
to
build
some
things
that
we'll
incorporate
the
community
a
little
more
on
as
we
progress,
but
you
know
we're
we're,
definitely
taking
salsa
to
heart
and
using
that
as
a
step-by-step
gauge,
for
where
our
solutions
and
our
internal
development
will
be,
how
you
know
what
our
posture
is.
O
So
I
think
it's
something
we
really
should
be
working
with
open
ssf
groups
to
to
make
a
standard
rather
than
you
know,
just
a
framework
that
can
be
adopted.
That's
it's
my
opinion.
A
Yeah,
real
quick
just
on
that
note.
I
know
that
some
of
the
the
the
partner
groups
in
the
linux
foundation
have
written
some
like
best
practices
guides
and
started
building
some
sort
of
standards
around
this.
I
linked
one
of
the
ones
from
the
cncf
supply
chain
security,
best
practices
guide
in
in
there,
but
I
agree,
but
I
agree
with
you
there
that
we
should
be
building
out
some
actual
practices.
O
C
Yep,
so
I
wanted
to
respond
real,
quick
to
the
countering
the
false
information
and
false
positives
and
other
stations.
Obviously
that's
a
that's
a
real
issue.
I
think
part
of
a
solution
is
not
just
recording.
You
know
what
the
claim
is,
but
attributing
where
you
got
that
you
know
that
doesn't
solve
the
problem
completely,
but
at
least
lets
you
answer
not
just
what
the
data
is,
but
why
should
I
believe
that,
and
maybe
discounting
things
that
you
think
are
are
dubious.
H
I
think
that's
a
really
good
variable
there,
david
there's
other
stuff
as
well
like
automating.
Some
of
this
as
well
like
some
of
the
tooling,
can
provide
additional
factors
that
say
hey
you
know,
we've
tried
this
a
number
of
different
ways
and
came
up
with
the
same
results,
but
it's
all
good
great
thought.
A
Cool
any
other
questions,
comments,
thoughts
brendan
anything
else
from
on
this.
D
A
Oh
and
feel
better.
E
All
right,
thanks
yeah,
so
I
just
wanted
to
to
draw
folks
folks
attention
to
this
to
this
series
of
of
blog
posts
on
on
how
to
salsa
the
first
two
have
been
published.
I
expect
that
that,
like
part,
three
should
should
go
up
sometime
very
soon.
E
Basically,
I
I
put
this
together
because
the
salsa
website
and
like
requirements
are,
are
like
very
specific
about
how
like
how
a
build
should
be
conducted
and
like
what
the
requirements
are
are
to
be
met,
but
there
wasn't
very
much
information
about
like
okay
now
now
that
I've
done
that,
how
like
how
can
all
of
this
fit
together,
and
so
this
this
series
is,
is
basically
a
collection
of
of
thoughts
on
on
on
how
those
things
can
be
done.
Who
should
who?
E
Who
can
and
should
do,
do
what,
when
and
yeah,
if,
if,
if
folks
are,
are
interested
and
want
to
take
a
look
and
provide
feedback
in
whatever
forum
you
choose,
I
think
that
would
be.
That
would
be
really
helpful
and
there's
no
like
I'm
under
no
illusions
that
the
solutions
that
I
propose
here
are
the
best
solutions,
they're
just
sort
of
sort
of
examples
that
we
can
use
to
to
build
off
of.
P
Yeah,
I
just
like
to
say
I
found
them
both
very
useful
because
they
explained
a
lot
of
things
that
explained
approaches
to
providing
attestations
for
a
lot
of
things
that
it
was
dubious
to
me
as
to
how
to
do,
and
it's
given
me
some
guidelines
on
how
we
can
start
start
providing
attestations
for
things
for
which
there
are
no
attestations
upstream.
I
think
that's
that's
been
a
very
useful
part
of
it
for
me
and
just
seeing
how
all
the
pieces
fit
together.
P
It
has
also
been
extremely
useful,
so
thank
you.
Tom.
A
Yeah
same
here,
I
think
it
also
highlights
a
lot
of
things
that
like,
even
though
there's
not
a
lot
of
external
tooling,
for
some
of
the
things
around
how
I
might
be
using
policy
around
some
of
this.
I
think
it
gives
a
lot
of
good
ideas
on
on
what
to
do
where
we
can
start
looking
at
next
steps
from
a
tooling
perspective,.
A
Cool,
so
I'm
going
to
go
quickly,
talk
about
two
small
things,
quick
and
then
go
to
the
the
I
think,
the
slightly
bigger
one.
So
I
also
wrote
a
blog
under
the
the
official
salsa
blog
called
salsas,
no
free
lunch,
I'll
link
that
here
as
well
in
the
thing
so
yeah.
A
This
is
more
or
less
just
trying
to
kind
of
clear
up
some
confusion
regarding
salsa,
given
that,
obviously
some
folks
are
just
very
relatively
new
to
salsa
they're
kind
of
confusing
best
practices
with
what
salsa
is
actually
sort
of
providing
love
to
get
some
additional
feedback
on
there.
I
know
that
has
actually
opened
up
some
interesting
potential
inconsistencies
in
the
salsa
spec
itself
so
which
we're
gonna
address,
but
yeah
love
to
also
get
some
feedback
on
that
as
well.
A
Another
quick
announcement
so
ssf,
which
is
some
of
the
stuff.
I
know
I've
demoed
in
the
past,
that
was
some
code,
contributed
by
city
to
the
open
ssf.
A
We
now
have
community
meetings
starting
next
wednesday
or
sorry
start
sorry,
not
next
week,
starting
this
upcoming
wednesday.
The
the
notes
are
in
the
all
the
information's
in
the
notes.
It's
on
the
the
official
calendar
it's
on
wednesday
at
10
a.m.
A
Looking
to
sort
of
start
addressing
some
of
these
things
in
in
a
in
a
real
way
where,
as
a
community,
we
can
sort
of,
you
know,
start
to
build
out
some
of
the
stuff.
That's
coming
out
of
salsa
from
up
some
of
the
other
things
from
the
other
open
ssf
groups
to
include
in
there
and
use
it
as
sort
of
like
a
a
project
that
you
know
is
dog
fooding.
Everything
that
the
openess
is
doing
to
then
also
show
what
supply
chain
security
could
look
like.
A
Okay,
now
the
the
bigger
one
is,
I
don't
know
if
I
created
some
issues,
there's
been
a
bunch
of
github
issues
created,
so
I
don't
know
if,
if
there's
one's
been
created
for
this,
these
two
particular
related
things.
A
One
is
that
salsa
2
service
generated
requirement
seems
to
conflict
in
ways
with
salsa
3
non-falsifiable,
as
well
as
based
on
some
of
the
stuff
that.
A
Some
of
the
folks,
you
know
azra
and
laurent-
had
had
demoed
previously
there's
some
concern
as
to
like
that
they
might
be
hitting
the
spirit
of
salsa
3,
but
are
they
actually
complying
salsa
3
because
of
the
way
that
service
general,
like
the
way
that
service
generated
is
defined?
And
I
think
it's
worthwhile
to
let
me
have
a
a
discussion
on
it.
A
A
So
if
I
go
down
to
service
generated,
so
service
generated
defines
sort
of
it
pretty
much
says:
hey
data
in
the
provenance
must
be
obtained
from
the
build
service
so
that
pretty
much
is
sort
of
saying,
hey
the
the
providence
is
generated
by
the
actual
build
service.
Not
the
build
step
totally
makes
sense.
A
A
I
might
be
answering
my
own
question
here,
but
is
there
ever
a
case
where
your
service
would
be
generating
provenance
but
then
would
be
signed
by
a
build
step?
Or
is
this
just
literally
saying
hey
if
you
do
have
a
signing
key
make
sure
that
that
signing
key
is
never
accessible
to
the
build
step.
Q
Shock
first,
it
feels
like
a
sanity,
preserving
measure
or
just
a
sort
of
a
thing
that
you
shouldn't
have
to
mention,
but
it
has
to
be
mentioned
for
completeness,
which
is
to
say
that
the
build
should
not
be
able
to
verify
itself.
It
should
be
an
agent
outside
of
the
build
that
verifies
that
bob
speaks
for
it.
A
I
I
know
I
think
I
I
think
so
I
think
it's
just
trying
to
make
sure
you
know,
because
when
I
read
through
it
I'm
just
like
oh
okay,
cool
the
the
service
is
now
generating
all
my
providence
and
then
the
next
thing
around
non-falsifiable
is
sort
of
saying,
hey.
Well,
given
that
my
stuff
is
already
being
generated
by
the
service,
do
I
need
to
say
that
the
thing
is
only
accessible
to
is
not
accessible
to
the
the
build
steps,
but
I
think
it's
worth
saying
for
completeness.
Q
Q
E
Yeah,
so
I
I
think
there
are
maybe
two
things
going
on
here:
one
I
think
when,
when
we
were
initially
drafting
these
these
requirements,
if
I
like,
if
I
recall
correctly,
what
what
we
were
thinking
was
that
at
level,
one
people
might
just
be
hand
crafting
their
their
their
level.
One
provenance
like
just
like
opening
up
a
text
editor
and
like
typing
in
the
the
the
answer,
and
we
said
like
at
level
one.
E
E
I
remember
that
the
intention
was
that
at
level
two
that
the
data
in
the
providence,
that
it
might
be
fine
if,
if
the
build
step,
actually
created
it
itself,
and
so
I
wonder
if
at
level
two
like,
if
sort
of
we,
if,
if
somehow
through
some
of
the
rewordings
we
we
had
wound
up
with
multiple
different
definitions
for
for
for
service
generated,
where
what
we
really
meant
is
like.
P
P
This
makes
sense
in
that
context,
and
I
don't
know
that
it
makes
much
sense
if
you
actually
trust
the
build
step,
but
yeah
we've
always
treated
bill
steps
as
hostile
code,
and
so
we've
always
assumed
that
it
would
be-
and
I
think
I've
seen
this
in
some
of
the
diagrams
that
you've
presented
before
michael-
is
it's
the
orchestration
part
that
actually
does
the
provenance
signing
and
so
that's
doing
an
inspection
of
the
build
step.
But
it's
not
actually
running
the
build
step,
so
the
build
step
itself
doesn't
need
access
to
any
of
this
material.
A
Yeah-
and
I
think
to
to
that
thing,
you
just
said-
is
gonna
be
very
important
in
the
the
next
little
topic
we'll
be
talking
about
david.
C
I
think
I
maybe
I
think
many
of
the
other
people
said
similar
things,
but
I
guess
my
thinking
is
you
know
the
signing
key.
The
the
point
of
this
signing
key
is
trying
to
minimize
the
privileges
of
the
build
service
and
therefore
by
not
providing
it
to
the
build
services.
A
separate
thing,
of
course,
you're
signing
something
that
was
actually
generated
by
someone
else.
So
you're
you're
not
getting,
maybe
a
huge
bang
for
a
buck,
but
you
know
you're
getting
something
for
this.
R
Sam
yeah,
so
just
to
add
on
to
what's
being
said
here,
I
know
so
I
I
work
at
gillab
and
I'm
we
were
somewhat
confused
by
the
definition
of
service
generated
and
what
I'm
hearing
from
tom
and
others
is
that
really
the
intention
was
that
this
was
more
of
a
scripted
generation
thing
rather
than
like
you
said,
you
know
somebody
just
opening
up
a
text
editor
and
our
confusion
was
on
the
definition
of
that,
whether
it
could
be
done
by
a
script
at
all
or
the
other
way
of
interpreting
that
definition
of
service
generated
as
it's
written
up
now,
is
that
the
actual
get
lab
runner
itself
or
if
you're,
using
github,
like
the
actual
github
actions
like
the
underlying
control
plane
itself
would
have
to
be
the
thing
generating
that,
and
so
you
know
that
seems
extremely
strict
for
salsa
level.
R
Two
is
certainly
very
secure
to
have
that
come
directly
from
the
underlying
control
plane
itself,
but
it
did
seem
overly
strict,
but
it
sounds
like
maybe
it's
just
a
terminology
or
a
definition,
misunderstanding,
and
maybe
you
know
rather
than
consolidating
these.
Perhaps
we
just
need
to
clarify
that
service
generated
or
maybe
even
rename
it
something
like
script
generated,
or
you
know
scripted
generation.
R
A
Yep
100
agree
with
you
on
on
on
that
one,
and
I
think
that
that
literally
opens
it
up
to
the
the
next
little
piece
of
that
same
topic,
which
is
yeah
what
counts
as
service
generated,
and
so
I
just
created
a
github
issue,
because
I
didn't
see
one
specifically
around
that-
and
I
think
some
of
this
had
come
out
of
lauren
and
and
ezra's
demo,
which
is
hey
they're,
not
taking
the
they're,
not
getting
the
provenance
necessarily
directly
out
of
github.
A
They
have
a
reusable
workflow,
which
you
can't
like
the
end
user,
can't
change
that
like
they're,
not
they
don't
have
the
ability
to
modify
what's
actually
happening
in
that
step,
and
so
does
that
count
as
service
generated
by
the
way
we
have
it
worded
here.
Probably
not,
but
is
it
still
safer
than
the
other
option,
which
is
you
know,
yeah?
I
have
an
a
build
step
that
has
build
and
that
has
developer
code
running
in
it
and
yeah.
A
On
that
case,
I
definitely
do
not
want
that
build
step
to
be
generating
its
own
provenance
because
it
can
fake
it
quite
easily.
But
if
I
have
something
that
has
been
pre-approved
has
gone
through
its
own
sorts
of
stuff,
I
probably
trust
it
significantly
more
than
that,
but
maybe
not
quite
as
much
as
a
full-blown
sort
of
trusted
control
plane
that
that
has
been
built
with
that
specifically
in
mind.
E
Yeah,
so
just
just
be
sure
that
I
understand
like,
like,
I
think
with
that
reading.
What
what
you're
saying
is
is
that
perhaps
the
only
thing
that
would
actually
be
acceptable
is,
if,
like
in
the
case
of
this
github
actions
workflow,
if
like
github
itself
as
a
built-in
feature
was
was,
was
what
was
producing
this
information.
A
That
is
my
reading
and
I
think
other
folks
as
well
like
git
lab,
and
I
think
a
few
other
people
have
sort
of
said
the
same
thing
like
if,
if
I
look
at
a
a
tool,
real
quick
like
if
I
look
at
a
tool
like
techton
and
tecton
chains,
the
way
that
tecton
chains
is
generating
the
provenance
is
tecton
chains.
Is
you
know,
reading
through
the
logs,
it's
validating
the
identities
and
so
on
and
so
forth,
which
itself
could
also
maybe
not
be
considered
salt?
A
You
know
service
journey
generated
depending
on
how
you
look
at
it,
but
I
think
the
thing
there
is
like
it's
a
separate
service
that
you
know.
I
think
the
big
thing
that
we're
trying
to
say
is
like
limiting
the
state
space
right
of
what
could
potentially
be
happening
in
there.
It's
only
looking
at
the
output
and
then
doing
some
stuff
to
it
compared
to
hey
here
is
another
build
step
and
that
bill
step.
How
did
it
get
in
there
and
yeah,
like?
I
think,
there's
some
confusion
as
to
to
that.
E
I
see
yeah,
I
I
I
think
that
the
I
think
that
what
we
really
want
with
this
is
like
in
the
end,
do
we
care
if
it
is
service
generated
per
se?
Probably
not.
What
we
care
about
is
that
we
can
trust
the
contents
right
and
so,
like
probably
anything
that
that
that
gives
us
a
high
degree
of
of
trust
in
the
contents
is
probably
fine,
and
maybe
it
just
comes
down
to
how
how
how
that's
encoded
in
the
requirements.
I
think
I
saw
that
that
osra
also
had
her
her
hand
up
so.
S
Yeah,
I
think,
plus
one
of
what
tom
just
said
about
how
you
know
we're
trying
to
trust
that
the
contents
of
the
providence
is
actually
non-falsifiable
and
not
temperable
by
the
build
process
and
by
the
maintainer,
and
so
I,
the
original
point
that
I
was
trying
to
make
when
raising
my
hand,
though,
is
that
the
reusable
workflow
itself
is
the
service
here.
So,
like
you
know,
for
straw
man's
sake,
let's
suppose
that
we
wanted
github
and
get
lab.
S
You
know
these
people
to
only
be
the
people
that
provided
provenance
in
those
cases.
It's
like
it's
very
difficult
to
define
a
generic
and
also
usable
and
practical
provenance
statement
that
would
apply
to
every
ecosystem's
type
of
build.
Like
I
don't
think,
that's
what
we
want.
You
know
you
could
only
pretty
much
get
like
basic
github
context.
Information
at
that
point.
You
can't
really,
you
know,
extract
away
information
that
you
might
care
about
in
a
specific
ecosystem.
S
So
I
think
that,
like
it
seems
a
little
bit
too
much
to
expect
that
github
or
git
lab
or
other
cicd
systems
are
the
ones
producing
this
provenance,
but
more
so
that
you
can
build
provenance
that
is
trusted
and
isolated
away
from
influence.
S
You
know,
for
example,
enterprises
and
whatever
it
can
define
their
own
reusable
workflow.
So
I
think
really
here.
The
reasonable
workflow
is
the
service.
A
Yep,
I
agreed,
I
think,
the
just
looking
at
what
tom
posted
in
chat
there.
I
I
think
I
would
even
maybe
take
it
a
little
step
further
from
not
just
automated,
but
you
know
to
what
sean
was
talking
about
like
at
the
end
of
the
day.
We
want
to
make
sure
that
whatever
is
generating
the
provenance
is
not
a
developer,
does
not
have
the
ability
to
modify
how
that
works
without
going
through.
Some
sort
of
you
know
normal
approval
process,
but
aaron.
N
Yeah,
I
I
like
this
conversation
a
lot
because
I'm
trying
to
think
about
you
know
I
guess
my
quick
question
is:
does
anyone
think
they're
at
that
third
level
today
right,
I'm
curious
if
anyone
could
argue
that
right
almost
seems
like
they're,
it's
the
way
we're
talking
about
it.
You
almost
need
a
third
party
like
gitlab
or
github
to
you
know
be
that
you
know
that
a
tester
itself
separate
like
you're
saying,
but
what
about
like?
What?
N
If
you
know
me
as
an
enterprise,
you
know
security
person
like
could
create
some
sort
of
job
that
the
developers
couldn't
dabble
with,
and
then
we
insert
that
as
as
that
piece
like.
I
wonder
if
that's
good
enough-
and
I
guess
that's
what
I'd
be
looking
for.
A
Yep
all
right.
T
I
think
the
reusable
workflow
is
basically
a
service
that
github
offers
specifically
to
be
isolated
from
the
rest
of
the
pipeline,
and
I
think
you
could
view
the
reusable
workflow
a
little
bit
like
your
your
control
plane.
So
the
reusable
workflow
uses
multiple
vms,
the
same
way
that
tecton
uses
multiple
tasks.
I
think
they're
called
so
I
think
I
think
that
would
be
the
analogy
yeah
so
so
yeah.
I
guess
it
depends
what
service
means,
but
I
think
a
reusable
workflow
is
really
a
service
provided
by
github
yep.
A
Yeah
that
makes
sense
to
me,
and
I
think
we
just
need
to
maybe
make
that
a
little
clearer
in
the
in
the
requirements
and
just
because
it
was
talked
about
before
so
tom
had
said.
I
wonder
if
we
just
relax
service
generated
to
automated
and
then
keep
non-falsifiable
as
it
would
be.
You
know,
as
would
be
fine,
and
then
that
thing
there
was.
A
Maybe
we
just
want
to
make
sure
that
make
sure
that
we
include
in
there
that
you
know
the
developer
does
not
get
to
sort
of
change
that
as
part
of
their
actual,
what
they're
running
in
their
build
to
make
sure
that
it's
like
hey,
that
that's
a
that
would
count
as
the
service
and
would
need
to
go
through
its
own
setup,
obviously
ci
cd
or
whatever,
to
deploy
that
sort
of
thing
out
the
only
and
then
for
the
tecton
thing.
A
The
only
thing
I
just
wanted
to
just
add
in
there
a
little
bit
is
at
least
the
way
that
tecton
chains,
sort
of
it
is
set
up,
is
that
tecton
change
is
sort
of
like
recording
what
tecton
is
doing
as
it's
happening
and,
and
so
that's
kind
of
a
like.
It
is
slightly
different
than
some
of
the
reusable
workflows,
but
I
do
agree
that
you
still
run
into
a
lot
of
the
same
issues,
but
I
think
once
again,
I
think
it's
more
of
a.
A
I
don't
know
if
it
actually
matters
to
be
clear,
so
actually.
T
T
Because
we,
because,
like
reusable
workflow,
can
do
something
similar,
so
each
vm
can
actually
output
some
data,
but
but
that's
not
entirely
like
you,
can't
really
trust
it,
because
the
the
trust
like
sorry,
the
the
build
step
can
really
output
anything
they
want.
So
we
could
record
it,
but
we
try
not
to
at
least
we
could
record
it,
but
the
provenance
like
you
might
read
it,
but
actually
you
would
maybe
you
know
it
wouldn't
be
as
trusted
as
the
rest
of
the
provenance
information
like
this.
A
Yep
david.
C
C
I
was
staring
at
the
thing
you
were
you
just
stopped
sharing,
but
you
know
I
I
guess
originally.
I
had
the
theory
that
hey
what
we're
just
trying
to
do
is
keep
the
the
signing
key
out
of
the
build
system
which
made
sense,
but
the
more
I
look
at
it.
The
you
know
this
was
coming
earlier.
You
know
if
a
build
system
generates
x,
you
know
I
don't
know
how
we
make
it
not
falsifiable
to
make
it
not
x.
C
I
mean
you
know
we
can
try
to
protect
the
build
system,
but
some
of
this
seems
a
little
harsh
in
a
lot
of
situations
and,
frankly,
I'm
not
sure
how
you
accomplish
it:
keeping
the
key
of
the
build
environment
for
say,
signing
for
a
release,
yeah,
absolutely
that
makes
sense,
but
that's
a
different
statement
than
what
seems
to
be
yeah.
A
At
some
point
in
the
future,
I
think
we
should
have
parth
and
maybe
brendan
demo,
some
of
the
how
they're
doing
some
of
this
with
the
spiffy
spire
end
to
sort
of
maybe
provide
some
of
those
additional
guarantees,
but
yeah
sean.
P
Yeah,
just
talking
about
this
discussion
about
recording
what
actually
happens,
I
wonder
how
it
meshes
with
the
reproducibility
requirement
further
up
or
further
on,
rather
as
to
whether
you
know,
if
are
you
recording
enough
information,
can
you
record
enough
information
at
the
level
that
you
generate
the
provenance
if
the
provenance
isn't
actually
part
of
the
build
step?
Can
you
capture
enough
information
to
actually
produce
something
which
a
third
party
could
then
reproduce?
P
You
know
if
you're
actually
doing
it
in
the
build
step,
then
you've
got
okay.
I
will
record
all
the
commands
that
I'm
doing
and
the
way.
P
That
is,
we
have
a
virtualization
satellite
environment,
sat
on
top
of
the
on
top
of
the
execution
engine
for
the
build
step
that
actually
inspects
everything
that
that
build
step
does,
and
so
we,
we
record
all
the
commands
that
we
do
that,
but
that's
actually
kind
of
in
the
same
container
as
the
build
step,
and
I
wonder
whether
an
orchestration
engine
could
actually
record
the
level
of
detail
required
to
produce
a
reproducible
build
if
it's
set.
If
it
sits
one
level
up
there.
A
Yes,
so
I
think
on
that
note,
I
think
we
are
okay
with
saying
the
I
think,
and
maybe
we
just
need
to
make
sure
that
that's
clear
as
well
is
making
sure
that
it's
clear
that
when
we
say
reproducible
we're
saying,
reproducible
the
the
subject
of
the
salsa
attestation
is
reproducible,
not
necessarily
the
actual
output
of
the
attestation,
because
you
could
be
running.
Those
reproducible
builds
on
two
different
machines
running
slightly
different
things,
to
sort
of
prove
the
reproducibility
but
yeah
jacques.
Q
I
promise
that
the
choice
of
t-shirt
today
was
was
purely
incidental,
I'm
wearing
my
concours
t-shirt.
Those
of
you
who
know
me
know
that
I
am
a
one-eyed
raging,
crazy
concourse
fan,
there's
a
there's,
a
sink
there's
a
sort
of
like
a
pair
of
concepts
in
concourse.
I
really
wish
people
would
steal,
which
is
the
concept
of
resources
and
resource
versions.
Q
Q
C
Yeah,
I
put
my
hand
back
up
for
two
things.
First
of
all,
simply
recording
all
the
commands
doesn't
necessarily
make
a
reproducible
build
as
soon
as
you
have
parallel
computation,
in
particular,
there's
no
guarantee
of
ordering
there
actually
has
been
some
research
work
where
they
actually
force
execution
of
threads
to
reproduce
as
well.
C
You
know
I'm
impressed
that
can
be
done,
but
I
don't
think
anybody's
seriously
going
to
want
to
do
that.
It
creates
hideous
overhead
that
can
be
resolved
in
far
simpler
way,
like
please
sort
things
occasionally
where
that
matters
and
just
keep
moving
on
with
your
life.
C
So
I
so
so
coming
back
to
this
whole
non
falsifiable
I
mean
the
more.
I
look
at
the
more
complicated
this
gets
because
you
know
how
do
I
figure
out
what
the
providence
is
in
so
many
situations?
Really
you
have
to
figure
that
out.
That's
a
that's
a
non-trivial
calculation
which
has
to
be
done
somewhere
and
it's
not
done
the
build
system
where
the
heck
do
you
do
it?
C
J
Yeah,
I
just
wanted
to
add,
like
you
were
saying,
michael
was
saying
that
we
are
brandon
and
I
are
working
with
on
tech
time
to
get
to
salsa
level.
Three,
I
would
say,
and
in
terms
of
non-falsifiable,
you
know
like
we're
using
spiffy
spire.
So
what's
happening
in
that
is
each
task
run,
that's
being
created
by
the
controller.
It
gets
its
own
s,
fit
generated
by
the
by
this
fire
server.
Basically,
and
that's
what's
being
used
to
sign
any
kind
of
results
that
comes
out
of
it.
J
So
any
result
that
comes
out
of
it,
it
gets,
gets
a
signature
and
it
gets
verified
at
the
end
by
the
spire
or
by
the
the
tecton
controller
itself
and
then
later
on
by
the
these,
the
tecton
chains,
once
it's
actually
done
running
the
pipeline,
so
each
task
run
has
gets
its
own
s
vid.
Besides
that,
we
also
are
doing
hashing
the
actual
status
itself,
the
the
task
run
status.
So
as
it's
running
we
can.
We
can
make
sure
that
nothing
is
changing.
J
That's
let's
say
let's
say
the
tecton
controller.
Only
the
tectonic
controller
can
make
any
changes
to
the
task
run
itself,
while
it's
running
so
that
no
other
third
party
or
somebody
else
could
come
in
and
change
something
as
the
as
the
task
line
is
running.
So
it
checks
that
continuously
and
then
the
controller
svid
would
be
the
one
that's
doing
the
signing
of
the
status
itself
and
again,
all
this
stuff
is
being
verified
by
chains.
Once
everything
finishes.
J
A
Just
a
quick
check
at
ezra
rent
are
your
hands
still
up
or
did?
Did
you?
Oh
okay,
all
right
cool,
so
now
I
know
we
took
up
most
of
the
time
here.
Sorry
about
that,
I
I
think
so
worthwhile.
A
I
I
posted
a
github
issue
in
the
chat
before
I'll
post
it
again
in
the
thing
here
just
so
that
if
folks
are
interested
in
continuing
the
conversation
about,
you
know
some
of
the
stuff,
because
I
think
it
just
will
need
to
sounds
like
the
consensus
is
largely
it.
A
The
way
it's
worded
is
kind
of
vague
and
super
strict
and
we
should
be
clear
about
what
counts
as
service
generated
as
as
well
as
non-falsifiable,
and
be
a
little
bit
clearer
about
that
and
then
potentially
also
sort
of
move,
some
of
the
specifics
there
either
potentially
to
a
higher
salsa
level,
or
just
you
know,
figure
something
like
that
out.
So
next
up,
I
believe,
is
so
david.
C
Oh,
this
is
just
the
course
real
quick
just
I
think
many
of
you
know
that
one
of
the
challenges
we
have
is
of
software
developers
don't
know
anything
about
developing
secure
software,
open
ssfs,
of
course
we're
updating
it.
In
fact,
it's
one
thing:
I'm
trying
to
get
finished
today
tomorrow
and
the
plan
is
to
reference
salsa
now
salsa
is
not
at
a
1.0,
but
I
think
we
can
still
reference
it
as
a
hey.
A
So
I
think
that's
everything
on
the
agenda.
I
know
we
have
only
about
five
minutes
left.
Was
there
anything
that
anybody
wanted
to
bring
up
real,
quick
or
any
topics
that
folks
wanted
to
to
bring
enough
as
something
to
do
next
week
or
anything
that
you
know,
announcements
or
anything
like
that?.
N
A
Cool,
well,
anybody
who's
here,
who's
going
there.
A
The
only
other
thing
right,
so
I
know
some
some
of
the
stuff
that
we
had
already
discussed
before
we're
actually
going
to
be
trying
to
build
out
tooling
around
some
of
it
for
s.
You
know
for
ssf
the
open
ssf
project
underneath
the
supply
chain,
integrity,
working
group
and
so
folks
are
interested
in
maybe
seeing
like
hey
actually
once
we
start
writing
the
code.
How
hard
is
this
thing
to
maybe
implement
or
how
hard
is
it
for
us
to
hit
this
actual
social
requirement?
A
You
know
love
to
have
additional
thoughts
and
and
contribution
that
sort
of
thing.
A
Cool
and
if
nothing
else
can
give
everybody
back
a
few
minutes.