►
From YouTube: SLSA Meeting (August 1, 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
B
That
that's
okay,
I
actually
I
took
some
time
off
last
week
too,
and
and
today
so
I
I
haven't,
really
been
able
to
to
make
any
changes
or
anything,
but
maybe
we
could
spend
this
time
to
talk
about.
I
don't
know
if
any
other
folks
are
coming,
joshua
said
he's
not
he's
not
coming.
B
All
right,
so
we
have
about
six
people
here.
A
I
think
last
time
we
discussed
that
we
wanted
to
talk
through
some
aspects
of
levels,
one
and
two,
but
I
think
there's
also
some
topics
that
need
conversation
out
of
that
the
first
half
of
that
document,
specifically
around
security
requirements
and
then
oh,
what
was
the
other?
Oh
and
versioning
names,
but
kind
of
we
talked
about
that
last
week.
So.
B
B
So
I'm
getting
my
all
my
tabs
in
order,
so
you
said
levels,
one
and
two
details
versioning
and
sorry,
and
what
was
the
other
thing
you
said.
A
So
last
week
we
had
talked
about
kind
of
locking
down
levels,
one
and
two
and
then
tackling
three
and
four.
But
on
a
another
note,
there's
also
the
the
versioning
conversation.
It
looks
like
there's
a
bunch
of
comments
around
that,
and
maybe
that
might
be
a
more
productive
use
of
our
conversational
time.
B
Yeah
yeah.
That
sounds
good
to
me.
B
B
Do
you
want
to
discuss
versioning
first,
since
that
kind
of
affects
how
how
we
proceed,
like
you
said,
because,
depending
on
how
we
do
that,
then
it
could
allow
us
to
kind
of
lock
down
one
and
two
and
then
three
and
then
four.
C
B
Yeah
so
emmy
commented
on
the
hybrid
sounded
good
to
her.
So
first
of
all,
these
are
the
ideas
that
you
know
I
had
gathered
from
conversations
with
various
folks.
Does
that
list
even
seem
complete?
B
So
for
reference
we
in
the
dock,
we
are
in
the
versioning
section
and
obviously
any
changes
to
attack
or
any
text
or
suggestions.
You
know
we
we
could
make
that
I.
I
also
agree
that
hybrid
seems
like
a
reasonable
approach.
B
My
my
feeling
is
that,
like
once,
you
call
something
once
you
give
something
a
name:
it's
really
hard
to
rename
it
and
not
just
add
a
bunch
of
confusion.
I
think
if
we
are
going
to
change
the
meaning
of
the
levels
or
like
the
structuring
levels,
now
would
be
the
time.
I
think
this
is
effectively
our
only
shot.
B
B
It's
signed
or
something
and
three
is
some
guarantee
about
the
builder,
something
like
that
and
then
we
could
always
tweak.
You
know
minor
visions
but
yeah
any
agreement
or
disagreement.
D
Yeah,
I
agree,
I
think
the
big
things
are,
you
know
even
to
go
a
little
bit
further.
I
know
we
might
not
want
to
talk
about,
let's
say
specific
attacks,
but
like
classifications
of
like
generally,
this
starts
to
protect
us
against.
These
sorts
of
things
would
be
useful,
so
that
folks
know
like
okay
as
I'm
building
out
my
full
suite
of
controls
and
for
supply
chain
security.
D
D
Actually,
can
you
can
somebody
link
me
again
because
for
some
reason
it's
not
showing
up
in
my
google
talks
and
I
think.
B
Said
I
just
I
just
added
you
mike
emmy
you're
not
listed
there
either
thanks
thanks,
perfect.
Thank
you
very
much.
B
And
so
for
the
naming,
there's
one
comment,
emmy
said
v1
any
thoughts
on
like
for
how
we
specify
the
version
specifiers
for
like
when
it
matters.
B
A
I
just
I
feel
like
if,
if
our
concern
is
that
people
aren't
going
to
use
that
piece
of
it,
we
should
make
it
as
simple
and
easy
to
type
out
as
possible,
and
if
it's
going
to
have
to
be
something,
that's
encoded,
I
don't
want
a
bunch
of
extra
characters
on
it.
I
think
yeah.
B
I
was
thinking
because
I
also
think
about
like
other
specifications
to
me.
The
two
main
contenders
are
the
version,
and
the
revision
like
the
rev
rev
would
be
two
or
three.
If
you
include
the
space
more
characters,
but
visually
might
make,
it
might
be
more
in
line
with
how
other
specifications
too,
I
don't
know,
go
ahead.
A
B
Okay,
but
any
other
thoughts,
opinions.
D
Oh,
I
was
just
gonna
throw
another
wrench
in
there,
which
is
just
yeah.
Ssdf
calls
it
version.
But
if
you
look
at
nist
853
it
calls
it
revision.
So
yeah.
A
C
Yeah,
can
you
hear
me,
I'm
not
sure
my
mic's
working
are
we
planning
to
do
like
minor
versions
and
have
some
kind
of
like
compatibility
with
that?
In
that
case,
like
I
think
versioning
probably
would
be.
C
B
B
I
guess
one
one
this
is
maybe
getting
off
topic
so
feel
free
to
shelf
this.
Do
we
give
a
version
number
specified
like
right
now
we
kind
of
have
like
a
we're,
just
publishing
it
head
and
every
time
we
make
a
commit
it's
live.
We
could
move
to
a
model
where
we
do
actual
releases
and
like
we
have
one
way
to
preview
the
current
head
version,
but
the
official
version.
B
B
Yeah,
so
so,
for
example,
we
made
a
change
to
the
spec
to
add.
Well,
this
is
a
pretty
significant
one
to
change.
To
add
the
I
think.
Like
the
configures
code,
it
was
like
one
of
the
new
entries
that
we
added.
I
don't
think
we
we
didn't
bump
up
the
v1
point
the
0.1
release
number.
For
that.
I
don't
remember
if
that
happened
before
or
after,
but
let's
say
we
do
that.
B
Something
like
that
or
we
change
the
wording
to
clarify
what
parameter
list
means
and,
like
you
know,
we
say
it's
also:
okay
to
blah
blah.
B
C
B
D
I
I
also
think
that
there's
you
probably
want
to
split
up,
because
I've
seen
with
a
lot
of
these
standards
and
specifications
they
sometimes
include
like
here
is
it
here
is
something
that
is
a
clarification.
It's
not
that
we're
actually
changing
the
specification
in
some
way.
It's
just
a
hey.
It
seems
like
some
folks
misinterpreted
what
we
meant
here.
This
is
sort
of
errata.
You
know
kind
of
stuff
there.
D
I
I've
seen
that
done,
and
that
seems
to
make
a
lot
of
sense
where
it's
like
you're
trying
to
convey
that
you're
not
changing
the
actual
content.
This
is
always.
This
requirement
still
is
staying
the
same.
It's
just
that
we
need
to
clarify,
maybe
a
bit
more
of
what
that
requirement
means.
So
for
folks
who
are
maybe
saw
the
previous
you
know
like
the
the.
Without
that
update
people
can
go
and
see.
Oh,
okay,
so
actually
what
they
meant
was
this,
and
it
was
always
this
it's
never
like.
D
Oh,
I
I'm
I'm
compliant
with
a
thing
that
actually
didn't
exist
in
the
first
place
right
because
it
was
misinterpreted
or
there
was
confusion.
C
A
Needs
to
kind
of
be
sorted
out
as
well,
so
that
folks,
it's
all
about
how
often
you're
gonna
have
to
maintain
you
have
to
like
look
at
your
attestations
to
see
if
you're
still
compliant.
A
If
someone
comes
out
with
a
minor
release,
did
it
change
your
compliance
level
that
you
were
saying
that
you
were,
but
I
think
that's
more
of
kind
of
a
operational
programmatic
question
that
I'm
gonna
propose
we
put
it
on
is
something
that
needs
to
be
sorted
out,
but
that
I
don't
know,
I
think,
probably
easy
enough
in
my
mind
to
just
pick
one
of
these
for
specifiers
and
move
forward
with
it.
What
do
you
think
or
do
we
go
to
like?
A
B
A
So
I
can
put
something
in
here
about
out
of
scope,
for
this
piece
that
still
needs
to
be
sorted
out
is
what
we
just
talked
about.
B
Sure
I
added
it
to
the
meeting
notes
as
well.
So
then,
in
terms
of
like.
C
I
think
well,
I
wonder,
if
versions
might
be
a
bit
easier
for
users
to
keep
track
of
just
because
a
revision
with
respect
to
what
is
always
gonna,
be
the
question
I
think,
and
so,
if
we
can
just
say
this
is
discrete
version
1.3
or
whatever.
C
D
One
second:
can
you
hear
me
still,
okay,
so
yeah,
I
think
I
mean
my
mind
is
just
maybe
a
slight
preference
perversion,
but
it's
like,
like
you,
could
flip
a
coin
out
and
be
like
yes,.
B
Okay
sounds
like
the
majority
opinion
is
very
no
one.
No
one
expressed
preference
for
revision,
except
for
me
so
version
of
this
and
then
like
the
v1
like
parenthesis,
v,
1.0,
syntax,
sound,
okay,.
B
All
right
and
we'll
keep
like
the
salsa
3
versus,
like
l3
notation
that
we've
had
before
all
right
sounds
good,
because.
C
Yeah,
the
1.0.
B
Okay,
that's
great
all
right
that
sounds
that
sounds
good,
then,
and
then
so
we
could.
I
think
the
next
step
on
the
versioning
thing
would
be
to
like
effectively
write
this
up
in
some
official
documentation
around
like
the
the
conditions
under
which
we
bump
major
and
minor
version
numbers
and
compatibility
and
and
kind
of
effectively
sum
that
up,
but
that
could
be
done
offline.
I
think
we
have
at
least
kind
of
conceptual
agreement
on
the
gist
and
it
would
just
be
nailing
downwarding.
B
Next,
step,
nail
down.
C
Propose
wording
to
be
included,
respect,
slash,
oops
website.
B
All
right
level
one
and
two
details
yeah,
I
think
at
least
it
sounds
like
there's
well,
there's
a
there's
at
least
a
couple
opinions
expressed
to
not
specify
at
least
version
four.
Now
it
seems
reasonable
to
do
it
by
the
way.
Am
I
pronouncing
your
name
correctly?
Emmy,
okay,
great
yeah,
saying
the
wrong
thing
over
and
over
again
that
sounds
good
to
me
of
like,
let's
nail
down
one
and
two
with
like
a
effectively
a
draft
idea
of
the
future
ones.
B
One
way
that
we
could
do
this
actually
from
like
a
practical
point
of
view
is
we
could
have
a
like
a
draft
or
like
latest
or
head
or
something
version
of
the
site
that
has
like
all
the
things
and
we
kind
of
mark
the
things
that
are
draft,
but
then
on
the
actual
published
version
1.0
or
whatever
we
could.
Just
I
don't
know,
just
kind
of
visually
clarify
like
this
is
up
in
the
air
versus
these
are
nailed
down.
A
A
I'm
thinking
about
some,
I
think,
they're
under
pull,
requests
right
now
or
that
can
be
sorted
out
in
at
the
same
time
like.
Maybe
we
want
to
take
a
look
at
some
of
those.
So
like
there's
one
group
of
requirements
that
is
not
the
way
it's
listed
in
the
specifications
makes
it
look
like
it's
a
set
of
requirements,
but
it's
like
the
way
you're
supposed
to
attest.
I
guess
so.
A
It's
not
actually
like
listed
in
the
like
high
level
graphic
at
the
top,
but
then
it
if
you
scroll
down,
you
can
see
a
whole
section
of
things
that
all
say
level,
one
two
three
and
four
on
them.
Anyways
there
might
be
more
things
like
you
know
what
I'm
talking
about.
Yeah.
A
Provenance
content-
yes
yeah
yeah,
so,
but
just
with
that
in
mind,
there
might
be
some
other
things
too,
that
I
think
we're
like
working
through
the
different
levels
we
might
be
able
to.
We
need
to
probably
like
grab
some
of
those
different
things
that
need
to
be
sorted
through
anyways
and
like
circle
them
into
this,
just
so
that
it
can
all
be
updated
together.
People
aren't
left
open
with
those.
A
But
I
wasn't
thinking
that
that
was
I
don't.
I
don't
even
know
if
it's
possible
to
lock
down
details
of
levels,
one
two
in
a
meeting
that
might
be
something
that
we
need
to
do
offline,
like
have
collaborative
discussions.
B
Yeah
I
have
so.
I
have
inspection
in
the
doc.
We
define
levels
as
outcomes,
not
requirements
which,
if
you
like
click,
my
little
picture
in
google
docs,
it
should
jump
to
my
cursor
and
I
there's
a
comment
here.
B
So
I
think
one
thing
that
I'd
like
to
figure
out
is
that
I
think
it
does
warrant
discussion.
Well,
what
is
is
s-bomb,
I'm
gonna
shove
that
for
a
second,
so
for
level.
One
and
two
I
my
proposal
here
is
that
effectively
level
one
is
that
provenance
exists.
B
Well,
I
I
want
your
opinion
on
on
this,
but
like
providing
sufficient
information
to
build
the
package
from
source,
because
I'm
trying
to
express
it
like
what
value?
Does
it
give
to
someone
to
to
have
this
information?
B
B
That
is
maybe
one
way
to
say
like
how
it
could
help
security
that,
like,
if
an
organization
wants
to
say,
like
I'm,
not
going
to
import
any
binary
packages,
I'm
always
going
to
build
everything
from
source
by
having
provenance
for
the
binary
packages.
You
do
gain
effectively
instructions
for,
like
you,
gain
confidence
that,
when
you're
building
from
source,
you
could
do
it
correctly.
B
The
accuracy
is
tested
by
some
service
so,
like
you
effectively
have
someone
like
there's
some
party
who's,
claiming
it
versus
like
a
random
person
on
the
internet
and
from
like
a
kind
of
compliance
and
like
security
point
of
view,
it
requires,
like
someone,
would
have
to
deliberately
attack
it.
It
requires
like
specifically,
evading
controls,
so
that
does
raise
the
bar
from
the
attacker
profile.
That's
not
just
like
someone.
B
A
I
feel
like
we
might
be
comparing
apples
with
oranges
with
level
with
those
descriptions,
and
I
maybe
we
do
how
it
relates
to
provenance
and
how
it
relates
to
an
adversary
both
in
each
level
for
the
description
while
they
they're.
You
can't
draw
correlations
between
the
two.
B
I'm
not
sure
any
other
one
thoughts.
I
have
to
process.
C
My
thought
was
more
around
like
the
s
bomb
stuff.
I
wasn't
sure
whether
we
were
talking
about
swam
all
the
time
with
the
signing
and
stuff
like
that.
But
at
least
I
heard
several
conversations
with
different
folks
and
I
think
the
question
like
like
salsa
as
bomb
both
both
kind
of
solve
slightly
different
problems.
I
guess
the
question
is
like:
would
we
want
to
include
vulnerability
management
within
the
salsa
framework,
or
do
you
want
to
keep
that
separate.
D
I
I
think,
actually,
that
that
ties
in
I
don't
want
to
go
down
this
rabbit
hole,
but
just
want
to
highlight
a
thing
where
I
know
we
had
kind
of
discussed
this
previously
a
little
bit
which
is
right
now.
Salsa
is
very
focused
on
the
provenance
piece
right
because
salt,
because
provenance
itself
is
not
really
something.
That's
discussed
a
lot
in
the
supply
chain
space
yet,
and
so
this
is
kind
of
like
helping
fit
that
need.
D
But
I
remember
in
a
bunch
of
the
conversations
we
were
going
back
to
like
hey,
maybe
1.0
or
post
1.0.
We
start
to
look
at
and
separate.
You
know
this
is
salsa
providence
and
then
there's
potentially
salsa
vulnerability,
management
and
whatever
else
as
time
goes
on,
so
just
wanted
to
kind
of
one
highlight
that
as
something
you
know,
I
think
we
should
keep
on
the
provenance
piece
for
right
now
and
then
the
second
piece
which
I
think
is
tied
to
what
emmy
was
saying,
which
I
I
agree
with,
is
when
implementing
this.
D
At
the
previous
place
I
was
at.
There
was
a
big
conversation
about
okay.
So
what
does
salsa
one
give
us
and
what
is
really
you
know
what
are
the
takeaways
of
the
different
salsa
levels
and
what
are
like
almost
a
requirement
like
what
are
the
general
human
readable
requirements
and
the
first
one
is
like
the
way
that
we
had
sort
of
defined
it
was
salsa.
One
is
about
keeping
track
of.
D
What's
going
on,
just
keeping
track
of
the
logs
the
build
logs
and
so
on,
whereas
a
lot
of
companies
today
and
organizations
projects
could
just
be
like
yeah,
we
throw
out
all
the
build
logs
after
we're
done
with
it
and
go
oh
well.
If
you
ever
need
to
go
back,
how
do
you
know
what
happened
right
and
that's
just
salsa
one,
and
that
doesn't
really
give
us
a
whole
lot,
but
you
know
it
helps
us
go
back
and
audit
and
and
start
to
figure
stuff
out.
D
However,
that
would
not
prevent
what
salsa
2
can
help
prevent
is
like
did
you
know?
Could
anybody
just
sort
of
generate
some
provenance
and
just
push
it
somewhere
and
say
yep?
This
log
is
what
generated
that
artifact,
yes,
salsa
one!
Can
that
doesn't
protect
against
that,
but
salsa
2
requires
that
attacker
to
have
access
to
your
secrets
that
are
doing
the
signing
and
that's
kind
of
how
we
were
going
through
to
sort
of
say,
sort
of
show
like
what
what
the
takeaways
are
and
some
of
the
takeaways
are
go
beyond
the
attack
takeaway.
D
Some
of
it's
also
just
general
efficiency
stuff
like,
as
you
know,
one
of
the
other
examples
when
we
were
talking
about
salsa
2
is
now
you
know.
This
build
system
is
the
one
that
built
it.
D
If
you
have
multiple
build
systems,
you
can
have
different
keys
and
different
identities
associated
with
those
build
systems,
and
then
you
can
always
know
and
go
back,
and
you
know
you
have
increased
confidence
that
the
provenance
is
correct
and
each
for
me
at
least
the
takeaway
for
salsa
itself,
at
least,
as
it's
stated,
the
takeaway
at
every
level
of
salsa.
Is
you
have
increased
confidence
that
the
provenance
is
what
it
says
it
is.
B
D
Oh
you're
on
you.
C
C
I
guess
what
I
also
wanted
to
point
out
was
that
it
might
be
helpful
to
provide
users
with
a
definition
of
like
what
all
even
falls
under
provenance,
because
I
mean
salsa
has
like
a
providence
specification,
which
is
like
the
actual
format
right,
but
it
seems
like
right
now
we're
also
talking
more
broadly
about
other
ways
that
we
can
understand
how
an
artifact
came
to
be
right,
and
so
maybe
providing
at
least
especially
if
level
one
is
going
to
be
the
sort
of
collect
information
about
your
build,
providing
sort
of
a
definition
or
a
list
of
what
all
falls
under
provenance.
D
Yeah,
so
maybe
we
make
that
clearer
in
the
in
the
specification
because,
like
right
now,
nothing
right
mark
nothing
requires
also.
D
We
just
suggest
that
you
use
salsa
predicate
format,
but
it
could
just
as
easily
be
an
s-bomb,
but
I
think,
as
we
are-
and
this
is
kind
of
part
of
I
think
how
we
this
is
something
for
the
positioning
group
as
well-
is
how
do
we
wanna
like
how
closely
do
we
want
to
do
that
right,
because
there's
there's
definitely
some
questions
and
concerns
around
interoperability
right
like
if
somebody
is
like
hey
I've
been.
D
I
have
millions
of
s-bombs
and
now
you're
telling
me
that
all
of
these
are
worthless
because
they're
not
salsa
specification,
I
think,
is
something
that
we
don't
necessarily
want
to
say,
but
we
might
want
to
have-
and
this
is
something
that
was
being
discussed
in
the
tooling
group
on
friday,
which
is
like
hey.
Maybe
we
also
have
some
tools
that
can
help
translate
between
you
know.
If
you
have
a
signed
s-bomb,
oh
okay,
well,
you
could
easily
turn
that
into
salsa.
D
You
know
specific,
you
know
salsa
format
and
I
think
largely
these
things
are
there.
So
I
think
we
should
that's
that's
another
piece,
though,
which
is,
I
think
we
should
be
reevaluating.
D
What
are
the
optional
versus
required
components
within
salsa,
predicate
format,
which
I
think
we
should
just
sort
of
have
that,
as
even
if
you
don't
use
salsa
predicate
format,
the
values
here
are
still
probably
the
same
values,
whether
or
not
they
live
in
an
s
bomb
or
anything
else
right,
because
you
probably
still
want
to
keep
a
lot
of
this
stuff
right
now
is,
is
all
optional,
but
I
think,
as
time
goes
on,
we
might
want
to
say
it's
optional
for
lower
levels,
but
probably
required
for
higher
levels.
C
B
Yeah
yeah,
I
agree
with
with
what
everything
was
said:
the
yes,
so
I
the
intention
was
not
to
require
a
specific
format
and
I
think
we
could.
I
think
it
having
the
same
name
is
confusing.
B
So
that's,
I
think
something
to
consider
of
like
should
we
I
don't
know,
I
don't
know
how
to
do
that.
Originally,
we
had
so
for
reference.
Originally,
we
had
it
under
the
in
toto
project,
but
then
it
was
hard
to
get
agreement
from
everyone
on
like
what
does
the
official
in
toto
provenance
cover
and
in
order
to
unblock
that
we
just
moved
it
under
the
salsa
project.
So
that
way
we
could
define
it
for
our
purposes.
B
What
do
we
need
and,
for
example,
tekton
developed
their
own
format
since
then
we
were
aligned
and
and
the
v0.2.
So
maybe
we
could
revisit
that
in
order
like
like,
perhaps
not
calling.
C
B
Yeah,
just
maybe
that
would
be
a
way
to
avoid
the
confusion.
That's
not
required,
although
maybe
maybe
the
confusion
is
valuable.
Coming
back
to
like
the
definition
of
levels,
I.
B
B
We
should
we
should
figure
out
the
details
like
do
you
need
to
list
the
source
repository?
Do
you
need
to
list
the
dependencies?
Is
it
best
effort,
etc?
There's
also
another
comment
by
the
way
that
optional
requirements
are
confusing
because
like
if
it's
optional
at
level
three,
what
what
the
heck
does
that
mean
like?
Isn't
it
optional
at
every
level
unless
it's
required,
so
so
I
think
we
should
figure
that
out,
but
but
effectively
level.
B
Tamper
protection
and
like
accuracy,
guarantees
well
does
it
does
that
have
an
error
you
guarantee,
I
don't
know,
that's.
I
guess
a
question
because
that's
something
you
said
mike
right:
yeah.
D
Yeah,
so
so
I
think
there's
definitely
elements
there
right.
So
as
you
go
up,
it's
it's
more
about,
I
think
the
the
tamper,
evidence
and
tamper-proofness
of
the
claims,
because,
like
there's,
nothing
that
today
in
salsa
that
would
prevent
a
build
system
that
totally
non-maliciously
it
just
turns
out.
The
build
system
is
broken
from
misreporting,
exactly
how
it
built
something,
and
I
think-
and
I
think
those
are
you
know.
D
Obviously,
two
important
pieces
like
like,
I
think
the
main
purpose
of
salsa
is
more
from
the
security
aspect,
as
opposed
to
the
the
actual
like
accuracy,
though
I
do
think
that
as
we
kind
of
go
through,
obviously,
people
are
probably
going
to
start
poking
around
with
the
various
build
tools
and
saying:
hey.
Is
this
accurately
reporting
the
data
you
know
and
then
being
able
to
kind
of
go
from
there?
D
But
you
know
I
I
think
that's
something
that
is
still
like
going
to
be
an
issue
right
regardless,
is
like
the
what
you
know
as
an
example
right
when,
when
looking
at
the
various
stuff
in
the
specification
and
looking
at
build
parameters
and
the
build
context
and
all
the
build
environment
information
that
we
want
to
include
in
there,
different
tools
are
going
to
assume
those
are
different
things.
D
So
there's
a
level
of
how
clear
do
we
want
to
be
versus
how
flexible
do
we
want
to
be
there
right,
because
some
people
might
just
say.
Oh,
these
are
environment
variables,
some
people
might
say
these
are
parameters
to
the
build
and-
and
you
know.
B
So
so,
in
practical
terms
like,
I
think,
it's
valuable
to
define
the
levels
in
terms
of
like
the
the
outcome,
but
in
like
practical
terms
of
like
what
you
actually
have
to
do
to
the
level
I
think
level
one
is
you
just
generate
provenance
and
it
has
to
you
have
to
at
the
best
effort
populate
this
type
of
data
like
with
a
specific
piece
of
information,
source
dependence,
etc.
B
We
could
discuss
what
the
specific
things
are.
Does
that,
first
of
all,
does
that
sound
good,
yep,
okay
and
then
level
two
is
have
it
be
generated
by
some
service?
Have
that
service
sign
it
that
I
think
we
we
agree
on.
B
Are
there
any
more
requirements
than
that?
I
have
one
I
want
to
discuss,
but
before
I
discuss
that
one
are
there
any.
B
Others,
okay,
so
one
thing
that
now
this
is
leading
topics
but
the
the
verification
piece
and
an
aspect
that
I.
B
I
think
we
need
to
decide
at
least
as
far
as
level
two
goes
or
or
we
may
make
a
decision
for
whether
it
affects
level
two
or
not
is
something
I
wanna
introduce
is
that
for
a
given
package
that
there
has
to
be
some
definition
of
what
the
canonical
or
expected
source
repository
is
for
that
package.
So,
for
example,
for
the
pi
pi
package.
B
That,
if
someone
builds
from
a
fork
of
that
that's
published
to
github
on
a
fork
or
from
like
a
fork,
that's
on
github
or
like
their
local
copy,
basically
a
commit,
that's
not
in
the
official
repository
on
if
the
correct
branch
or
tag
or
whatever
then
effectively.
That's
not
the
same
code.
B
Right
because,
like
you,
could
just
in
an
extreme
example,
just
replace
the
entire
contents
with
a
completely
different
software,
and
so
I
like,
for
example,
that's
what
we
do
at
google.
We
we
have
this
concept,
although,
like
our
current
levels,
haven't
had
nearly
this
level
of
thought
that
we're
putting
into
this
meeting
right
now,
the
oh.
So
I
think
I
feel
like
we
need
to
introduce
that
at
some
point.
D
So
I
think
this
thing
is
is
also
one
of
the
it's
tied
to
also
the
problem
of
who
determines
what
the
canonical
source
is
and
also
in
certain
contexts
where,
for
example,
right
like
how
do
you
want
to
define
for
like
red,
hat's
version
of
a
thing
right?
Red
hat
often
has
patches
and
whatever
else,
and
so
they
are,
you
know
they
might
be
pulling
from
upstream
code
and
injecting
other
stuff
on
it,
and
some
people
might
say.
D
Actually
I
trust
that
more
than
just
the
the
the
other
package
that's
coming
out,
and
so
I
think
we
do
want
to
figure
out
like
how
do
we
support
that
use
case,
while
making
sure
that
people
understand.
D
B
Yeah,
and
so
this
kind
of
again
bleeds
into
the
policy
question
like
what
is
the
policy
model
which
we'll
have
to
figure
out
in
my
mind,
the
way
it
would
work
like
in
practice
would
be
that,
for
wherever
is
consuming
this
artifact,
that
there
needs
to
be
some
sort
of
policy
or
configuration
saying
what
is
expected.
B
So
if
I'm
expecting
it
to
be
built
from
directly
from
github,
then
someone
building
it
from
red
hat
would
not
be
acceptable
right
if
in
a
different
environment,
if
it
is
I'm
expecting
it
to
be
built,
like
let's
say
the
packages
on
the
red
hat,
whether
red
hat
apology
linux,
is
that
the
currently
important
like
or
whatever,
distribution,
if
it's
supposed
to
be
built
from
there,
then
building
different
grit
hub
is
actually
wrong
right
and
like
it's
supposed
to
be
built
from
the
get
the
fork
and
those
are
two
different
packages,
and
they
would
have
two
different
effectively
policies.
B
C
You
might
have
been
about
to
step
into
this,
but
I
was
just
wondering:
does
it
satisfy
this
concern
simply
to
make
sure
that
source
is
listed
in
the
provenance
document
and
as
long
as
that
is
done,
then
downstream
verifiers
can
look
at
that
source.
Or
do
you
want
policy
verification
to
be
built
into
the
requirement.
C
B
This
would
be
the
way
it
works
in
my
mind,
one
the
way
it
works
at
google
and
the
way
it
works
in
my
mind
is
that
the
in
the
provenance
document
it
says
where
it
was
actually
built
from
and
is
tied
to
a
specific
artifact
with
with
a
hash
right,
you
build
a
new
one.
You
get
a
new
provenance
there's
also
a.
B
Policy
that
perhaps,
among
other
things,
says
all
artifacts
that
are
to
be
called
pi
yaml
have
to
be
built
from
this
source.
So
it's
like
the
prominence
would
be
this
artifact
with
this
hash
was
built
from
the
source.
With
this
hash,
the
policy
would
say
you
know
almost
like
a
template
or
a
match
or
something
saying
in
order
for
something
to
be
called
pi
yaml,
it
has
to
come
from
a
you
know,
source
that
looks
like
this.
So
it's
not
quite
it's
like
a
different
level.
C
C
Actually
another
possibility
could
be
that
you
know
we
we
I
mean
in
this
way
we
are
stressing
who
performs
the
actual
building
of
the
final
artifact
okay,
so
it's
basically
responsibility
of
who
performs
the
build
to
decide
if
the
package
that
is
coming
is
okay
kind
of
trusted
this
kind.
Okay,
now
the
possibility,
maybe
is
like
we
actually
define
some
reference
repositories
like
for
payamal,
we
reference
github,
and
then
we
say:
okay.
C
If
there
is
somewhere
else,
another
dependency
manager,
another
manager,
another
package
manager.
For
this,
then
this
guy
can
ask
for
permission
to
be.
Like
accounted
as
an
official
repository,
you
see
what
they
say.
D
Yeah
I
mean
I,
I
do
think
that
I
think
the
question
is
and
is
salsa
as
a
thing.
D
Somehow
an
orbiter
of
truth
on
on
the
source
sources
here,
and
I
I
so
I
I
would
kind
of
I
think.
C
D
I'm
trying
to
think
here
right
of
I'm
trying.
D
There's
I
think
what
we're
trying
to
kind
of
get
across
here
is.
Is
people
want
to
know
like
where
the
actual
code
came
from,
and
I
think
there's
a
couple
of
things
which
is
a
malicious
actor?
You
know
who
who
puts
a
different
repo
than
what
they're
actually
building
right
can
just
say:
hey,
I'm
building
whatever,
so
I
don't
see
what
any
of
the
verification
gets
you
really
like
outside
sorry.
D
I
think
we
need
to
like
separate
out
the
verification
piece
which
is
still
like
a
valuable
thing
to
know
whether
or
not
let's
say
somebody's
lying
to
you
in
some
way
like
if
there's
ways
you
could
look
at
the
salsa
salsa
data
and
be
able
to
verify
it
in
some
way
that
you
can
verify
it
in
a
way
that
the
person
who's
actually
making.
The
claim
can't
falsify
that
own
claim.
D
Because
I
know
there
was
some
discussion
about
previously
about
like
hey
when
looking
at
salsa,
could
you
go
in
and
say
I
have
I'm
a
package
manager
here
and
to
prove
to
you.
I
can
make
an
update
to
that
source
repository.
I
can
like
essentially
put
like
a
a
little
test
file
there
with
an
identifier
regarding
the
build
or
something
like
that,
so
you
can
go
and
validate.
D
Oh,
I
made
this
change
that
you
know
essentially
just
made
an
arbitrary
change
to
the
to
the
code
base,
and
then
I
can
verify
that,
but
I
think
to
take
a
step
back.
I
think
that
the
main
thing
here
is
like
most
of
what
is
based.
What
most
of
what
salsa
is
based
on
is
that
you
are
at
some
level
trusting
whoever
is
giving
you
the
sauce
of
providence.
They
are
saying,
hey,
look,
I
did
the
right
things
and
at
some
level
you
know
you
have
to
trust
them
that
they
did
the
right
things.
D
The
things
that
salsa
gives
us
is,
it
gives
us
more.
It
gives
us
tamper
evidence
and
tamper
evidence
when
somebody
outside
of
the
person
making
the
claim
is
saying.
Actually
I
am
that
person
and
I'm
this
is
the
claim
I'm
making.
C
Yeah,
okay,
okay,
I
got
it,
I
mean
I
think,
makes
sense.
I
was
just
you
know
raised
the
point
because
I
was
not
sure
what
is
the
best.
What
was
the
best.
C
So
I
think,
to
add
to
both
alessandro
and
mike
were
saying:
maybe
this
is
just
my
interpretation
is,
I
guess
it
would
probably
be
very
useful
to
have
a
notion
of
like
what
is
a
reference
value
for
a
specific
source.
C
I
guess
my
question
then,
would
be
if
I'm
the
actual
package
maintainer
and
I
sign
off
of
off
on
whatever
the
specific
hash
of
my
repo,
and
I
say
if
you're
building
from
my
repo.
This
is
what
the
hash
should
look
like.
Is
that
evidence
now,
for,
I
guess,
the
validity
of
the
source.
C
D
Yeah,
so
I
so
what
I
think
is
valuable
here-
and
this
is
just
once
again
by
my
my
opinion-
is
most
likely
like
I
imagine,
especially
with
how
salsa
is
going
and
then
what
people
are
doing
with
this
thing
and
what
they're
going
to
want
to
convey
right
people
are
wanting
to
convey,
is
hey.
I
wrote
none
of
this
code,
but
I'm
a
security
company
or
whatever
that
has
built
that
code
very
securely.
We
we're
that's
the
claim,
we're
making
we're
making
the
claim.
D
We
didn't
write
the
code,
but
we
built
the
code
securely
and
that's
kind
of
what
is
coming
out
of
a
lot
of
the
salsa
stuff.
The
salsa
stuff
is
not
necessarily
that
it's
all
about
the
provenance
piece
right.
It's
it's
not
that
I'm
claiming
that
somehow
the
software
is
not
malicious.
I'm
just
claiming
that
this
software
was
built
in
these
ways
against
this
source
code,
etc,
etc,
and
I
think
still
from-
and
this
is
where
the
sort
of
adoption
positioning
and
tooling
comes
into
play
is.
I
do
think
that
sorry.
D
No
never
mind
what
the
tooling
is
coming
into
play
is,
I
think,
super
valuable
here.
Oh
give
me
one.
Second,
sorry.
B
All
right,
I
don't
know
how
long
a
literal
second
or
a
couple
minutes.
So
in
the
meantime,
I
think
I
think,
there's
a
difference
between.
B
We
need
to
agree
on
like
wording
and
concepts
here.
I
didn't
actually
mean
verification
that
the
claims
being
made
are
true,
like
if
you're
built
on
github
actions
that
github
actions
or
has
been
compromised
or
is
lying
or
there's
a
bug
or
whatever,
like
that.
That's
not
actually
not
what
I
meant.
So
maybe
verification
is
the
wrong
word,
but
rather
I
was
thinking
that
like,
if
I'm
a
pie,
yaml
user
and
I
do
like
pip
and
stall
pie
yaml.
B
So
all
right,
so
we're
almost
out
of
time
so,
okay,
so
I
take
from
this
conversation,
I
propose
that
we
do
not
include
level
two,
because
it
sounds
for
two
reasons:
one.
B
B
I
think
we
could
add
it
to
a
later
level,
because
we
don't
we
kind
of
want
to
make
each
of
the
steps
achievable
without,
like
too
big
a
jumps
between
steps,
and
so
this
would
probably
be
too
big
of
a
jump,
and
so
we
can
work
on
kind
of
shoring
up
what
this
means
and
get
a
better
first
of
all
agreement
on
what
it
is
and
then
figure
out
like
do
we
actually
want
it
as
a
requirement,
but
but
we
could
defer
it
to
a
future
level
and
so
effectively
level.
B
B
I
see
some
nodding
heads,
so
okay
someone's
highlighted
that
yeah.
If
you
want
to
just
have
the
comment
in
the
doc
to
say
to
to
move
to
future
level.
That
sounds
good,
so
I'll
say.
C
Consensus
move
to
to
a
higher
level.
B
Don't
have
a
clear
shared
mental
model
for.
B
B
Don't
have
a
clear
mental
file
too
big
from
one
to
two:
okay,
great
all
right,
so
we're
at
a
time
calendar.
Yes,
I
think
it's
still
missing
from
the
calendar,
so
next
steps.
I
think
if
we
could
continue
revising
the
docs
feel
free
to
make
any
suggestions
changes
and
if
you
have
thoughts
on
what
to
discuss
next
time,
that
would
be
great
all
right.