►
From YouTube: SLSA bi weekly sync (September 8, 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
There
we
go
great,
so
just
I'm
just
taking
a
look
at
this
week's
and
this
week's
agenda,
we
we
we
have
a
couple.
We
have
a
couple
items,
please
feel
free
to
add
anything
that
you
might
like
to
to
discuss
as
as
a
reminder,
I'm
I'm
filling
in
for
for
mark.
While
he's
out,
I
believe,
he'll
be
back
for
the
next
meeting.
A
A
It
like
it
definitely
seemed
to
be
to
be
tripping
people
up
previously,
there's
a
question
of
like
if
all
of
the
salsa
requirements
can
be
verified,
whereas
what
at
least
I
had
intended
when
I
had
expressed
my
my
desire
for
things
to
be
automatically
verifiable,
that
the
artifacts
that
are
produced
can
be
automatically
verified
as
having
met
the
salsa
requirements,
even
if
some
of
the
requirements
on
the
systems
involved,
like
the
source
control
systems
and
the
build
systems,
do
require
some
sort
of
human,
some
sort
of
human
analysis.
A
My
thought
is
that
it's
probably
hard
to
get
automatic
verifiability
for
some
of
the
properties
that
we
want,
like
is
a
build
like
is
a
build
isolated,
is
a
build
hermetic.
These
are
things
that
it
would
be
hard.
I
I
think
to
to
write
to
write
some
code
to
to
check
and
likely
instead
requires
that
some
some
security
team
review
sort
of
review
designs,
review
code,
maybe
and
and
maybe
perform
red
teams
before
finally
saying
okay.
A
Yes,
we
certify
this
build
system
as
meeting
salsa
level
three
and
then
maybe,
oh,
and
by
the
way,
this.
The
this
build
system
is
identified
by
by
these
keys,
and
you
can
use
those
keys
to
then
verify
the
provenance
that
is
produced
for
for
for
artifacts
and
that
you
can
use
to
automatically
verify
the
artifacts.
C
I
I
think
that
sounds
great
thom
I
so
I
agree
with
your
with
your
point
that
some
of
them
are
not
going
to
be
automatically
verifiable.
C
D
Of
the
things
is
that
a
lot
of
these
things,
which
can't
be
automatically
verified,
are
requirements
of
a
platform,
so
you
would
achieve
that
salsa
level
by
using
a
platform
that's
already
obtained,
so
in
the
open
source
case
that
would
be
like
I'm
using
github
actions
to
do
my
builds
and
githubs
attain
salsa
3
for
their
builders.
E
Yeah,
I
think
that
was
one
things
we
talked
about
before,
where,
if
there's
other
aspects
of
it,
where
you
could
certify
it
or
you
could
use
someone
who
is
certified
to
some
degree,
I
think
one
of
the
key
pieces
is
if
nothing
else,
if
we
our
agreement
on
generally
what
those
individual
check
marks
requirements
are
for
salsa
one
through
four:
are
we
able
to
now
go
in
and
identify
which
ones
we
know
can
be
automatically
verified
and
what
the
process
is
to
automatically
verify
that,
if
there's
a
way
effectively
to
drill
down,
as
you
go
into
also
like
level
one
two
and
three
four
which
is
hey,
I
need
you,
these
five
things
for
salsa,
one
they're
automatically
verifiable,
provided
I'm
using
github
using
this
using
this
using
this.
E
D
So
I
I
think
this
is
a
good
clarification,
both
in
narrowing
the
scope
of
what
is
automatically
verifiable,
but
also
describing
how
we
indicate
trustworth
trust
of
like
the
things
that
can
be
automatically
verifiable
right.
We,
you
have
some
kind
of
keys
that
indicate
problems
produced
by
this
system
is
trusted
up
to
whatever
level.
So
I
think
this
is
a
like
a
good
good
clarification
that
we
should
try
and
capture
in
the
ducks.
D
I
don't
know
what
the
right
way
to
yeah
is:
is
the
next
step
just
to
file
a
pr
and
get
review
on
it,
or
do
you
think
we
need
to
do
a
like
a
show
of
hands
here
or.
A
It
certainly
makes
sense
to
me,
I
think,
there's
probably
an
interesting
consequence
if
you
combine
a
few
of
those
things
together
so
first,
if,
if
the
lower
level
should
allow
for
automatically
for
automatic,
more
automatic
verification,
that
would
have
the
effect
of
pushing
people
to
use
systems
that
others
have
vetted,
which
probably
isn't
a
bad
thing,
because
there's
a
lot
of
skill
required
to
validate
a
system,
but
then,
of
course,
it'll
be
even
more
important
to
have
build
systems
that
are
compliant
and
to
have
a
couple
of
options
and
because
the
breadth
of
ecosystems
you're
trying
to
target
it,
can
be
really
tough
for
some
ecosystems
to
be
compliant
unless
they
do
all
of
it.
A
So
how
do
you,
I
guess?
The
only
thing
that
jumps
at
me
is:
how
do
you
also
balance
compliance
needs
at
lower
levels
for
more
esoteric
ecosystems,
like
I
don't
know
during
haskell,
just
because
it
feels
esoteric,
but
maybe
it's
easy
to
implement,
for
it.
E
I
have
my
contributors
on
there
if
those
contributors
aren't
using
2fa
and
other
basic
security,
things
that
are
offered
by
github
you're,
risking
out
like
we
have
a
company
where
everyone's
2fa,
but
they
have
one
bot
they're
using
connect
to
their
github,
that's
not
protected,
which
means
that
could
get
compromised
and
go
directly
into
the
code.
So
there's
an
aspect
of
like
the
service
may
offer
the
right
elements
to
make
sure
you
meet
that
criteria.
F
E
E
Sorry
matthew
or
in
a
case
where,
like
some
things,
we
just
talked
about
a
configuration
issue.
Let's
just
say
you
did
have
an
ability
to
step
in
and
say:
okay,
an
organization
will
look
and
say
you
are
salsa
level
whatever,
but
like
that's
only
a
snapshot
in
time,
it's
kind
of,
like
a
you,
know,
a
type
2
stock
like
it.
It's
not
looking
overnight.
It's
a
at
this
point
in
time.
I
can
say
you
met
this
criteria,
but
someone
else
is
going
to
double
check
the
next
day
or
later
on,
to
be
sure,
100
sure.
A
I
also
I
agreed,
and
I
do
wonder
if
it's
is
manual-
verification,
a
bad
thing
simply
because
maybe
there
should
always
be
an
onus
on
someone
or
someone's
to
understand
that
they've
implemented
the
process
properly,
because
you're
right
there
are
too
many
ways,
donnie
and
others
you're
right.
There
are
too
many
ways
around.
You
can
always
misuse
a
system.
There
should
be
some
someone
has
to
take
accountability,
that
it's
actually
right.
A
B
C
I'm
done,
I
believe
tom
raised
his
hand
also,
so
he
should
go
first.
I'll
raise
my
hand.
A
Yeah,
so
I
yeah,
I
I
I
definitely
agree
some
some,
some
methods
that
that
that
that
could
be
used
to
to
address
these
sort
of
these
sort
of
configurability
problems
like
like
does.
Does
everything
require
2fa
for
for,
for
example,
one
of
the
routes
that
we're
pursuing
internally
is
is
that
the
source
control
system
has
a
has
a
switch
that
that
you
flip,
which,
after
it's
flipped,
you
can't
go
back,
and
so,
ideally,
what
would
happen
is
like
github
would
have
a
switch.
A
A
Now,
if
that
doesn't
happen,
I
think
that
another
route
is,
is
one
that
matt
had
suggested,
which
is
like
you
could
leverage
something
like
something
like
scorecards,
which
is
where
you
don't
have
the
source
control
system
sort
of
issuing
an
attestation
that
says
hey
it's
configured
in
this
way,
but
rather
you
could
have
like
scorecards
monitoring
that
that
that
repo
and
it
can
issue
at
the
stations
that
say,
hey
like
like.
F
G
Well,
I
mean
I'll,
tell
you
like
when
I'm
looking
at
this
from
from
internal
build
perspective
from
ibm.
Everyone
knows
if
I
speak
on
other
calls.
We
want
to
use
protect
on
change
and
sig
store
at
station
logs,
and
you
know
the
whole
goal
is
then
is
what
you're
describing
I
think
matthew
in
terms
of
capturing
the
environment.
You
know
what
what's
the
platform
we're
running
on?
What's
the
input,
so
we
want
to.
G
We
know
that
we
can't
achieve
reproducibility,
but
at
least
sign
and
store
the
artifacts
that
at
least
manually,
given
information
you
could
to
to
try
to
reproduce
on
your
own,
which
is
not
a
bad
thing
and
align
with
what
zac
was
saying.
It's
not
bad,
and
that's
exactly
what
you
know
I
viewed
like
apache
foundation.
I
cite
them
often
is
their
release.
Process
is
very
stringent
and
it's
a
it's
a
pain,
but
once
you
get
it
established
you're
grateful
because
it
requires
manual
review.
G
It
requires
many
reproducibility
and
verification
signatures
before
anything's
ever
released,
so
give
them
give
them
the
information,
give
them
as
much
as
you
can
capture
it
verify
those
things
you
know
tell
them
that
exist
and
verify
those
things
as
historic
card.
This
whole
world
is
about
continuous
compliance
and
diffs
on
a
regular
basis
on
a
continuous
basis,
so
yeah.
A
H
Yep,
so
one
thing
I
think
I
know
this
was
brought
up
in
one
of
the
related
github
issues
it
one
of
the
concerns.
I
know
that
that
I
have
internally.
Is
you
know
what
is
the
currently
right
like
there's?
No
proof
that,
even
if
you
were
to
provide
these
attestations
coming
from
github,
github
could
be
lying
to
you
about
some
of
those
things,
and
so
I
think
that
there's
definitely
some
sort
of
baseline.
H
That
should
also
be
discussed
in
that,
regarding
you
know,
hey
look
for
some
of
these
key
tools
that
you
are
sort
of
saying.
You
know,
salsa
your
builders
providing
this
attestation,
you,
you
have
to
have
some
sort
of
baseline
level
of
security
because,
right
you
know,
if
somebody
were
to
let's
say
you
know:
let's
say
it
is
github,
that's
providing
some
sort
of
signed
thing
or
actually
probably
that's
a
bad
example,
because
they're
they're
huge
but
like
if,
let's
say
you
know,
some
builder
is
providing
a
signed
thing.
H
Well,
you
need
to
make
sure
that
you
know
whoever
has
those
keys
is
not
signing
that
yeah
the
builder's
fine
right,
because
I
know
that
that's
that's
one
of
the
the
big
worries.
G
F
So
to
to
that
point
like,
like,
I,
I
definitely
think
there's
no
one's
getting
around
the
consumer.
You
know
the
automatic
or
like
annual
consumer
of
this
provenance,
having
some
sort
of
like
assessment
or
like
evaluation
of
all
of
the
builders
they're
going
to
end
up
trusting.
F
I
think
it's
difficult,
but,
like
you,
you
need
to
say,
for
instance,
for
a
given.
You
know
builder
what
keys
you're
gonna
trust
so
that
just
gets
up
down
to
like
core
pki.
You
know
like
identity
stuff,
but
also,
honestly,
the
those
you
know,
high
level
security.
You
know,
guarantees
like
hermeticity
reproducibility,
all
the
things
and
whether
you
leave
this
system
to
be
meeting
them,
and
I
think
talking
about
it
on
the
producer
side
is
great
but
like
ultimately,
if
they're
like
it's
the
consumer,
that
kind
of
needs
to
make
the
call.
C
C
A
Yeah-
and
I
I
think
that
some
of
that
probably
rests
on
how
like
on
how
we
agree
to
like
certify
things
at
like
at
like
higher
salsa
levels,
because,
certainly
at
like
level
one
and
two
I
don't
like,
I
don't
know
that
we
have
any
requirements
on
like
how,
unlike
how
that
key
material
is,
is
handled,
but
I
think,
certainly
at
level
four.
It
would
be
very
fair
for
for
us
to
say
that,
like
no,
no
human
should
should
be
able
to
like
sign
anything
with
these
keys.
A
That
can
only
be
like
the
role
that's
running,
that's
like
running
the
build
system
and
that
that
would
then,
of
course,
like
leverage
back
on
to
like
well
who
who
reviewed
the
design.
That
said
that
it's
actually
doing
it.
That
way.
Yeah.
F
I
I
like
the
idea
of
like
having
a
very
like
public,
like
security
statement,
be
published
like
by
builders
or
like
something
like
that
like
linking
off
to,
I
don't
know
like
a
an
assessment
like
a
professional
assessment
or
just
walking
through
maybe
the
pieces
or
the
I
don't
know,
yeah.
Why
or
how
you
meet
criterias
xyz.
A
I
I
think
that
there's
an
outstanding
issue
related
to
this
that
perhaps
trishank
and
joshua
were
going
to
look
into.
A
Okay,
so
I
I
think
that
this
was
it's
a
very
good
discussion.
If
I
could
summarize
where
I
think
that
we've
landed,
it's
that
it
sounds
like
the
split
as
proposed
in
issue
130
regarding
automatic
automatic
verifiability
makes,
makes
sense,
and
that
we've
outlined
that
there's
sort
of
additional
open
questions
around
how
you
you
imbue
trust
into
certain
keys
or
how
or
like
how
it
gets,
communicated
and
and
so
forth
and
then
and
that
that
is
future
work
that
that
that
needs
to
be
done.
Is
that
fair.
C
Oh
sorry,
you
mean
for
the
trust,
yeah,
that's
that's
a
good
question,
so
I
think
joshua
you
should
chime.
In
also,
we
want
to
say
that
this
is
one
way
for
you
to
imbue
trust
on
your
keys
right.
You
may
already
have
your
own
existing
infrastructure.
C
Yes,
I
think
abhishek
is
alluding
to
to
imbue
trust
already,
for
example,
some
people.
Maybe
you
may
want
to
reuse
the
existing
x509
infrastructure
right,
which
is
totally
fine.
This
is
one
proposal
for
using
something
called
tough,
which
I
think
I
believe
the
cncf
recommends
this
to
secure
deployments.
So
this
is,
after
your
whole,
build
system.
Your
developers
have
produced
attestations
and
everything.
How
do
you
package
all
of
them
up
and
then
say
you
know?
C
D
I
think
that
makes
sense
yeah.
I
don't
have
anything
to
add
at
this
point.
We
we've
talked
about
effectively
prototyping,
something
like
this
with
puff
in
issue
101.
D
So
I
think
this
discussion
is
a
good
indication
of
like
I
need
to
get
to
that
approach.
I
can
work
effectively.
C
So
it
might
be,
it
really
depends
on
the
platform
to
go
back
to
abhishek's
question
like
how
easy
would,
for
example,
using
tough
would
be
for
like
the
lower
levels.
I
think
level,
one
probably
wouldn't
even
use
it
right,
there's
probably
really
no
attestations
there
really.
I
could
be
wrong
someone
someone
correct
me
if
I'm
wrong
but
yeah
for
things
like
level,
two,
two
and
three
and
so
forth.
We
expect
automation
to
handle
a
lot
of
this
for
you.
C
H
Yeah,
sorry,
I
was
just
gonna
second
that
and
then
from
my
understanding,
just
as
sort
of
mostly
as
the
end
user
of
a
lot
of
the
the
salsa
stuff,
the
the
thing
that
I'm
viewing
sort
of
level
one
as
is
like
level
one,
is
getting
started,
establishing
just
provenance,
even
if
that
provenance
is
incorrect.
It's
better
than
literally
not
knowing
anything.
That's
going
on.
So
even
if
that
the
stuff
that
you
you're
doing
is
signed
by
you,
know
invalid
stuff
and
and
is
or
sorry
not
signed.
H
But
if
it's
being
generated
by
compromised
things,
it's
it's
still
better
to
have
it
and
to
then
you
know
eventually
work
backwards
and
fix
stuff
than
it
is
to
not
have
it
at
all
and
not
even
know
where
to
start.
A
So
I
I
think
that
that
might
be
a
good
segue
in
into
the
next
agenda
item.
I
think
it
was
at
the
last
meeting
that
that
would
mention
that
matthew
had
had
put
together
this,
this
doc
sort
of
outlining
the
goals
for
our
party
proposed
goals
for
each
of
the
software
each
of
the
salsa
levels,
and
I
think
if,
if
enough,
people
think
that
this
sounds
good,
then
then
maybe
matt
can
can
put
a
apr
together
to
sort
of
to
sort
of
codify
these
things.
F
Honestly
also
just
figuring
out
realistic
or
more
creative
use
cases
or
specific
things
for
a
specific
or
a
blocker
that
you
might
have
moving
to
the
next
level.
That's
a
big
sort
of
it's
an
intent
of
the
kind
of
use
cases
as
well.
H
I
can
definitely
provide
you
know
as
an
end
user,
not
somebody
who's,
not
like
developing
software.
That's
intended
to
be
sold
but
like
building
our
own
internal
stuff
and
obviously
like
banking
apps.
That
kind
of
thing,
I
think
for
us,
like
one
of
the
big
things
that
we
want
to
also
make
sure
of
is
like
you
know.
H
I
think
that
also
ties
back
into
the
sort
of
what
is
the
general
scope
of
of
salsa,
making
sure
that,
like
when,
when
looking
at
this
and
looking,
you
know
what
what
does
you
know
like
the
sorts
of
things
I'm
looking
at,
not
just
purely
from
a
regulatory
and
compliance
perspective,
but
just
other
you
know
generally,
like
oh
salsa,
helps
us
deal
with
these
things
like
if
we
start
to
follow
the
frame.
H
You
know
the
salsa
framework
that
helps
you
know
mitigate
these
sorts
of
risks
and
it's
focused
around
these
sorts
of
things,
whereas,
let's
say
you
know,
nist
853
to
be
clear,
I'm
not
saying
that
they're
equivalent
in
any
way,
I'm
just
kind
of
saying
like,
whereas
that
sort
of
handles
these
sorts
of
things,
there's
some
overlap
between
them.
There's
yeah,
like
those
sort
of
things
I
think,
helps
us
out,
because
you
know
when
I
also
look
at
some
of
the
use
cases.
There's
a
lot
of
you
know.
A
I
yes,
I
I
I
agree
with
you
that
it's
important
to
to
have
the
scope
defined.
I
think
so
far.
It's
so
far
the
scope
is
strictly
tampering,
and
I
wonder
if,
if
you
feel
like
that
or
if
anyone
feels
that
that
is
either
insufficiently
broad
or
if
or
if
it
needs
further
further
discussion
around
what
exactly
we
mean
by
by
tampering.
H
So
my
my
quick
two
cents
is:
I'm
I'm
curious.
H
What
so
I
understand
it
from
the
tampering
perspective
and
I
think,
if
I
would
also
be
under,
I
think
that
maybe,
if
that's
like
the
breath,
it'd
be
useful
to
understand
a
little
bit
of
the
the
depth
because,
as
an
example
right
like
I
could
today
right
assuming
I
have
a
builder
I'm
using
tekton,
I'm
using
chains
I'm
using
in
toto.
H
I
can
still
have
that
if
I
don't
have,
if
I
have
a
builder
and
assuming
that
the
builders
themselves
are
not
coming
in
and
being
authorized,
I
can
have
a
builder
still
do
whatever
it
needs
to
do,
create
compromised,
artifacts
and
all
the
things
are
going
to
sign
it
right,
everything's
going
to
say
yep
it
was
signed.
I
can
say
that
it
wasn't
like
within
the
scope
of
what
was
happening
there.
It
wasn't
tampered
with,
but
my
stuff
is
still
compromised
at
that
point.
So
I'm
curious
to
to
know
like
okay.
C
E
C
H
Oh
I
to
be
clear.
I
I
agree
as
well.
I
think
that
the
question
then
just
becomes
like
if
there
are
certain
things
that
are,
let's
say
out
of
scope
of
salsa,
then
it's
clearly
like
okay
salsa
is
focused
around
these
things.
We're
saying:
hey!
Look
at
the
end
of
the
day.
Let's
say
you
are
checking
for
for
signed
builders,
and
you
know
somewhere
down
the
line
has
compromised.
You
know
the
linux
kernel
supply
chain.
H
You
know,
there's
not
like
there's
nothing.
Salsa
is
going
to
be
able
to
do
for
you
there,
but
it
would
be
useful
to
kind
of
you
know
know
where
those
things
you
know
where
salsa
begins
and
ends
so
that
we
can
kind
of
say,
hey,
look
as
the
end
user.
H
If
you,
if
you
are
concerned
about
those
things,
that's
very
much
stuff,
you
have
to
sort
of
deal
with,
but
to
better
understand
you
know
some
of
those
things
right
like
if,
if
salsa
recommends,
you
know
all
of
your
build
tools
should
be
signed
and
maybe
something
like
have
a
transitive
salsa
score
or
something
that
where
you
know
yes,
you
know
you're,
let's
say
installing
cargo
rust
all
that
sort
of
stuff.
You
should
be
using
signed
versions
of
those
things.
You
should
be
checking
the
hashes
of
those
things
yaya.
H
I
Yeah,
it
strikes
me
that
some
of
the
values,
even
if
a
compromised,
let
me
get
rid
of
that,
even
if
you
have
a
compromised
artifact
that
reaches
production,
which
is
the
nightmare
scenario.
It's
still
useful
to
have
a
forensic
chain
that
can
give
you
a
fighting
chance
of
working
out
how
it
got
there.
I
Each
of
the
levels
of
assurance
makes
it
both
harder
to
tamper
and
easier
to
detect
where
tampering
occurred,
even
if
that's
by
not
deduction
abduction
or
abducement
abducing,
whatever
the
fancy
thing
that
sherlock
does,
where
he
eliminates
possibilities
and
then
whatever's
left
has
to
be
the
thing
and
it's
the
same
thing.
As
you
add
each
of
these
controls
more
and
more
possibilities
that
a
tampering
could
have
occurred
in
such
in
such
a
way
are
eliminated
and
the
places
you
have
to
look
are
reduced
does
does
that
fit?
H
So
yeah
I
I
100
agree
with
you
on
on
that
front.
I
I
definitely
see
the
forensic
chain
as
being
super
important.
I
think
one
thing
and
I
don't
want
to
go
too
deep
down
the
rabbit
hole
right
where
there
is
the
concern
around
like
well,
you
have
a
forensic
you
have
a
chain
of
you
know
you
have
a
forensic
chain,
but
if
your
supply
chain
was
compromised,
is
that
now
compromising
all
the
rest
of
your
tools
throughout
your
entire
system?
H
And
then
you
know
your
ability
to
actually
do
the
forensics
is
now
compromised.
I
don't
want
it
like
to
be
clear:
I'm
not
saying
that
we
want
to
go
down
that
rabbit
hole,
but
I
think
at
least
sort
of
saying
yeah,
that's
still
a
risk
and
that's
something
that
you
need
to
kind
of
sort
of.
You
know
whether
it's
separate
trust
domains
or
whatever,
like
at
least
sort
of
put,
that
out
there
as
a
risk.
A
Yeah,
so
I
thank
you
for
this,
and
yes,
I
it
like
it
it.
It
does
seem
as
though
it's
it's.
It's
sort
of
the
transitive
dependency
problem
like
whether
or
not
that
dependency
is
like
code.
That's
included
in
the
like
in
the
final
artifact
or
like
code
that
was
used
to
to
to
produce
it.
A
Sort
of
my
my
expectation
is
that
those
things
are
in
scope
for
salsa
the
project,
but
they,
but
but
that
it
might
not
be
be
addressed
at
salsa
level,
one
one
through
four
like
at
least
as
it's
currently
defined.
We
for
salsa
one
through
four,
we
sort
of
rolled
out
transitive
the
problem
of
like
transitivity,
because
it's
sort
of
it's
sort
of
a
recursive
problem.
And
you
need
your
base
case
first.
A
And
this
is
the
base
case
and
like
and
like
the
way
that
I'm
thinking
about
using
it
is
is,
is
by
being
able
to
like
look
at
the
at
the
artifact
that
I
got
and
seeing
what
its
salsa
level
is
and
then
using
the
providence
to
see
what
its
dependencies
are
and
what
salsa
level
they
have
and
then
being
able
to
like
recurse
through
sort
of
through
that
to
sort
of
figure
out
where
we
need
to
make
further
investments.
F
Yeah,
I
I
liked,
I
think
joshua
said
just
as
as
a
way
of
making
trust
relationships
explicit.
I
think
that's
that's
a
great
sort
of
headline
for
especially
like
a
lower
level
sort
of
just
get
all
of
the
prominence
you
want
just
figure
out
where
you're
I
don't
know
you
know
where,
where
you're
vulnerable
or
what
you
were
vulnerable
to
and
if
nothing
else,
it
provides
a
way
to
sort
of
prioritize.
A
C
Actor
right
so
maybe
to
add
to
that,
would
it
be
fair
to
say:
let
me
try
to
paraphrase
tom's
to
see.
If
I
understand
him
correctly,
maybe
salsa
should
be
focused
on
any
one
actors
particular
play
that
particular
project
right
there.
One
activated
many
projects
and
you
can't
really
guarantee
anything
about
the
rest
of
the
system.
You
could
recursively
as
a
consumer,
go
and
check
their
salsa
supply
chain
to
be
one
at
that
stations,
but
I
don't
think
that
one
particular
actor
is
responsible
for
it.
A
I
thought
I
think
that
that's
accurate
as
as
to
where
we
are
now,
but
I
think
that
I
would
like
to
see
you
know
in
a
couple
years
once
things
are
are,
are
are
sorted
out
that
maybe
there
is
room
for
like
a
salsa
level,
five
or
level
six.
A
That
says
you
must
use
salt
level
four
or
higher
or
or
higher
artifacts,
and
because
at
some
point
like
so
as
a
project
maintainer,
I
do,
and
I
don't
have
have
have
control
over
the
over
the
supply
chain
of
of
of
my
dependencies
like.
I
can't
necessarily
go
and
fix
it
for
them,
but
I
do
have
a,
but
I
do
have
a
choice
about
which
dependencies
I
take
and
like.
A
If
I
see
that
they're
bad
and
that
there's
high
risk,
then
I
can
ask
them
to
to
to
to
fix
it
which
might
include
funding
or
I
can,
or
I
can
pick
a
different
way
to
fulfill,
that
requirement
of
my
product.
A
And
it's
nice
shifting
security
so
far
left
it
moves
out
of
your
org
in
some
cases,
right
and-
and
hopefully
something
that
can
happen-
is
that
the
community
can
see.
Oh
look,
there
are
a
thousand
of
us
depending
on
this
one
project
that
has
that
has
poor
hygiene.
Maybe
we
can
all
like
pitch
in
to
to
fix
that.
A
E
E
A
Okay,
so
I
think
that
was
a
pretty
good
discussion.
My
my
takeaway
is
that
generally-
and
you
know
we
can
wait,
we
can
wait
to
see
generally.
No
one
has
any
issues
with
with
with
the
latter
goals
as
as
matt
spelled
out,
but
that
we
feel
that
there's
still
a
bit
more
work
to
be
done
in
defining
not
the
level
and
ladder
goals
but
sort
of
the
broader
goals
for
for
for
salsa
in
particular.
That
is
like
that.
A
Just
saying
that
it's
that
the
goal
is
is
to
prevent
tampering
is
not
quite
sufficient
and
that
we
can
outline
some
of
these
other.
Some
of
these
other
future
use
cases
is
that
is
that
a
fair
place
that
we've
wound
up.
A
C
A
Great
all
right,
so
moving
on
tagging
version,
0.1
abhishek
has
proposed
that
we
have
a
goal
of
of
of
tagging
it
by
by
september
15th
they're,
like
does
anyone
have
any
last-minute
reviews
that
they
would
like
to
do
any
issues
that
they
would
like
to
see
resolved
before
this
point?
A
D
I
seem
to
recall
there
are
a
couple
of
issues
we
discussed
in
either
previous
meeting
of
the
one
before
that
that
we
had
talked
about
trying
to
resolve
before
an
initial
release.
I
think
one
of
them
was.
D
The
best
definition
of
source
was
it,
which
I
think
tom's
taking
a
stab
at,
but
I'm
trying.
A
There
were
two:
there
were
two
that
I'm
aware
of
one
is
one
is
issue
115,
which
has
been
resolved,
which
is
that,
as
as
written
the
the
the
requirements
previously
required
configures
code
at
levels,
one
and
two,
and
that's
just
not
how
a
large
number
of
build
systems
work
work
work
today,
so
that
that
was
resolved.
A
Another
one-
I
I
don't
know
if
it's
so
much
well,
pardon
me,
I
suppose
it.
It
is
related
to
issue
129,
which
is
better
to
find
source.
But
there
is
issue
127,
I
think,
which
is
making
version
control
required
at
level
one
this
this
one
is
this
one
is
not
resolved.
A
I
think,
but
I
think
that
with
so.
I
think
that
we
could
punt
on
this
until
the
next
revision
or
or
or
we
could
try,
try
to
resolve
it
now.
I
think
that,
with
the
lighter
goals
that
that
that
matt
outlined
and
the
and
the
discussion
around
automatic
verifiability
that
that
that
we
could
that
that
I
might
propose
that
we
close
this
as
as
as
won't
fix,
but
you
know
I'd
like
to
hear
what
other
people
think
yeah
michael.
H
So
I
I
think
it's
worthwhile
to
just
ask
the
question
of
like
I
like.
I
personally
think
you
know,
every
salsa
level
should
provide
something
there
should
be.
You
know
some
you
know
like.
Oh
it
does
this
for
you,
so
I'd
be
useful
to
understand.
It'd,
be
useful
for
me
to
understand,
like
without
source
code
control.
Does
it
actually
provide,
like
you
know,
does
it
provide
any
value,
but
I
also
recognize,
like
I
know,
one
of
the
things
that
was
brought
up
in
some
of
the
sort
of
off
off
channel
discussions
was.
H
There
is
a
lot
of
software
that
is
out
there.
That
is
like
a
gzipped
tarball,
that's
on
some
professor's
website,
and
you
know,
a
lot
of
people
are
downloading.
It
unpacking
it
and
compiling
it,
especially
in
the
machine
learning
world-
and
you
know,
is
there
still
value
in
in
handling
that
versus
saying
you
know
everybody
has
to
use.
You
know,
source
code
control.
A
Yeah,
so
I
I
think
that
there
are
two
that
there
are
two
thoughts
there.
So
one
is
in
the
in
the
salsa
ladder.
Motivation
talk
it's
it's,
it
does
discuss
what
what
level
one
does,
even
even
in
the
absence
of
of
of
source
code
control.
Now
like
whether
or
not
you
find
that
compelling.
I,
like
that's
a
different
story.
Please
please
provide
comments.
A
If,
if
you
don't,
I,
I
think
that
to
the
like
one
of
the
issues
that,
like
I
have
with
with
with
requiring
source
control
at
level,
one
is
it
like
goes
along
with
the
automatic
verifiability
aspect,
because
what
we
very
well
may
have
is
that,
like
you,
might
have
a
a
a
ci
cd
system
that
like
works
in
like
multiple
steps
and
in
like
step,
one
it
like
checks
out
the
source
code
from
from
from
some
repo
zips
it
up
and
then
drops
it
and
then
drops
it
in
a
bucket
and
then
in
the
very
next
step
it
like
it
like
takes
the
zip
file
out
of
that
bucket
and
like
does
the
build,
and
if,
if
that
build
step,
is
the
thing
that's
producing
the
provenance
which
is
good
like
that?
A
Still
helps
us
out.
We
don't
have
a
record
in
the
provenance
of
the
source
control
system
that
it
came
from,
so
we
so
it
looks
so
it
would
look
as
though
it's
failing
that
that
requirement,
but
the
organization
that
has
that
setup,
they
might
say,
but
we
are
using
source
control
so.
H
Yeah
so
my
yeah,
my
only
other
two
cents-
and
this
is
just
coming
from
because
I'm
very
much
on
the
fence
with
with
it.
Just
because
there
is
an
element
of.
H
Kicking
people
to
just
really
start
doing
the
right
thing
like
if
you
are
not
putting
your
code
in
you
know
in
in
actual
sort
of
a
real
version,
control
system,
whatever
it
may
be.
Like
you
got
problems
and
with
that
said,
I
also
recognize.
On
the
other
end,
there
is
a
pretty
reasonable
way
of
just
saying
yeah,
but
at
least
with
salsa
one
without
the
source
code
thing
you're
starting
to
know.
H
Where
is
this
code
coming
from
right
and
I
think
like,
but
I
think
we
need
to
just
be
clear,
like
if
you're
only
doing
salsa
one
you're
really
not
getting
much
of
any
value
out
of
it
and
in
fact
it's
kind
of
it's
kind
of
scary,
but,
like
I
think
on
that
end,
I
think
there's.
H
H
You
have
a
legacy
environment
that
you
know
with
people
doing
silly
things
to
you
know
work
around
stuff,
whereas
you
should
be
trying
to
get
to
salsa
level
two
as
as
quickly
as
possible,
but
I
guess
maybe
I
even
I
convinced
myself
that
salsa
one
seems
to
be
reasonable,
for
that
of
you
know
just
saying:
look
if
you're
not
using
source
code
control,
we're
gonna,
at
least
in
the
very
least,
tell
you
where
the
code
came
from,
but
we're
not
making
any
attestation.
You
know
any
sorry
assertion
about
anything.
H
F
Another
potential
justification
for
it
being
should
would
just
be
like
towards
like
automatic
verification.
If
you
can't
automatically
verify
like
from
your
build
system,
your
build
system
does
not
know
if
your
source
is
in
source
control.
This
is
just
a
hey.
That's
a
work
item
for
you
to
get
to
l2
you
need
to
you
need
to.
You
know,
know
you're
fetching
it
from
somewhere
that
has
all
of
the
properties
that
will
be
built
on
later.
A
Yeah,
so
great,
so
picking
up
some
of
the
comments
in
the
in
the
chat
thread
there's
a
suggestion
that,
like
maybe
salsa
one,
should
actually
be
called
salsa
level
zero
and
ultra
shank
wood
or
like
excellent
shank.
Would
you
like
to
to
speak
to
those
things.
C
Oh
sorry,
you
mean
clarify
l0
and
l1
yeah.
I
think
there
should
be
a
difference.
L0
should
be
the
case
of
absolute.
Nothing,
maybe
maybe
to
use
michael's
running
example
of
downloading
a
random
tarball
from
a
professor's
website
right
over
http.
No
less
l1
should
give
you
something
more
in
my
estimation.
Otherwise,
why
call
it
l1
at
all?
I
think
we
should
distinguish
between
no
security
and
some
a
little
bit
not
much
to
change
the
world,
but
it
gives
you
something
extra
and
in
this
case
I
believe
it's
unsigned
at
that
station.
H
Yeah,
so
just
to
kind
of
also
just
go
back
one
one
step
yeah.
I
think
if
you
are
downloading
it
from
a
random
professor's
website,
I
think
the
one
thing
is
or
just
a
random.
You
know
you're
pulling
it
from
somewhere
a
shared
drive
or
whatever.
I
think
the
one
thing
that
salsa
one
still
does
provide
right
now
is
that
you
are
making
that
explicit.
You
are
saying-
or
at
least
it
should
be
explicit
in
the
salsa
level
right,
you
are
explicitly
saying
I
am
pulling
this
from
a
website.
H
I
am
you
know
w
getting
or
I'm
curling
it.
I
am
pulling
it
from
the
shared
drive.
H
You
know
that
sort
of
thing,
because
then,
in
the
very
least
you
you
know
hey
where,
where
this
came
from
or
like
even
something
like,
I
am
looking
for
this
to
show
up
under
slash
temp
somewhere
at
some
point
like
at
least
making
that
explicit.
Then
you
know
the
the
sorts
of
things
of
okay
that
needs
to
get
fixed,
because
I
know
like
in
in
the
enterprise.
I
know.
H
One
of
the
biggest
concerns
for
us
is
just
that
shadow
I.t
problem
right
where
some
developers
somehow
figured
out
some
way
of
doing
these
things,
and
even
the
very
least,
if
we
can
start
to
sort
of
say,
look
we
want
to
have
an
addis.
We
want
to
have
some
metadata.
Let's
just
say
we
want
to
have
some
in
total
layout
right.
You
are
specifically
saying
you're
doing
these
bad
things.
You
have
two
weeks
to
fix
it
right
or
we
just
start
to
say
you
can't.
H
I
Yeah
so
in
terms
of
what
should
or
shouldn't
be
in
l1,
it
seems
to
me
like
this
goes
back
to
the
question
of
how
much
of
salsa
is
intended
for
prevention.
You
know
controls
that
make
it
impossible
to
do
this,
or
do
that
so
permissions
around
build
systems.
I
That
kind
of
thing
how
much
of
it
is
straight
up
detection
I've
detected,
some
kind
of
tampering
has
occurred,
and
so
I
can
take
action
and
the
last
one
is
that
third
sort
of
slightly
strange
case
of
forensics,
where
I
neither
prevented
nor
detected
the
tampering
at
the
time.
But
I
want
to
be
able
to
reduce
the
places
where
I
go
and
do
a
forensic
inspection
to
work
out
how
a
tambourine
occurred
when
it
was
detected
out
of
band.
I
Somehow
the
reason
I
bring
those
up
is
because
to
me
it
seems
like
the
downloading
the
source
code
from
the
professor's
website
kind
of
has
none
of
those
things
right.
So
I
would
say
I
would
argue
that
l1,
at
least
one
of
those
three
kind
of
general
categories
has
to
be
satisfied.
It's
either
preventing
detecting
or
making
forensics
tractable,
which
you,
like
you,
like
all
three.
In
my
opinion,.
F
Theme
that
it
felt
fell
out
of
the
levels
is
more
just
about
increasing,
like
data
and
integrity
assurance.
It's
not
necessarily
about
how
you
apply
or
use
that
data,
be
it
for
forensics,
for
you
know,
admission
control
for
whatever
it
is
about
sort
of
understanding
the
unknowns
in
your
system
and
then
being
able
to
act
on
them.
It's
not
so
much
it
feels
like
like
gradually,
I
don't
know
increasing
security.
F
A
Yeah,
so
yes-
and
so
I
think
to
that
point-
that
at
at
lower
salsa
levels
like
they
can
do
something
in
the
way
of
of
of
prevention.
A
But
you
know
there
are
still
plenty
of
ways
for
for
for
an
attacker
to
to
get
around
it,
but
it
does
certainly
provide
for
for
for
that
forensic
ability,
because
the
fact
that
you
pulled
the
source
code
from
a
website
should
be
encoded
in
the
province
like
there
will
be
a
there
will
be
a
uri
that
was
fetched
from
and
a
hash
of
the
hash
of
the
archive
and
and
that
can
be
used
by
by
by
an
analyst
to
like
to
like.
I
Can
I
pivot
slightly
then,
to
propose
another
sort
of
axis
for
for
categorizing?
What
goes
where,
which
would
be
it
sounds
to
me
like.
We
have
well
really
two
axes,
two
kinds
of
things
that
are
helping
to
categorize
what
goes
into
each
level,
one
of
which
is
what
is
the
capability
of
the
attacker
that
we're
worried
about?
So
how
motivated?
How
capable
and
the
other
one
is,
how
much
effort
it
is
for
the
defender
like
how
complex
is
this
to
to
achieve
so,
for
example,
something
like
source
control
is
pretty
simple.
I
I
go
and
create
an
account
on
github,
and
it's
all
there,
something
like
capturing
the
provenance
of
a
download,
probably
takes
more
effort
and
might
have
a
like
a
different
capability.
I
I
don't
have
an
answer
like
how
I
would
lay
that
out.
I
just
know
that
I
have
a
consulting
background,
so
I
smell
a
2x2
and
I
have
to
have
it.
F
Yeah,
I
think
that's
basically
just
like.
What's
the
value
proposition
of
this,
and
talking
about
that
with
all
of
the
things
I
think
is,
is
just
total
common
sense
like
that
that
should
be
like
hey.
How
much
cost
is
this
for
the
average
person?
How
much
value
do
we
get
talking
about?
You
know
the
sophistication
of
attackers,
maybe
it's
valuable,
but
fundamentally,
like
just
your
average,
I
don't
know
convenience
hacker
versus
a
government,
so
security
security.
A
So
I'm
cognizant
of
time-
and
we
have
two
minutes
left-
I
I'm
not
sure
where
we've
landed
with
tagging,
a
a
point
release.
A
So
I
I
will
propose
in
an
issue
in
in
the
github
repo
and
and
and
take
and
take
the
committee
members
and
and
we
can
have
and
we
can
have
a
discussion
there.
A
A
All
right
well
that
that
is
basically
all
all
the
time
we
have.
Thank
you
all
very
much
for
your
participation
and
we'll
see
you
next
time.