►
From YouTube: SLSA Meeting (July 25, 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).
A
B
A
A
A
A
A
I
think
that's
like
most
of
the
folks
thanks
joshua,
for
for
linking
to
the
meeting
notes.
A
So
I
think
what.
A
Why
don't
we?
Maybe
I
thought
maybe
we
could
talk
about
like
priorities
for
the
the
group?
Well,
I
don't
know
who's
writing.
That
special
interest
group
is
what
we're
supposed
to
call
ourselves.
B
Yeah
brian
is
pushing
back
on
task
force,
which
was
recommended
by
arnold,
and
so
he's
saying
it's
a
special
interest
group.
So
just.
A
Okay,
I
like
that
better
than
task
force
or
work
stream
for
for
what
it's
worth
all
right,
so
we
can
make
that
change
in
the
the
official
thing.
That's
great
thanks,
and
so
I
think
I
guess
I'm
gonna
say
special
interest
for
brian,
that's
great,
so
I
think
the
so
for
the
priorities
of
this
sig.
A
A
There's
also
some
discussion,
like
we
had
at
the
community
meeting
around
aligning
with
s-bomb,
either
from
like
a
requirements
perspective
or
from
a
format
perspective
like
sp,
like
spx,
for
example,
and
so
I
know
there's
the
the
other
sig
is
looking
at
that
too,
and
so
I
think
maybe
we
could
just
leave
that
discussion
to
to
to
them,
and
then
you
know
eventually
like
meet
me
back.
A
A
I
think
there's
been
some
desire
express
to
just
call
it
1.0
because,
like
if
we
just
keep
having
zero
dot
releases
forever,
it
doesn't
seem
like
it's
stable
in
the
roadmap.
We'd
also
propose
like
basically
not
changing
it
too
much
for
this
next
release
of
like
not
just
like
throwing
everything
out
and
starting
from
scratch.
I
don't
think
that
is
a
hard
requirement.
I
think,
if
there's
other
opinions,
I
think
we
should
discuss
that.
I
and
then
so
like.
A
If
we
get
agreement
on
what
we
overall
want
to
do
with
the
1.0
like,
if
we
could
figure
out
like
what
things
are
we
going
to
tackle,
what
are
we
going
to
defer
and
not
tackle
and
what
are
our
priorities?
I
I'd
be
I'd,
be
happy
with
that
and
then,
in
terms
of
the
actual,
like
the
wording
of
the
specification,
I
think
we
could
do
like
in
like
docs
or
pull
requests,
or
something
like
that.
A
I'm
in
in
these
meetings
I'm
more
worried
about
getting
kind
of
all
an
agreement
of
like
here's
kind
of
what
we
want
the
thing
to
look
like
and
then
like
hammer
out
the
details
like
the
later
melba
asked
about
solidifying
one
point
one
and
two
yeah.
That's,
I
think
that's
an
that's
an
open
question,
if,
like
in
my
opinion,.
A
The
levels
one
two
and
three
are
pretty
solid
in
my
mind,
of
like
I
kind
of
have
an
idea
of
what
the
benefits
are,
which
we
could
talk
about.
The
four
seems
up
in
the
air.
It
kind
of
has
these
two
requirements
of
hermeticity
and
two-party
review,
both
of
them
people
find
difficult
for
different
reasons,
exactly
why
we're
doing
is
unclear,
and
so,
if
you
think
like
we
should,
I
don't
know
like
just
define
one
two
and
three
and
then
like
pause
for
four.
I
don't
know
melba.
B
Yeah,
I
think
it's
it's
more
of
the
clarification
right.
I've
seen
in
the
regular
salsa
meetings,
people
aren't
sure
about
the
definitions
and
how
they're
written,
and
so,
if
we
can
make
sure
that
there's
no
ambiguity
in
the
definitions
in
the
requirements,
for
you
know
one
and
two.
Then
we
can
focus
on
three
and
then
we
can
focus
on
four,
because
people
are
still
having
a
lot
of
questions
even
on
one
and
two,
so
that
that
that
was
my
point
in
trying
to
tackle
one
and
two.
D
Yeah
yeah,
I
was
just
going
to
say
I
I
agree
with
the
melbourne
on
that
one
that,
like
even
just
like
a
couple
of
the
common
terms
like
you
know,
fermenticity
reproducibility,
if
we
just
kind
of
like
very
clearly
state
what
that
means,
and
also
I
think
one
of
the
big
ones
is
like
the
reasoning
why,
behind
it
it
it
sorts
out
a
lot
of
stuff
and
so
that,
if
we
then
because,
I
think
like
if
we
just
kind
of
even
start
saying
hey,
how
do
we
do
this
purely
for
you
know
the
next
level.
D
What
what
I
think
we
already
start,
what
we're
already
starting
to
see
is
like
some
folks
being
like
wait.
I
still
don't
even
know
why
it
was
originally
stated
that
way.
A
C
Yeah,
I
think,
I'd
I'd
answer
that
as
well.
I
think
there's
definitely
scope
for
us
keeping
the
wording
in
the
core
requirements,
succinct,
but
I
think
there's
definitely
some
some
educational
and
clarification
clarifying
work
to
be
done
around
some
of
those
things
that
exist
only
about
four.
I
would
also
just
like
to
say,
I'm
also,
plus
one
or
one
going
for
1.0,
rather
than
another,
zero
dot
release,
because
I
think
it
it
kind
of
adds
nothing
else,
an
area
of
stability
that
people
can
aim
at
and
say.
C
A
Sounds
good
okay,
so
I
have
a
1.0
proposal,
doc
that
doesn't
necessarily
talk
even
about
the
specific
changes
but
kind
of
like
that,
isn't
like
a
meta
document
of
like
how
we
do
versioning
etc.
Before
we
go
into
that,
I
just
want
to
clarify
just
like
the
collaboration
model
for
the
census,
their
first
meeting
as
a
group,
or
maybe
should
we
talk
about
the
end
after
we
see
what
we
actually
get
done
in
the
next
45
minutes?
What
do
you
think
is
it?
Would
that
be
a
better
model?
E
Yeah
make
sure
we
take
at
least
10
minutes
for
it,
but
I
think
since
yeah.
A
All
right,
so,
let's
see
how
this
goes
right
now
and
then
yeah
all
right,
so
we'll
leave
everyone
just
try
to
be
cognizant
around
like
about
half
in
about
40
minutes,
we'll
we'll
leave
time
for
like
how
do
we
continue
the
conversation,
so
I
I
have
this
doc.
I
put
together
just
to
get
something
started,
I'm
not
claiming
that
anything
here
is
correct
or
good.
Just
I
wanted
to
try
to
accelerate
it.
A
I
the
I
could
I'll
if
it
would
be
helpful,
I'll,
try
to
just
run
through
the
main
concepts,
and
then
we
could
maybe
figure
out
what
would
be
valuable
to
talk
about
now.
Let
me
present,
so
you
could
see
what
I'm
looking
at.
Actually,
let
me
move
that
out
to
another
window.
A
Okay
and
then
you
can
still
hear
me,
yes,
okay,
I
don't
have
a
problem
like
last
time,
where
I
muted
myself
by
mistake.
A
So
I
we
could
I'm
just
going
to
skip
the
maybe
the
problem
statement
for
now.
That's
something
I
think
we
could
collaboratively
come
up
with,
but
the
the
main
topics
that
I
think
that
we
need
that.
At
least
that
I
thought
about
that.
We
want
to
tackle
the
hard
problems
for
1.0
are
versioning
like
how
do
we
version
specification
while
keeping
existing
references
unambiguous.
A
So,
for
example,
if
someone
says
like
sousa,
for
example,
they
presented
last
week,
they
said
we
are
salsa
for
and
here's
all
the
reasons.
If
we
then
change
what
salsa
form
means
all
those
old
references
to
the
level
are
like
ambiguous
and
so
it
it
becomes
confusing
both
like
in
writing
and
in
conversation
to
have.
A
Like
the
levels
float
over
time
for
what
it's
worth
here
at
google
we've
had
we
have
these
notions
these
levels,
we
we
call
it
something
different
and
like
them,
it's
basically
the
same
as
salsa
levels,
but
there's
some
slight
differences
and
we've
gone
over
this
too
and
there's
some
amount
of
value
and
we
have
found
in
our
organization
there's
some
value
value
of
having
like
mind
share
around
like
this
is
what
salsa
3
means
and
people
over
the
years
kind
of
grow
to
know
what
that
means,
and
so,
if
we
keep
shifting
it,
that's
kind
of
that's
something,
that's
undesirable,
that
I
think
we
should
figure
out.
A
So
there's
like
you
know
one
thing
I
anyway,
so
I
guess
we
could
go
into
the
details
for
each
of
them.
But
let
me
just
kind
of
talk
about
the
the
major
topics.
Another
is
around
the
common
requirements
and
evidence
of
security
claims
right
now
in
the
in
the
spec.
We
have
these
like
common
requirements
at
the
bottom
around
like
it
needs
to
be
secure.
A
Somehow
and
like
we
don't
even
say
exactly
what
that
means,
all
access
should
be
rare
logged
and
have
multi-party
approval
and
the
number
of
people
that
could
kind
of
override
the
other
guarantees
around
like
forging
provenance
or
tampering
with
it
has
to
be
a
small
number
of
people,
and
it
requires
a
two-party
review
to
do
that
again,
trying
to
think
of
like
an
organization
I'm
coming
at
it
from
a
large
organization
like
google,
where
we,
where
we
say
you
know,
there's
not
it's
not
just
like
any
engineer,
is
responsible
for
their
own
key
management
or
something
we
say
well
of
the
whole
huge
company.
A
First,
I
imagine
that
is
still
valuable
for
like
medium-sized
companies
as
you
get
smaller,
I
don't
know
how
valuable
it
is
and
for
open
source.
I'm
I'm
not
sure
how
well
that
works
either,
but
but
otherwise,
like
these,
these
requirements
kind
of
are
ill-specified
and
they're,
also
not
sufficient,
because
they
don't.
If
someone
says
they
do
this,
the
immediate
question
is
like
how,
and
so
one
idea
is
to
kind
of
refocus
instead
of
having
like
a
checkbox
list
of
things,
to
do
focus
on.
A
A
How
does
your
system
designed
to
guarantee
adherence
to
these
requirements
like
how
are
the
builds
isolated
and
we
could
even
have
some
sort
of
template
or
something
that
goes
into
like
specific
things
you
have
to
address
like
how
are
they
isolated
from
like
one
workload
influencing
the
next
that
runs
on
the
same
machine?
How
are
they
in
lockdown,
so
the
control
plane
can't
be
influenced
blah
blah
blah?
How
do
admins?
A
How
can
they
make
like
system
administrator?
What,
if
someone
has
physical
access?
How
do
they
do
that?
And
in
this
way
we
could
have
like
different
people,
like
kind
of
because
we
don't
have
any
formal
authority
on
what
salsa
is
right,
and
so
this
at
least
different
consumers
can
kind
of
make
a
decision
of
like
do.
I
trust
this
or
not
sean.
C
Yeah,
I
think,
with
those
security
requirements
at
the
end,
I
think,
what's
what
makes
that
more
difficult,
I
think,
is
the
fact
that
it
blows
up
the
scope
of
what
it
is.
An
auditor
might
want
to
do
if
they
were
providing
a
certification
because
suddenly
you're
into
the
kind
of
the
realms
of
sock,
2
and
you
know
other
organizational
parts,
and
so
you
know
an
audit
against
that
is
going
to
be
a
much
larger
scope
than
auditing.
C
You
know
a
build
system
and
a
software
supply
chain,
so
I
think
initially
I'd
I'd
like
to
kind
of,
especially
while
these
are
very
very
hand.
Wavy
try
to
keep
these
out
of
scope
for
1.0,
and
you
know,
okay,
we
want
these
things
and
we
want
to
be
able
to
back
them
up
with
evidence,
but
until
we
have
one
a
better
definition
of
what
it
is
and
two
we
can
define
a
scope
for
what
an
audit
would
look
like
for
this
sort
of
thing.
B
Yeah,
I
just
wanted
to
add
that
I
think
if
media
is
to
not
necessarily
lock
anyone
down
into
this
is
how
you
have
to
provide
isolation.
It
might
still
be
good
to
provide.
I
mean.
B
Maybe
this
is
already
part
of
it,
some
examples
as
to
how
you
know
what
types
of
mechanisms
or
techniques
might
help
you
qualify
to
reach
that
if
that
makes
sense,
and
so
that
way,
developers
use
it
trying
to
yeah
trying
to
reach
salsa
level,
whatever
can
actually
sort
of
have
at
least
a
vague
notion
of
how
they
might
go
about
doing
that.
A
D
And
to
simplify
yeah
to
simplify
some
of
this,
it
might
be
worthwhile
to
just
look
at
some
of
the
various
like
community
best
practices
around
some
of
these
things
and
just
see
if
we
can
like
specify.
You
know
cite
that
as
like:
hey
here's,
a
way
of
doing
that,
you
know
because
there
are
like
a
lot
of
standards
around
stuff
like
key
management
and
whatever
already
so.
It
might
just
be
useful
to
sort
of.
D
Like
cite
one
of
those
and
necessarily
like
you
know,
it's
probably
still
worthwhile
right
to
talk
about
a
few
examples,
but
I
think
if
we
can
sort
of
cite
what
a
lot
of
folks
have
already
done,
it
might
just
make
our
lives
a
little
bit
simpler.
A
A
A
How
can
someone
like
verify
that
like?
How
do
we
stop
like
that
from
happening?
I
don't
have
any
particularly
good
ideas
here.
There
was
some
notion
of,
like
maybe
there's
like
a
public
comment
form
where
people
can
like
say
hey.
I
don't
believe
that
I
don't
know
how
how
much
I
like
that
or
not
I
another
thought
was
like
if
we
phrase
requirements
in
the
forms
of
attacks,
it
must
prevent
and
we
have
some
sort
of
oracle
that,
like
people
could
post
and
say
hey.
A
I
pulled
off
this
attack
like
you're,
not
supposed
to.
If
you
use
I'll
use,
github
actions,
because
we
we
have
that
project
you're
not
supposed
to
be
able
to
fake
the
github
actions
provenance.
But
if
someone
says
hey,
I
faked
the
github
actions
providence,
like
I
generated
prominence
that
claims
this
particular
commit
made
this
output
when
it
when
it
didn't
that
that
could
be
some
way
of
kind
of
bolstering
arguments.
D
Oh
no
yeah,
I
raised
it
again.
Yeah
I
mean
I
think,
along
those
lines
it
you
know
one
of
the
things
that
a
lot
of
folks
have
been
chatting
about
in
the
community
is
like.
Could
you
create
somebody
who
could
like
you
know,
essentially
a
certifier
right,
and
so,
if
a
third
third-party
auditor,
let's
say
or
whatever
comes
in
and
certifies
that,
yes,
you
know,
we
checked
the
provenance.
We
also
checked
some
of
the
other
stuff
to
make
sure
that
that
providence
couldn't
be.
D
You
know,
you
know
that
they're
doing
all
the
right
things
where
their
key
can't
be
used
to
sign
other
things.
Whatever.
I
think
that's
one
of
the
things
that
I
know
a
lot
of
folks
are
starting
to
ask
about,
is,
could
you
could
you
have
a
third
party
auditor
and
then
I
think
you
have
it
sort
of
okay,
maybe
yeah.
So
one
of
the
other
ones
was
also
just
just
generally
like.
D
If,
let's
say
a
somebody,
you
trust
is
making
that
claim.
You
might
just
sort
of
trust
that
they
are.
You
know
reasonable
about
it
like
if
a
large
company,
like
a
google,
an
ibm,
a
microsoft,
makes
a
giant
claim.
You
are
probably
going
to
trust
them
a
little
bit
more
than
you
know,
let's
say
a
an
open
source
project
with
like
two
maintainers,
and
you
know
that
sort
of
thing.
B
Support
exactly
that
right
through,
like
any
third
party,
could
produce
a
vsa
for
an
artifact,
which
you
know
is
essentially
that
auditing
function
like
if
I'm
trainer
bits
or
or
some
third-party
organization.
I
could
take
a
given
artifact
with
a
salsa
attestation
from
its
producer
and
then
create
a
vsa
testing
to
yeah
I've
audited
this,
and
I'm
going
to
put
my
signature
on
the
fact
that
I
think
that
this
thing
is
also
level
three,
and
so
we
have
the
mechanisms
for
for
that
function
in
the
existing
specification
and
mdsa
definition.
E
Like
I
don't
know,
red
hat
coming
in
and
saying
yeah
we've
taken
a
close
enough
look
at.
A
Yeah
yeah,
but
yeah,
I
think
I
think
both
of
you
are,
I
think,
there's
certainly
room
for
for
third-party
auditors
on
third.
A
B
Yeah,
I
was
going
to
say
I
I
like
that.
There's
room
for
third
party
auditors
and
I
would
also
like
to
be
room.
You
know
I
think
it's
implied
but
for
you
know
self
self-certification
claims
too
for
a
project
that
doesn't
want
to
do
that.
They
can
simply
say.
Yes,
we
acknowledge,
we
didn't
have
a
third
party,
but
you
know
to
the
best
of
our
judgment.
B
We
followed
these
if,
if
we
have
failed
to
because
we
made
a
mistake
or
misunderstanding,
please
don't
sue
us,
but
you
know
we
did
a
best,
diligent
effort.
I
think
that's
implied
right
now,
but
I
just
wanted
to
say
that
would
that
would
also
be
nice.
A
Yeah,
so
so
that's
where
that
fits
into
this
to
the
specification,
I
don't
know,
but
it's
something
I
think
that's
kind
of
been
coming
up.
That
would
be
nice
if
we
could
address
another
thing
that
I
would
like
to
consider
is:
oh
michael.
D
Oh
yeah
one
one
last
thing
just
I
mean
I
do
think
that
it's
it's
important,
maybe
to
to
really
to
be
clear.
D
I'm
sorry
if
I,
if
it's
in
the
dock,
I'm
on
my
phone
right
now,
but
one
thing
to
call
out:
there
is
sort
of
the
difference
between
yeah
like
the
builder
and
a
project
right,
you
know,
a
builder's
certification
doesn't
necessarily
mean
that
the
project
that's
doing
it,
is
still
applying
all
the
right
fools,
and,
and
vice
versa,
right,
like
a
builder,
could
be
potentially
not
salsa,
but
the
way
that
they're
using
the
the
builder
actually
does
make
it
salsa,
and
I
think,
when
we
build
out
some
of
these
requirements,
I
know
one
of
the
other
things
that
has
been
confusing
to
folks
is
like
wait.
B
I
think
related
to
this,
I'm
wondering
if
it
might
be
worth
actually,
this
might
complicate
things
a
lot,
but
it
might
be
worth
trying
to
capture
a
notion
of
reputation
also,
especially
if
we
have
third
party
auditors.
I
think
you
know
someone
like
someone
mentioned
red
hat
before
certifying
that
github
actions
is
compliant
to
a
certain
level,
is
very
different
than
me
just
randomly
saying
that
maybe
it's
just
up
to
the
verifier
to
decide
if
they
trust
the
statement
but
yeah.
That
was
just
kind
of
a
comment.
A
Yeah
sorry,
I'm
like
having
tab
juggling
challenges.
Oh
open
up
this
to
comment.
Okay,
anyone
with
the
link
should
be
able
to
comment.
Now.
I
think
if
you
reload
the
page,
you
should
be
able
to
comment
now.
If
you
have
problems,
let
me
know.
A
So
so
another
thing
I'd
like
to
consider
is
redefining
levels
as
kind
of
outcomes
as
opposed
to
requirements,
because,
right
now
it's
pretty
prescriptive
of
like
level.
One
means
you
do
a
and
b
level
two
means,
like
you
sign
the
thing
and
do
this
and
it's
less
clear
of
why
you're
doing
these
things
and
what
is
the
expected
outcome?
A
And
I
worry
a
bit
that
kind
of
you
check
the
boxes
without
actually
achieving
the
intended
results,
and
if
we
reframe
things
in
terms
of
like
level,
one
means
you
get
this
outcome,
and
here
is,
you
know,
kind
of
the
the
implications
of
you.
You're
gonna
have
to
do
this
in
practice.
A
You're
gonna
have
to
do
these
things
in
order
to
achieve
that
outcome,
I
think
that
might
be
a
better
way
to
phrase
it
like,
for
example,
like
level
one
like
the
basically
there's
just
the
provenance
exists
and
we
could
go
into
details
here.
A
I
don't
want
to
go
into
it
right
now,
level,
two,
maybe
something
around
like
the
adversary,
can't
tamper
with
the
artifact
after
the
build,
because
it's
signed
like
in
practice
because
it's
signed,
the
accuracy
of
the
provenance
is
tested
by
some
service
which
requires
a
deliberate
attack
to
attack
and
there
the
benefit
is
that,
like
you,.
A
It's
not
just
trivial
to
forge
provenance
and
that,
like
people
have
to
make
a
specific
action
and-
and
when
we
think
about
this,
like
within
a
large
organization,
there's
there's
benefits
to
that
right
of
like
it
stops
curious
employees.
It
stops
people
kind
of
like
don't
want
to
do
the
wrong
thing
and
not
willing
to
do
an
attack,
but
like
would
do
something
so
so
you
could
kind
of
explain
it
in
in
those
those
terms
and
like
level
three
would
be
like.
A
D
Yeah,
no,
I
definitely
think
it's
required
as
soon
as
possible.
Actually
just
because
I
know
like
one
of
the
comments
I've
heard
a
few
times
was
wait.
What
am
I
actually
getting
with
level
one?
This
doesn't
prevent
any
attacks,
and-
and
so,
if
somebody
says
their
level-
one
doesn't
really
matter,
and
I
think
like
what
you
mentioned,
there
is
like
a
is
a
you
know.
D
Oh
great,
that's
that's
a
problem
you
should
probably
be
holding
on
to
those
build
logs
associating
with
the
artifact
for
the
life
of
the
artifact
and
not
just
the
build
logs,
but
you
know
any
sort
of
metadata,
that's
associated
with
it,
and
you
know
here's
why
right
and-
and
I
think
it's
worthwhile
to
talk
about
it
in
like
sort
of
the
the
two
things
you
talked
about
right
was.
One
is
like
the
goal
of
like
hey.
D
What
is
this
generally
getting
us
and
two
is
maybe
like
some
specific
attacks,
because
one
of
the
things
that
I
know
people
keep
asking
is
like:
okay,
if
I'm
salsa
2
or
I'm
salsa
1
or
I'm
salsa
3.
What
attacks
does
this
actually
prevent
or
what
attack
should
this
prevent
or
mitigate
or
whatever?
And-
and
it's
currently
not
very
clear.
E
So
I'll
just
jump
in
and
say
I'm
really
torn
on
this
one.
On
the
one
hand,
I
really
like
the
articulation
of
the
outcome
on
the
flip
side.
I
worry
that
it
makes
it
much
in
some
ways
it
makes
it
harder
to
achieve,
because
we
don't
help
people
understand
in
as
much
detail
how
to
achieve.
E
Obviously,
that
will
depend
on
how
we
write
yeah,
what
what,
how
we
provide
the
guidance
effectively,
but
one
of
the
things
that
a
lot
of
people
have
liked
about
salsa
is
that
it
tries
to
provide
a
road
map
to
achieving
these
things,
and
if
we
focus
more
on
the
outcomes
and
less
on
how
to
achieve
them,
we
might
reduce
that
it
does
sidestep
a
lot
of
the
difficulties
in
interpreting
the
current
requirements.
A
Yeah,
just
I
guess
maybe
one
minute
comment
before
the
other
hand,
melva
mentioned
like
getting
time
to
review
the
doc
for
sure
I
I'm
my
point
in
going
through.
This
is
just
to
kind
of
give
an
overview
in
case
like
what
I
wrote
wasn't
very
clear.
I
tried
to
thought
I
think,
like
maybe
for
this
group,
since
it's
like
a
draft,
it
might
be
good
to
kind
of
give
a
sense
for
this.
I
I
don't
think
we're
intending
to
like
actually
decide
anything
right
right
now.
Anyway,
I
think
emmy
was
next.
B
So
your
question
about-
and
maybe
I
miss
the
provenance
or
the
the
purpose
behind,
maybe
we
should
say
like
what
do
the
different
levels?
What
are
you
gaining
by
achieving
the
different
levels
like
what
types
of
attacks
are
you
preventing
so
maybe
having
like
user
stories
for
each
level?
B
I'd
be
cautious
on
what
types
of
attacks
we're
preventing,
because
I
think
that's
a
call
to
a
challenge
to
certain
folks
in
the
hacking
industry.
So
maybe
maybe
not
like
hey.
You
won't
have
this
type
of
attack.
If
you
are
this
level
certified
because
there's
more
than
one
way
to
attack
supply
chains,
but
I
think
having
user
stories
of
like
who
might
be
targeting
level
one
as
an
organization.
So
like
you're,
a
small
company
starting
up,
you
have
your
first
product.
That's
going
out.
B
You
want
to
like
show
some
verifiable
security,
that's
being
done
in
your
supply
chain.
It
might
be
a
level
one
like
I'm,
not
at
red
hat
gonna
sit
there
and
say:
hey
guys,
look
at.
We
did
level
one
look
how
great
we
are
with
all
of
the
products
that
we
have
like.
If
you,
it
would
immediately
be
like
a
negative
pr
campaign,
so
maybe
some
user
stories
about
whom
might
target
the
different
levels,
but
also
for
customers.
A
B
Yeah
I
like
the
thrust
of
the
recent
comments.
It
makes
me
think
that,
instead
of
redefining
the
levels
as
outcomes
not
requirements,
a
solution
that
satisfies
the
zeitgeist
of
what's
in
here,
but
without
actually
redefining
the
levels,
is
to
have
exactly
like
what
was
just
described,
some
sort
of
additional
documentation,
user
user
stories
or
something
similar
where
it
explains
what
each
level
achieves.
But
it
doesn't
actually
require
redefining
each
level
you
know
as
specified.
C
Yeah
I
like
this
trust
too.
I
think
one
of
the
things
it
gives
us
is.
I
like
emmy's
idea
of
treating
it
as
stories,
because
one
of
the
things
that
you
put
on
stories
or
acceptance
criteria
which
could
make
this
something
that
it's
more
measurable,
at
least,
if
not
testable,
which
would
be
nice.
It's
actually.
C
Know?
Okay:
this
is
the
outcome
you
want
to
achieve
and
then
that
kind
of
leads
kind
of
neatly
into
a
way
to
at
least
verified
that
you've
you've
met
that
criteria.
It
also
opens
up
that
opens
up
the
thought
to
more
implementations
than
the
ones
that
you
know
sometimes
implied
by
the
more
prescriptive
text
in
the
how
to,
rather
than
what
to
approach
we
currently
have.
A
Yeah
I
yeah,
so
I
think
I
in
my
mind
I
was
thinking
there
would
still
be
two
documents.
One
is
like
the
levels
in
terms
of
outcomes,
and
one
is
like
the
kind
of
prescriptive
like
in
practice.
Here's
how
you
do
it,
I
think,
maybe
one
it
sounds
like
we're
all
in
agreement
that
both
of
those
documents
are
valuable.
Maybe
the
question
is
which
one
is
the
canonical
one
or
like
the
definitive
one
and
which
one
is
like
the
supplementary
doctor
normative.
I
guess
and
which
one
is
like
this.
A
A
Also
one
one
comment
of
like
cautious
on
what
types
of
attacks
are
preventing.
That's
a
very
good
thought.
I
had
been
thinking
of
this
from
the
build
system
perspective
of
like
if
I
am
foo
builder,
you
know
whatever
build
service.
If
I
claim
that
my
builder
level
three
me
from
like
a
security
engineering,
kind
of
point
of
view,
not
thinking
anything
or
legal
or
political
considerations,
it's
kind
of
nice
that,
like
people,
could
go
and
try
to
attack
it
and
prove
prove
that
company
wrong
right.
A
Like
hey,
I
could
post
this
thing
saying
but
yeah
I
hadn't
thought
of
it
from
like
the
I
am
a
user
of
that
system,
and
now
I'm
trying
to
invite
people
like
to
attack
myself
so
yeah,
that's
a
good
point.
John
is
you're
still
handsome
up,
or
do
you
want
six
months.
A
Okay,
so
I
think
that's
maybe
something
that
to
to
think
about
an
another
topic,
we're
almost
sort
of
towards
the
end,
the
other,
I
think
that's
the
last
two
main
major
topics,
I'll
just
briefly
mention,
because
we
don't
have
time
later,
like
there's
other
stuff
around
clarifications
in
the
model
and
getting
started
page.
That's
those
aren't
ion
views
like
the
high
level
thing.
A
Right
like
there
needs
to
be
something
checking
it
and
requiring
it
to
exist
in
order
for
it
to
have
any
value
well
in
order
for
to
prevent
the
attacks,
and
so
I
think
we
need
to
introduce
that
somehow
into
the
specification
for
what
it's
worth
originally.
A
In
an
earlier
draft,
we
had
to
find
the
levels
not
on
like
an
artifact
basis,
where
an
artifact
is
like
a
blob
of
data,
but
rather
on
a
resource
like
a
package
name
or
something
like
that
and
said
like
this
package.
Name
is
a
level
if
there
is
a
policy
associated
with
it
that
restricts
it
to
things
that
have
these
properties.
A
In
my
mind,
that
made
a
lot
of
sense
in
some
other
people's
minds
when
they
read
it.
They
were
confused
by
that,
and
so
we
we
change
it
to
the
current
version
but
mate,
but
the
current
version
makes
it
very
hard
to
talk
about
kind
of
like
policy
or
verification
or
like
gating
things,
because,
like
an
artifact's,
just
a
blob
of
data.
A
E
Try
and
clarify
whether
the
objection
to
package
names
was
the
the
fact
that
no
there's
no
consistency
in
how
packages
are
referred
to
across
kind
of
content
repositories.
In
the
episode
space,
like
the
name
of
a
github
repository,
doesn't
necessarily
map
to
what
the
things
published
as
and
that
may
not
map
to
what
it
becomes
when
it's
ingested
by
a
distribution
and
things
like
that.
A
No,
that
wasn't
the
objection
at
the
time.
I'm
not
saying
that's
not
a
concern,
but
rather
it
was
just
a
conceptual
simplicity.
I
think
the
some
of
the
early
reviewers,
actually,
I
think
one
person
in
particular
was
viewing
it.
I
think,
maybe
from
the
use
case
of
like
I
just
want
the
providence.
I
want
to
know
where
this
thing
came
from.
A
And
so
to
me
at
least
that
still
doesn't
quite
sit
right,
I
kind
of
come
from
the.
I
want
to
know
what
it
should
be
perspective,
so
if
anyone
here
has
ideas,
one
way
or
the
other
or
like
to
say
like
no,
the
current
one
is
good.
Adding
this
other
notion
makes
it
too
complex,
because
ultimately,
we
land
on
the
current
one,
because
it
was
easier
to
understand.
E
A
Technical
ways
that
we
could
get
there
so,
but
but
anyway,
figuring
out
how
to
get
some
notion
of
like
you
actually
have
to
verify
that
provenance.
A
In
order
to
get
these
benefits,
we
got
to
work
that
in
somehow
I
I
don't
know
how,
at
this
point
and
the
last
one
is,
I
think
the
most
controversial
which
I
had
suggested,
but
I
know
there's
strong
opinions
on
both
directions
and
I
personally
am
split
on
this.
Is
the
idea
to
potentially
drop
the
source
integrity
requirements
because,
right
now
in
the
requirements,
we
have
these
like
version
control,
which
is
kind
of
not
really
a
huge
deal,
but
the
verified
history
retained
indefinitely
and
two-person
reviewed.
A
In
other
words,
we
have
requirements
like
not
just
how
the
thing
is
built,
but
properties
of
the
source,
control
and
not
really
just
of
the
commit
the
like
the
artifact,
but
really
how
like
the
project
is
done
because
in
practice
you
can't
really
say
two-person
reviewed
and
every
single
commit
in
the
history
was
two-person
reviewed,
because
in
practice
every
project
has
at
least
some
unreviewed
commits,
and
it's
not
valuable
to
go
back
and
review
every
single
one.
A
A
B
A
Somehow
have
no
thoughts.
C
Yeah-
I
I
quite
I'm
in
favor
at
the
moment
of
kind
of
dropping
this
from
1.0
apart,
because
when
there
are
multiple
parties
in
the
chain
of
from
source
code
to
delivery,
you
know
if
we're
that,
if
we're
the
build
service
that
sits
in
the
middle
and
we
draw
our
source
of
github
and
we
publish
then
on
to
our
users
pretty
much
everything
is
going
to
come
out
so
level
one,
because
we
have
no
control
over
the
source
over
the
source
and
in
fact,
unless
you
are
github,
you
don't
necessarily
have
visibility
into
any
of
those
things
that
you
that
are
requirements.
C
So
you
can't
make
any
statement
on
their
behalf,
so
it
makes
it
very
difficult,
for
you
know
the
kind
of
intermediary
intermediaries
in
the
chain
to
actually
make
any
kind
of
statement
about.
What's
you
know
what
level
something
is
that
we
can
build
a
perfect
lip
saucer
level,
four
compliant
build
system,
but
don't
ever
produce
also
level
one
artifacts.
C
If
we,
you
know,
if
we
don't
have
visibility
to
the
control,
so
I
think
you
know
if
we
need
to
get
to
the
point
where
there's
a
there's,
a
large
number
of
open
source
projects
that
are
making
attestations
on
how
they
generate
their
source
releases
before
we
can
start
to
think
about
actually
producing
anything.
That's
also
level
four
with
multiple
intermediaries
in
the
chain.
C
E
I'm
I'm
really
told
on
this
one
because
I
know
like
most
open
source
projects
can't
meet
this
today,
but
I
don't
know
that
that's
I
yeah,
I'm
told.
Let
me
just
say
that
I
do
think
we've
almost
sized
up
this
problem
if
we
do
agree
to
focus
on
one
and
two
first
sales
levels,
one
and
two
for
the
v1
of
the
spec.
So
that
should
be
a
consideration,
and
I
think
the
discussion
here
even
has
highlighted
one
of
the
areas
of
clarity.
That's
required
in
that.
E
B
Oh
sure,
someone
might
have
already
said
it
in
this
particular
context,
but
someone
also
mentioned
earlier
distinguishing
between
the
builder
service
and
the
project
itself,
and
it
seems
like
right
now
we
might.
B
If
we
did,
I
should
say
I
also
don't
know
if
I
fall
on
one
side
or
the
other
yet,
but
if
we
do
keep
source
integrity,
that
seems
to
be
more
comment
about
the
project
than
the
actual
build
process,
and
so
yeah
I
mean
it
seems
like
we'd,
be
conflating
two
sort
of
different
certifications.
If
we
keep
them
together,
something
to
be
said
about
being
able
to
certify
each
separately
also,
but
yeah.
A
And
yeah,
if
I'm
taking
poor
note
too,
do
please.
B
C
D
So
yeah,
I
think
on,
I
don't
want
to
go
too
far
down
that
hole
again,
but,
but
I
do
kind
of
I
know
we
we've
kind
of
talked
a
lot
about
like
certifying
builders
versus
certifying
projects
and
knowing
what
the
responsibility
of
the
builder
versus
the
responsibility
of
the
project
is,
and
I
think
definitely
on
on
the
specification
point.
We
just
need
to
be
very
clear
and
it's
going
to
obviously
differ
for
different
organizations
right
like
an
organization
that
builds
all
of
a
lot
of
their
tools.
A
Is
is
to
come
up
with
some
concrete
options,
because
I
don't
think
there's
it
sounds
like
there's.
No,
there's
really
no
consensus
on
like
what's
the
best
path
forward.
Maybe
if
we
come
up
with
a
couple
like
options
of
like
well,
if
we
keep
it,
it
looks
like
this.
If
we
split
it
out,
it
looks
like
this,
and
maybe
if
we
had
like
actual
like
a
versus
b
to
look
at,
we
could
kind
of
look
versus
like
notionally.
A
C
Yes,
you
know,
I
think
this
also
speaks
to
the
transitive
source
of
properties
as
well
as
to
whether
or
not
you
know
something
that
you've
built
to
source
a
level
four
from
source
code.
That
you
didn't
trust
is
that
a
source
of
level,
four
artifact.
Do
you
treat
the
source
code
as
one
artifact
and
build
a
deliverable
as
another
artifact,
and
can
that
build
artifact
be
sourced
level?
Four,
if
you
have
no
real
information
on
the
source.
A
If
we
go
like
right
now,
I
think
the
transit
thing
is
is
in
this
weird
state,
where,
like
the
artifact,
the
level
of
an
artifact
depends
on
just
that
things
build
and
its
sources,
but
not
its
dependencies
like
if
you
just
made
it
of
the
artifact
independent
of
the
sources
and
in
dependencies
that
would
be
kind
of
philosophically
one
way
to
go
right
of
like
the
the
build
like
the,
for
example,
the
python
wheel,
which
is
a
binary
like
a
zip
file.
A
compiled
thing
has
a
level,
but
its
sources
is
like
completely
independent.
A
Like
a
git
repo.
From
like
a
technical
philosophical
perspective,
I
kind
of
like
that
when
talking
to
people,
I
think
everyone
finds
that
that
concept,
confusing
though,
although
you
know
then
like
the
level
could
be,
you
know,
you
could
define
the
level
of
a
source
as
like
a
different
ladder
right
of
like
if
it's
a
source,
here's
the
requirements.
If
it's
built
it's
these
requirements
or
you
could.
D
A
A
Also
on
the
notion
of
like
deferring
another
idea
I
had
in
the
doc
was
if
we
get
rid
of
the
retention
requirement
for
level
three
which
I'm
happy
to
talk
about,
but
I
think
we're
out
of
time
now
and
then
we
could
defer
level
four,
like
we
just
kind
of
undefined
level,
four
for
now,
which
I
think
has
other
some
problems
anyway.
So
we
define
what
one
two
and
three
mean
we
kind
of
define
vision
wise
of
like
here's,
other
properties,
we
think
we'll
care
about.
A
Two-Part
earview
hermetic
builds
whatever,
but
don't
give
them
a
label
quite
yet,
and
then
it'll
maybe
give
buy
us
some
time
to
define
like
what
is
the
next
rung
on
the
ladder
which
I
guess
effectively
agreeing
with
whoever
suggested
of
like
just
starting
with
one
and
two.
I
think
we
should
also
do
three
as
well,
but
starting
with
one
and
two
and
then
maybe
doing
three
and
then
and
figuring
out
that
that
sounds
good
to
me.
A
Okay,
so
we
are
almost
out
of
time.
A
What
do
you
think
would
be
a
good
path
forward
for
making
progress
here?
Should
we
yeah,
I
don't
know,
do
you
have
any
ideas?
Should
we
comment,
I
mean
you
could
comment
on
the
doc
if
you
think
the
doc
is
useful,
are
there
other
topics
that
we
want
to
address
in
1.0
that,
like
aren't
listed
there,
I
kind
of
took
up
the
whole
time
but,
like
I
I
don't
mean
to
claim
like
that.
I
know
everything.
E
So
one
topic
I'm
curious
about,
but
I'm
actually
not
certain
which
sig
it
falls
under
is
and
skit
stuff
that's
happening
in
the
ietf
like
because
we
talked
about
having
salsa
one
also
have
like
formats
releases
to
go
with
it.
So
I
think
that's,
but
maybe
that's
a
positioning
problem,
but
I'd
like
something,
but
on
that
probably
not
now
and
then
on
next
steps.
E
I
think
we
need
to
be
working
towards
like
what
a
consensus
on
what
we're
focusing
on
for
the
next
for
the
1.0
release
and
reviewing
your
document
mark
is
a
good
as
good
as
suggestion
as
any
to
start
like
forming
some
concrete
opinions,
but
I
think
ultimately,
that's
what
we
should
be
working
for
I
mean
working
towards
immediately
is
like
what
actually
are
we
trying
to
define
this?
Also,
one.
A
Sounds
good
so
does
that
sound
good
to
everyone
that
we
yeah?
I
propose
that
the
the
relationship
to
sketch
would
be
positioning
similar
to
like
spdx
and
all
those
other
things
the
yeah.
If
we
want
to
just
go
on
that
dock
and
again
feel
free
to
say
like
oh
no,
this
is
like
garbage
like.
We
should
be
focusing
on
these
other
things
or
like
this
thing.
This
topic
is
unimportant,
want
to
defer.
You
know,
let's,
let's
go
for
it.
A
A
So
so,
maybe
for
the
next
week,
we'll
just
review
the
doc
make
suggestions
or
feel
free
to
write
anything
in
there
and
do
doc's
comments.
Sean.
C
A
Yeah,
I
feel
like
comparing
google
docs
comment.
Threads
to
github
pull
requests
comment,
threads,
it's
like
which,
which
one
do
I
find
harder
to
follow.
I
personally
find
github
comment
threads
like
once.
A
thing
is
resolved.
B
A
Impossible
to
ever
follow
because,
like
each
time
a
person
responds
like
you
get
all
their
responses,
any
opinions,
one
way
or
the
other.
B
E
B
B
A
Okay,
so
then,
if
you,
if
you
have
time,
comment
on
the
doc,
I
I'll
also
give,
I
guess,
write
access
if
you're
a
member
of
the
the
google
group.
What's
that
shield
thing
well
I'll
try
to
give
right
access,
so
you
could
just
edit
in
there
if
you
want
or
like
well
often,
what
I
do
is
like.
A
I
just
make
my
own
section:
it's
like
I'm,
not
confident
in
what
I'm
writing
and
then
maybe
we'll
have
something
for
next
time
to
to
discuss,
and
then
we
can
dig
in
and
also,
I
think
in
particular,
if
like,
if
there's
topics
that
we
should
tackle
first,
like
versioning
or
the
order,
you
know
like
defining
lower
levels
or
you
know
what
everything
I
think
that's
super
valuable.