►
From YouTube: SLSA Specifications Meeting (November 14, 2022)
Description
Meeting notes: https://docs.google.com/document/d/1kMP62o3KI0IqjPRSNtUqADodBqpEL_wlL1PEOsl6u20/edit#heading=h.yfiy9b23vayj
B
A
D
A
A
Yeah
and
for
my
camera
I
did
the
amazing,
unplug
and
re-plug
it
back
in
that
should
have
no
useful
effect,
but.
B
A
E
If
anyone
has
topics,
please
add
them
to
the
agenda
which
I
just
sent
in
the
via
the
chat.
E
E
Okay,
I
think:
let's
get
started
again,
please
add
more
agenda
items.
If
you
have
anything
reminder
to.
Please
remember
that
we're
by
participating
our
body
by
the
Linux
Foundation
code
of
conduct
and
the
register,
your
attendance
on
the
shared
meeting
notes.
Sean:
do
you
want
to
go
up
first.
D
Yeah
sure
so
I
was
looking
through
the
specs
for
bundles
again
the
other
day
and
then
noticed
that
there
isn't
there,
whilst
each
of
the
attestations
themselves
have
a
signature
in
the
bundle
and
the
bundle
itself
doesn't
have.
A
signature
and
I
didn't
really
get
the
explanation
for
not
needing
one,
because
it
seems
to
me
that
if
you
know,
if
you're,
if
you
try
to
treat
the
bundle
incorrectly
as
it
may
seem
as
a
kind
of
bill
of
materials,
not
necessarily
you
know
in
s-bombers
as
the
way
we
all
know
it.
D
It
seems
to
me
that
a
malicious
actor
could
hide
malicious
binaries
in
the
software
stack
and
just
remove
the
attestation
for,
for
the
general
genuine
version
that
they've
that
they've
added
and
I
didn't
see
where
to
see
quite
how
the
monotonic
principle
protected.
You
from
that.
D
So
I
just
wondered
whether
the
group
had
any
had
any
thoughts
on
that
or
whether
we
should
be
specifying
that
bundles
also
have
an
envelope
with
a
signature.
Wow.
E
Yeah
I
was
going
to
say
the
monotonic
principle,
so
the
so
first
I
guess
we
didn't
Define
it
because
we
didn't
have
a
concrete
use
case
for
it
yet
and
we're
considering
each
as
a
station
as
like
an
independent
thing
and
like
maybe
you
could
use
tough
or
something,
and
so
like.
E
We
basically
didn't
want
to
kind
of
go
into
a
space
where
there's
already
like
Solutions,
just
as
a
history,
I
I've
been
thinking
that
the
that
attestations
should
be
like
the
monotonic
principle,
meaning
like
deleting
an
attestation
should
never
go
from
something
being
bad
to
good.
E
So
something
like
the
fact
that
a
piece
of
software
has
a
vulnerability.
That
would
not
be
a
very
good
attestation,
because
if
you
deleted
that
now
it
goes
from
bad
to
good
and
that
you
could
phrase
it
a
different
way
or,
alternatively,
not
store
that
as
at
the
stations
that
store
it
as
something
else
like
a
database.
E
But
it
sounds
like
that.
It
didn't
wasn't
solved
in
the
use
case.
So
I'd
like
to
hear
more
about
like
why
that
doesn't
work.
D
I
think
it's
just
I
mean
salsa
doesn't
really
say
much
about
the
relationship
between
artifacts.
Apart
from
saying
that
you
know
potentially
listing
a
flat
list
of
dependencies,
but
even
then
it
only
lists.
You
know
the
attestation
only
lists
the
the
checksums
for
those
it
doesn't
actually
point
you
off
to
any
attestations
for
so,
if
you're
actually
trying
to
graph
graph
walk
and
discover
attestations
for
everything.
D
We
would
create
a
bundle
that
contained
the
attestations
for
everything
in
that
chain,
and
then
we
could
present
that
to
the
user
and
the
user
could
have
that
as
a
convenient
way
to
check
that
you
know
the
entire
stack
that
they've
been
given
for
that
artifact
is,
is
in
fact
verified,
but
it
seems
to
me,
like
you
can't
do
that,
because
somebody
could
say:
okay
well,
I've
got
a
dependency
here,
but
what
I
want
to
do?
You
know
it's
also
three.
D
Have
that
contribute
code
to
the
final
artifact
and
just
remove
its
attestation
from
the
bundle
and
naive
systems
that
don't
double
check
that
the
Manifest
of
things
that
have
been
shipped
and
the
attestations.
But
it's
also
level
three
you'd
never
know.
D
Were
there
any
contributed.
Coders
come
from
something
malicious.
Unless
you
also
had
access
stations
for
all
of
those
things
and
so
yeah,
you
could
potentially
just
remove
an
attestation
and
a
naive
system
that
didn't
double
check,
that
there
was
an
attestation
for
every
artifact
and
knew
every
artifact
that
was
involved
in
that
Journey.
D
F
Yeah
yeah:
this
is
something
that
we've
been
also
poking
around
with
with
guac
and
some
of
the
other
things
I
think
it
kind
of
goes
beyond
salsa,
but
I
think
it's
something
that
salsa
needs
to
consider.
Giving
that
I.
Think
salsa
is
one
of
the
the
few
that's
really
sort
of
driving
the
charge
in
the
right
ways.
So
I
I
do
think.
F
That's
something
that
needs
to
be
considered
like
one
of
the
things
that
we've
been
doing
is
we've
been
sort
of
relying
on
whether
it's
stuff
like
policy
to
sort
of
manage
some
of
that,
so
that,
like
anything,
I
download,
must
match
a
certain
policy,
and
so,
if
you
deleted
something
from
a
bundle,
hey,
that's
great!
It
no
longer
matches
the
policy
in
some
way
because
it
expects
a
thing.
So
that's
one
thing
we've
been
doing
and
then
separately.
F
We
also
looking
at
stuff,
like
you
know,
working
with
the
in
Toto
folks
on
in
Toto
layouts,
to
maybe
make
that
a
little
bit
you
know
saying,
like
hey
I
expect
this
change.
So
if
I
don't
see
this
chain-
and
once
again
this
is
kind
of
a
little
beyond
the
scope
of
salsa,
but
I
think
the
one
thing
that
I
think
is
really
important.
F
F
We
anticipate
like
we
expect
pot
like
the
same
thing
with
the
monotonic
principle,
like
we
expect
positive
assertions,
so
it's
like
at
this
time.
I
checked
this
thing
and
found
no
vulnerabilities
like
that
over
a
lack
of
an
attestation,
meaning
it's
good.
So
as
long
as
you
have
like
a
Time
stamped
attestation
that
says,
I
didn't
find
anything
at
this
time.
Then
that's
you
know.
So
that's
another
thing
we've
been
doing
and
but
I
think
there's
a
lot
more.
That
needs
to
get
done
there.
D
Yeah
I
mean
I,
think
it's
it's
also
level
three
at
least
you
won't
necessarily
know
the
chain
of
all
of
the
artifacts
that
actually
led
to
the
artifact
that
you've
been
given,
because
you
don't
have
to
it's,
you
don't
have
to
be
dependencies
complete
for
for
level
three,
so
I,
just
wonder
how
you
would
do
the
checks
and
balances.
That
would
say
similar,
wins
didn't
happen
to
me,
because
I've
got
these
attestations.
E
I
guess
it
my
I'm,
not
100,
confident
my
inclination
would
be
that
signing
the
bundle
would
not
be
what
that
wouldn't
be.
My
first
choice
for
the
solution.
E
Would
be
that
perhaps
you
could
make
a
different
attestation
that
says
like
this
is
the
chain
of
things
and
sign
that,
but
it's
yeah,
that's
that's
the
way.
The
way
I
would
lean
toward
is
like
keep
it
it's
kind
of
a
nice
property.
Each
station
itself
is
signed
separately.
You
could
also
list
the
hash
of
one
in
another
and
you
could
kind
of
change.
D
I
think
what
you're
saying
is
you're
advocating
for
a
separate
kind
of
signed,
manifest
for
a
software
stack
rather
than
having
that
having
the
bundles
of
that
purpose.
D
So
I
can
take
that.
That's
yeah,
that's
fine
it
just.
It
was
just
one
use
case
we
had
for,
but
we
thought
we
could
use
for
bundles,
but
it
seems
like
it's
it's
it's
not
quite
suitable
for
that
use
case.
B
E
That
sounds
good
okay,
so
I
I
talked
last
time
about
the
the
build
model.
I
didn't
make
as
much
progress
as
I
I
want.
I
have
a
bunch
of
in-plate
stuff.
That's
not
really
ready
to
publish
it,
but
one
thing:
I
wanted
to
quickly
share
just
to
get
some
initial
feedback
before
I
spend
more
time
on.
It
is.
E
E
It
would
be
good
but
I
that
we
I'm
trying
to
figure
out
a
way
that
we
could
use
terminology
and
a
diagram
that
makes
it
clear
to
what
we're
trying
to
express
so
that
way,
people
read
it
and
just
get
it
and
don't
have
to
like
read
the
Nuance
of
it
and
read
a
bunch
of
documentation
that,
like
you
just
see
some
picture
and
like
you
could
infer
all
of
the
things
correctly.
E
This
is
too
busy.
I
could
already.
E
Too
busy,
but
the
thinking
was
that,
like
there's
some
external
parameters
that
themselves,
some
of
them
refer
to
artifacts
like
the
parameter
is
like,
let's
say:
I
get
repo
URL,
the
actual
artifact
is
some
external
thing
or
like,
for
example,
and
that
gets
part
of
the
build
definition
also
originally
before
I
called
this
like
in
this
box
on
the
left
like
initialization
or
something.
E
Basically,
it's
all
the
things
to
kick
off
the
build
there'd
also
be
some
sort
of
system
inputs
that
are
I,
guess
not
really
part
of
the
things
that
the
bill
depends
on,
but
not
external
parameters,
for
example
like
when
you
run
on
GitHub
actions.
E
The
specific
version
of
the
I'm,
not
sure
if
that
would
be
a
dependency
or
not,
but
like
like
the
build
environment,
would
provide
things
that
is
not
being
explicitly
dependent
on,
but
it's
kind
of
implicitly
dependent
on
and
for
reproducibility
you'd
need
that,
but
is
not
an
external
thing
and
so
from
a
threat
model.
It's
not
like
it's
like
a
different
trust
domain.
I
don't
anyway,
this
again.
This
is
all
very
handy,
wavy
and
I.
E
Don't
it's
work
in
progress,
so
people
have
thoughts,
and
so
that's
what
kicks
off
the
build
when
the
build
is
running
it
can
fetch
other
dependencies
and
hope
I'm.
Just
hoping
this
kind
of
diagram
would
show
that,
like
there's
top
level,
yes
and
then
other
dependencies
kind
of
recurs,
you
know
there's
like
some
tree
of
dependencies.
E
The
environment
also
can
talk
to
the
build
platform.
This
is
something
that's
come
up
before
in
terms
of
the
Hermetic
requirement
of
like
there's
going
to
be
some
internal
traffic,
but
it's
like
maybe
not
part
of
the
the
main
definition
of
the
build
and
like
user
visible,
and
then
it
outputs
some
artifacts.
So
I
guess
I'll
stop
there
and
wanted
to
see
if
this
type
of
thing
either
resonated
or
didn't,
and
it's
like
confusing
or
positive
or
negative
feedback.
A
Yeah
I
I
I
think
it
is
rather
complicated.
I
mean
I,
I
suspect
a
lot
of
people
when
they
first
see
these
things
or
where's
the
source.
E
Yeah
also
I
didn't
I
specifically
didn't
put
Source,
because
that
itself
has
been
confusion
of
like
what
is
source
and
what's
not,
and
so
I
thought
well,
if
we
just
don't
if
we
don't
special
case
it
like,
why
do
we
need
to
special
case
it?
And
it's
really
just
yeah
I.
F
Don't
know
yeah
yeah,
so
a
couple
of
things
that
have
come
up
and
some
folks
have
been
pinging
me
about
just
sort
of
more
generally
and
is
around
this
sort
of
problem
of
and
this
kind
of
goes
beyond.
Once
again,
it
goes
beyond
salsa
and
I.
Think,
but
I
do
think
that
salsa
kind
of
has
a
way
of
helping
Drive
the
change
and
lead
the
charge.
F
F
That's
one
thing,
but
the
other
thing
I
think
that
is
being
brought
up
and
just
something
that
we
need
to
be
aware
of,
and
we
need
to
probably
make
sure
that
we
stay
in
sync
with
other
folks
is
like,
for
example,
the
s-bomb
folks
are
starting
to
build
out
whether
it's
build
info
right
within
spdx
or
I.
F
Think
cyclic
DX
is
calling
it
formulation
or
something
like
that,
but
they're
both
kind
of
coming
at
it
in
a
similar
way
of
saying,
hey,
we
take
in
some
sort
of
inputs
that
come
from
the
build
platform,
some
sort
of
inputs
that
come
from
the
build
itself
and
so
on
and
so
forth,
and
then
we
build
a
thing
and
that's
kind
of
where,
where
they're
coming
at
it
from
and
I
think,
one
thing
that
I
just
want
to
make
sure
of
is
like.
F
We
don't
necessarily
need
to
be
in
lockstep
with
everything
that
other
folks
are
doing,
but
it
would
be
nice
to
make
sure
that
we're
not
completely
doing
something.
You
know
completely
different
and
especially
since
I
think
we're
we
could
lead
the
charge
on.
This
is
like
we
can
say
hey.
This
is
how
we're
doing
it.
If
other
folks
who
are
debating
this
want
us,
you
know,
look
at
what
we're
doing.
Here's
where
it
is.
A
F
Agreed
I,
I,
I,
I,
yeah
I
was
just
about
to
say:
yeah
I
agree
with
you,
but
Josh
just
just.
A
Yeah
I
mean
yes
for
once
I
I'm,
fully
admitting
that
that
I
may
be
dreaming,
but
I
think
the
spdx
folks
have
worked
on
this
for
some
time.
Haven't
they.
E
Yeah
and
in
fact,
I've
been
attending
the
build
meetings.
It's
actually
a
little
bit
circular,
because
they've
been
using
the
salsa
definition.
No.
E
E
Is
it's
not
specific
enough
that
for
s-bomb
it
is
like
it
does
not
cover
all
it's
not
as
strong
and
strict
of
a
build
model,
because
they're
not
worried
about
the
integrity
and
tampering
piece
and
so
like
for
they're,
mostly
worried
about
vulnerability
management
and
so
or
like
hand,
analysis
or
something
where
it's
just
human
readable
and
a
human
can
understand
it,
and
so
that
that,
like
lack
of
rigor
or
Precision,
just
hasn't
been
a
problem
so
far,
I
think,
and
so
that's
where
I've
been
kind
of
struggling
a
little
bit.
E
E
Ideally,
we'd
align
between
Cyclone,
DX
and
spdx
and
and
salsa,
and
just
have
like
the
same
model.
Ideally
the
same
terms.
A
Yeah
I'm
wondering
if
maybe
you
can
use
the
higher
level
terms
and
then
break
it
out
for
the
refer
for
refinement.
So,
like
you
know,
your
diagram
could
even
have
a
more
a
looser,
but
then
say:
hey,
like
you
know
these
artifacts
divide
into
several
things
or
like
you
might
not
need
to
expressly
note
the
parameters.
You
can
just
say
that
top
level
of
artifacts
come
in,
that
artifacts
come
in
and
some
that
are
defined
by
parameters
and
some
of
them
are
discovered
during
the
build
process.
H
Yeah,
so
you
know
it
may
just
be
because
I
am
still
too
new
here
to
know
what's
behind
those,
but
actually
I,
I
kind
of
like
your
diagram
and
I
had
no
problem
interpreting
the
top
part.
The
green
part
is
less
clear
to
me,
especially
the
relationship
between
system
inputs
and
build
platform
and
the
environment.
It
seems
to
be
too
many
arrows
there.
So
maybe
again,
I
mean
I'm,
just
lacking
and
clear
understanding
of
what's
behind
those
boxes
exactly,
but
the
system
inputs
is
especially
the
part.
That's
a
bit
mysterious
to
me.
I.
E
And
I
don't
know
yeah
I'm
trying
to
figure
out
how
to
simplify
it.
The
so
I
could
explain
what
my
thinking
was,
and
maybe
that
can
spur
you
to
like
come
up
with.
Oh,
you
can
simplify
this
bike
that
these
that's.
Why
I
originally
had
like
those
gray
boxes,
but
I
think
just
the
gray
boxes.
That
kind
of
are
in
these
arrows
just
added
too
much
noise
that
these
two
things
are
effectively
parameters
to
kick
off
the
build
like
it
is
the
small
like
the
minimal
set
of
information.
E
You
need
to
kick
off
the
build
the
parameters
coming
from
an
external
source
and
system
inputs
and
like
this
is
what
we
were
kind
of
worried
about
in
the
threat
model
like
this
is
what
external
attackers
can
control.
These
are
things
that
only
like
an
Insider
within
the
build
platform
can
control
or
like,
and
so
they
would
be
needed
to
say
for
reproducibility,
but
would
not
be
like.
E
Because
they're
not
as
big
of
a
risk
there
again,
this
is
all
the
thinking.
Not
necessarily.
This
is
correct.
This
build
versus
environment
I
did
that,
because
that
was
in
our
current
diagram.
Where
is
it
here?
Let
me
present
it
in
this
tab.
That
was
here.
E
Maybe
we
just
split
it,
and
we
also
talk
about
like
an
ephemeral
environment
that,
like
you,
it
creates
something.
If
that's
too
confusing,
we
could
just
split
it
off
and
just
you
know,
delete
that
and
make
one
big
thing
like
that.
A
H
E
They
clarify
it,
then
you
mean
you
mean,
like
terminology
wise,
like.
H
A
A
A
E
Yeah
I
think
maybe
probably
keep
this,
because,
like
this
is
in
in
practice
in
most
systems
would
be
some
sort
of
orchestrator
again
using
GitHub
actions
as
like
our
default
build
system.
E
This
would
be
like
effectively
this
thing.
This
box
here
is
the
VM
where
it
runs,
and
this
would
be
the
communication
like
the
control
plane.
A
If,
if
you
want
to
play
games
on
simplifying
how
it
looks,
you
can
turn
the
two-way
arrows
into
a
single
double
double
error.
You
know
air
on
each
end,
I
I
know
yeah,
I
know,
there's
a
name
for
it.
I
can't
remember
what
it
is.
I
mean
it
does.
It
doesn't
change
what
you're
showing
so.
H
H
H
E
To
visualize
it
because,
like
ideally
there'd
be-
and
you
know,
part
of
this
came
up
because
Sean
previously
had
talked
about
like
trust,
domains
or
trust
boundaries
and
I
was
trying
to
like
visualize
that,
like
there's
some
things
coming
from
the
outside
and
some
things
coming
from
internal
and
I,
don't
like
just
having
the
word
trusted
or
not:
I,
don't
love
it.
E
Since
I
was
trying
to
visualize
it,
but
I
couldn't
figure
out
how
to
like
visualize
like
a
boundary,
because,
like
there's
kind
of
like
this
is
a
VM
here,
and
this
is
the
build
platform.
I
don't
know,
but
maybe
this
is
the
best
result.
A
I
I
I
but
I
think
you're
you're.
Basically
right,
though
Let
Me
Pitch
for
what
you
wrote,
you
know
you
are
trusting
the
the
environment
parameters
more
or
less,
certainly
more
than
the
external
parameters,
whereas
if
the
I
mean
in
some
sense
you
are
trusting
the
external
parameters,
because
you
think
that
that's
going
to
help
you
build
something,
but
you
are
trusting
them
a
lot.
Less
all
right:
environmental
parameters,
Fair.
E
The
other
thing
I
was
thinking
was
like
I,
there's
kind
of
a
circular
definition
of
what
is
trust.
What
does
trusted
mean
and
I
I
would
yeah
and
that.
A
Yeah
that
one,
certainly
that
eliminates
the
the
trust
concern.
E
Yeah,
okay,
all
right
I,
don't
want
to
take
too
much
time.
This
was
super
helpful
thanks
for
the
the
feedback.
I
will
continue
iterating
on
this
in
the
whatever
pull
request,
it
is
I
can't
find
it
right
this
second
on
the
provenance
1.0,
the
draft
pull
request.
B
E
When
redesigning
it,
to
simplify.
E
A
Yeah,
so
this
is
not
really
I'm,
not
sure
I
have
a
strong
position
really
other
than
the
obvious
one
of
we'll
have
to
resolve
this,
which
I,
don't
think
is
really
in
doubt,
but
I
I
think
this
is.
This
is
going
to
be
a
little
complicated,
I!
Don't!
But
you
know
this,
you
know
how
strong
is
your
guarantee
required
for
isolated
and
femoral
environments?
A
It's
also
three
and
I
guess
the
the
main
thing
I
was
worried
about
and
I
I
reread
pull
request
that
321
and
it
looks
like
it
wasn't
as
concerned,
as
was
but
I
to
me.
It
needs
to
be
possible
to
automate
and
I,
don't
think.
That's
really
In
Contention
at
first
I
was
afraid
that
we
were
gonna.
Go
down
that
path,
so
I
see
there's
a
pull
request
proposed,
but
I
just
this
needs
resolution
and
I
think
this
looks
this
is
this
seems
complicated.
The
more
I
think
about
it.
E
E
I
think
the
best
I
was
thinking
that
we
could
do
would
be
foreign
for
the
requirements
that
the
build
system
like
by
default
doesn't
listen
to
external
influence
and
if
the
user's
script
or
configuration
ends
up
doing
that
like
we
could,
there
could
be
clear
instruction
not
to
do
that,
but
I
I
think
there's
no
way
that
we
could
really
guarantee
that
unless
we
had
like
a
higher
salsa
level.
A
Yeah
and
and
good
luck
on
some
of
these
systems,
I
mean
there
are
so
many
systems
where
you
know
Step
One
is
curl
bar
sh.
So
and
you
know,
if
you
don't
do
that,
you
have
no
tools.
So
it's
challenging
no
I'm
not
encouraging
this
by
the
way,
just
observing
reality.
F
Yeah
so
I
do
think,
like
there
probably
is
a
lot
of
fire
art
on
this.
That
I
think
we
can
kind
of
draw
from
whether
it's
how
bazel
does
or
basil
basil
does
this
in
similar
sort
of
build
systems,
as
well
as
like
Nick's
Nick's,
how
they
sort
of
do
isolated,
ephemeral,
sandboxed,
hermetic,
Etc,
I.
Think
there's
a
lot
of
like
interesting
literature
out
there
on
kind
of
like
that
hierarchy
of
like
this
is
isolated,
but
not
ephemeral.
This
is
ephemeral
but
not
isolated.
F
E
Foreign
in
terms
of
the
pull
request,
Aaron's
pull
request,
I
any
thoughts
on
that
has
anyone
else
reviewed
it.
The
basic
idea
is
to
merge
isolated
ephemeral
because
they're
really
describing
the
same
thing,
which
is
that,
like
there's
one
build,
can't
influence
another
build.
D
A
D
E
One
thing
I've
been
thinking
about
would
would
be
to
kind
of
go
a
step
further
than
this
pull
request,
and
let
me
see
if
I
could
share
my
draft.
A
C
Is
more
recommendation
rather
than
a
can't.
A
E
Ignore
all
the
other
text
it's
solved
computer
but
like
I,
was
thinking
of
simplifying
the
the
level
structure.
E
So,
instead
of
having
like
a
bunch
of
check
boxes,
basically
I
think
if
we
think
about
the
build
levels,
they
boil
down
to
two
things:
one
is
guarantees
about
the
province
level,
one
just
that
it
exists
at
all
level,
two
that
we
have
authentication
and
some
sort
of
I'm,
not
sure
that
word
is
perfect
there
and
three
that
it's
like
nonforgeable
and
we
could
Define
what
those
mean
and
then,
similarly,
the
strength
of
isolation
between
builds
level.
One
there's
no
guarantee
at
all
level,
two
merely.
E
Just
it's
hosted
on
some
service.
We
have
to
figure
out
how
that
plays
into
reproducible
builds,
but
that's
separate
and
then
three
that
it's
this
would
be
the
isolated
and
ephemeral
environment.
E
Think
maybe
we
could
think
of
the
build
levels
and
you
know
strategies
or
on
those
they're,
not
really
orthogonal
axes
but
they're
they're
related.
But
in.
B
E
E
E
I
think
it
would
be
that's
a
good
question,
maybe
something
around
dependencies
like
it's
not
unforgeable,
and
you
know
dependencies
complete
or
complete,
or
something
like
that.
I
don't
know
if
there's
anything
about
isolation,
strength
as
well,
like
maybe
full
again,
I,
don't
think
these
label
I,
don't
like
these
labels
just
to
be
clear,
I
think
I
need
better
labels,
but
yeah
and
I
think
this
is
extending
the
idea
of
what
Aaron
there
and
anyway,
okay
I
think
Marcelo
was
first.
J
Yeah
I
guess
I
just
wanted
to
actually
overall
I
I
think
the
structure
will
make
it
easier
for
people
to
understand
the
different
levels.
What
you're
trying
to
accomplish,
but
I,
also
like
second
or
third,
the
fact
that
hosted
and
fully
isolated,
especially
I,
don't
know
what
that
means.
Just
looking
at
those
and
especially
yeah
I
think
the
distinction
between
fully
isolated
and
then
hermetic
is
really
unclear.
J
If
that's
what
we're
trying
to
sort
of
distinguish
the
team,
L3
and
all
four
I,
don't
exactly
know
what
we
mean
by
authenticated
versus
non-forgeable,
but
yeah
I.
Think
I'm,
just
like
echoing
the
terminology,
questions.
C
I
was
just
gonna
say
not
as
not
as
much
detail
but
more
like
a
marketing
kind
of
attack
of
this
I,
like
that.
It's
simplified
right
because
it's
a
lot
easier
to
consume.
However,
from
a
from
a
first
look
at
it
all
the
check
boxes
made,
it
look
really
cool.
C
D
Yeah
so
I
I,
like
I,
like
the
that
yeah
I,
agree
with
Aaron
I,
like
the
the
kind
of
check
boxes,
that
kind
of
approach
and
I
think
for
what
that
leave
for
L4
is
you
know
your
Providence
guarantees
are
complete
as
well
at
L4
and
your
isolation.
Strict,
then,
is
when
we
fall
down
on
on
hermetic,
as
as
that,
but
I
think
we
do
need
some
yeah
strong,
complete
definitions
of
what
we
mean
by
isolated
and
hermetic,
and
what
the
difference
between
them
is.
D
Yeah
I
get
you
know,
I
think
the
difference
between
the
potentially
between
authenticated
and
non-foldable
is
it
authenticated.
Is
you
can
tell
that
the
provenance
came
from
where
it
came
from
and
unfortunately
you
can
also
tell
that
the
content
hasn't
been
tampered
with,
whether
there's
a
technical
distinction
depending
on
the
implementation
or
not
I,
don't
know,
but
you
could
look
at
it
that
way.
K
I
think
I
have
to
disagree
a
bit
with
Aaron
and
Sean
I
kind
of
I
I
get
the
appeal
of
the
checkbox
visual,
but
I
also
think
that
not
making
I
worry
that
it's
made
it
look
too
easy,
like
you,
can
just
check
a
few
boxes
and
you've
achieved
things,
whereas
it
actually
records
the
requirements
actually
require
you
to
think
at
a
much
deeper
level
than
a
lot
of
first-time
readers
realize
because
of
things
like
the
isolated
and
hermetic
requirements
that
the
terminology
is
so
confusing
around.
K
So
I
do
like
the
direction
of
the
visual
you've
come
up
with
Mark,
even
if
we
have
to
do
a
round
of
back
and
forth
on
the
specific
terms,
I.
Also
like
last
week,
and
this
week,
there
we
have
been
starting,
it
feels
like
we've
been
starting
to
Trend
towards.
Maybe
hermetic
is
an
L3
requirement
and
not
an
L4
requirement
and
I'm
I
just
wanted
to
raise
that
as
a
point
of
discussion.
Maybe.
K
C
E
That
was
nudging
all
my
intention,
so
if
anything
is
trending
that
direction,
then
let's
call
that
out.
I
I
was
not
trying
to
actually
change
any
of
the
requirements,
but
just
change
how
we
let.
D
Lay
them
on
a
pretty
practical
level.
I
think
there
are
steps
that
need
to
be
taken
to
get
to
a
fully
hermetic,
build
that
I'm,
not
that
are
more
difficult
to
get
to
than
a
slightly
more
watered-down
Definition
of
isolated.
D
There
are
some
processes
that
still
a
better
or
worse,
require
some
sort
of
network
access
to
do
things
like
getting
a
lot
of
time.
Steps
and
things
like
that
and
I
think
you
know
eliminating
those
is
is
a
is
a
fantastic
goal,
but
it's
it's
not
entirely
practical
right
now,.
H
K
B
K
K
So,
oh
no
does
that
address
your
yeah.
H
K
H
H
A
A
E
Yeah
I
I
think
that's,
let's
consider
that.
My
only
worry
is
that
if
we
call
Something
level
four
there,
then
it's
just
going
to
be
set
in
stone,
it'll
be
really
hard
to
change
and.
A
Here's
a
weird
idea:
Mark:
can
we
agree
on
a
definition
of
hermetic
I
think
we
can
and
then
we
can
Define
the
other
term
as
in
the
definition
that
say
Hey.
It
has
to
do
this
note
that
it
is
not
necessarily
hermetic
see
her
medic
include
a
definition.
Now
it's
not
in
the
table,
but
at
least
we've
stuck
a
flag
in
the
work
for
the
word.
Hermetic.
B
L
Yeah,
the
only
just
just
I'm
sorry
I'm,
trying
to
just
listen
for
walks,
I'm
kind
of
new
to
the
Google
and
see
where
things
are
going,
but
just
in
my
own
past
experience,
dealing
with
audit
audited
and
audible
environments
is
is
I.
Think
there
might
be
concern
out
there.
People
saying
well,
three
may
not
be
the
level
I
need
to
be
at
for
the
industry.
L
I
need
to
be
at
four
and
there's
a
confusion
that
whenever
a
couple
people
say
that
three
is
not
the
a
bad
thing,
but
externally
I
think
the
view
is,
if
I'm,
not
a
four
I'm
not
going
to
be
salsa,
should
we
even
pursue
it
or
not?
It's
like
an
All
or
Nothing
Viewpoint
like
if
you're
looking
at
if
you're
a
PCI,
Compliant,
you're,
the
compliant
or
not
and
I.
Think
that's
just
one
concern.
I
have
I
just
want
to
raise
it
and
see
what
people
thought.
H
So
I
may
have
a
solution.
At
least
I
have
a
suggestion
which
may
address
the
problem.
Maybe
we
just
need
to
this
was
not
required
for
L3,
so
we
don't
have
to
call
it
L4
or
anything
like
this.
We
just
list
the
kind
of
things
that
are
not
required
for
L
4
by
3.
H
F
To
David's
point,
though,
I
think
there's
also
yeah.
They
like
one
of
the
stances
I
know
we
took
fairly
early
on,
was
to
try
and
not
get
into
the
hey
when
when
somebody
decides
to
require
salsa
conformance
as
as
a
requirement
for
some
sort
of
compliance
reason,
we
still
want
to
allow
whatever
that
might
be
like
whatever
you
know.
If
folks
are
going
to
say,
hey,
we
require
salsa,
three
or
salsa
4.
F
For
you
know
up
and
down
the
chain,
that's
fine,
there's
going
to
be
some
standards
body
or
whatever
that
that
might
say
that.
That's
that's
the
requirement,
but
this
group
is
trying
not
to
take
like
a
hard
stance
on
you
know
on
that.
Given
that
different
use
cases
and
different,
you
know,
organizations
are
going
to
have
different
requirements
and
you
know
I'm
not
going
to
be
salsa
for
for
my
my
personal
blog,
but
if
I'm
working
on
you
know,
transaction
software
for
a
bank
I
might
want
to
be
salsa
for.
E
Yeah
that
sounds
good.
Okay,
I
want
to
make
sure
we
only
have
10
minutes,
I,
don't
know
if
that's
enough
time
for
Josh,
but
let's
I
think
if,
if
we're
okay
with
that,
let's
have
time
for
that.
I
will
try
to
incorporate
this
feedback
and
I'll
send
out
two
pull
requests
whenever
I
clean
them
up
right
now,
they're
a
big
mess
on
the
for
the
the
Providence.
E
Well,
I'll
update
the
problem,
existing
Port
request
for
the
provenance
diagram,
and
then
this
one
on
like
the
restructuring
of
the
the
table.
So
we
could
try
to
figure
out
what
what
makes
sense
there.
E
M
Yes,
so
I
kind
of
wanted
to
I
know
we
discussed
it
a
little
bit
ago
in
a
larger
salsa
meeting,
but
it's
kind
of
been
and
I've
been
fairly
busy
for
the
past
couple
weeks.
I
haven't
really
been
able
to
come
and
attend
and
and
bring
it
up
again,
but
I
wanted
to
discuss
a
little
bit
more
on
the
conformance
program,
because
I
know
as
we're
building
our
requirements.
M
M
I
know
it
was
discussed
that
was
kind
of
the
biggest
point
of
discussion
around
it
when
it
first
came
up
is,
is
what
exactly
do
we
want
to
prove
conforms
to
salsa
and
so
kind
of
my
my
first
first
thought,
and
something
I've
been
mulling
over,
is,
is
kind
of
in
the
spirit
of
developing
and
kind
of
a
minimal
viable
product.
M
For
this
to
to
see
what
works
would
be
to
initially
Target
build
systems,
for
a
set
of
you
know,
features
that
they
can
provide,
so
that
users
will
be
able
to
know
if
they
go
and
select
a
build
system
that
they're
able
to
meet
their
salsa
goals
for
their
software
as
they
as
they
build
their
software.
They
want
to
hit
salsa
level
four.
Well,
they
got
to
select
a
build
system
that
provides
salsa
level
four,
a
functionality
or
or
is,
can
attest
to
to
that
accurately.
M
So
I
was
hoping
that
we
could
kind
of
discuss
that
scope
item
here
in
this
meeting
and
kind
of
figure
out
if
we're
aligned
on
what
we
want,
the
scope
to
be
so
that
we
can
kind
of
identify
the
subset
of
requirements
that
apply
in
particular
to
build
systems,
and
so
that
we
can
then
Define
exactly
what
a
questionnaire
might
look
like
and
and
start
refining
those
items.
So
we
can
get
started
testing
and
then
obviously
we'll
have
to
work
on.
Well,
what
does
branding
look
like?
M
G
Yeah
no
I
think
that's
a
great
point
to
start
with,
and
I'm
kind
of
looking
at
some
of
the
examples
of
what
people
are
claiming
are
are
salsa
compliant
and
then
the
one
one
I
do
want
to
make
sure
we
cover
is
things
like
the
the
kubernetes
release
process.
G
Those
folks
are
working
through
kind
of
salsa
compliance
and
I
shared
a
link
to
the
spreadsheet
they're
checking
things
off,
but
I
think
definitely
having
a
way
for
open
source
projects
and
their
build
slash.
Release
process
to
be
like
deemed
salsa
compliant
will
be
a
key
one.
G
E
Yeah
I
think
starting
with
build
system,
sounds
good
to
me.
I
I.
Think
that's
to
me.
That's
like
the
bulk
of
what
I
was
thinking,
maybe
expand
the
future,
but
like
not
just
start
with
build
system,
but
I
feel
like
that
is
at
least
for
the
first
version.
E
Limiting
this
scope
to
that
is
probably
good
in
my
mind,
okay
and
then,
and
then,
if
we
I
feel
like,
we
should
develop
that
in
conjunction
with
the
requirements
where
we
say
like
this
is
how
you
assess
that
and
a
link
to
the
guidelines
of
like
well,
here's
how
you
do
it
in
the
assessment
and
like
the
property
that
you
check.
E
So
that
way
you
could
map
directly
from,
like
the
I'll
use.
The
term
hosted
the
current
crappy
term
that
we
just
discussed
in
previous
section,
and
you
could
link
that
to
like
well
here
in
the
assessment,
like
here's,
the
properties
that
you
check,
and
this
is
what
we're
expecting.
This
is
what
we're
not
expecting
at
this
level
like
kind
of
guidelines,
I
think
that'd
be
good.
M
Yeah,
okay,
yeah
I,
like
that,
having
a
you
know,
each
each
kind
of
question
in
the
questionnaire
would
would
kind
of
maybe
map
to
one
or
more
different
of
the
requirements
and
that
we
could
you
know
and
then
they
could
say.
Yes,
we
checked
that
property
of
our
build
system
and
we
think
it
complies
with
this
or
here's
why
we
think
it.
You
know
it
doesn't
maybe
match
the
letter
of
the
law,
but
here's
why
we
think
it
does
and
here's
our
explanation
Etc.
M
J
I
think
it
was
Luke.
Okay,.
B
I
Just
talking
away
on
me,
sorry,
yes,
it's
probably
quite
a
rudimentary
question
just
to
get
me
up
to
speed.
So
is
this
something
that
a
community
would
self-certified,
they
would
sort
of
take
themselves
through
the
process
or
would
that
be
an
Arbiter?
Is
it
like
a
badging
program.
M
Yeah,
so
the
their
the
idea.
The
initial
idea
is
that
we
have
kind
of
two
levels.
One
is
a
self-certification
level
and
the
other
one
is
a.
Is
a
third
party
assessed
level,
but
obviously
you
know
taken
one
thing
at
a
time
well
figuring
out,
who
is
able
to
who
is
able
to
assess
projects
to
salsa?
That's
a
whole
other
discussion
that
we'll
have
to
figure
out
like
which,
which
audit
companies
are
are
approved
to
do
Audits
and
et
cetera,
et
cetera
right.
M
So
the
kind
of
the
first
step,
we're
thinking,
is
a
self-assessment
that
will
be
clearly
marked,
as
this
is
self-certified
and
they
get
to
use
the
self-certified
badge.
So
they
don't
get
the
this
has
been
third
party
audited,
Etc
badge
or
or
something
like
that,
but
kind
of
First
Step
would
be
self-certification
anyway,
kind
of
in
line
with
what,
with
what
some
other
organizations
do
like
what?
What
is
the
program
yeah
yeah
kind
of
similar
to
to
to
that
world?
M
But
you
can
look
more
at
the
dock
attached
to
the
GitHub
issue
and
it
kind
of
go
over
goes
over
the
idea
of
the
two
levels
and
kind
of
how
that
would
work
and
and
what
you
would
get
for
self-certifying.
What
versus
what
you
would
get
for
going.
Full
third
party
audit
but
kind
of
right
now
we're
just
thinking
about
targeting
that
first
self-certification
level.
J
I
wanted
to
want
any
case,
a
discussion
that
I,
Chris
and
I
have
been
having
has
been
around
evidence
for
self-certification
or
not,
and
so
I
just
kind
of
wanted
to
bring
it
back
to
that
aspect
as
well,
that
you
know
whether
or
not
evidence
is
required
or
recommended
for
whatever
else
you
want
to
sort
of
specify
should
be
part
of
the
conformance
questions
as
well.
I
think
so.
J
A
Yeah
I
realize
we're
almost
at
that
time.
If
two
real
quick
points-
one-
hopefully
it's
obvious,
but
just
a
footstep
because,
like
you,
know
the
the
levels
it
doesn't
matter,
if
it's
self-cert
or
third
party,
the
requirements
are
the
same.
All
you're
asking
is
how
much
evidence
and
verification
of
these
there
are
and
Trace
Miranda
noted.
You
know
public
sharing,
how
they
believe
the
requirements.
I
think
that
does
at
least
partially
help
some
of
the
known
challenges
of
self-cert
I
would
expect.
A
M
Yeah
that
makes
total
sense,
yeah
I
think
the
the
I.
The
idea
is
is
that
you
know
if
you,
if
you
get,
if
you
do
a
self-cert,
it
would
be
like
some
a
lot
of
these
other
programs.
They
require
an
upload
of
your
questionnaire
document,
like
that.
You
filled
out
for
your
company
to
be
applied
to
a
public
registry
of
some
sort.
So
there
the
idea
could
be
like
you
know
every
you
know
different
build
systems
if
they
want
to.
M
A
And
I'm
leading
the
best
practices
badge
and
although
it's
mostly
self-cert,
we
actually
do
detect
cases
and
we
reject
answers.
We
can
determine
our
folds.
So
if
you
make
a
claim-
and
we
can
tell
it's
false-
it
actually
doesn't
matter,
we
will
reject
and
reject
the
claim.
So
it's
you
know
you
can
sometimes
you
know,
detect
certain
configurations
that
you
know
either
will
or
won't
meet
certain
criteria.
M
M
M
A
B
E
We're
out
of
time,
thank
you,
everyone,
this
I,
think
was
very
productive
and
we'll
talk
to
you
next
time.