►
From YouTube: SLSA Specifications Meeting (March 20, 2023)
Description
Meeting notes: https://docs.google.com/document/d/1kMP62o3KI0IqjPRSNtUqADodBqpEL_wlL1PEOsl6u20/edit#heading=h.yfiy9b23vayj
B
D
A
B
B
One
thing
I've
been
wondering
is:
should
we
have
another
release
candidate
before
we
mark
it?
As
final
I,
we've
had
like
a
lot
of
changes
since
the
original
release,
candidate
they've,
pretty
much
been
editorial
changes
I,
don't
think
we're
changing
a
ton
in
terms
of
like
this,
the
meaning
of
the
levels,
but
there's
like
quite
a
lot
of
text
and
a
lot
of
you
know,
new
explanation
terms
have
changed
and
so
I
was
wondering
like.
B
Would
it
be
good
to
have
another
well-defined
release
candidate
with
like
a
two-week
comment
period,
and
during
that
comment
period
we
just
don't
intend
to
make
any
more
changes.
Unlike
this
past
comment
period,
and
then
you
know
address
any
like
bug,
fixes
or
typos
or
whatever,
but
then
the
markets
table
then
on.
G
A
I'm,
the
next
yeah
Chris
I
think
that's
a
good
point
right,
just
like
having
it
scheduled,
just
kind
of
having
that
that
extra
just
little
bump,
maybe
like
you,
said,
Mark
one
more
review
before
we
do
the
one
but
then
having
a
scheduled
1.1
on
the
book
so
that
we
don't
have
to
keep
extending
per
se
I.
Think
it's
a
good
idea.
H
I
So
I
think
we
ought
to
have
a
second
candidate
release,
and
so
you
know,
Mark
and
I
actually
worked
on
something.
Maybe
that
not
everybody
has
realized,
but
we
had
to
align
the
spec
stages
that
we
had
defined.
Thankfully
they
were
really
not
too
far
from
it,
but
to
the
what's
in
the
community
specification
license
framework
that
we
use
that
governs
this
work.
Brian
belendov
actually
pointed
that
out
to
me
he
said:
are
you
guys
following
this
and
I
was
like?
Oh
wait?
Let
me
check
and
I
realized.
I
It
wasn't
exactly
the
right
wording,
so
we
kind
of
reshaped
everything.
Thankfully
you
know
as
the
same
number
of
stages.
They
actually
mean
the
same,
but
there
is
an
important
aspect
to
it,
which
is
you
know
it's
related
to
licensing
commitments
that
people
make
when
they
contribute
to
the
specification,
and
so
it
does
call
for
us
to
make
it
clear
that
when
we
go
when
we
go
to
to
when
we
publish
a
candidate
for
Approved
specification,
a
proof
specification
being
the
last
stage
which
we
used
to
call
stable,
that's
the
biggest
change.
I
You
know
we
have
to
clearly
highlight
this
is
an
important
step
because,
from
a
legal
point
of
view
they
are
I'm,
not
a
lawyer,
so
I
don't
want
to
advise
you
on
what
exactly
it
means.
I
suggest
you
get
your
lawyer
to
read
it.
If
you
care
and
inform
you,
but
essentially
there's
some.
You
know
boundaries.
There
are
some
deadlines
as
to
you
know,
if
you
want
to
exclude
some
intellectual
property,
you
might
have
related
to
your
contributions
and
to
the
specification
that's
going
to
be
approved.
I
So
we
didn't
really
do
that,
because
we're
not
completely
on
board
with
what
you
know
we
should
have
been
done
so
for
that
purpose
alone.
I
think
we
ought
to
do
it
and
make
it
clear.
So
we
don't
have
any
problem
down
the
line
and
also
I
think
you
know,
there's
been
tremendous
changes
made
to
the
spec.
A
lot
of
them
can
probably
be
labeled
as
a
tutorial,
but
clearly
not
everything
so
I
think
for
that
purpose
we
ought
to
have
another
release
and
so
from
the
communication,
Community
specification
process
point
of
view.
I
C
Yeah,
so
I
just
wanted
to
to
say
that
I,
don't
think
that
we
need
to
make
it
longer
than
two
weeks,
because
I
assume
that
most
people
who
were
engaged
in
providing
feedback
for
their
first
release
candidate,
we're
probably
going
to
be
continued
or
hopefully,
they're
continued
to
be
engaged
in
the
issues
and
so
I
think,
especially
with
the
with
the
recent
change
that
was
pushed
where
you
can
actually
view
the
entire
table
of
contents.
From
the
from
the
perspective
of
the
different
versions.
C
J
J
What's
changed
that
said,
I
I
think
that
I
I
Mark
I
agree
with
you
that
we
want
to
put
out
one
that
we
don't
expect
more
changes
on
I,
don't
know
how
many
changes
that
we've
received
already
it's
possible
that
there'll
be
a
whole
bunch
of
folks
showing
up
with
changes
on
the
very
last
deadline
day
which
case
oh
man,
we're
gonna
have
to
review.
It's
also
possible,
though,
that
you
know
people
who
are
interested
are
already
involved.
J
Most
of
them
have
already
said
they're
peace,
so
we
we
may
have
to
make
a
decision
once
we
what's
the
deadlines
passed,
but
I
would
say
as
soon
as
we
can
resolve
all
comments
put
in
by
the
deadline
then
put
out
a
two-week
ver
then
put
it
out.
I
think
two
weeks
is
is
fine,
especially
since
people
have
been
given
a
heads
up,
but
I
do
think.
Another
round
makes
sense
and
I
know
I
think
more
than
two
weeks.
J
You
don't
need
this
time,
though
I
think
we
ought
to
coordinate
with
Jennifer
Bligh
and
basically
just
we.
It
was
kind
of
a
lesson.
Oh
wait:
should
we
put
a
blog
post
on
it?
I,
don't
think,
there's
a
legal
requirement,
but
I
think
that
from
a
you
know,
hey.
We
are
honestly
doing
our
best
to
make
people
aware
to
review
this.
That's
about
to
go
out
the
door.
I
think
that's
important,
so
why
you
know
I
mean
we.
J
K
So
yeah
I,
my
question
I
think,
is-
is
more
on
the
the
The
Meta
end
of
like
Okay.
So
let's
assume,
okay
based
on
some
of
the
stuff.
We
were
talking
about
last
week,
a
little
bit
about
versioning
and
assuming
let's
say
we
do
something
like
hey
we're
gonna
do
quarterly
releases.
Does
that
also
include
stuff
like
what
we
might
consider,
something
that
you
know,
a
bug
that
wasn't
caught
or
or
a
typo
fix
or
or
whatever
I'm
just
curious?
K
I
E
B
E
B
B
A
B
J
J
C
A
J
I
B
B
B
Although
the
project
board
doesn't
look
that
way
to
resolving
a
lot
of
the
things,
should
we
shoot
for
like
have
all
the
changes
submitted
by
end
of
next
week,
and
then
we
can
make
a
decision
for
if
that's
ready
or
if
we
need
more
time,
I,
don't
know
what
the
process
I've
not
worked
in
Open
Source
before
so
I,
don't
know
like
or
on
any
sort
of
specifications
like
this
I.
Don't
know
like
what
is
a
good
idea
for
keeping
things
on
track.
K
I
can
just
provide
my
perspective
of
the
past
several
years
of
doing
I,
I
think
at
a
certain
point
you
just
kind
of
have
to
call
it
and
because
you
know
the
thing
about
open
source
rate
is,
is
since
we're
all
volunteers
here
and
we're
all
working
under
sort
of
a
very
flexible
sort
of
code
of
conduct
and
whatever
like
as
long
as
somebody's,
not
outwardly
trying
to
sabotage
something.
You
know
we
could
keep,
we
could
keep
going
and
and
in
perpetuity.
K
B
We've
talked
about
this
a
bunch
before
but
like
air,
on
the
side
of
let's
get
something
and
I
know
I'm
I'm,
worse,
get
something,
that's
good
enough
and
submit
it
and
then
so
we
have
something
in
there
and
then
we
could
always
have
further
pull
requests,
but
we,
you
know,
have
a
tendency
to
leave
pull
requests
open
for
weeks.
It'll
be
good
if
we
could
try
to
close
the
loop
faster,
especially
if
we
only
have
you
know.
A
C
I
B
description
across
also
page.
We
just
mentioned
format,
selector,
that's
a
pretty
minor
thing,
I,
don't
think.
That's
a
blocker,
though,
do
that
independently,
the
combined
ephemeral
and
isolated
700
is
going
to
active
comments
and
rewrite
understanding.
Sausage
was
just
opened,
so
I
think
the
rest
of
them
are
either
like
Dale
or
not
particularly
urgent.
A
D
B
B
J
E
B
I
I
B
B
H
C
If
we
had
any
questions
now,
we
don't
have
to
address
it
immediately,
but
I
I
didn't
want
I
wanted
to
know
if,
as
part
of
the
ephemeral
and
isolated
conversations
that
are
happening,
I
feel
like
what
I'm
trying
to
different
differentiate
on
is
between
level
three
and
level.
Four
isolated
and
I
didn't
want
to
know
or
I
I
wanted
to
know
how
specific
in
the
future
directions.
C
A
B
In
the
chat
too,
this
this
in
the
background
here,
this
ephemeral,
isolated,
is
the
topic
of
many
of
the
comments
we've
had
in
the
past,
and
so
I
think
this
is
really
valuable
to
to
resolve
the
especially
if
you
could
comment
on
the
pull
request.
I
think
there's
like
getting
the
wording
right
I
think
is
pretty
tricky
what
we
did
to
recap,
what
we
discussed
Andrew
and
I
on
the
thread.
It
seems
like
we're
kind
of
zeroing
in
on
the
requirements
for
level.
B
B
But
if
the
users
open
up,
you
know
like
a
port
like
with
SSH
or
something
on
it,
for
example,
which
would
allow
a
remote
user
to
just
kind
of
run
arbitrary
commands
that
that
is
not
something
that
has
to
be
blocked
by
level
three,
but
maybe
a
future
version
would
and
so
like.
How
do
we
clearly
Express
that
that,
like
the
Builder,
has
a
requirement
to
like
be
to
some
amount
of
secure,
but
they
don't
have
to
like
block
everything?
Is
it
does
that
capture
danger?
C
In
order
to
achieve
that
best
effort.
And
then
it's
not
until
you
go
to
level
four
where
you
can
hopefully
achieve
maybe
a
little
bit
better
than
best
effort.
Once
you
start
having
further
requirements
on
the
build
system
and
on
the
user
to
prevent
the
like
network
access
whatnot
that
you
can
be
reasonably
confident
that
everything
that
is
contained
in
the
references
for
the
builds
is
actually
all
that's
needed
to
produce.
The
artifact.
E
G
B
B
B
I'm,
not
sure
Andrew
agrees
with
me
like
if
you,
if
you
just
use
the
service
by
default
in
like
the
normal
way,
you
will
have
isolation
between
bills
and
the
providences,
particularly
like
the
external
parameters
list,
will
be
accurate
and
complete.
And
if
someone
were
to
rerun
that
build
with
those
same
external
parameters,
they'll
get
the
same
room
results,
maybe
not
bit
for
a
bit
identical,
because
maybe
it's
not
reproducible
but
like
logically
they'll
kind
of
get
the
same
thing,
but
a
build.
That
kind
of
does
kind
of
violates
the.
F
B
You
know
open
up
open
up
a
port
that
allows
like
some
something
else,
to
connect
and
run
arbitrary
commands
or
might
Farm
out
the
execution
to
another
service.
That's
not
part
of
the
Builder
and
there's
no
requirement
for
the
build
service
to
like
block
that
from
happening,
because
doing
that
sort
of
blocking
would
be
it.
C
C
G
C
Right
and
I
I
think
I
I
tried
to
make
that
clearer
with
an
earlier
PR,
where
the
action
for
the
producer
to
achieve
level
three
is
really
just
to
onboard
to
a
level
three
compliant
build
system,
and
so
it
is
intentionally
the
the
first
is
to
kind
of
Drive
adoption
towards
these
systems,
which
have
it
in
mind
to
try
and
Harden
themselves
and
then
only
once
they
they
get
into
those
Avenues
of
these
hardened
systems.
Can
they
then
explore
the
possibility
of
trying
to
further
Harden
against
these
attack
vectors.
G
I
C
Fine,
so
I
in
in
my
head,
I
was
I
was
describing
it
as
the
maximum.
Now
so
I
I
wasn't
I
haven't
been
focused
on
anything
other
than
level.
Three,
so
I
didn't
see
what
the
intricacies
are,
but
in
order
to
to
achieve
the
maximum
now
all
you
have
to
do
basically
is
to
start
using
some
compliance
system.
C
G
K
Let's
say
a
key,
and
so
the
idea
there
right
is
is
you
know
you
could
still
end
up
with
a
situation
where,
based
on
how
you've
set
up
tecton
and
tecton
chains,
even
though
it
could
do
level
two,
your
job
doesn't
provide
a
key,
so
it
doesn't
actually
sign
it
with.
So
it
doesn't
make
it
salsa
level.
Two,
it's
also
level
one.
So
there's
some
stuff
there
is
well
beyond
just
sort
of
like
the
hey.
These
are
things
you
actually
need
to
make
part
of
your.
K
I
think
that
there's
also
separately
I
think
that
one
of
the
things
I
think
would
be
really
useful
is,
is
really
kind
of
focusing
a
little
bit
more
on
the
the
like.
What
are
the
actual
attack
vectors
so
that
we
can
then
kind
of
transform
that
into
sort
of
the
the
levels
there,
because,
like
I,
think
one
of
the
the
things
that's
a
little
unclear
to
me
is
like
what
is
let's
say,
the
attack
Vector
that
salsa
level
2
would
protect
against
versus
level.
Three
and
I.
K
Think
I
have
like
I,
have
some
thoughts
around
it,
but
I
think
that
sort
of
thing
is
is
I,
don't
want
to
say
that
this
is
the
case
exactly,
but
like
one
of
the
things
that's
confusing
me
is
is
unclear
exactly
like
is
the
requirements
we're
adding
in
to
say:
hey,
here's
the
attack
vector-
and
this
is
what
we're
trying
to
prevent.
So
these
are
the
new
requirements
or
are
the
requirements
just
kind
of
there
and
saying
like
hey?
What
are
the?
What
are
the
attack
vectors?
K
C
This
ephemeral,
isolated
PR
explaining
explain
that
you
must
Define
a
security
model
for
your
build
system,
because
I
think
that
Michael
what
what
I
hear
when
you're
saying
that
is
that
we
need
to
make
sure
that
anybody
who's
developing
a
build
system
has
a
security
model
so
that
they
know
what
is
within
the
the
trust
boundary
and
what
is
not
within
the
trust
boundary,
because
not
until
you
know
where
that
line
is
where
you're
you
differentiate,
custom
versus
untrusted.
Can
you
start
to
make
those
types
of
decisions
about?
K
There
are
certain
things
like
the
reusable
workflow
and
exactly
what
GitHub
action
you're
using
and
so
on,
but
like
a
lot
of
the
stuff
around
like
you're
sort
of
largely
assuming
that
GitHub
when
it
says
Hey,
different
jobs
or
not
be
able
to,
you
know
they're
isolated,
and
they
should
not.
You
know
one
job
should
not
be
able
to
interact
with
another
job,
you're
sort
of
trusting
GitHub
on
that
I.
K
Think
that
there's
some
open
questions
about
like
yeah
and
when
sort
of
exploring
that
just
a
bit
more
generically
like
if
I
look
at,
let's
say
Jenkins
or
I.
Look
at
some
of
these
things.
It's
not
just
purely
about
the
tool.
It's
also
how
you've
configured
the
tool
and
what
sort
of
constraints
you've
also
potentially
set
up
on
the
end
users
of
that
tool.
Right,
like
Jenkins,
is
pretty
well
known
for
being
pretty
open
by
default.
But
by
placing
you
know,
the
implementer
of
that
thing
could
place
a
ton
of
restrictions
on
it.
K
J
K
I
I
think
yeah
I
think
we,
the
the
thing
there
is,
is
and
I
think
we
do
and
a
decent
job
at
the
build
system,
but
we
might
want
to
sort
of
clarify
a
bit
that
when
we
call
when
we
say
build
system
we're
not
purely
saying
Jenkins,
tecton,
GitHub
actions,
we're
saying
it's
those
things
and
we
do
have
some
things
in
there
we
just
might.
We
do
have
some
things
around,
that
the
build
system
consists
of
the
people
and
processes,
and
so
on
that
surround
it.
K
We
just
might
want
to
make
sure
that
we're
we're
given
that
there's
a
bunch
of
stuff
out
there
I
think
we
just
need
to
make
sure
that
we're
crystal
clear
that
a
lot
of
folks
assume
build
tool
here,
like
you
know,
Jenkins
tecton,
yada
yada,
it's
those
things
configured
in
the
right
ways
with
the
right
Security
in
in
mind
that
are
capable
of
that
and
I.
Think
that
sort
of
thing,
though,
is,
does
get
confusion
confusing,
because
a
lot
of
folks
are
going
to
be
evaluating
and
saying
at
what
point?
K
Is
it
like
because
any
tool
that
you
know
if
you
configure
it?
The
right
way-
and
you
add
the
right
sorts
of
plugins-
and
you
add
you
change
it
in
the
right
ways-
could
be
salsa
level.
You
know
three
compliant
but,
like
certain
tools
are
inevitably
going
to
be
like
out
of
the
box,
it's
more
or
less
salsa
compliant.
K
E
I
I
agree
on
that.
That's
in
the
end,
it's
more
the.
What
will
be
B
level
three
or
two
will
be
the
Builder
ID
rather
than
the
build
type
I
mean,
for
example,
you
can
host
githubs
or
git
Labs
on
your
own
and
they
can
be
completely
unsecure
and
you
can,
if
you
don't,
then
run
them
in
a
separate
user.
You,
you
are
broken
breaking
starts
on
some
in
some
ways,
so
yeah
it's
the
instance
of
the
the
the
Builder.
It's
not
the
Builder
framework
in
the
end.
E
B
Thanks
so
can
I
ask
folks
who
participants
conversation,
have
an
opinion
to
review
Andrew's
pull
request
so
that
way
we
could
come
up
with.
We
could
figure
out.
Basically
what
we
should
expect
should
say:
I
agree
who
think
by
the
way,
whoever's
thinking
those
I
really
really
appreciate,
you're
doing
a
great
job.
So
thank
you
so
much.
It
doesn't
say
who
it
is.
On
my
screen
at
least.
B
You
Nicole,
the
like
the
self-hosted
versus
you
know
centrally
hosted
I
I
feel
like
I
agree
is,
is
a
big
thing
that
comes
up
a
lot
and
people
want
to
know
and
they
feel
like.
We
should
answer
that.
So
if
you
could
comment
on
the
pull
request
and
get
you
know,
we
could
come
and
do
it
there
I
think
that
would
be
great.
I
Yeah
so
expectations,
actually,
so
it
Bears
on
pull
request.
Is
it
675
so
the
way
the
one
zero
or
C1
has
it?
Is
it
says
that
expectations
are
set
of
constraints
on
the
packages
probed
on
submitted
data
that
the
package
producer
sets
and
the
proposal
I
mean
the
the
if
PR
675
were
to
be
merged,
as
is
it
actually
changes
this?
To
saying
that
you
know
the
it's
the
provenance
verifier
that
sets
the
expectation
and
I
think
that's
a
major
change
that
we
need
to
really
nail
down
and
I
think
it
has
to.
I
It
comes
from
a
bit
of
a
confusion,
I
think
the
the
intent
is
that
you
know
it's
understood
that
at
the
end
of
the
day,
the
verifier
is
in
control.
They
can
set
their
own
policies,
they
can
Define.
You
know
what
they
are
going
to
rely
on
to
do
the
verification
and-
and
so
from
that
point
of
view
they
can
override
whatever
comes
from
the
the
package
producer
anyway,
but
I
think
the
initial
intent
was
to
say:
well,
there
is
some
kind
of
default
expectations
that
are
being
defined
by
the
package
producer.
I
But
so
the
the
this
is
a
bit
different
from
what
and
and
where,
and
the
pull
request,
as
I
pointed
out
in
the
comments
is,
is
not
very
consistent
because
in
some
places
it
basically
says
is
that
and
I
have
to
give
Josh
credit.
He
is
the
one
who
who
defined
it
in
the
the
way.
I
just
said
it,
which
is
the
producer,
sets
default
expectations
and
the
fire
can
use
those
and
may
override
them
as
they
want.
I
G
Yeah
so
I
I
agree
with
the
framing
of
setting
expectations
and
setting
a
verification
policy.
Actually
I
hadn't
heard
that
from
Josh
I
had
a
talk
with
Kara
with
with
Care
at
the
end
of
last
week.
She
brought
that
up
to
me,
I'm
yeah,
I'm,
happy
with
that
split.
My
my
main
concern
or
I
had
two
main
concerns.
G
I
So
I
I
think
we
we
need
to
confirm
the
model
right
once
we
have
the
model
we
all
agree.
This
is
what
we
want
to
say.
We
can
work
on
the
detail,
but
beyond
the
text
and
I'm
happy
to
review
again
some
changes,
but
so
I
want
to
know
if
anybody
disagree
with
the
model
I
laid
out,
which
is
actually
by
the
way,
it's
in
a
comment
from
Joshua
further
down
in
the
pull
request,
go
ahead.
F
I
I
So
we
are
not
claiming
to
change
that.
We
cannot
constrain
with
the
verifier
trust
and
text
into
account,
but
the
question
is
whether
their
expectations
that
are
set
by
the
producers
that
are
and
and
what
role
you
know
this
has
so
I
like
the
model
that
Joshua
laid
out,
which
is
basically
the
consumer,
can
take
a
slash.
Verifier
can
take
that
as
the
default,
but
it's
you
know
all
of
the
input
they
get.
G
F
B
A
little
bit
worry
that
we
are
using
expectations
like
jargon,
to
mean
a
particular
concept,
but
that
concept
is
not
fully
fleshed
out
because
like
if
we
we're
just
talking
like
kind
of
real
world
terms,
I
think
that
basically,
the
way
it
works
is
that
the
producer
has
to
build
in
some
way
and
like
it,
maybe
using
passive
voice.
Because
it's
a
little
bit
easier
here
like
it
must.
B
It
must
be
knowable
what,
for
example,
Source
repo.
This
thing
is
supposed
to
come
from,
like
when
you
say
the
underscore
JS
package.
There
needs
to
be
like
a
proper
thing
to
compare
it
against.
Right,
like
there
is
some
sort
of
official,
Upstream
and
I
guess
we
could
talk
about
in
the
spec
of
like
who
decides
what
the
official
one
is.
B
But
I
would
imagine
in
most
cases
when
you
like,
when
you,
when
I
use
underscore.js
like
I
I,
don't
know
I'm,
gonna,
I'm
gonna
use
some
sort
of
process
to
figure
that
out,
and
maybe
it's
like
I
do
a
search
and
like
that's
the
first
one
and
I
say:
okay,
that's
good
enough
or
there's
metadata
in
the
in
npm.
That
says
that
that's
what
it's
supposed
to
be
but
I
think
that's.
B
Basically
what
we're
trying
to
say
is
that,
like
you
can
know
what
the
thing
is
supposed
to
be
built
from
and
I
think
what
we're
maybe
running
into
is
that
like
in
reality,
it's
messy
and
I
I
worry
that
we,
if
we
say
the
package
producer,
does
this
or
the
ecosystem?
Does
this
or
the
consumer?
Does
this
I
wonder
if
a
little
bit
more
vagueness
would
actually
be
useful,
yeah,
Michael.
K
K
Think,
inevitably,
a
lot
of
it
is
going
to
be
an
agreement
between
the
producer
and
verifier
right
and
I
like
when
I
think
about
it
right,
I,
think
about
hey.
If
I
you
know,
I've
worked
at
companies
large
and
small
and
I
think
the
thing
is
like
large
companies
are
going
to
say:
hey,
they
want
to
make
sure
a
bunch
of
stuff
from
at
least
like
the
people,
they're
actually
buying
from
right,
they're
going
to
say.
K
Well,
we
expect
this
stuff
is
going
to
be
in
your
salsa
metadata,
because
it's
not
just
like
I
think
salsa,
mostly
has
been
focused
around
guaranteeing
that
the
Providence
is,
is
a
tamper,
evident
or
tamper
proof,
but
I
think
different
companies
are
going
to
say
what
information
do
I
want
in
that
provenance
and
I.
Think
what
we'll
see
is
the
consumers
right
are
going
to
say:
hey
I,
demand
that
if
I
buy
something
from
you
that
you're
going
to
include
in
your
provenance,
you
know
the
this
Source.
K
You
know
like
exactly
the
source
that
it
came
from
or
or
whatever,
or
hear
what
the
the
resolve
dependency
should.
Look
like
and
I
think
that
itself
is
is:
is
okay,
I
think
it's
going
to
be
a
little
bit
more
complicated
when
you
look
at
open
source,
because
you
know
you
can't
really
make
a
demand
of
an
open
source
provider
in
most
cases
right
like
it's
going
to
be
one,
it's
gonna
be
different.
K
I
still
think
that
you
know
generally,
the
the
build
service
right
is
more
responsible.
Just
purely
for
saying,
I
did
all
the
right
things
from
a
requirements
level
to
sign
the
stuff.
To
sort
of
show
that
tamper,
you
know
to
show
those
those
those
security
properties.
More
so
than
necessarily
saying
hey.
The
build
service
is
responsible
for
making
sure
that
the
up
you
know
I
can
fetch
the
Upstream
package
or
something
like
that.
G
F
And
someone
whose
entire
business
model
is
building
things
from
source
and
letting
open
source
people
build
things
from
Source
on
our
system
if
they
want
to
get
provenance
stuff
I,
like
that
last
paragraph,
where
we
were
saying
that
the
build
system
should
be
saying,
I
can
do
all
of
this
and
then
it's
kind
of
like
well.
You
know
not
guaranteeing
the
Upstream,
because
if
the
open
source
maintainer
tells
us
rubbish,
we're
gonna
put
the
rubbish
in
there.
You
know.
I
J
J
J
F
I'll
give
it
a
review
and
at
least
see
if
it
sounds
to
me,
like
you
know
we
get
out
of
that,
get
a
you
know
to
best
effort,
you
know,
must
be
verifiably
produced
and
signed.
So
I
can
say
exactly
what
I
did
and
who
gave
me
what
and
then
this
way
we
can
say
well,
Bob
gave
me
x,
x
is
rubbish,
but
that's
not
my
fault.
I
recorded
Bob
gave
it
to
me
and
I
made
it.
You
know
verifiable.