►
From YouTube: SLSA Specifications Meeting (October 10, 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
A
Hi
everyone
welcome
if
a
reminder
to
please
sign
in
to
the
meeting
notes
which
I'm
pasting
into
the
chat
right
now
and
a
reminder
that
participation
in
the
meeting
is
an
agreement
to
buy
buy
by
the
Linux
Foundation
code
of
conduct,
which
can
be
found
in
at
the
top
of
the
meeting
notes.
A
If
anyone
has
agenda
items,
please
please
add
them.
I
mostly
want
to
talk
about
that
the
1.0
proposal,
so
first
I
want
it's
the
first
item.
You
know
and
I'll
I
guess:
I'll
present
real
quick.
A
So
we
talked
about
this
in
previous
meeting,
there's
a
a
conversion
of
the
1.0
proposal
dock
that
this
group
has
reviewed
to
mark
down,
ask
folks
to
to
review
it.
I
have
two
lgtms.
So
far
since
I
haven't
heard
anything
I'll
submit
it
by
the
end
of
the
day,
so
it's
just
the
last
chance
to
calm
it
down
before
it's
a
minute.
I
could
always
make
further
pull
requests
to
change
it
if
needed,
but
I
just
want
to.
Let
folks
know.
A
Second
topic:
I
wanted
to
present
just
to
give
an
update
on
some
changes.
I've
been
making
it's
not
really
ready
for
review
per
se,
but
I
just
want
to
not
have
like
silence
for
weeks
on
end
I
have
a.
Let
me
show
you
the
screen.
A
Yes,
okay,
all
right!
Thanks!
I
found
the
zoom
interface
confusing
every
time.
So
this
this
is
the
only
page,
I've
updated.
So
far
it
tries
to
incorporate
the
the
main
high
level
feedback
that
we're
wanting
to
address
for
1.0,
namely
explaining
at
a
higher
level
what
the
levels
are
explaining.
Why
we're
doing
and
what
the
security
you
know
what
the
benefits
are
and
kind
of
give
a
more
clear
progression.
A
I
think
I
won't
read
through
the
text
out
again:
I'll
send
out
a
proper
pull
request
later,
once
I've
cleaned
up
a
lot
of
these
to
Do's,
but
I
have
like
a
little
bit
expanded,
intro,
a
summary
of
the
levels
with
requirements
and
benefits.
A
A
Should
go
in
this
page
or
a
different
page,
and
the
the
main
thing
is
that
this
build
track
page
where
we,
where
I
talk
about
kind
of
what
the
what
each
level
means
who
it's
intended
for,
what
are
the
actual
requirements
and
why
one
would
want
to
do
that
and
so
the
the
the
the
the
base
again,
the
basic
idea
is
to
give
people
a
clear
guidance
for
like
who
were
these
levels,
for
how
would
I
go
about
doing
them?
What
why
would
I
do
them?
A
I
think
there's
still
further
work
to
do
here.
In
particular,
we
talked
about
breaking
up
requirements
between
like
what
the
project
maintainers
should
do
versus
like
a
implementer
of
a
build
system
should
do
that.
A
I
haven't
Incorporated
yet
but
I'm,
hoping
that
this
type
of
layout
will
be
a
little
bit
easier
to
read
again
if
you're
interested
in
looking
at
a
preview
version,
you
could
click
on
the
link
in
the
meeting,
notes
and
I'm
going
to
hopefully
have
this
within
a
day
or
two
to
send
out
to
for
actual
review
again
chopping
out
a
lot
of
the
to-do's.
Maybe
one
thing
that's
worth
asking
now
like
before
kind
of
wordsmithing.
The
text
is
on
this
summary
of
of
levels.
A
I
tried
to
incorporate
the
the
notion
that
it's
not
just
like
just
publishing
provenance
is
not
sufficient,
that
you
need
to
actually
do
something
with
it
or
else
you
don't
actually
get
any
of
the
benefits
like
you
can't
you
don't
prevent
any
attacks
if
you
publish
Providence
and
it
just
gets
deleted
for
example
or
used,
so
some
Downstream
system
actually
has
to
do
something
with
it
to
make
some
sort
of
impact.
A
So
I
tried
to
include
that
in
the
wording,
so
so
at
build
level.
One
evidence
that
the
package
was
built
as
expected
or
documented,
which
would
incorporate
the
notion
like
not
just
that
it
exists,
but
that
also
there's
some
sort
of
expectation
of
what
it
should
look
like
and
you're.
Comparing
to
that
and
then
at
level
two
we
had
signing
and
the
hosted
build
service
and
then
three
is
further
hardening
because
and
is
there
any
initial
thoughts
on
that?
Like?
Oh?
No,
that,
like
yes,
that's
good
or
no
that's
terrible.
B
A
C
Yeah
no
I
think
generally
this.
This
looks
good
I'm
just
trying
to
think
of
some
of
the,
and
we
can
figure
out
some
of
the
wording.
But
I
know
that
there's
what's
the
term
for
it,
where.
C
I
think
we
just
need
to
make
it
clear
that
it
should
be
considered
an
affirmative
thing
like
lack
of
salsa
evidence
doesn't
necessarily
mean
anything
if
that
makes
sense
like,
for
example,
I
think
with
what
we
were
talking
about
with
like
L1
right
is,
if
you
are
I'm
trying
to
think
of
how
to
how
to
word
this,
but
it's
like
this
thing
here
of
you
know:
L1
is
a
start.
Obviously
it's
not
signed,
yeah,
yeah
and
I.
C
Think
you,
you
did
a
pretty
good
job
there,
explaining
that
it
could
be
incomplete,
but
I
think
the
thing
that
we
just
need
to
make
sure
is
that
incompleteness
should
not
be
an
assertion
that
you
actually
did
something
correct.
It
should
be
only
used,
as
we
don't
know,.
A
Yeah
I,
don't
think
I
follow,
but
maybe
I
think
yeah.
C
Sorry
I'm
I'm,
trying
to
think
of
the
I'm
forgetting
the
actual
term
for
it,
but
it's
like
it's
like
a
positive
assertion
like
so
at
L1,
right
or
even
in
some
of
the
other
ones,
I'm
trying
to
think
of
the
the
right
way
to
explain
it.
It's
like.
D
I
mean
I
mean
if
I,
maybe
as
I
understood
L1
beforehand.
It
was
just
the
ability
two
generate
some
type
of
Providence
attestation,
not
necessarily
the
the
actual
evidence
of
of
Providence
attestation.
Right
I
mean
so
so
the
ability
to
be
able
to
generate
that
alone
was
sufficient
for
L1
I
mean
I'm,
saying
I
I.
D
If
this,
if
this
has
changed
great
I'm,
just
saying
that
the
that
the
ability
to
provide
it,
not
necessarily
the
absence
of,
doesn't
necessarily
detract
from
from
being
from
being
a
level
one,
but
the
ability
to
generate
Providence
attestation,
it's
sufficient
for
L1,
so
and
I'm
just
I'm,
just
giving
the
caveat
to
to
to
what
to
what
to
what
Mike
is
saying:
I
mean
I
I,
don't
the
lack
of
evidence
doesn't
necessarily
mean
that
you
don't
have
L1.
If
you're
able
to
generate
said
evidence.
A
Yeah
and
And
to
clarify,
there's
I,
think
two
other
than
like
a
rewrite.
You
know,
like
refactoring,
I,
think
there's
two
main
content
changes
here
that
I'm
just
kind
of
like
previewing
for
this
group
to
discuss
now
and
we
could
actually
I
think
once
you
actually
read
the
thing
I
think
that's
a
better
way
to
form
an
opinion,
but
one
is
like,
including.
A
The
switch
to
the
term
evidence
where,
like
provenance
attestation
is,
is
the
form
of
the
evidence,
because
when
I
was
writing
this
original
table
up
here
saying
provenance
exists
or
something
like
that.
It
almost
it
kind
of
raised
the
question
of
like
well.
What
beg
the
question
of?
Why
does
that
is
that
value,
whereas
I
think
evidence
is
a
little
bit
more
self-explanatory
or
I'm
opening?
A
That
was,
that
was
a
thought
process
and
two
that
there
is
that
it
would
require-
and
this
is
this
is
a
big
change
and
and
that
we
really
need
to
discuss
at
level
one.
We
not
just
produce
Providence,
but
you
also
have
some
expectation
of
what
that
Providence
should
look
like
that
and
I
think
I
said
it
down
here
like.
What's
expect?
How
is
it
expected
to
be
like
the
source
repository
in
the
build
command
and
and
that
that
you
actually
check
it
against
that,
so
that
these
two
are?
B
Yeah
I
might
be
echoing
what
some
of
the
other
folks
are
saying.
I
think
for
me,
I'm
having
a
bit
of
a
hard
time
with
the
word
evidence
itself,
because
we
also
have
this
notion
of
providing
evidence
for
the
claimed
like
metadata
right
for
higher
provenance
levels
and
so
I'm
wondering
if
the
word
evidence
might
be
a
bit
misleading
like.
B
What
I'm
trying
to
say,
I,
guess
and
are
we
really
providing
evidence
or
is
it
really
just
claims
of
this
was
built
in
a
certain
way
or
or
assertions
or
maybe
on
being
a
bit
of
a
language
stickler?
But
if
we
are
using
evidence
to
mean
something
else
in
other
levels,
then
I'm,
maybe
we
should
disambiguate.
This
is
what
I'm
saying.
A
Yeah,
no,
that's
that's
I,
think
a
very
good
point.
So,
like
one
one
way
to
change,
it
would
be
to
just
say
like,
for
example,
attestation
that
the
package
was
built
as
expected,
yeah.
A
Out,
like
an
outcome
perspective
like
what
are
we
actually
trying
to
achieve
here,
I
think
like
well,
one
I,
don't
we
have
to
be
careful
about
wordy,
because
it's
not
just
an
attestation
that
the
package
has
built,
but
more
of
like
that,
we
checked
that
there
was
some
sort
of
attestation.
It
was
actually
built
the
way
it
was
supposed
to
be
built.
A
Okay,
all
right,
maybe
we
should
well
it's
up
to
you
if
you
want
to
spend
more
time
in
it.
I
could
also
think
I'll
try
to
incorporate
that
more
in
the
draft,
and
then
we
could
also
think
about
it
when
we
actually
send
a
pull
request.
A
A
Any
thoughts
on
like
this
notion
that
there
is
some
sort
of
expectation.
It's
what
we've
you
know
I'd
be
tonight
called
policy
before,
but
that
term
is
overloaded
and
so
I'm
just
trying
to
avoid
that
term
that
there's
some
sort
of
expectation
of
how
it
should
be
built,
like
all
versions
of
the
package,
should
be
built
or
future
versions
of
the
package
should
be
built
and
that
you
verified
against
that.
A
So
it's
not
it's
not
just
change
your
build
system
and
you've
done,
but
there
needs
to
be
some
sort
of
notion
of
what
correct
is,
and
it's
not
here,
I,
don't
know
where
to
stick
it,
but
correct
could
be
an
explicit
writing
down
of
like
it's
supposed
to
be
built
from
this
Source
or
it
could
be
implicit
of,
like
all
prior
versions
were
built.
This
way,
so
I
expect
future
built
versions
to
be
built.
That
way
too.
B
Monica,
are
you
referring
to
the
check
being
done
by
the
publisher
or
the
check
being
done
by
the
receiver.
A
I
was
trying
so
I
had
like
a
little
thing
saying
it's
kind
of
implementation,
dependent,
upload
and
use,
maybe
I
should
say
who
doesn't
do
I
was
thinking
that
this
would
be
unopinionated
about
that
that,
like
you,
could
claim
to
do
salsa
in
either
case
like
if
you
do
it
at
upload
time,
for
example
like,
for
example,
if
this
is
Let's
Pretend
We're
doing
this
for,
and
the
npm
open
source
ecosystem
like
npm
doing
it
upload
time
or
the
npm
client
at
install
time
or
even
some
sort
of
monitoring
like
just
the
fact
that
the
check
happens
seems
valuable,
although
Maybe,
that
almost
implies,
that
should
be
a
different.
A
It's
almost
orthogonal
of
like
whether
it
was
actually
enforced
or
not
I
would
like
does
a
general
warning.
Does
it
actually
block
the
uploads?
Does
it
just
send
it?
After
the
fact
notifications.
B
Yeah
this
issue
will
show
who
provides
this
expectation.
We
could
maybe
discuss
that
offline.
Is
it
like
if
it
takes
too
much
time.
A
Yeah
I
I
was
thinking
for
for
the
you
know
who
provides
it
I.
Maybe
this
wording
is
too
too
prescriptive,
but
I
feel
like
the
package.
Maintainer
is
the
one
that
is
the
only
one
that
really
knows
that
that
like
I
as
a
user
have
to
just
trust
whatever
the
package
maintainer
says
like.
If
they
say
it's
going
to
be
built
from
this
source,
then
it
doesn't
make
sense
for
me
to
expect
it
to
be
about
from
some
other
source
like
I.
Can't
I
can't
get
them
to
do
that.
A
Okay,
so
anyway,
I'll
I'll
share.
This
I
want
to
see
that
thought
in
people's
heads
in
case
that
you
think
about
it
further
and
they're,
like
yes,
I
like
this
idea
or
no
I
hate
this
idea,
if
you
have
an
opinion
at
all
before,
like
the
full
thing
goes
out
and
I'll
have
to
figure
out
how
to
break
this
up,
because
I
I
would
ideally
like
to
separate
like
this.
A
A
A
A
A
When
writing
this
I
tried
I
was
coming
from
the
perspective
of
like
how
can
I
summarize
what
the
point
of
each
level
was
and
I
think
the
point
of
level.
One
is
that
you
just
have
provenance
and
you
check
provenance
and
the
build
script
piece
kind
of
felt
foreign
I
couldn't
really
explain
why
it
existed
or
what
benefit
it's
adding
to
that
level,
and
so
I
thought.
A
Is
it
really
buying
us
anything
if
we
chop
it
out
so
that
way,
it's
it's
not
listed
as
a
requirement
here.
It
effectively
gets
required
at
the
next
level
because
any
sort
of
automated
system
you
have
to
give
it
the
commands
to
automate
and
so
at
level
one
if
the
Providence
describes,
if
we're
saying
it
has
to
say
how
it
was
built.
A
E
E
A
E
Both
right,
so
what
was
the
purpose
of
having
a
scripted
a
script,
build
script
inside
to
build
process
I
understand
it.
Why?
But
try
to
understand
yeah.
A
E
A
Yeah
I
I,
so
the
the
original
Genesis
of
this
was
that
we
started.
Actually
we
didn't
have
a
level
one.
We
just
started
but
level
two
was
the
original
level
one
and
we
thought
that
you
know
in
in
the
very
early
reviews
like
that
was
too
big
of
a
jump
to
go
straight
to
level
two
like
make.
People
go
to
build
service
and
that
generating
provenance
would
be
a
good
first
step,
because
it's
like
low
barrier
to
entry.
A
We
want
to
make
it
as
low
barrier
as
possible
and
again
my
memory
is
probably
incomplete
here.
I
think
it
was.
This
was
added
one
as
like:
a
stepping
stone
toward
making
a
build
service.
Thinking
that
like
well
you're
gonna
have
to
do
these
steps
anyway,
and
we
could
kind
of
like
have
part
of
the
way
there
as
like
part
of
the
level
system
and
two.
So
that
way,
the
thing
that's
listed
in
the
provenance
is
like
run
make
as
opposed
to
run.
Gcc
on
this
file
then
run
GCC
then
run
LD.
A
Then
like
tar
up.
This
thing
then
run
this
said
script
and
blah
blah
blah,
and
if
you
have
some
big
complicated
thing
in
the
provenance
saying
like
here's,
where
the
actions
that
were
run
when
you
verify
it
Downstream
it's
hard
to
say
like
whether
that
was
correct
or
not
and
like.
If
someone
either
made
a
mistake
or
they
slip,
some
malicious
command
in
there,
like
Downstream
systems,
have
no
way
to
verify.
E
Got
understood
so
so
what
I?
What
we
have
that
I
can
suggest
is
we
have
a
what
we
call
a
blueprint
so
building
and
understanding
the
blueprint
at
every
run
count
for
every
time
you
build
something:
that's
what
we
call
it
and
for
every
blueprint
it
spits
out
every
single
step
of
the
build
process,
and
that
could
include
a
script
that
could
include
a
service.
A
So
that
would
be
if
we
kept
it
right.
Are
you
saying
covert.
E
Yeah
I
mean
that
would
be
a
a
pre,
a
pre-step
right
from
the
previous
level
that
we
somehow
the
user
collects.
The
metadata
like
we
said
evidence,
not
evidence,
I'd
call
it
I'd
call
it
a
scope.
My
suggestion
would
be
a
scope
because
then
you're
I
don't
know
again.
I
don't
want
to
get
hung
up
on
the
terms
here,
but
some
sort
of
way
of
you
collecting
that
data.
F
Yes,
thank
you.
I
do
agree
of
keeping
it
because
I
actually
worked
for
the
the
slackboard
Distribution
on
the
wrist
five
port,
and
something
very
important
about
slackware
is
that
we
don't
have
a
build
system
itself,
so
there
is
no
way
that
slackware
is
going
to
pass
through
a
level
two.
So
having
this
build
script
in
the
in
the
level,
one
is
actually
a
good
idea,
because
slapper
only
uses
something
called
the
slack
build
Scripts.
F
So
if
we,
if
we
actually
try
to
make
slapper
SLA
compliant,
it
would
actually
have
to
jump
from
level
one
strict
to
level
three
for
this.
Thank
you.
C
So
my
main
concerns
are
mostly
have
been
around
if
you,
if
you
reach
out
to
the
community,
there's
a
lot
of
folks
who
are
kind
of
confused
between
the
difference
of
scripted,
build
versus,
build
this
code
and
then
a
little
bit
of
the
the
the
sort
of
like
how
build
surface
comes
in
and
I
I'm,
not
100,
sure
keep
it
versus,
don't
keep
it
I
I
do
think
we
probably
want
to
maybe
take
a
step
back
and
just
say
what
what
are
the
the
goals
here
and
to
be
clear,
I
think
you
did
a
pretty
good
job,
at
least
highlighting
some
of
the
problems,
but
I
think
that
there
still
is
value
in
making
making
sense
of
the
difference
between
somebody
running
command
arbitrarily
to
make
a
to
run
a
build
versus
the
build
itself
versus
the
build
service.
C
So
something
like
the
thing
that
is
triggering
the
build,
and
there
is
some
minutia
there
that
I
think
is
worth
at
least
making
sure
it's
clear
to
folks
right,
which
is
you
know
what
is
the
responsibility
of
the
build
service,
because
certain
folks
maybe
consider
that
something
like
see
it
just
like
Ci.
You
know
where
oh
actually
I'm
running
multiple
compilation,
actions
and
tying
a
bunch
of
different
pieces
all
into
some
package
which
potentially
contains
multiple
Downstream,
build.
Scripts,
sorry
build
this
code,
scripts
and
I.
C
Think
kind
of
like
highlighting
whether
or
not
we
care
or
or
making
it
clear
that
we
don't
care
about.
That
I
think
is
still
important
right,
because
a
lot
of
folks
are
going
to
ask
the
question
of:
should
I
have
a
salsa
attestation
per
component
or
per
distributable
artifact,
or
does
it
matter
and
I?
Think
the
the
the
scripted
build
helped
out
there
a
little
bit,
but
I
think
it
was
still
a
little
unclear.
A
Is
that
the
you
ident
with
Builders
code
I,
you
identify
where
those
things
came
from
So
like
for,
for
example,
if
in
Google
Cloud
build,
for
example,
which
is
the
build
service,
you
can
either
upload
the
the
client
can
parse
your
yaml
file
on
your
local
machine
and
send
it
to
the
service
with,
like
all
the
commands,
basically
inlined
in
the
request,
effectively
I
think
it
gets
uploaded
to
somewhere.
A
So
something
like
that
and
the
build
service
says
I
was
given
these
commands
and
I
ran
them,
but
you
don't
know
like
what
can
you
know
what
source
and
what
commit
those
things
actually
came
from
or
if
they
were
modified
from
what
was
actually
checked
in,
whereas
with
at
level
three
in
the
current
requirements
as
I
understand
it,
the
idea
would
be
that
you
could
actually
tie
that
back
and
say
effectively.
E
Yeah
yeah,
I,
think
I.
Think
I
think
you
said
what
I
was
gonna.
What
I
was
gonna
ask
is:
do
we
want
to
identify
the
build
step
that
ran
in
someone's
like
workstation
versus
someone
like
you
said
earlier,
like
you
submitted
these
steps
to
some
build
process
and
that
build
process
looks
at
it
and
that
build
process
could
be
anything
right,
I
think
somebody
earlier
I
think
Alvaro
mentioned
he.
Doesn't
they
don't
have
a
build
service?
So
how
do
they
track
that?
F
Yeah,
so
in
a
distribution
like
slacker,
it's
kind
of
like
a
legacy
thing,
because
let's
remember
that
slacker
was
actually
the
second
Linux
distribution
that
existed
and
I
think
it's
the
first
distribution
to
actually
have
build
a
script
to
to
create
the
packages.
So
since
that
time
packages
have
been
built
by
by
Patrick
volkerty,
which
is
the
the
main
developer
in
the
distribution,
so
we
all
from
from
the
slacker
team.
We
all
try
to
replicate
this,
the
the
building
of
the
packages
by
hand
and
yeah.
F
It's
something
that
completely
gets
done
by
hand,
there's
actually
no
build
system,
there's
no
build,
there's
no
build
damages.
We
don't
really
do
anything,
that's
replicable,
but
we
actually
try
to
replicate
it
ourselves.
So
it's
it's
something
that
it's
really
Legacy
so
and
because
it's
very
it's
a
very
small
project,
Patrick
actually
does
the
most
of
the
stuff.
F
I,
don't
really
see
a
future
where
a
build
system
gets
implemented,
but
we're
kind
of
slowly
working
to
it.
So
you
know
it
might
happen
in
the
future.
Let's
see
what
happens.
C
So
and
Mark
and
others
correct
me
if
you
think
I'm
wrong.
It
sounds
to
me
that
the
the
goal
here
of
some
of
these
things
is
is
the
repeatability
component.
It's
the
hey.
C
If
I
have
a
build
script
and
I
run
that
build
script
locally,
if
I
run
that
build
script
and
give
it
some
inputs,
it
does
a
thing
right,
and
the
idea
here
as
well
is,
if
I
have
a
build
service,
that's
running
the
build
it
might
be,
generating
those
inputs
to
the
build
scripts
and
running
those
things,
and
the
idea
should
be.
There
needs
to
be
or
sorry
at
higher
levels.
At
least
there
needs
to
be
some
way
of
tying
it
back.
C
So,
if
so
that,
if
somebody
wants
to
know
what
were
the
actual
inputs
to
the
build
script,
you
know
whatever,
even
if
some
of
that
stuff
is
generated,
what
were
the
inputs
to
then
generate?
That
thing,
I,
think
is,
is
really
valuable
there,
so
that
somebody
who
is
going
in
and
trying
to
repeat
a
build,
you
know,
can
go
back
and
and
run
it
against
the
same
set
of
inputs,
and
the
same
thing
goes
at
some
level
to
the
build
service
right.
C
If
the
build
service
goes
and
says,
hey
I
was
triggered
with
pull
this
code
from
this
git
repo
spin
up
this
container
and
then
in
that
container
trigger
this
make
file
right.
Having
that
information
is
super
valuable,
but
I.
Also
don't
that's
where
I
think
it
still
is
confusing
to
me.
If
the
distinction
between
what
actions
are
happening
at
the
build
service
versus
what
actions
are
happening
in
something
like
a
make
file
or
a
build.sh,
that's
where
that
distinction
is,
is
really
still
unclear.
A
Yeah
I
think
I,
like
the
the
focus
on
on
repeatability
I,
wonder
you
know
tying
it
back
to
the
the
previous
topic
around
expectations.
A
What
do
you
think
about,
like
the
scripted
build
I,
think
maybe
the
purpose
that
we're
trying
to
get
at
is
we're
defining
an
expectation
of
how
the
thing
should
actually
be
built
that,
like
you,
for
example,
you
run
make
or
you
run
this
command
or
you
run
this
series
of
commands,
but
there
should
be
some
notion
of
like
what
good
looks
like
so
that
way,
other
people
can
can
do
it
and
also
you
can
you
know
that
on
any
when
you
get
provenance
for
any
individual
one,
you
could
compare
that
to
the
expectation
so
I
guess
maybe
I
I
like
to
think
about.
E
Yeah,
what
I
was
going
to
suggest
is
maybe
the
scripted
build
can
be
part
of
a
build
service
right
because
it
goes
back
to
I.
Think
Mike
mentioned
it
on
a
remark.
Yeah
Mike
about
the
repeatability
right
I
always
go
back
to
the
repeatability,
because
we
want
to
see
the
history
of
what
happened
and
who
executed.
What
not
necessarily
I
would
separate
out
the
parameter
input
as
part
of
logs
and
history
of
hey
Gilbert
submitted
these
parameters
for
this
build
on
the
script
right
versus,
saying,
hey.
E
This
script
was
included
as
part
of
the
build,
so
those
are
two
separate
things
in
my
opinion,
but
I'd
say
build
script
is
part
of
any
type
of
build
that
could
be
I'll,
call
it
a
sub
a
sub
of
of
a
build
service,
but
the
build
service.
So
so,
in
my
my
view
is
that
most
of
us
have
control
over
the
build
because
or
at
least
those
that
manage
to
build
service
itself
in
within
a
company,
but
we
don't
have
control
over.
E
Sometimes
the
source
we
don't
have
control
source
code
or
we
don't
have
control
of
libraries
coming
in
that
are
be
that
developers
use
from,
let's
say,
an
open
source
capability,
so
so
that's
kind
of
where
I'm
coming
from,
hopefully
that
that
adds
more
flavor
to
the
to
the
conversation
here.
A
A
At
level
two
and
higher
I
think
this
is
in
practice
always
going
to
be
satisfied
anyway
and
and
so
I
wonder
if,
like
you,
just
replace
this
with
expectations,
yeah
Arno.
G
G
That
seems
a
little
bit
wrong
to
me.
It
seems,
like
you
know.
The
initial
motivation
was
was
right
in
saying
you
know.
If
already
you
have
a
defined
way
of
building
you're
already
One
Step,
you
know
beyond
where
you
would
be
otherwise
and-
and
you
know,
I
I,
maybe
it's
contrary
to
what
I'm
just
saying
now,
but
you
know
to
at
the
same
time
it's
like
what
is
scripts
right,
what
qualifies
because
if
I
ever
read
me
that
tells
me
okay,
this
is
the
instruction
you
need
to
to
issue
to
build.
A
A
I
feel,
like
that's
a
good
example,
so
I
would
lean
toward
that.
The
script
is
not
actually
what
we
want,
but
rather
some
sort
of
reasonable
expectation
of
what
to
run
like
in
a
readme.
You
would
say
run
again
taking
this
like
a
C
plus
plus
example
like
run
all
these
GCC
commands
and
then
LD
and
then
tar
and
said,
and
like
you
wouldn't
do
that
you
would
put
it
in
some
sort
of
script
in
reality.
A
But
but
if
it's
just
a
single
command,
then
that
would
be
fine
and
so
I.
Think
again,
it
feels
like
setting
the
expectation
for
what
what
correct
is
Marcella.
B
Yeah
I
like
where
I
like
the
connection
to
the
expectations
because
yeah
you
said
the
build
instructions,
however,
they
are
documented,
would
be
the
expectation
for
how
the
bill
is
supposed
to
run.
B
But
that
is
only
one
facet
of
expectations
right,
because
expectations
are
also
about
how
we
should
be
verifying
the
Providence
right,
like
thinking
of
the
sort
of
policy
angle
as
well,
I'm
wondering
if
it
would
make
sense
to
almost
and
and
I
think
you
maybe
already
wrote
that
down
about
sort
of
build
instructions
versus
verification
instructions
or
something
like
this
and
sort
of
separate
out
those
two
requirements,
and
maybe
this
gets
a
little
bit
too
low
into
the
how
this
would
actually
be
expressed
in
the
provenance
metadata
itself.
B
But
it
seems,
like
part
of
part
of
the
requirement
for
build.
Instructions
is
to
have
it
documented
somewhere,
whether
that's
a
readme
or
whether
that's
a
make
file
requiring
to
the
requirement
should
be
to
point
to
wherever
that
is
documented,
I'm
suggesting
wherever
the
instructions
are
documented,
because
I
know
in
Toto,
for
example,
you
can
sort
of
Define
your
layout
as
well
or
Define.
A
Yeah,
the
so
I
would
go
so
far
as
to
say
that
like
well
I
think
it
might
be
like
a
light
in
total
layout.
Yes,
that
would
be,
in
my
opinion,
certainly
satisfy
this
pointing
to
a
readme.
So
my
concern
would
be
like
that
it
should
be
machine,
verifiable.
B
A
That
we
make
sure
that
the
look
at
level
one
we're
not
trying
to
prevent
tampering
or
anyone
lying
assuming
that
the
tools
are
doing
things
correctly
and
Faithfully,
that
if
someone
builds
from
the
wrong
command
or
the
wrong
script,
that
that
should
be
caught,
and
so
simply
saying,
like
I
ran
this
stuff
into
read,
me
would
be
insufficient
unless
there's
something
that
actually
parses
the
readme
and
runs
those
commands
which
I'm,
assuming
probably
would
not
exist.
A
I,
don't
know
well,
I,
guess
I,
don't
know
so
another.
This
is
now
kind
of
coming
into
like
what
is
the
policy
and
how
do
you
implement
the
policy
and
I
I
would
in
my
mind
you
could
have
an
explicit
policy
like
an
in
total
layout
saying
we,
you
know
the
powers
that
be
had
declared,
that
this
is
what
good
looks
like,
and
this
is
what
the
expectations
are.
A
I
don't
know
how
necessarily
that
would
work
in
open
source
in
like
first
party
closed
Source
like
that
I
think
is
a
lot
more
clear
because
there's
like
a
hierarchy,
look
at,
for
example,
that's
what
we
do
at
Google,
but
I
think
another
model
would
be
that
an
implicit
like
a
change
on
Trust
on
first
use
like
so.
If
the
expectation
is
you
know,
all
the
previous
versions
were
built.
This
way
then
effectively
you're
setting
the
expectation
that
future
versions
will
be
built.
C
Yeah
so
I
think
yeah,
that's
starting
to
make
sense,
I
think
the
the
main
things.
From
my
perspective,
this
is
probably
a
requirement.
A
stricter
requirement,
as
we
get
up
to
a
higher
level,
is
sort
of
like
parsing
it
all
out
for.
C
C
Is
that
you
can
you
would
you
know
at
least
all
the
information
you
need
to
to
rerun
a
build
and
then
that
information
should
be
complete
where
the
inputs
are
reproducible,
as
in
like
you,
have
the
hashes
of
everything
that
went
in
and
yada
yada
yada
and
there's
other
like
temporal
metadata
that
might
mess
stuff
up
there,
because,
like
ideally
right
even
from
even
if
you
know
that
the
binary
is
not
reproducible
bit
for
bit.
C
If
you
have
the
same
inputs,
you're
able
to
run
the
build,
you
get
two
different
binary
outputs,
but
you
can
run
tests
and
scans
against
those
two
things
and
you're
like
yep,
largely
they
seem
to
have
created
the
same
outputs,
I
trust.
Those
two
build
systems,
I
think
is
one
of
the
key
goals
here
and
so
the
other.
The
other
thing
that
I
think
you
know
complicates
the
matter,
but
we
probably
don't
need
to
include
at
a
lower
level
is
at
the
higher
level.
C
We
should
make
sure
that
it
is
a
requirement
that
that
the
input
should
be
reproducible
like
you
should
be
able
to
capture
literally
and
that
I
know
at
level.
Four
and
I
know
we're
not
pushing
for
level
four
right
now,
but
it's
that
sort
of
dependencies
complete
sources,
you
know
sources
included,
sort
of
thing
is
you
can
go
in
and
say
great
here
is
literally
the
hash
of
everything
I
included,
even
if
those
hashes
are
no
longer
available
at
least
I
know
what
was
there
if
I
need
to
go
back.
A
Okay,
so
I
think
I
I
have
enough
from
this
conversation
that
we
want
something
for
this
requirement
and
it
May
it's
worth
considering
something
around
like
expectations,
slash
policy
and
also
like
how
you
verify
it,
and
so
I
I
feel
like
the
next
step.
I'll
try
to
recapture
capture
what
we
discussed
here
and
put
it
on
the
bug
or
the
issue
and
I
feel
like
the
next
step
would
be
to
actually
write
it
up
as
a
pull
request
and
see
what
it
looks
like
and
see.
A
If
we
we
like
the
wording,
because
you
know
in.
A
A
We
only
have
a
few
minutes
left
is
there?
Are
there
any
other
topics
that
folks
want
to
discuss?
If
not,
we
could
just
cut
off
early.
A
Coming
once
going
twice:
okay,
I
say
we
we
stop
here
thanks
everyone.
This
was
super
helpful
and
again
I
I'll,
try
to
break
up
the
change
into
reviewable
pieces
and
send
it
out
sometime
this
week,
thanks.