►
From YouTube: SLSA Specifications Meeting (March 13, 2023)
Description
Meeting notes: https://docs.google.com/document/d/1kMP62o3KI0IqjPRSNtUqADodBqpEL_wlL1PEOsl6u20/edit#heading=h.yfiy9b23vayj
A
B
Give
it
a
few
minutes
for
some
more
Forks.
D
A
Sure,
yeah
yeah,
we'll
we'll
wait
a
few
more
minutes
for
some
folks
to
join,
but
then
once
they
do,
we
usually
start
off
with
new
folks
introducing
themselves
followed
by
some
agenda
items.
The
person
who
normally
runs
this
meeting
is
is
out
of
office
for
today,
so
I'll
be
running.
The
meeting
at
least
part
of
it
might
need
to
hop
off
at
the
bottom
of
the
hour,
but
yeah
we're
right
now,
just
trying
to
go
through
and
quickly
see
what
agenda
items
should
be
on
here.
A
A
Feel
free
to
add
your
attendance
to
the
meeting
notes
as
well
as
anything
you
want
to
add
to
the
agenda.
I
know
we
don't
have
a
very
packed
agenda
today.
A
A
Oh
whoops,
all
right,
so
we
can
get
started
just
so,
just
as
a
reminder
to
folks.
This
meeting
is
being
recorded,
it'll
be
uploaded
to
YouTube
shortly
after,
and
your
participation
in
this
meeting
is
an
agreement
to
abide
by
the
open,
ssf
code
of
conduct,
all
right.
So
before
I'm,
starting
off
with
any
agenda
items,
is
there
anybody
new
who
wants
to
introduce
themselves.
H
Technically
I'm
new
Nicole
Schwartz
I've
been
creeping
on
the
notes
in
the
black
channel
for
the
past
year,
and
somebody
finally
got
me
on
the
meeting,
invite
so
hi
I'm
with
active,
State
and
not
sure
what
else
we
generally
put
in
with
the
intros
but
feel
free
to
ask.
A
Yeah
I
think
well
so
I
know
that
a
few
folks
from
active
State
over
some
time
and
I
know
some
folks
have
have
left
active
state.
But
so,
if
there's
anything,
you
wanted
to
sort
of
talk
about
with
your
work
with
salsa
or
or
you're
interested
in
the
salsa
specification
group
feel
free
to
to
talk
about
that.
H
Well,
yes,
so
far,
we
have
a
version
0.1,
because
one's
not
out
yet
available
for
any
of
our
customers
in
our
open
source
builds
So.
For
anybody
who
doesn't
know
what
we
do.
We
basically
build
worked
copies
of
well
they're,
not
parked
mirrored
copies
of
Open
Source
projects,
so
they're
built
hermetically
and
you
can
get
attestation
software
with
them.
H
We
do
keep
running
into
issues,
which
is
why
we're
trying
to
keep
involved,
because
a
lot
of
the
specs
seem
to
kind
of
miss
out
on
the
middleman
situation
like
they
clearly
cover
if
you're
the
originator
or
the
software
developer,
but
us
in
the
weird
middle
seem
to
get
missed.
So
that's
why
we're
keeping
involved
and
hopefully
we're
making
it
super
easy
for
everybody
to
get
attestations
for
their
open
source.
A
Cool
and
you
might
be
interested
in
one
of
the
agenda
items-
that's
that's!
Maybe,
at
the
the
end
there
regarding
trying
to
clarify
some
of
that
all
right.
I
know
that
Claudia,
you
began
to
introduce
yourself,
but
would
you
like
to
introduce
yourself
to
the
to
the
group.
D
Sure
I'm
Claudia
I
work
at
active
state
with
Nikki.
Actually,
so
we
both
jumped
on
today
after
finding
the
open,
ssf
calendar,
which
is
great
and
so
same
deal
plus
one
to
everything.
Nikki
said
related
to
salsa
specs
and
our
involvement
in
attestation
and
s-bomb
generation.
F
A
C
Here,
where
is
this.
F
A
So
I'm
just
gonna,
there's
there's
a
couple
of
what
I'm
going
to
call
Meta
issues
which
are
like
hey.
Should
we
be
versioning?
So
if
there's
one
issue
issue
680
and
let
me
see
if
I
can
share
my
screen
here.
A
Similarly
with
the
idea
here
being
that,
like
we
don't
want,
you
know,
do
we
want
to
have
something
where
you
have
the
five
of
the
spec
but
you're
on
V2
with
the
requirements,
and
it
could
cause
some
confusion
about
well,
if
I'm
following
the
V5
of
the
spec,
does
that
mean
I
need
to
be
on
V5
of
the
requirements
or
what
does
that
really
mean
and
I
think
the
there's
there's
some
stuff
here
around
figuring
that
out?
A
There's
some
suggestions
from
these
folks
I
think
largely
saying
we
should
be:
have
some
semantic,
versioning,
more
or
less
stay
in
lockstep,
with
allowing
for
some
minor
revisions
to
something
like
the
spec
not
requiring
a
whole
bump
to
the
version
of
the
requirements.
But
as
long
as
it's
like
a
minor
revision
folks
have
thoughts
around
this.
H
E
F
E
Agree
just
to
clarify,
though
so
like
are
you
guys,
thinking
like
we
would
have
version
one
and
version
one,
but
then,
when
we'd
update
the
provenance
specifically
like
1.1
kind
of
within
that
kind
of
idea,
yeah.
A
I
I
think
the
I
don't
think
there's
any
details
yet,
but
I
think
the
general
like
I
think
first
is
what
what
approach
should
be
taken
and
Then
followed
by
like
what
that
might
might
look
like.
Okay,.
B
So
I,
you
know
I'm
all
for
Simplicity
but
in
this
case
I'm
a
big
concern
that
we
would
be
tying
provenance
to
the
rest,
because
I
think
provenance
in
particular
is
a
you
know,
an
area
where
we
can
easily
imagine
doing
newer
versions
without
changing
anything
else
to
to
the
South
suspect.
Like
you
know,
we
have
had
discussions
about
possibly
time
provenance
to
an
s-bomb
and
that
would
change
nothing
to
salsa
and
I.
Think
versioning
salsa,
because
we're
changing
provenance,
maybe
not
the
best
I,
don't
know
I'm
a
bit
digital.
A
Yeah
I
think
the
idea
of
so
I
I
have
the
same
sort
of
concerns
and
I
think
there
might
be
some
way
we
can
sort
of
work
around
it
by
sort
of
still
tying
the
requirements
somehow
into
the
version
of
the
the
provenance
spec
right
like
where
something
like
you
know,
you
might
imagine
hey
if
there's
version
two
of
the
requirements,
maybe
regardless
of
whatever
you
do
with
the
spec,
the
spec,
it
becomes
sort
of
like
a
point
on
that
thing
of,
like
you.
A
Two
of
the
requirement,
so
anything
after
the
the
point
is
going
to
be
what
version
of
the
provenance
spec
is
tied
into
that,
so
you
could
have
like
version
2.10
of
the
provenance
back,
and
you
know
it
refers
to
version
two
of
the
requirements,
something
like
that.
I
think
the
I
I
think
we're
also
still
once
again
this.
This
issue
was
just
opened
a
few
days
ago,
so
I
don't
think
there's
any
decisions
being
made,
but
I
think
we
would
wanna
because
I
think
you
bring
up
a
a
good
point.
A
A
G
A
So
I
personally,
don't
have
much
of
an
opinion
one
way
or
the
other
outside
of
I.
Think
generally,
the
more
we
can
I
I
think
from
the
end
user
perspective.
The
thing
that
folks
want
is
they
want
to
have
it
packaged
up
as
much
as
possible,
so
they
know
like
oh
I
need
to
hit
like
salsa,
3
or
salsa
version
three
and
okay.
These
are
all
the
things
that
are
required
for
salsa
version.
Three
ATP,
this
prominent
spec
I
need
to
be
this.
A
This
and
the
other
thing
this
is
the
PSA
or
whatever,
like
I,
think
that's
sort
of
where
folks
want,
but
then
that
has
the
trade-off
of
from
a
maintainer
point
of
view
of
when
we
try
to
create
new
requirements
or
try
to
create
new
things
in
any
of
the
specs
or
we
come
up
with
something
like
the
salsa
Source
spec
right
with
something
like
the
source
of
salsa
Source
stack
require
change
it.
You
know,
I,
think
that
sort
of
stuff
is
is
yeah.
B
So
I
read
the
issue
society,
as
you
know,
being
inclusive
to
all
the
different
pieces
we
are,
which
is
indeed
which
it
would
include.
The
essay
I
don't
know,
I
mean
not
the
mind
reader
I,
don't
know
what
Mark
exactly
had
in
mind,
but
that's
the
way
I
read
it.
The
issue
erased.
It
was
like
okay,
let's
get
rid
of
all
the
different
specs
put
them
all
in
one
bundle,
and
only
have
one
versioning
for
everything
which
I
think
makes
sense.
E
Yeah
I'll
just
jump
in
yeah
for
a
half
second
I
was
thinking
of
in
a
way
where
it'd
be
three
different
versions
right
for
the
requirements
for
the
provenance
and
then
for
the
VSA,
but
yeah
I
know
you
were
I,
think
you're
onto
something
right
like
bundle
it
all
together
into
one
because
for
another
half
second
Chris,
when
you
asked
Julia
version
the
VSA
different
Well
yeah,
if
we
bump
it
up
to,
you
know
version
two,
but
we
haven't
changed
anything
into
VSA,
then
that'll
be
very
confusing,
so
bundling
them
all
together
into
one
thing.
A
So
one
idea
I
I
just
had-
and
this
is
just
I
think
something
from
this
is
something
from
that.
Maybe
we
can
take
just
generally
from
software
is
I.
Do
wonder
if
we
can
say
that
some
element
of
salsa-
let's
just
say
those
complete
package
of
salsa-
is
versioned
and
when
we
do
even
minor
releases
right
like
these
things
are
I.
Think
we
just
need
to
be
clear
about
these.
A
Things
are
what
has
changed
in
those
things
so
like,
for
example,
I
would
almost
imagine
that
the
VSA
spec
the
requirements
and
some
of
these
other
things
are
all
almost
dependencies
of
salsa
itself
like
the
full
packages
salsa,
and
so
we
might
be
able
to
still
do
something
on
that
end,
where
we
might
be
able
to
say
hey
this
is
you
know,
we've
we
made
an
update
to
the
such
and
such
you
know,
to
the
salsa,
prominent
spec,
and
so
now
we're
updating
salsa
to
this
sort
of
stage.
A
I
think
the
problem
I
think
the
problem
that
we
still
run
into
right
is
with
a
lot
of
this
stuff
is
given
that
it
is
a
a
specification
that
folks
are
intended
to
consume,
along
with
requirements
that
you
know
or
indicate.
What's
in
that
specification,
it
becomes
harder
for
the
end
user
to
then
consume
and
say
well
what
happens
if
this
person's
on
salsa
version
3.2
and
this
other
person's
on
salsa
version
3.3?
Is
there
General
compatibility
between
them?
What
are
the
real
differences?
A
B
So,
just
to
be
clear,
I
mean
you
guys
have
been
talking
about
requirements
as
if
it's
separate,
but
requirements
are
part
of
cell
suspect
right.
So
right
now,
this
is
completely
tied
to
the
suspect
version.
Well,
we
have,
as
far
as
I
can
tell
we
have
three
pieces.
We
have
salsa,
including
requirements.
We
have
provenance
and
yes,
those
three
are
three
independent
PCS.
A
Yeah
I
think
that's
right
by
that
I
mean
and
once
again,
I
think,
there's
still
confusion
tied
to
yeah.
So
by
the
spec
I
mean
the
the
Providence
format.
That's
really
what
I
I
mean,
and
maybe
we
should
call
it
the
provenance
format
as
opposed
to
the
Providence
spec
for-profit
in
format
yeah
anyway,
I.
A
Yeah,
the
Providence
yeah,
so
I,
agree
and
I
think
the
provenance
format.
Also,
there
are
certain
elements
that
are
inevitably
tied
directly
into
the
requirements
and
the
the
that
element
of
it,
and
then
there
are
certain
things
that
necessarily
aren't
and
I
think
if
we
were
to
version
them
separately.
We
would
also
need
to
make
sure
that
the
format
indicates
what
version
specifically
like.
Even
what
you
know,
what
version
of
the
requirements
you're
associated
with
as
well
and
yeah,
definitely
complicate
it.
C
H
I
mean
I,
guess
I
was
thinking
in
my
head
that
when
a
major
version
bump
happens,
there's
some
kind
of
major
breaking
change
and
so
like
everything,
the
vfa,
the
provenance
and
the
the
spec
got
bumped
to
say
version
two
or
version
three
and
then
independently.
As
long
as
it
was
an
addition
or
a
optional
and
not
anything,
breaking
that
the
individual
items
could
all
iterate
on.
You
know
minor
releases
within
that
as
much
as
they
wanted.
But
if
something
like
I
don't
know,
vfa
for
some
reason
was
going
to
make
a
a
breaking
change.
H
It
would
have
to
wait
for
the
next
major
version
or
force
a
major
version.
I
guess
how
I
was
being
it
in
my
head,
and
somebody
had
mentioned
like
having
good
release
notes
of
thing.
Like
yeah,
the
you
know,
we
bumped
off
the
vfa
to
version
3.4
and
it's
compatible
with
all
of
the
other
three
that
just
said
this
new
optional
field
or
this
new
additional
variable.
A
Yeah
I
think
that
I
agree
I
think
that's
some
some
of
the
stuff
that
you
know.
If
you
look
at
the
issue,
some
folks,
what
happened
to
my
sharing
some
some
stuff
with
that
folks
have
been
bringing
up
with
like
doing
something
like
semantic
versioning
and
also
like
I,
do
think
yeah
like
if
we
as
much
as
we
can
take
elements
from
sort
of
like
the
the
general
software
space
of
saying,
hey.
These
are
backwards,
compatible
changes.
A
These
are
backwards,
incompatible
changes,
and
these
are
the
sorts
of
things
you
can
expect
between
minor
revisions
and
making
sure
that
that's
clear
and
also
I
think
relatively
consistent
with
how
the
rest
of
the
world
tends
to
handle
these
things
which
I
you
know
I
think
would
be
important
because,
because
I
think
there
are
going
to
be
also
things
that
when
we
release
this
version
of
salsa,
this
version
of
the
salsa
Providence
spec
I
think
we
also
need
to
sorry
the
salsa
Providence
format.
A
There's
going
to
be
like
there
might
be,
for
example,
when
we
release
salsa
version,
two,
nothing
might
change
with
the
salsa.
Providence
spec
I
doubt
it,
but
there
might
be
like
literally
no
changes
to
the
provenance
spec.
It's
just
like
hey
here
are
some
different
requirements
and
you
still
use
the
profit
and
inspect
the
same
generally.
The
same
way
you
just
and
I
think
that
sort
of
thing
is,
you
know
we
might
just
still
do
something
like
where
we
bump
the
provenance
format
anyway
and
say:
hey,
but
yeah
Chris.
G
A
Oh
yeah,
yeah,
I,
I,
so
I
think
it's
less
about
necessarily
that
and
more
just
I
can
because
at
the
same
time,
I
could
also
Imagine
a
scenario
right
where
we've
been
updating
the
provenance
stuff
to
meet
certain
things
and
then,
when
we
change
the
requirements.
A
Oh
so
actually
let
me
let
me
ask
you
this.
So
do
you
think
the
idea
here
is
that
the
way
that
the
provenance
spec
is
even
used
is
the
provenance
format
is
even
used
is
also
part
of
that
is
part
like.
So,
even
if
actually
let
me
take
a
step
back
if
I
have
right
to
just
provide
an
example.
A
Are
you
saying
that
you
sort
of
view
it
differently
where,
if
you
have
elements
that
are
required,
you
know
if
you
have
these
set
of
requirements,
you
fill
out
the
salsa
provenance
format,
let's
say
version
two
and
then,
when
you
have
different
requirements,
even
though
the
provenance
format
hasn't
materially
changed
the
meaning
behind
what
is
how
it's
filled
in
might
change,
so
you
actually
still
want
to
say
this
is
now
technically
a
new
version
of
the
format,
because
the
way
it's
intended
to
be
used
is
different.
G
Yes,
I
see
the
provenance
as
a
representation
of
meeting
Salsa's
requirements
and
if
the
requirements
have
changed
the
provenance,
the
provenance's
meaning
has
changed
so
yeah.
It's
it's
a
new
sort
of
provenance
or
a
new
version
of
the
provenance.
A
Yeah
yeah
I
I,
never
mind.
C
B
Think
that
makes
sense,
but
I
mean
I.
Also
think
this.
The
cost
of
that
right
is
that
it
we
are
putting
the
burden
in
the
consumer
to
figure
out
whether
there
is
actually
some
meaningful
change
or
not
and
how
they
should
interpret
the
provenance
they
are
getting
and
we
may
create
more
children
than
it's
worth
it
if
in
a
way,
but.
B
Because
you're
talking
about,
like
you,
know,
release
notes
or
your
men,
but
this
becomes
really
critical.
It's
like
every
time
we
bump
the
version.
Number
people
started,
you
know
implemented,
they
produce
a
new
provenance
with
a
new
version
and
people
say:
oh
shoot,
it's
not
that's
changed.
What
does
it
mean
for
me?
B
A
Yeah
and
I
mean
I
think
a
lot
of
it
is
it's
a
little
bit
complicated
generally
because
some
of
it
could
be
solved.
A
If,
let's
say
there
was
an
official
set
of
salsa
libraries
for
the
different
things
and
just
say
hey,
if
you
use
go,
this
is
you
know,
and
so
then,
when
we
versioned
to
3.0
of
the
spec
from
2.0,
the
spec
you'd
still
be
able
to
like
oh
okay,
now,
I
just
need
to
import
version
three
and,
and
but
it's
still
at
the
end
of
the
day,
somebody
has
to
go
in
and
say
well
when
I
fill
in
the
blanks
of
the
provenance
format,
some
of
those
things
might
have
different
semantic.
Meaning
of
you
know.
A
A
What
are
some
of
these
other
things
mean
and
as
we
clarify
those
things,
they
fundamentally
have
a
different
meaning
inside
the
inside
of
the
documents,
and
we
need
to
have
a
a
way
to
specify
that,
and
some
of
that
could
be
specified
via
the
the
URI
element
of
of
what
version
of
salsa
provenance
format
that
folks
are
using.
A
You
could
say:
hey,
this
is
the
you
know,
we're
using
version
three
or
whatever
and
version
three
now
means
that
this
field
means
something
different,
but
it's
still
a
much
fuzzier
thing
than
you
know
normal,
like
software,
where
you
can
say
hey
this
thing
used
to
take
a
string.
Now
it
takes
an
integer,
whereas
here
it's
like
well
last
week,
isolated
ephemeral
meant
this
weaker
thing
this
week,
you
know
in
the
new
version:
isolated
ephemeral
means
this
much
stronger
thing.
A
Well
so
I
think
the
thing
that
is
so
that
works
for
when
we're
producing
it,
but
for
the
end,
consumer,
the
consumer
might
let's
say,
have
a
policy
that
says:
oh
okay.
Well,
when
I'm
looking
at
my
version
of
salsa
and
yeah
yeah
I
really
want
to
make
sure
that
the
claims
of
isolated
and
ephemeral
mean
this
and
then
oh
that
changed
and
so
now
yes,
there's
a
new
version.
A
H
I
mean
I
feel
like
that
happens
today,
with
like
fips,
where
somebody
says
I
will
only
use
version.
2.7
I
will
not
use
2.6
and
I
will
not
use
2.8,
because
I
have
decided
that
this
is
fips
compliant
and
they
will
not
use
a
different
point
version
and
if
the
vendor,
providing
them
stuff
provides
a
different
version.
They're
like
no
I
also
need
this
version,
because
that's
the
one
my
company
said,
though,.
A
Yeah
and
I
think
that's
the
sort
of
thing
as
much
as
we
can
we're
trying
to
trying
to
avoid
in
the
community,
because
then,
obviously
the
thing
is
like
it's
one
thing:
if
you
know
an
individual
company
sets
up
a
specific
requirement,
it's
going
to
be
a
whole
other
thing
when
salsa
is
trying
to
be
as
like,
even
though
various
companies
can
use
it
right,
it's
mostly
for
open
source
and
for
producing
open
source
or
consuming
open
source,
and
if
a
bunch
of
different
open
source
providers,
you
know
if
it
just
as
an
example,
if,
like
some
packaging,
Eco
packaging
and
build
ecosystem
like
I,
don't
know
if
Debian
says
all
of
our
stuff
is
salsa
version.
H
Necessarily
care
that
ephemeral
change
from
X
to
Y,
they
might
have
a
different
bit
flip
on
their
CI
CD
pipeline.
That
says,
assuming
this,
you
know
it's
less
trusted.
Assuming
this
it's
more
interested
but
I
feel
like
the
people
who
are
going
to
outright
reject.
It
are
probably
going
to
be
a
smaller
group
unless
it's
a
major
change,
in
which
case
are
we.
You
know
that
really
shouldn't
be
a
minor
version.
H
A
All
right,
I,
don't
want
to
take
up
too
much
more
time
on
this
I
think
there's
a
lot
here
and
it's
gonna
probably
require
some
additional
discussion
and
offline
and
all
that
good
stuff.
So
one
of
the
other
issues
and
I
want
to
just
go
over
this
one
real
quickly,
so
we
can
get
to
some
of
the
other
stuff.
A
So
there
is,
and
typically
there's
a
bunch
of
other
issues,
I'm
just
not
exactly
sure
which
ones
are
there,
but
there
was
one
here
from
I
believe
it
was
Andrew
yeah
Andrew
asking
some.
Probably
we
just
need
to
make
sure
that
it's
really
clarified
in
the
requirements
around
around
what
it
counts
as
remote
execution.
A
What
is
isolated
and
ephemeral,
so
I
put
in
my
my
two
cents
on
it,
but
basically
you
know
he
has
a
bunch
of
questions
about
some
of
the
requirements
about
isolated
and
ephemeral
is
like
this.
Build
should
not
call
out
the
remote
execute
call
after
remote
execution
unless
it's
considered
part
of
the
Builder
within
the
trust
boundary.
A
His
worry
is.
Would
this
prevent
the
vendoring
of
binary
content
as
some
process
of
the
build
was
performed
outside
the
trust
boundary
prevent
curling,
yeah,
yeah
I
think
the
thing
that
I
try
to
at
least
I
know
in
some
of
our
stuff
the
way
I
always
interpreted
it,
and
maybe
the
requirements
just
dbb
bit
works.
The
wording
just
needs
to
be
a
bit
more
explicit
is
I,
always
viewed
all
of
these
things
as
being
dependencies,
so
they
would
be
considered
separate
builds.
A
So
if
somebody,
if
something
else
came
in-
and
it
was
another
dependency
yeah-
that's
just
another
dependency-
salsa
is
currently
not
transitive,
and
so
most
of
these
things
that
might
be
coming
from
other
locations
are
just
considered
dependencies.
They
they
might
or
might
not
have
social
attestations
associated
with
them,
but
they're
coming
from
a
different
trust
boundary,
so
they're
just
considered
dependencies,
whereas
the
actual,
like
compilation,
building
and
packaging
step
should
be
isolated
and
ephemeral
right
where
it
can't
modify
other
builds,
it
can't
interact
with
other
builds.
A
The
build
environment
needs
to
be
cleaned
up
at
the
end
and
that
sort
of
thing
and
that
if
you
are
using
a
binary
cache,
the
binary
cash
should
be
underneath
that
trust
boundary
right,
where
you
know,
if
you're
doing
partial
compilation
of
things
it's
part
of
that
entire
salsa
Builder,
whereas
if
you
pull
the
binary
cache
from
something
from
another
location,
that
is
kind
of
should
just
be
considered
dependency
like
if
you
pull,
you
know,
if
you
pull
a
if
you
pull
a
dependency
from,
you
know,
saying
like
if
you
pull
a
dependency
from
like
a
Debian
package
or
whatever
hey
that's
outside
of
your
trust,
boundary,
that's
considered
a
dependency,
that's
the
way,
I've
viewed
it,
but
I
wanted
to
get
other
folks
thoughts
on
on
this
as
well.
A
Or
an
external
dependency
like
the
the
way
that
we
have
been
sort
of
defining.
It
is
largely
like,
if,
let's
say
I'm,
building
a
python
package
and
that
python
package
requires
a
bunch
of
external
dependencies.
A
Well,
what
My,
Salsa
Ellen,
you
know
when
I,
when
I
do
my
salsa
build
I'm
only
doing
the
salsa
build
for
that
specific
python
code
that
I
pulled
in
if,
if
I
pull
in
the
other
things
that
it
depends
on
those
are
considered
external
dependencies,
they
get
recorded
in
the
materials
section
in
some
fashion,
whether
it's
an
S,
whether
it's
an
s-bomb
link
or
something
else
those
would
get
recorded.
But
the
idea
here
is
that
they're
not
like
what
an
end
user
knows
like.
A
Oh,
that's,
not
what
I'm
trusting
I'm,
not
trusting
the
dependencies
I'm,
trusting
the
build
of
this
thing
and
I'm
trusting
the
build
of
that
thing
did
the
right
steps.
But
if
you
were
to
do
something
like
as
part
of
your
building,
compilation,
step
and
I
know,
this
is
a
big
issue
in
certain
ecosystems
like
npm,
where
hey
even
doing
an
npn
build,
could
potentially
curl
out
to
some
other
random
location.
A
A
Well,
that
hash
is
not
accurate
right
because
you
pulled
in
other
dependencies,
you
don't
know
so
that's
kind
of
where
we
really
want
to
make
sure
that
that's
like
super
super
clear
to
folks
is
that's
kind
of
the
intent
here
is
to
say
when
running
the
building
compilation,
that's
really
hard
to
understand
right
if
you're
running
a
compilation,
you're
running
GCC,
whatever
you're
taking
C
source
code
or
C,
plus
or
whatever
and
you're,
transforming
it
into
a
binary.
That
process
is
hard
to
understand.
A
If
you
include
stuff
like
well,
it
reached
out
to
ntp
for
this,
and
it
reached
out
to
this
API
call
to
fetch
this
other
information
or
it
then
curled
these
other
binaries
as
part
of
the
literal
compilation,
then
it's
you
don't
have
an
understanding
of
what
your
dependencies
are
anymore.
I
think
that's
that
that's
the
intent!
Sorry,
my
rants
over.
B
A
Yes,
Brendan.
C
I
was
going
to
ask:
where
do
we
want
to
draw
the
line
for
fed
external,
knowing
some
of
the
stuff
that
I've
been
working
on
my
side,
projects
of
like
making
an
HTTP
proxy?
That
is
itself
something
you
would
attach
as
a
side
card
to
your
build
and
that
proxy
itself
is
completely
hermetic
itself.
A
So
the
way
that
it's
worded
and
and
I
think
this
makes
sense
with
the
requirements
is
that
if
you
consider
that
part
of
the
build
system,
it's
part
of
that
same
trust
boundary,
then
that's
fine.
Okay,
now
with
that
said
right,
you
might
still
say
like
if,
if
you're
pulling
in
these
external
dependencies,
let's
just
assume
for
a
second
that
you're
still
like
saying:
hey,
I
have
an
eternal
cache
of
npm
packages
or
whatever,
and
that's
part
of
the
build
side
car,
you
might
still
say:
hey.
A
No,
that's
not
I'm,
not
I
did
not
build
those
things
under
my
my
own
trust
boundary,
so
I'm
not
making
that
claim.
So
you
might
still
do
that,
but
in
cases
where,
let's
just
assume
for
a
second,
that
everything
you're
building
is
in
your
own
trust,
boundary
you're
publishing
it
to
an
internal
build
cash.
A
Then,
yes,
that
would
that
would
totally
work.
But
if
you're
talking
about
like
your
proxying
external
things,
then
I
would
still
say:
hey
that
that
you
would,
you
would
probably
want
to
make
the
claim
that
no
no
I'm
still
not
saying
that
the
things
I
pulled
externally
are
actually
good.
Just
that
I
can
reproduce
it
right
like
that
that
I
have
recorded
you
know
these
npm
dependencies
or
whatever
or
Pi
Pi.
You
know
dependencies
or
whatever,
and
then
I
can
rerun.
It.
A
Yeah
and
that's
something
that
you
know
one
of
the
open
questions
with
an
eventual
reintroduction.
Reintroduction
of
a
salsa
IV
would
be
something
like
hey
that
thing
that
you're
doing
with
the
Hermetic
sort
of
hermetic
build
would
be
something
that
allows
you
to
hit
those
requirements.
But
you
know
you
still
might
say:
hey
look,
even
though
I
can
hit
these
the
requirements
I'm
still
not
making
a
any
claim
that
transitively.
You
know
these
things,
I
pulled
Upstream
are
are
salsa
Andres,.
I
Hey
Mike
so
I'm
hearing
that
as
the
the
spec
continues
to
evolve,
definitions
are
going
to
be
more
crisp
and,
as
those
happen
well,
what's
the
right,
versioning
three
percent
that
and
tied
to
well,
if
people
have
a
clear
understanding
of
what
they
were
getting
with
1-0
and
that
suddenly
changes
and
the
attestations
are
different.
I
I
I
came
here
today,
hoping
to
get
a
sense
of
a
road
map
for
what
is
one
one,
two
one
three
2.0
and
I:
don't
like
I'm
hearing
several
things
that
you
have
a
strong
sense
of
well
we're
going
to
have
a
new
definition
for
level.
Four
we're
gonna
have
a
new
definition
for
what
isolated
means
we
may
have
different
guarantees
around
reproductibility.
I
So
would
it
be
worthwhile
rather
than
well
there's
a
version
Bob,
something
evidently
changed
that
is
Major.
Let's
go
read
the
change
log.
Would
it
be
beneficial
to
give
people
the
heads
up
through
a
roadmap
of
what
is
expected
to
change
short
term
and
Midterm.
A
So
yeah,
so
that
that
is
actually
part
of
that.
That
issue
is
so
one
of
the
things
is
we
have
the
salsa
1.0
which
should
be
going
live
after
you
know,
after
the
like
a
full
release,
most
likely
at
the
end
of
this
month
and
and
or
well
we're
at
least
closing
up
feedback
by
the
end
of
this
month.
It
might
be
a
little
bit
after
that,
and
so
for
us
I.
A
Think
that
the
thing
that
we're
still
trying
to
kind
of
get
super
Chris
is
that
meta
issue
of
how
do
we
Define
these
future
releases
and
what
are
the
expectations
that
should
be
changing,
and
so
that's
another
thing:
I
think
we
want
to
get
done
by
1.0,
so
that
post
1.0
people
know
okay,
yes,
1.1
will
mean
this
right
like
these
are
the
the
sorts
of
changes
you
might
expect,
and
then
these
are
also
the
things
that
are
are
on
the
roadmap,
but
for
right
now,
we've
been
super
focused
on
just
sort
of
the
one
point,
O
piece
while
teasing
out
those
other
meta
issues.
I
Were
there
things
as
you're
cutting
the
release
candidate
that
the
team
wanted
to
do,
but
there
was
just
no
time
and
they
prioritized
for
release
candidate
and
said,
like
no
we're
leaving
this
things
out
for
a
later
point
in
time.
Obviously,
with
the
release
candidate
thinks
that
what
you
caught
at
is
going
to
be
improving
those
things
that
exist
and
are
available
versus
the
things
you
wanted
to
do
and
did
it.
A
Yep,
so
there's
a
bunch
of
things
and
I,
don't
remember
exactly
where
Mark
has
all
of
that
it's
somewhere
in
in
the
the
site
and
might
not
be
the
easiest
thing
to
find.
But
the
there
are
a
couple
of
things
like
hey:
we
cut
out
L4
because
we
used
to
have
L4.
We
cut
out
L4,
because
the
definitions
were
a
little
unclear.
There's
a
lot
of
confusion
around
hermeticity
and
a
confusion
around
some
of
these
other
pieces,
as
well
as
a
lot
of
the
tools
that
we
were
looking
at.
A
Just
don't
necessarily
support
it
and,
and
even
though
we
want
it
to
be
obviously
very
aspirational
like
it
should
be
difficult
to
do
and
if,
even
if
there's
no
tools
that
can
hit
it
exactly,
we
want
to
make
sure
that
folks
can
eventually
hit
it.
The
issue
is
that
there's
just
like
so
much
confusion
around
it.
We
got
rid
of
that
and
then,
in
addition
to
that,
I
think
yeah
we're
trying
to
kind
of
tease
out
some
of
these
other
other
pieces.
A
Like
we
pretty
much
said
version,
one
is
purely
about
the
build
we're
not
talking
about
Source
Integrity
outside
of
the
idea
that
if
you
pull
something
you
should
be
trusting
the
bill
to
actually
be
pulling
down
the
right
thing
you
shouldn't
be.
Assuming
that
the
build
is
like
hey
the
build
said
you
shouldn't
one.
Second
yeah,
you
shouldn't
trust
that
the
you
know.
If
you
build
pull
down
X,
it
should
not
pull
down
y.
B
F
B
In
the
one
zero
spec
there
is
a
page,
that's
called
what's
new
in
the
RC
version,
it's
very
limited,
but
there
is
I
think
it
has
been
already
expanded
in
the
one
zero
draft
and
then
there's
a
section
on
future
directions,
which
also
gives
some
answers
to.
You
know
things
that
have
actually
been
removed
like
level
four
and
talks
a
little
bit
about.
What's
coming
but
I.
Could
you
know
I
think
this
is
a
great
feedback
that
we
should
take
into
account
to
try
to
beef
up
those
sections
so
that
we
do
get
people?
B
B
B
A
So
I
don't
I
want
to
give
enough
time
for
Arno
on
the
next.
The
getting
started.
B
B
It
I
mean
we
kind
of
limited
most
of
the
content
to
information
related
to
freely
available
build
systems,
but
there
is
also
a
section
at
the
very
end
that
list
different
Builders
and
the
idea
is
that
eventually
I
mean
there's
been
the
work
on
the
certification
program
for
salsa,
but
we
don't
have
it
yet
and
so
in
once
we
have
that
we
will
have
you
know
more
of
an
official
list
and
but
for
now
there
is
a
a
list
which
is
self-claims
right,
and
so
this
is
completely
open.
Anybody.
F
B
Has
a
builder
that
claims
to
you
know,
comply
with
a
certain
level
of
salsa
can
basically
submit
a
pull
request
to
get
added
to
that
list,
and
we
probably
should
have
some
link
associated
with
the
builder,
because
there's
just
a
name
and
I.
Suppose
that's
not
very,
but
you
know
I
just
want
to
point
that
out
because
I
know
there
are
the
people
that
we
heard
from
Nicole
earlier
they're
working
on
one.
You
know,
and
there
will
be
many
others.
Hopefully,
if
we're.
H
I
know
of
testify
fact
that
does
witness,
which
is
open
source,
I'll
ping
them
as
soon
as
I
figure
out
how
to
get
a
PR
in
for
us
that
I'll
ping.
Some
other
groups
that
I'm
aware
of
to
get
them
in
as
well.
B
I
mean
it's,
you
know,
you
know
the
the
I
actually
added
the
disclaimer
in
the
section
to
say
Hey,
you
know
this
is
provided
as
is
open.
This
isn't
makes
no
claim
blah
blah
blah
yeah.
You
know,
because
we
don't
want
to
have
any
liabilities
related
to
this.
So
it's
really
just
for
your
information.
It
is
to
help
people
who
are
out
there
and
they're
going.
E
B
H
But
I
don't
want
to
like
go
adding
people
like
I
know
get
lab.
Does
it
and
I
know
witness?
Does
it
and
I
know
some
other
groups?
Do
it,
but
I
don't
want
to
add
them
without
their
permissions?
I'll
probably
start
PR's
and
then
tag
them
in
their
PRS,
because
it's
kind
of
rude
to
just
add
people's
way.
Yeah.
B
H
I'm
just
going
to
bring
something
from
my
get
lab
day
that
may
help
here
sometimes
putting
a
small
statement
at
the
bottom
like
right
now.
It
says
if
a
build
option
is
myth
classified
open
or
submit
a
PR
against
it.
We
may
want
to
add
at
the
bottom,
like
anyone
is
open
to
suggest
and
edit
by
opening
a
PR,
because,
right
now
it
sounds
like
you're
only
allowed
to
fixed
items,
not
suggest
items
so
people.
B
H
If
you
squish
them
together,
people
don't
like
to
read
I
I
know
it
sounds
terrible,
but
people
get
overwhelmed
so
like
change
that
into
two
separate
sentences,
and
that
may
actually
make
it
more
clear
to
people.
F
H
F
F
A
That,
okay,
so
I
doubt
we'll
have
enough
time
and
I
also
I
know
that
Melba
was
one
of
the
folks
who
was
super
had
a
lot
of
thoughts
about
the
the
other
issue
about
the
splitting
up
source
and
build
because
I
know
that's
one
of
the
things
that
we
still
wanted
to
kind
of
make
sure
that
we
had
a
clear
distinction
as
we
go
into.
A
Actually
you
know
as
we
go
into
post
1.0,
we
want
to
make
sure
that
it
was
clear,
like
hey
here's,
the
stuff
that
we're
working
on
on
the
roadmap
and
then
here's
clearly
the
distinction
between
you
know
what
is
the
limit
of
salsa
1.0
and
here
are
the
things
that
we're
working
on
for
post,
salsa,
1.0
and
I
know
that
there
was
some
thoughts
and
discussion
and
confusion
around
exactly
what
counted
as
Source
versus
build
so
I.
A
We
want
to
talk
about
that,
but
I
think
with
only
nine
minutes,
left
I
doubt
we'll
be
able
to
to
get
to
it,
but
yeah
actually
hold
on.
Let
me
double
check.
Is
there
anything
else
on
the
agenda
that
anybody
added
my
Tabs
are
all
messed
up?
A
Okay,
cool-
if
not
here,
I'll
just
put
this-
you
all-
can
have
nine
minutes
back
unless
there's
something
else.
Somebody
wanted
to
bring
up
real,
quick.