►
From YouTube: SLSA Specifications Meeting (August 22, 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
I
guess
we're
missing
a
couple
of
the
regular
so
I'll
just
give
it
a
few
more
minutes
mark's
out
this
week,
so
I'm
going
to
be
trying
to
run
the
meeting
in
his
third.
B
We've
got
the
same
100
proposal
document
to
keep
working
through
some
of
the
items
in
and
a
couple
of
topics
from
melbourne
mike
as
well.
C
I
can
just
show
the
diagram,
I
don't
know
what
kind
of
questions
will
come
from
it.
So
five
five
minutes,
I
think
it'll
help
with
the
evidence
of
security
claims
and
the
salsa,
or
rather
the
source
versus
build,
but
I
don't
think
it's
gonna
take
very
long.
Unless
people
have
questions.
D
E
So
it's
more
yeah,
it's
an
inform.
It's
a
combination
of
an
informational
thing,
along
with,
like
probably
just
just
some
open
questions
of
something
that
we
probably
should
address
in
the
specification
meeting.
So
it's
it
shouldn't.
Take
too
long,
okey-dokey.
B
I
want
to
try
and
make
sure
that
everyone
gets
to
see
melvin's
diagram,
so,
okay
I'll,
do
it
try
and
do
the
housekeeping
first,
so
we've
got
u.s
labor
day
on
september
5th,
and
I
think
everyone
here,
apart
from
me,
is
us-based
right.
So
that
sounds
like
a
good
one
to
cancel.
If
anyone
has
strong
objection,
please
make
it
known
and
then
the
other
one
is
next
monday's
national
holiday
in
uk,
where
I'm
based
and
mark
is
out
on
pto,
so
that'll
mean
both
of
the
workstream
leads
are
out.
B
A
B
Well,
I
guess
that's,
probably
everyone
so
we'll
jump
in
melbourne.
Do
you
want
to
show
us
your
diagram
and
talk
us
through
that.
C
Thank
you
I
was
saying.
Hopefully
my
screen
won't
be
problematic
and
in
case
this
is
too
small
print.
The
diagram
I'm
gonna
go
over
is
in
this
github
issue
and
I'm
going
to
share
I'm
trying
to
open
it
here.
C
B
C
And
I'll
zoom
in
so
this
is
my
attempt
of
trying
to
visualize
the
the
why
we
want
to
separate
build
versus
source
and
who
should
be
attesting
to
what
and
some
of
this
also
has
security
evidence
claims.
So
I
think
it
can
be
used
for
a
bunch
of
different
reasons.
Now
this
is
just
draft
right
now,
but
I
wanted
to
show
what
I've
been
working
on.
C
You
know
the
the
container
images
they
have
the
security
tools
and
they
do
the
deployment,
if
there's
some
sort
of
runtime
or
evidence
locker,
if
they
own
everything
full
of
full
salsa
attestation
can
be
claimed
by
that
provider,
but
where
it
starts
getting
tricky
is
well
what
if
they
don't,
have
everything
right.
What,
if
there's
a
public?
Oh,
I
did
not
mean
to
do
that.
A
public
image,
repo
right
or
public,
open
source
repo-
they
don't
necessarily
have
visibility
into
how
those
packages
are
not
packages.
C
You
know
how
that
community
is
creating
the
code,
betting,
the
code
right,
and
so
they
may
not
be
able
to
attest
to
those
particular
pieces
right.
So
that's
kind
of
like
unknown
trust.
C
The
provider
could
say
we
have
full
salsa
at
the
station
for
build
and
source
with
the
exception
of
these
packages
right
because
we
we
don't
control
them,
then
you
talk
about
well
what,
if
the
runner
or
the
worker
is
actually
on
the
customers
inside
customers,
environment,
so
it's
behind
a
firewall.
C
C
I,
the
customer,
can
bet
for
salsa
4
at
the
station
for
source,
but
the
build
servers
can't
say
that,
because
it
can't
tell
what's
happening.
However,
it
does
get
the
information
from
the
customer
because
it
has
that
communication,
so
it
can
attest
to
the
hosted,
build
service
and
what
it's
performing,
but
it
can't
attest
to
necessarily
the
source.
C
And
then
you
know
this
is
a
different
variation
here.
Where
you
know,
if
there
are
it's
just
the
repo
the
software
and
then
the
rest
of
it
is
hosted
right.
The
customer
can
still
attest
to
the
the
source,
but
then
the
build
provider
can
attest
to
obviously
just
the
build
part
and
the
security
at
the
station,
et
cetera.
A
Quick,
quick,
quick
comment:
if
you
don't
mind
interrupt
me,
you
can
you
can
assert
that
hey
someone
else
attests
this.
Yes,.
C
A
The
usual
solution
to
this
is,
you
know
I
can't
see
in,
but
I
have
perhaps
rightly
or
wrongly.
I
trust
this
other
other
source
and
you
might
too,
and
I
can
at
least
assert
that
they
assert.
C
C
That
is
deceiving
right,
that's
misrepresented
because
you
don't
know
what's
happening
under
the
covers
right.
You
only
know
about
your
portion,
not
the
rest,
but
you're
right.
If
someone
can
provide
that
attestation
for
you,
you
could
say
my
hosted.
Build
service
is
also
whatever
compliant
and
oh
by
the
way
on
behalf
of
the
customer.
They
are
attesting.
You
know
this
source
code
compliance,
but
to
say
that
you
are
salsa
level,
four
for
build
and
source.
C
When
you
don't
know,
what's
happening
with
the
source
code,
that's
where
it
gets
tricky,
and
so
that's
why
I'm
advocating
for
the
the
separation
of
source
and
build,
but
then
also
this
these
diagrams
could
be
used
used
for
the
security
requirements.
Discussion
like
evidence
of
security
right,
the
customer
can
provide
it
or
the
you
know
hosted
build
service
can
provide
it,
and
so
you
this
is
just
different
scenarios.
C
C
So
there
there
are
discussions
in
the
salsa
spec,
like
somebody
wrote
where
is
it
salsa
spec
talked
about.
You
know
a
survey
I'm
trying
to
find
where
that
was.
It
was
for
the
security
requirements
right
evidence
of
security
claims
as
an
example
that
there
would
be
a
targeted
survey.
It's
like
yes,
this
is
good
as
long
as
it's
standardized.
What
does
that
mean.
C
That
you
would
have
to,
I
lost
my
diagram.
C
C
So
this
could
be
a
way
of
standardizing
that
how
we
provide
information
or
what
we
expect,
but
it
was
for
me,
it
was
more
of
visualization
of
showing
the
different
scenarios
that
could
happen
when
someone
tries
to
say
their
salsa
level
four
and
why
they
can't
really
claim
their
salsa
level
four
if
they
don't
have
full
visibility.
A
Have
you
considered
the
case
of
reproducible
builds
where
at
least
you
can
do
a
double
check
of
the
produced
images,
though
not
necessarily
the
security
tools.
C
I'm
not
yeah
yeah,
no,
I'm
not
taking
that
into
consideration.
Yet
this
is
still
in
draft
I'm
still
trying
to.
I
got
that
got
it
so
no,
but
I
will
put
it
on
my
to
do.
E
As
well-
oh
yeah
yeah-
I
think
this
is
one
of
the
things
that
I
also
think
is
is
kind
of
an
interesting
challenge,
because,
like
one
of
the
things
that
you
know,
we
stated
as
a
goal
or
a
non-goal
is
is
salsa
as
it
stated
today
is
not
transitive.
It's
not
transitive.
It's
not
transitive,
however,
in
certain
contexts
right,
you
know,
if
you're
pulling
in
other
dependencies
yaya
at
least
then
you
kind
of
go.
E
You
can
ask
the
question
to
the
package
that
they're
you
know
pulling
in
and
saying
hey
at
least,
if
I
can
tie
back
the
source
to
the
build,
I
can
go
and
look
at
the
source
and
look
at
their
the
packages
that
they
depend
on
at
least
rely
that
they're
probably
pointing
to
those
packages
and
and
whatever,
and
there
could
still
be
depending
on
if
it's
all
packaged
up
together
versus
hey,
it's
just
dynamically
linked
or
whatever.
There's.
E
Definitely
some
open
questions
on
how
that
might
work
right,
because
you
could
end
up
with
a
situation
right
where,
where
hey,
actually,
everything
gets
pulled
down
all
at
the
same
time,
right
like
an
npm
model
or
like
that
or
there
could
be
certain
contexts
where
it's
like?
No,
I'm
just
going
to
assume
you
have
open
ssl
installed,
and
you
know
that
sort
of
thing,
but
then
there's
also
some
interesting
problems
when
you
start
to
look
at
like
statically
compiled
things
like
like,
go
where
hey.
E
Actually,
you
are
pulling
down
all
the
source,
including
all
the
source
of
all
the
dependencies,
and
then
it
becomes,
I
think,
also
kind
of
a
complicated
situation
there
as
well,
because,
like
I
yeah,
I
don't
know
what
the.
C
Are
you
referring
to
kind
of
like
an
internal
house
repository
of
all
the
dependencies.
E
Well,
I
mean
one
of
the
common
ways
right
in
in
or
actually
you
know,
ghost
is
statically
compiled,
pulls
down
everything
and
compiles
it
all
at
at
once,
and
so
that
includes
all
the
upstream
sort
of
source
and
includes
all
of
that
in
there,
and
just
so
just
to
be
clear,
like
you
actually
now
have
all
the
source,
including
well
not
all
the
transit
dependencies,
but
anything
that
is
written
in
go
is
all
all
in
there.
D
Yeah
hi
yeah,
so
so
I
I
agree
with
you
guys.
I
I
just
I'm
having
a
similar
challenges
internally,
discussing
discussing
this
topic.
How
much
I
mean
I
guess:
when
do
we
stop
tracking
all
of
the
metadata
dependencies
and
then
how
do
we
track?
I
guess:
do
we
record
those?
Do
we
use
some
sort
of
like
signature
or
cryptographic
or
how
like
what
do
you
guys
think
on
that
level?
And
then
what
do
you
think
of
I
mean
because
we
can't
control
what
people
build
right?
D
Maybe
aws
or
azure
or
gcp,
have
a
common
attestation
or
a
common
I'll
call
it
images
as
code
right
that
they
publish,
but
at
what
level
do
we
stop
tracking?
What
level
do
we
do?
We
say
yes,
this
is.
This
is
good.
D
D
I
mean
because
I
I've
you
know
per
from
my
experience
right
in
building
building
images
and
then
handing
that
to
engineering
through
a
pipeline
right.
It's
it
that
in
that
image
gets
tracked
in
an
artifact
right
and
that
artifact
it
could
be
any
image
gallery.
It
can
be
an
azure,
an
aws
or
your
own,
and
then
that
artifact
has
some
some
some
sort
of
signature
right
and
then
you
can
download
and
proceed
with
it,
but
it
becomes
difficult
when
it
comes.
D
A
B
So
there's
a
lot
of
scope
in
that
discussion.
I
think
I
think
maybe
the
salsa
general
source
of
select
channel
is
a
good
place
to
start
to
explore
some
of
that
asynchronously.
B
We're,
certainly
not
gonna,
be
able
to
cover
it
all
here,
but
it
looks
like
michael
has
got
his
hand
up
as
well.
Oh.
F
B
F
So
so,
just
to
kind
of
riff
on
that
you
know
the
trans
and
I'm
sorry.
If
this
is
a
newbie
question,
when
the
the
the
sauce,
the
the
access
stations
that
are
made,
do
they
are
they
simply
the
wrapped,
essentially
signature
of
underlying
data
that
may
not
be
transparent
itself
or
does
the
entire
train,
including,
like
the
actual
output
logs,
need
to
be
included
in
that
bundle
and
made
transparent?
F
F
What
went
on
in
that
action-
and
I
know
that
you
know
the
difference
between
the
open
source
world
and
the
commercial
world
like
there-
are
differences,
but
I
guess
as
a
spec,
it
would
be
nice
if
salsa
accounted
for
transparency
of
actions
versus
transparency
of
the
details
within
those.
I
guess
as
we're
talking
about
black
boxes,
that's
kind
of
how
I'm,
how
I'm
interpreting
that.
So
just
my
thoughts
there.
G
I
think
the
endorsement,
which
is
the
summation
of
looking
at
that
or
or
other
stuff
is
the
the
doesn't
have
to
state
what
evidence
is
backed
by
to
me.
Basically,
the
the
dividing
line
for
product
software
could
be
an
internal
skid
ledger
with
salsa
claims
and
on
the
public
ledger.
You
would
put
in
the
endorsement
that
that
you
basically
need
to
have.
G
Authenticator
rights
to
read
into
the
the
skit
store
I'd
rather
like
to
see
salsa
claims,
backed
by
evidence
being
transparent.
If
you
have
access
to
the
salsa
claims
and
you
have
access
to
the
evidence
and
not
divide
those
two
into
two
different
worlds.
Some
to
my
thought
is
that
the
public
side
of
it
would
be
the
endorsement.
That's
what
the
customer
sees
based
on
a
reviewer
auditor
that
looks
at
the
salsa
data
and
it's
the
trust
and
the
reviewer
that
the
end
customer
looks
at
to
make
the
decisions.
B
I
forget
the
acronym
expands
to
now,
but
it's
effectively
a
way
to
link
multiple
software
associations
together
and
indicate
the
presence
of
an
attestation
that
you
don't
have
from
a
trusted
kind
of
end.
Also.
F
I
I
think
so
I
mean
I
think,
having
the
the
I
think,
having
the
separation
or
having
the
you
can
verify,
claims
all
the
way
back,
but
not
necessarily
see,
for
example,
the
logs
of
things
beyond
a
certain
point.
I'm
not
sure
that
the
public
versus
private
is
like.
I
don't
know
that
we
can
be
that
we
might
need
to
be
more
granular
than
that
it
may
need
to
be.
F
You
know
the
world
isn't
just
like
internal
and
external,
but
as
long
as
it
supports
the
concept
of
a
of
a
and
I'm
sorry,
if
I'm
using
the
wrong
words,
but
a
claim
that
could
be
can
be
verified
and
that
points
to
something.
Even
if
you
don't
have
access
to
it,
you
can
verify
that
it
was
made
authentically.
E
Yeah
yeah,
this
very
much
oh
yeah.
This
is
something
that
we
we
talked
about.
I
think
a
little
bit
previously
and
one
of
the
things
we
wanted
to
do
was,
I
think,
make
sure
we
we
had
a
good
understanding
of
the
spec
and
then
we
can
kind
of
go
back
and
say:
okay,
what
do
we
expect
to
be
always
public?
What
do
we
expect
to
be
private,
etc?
Because
one
of
the
things
that
had
been
discussed
previously
is
yeah
like?
E
Could
you
say,
hey
some
somebody
signs
off
on
the
hash
of
the
evidence
right,
you
know,
so
you
have
a
hash
of
the
evidence
and
you
know
so.
If
anybody
ever
needs
to
go
back
and
and
somebody
an
auditor
comes
in
and
says,
okay
now
show
me
that
actual
evidence,
you
could
always
go
back
or
whatever.
So
that
is
something
sort
of
we
had
discussed
and
then
you
know,
there's
the
stuff
that's
coming
out
with
skid
and
and
we
want
to
make
sure
that
that
we
we
interrupt
with
that
and
and
so
on.
E
But
I
think
the
thing
that
we
wanted
to
make
sure
of
also
was
just
like.
First,
sort
of
seeing
okay:
what
are
let's,
let's
see,
what
is
the
evidence
we
want
to
make
sure
exists
and
then
okay,
let's
see
what
evidence
we
expect
to
be
public.
What
evidence
we
expect
to
be
private
in
what
context,
and
that
kind
of
thing.
G
Think
it
gets
back
to
mr
scavenger's
comment
that
not
everything
is
it'll,
it
won't
be
black
and
white
it'll
be
shades
of
gray
in
this
area.
The
other
thing
to
note
is
the
auditing
from
a
when
things
happen.
Point
of
view
in
a
skit
world
with
the
e
notary
system
is
similar.
To
that
same
thing,
you
basically
have
to
go
back
to
the
notary
and
say
show
me
proof
of
what
you
were
given
to
prove
that
michael
was
michael
and
which
michael
it
was,
is
slightly
different
than
here's.
G
G
B
I
think
so,
if
you
could
drop
those
in
the
notes
that
would
help
me.
Okay,.
B
Just
to
keep
things
moving
go
mike.
E
Yeah,
so
actually
it's
probably
gonna
be
short,
given
that
literally
everything
we're
talking
about
is
is
was
gonna,
be
this
this
sort
of
on
topic
here,
so
one
of
the
things
that's
being
was
being
discussed
was
hey
as
we
sort
of
flesh
out
the
specification.
E
How
do
people
sort
of
confirm
that
they
are
actually
conforming
to
the
specification
and
there's
a
couple
of
different
pieces
of
that
right?
One
is
there's,
probably
the
builder
right
and
is
a
builder
conformant
to
the
spec
and
then
separately.
E
There's
different
elements
of
is
your
project
also
following
the
rules
it
needs
to
follow
to
then
be
conformed
right
because
there's
certain
things
that
can
be
just
done
automatically
as
part
of
the
builder,
but
there's
certain
things
that
your
project
in
order
to
really
be
part
of
the
spec
you
know
to
conform
to
certain
things,
needs
to
be
done
a
certain
way.
E
So
there's
some
discussion
about
there's
some
folks
who
have
already
started
like
having
some
chats
a
few
folks
from
chain
guard.
I
think
started
talking
about.
You
know
hey
what
does
it
take
to
become
conformant
to
salsa,
and
then
I
think
that
kind
of
ties
back
to
some
of
this
other
stuff
which
is
like
well.
E
It
also
really
depends
right,
because
there's
also
going
to
be
things
like
auditors,
right
and
you're
going
to
have
folks
who
are
making
you
know
public
claims
which
are
going
to
be
different
than
claims
that
you
want
to.
You
know
where
the
evidence
is
going
to
be
private
and
and
and
that
sort
of
thing
so
just
wanted
to
kind
of
say,
as
we
kind
of
flesh
this
out,
and
I
think
the
takeaway
is
just
once-
we
have
a
good
understanding
of
the
spec,
at
least
for
the
1.0.
E
I
think
we
can
then
go
back
and
say:
okay
now,
how
do
we
expect
folks
to
sort
of
provide
conformance
right?
Because
another
thing
that
we
don't
want,
one
of
what
just
a
big
takeaway
is
what
we
don't
want
to
have
happen
is
just
we
want
to
have
some
protection
around
just
a
random
person.
Just
saying
yeah,
my
stuff
is
all
salsa
for
you
know,
and
I
have
a
social
forebuilder
or
whatever
and
don't
look.
You
know
that
kind
of
thing.
B
Yeah,
I
think
that
all
feeds
into
this
idea
of
the
evidence
of
security
claims
they
were
discussed
a
couple
of
times
because
in
at
least
in
the
salsa
100
time
frame
effectively,
people
are
going
to
claim
that
they
are
sort
of.
You
know,
they're,
meeting
the
salesforce
requirements
and
we
don't
have
a
network
of
auditing
in
place
or
any
any
way
to
enforce
that.
B
So
the
the
thing
we've
discussed
is:
how
do
we
improve
the
confidence
in
the
services
that
are
making
those
claims,
and
the
proposal
has
been
this
documented
evidence
of
the
security
claims.
So,
instead
of
having
or
perhaps
in
addition
to
the
common
requirements
that
we've
listed
in
the
spec
today,
we
say
we
have
effectively
a
questionnaire
type
thing
or
a
a
templated
format
to
follow
where
build
services
can
provide
information
on
how
they
they
meet
information
and
evidence
on
how
they
meet
the
sales
requirements.
B
Which
is
one
of
the
topics
for
today's
effectively
is?
Is
this
truly
decided-
and
I
think,
discussion
today
and
recent
comments
from
emmy
and
melba
were
maybe
not
all
agreed
on
this
yet.
C
B
I
think
it's
that
there
is
there's
no
independent
authority.
That
can
say
this
is
this
thing
is
definitely
sell.
Syllable
three
right,
so
each
downstream
has
to
decide
whether
whether
they
trust
the
system
making
the
or
the
the
the
actor
making
those
claims
and
one
of
the
ways
we
can
help
them
make.
That
trust
decision
is
by
as
part
of
the
self-specification
requiring
some
kind
of
documented
evidence
that
the
claims
have
been
met.
C
Okay,
so
I
don't
know
how
you
want
to
reword
this,
but
I
think
that
would
help
because
otherwise
they
somebody
might
interpret
it
as
universal
salsa
rating
for
security
claims.
A
C
That's
it
right,
so
you
can
reword
it,
however,
but
that
that
was
one
thing
that
stuck
out
and
then
I
guess
the
other
thing
was
about
the
survey
right,
but
can
we
make
it
a
requirement
that
thou
must
use?
C
You
know
sas
das,
you
know,
you
know
sca
buzzer
right
is
there
a
way
that
we
can
at
least
say?
Okay,
if
you're
gonna
make
these
security
claims,
you
should
use
at
the
very
least
what
nist
is
telling
us
to
do
right.
B
Yeah,
so
the
the
common
requirements
in
the
v01
spec
are
mostly
around
effectively
how
you
operate
your
infrastructure.
You
know
what
and
how
you
design,
architecturally
design
the
build
service,
and
we
linked
to
some
common
requirements.
We
had
some
high
level
requirements
like
always
requiring
two-party
approval
for
any
administrative
changes
and
the
feedback
that
folks
have
had
is
that
those
are
a
combination
of
too
prescriptive
in
some
cases
and
not
specific
enough
in
others.
B
So
this
was
an
attempt
to
provide
more
guidance
while
not
binding
people's
hands.
Quite
so
much.
So
that's
why
I
think
mark
rewrote
it
just
suggesting,
including
the
common
requirements
as
a
recommendation,
but
having
the.
B
The
evidence
kind
of
document
to
effectively
yeah
justify
how
you
meet
the
requirements
and
help
your
downstream
evaluate
whether
to
trust
your
claims
about
salsa.
A
C
G
D
I
don't
recall
seeing
that
in
a
document,
but
just
wanted
to
clarify
a
scorecard
versus
an
attestation
claim
right
we
are
do
we
really
want
to
build
a
scorecard,
or
do
we
want
to
build
a
continuous
kind
of
check?
D
Hey?
Yes,
this!
This
is
a
salsa
level
one,
but
at
the
next
run
or
the
next
build.
We
see
that
it
shifted
from
one
to
three
or
whatever
and
then
at
the
third
round
and
shifted
back
to
two.
I'm
just
right.
That's.
G
D
G
B
I
think
there's
some
confusion
in
that
security
claims
are
mostly
about
the
requirements
that
apply
to
a
builder
or
build
service
and
scorecard
mostly
evaluates
how
I
mean
I
haven't
looked
at
scorecard
for
a
long
time,
but
I
think
scorecard
mostly
evaluates
how
a
project
on
that
service
is
configured.
B
So
social
security
claims
are,
we
don't
have
well
defined
in
cell.
So
today,
right,
that's
one
of
the
things
we
have
been
discussing
is
whether
to
split
that
as
a
separate
track
and
flush
them
out
bar
or
whether
to
remove
them
entirely,
and
I
think
we
had
general
agreement
to
separate
them
out
yeah.
G
B
Like
I
don't
think,
there's
a
universal
interpretation
of
what
the
term
source
means
in
this
instance
and
that's.
Why
there's
a
lot
of
disagreement
around
the
social
requirements?
There's
there's!
No!
What
we've
discussed
so
far
doesn't
remove
the
requirements
to
capture
the
origin
of
what
you're
building,
but
it's
talking
about
separating
out
the
requirements
are
applied
specifically
to
the
kind
of
source
control
revision
control
system.
B
So
things
like
requiring
two-party
review.
G
B
E
So
so,
to
take
a
step
back,
I
think
the
thing
here
with
so
I
want
to
kind
of
separate
out
tracing
this,
the
build
back
to
source,
which
that
is
something
that
we're
doing
from
the
hey.
Does
that
source
go
through
two-person
review
and
some
of
the
other
requirements
that
we
had,
because
we
wanted
to
separate
those
two
things,
because
one
is
absolutely
like.
E
If
you
know
how
do
you
have
providence,
if
you
don't
aren't
making
a
claim
about
provenance,
but
the
the
key
here
here,
I
think,
is
we
do
want
to
make
sure
that
the
key
piece
here
is:
is
that
provenance
piece
so
that
hey
yes,
this
source
got
pulled
in
in
this
way?
We
recorded
these
things.
This
was
the
output
which,
which
is
is
separate
than
the
the
some
of
the
other
things
like
the
source
levels,
which
we
do
want
to
include
at
some
point,
which
is
yes,
it's
stored.
E
In
this
way
it
has
gone
through
two-person
code
review
and
that
kind
of
thing.
G
I
have
a
hard
time
just
detangling
those
two
truly.
I
do
because
I
know
there's
the
the
business
cadence
of
potentially
there's
a
break
in
the
middle
of
the
night.
Somebody
comes
in
and
makes
a
change
and
a
single
person
reviewer
until
the
next
morning,
where
somebody
then
follows
it
up
and
does
a
second
review
that
should
release
the
gates
to,
from
a
salsa
point
of
view,
that
this
has
now
reached
some
milestone,
because
it's
continuous.
G
B
G
For
the
next
two
weeks,
I'm
kind
of
stuck
with
the
the
charter
for
skit
trying
to
drive
that
to
completion.
So
I
would
hope
I
would
like
somebody
else
to
pick
this
up
if
they
could
just
I'm
willing
to
get
other
people
to
help
in
this
area.
But
I
think
we
kind
of
need
to
backfill
and
settle
on
what
we
want
here.
C
A
A
G
I
definitely
don't
want
to
kick
things
out
because
it's
hard
for
some
tool
chain
to
reach
salsa
level.
Four.
That
would
be
the
wrong
decision
if
we're
based
on
what
we
think
is
necessary
from
a
security
providence
point
of
view,
then
I'm
that's
a
different,
but
if
it's
coming
back
to
hey
this
is
super
hard
for
xyz.
E
So
so
I
think
there's
also
I
just
want
to
kind
of.
I
guess
ask
a
question
here
right
because
so
far
I
think
the
majority
of
the
stuff
in
the
specification
has
mostly
been
focused
on
provenance
on
not
necessarily
making
claims
about
the
trustworthiness
of
actually
what
is
being
built
just
that
you
could
always
go
back
and
say.
Oh,
this
is
the
thing
I
installed.
I
go
back
eventually
to
the
claims.
E
I
go
back
to
these
things
and
I
see
that
oh
yes,
this
was
the
source
code,
was
bad
right
and
and
because,
when
I
look
through
the
the
levels
here,
I'm
seeing
stuff
like
level
one
is
hey.
If
you're
not
recording
elements
of
your
build,
how
do
you
know
what
build
even
started?
This
level?
Two
is
saying:
let
me
start
associating
identities
with
those
that
those
attestations
that
I'm
signing
right
so
now
I
can
actually
know
at
some
level
I
can
go
back
to
hey.
E
I
know
that
this
build
service
is
the
thing
that
built
it
and
then
salsa
3
provides
some
non-falsifiability
elements
which
is
like
hey
you're,
using
single
use,
certificates,
keys,
etc.
To
do
the
signing
so
now
it's
not
just
that.
E
It's
not
just
the
identity
of
the
build
service,
but
a
build
service
at
a
particular
time
with
these
particular
parameters
is
the
thing
that
actually
built
the
thing,
and
it's
also
for
that
sort
of
additional
level
on
top,
which
is
now
that
you're
doing
it
potentially,
let's
say
reproducibly
or
hermetically,
you
have
significantly
more
guarantees,
and
I
think
none
of
those
things
really
talk
to
the
actual
underlying
security
of
the
the
actual
code.
E
G
G
D
G
E
So
it's
still
the
same
route
of
trust,
just
to
be
clear.
It's
just
that
the
actual
signing,
like
the
thing
that's
being
used
to
do
the
signing.
So
if
I
were
to
go
in
and
I
have
a
malicious
build
and
I
copy
that
signing
secret,
somehow
external-
I
can't
actually
use
it.
It's
not
valuable
if
I
have
a
static
certificate,
great
yeah.
G
Now
you
know
you're
getting
into
a
whole
bunch
of
security
stuff.
I
I
don't
want
us
to
get
hung
up
on.
Hey
single
sign.
Use
certificates
are
much
better
than
multi-use
certificates,
because
now
I
can
start
bringing
in
tpms
and
atsms
and
a
whole
bunch
of
other
stuff
and
it's
you've
lost
at
this
point
right.
That's
not
a
claim.
That's.
B
G
E
B
There's
yeah
I
mean
there's,
there's
different
ways
to
achieve
that:
right:
okay,
but
we've
agreed.
I
guess
we'll
table
this.
One.
G
Back
back
to
the
original
claim
right,
I
can
compromise
the
tools
I
can
compromise
the
os.
I
can
compromise
the
source
code,
so
all
three
of
those
are
important
as
inputs
into
this
process.
Right
now
we
don't
have
a
solution
for
other
than
the
oss
components
that
are
coming
in
and
being
listed
in
the
the
s-bomb.
A
B
B
B
It,
oh
sure,
that's,
I
believe,
that's
the
goal.
B
I,
and
I
should
say
I'm
not
aware
of
like
any
fundamental
inconsistencies
that
would
prevent
us
from
achieving
that
goal,
but
I
will
admit
that
I
work
purely
in
the
open
source
space,
so
I
probably
don't
have
the
the
breadth
of
experience
that
others
do
so.
We
should
definitely
figure
out
a
way
to
model
this
and
explore
it
somewhere
to
make
sure
that
we
are
covering
a
lot
of
bases
here.
B
Okay,
that
was
so
what's
the
best
way
to
move
forward
on
that
discussion
and
modeling.
G
G
B
Did
you
say,
did
I
I'm
not
sure
if
I
interpret
you
correctly,
but
did
you
say
there's
already
some
documents
around
the
interoperability
risk.
G
There
was
a
discussion
on
how
to
distribute
salsa
that
was
created
last
friday.
Let
me
go
see
if
I
can
find.
B
Okay
was
this
in
the
description,
the
salsa
tools.
B
So,
let's
yeah,
let's
try
and
take
this
offline
and
find
some
stakeholders
who
can
drive
this
forward
unless
there
are
any
volunteers
on
the
call
who
want
to
put
a
hand
up
and
have
their
name
written
down
next
to
it.
Right
now,.
B
B
There's
sort
of
three
interrelated
pieces,
I
think
one
is
how
salsa
can
be
applied
to
a
model
where
you
have
some
open
source
components
and
some
proprietary
components
does
the
the
source
code
leveling,
which
roy
is
asserting
links
to
that.
Specifically,
I
think
royal
correct
me
if
I'm
wrong
and
then
this
is
how
this
all
interoperates
with
skit,
which
is
supply.
C
Yes,
the
the
first
one
about
open
source
versus
you
know.
Private
I
mean
I
can
take
that
that's
what
I
was
trying
to
convey,
but
I
didn't
finish
all
the
diagrams
and
I
think
that
helps
maybe
with
the
source
code
leveling.
If
I
understand
that
right,
I
think
that's
just
what
are
the
requirements
for
source
versus
build?
Is
that
what
it
is.
C
G
G
C
D
So,
just
to
clarify
on
the
sourcing
levels,
could
we
give
an
example
what
you
mean
on
sourcing
levels?
Just
so
I
can
understand
it.
I
mean
I
definitely
want
to
help
somewhere
and
drive
some
of
this,
but.
G
And
you
call
somebody
in
at
two
o'clock
in
the
morning:
does
he
still
have
to
have
the
two-person
code
reviewer,
or
does
he
get
by
with
one
and
we
produce
the
bits
of
backside,
but
you're
stopped
from
deploying
it
or
testing
it
until
somebody
comes
in
the
next
morning
and
applies
to
second
review
like
how
does
that
flow
right?
It
isn't
that
everything
is
is
met
before
we
start
the
build.
It
may
be
that
we
end
up
having
to
recover
a
build
and
continue
on
and
for
most
and
most
projects.
The
build
is
so
short.
G
This
really
doesn't
matter,
but
for
something
like
the
office
in
visual
studio
in
windows,
those
can
be
multi-hours
and
hours
and
hours
of
build.
G
B
Yeah,
I
I'm
we
have
six
minutes,
so
I
don't
think
we're
gonna
be
able
to
dig
into
this,
but
I'm
definitely
interested
to
dig
into
that,
because
I,
as
I
understood
the
solar
winds
attack,
it
was
that
some
like
it
wasn't,
the
the
source
control
system
was
tampered
with.
It's
that
file
was
copied
in
by
a
compromised,
build
tool
right.
B
G
The
file
revert
the
file
when
it
was
built
exited,
so
there
was
no
trace
from
the
source
control
system
point
of
view.
On
the
other
hand,
that's
where
the
build
providence
saying
hey
nobody
mucked
with
the
box,
or
we
have
hashes
of
files
and
so
forth,
but
that
doesn't
preclude
the
hey.
I
compromised
your
source
control
on
entry
or
on
the
wire.
So
when
you
pull
the
specific
file
in
that
it
didn't
get
tainted
at
that
point
like
how
do
you
validate
it
back
to
to
source
control?
To
say
this?
G
B
Yeah,
so
I
don't
disagree
that
yeah,
I
think
the
source
requirements
are
definitely
an
area
that
we
need
to
develop
and.
B
B
The
current
salsa
requirements
do
bind
or
do
model
that,
like
source
code
to
what
was
built,
mapping
and
they're
they're,
intended
to
prevent
the
solarwinds
style
attack
amongst
others,
which
is
why
I
was
curious
about
that.
B
Yeah,
I
I
I
don't
know
any
git
bomb
experts,
but
if
you
do.
B
B
Mike
lieberman,
did
we
cover
your?
I
think
we
covered
your
conformance
topic
right.
E
Yeah,
so
so
so
we
did
it's
just
something
to
kind
of
keep
in
mind,
as
we
begin
to
build.
This
out
is
also
like
hey
how
do
folks
sort
of
a
test
or
not
a
test?
That's
an
overloaded
term.
How
do
they
sort
of
say?
Yes,
we
are
doing
these
things
like
we
hope
we
have
a
salsa
builder,
that
is
this
and
and
make
that
you
know
public.
In
fact,
it's
actually
something
that
got
sent
to
the
the
mailing
list
is
somebody's
asking
like
hey,
we
believe
to
be
salsa
4.
E
We
want
to
make
sure
that
you
know
what
requirements
do
we
need
to
do
before
we
can.
You
know
publicly
claim
we're
salsa
4.
B
Good
thanks:
okay.
B
So
yeah
just
to
look
back
trying
to
desperately
trying
to
close
out
something
evidence
of
security
claims
we
had.
I
think
I
heard
mel
we
heard
melba's
clarifications.
Emmy
did
you
have
anything
you
wanted
to
discuss
on
the
evidence
of
security
claims,
peace.
A
B
I'd
like
to
understand
the
reservation,
if
we
can
address
them
and
move
this
one
forward,
I
see
you've
left
a
comment
in
the
talk,
so
I'll
try
and
follow
up
on
that
this
week,
and
hopefully
you
can
figure
that
out.
B
Okay,
cool
well
thanks
everyone
for
the
time
it
was
a
lot
luckier
than
I
was
expecting
and
we
shall
reconvene
in
is
it
three
weeks?
I
think
it
is
try
and
follow
up
offline
on
some
of
these
things,
especially
source
code
leveling,
and
the
evidence
of
claims.