►
From YouTube: SLSA Meeting (May 12, 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).
C
Actually,
let
me
double
check
here.
I
think,
since
kim
and
some
of
the
other
folks
are.
B
C
B
Okay,
so
yeah
we'll
give
it
another
minute
or
two
for
a
few
more
folks
to
join,
and
then
we
can
get
started.
B
Oh
true
yeah,
I
did
it's
been
a
it's
been
a
long
week.
C
Let's
see
here,
okay
whoops,
so
we
can
get
started
here.
So
I'm
gonna
post
here
are
the
the
notes.
Put
your.
C
B
And
then,
while
that's
going
on
just
a
reminder
here,
the
meeting
is
being
recorded
and
will
be
uploaded
to
youtube
shortly
thereafter.
So
and
also
you
know,
your
participation
in
this
meeting
buys
by
like
the
open,
is
an
agreement
to
abide
by
the
open,
ssf
code
of
conduct,
okay
cool,
so
we
can
get
started
with
the
agenda
here.
Usually
we
start
off
first,
just
sort
of
asking:
is
there
anybody
new
to
the
meeting
who
wants
to
introduce
themselves.
E
I'll
go
hi,
I'm
patrick
flynn,
I'm
a
recent
chain
guard
employee
and
just
coming
to
check
out
south
and
find
out
more
about
it.
Thanks.
B
F
Likewise,
my
name
is
jason,
lutz,
I'm
a
relatively
new
chain
guard
employee
and
definitely
checking
out
the
sls
salsa
framework.
G
Oh
cool
mark
sturtevant.
I
work
at
ibm
with
some
folks
that
you've
probably
met
here
already
been
working
on
security
just
recently.
H
Hey
I'm
josh
mullikin
from
red
hat,
checking
out
salsa
and
trying
to
learn
how
we
can
integrate
it
kind
of
here
when
and
with
how
we
do
things
red
hat.
C
Cool
all
right,
I
guess
we
can
get
to
the
agenda
now
glad
to
see
every
glad
to
see.
B
So
many
new
faces
mark
you're
up
first.
I
Thanks,
I
just
wanted
to
point
out
in
case
not
everyone
is
subscribed
to
the
other
repo,
the
salsa
proposals,
repo.
I
sent
out
the
project
roadmap
that
I
presented
two
weeks
ago,
which
is
in
text
form
right
now.
It
just
contains
things
that.
I
My
organization
google,
is
is
working
on.
It
doesn't
represent
any
other
projects
that
people
are
working
on
because
I'm
unaware
of
them.
So
if
the
overall
road
like,
if
folks
agree
with
the
overall
direction
and
and
how
it's
presented
here,
we
could
have
subsequent
pull
requests
to
add
other
parts
of
the
roadmap
or
other
kind
of
committed
work
to
the
roadmap.
But
hopefully
I
I
put
in
the
salsa
roadmap
to
or
like
in
the
proposals
directory
repository.
I
J
Yeah,
I
realized
I
did
not
make
the
document
I
linked
here
public
until
this
morning,
so
I'm
guessing
not
a
lot
of
people
have
had
a
chance
to
have
a
look
at
it.
Yeah
that
I
didn't
want
to
create
this
just
as
a
github
issue,
because
the
explanation
in
there
is
somewhat
lengthy
and
a
little
bit
too
much
for
an
issue
on
its
own
and
probably
not
suitable
for
a
proposal
either.
J
But
I
figured
that,
as
we
were
getting
towards
finalizing
a
source
of
1.0
specification,
it
would
be
good
to
open
up
a
discussion
that
we've
been
having
internally,
at
least
on
reproducibility,
specifically
that
we're
finding
that
reproducibility
for
certain
ecosystems
is
just
not
a
possibility
we'll
go
into.
Why
a
little
bit
here.
If
I
can
just
share
my
screen
here,.
J
Okay,
so
my
our
take
on
salsa
here
is
that
it's
there's
a
lot
of
things
in
salsa,
which
will
help
make
a
build
system
tamper
proof,
but
none
of
it
is
guaranteed,
and
so
what's
also
really
giving
us
is
a
measure
of
temper
evidence
within
a
build
system
and
within
a
within
a
supply
chain,
and
so
there
are
certain
requirements
that
are
somewhat
more
casual
and
reproducibility.
J
I
think
is
kind
of
the
ultimate
catch-all
here
in
that
everything
that's
not
specifically
covered
by
salsa
in
terms
of
what
you
can
attest
to
and
everything
else,
so
everything
kind
of
below
that
layer,
even
in
the
software
supply
chain,
so
even
down
to
the
hardware
that
things
run
run
on
this
also
doesn't
make
any
specific
attestations
on
it
and
bitwise
reproducibility
is
kind
of
a
proxy
for
tamper
evidence
in
in
the
parts
of
build
systems
that
are
not
covered
by
salsa
elsewhere.
J
So
it
gives
you
you
know
as
a
benefit.
It
gives
you
some
measure
of
whether
or
not
the
the
whole
you
know
of
the
supply
chain.
Even
the
parts
that
aren't
covered
by
salsa
have
not
been
tampered
with,
but
certainly
for
some
ecosystems
and
some
underlying
build
systems
that
you'd
end
up
bootstrapping
bitwise
reproducibility
is
not
a
good
measure,
for
you
know
the
overall
temper
evidence
in
the
in
a
build
system.
J
One
key
reason
that
we
find
is
that
looking
at
a
lot
of
ecosystems
kind
of
artifact
formats.
So
if
we
look
at
python's
wheel,
format,
java's
jar,
ruby's
gem-
these
are
all
usually
variants
of
or
subdialects
of,
tarballs
or
zip
files
doubles
and
zip
files
usually
contain
timestamp
and
metadata
information
on
the
files
that
they've
packaged
up,
and
so
you
literally
cannot
produce
a
bitwise.
J
Even
if
all
of
your
inputs
are
the
same,
it's
almost
impossible
to
generate
a
bitwise,
identical
wheel
or
gem
or
jar
file
from
two
runs,
even
from
the
same
source.
So
you
know
I've
just
been
testing
this
again
this
morning,
I
just
you
know
from
exact
from
a
pure
python
module
two
runs
of
pip
wheel,
dot
in
the
same
directory
with
the
same
source,
files
on
the
same
machine
produce
different
wheels,
and
that
is
purely
down
to
the
time
stamps.
J
So,
for
example,
if
you
make
a
tarball
of
something
that's
you
know
an
intermediate
step
like
if
you
do,
if
you
take
a
c
library
and
you
do
a
make
all
you
tie
that
up,
take
it
somewhere
else
and
then
do
the
make
install
somewhere
else.
If
you
flatten
the
timestamp,
the
make
doesn't
know
which
artifact
came
before,
which
other
ones
so
you
end
up
with
you
know,
don't
see
files
and
dotto
files
with
the
same
dates
on
and
make
doesn't
really
know
what
to
do
with
them.
J
J
The
actual
hardware
that
things
run
on
actually
has
an
influence
on
the
output
so
running
the
same
container
in
the
same
cluster,
but
on
different
hardware
can
sometimes
produce
different
artifacts.
J
J
You
can
end
up
with
with
different
output,
for
different
builds,
offer
the
same
build,
so
you
even
get
different
steppings
of
the
same
cpu
can
end
up
with
different
builds,
especially
in
terms
of
things
like
tensorflow
that
take
advantage
of
all
of
the
all
of
the
potential
optimizations
that
the
cpus
can
use
yeah
and
then
laid
out
here.
J
There
are
some
other
conditions
that
potentially
affect
reproducibility
it's
possible
that
things
like
load
on
the
machine,
that's
actually
hosting
your
container
may
actually
affect
the
output,
because
you
may
end
up
with
different
compiler
strategies,
based
on
the
available
memory
that
you've
got.
You
may
end
up
with
different
thread
ordering
in
execution.
Some
of
these
things
may
affect
the
output
of
compilers.
J
So
a
problem
really
with
this
is
that,
although
even
though
salsa
level
four
specifies
that
reproducibility
is
a
kind
of
an
optional
requirement,
it
does
make
a
requirement
that
you
specify
why
any
particular
build
is
not
reproducible
and
I
think
what
that's
going
to
lead
to
is
a
bunch
of
basically
blanket
get
out
clauses
for
reproducibility.
As
in
the
you
know,
this
would
be
reproducible,
but
it's
python
and
we've
made
a
wheel
if
this
would
be
reproducible.
J
But-
and
basically
you
can't
you-
you
count
out
entire
ecosystems
from
being
able
to
produce
this,
and
so
you
know
that
each
ecosystem
that
can't
do
this
will
end
up
needing
kind
of
a
blanket
exception
for
reproducibility.
J
Now
you
know
I'd
love
to
be
proved
wrong
on
a
lot
of
these
things,
but
it's
been
our
experience
that
you
know
the
things
that
we're
building
at
the
moment,
so
mostly
pearl
python,
tickle
ruby.
We
cannot
produce
bit
wise
identical
bills
on
on
subsequent
runs
of
the
same
with
her.
You
know,
hermetic
build
system,
exactly
the
same
containers,
exactly
the
same,
build
conditions
we
still
cannot
produce
identical,
artifacts,
so
yeah.
J
This
is
really
opening
a
discussion
on
whether
or
not
we
should
find
a
better
proxy
for
build
system
tampering
than
purely
bitwise
item
potency
or
whether
we
can
find
a
better
way
to
actually
if
we
can
find
a
better
way
to
kind
of
improve
the
the
the
ecosystems
that
currently
can't
produce.
Reproducible
builds.
A
I
I
was
going
to
say
I
think
part
of
the
problem
might
be
in
the
caveat,
which
was
the
things
we're
trying
to
build
today,
like
a
lot
of
modern
python.
Python
3
has
a
very
volatile,
build
ecosystem,
but
if
you're
building
with
I
don't
know,
I
don't
know
how
recent
but
recent
versions
of
the
build
tools
like
you
can
get
a
bit
reproducible
wheels,
and
so
I
would
guess
the
problem
is
like
old,
old
inputs
and
old
tools
in
use.
Well,.
A
Interesting,
okay,
I
don't
want,
I
don't
know,
I
guess
we
shouldn't
dive
into
debugging
your
build
system
right
now,
but
I
think
like
from
where
I'm
standing.
This
has
been
a
relatively
solved
problem
for
ten
or
so
years
like
the
reproducible,
builds
project
has
established
standards
which
toolchains
implement
and
the
number
for
example.
The
number
of
packages
in
debian,
which
are
biff
bit
reproducible
is
fairly
significant
in
the
high
90th
percentile.
I
think
so
I
don't.
J
A
I
I
Like,
yes,
you
could
strip
timestamps,
you
could
make
sure
the
zip
files
are
ordered
in
some
deterministic
manner.
You
could
blah
blah
blah
like
the
fact
that
debian
doesn't
have
100,
but
only
like
90
is.
I
think,
indicative
that
it's
it's
it's
not
too
bad
to
get
the
majority
of
packages,
but
I
think
we
should
consider
cost
and,
like
the
cost
benefit
like
the
return
on
investment
from
from
requiring
things
to
be
reproducible,
we
should,
I
don't
think
we
should
discount
the
cost.
I
The
reason
it
was
added
because
you
said
it
as
a
proxy
for
tamper
evidence,
I
think,
is
used
so
originally
just
kind
of
as
a
background
it
was
this
was
not
in
the
in
the
requirements.
This
was
added
david
wheeler
had
david,
a
wheeler
had
suggested,
adding
it
as
a
recommendation,
and
I
think
it's
a
good
thing
to
think
about
for
one.
I
agree,
that's
good
to
think
about
for
1.0
of
like
where
and
how
we
should.
We
should
fit
it
in.
I
I
I
think
the
the
intention
of
it,
at
least
from
my
so
that
my
personal
point
of
view
is
that
reproducibility
is
valuable
because
it
makes
it
very
easy
for
forensics
and
for
like,
like
you
said,
I
guess,
that's,
maybe
what
you're
saying
by
tamper,
tamper
evidence
and
also
it
makes
it
easier
to
build
a
where
it
can
enable.
Oh,
this
is
speculative
like
a
salsa
4
build
system
by
having,
if
two
independent
things
build
it,
then
you
kind
of
know
you
get
a
lot
of
properties
out
of
that.
I
If
you
have
a
whole
verification
system
in
place,
so
I
think
there's
a
there's,
also
some
nice
properties
in
like
the
bit
for
bit
identical.
I
It's
just
like
easy
to
compare,
but
I
feel
like
there's,
maybe
room
that
we
could
like
better
define
what
that
means
like
something
to
perhaps
that
we
could
consider
would
be
like
if,
if
it's
not
necessarily
deterministic
the
first
time
but
to
reproduce
it,
you
kind
of
use
these
non-deterministic
or
like
these
non-hermetic
inputs
and
subsequent
rebuilds
could
use
the
same
time
stamp
or
something
that
seems
okay
to
me,
although
that
probably
is
just
as
expensive
to
do
as
making
it
fully
deterministic.
So
I
don't
know
if
that's
actually
of
any
value.
K
So
my
thoughts
here
are
that
reproducibility
is
still
very
important
and
even
if,
like
it,
it's
the
only
salsa
roll
that
has
an
easy
escape
of
you.
Just
explain
why
you
don't
have
the
capabilities
to
do
it
so
again
it
if
the
catch-all
escape
was
well
the
whole
npm
ecosystem,
whether
it
does
or
not.
I
don't
know,
but
as
an
example.
If
you
have
to
say
the
whole
ecosystem
is
non-reproducible,
then
then
there's
your
reason.
K
I
think
that
you
know
if
you,
you
can
only
get
so
much
trust
in
various
different
build
servers,
and
if
you
want
to
have
less
trust
in
them,
then
you
can
just
build
on
many
servers
and
and
hope
for
a
quorum
or
look
for
any
kind
of
outliers.
You
know
that
kind
of
thing.
It's
there's
a
lot
of
big
advantages
with
reproducible
builds
and
there's
a
lot
of
work
being
done
by
a
lot
of
people.
So
it's
it's
not
like
you
know.
Everyone
will
just
be
on
their
own.
K
Trying
to
achieve
reproducible
builds
on
their
own
there's
a
lot
of
help
out
there
there's
a
lot
of
work.
That's
been
done
in
the
past
and
I
think
it's
it's
a
key
part,
especially
of
level
four,
which
is
meant
to
be
advanced,
and
when
we
start
talking
about
the
cost
of
implementing
some
of
this,
that
there's
already
quite
a
big
cost
in
in
some
of
the
sales
stuff.
You
know,
if
you're
doing
massive
amounts
of
build
to
a
massive
scale,
you've
got
to
store
a
massive
amount
of
provenance.
K
You
know
each
individual
file
might
be
small,
but
you
know
you,
you
want
to
start
maintaining
this.
K
J
Yeah,
I
agree
that
it's
it's
it's
expensive
to
do,
and
you
know
there
is
a
whole
lot,
a
lot
of
expense
in
producing
something
that
comes
up
with
all
the
the
other
requirements
of
salsa
4.
yeah,
and
I'm
certainly
happy
to
take
a
look
at
any
efforts
that
that
are
out
there
for
the
ecosystems
that
we're
trying
to
build
to
help
make
them
reproduce.
J
Well,
you
know,
I
think
reproducibility
is
a
good
thing
in
the
build
system
in
general,
but
by
and
large
what
we're
doing
here
is
bootstrapping
someone
else's
build
system,
and
quite
often
they
haven't
had
reproducibility
as
one
of
their
as
one
of
their
one
of
their
tenants
from
the
outset.
J
I
Yeah
yeah,
I
I
think
that
like
to
scale
this
in
order
like
to
actually
cover
a
significant
number
of
packages,
it
kind
of
has
to
be
done
at
the
infrastructure
level,
so
individual
package
maintainers
shouldn't,
have
to
do
anything
like
for
the
python
case.
I
think
the
right
solution
for
reproducibility,
whether
or
not
it's
a
formal
salsa
requirement
or
not.
I
think
it
would
be
valuable
to
spend
some
effort
trying
to
make
all
python
packages
reproducible
by
default
with
the
default
tooling
and,
like
you,
have
to
go
out
of
your
way.
I
Not
to
do
that
like
within,
like,
for
example,
basil
is
reproducible
like
by
design.
They
originally
did
it
for
like
performance
reasons,
so
that
you
for
caching,
but
but
we
also
get
the
security
benefit
of
that
as
well,
and
I
think
if,
if,
if
any
individual
package
owner
had
to
do
work
to
make
it
reproducible,
it
wouldn't
happen.
J
Yeah,
fair
enough,
I
mean
yeah.
We
we
see
that
same
sort
of
thing
and
we
different
you
know
specifically
call
out,
go
and
basil
or
something
that
as
things
that
have
that
reproducibility
baked
in
from
there
from
the
outset,
yeah.
I
think
it's
it's
it's
kind
of
it's
just
tough
to
impose
already
on
an
existing
ecosystem,
but
yeah.
I
agree
that
you
know
efforts
to
actually
improve
ecosystems
that
are
in
place
already
to
get
to
this
point
would
probably
be
the
easiest
way
to
to
solve
it.
B
Yeah
just
to
to
add
on
to
what
mark
was
saying
yeah,
I
think
this
is
sort
of
what
products
like
alpha
omega
are
really
also
useful,
for
here
is
like
to
kind
of
come
in
and
say:
hey:
can
we
go
to
something
like
the
python
ecosystem
and
say
we'll
spend
some
money
to
make
your
build
ecosystem
reproducible
or
so?
B
And
I
think
I
think
that's
gonna
provide
a
lot
of
value
because,
like
I
know,
there's
a
lot
of
systems
that
try
to
sort
of
build
on
top
of
stuff
and
do
a
lot
of
things
and
you
know
sort
of
patch
things
and
and
strip
out
timestamps,
but
in
a
lot
of
ways
I
think
you
know
long
term
it's
going
to
be
cheaper,
the
more
we
can
kind
of
go
back
to
hey,
like
working
with
the
actual
language,
maintainers,
the
ecosystem,
maintainers
and
so
on.
A
Yeah
mark
just
preempted
me
in
the
dock
a
bit
I
think,
but
I
was
going
to
suggest
like
this
there's
been
some
discussion
about
highest
also
levels
and
the
fact
that
this
is
currently
as
you've
articulated
fairly
hand.
Wavy
with
a
big
like
gal
hatch
might
be
a
reason
to
put
this
in
a
higher
level
if
we're
going
to
have
higher
levels
in
the
first
version
of
the
spec
or
at
the
very
least.
This
deserves
some
consideration
in
how
it's
phrased
and
where
it
sits
in
the
in
the
lineup.
A
I
do
genuinely
believe
this
is
like
a
worthwhile
goal.
We
had
some
pretty
good
success
in
a
project
we
worked
on
in
the
back
in
the
past,
taking
you
know,
700
or
so
packages
from
random
ecosystems
and
making
them
reproducible.
So
I
know
it
is
possible,
but
I
also
do
fully
understand
that
it
is
a
lot
of
work
that
most
people
don't
find
very
interesting.
L
Yeah,
I
was
gonna
just
comment
it.
So
you
know.
Within
this
conversation
it
seems
like
the
reproducibility
across
different
ecosystems
is
difficult.
Today
it
seems,
like
you
know,
unless
there's
a
driver
behind
it,
who's
gonna
wanna,
take
the
time
to
do
that
right
across
an
ecosystem.
The
security
benefit
for
reproducibility.
L
J
Hey
jack.
M
Perhaps
if
I
mute
myself,
I'm
just
going
to
drop
a
link
into
the
chat,
there's
a
spreadsheet
that's
been
developed.
Why
won't
the
lower
hand
button
actually
lower
my
hand
there
we
go.
M
I
think
one
of
the
reasons
that
it
hasn't
been
on
the
radar
apart
from
it's,
not
a
thing
you
think
of
naturally,
until
somebody
points
it
out
is
also
that
most
package
registries
or
repositories
behave
immutably
once
you've
consumed
a
package
at
a
version
it's
consumed
for
good.
So
there's
no
concept
in
the
repository
of
reproduction.
M
J
Yeah
I
mean
we
have,
I
mean
just
coming
back
to
bashing
a
little
bit.
I
mean
we
kind
of
fake
this
up
by.
If
you
give
us
the
same
requirements,
we
give
you
the
same,
build
plan
and
hence
the
same
artifact,
and
we
just
draw
that
from
cache.
So
it
looks
like
we're
doing
it.
But
it's
you
know
it's
caching,
it's
not
really.
We
can't
reproduce
these
builds
directly
and
I
think
you
know
if,
if
comparing
output
of
builds,
you
probably
need
at
least
three
one
to
two.
J
J
J
J
And
hence
you
know
not
necessarily
worth
the
comparison
mark?
You
have
your
hand
up.
I
Is
there
are
we
all
interpreting
the
requirement?
The
same
is:
does
the
build
system
actually
need
to
verify
that
it
was
reproduced
like
by
actually
building
it
twice
and
checking,
or
is
it
just
simply
a
claim
that
I
think
this
ought
to
be
reproducible,
so
someone
should
be
able
to
try
or
I'm
explicitly
claiming
no,
I
know
it's
not
reproducible
for
this.
A
J
You
know
the
fact
that
we're
specific
about
about
it
being
done,
bitwise
identical,
because
we
don't
have
a
better
measure
of
functionally
identical.
A
So,
just
jumping
on
that
quickly,
because
david
was
the
original
person
that
introduced
this
requirements
level.
Four
and
he's
also
filed
an
issue
on
the
sales
repository
about
introducing
verifiably
reproducible
builds
at
iso
levels.
So
I
think
that
how
you
summarize
the
state
is
correct.
K
Yeah,
just
one
comment
on
the
the
separate
build
servers
and
you
know
whether
they're
different
and
such
so
so,
typically,
once
you
get
a
reproducible,
build
at
least
on
your
machine
you'll
then
start
introducing
kind
of
things
that
cause
the
builds
to
be
different.
K
You
can
introduce
other
kind
of
forms
of
stuff
that
usually
sets
your
your
build
off
in
in
unstable
paths,
with
like
an
unstable
file
system,
and
quite
a
lot
of
this
is
listed
in
the
in
the
reproducible,
builds
kind
of
wiki
and
such
so
you
once
you
get
a
reproducible,
build.
You
then
start
testing
that
to
the
extreme,
by
introducing
yeah
this
kind
of
disorder,
this
kind
of
stuff
that
will
then
tease
out
things
that
are,
in
fact
not
reproducible
across
machines.
J
Okay,
no
other
hands
up
yeah
hand,
it
back
michael.
Take
it
away.
C
So
I
think
next
up
is
josh.
A
Oh
sorry,
where's
typing-
I
can't
multitask
apparently
so
I
just
wanted
to
highlight
this
really
for
a
similar
reason.
That
mark
did
his
note,
because
there's
a
discussion
happening
in
a
separate
repository
about
the
switch
to
the
community
specification
license
and
how
there's
some
misalignment
between
how
the
salsa
community
governance
is
arranged
and
how
the
community
specification
license,
expects
governance
to
be
arranged.
I
think
so.
A
I
just
wanted
to
highlight
the
issue
that
I've
included
in
the
doc
and
asked
people
to
take
a
look
offline
and
try
and
figure
out
what
what?
If
anything,
we
need
to
do
that.
So,
especially,
I
guess
they're
in
committee
folks,
but
really
just
everyone.
A
That's
interested
could
use
some
some
participants
in
the
conversation,
so
we
can
figure
out
what
we
need
to
do
and
move
forward
with
this.
I
Oh
sorry,
is
this
simply
changing
the
text
to
match
what
we
already
have,
or
is
it
a
requirement
from
like
open
ssf
that
we
restructure
to
match?
What's
in
the
text.
A
B
A
I
think
I
just
want
to
add.
One
thing
I
did
comment
on
in
the
issue
is
that
one
of
the
things
in
the
community
specification
license
suggestion
is
that
we
have
explicitly
named
kind
of
maintainer
and
editors,
and
I
do
feel
like
we've
grown
there's.
Some
distinct
like
there
are
people
who
are
working
on
effectively.
A
Maintaining
their
specifications
rightly
is
a
great
example
of
that
who
long
investment
in
the
project,
I
think,
should
be
recognized
by
some
kind
of
formal
role,
whereas
the
steering
committee
is
was
imagined
to
be
rotating
and
provide
like
a
more
balanced
set
of
reviewers
for
kind
of
project
direction,
but
I
do
think
there's
distinct
roles,
but
it's
worth
codifying
so
even
yeah.
Even
once
we've
answered
the
question,
I
still
think
there's
something
to
think
about
here.
C
All
right
cool,
oh
jacques,.
M
I
I
don't
know
if
we
went
through
the
process
of
adopting
the
draft
charter
that
the
open
ssf
were
asking
folks
to
do
a
little
while
back
before
the
governance
review,
but
got
more
involved.
It
does
talk
about
maintainers
quite
explicitly
and
the
idea
of
a
steering
committee
who
are
composed
or
which
is
sorry
composed
of
those
maintainers.
M
So
it
seems
like
there's
some
overlap.
There.
A
It's
part
of
the
confusion,
yeah
and
I'm
not
very
familiar
with
the
openness
of
charleston.
So
forgive
me
but,
as
I
understand
it,
salsa
is
a
sub
project
of
the
supply
chain,
integrity
working
group,
so
that
has
it
it's
a.
M
Good
point
yeah,
that
would
be
where
like
charters
are
handed
out,
but
part
of
my
understanding
of
it's
kind
of
yeah,
it's
kind
of
tricky
because
there's
things
that
are
like
capital
p
projects
that
directly
hang
off
the
side
of
the
open
ssf.
So
six
story
is
an
example
or
the
gnu
tool
chain
initiative.
M
But
then
there's
a
lot
of
places
where
there's
projects
hanging
off
working
groups
that,
but
I
mean
salsa-
is
like
got
a
lot
of
a
lot
of
mass
yeah.
So
in
some
ways
the
supply
chain
integrity,
working
group
orbits
around
salsa,
rather
than
the
other
way
around.
M
So
I'm
not
I'm
not
sure
how
to
that's
a
good
point.
I
hadn't,
I
hadn't
thought
of
that.
I
think
I
had
thought
of
the
question
of
like.
Is
it
chatters
all
the
way
down
or
what's
the
dealio
or
whether
it
just
hangs
off
whatever
the
working
group
has?
Whether
the
working
group
defines
in
fact
who
are
maintainers
for
the
purposes
of
the
csl.
B
Yeah,
I
think
what
mark
just
posted
in
there
like
I,
I
do
think
we
should
just
bump
this
up
to
open
ssf
the
attack
level,
because
it's
a
fairly
common
thing
throughout
a
lot
of
the
conversations
we've
had,
because
also
I
know
one
of
the
other
big
conversations
is
just
around
hey.
We
have
a
lot
of
different
working
groups
that
all
sort
of
you
know.
How
does
the
secure
repositories
group
change
differ
from
this?
B
N
C
C
Okay,
so
I
am
going
to
share
my
stuff
here
in
a
second.
B
All
right,
so
I
want
to
show
off
a
couple
of
things
of
how
you
can
use
salsa
attestations
that
are
stored
in
recore
to
build
out
your
sort
of
supply
chain
graph.
So,
assuming
you
build
a
thing
and
you
rely
on
some
dependencies
and
you're
accurately
putting
those
dependencies
in
the
materials,
how
you
can
then
begin
to
sort
of
build
out
a
supply
chain
graph
and
you
can
potentially
use
policy
and
whatever
to
sort
of
assert
that
like
hey,
am
I
using
is
everything
in
my
supply
chain.
B
You
know
things
I
trust
and
and
so
on,
assuming
everything
is
using
salsa.
So
I
ran
a
a
nix
build
and
you
know
some
of
this
is
poc,
so
some
of
it
is
not
stuff.
I
literally
built
I
just
sort
of
took
the
metadata
that
salsa
did
and
sort
of
signed
it
with
my
key
just
to
sort
of
build
a
poc
here,
and
so
I'm
just
gonna
run
this.
It
takes
a
few
seconds
to
run,
but
pretty
much
what
it
does
is.
B
I
look
up
this
hash
in
the
recore
transparency
log,
download
any
attestations
associated
with
it
and
then
look
at
the
materials
in
those
attestations
and
then
recursively.
Follow
that
say:
hey
do
I
see
you
know
for
its
dependencies.
Do
I
see
salsa
out
of
stations
if
I
do
great
pull
those
down
and
keep
going
until?
B
I
can't
find
anything
else,
and
so
if
I
go
here
and
now
open
up
that
graph-
and
so
this
is
just,
I
believe,
xz
the
program
xz
and
if
I
go
in
here
and
let
me
go
and
format
it,
so
it
pulls
down
all
the
attestations
associated
with
that
supply
chain,
so
hey
for
xz.
These
are
all
the
packages
that
were
used
to
sort
of
build
it
and
then
down
here
are
sort
of
the
the
graph
right
like
so
this
hash
relies
on
these
hashes.
B
These
hashes
don't
have
any
dependencies,
or
at
least
no
found
dependencies
and
so
on,
and
so
then,
if
I
go
in
and
I
have
a
thing
that
will
just
go
out
and
generate
a
graphviz
of
it,
I
can
now
see
you
know
it's
once
again
graph.
This
is
not
the
greatest
at
the
layout,
but
you
can
see
here
so
I
have
xz.
B
You
know,
xz
relies
on
this,
which
is
pretty
much
the
source,
and
so
the
dot
d
or
v
is
kind
of
like
sort
of
just
saying
it's
not
that
I
just
rely
on
the
source
that
this
sort
of
relies
on
the
source.
It
actually
relies
on
sort
of
the
build
of
the
source.
So
this
is
what
that
is,
and
I
can
actually
go
through
and,
like
you
know,
look
through
here
like
it.
It
also
relies
on
this
bootstrapping
build.
B
It
relies
on
a
a
builder.sh
script,
it
relies
on
some
bootstrapping
tools
and
and
and
so
on,
and
so
I
can
see
you
know
somewhere
down
the
line
here.
It
relies
on
g,
lib
c,
there's
some
patches
it
uses
and
and
so
on,
and
so
this
sort
of
thing
that
you
know,
I
think,
is
sort
of
valuable
is
like
hey.
B
If,
as
we
sort
of
build
out
the
salsa
ecosystem
and
more
and
more
people
are
generating
salsa
attestations,
we
can
start
to
follow
those
salsa
attestations
to
kind
of
better
understand
our
supply
chain
and
then
be
able
to
say
like
hey.
Do
I
you
know
do
I
have?
Is
everything
in
my
supply
chain
using
you
know,
keys,
I
trust
or
whatever.
B
So
this
is
just
something
what
x
z
looks
like,
but
now
just
to
kind
of
show
you
maybe
what
the
some
of
the
issues
in
in
this
looks
like.
Is
I'm
not
going
to
run
it
because
it's
going
to
take
way
too
long,
but
let
me
show
you
what
a
hello
world
program
sort
of
looks
like
100
from
all
the
bootstrapping
and
everything.
B
This
is
what
that
graph
looks
like
it
would
take.
I
think
five
or
six
minutes
to
recursively
go
through
record
to
pull
down
the
hundreds
of
attestations
associated
with
it,
but
you
can
see
here
it's
like
thousands
and
thousands
of
lines.
B
Long
and
you
know
there's
tons
of
edges
between
all
of
this,
because
it's
literally
going
out
there
and
seeing
that
you
know
at
some
point
in
time
it
needs
to
look
at
you
know
a
bootstrapping
compiler
and
all
that
great
stuff
and
to
also
show
you
one
of
the
issues
here,
and
hopefully
this
shows
up
good.
It
might
be
a
little
hard
to
see.
B
Can
you
can
you
see
sort
of
my
my
thing?
There
awesome
okay,
so
this
is
the
unix
hello
program
right,
so
unix
hello
relies
on
the
source
of
hello.
It
relies
on,
you
know,
hey,
I
need
mirrors
to
know
where
to
pull
down
code,
so
it
relies
on
that.
It
relies
on
all
sorts
and
to
be
clear,
this
is
what's
required
to
actually
pull
everything
down
and
set
it
all
up.
B
B
This
png
here
is
over
40
megs,
and
you
know
here
is
what
that
sort
of
entire
graph
looks
like
and
it
looks
like
a
a
a
mess,
but
you
know
this
is
sort
of
the
thing
that
I
think
folks,
don't
necessarily
recognize
that
like
this
doesn't
just
include
the
libraries
that
were
used
to
make
up
the
to
make
up
that
hello
program.
B
This
also
includes
the
compiler
and
the
compilers
library
and
the
compilers
compilers
libraries
and
so
on
until
you
have
like
a
until
it
goes
to
just
like
the
the
default
binary
bootstrapping
stuff,
and
so
all
of
this
is
used
to
sort
of
make.
All
of
that-
and
you
know
it
most
of
the
stuff
sort
of
falls
under
this
bootstrap
stage:
euro,
glib
c
and
and
so
on.
B
But
anyway,
this
supply
chain
query
tool
that
I
wrote
up
and
I
hopefully
plan
to
expand
the
idea
behind.
It
is
hey
if
we're
all
starting
to
use
salsa
and
we're
all
pushing
to
let's
say
record
or
we're
pushing
to
the
attestation
to
oci
or
other
package
repositories.
We
can
start
to
go
back
and
recursively
query
those
salsa
attestations
to
go
and
build
out
a
better
understanding
of
our
supply
chain
to
then
make
some
of
those
future
policy
decisions.
B
B
Also,
I
saw
sorry,
I
saw
a
couple
of
comments
yeah,
so
I
did
try
out
a
couple
of
the
different
layout
engines
and
a
lot
of
them
also
still
come
out
really
really
gross
some
of
them.
It's
just
all
overlapping
and
it's
yeah.
I
think
once
you
have
whatever
this
is,
which
is,
I
think,
thousands
of
nodes
all
connected.
It
kind
of
becomes
a
bit
of
a
mess.
M
Jacques
yeah,
I
guess
my
first
thought
is
slightly
tangential,
which
is,
as
this
kind
of
thing
becomes
more
popular.
It's
the
n
plus
one
query
from
hell.
Yes,
we
might
wanna
signal
to
our
colleagues
in
six
store
that
this
is
in
their
future.
B
B
There's
also
other
problems
which
are
were
brought
up
to
six
store
as
well,
which
is
the
the
the
there's
there's
a
big
problem
with
also,
let's
say
I
have
an
attestation,
I
I
just
say
only
look
for
attestations
against
these
keys
right.
M
Are
you
aware
of
anyone
who
suggested
that
we
need
a
database
for
this?
That's
suitable.
B
For
querying
almost
like
a
universal
asset
graph
of
some
sort-
yeah,
it's
a
catchy
name
yeah.
So
there
is
some
discussion.
This
is
some
of
the
stuff
that
I've
been
working
with
brandon
lum
from
google
and
and
santiago
from
purdue
on
some
of
this
stuff,
there's
definitely
things
that
will
probably
have
to
be
caching
and,
and
so
one
of
the
ideas
behind
this
is
hey.
Maybe
we
run
this
query
once
cache
it,
and
then
you
know,
do
stuff
to
sort
of
refresh
that
cache.
J
B
Absolutely,
and
I
think
it's
something
that
when
we
are
looking
at
the
tools
that
generate
salsa,
attestations
we'll
have
to
think
about
how
we
define
those
materials
or
how
we
define
the
builder
elements,
because
right
now
in
here,
I've
also
included
the
builder
elements,
not
just
what's
included
at
runtime
to
just
show
like
if
you
wanted
to
include
everything.
This
is
literally
what
your
supply
chain
looks
like
and
just
to
kind
of
give
an
idea
real
quickly.
B
One
of
the
things
I
noticed
in
a
bunch
of
the
stuff-
and
this
is
something
I
was
brought
up.
If
you
want
to
compromise
the
supply
chain,
go
after
regular
expressions,
everything
relies
on
regular
expressions,
libraries,
everything,
and
so,
if
you
wanted
to
to
mess
some
stuff
up,
you
attack
that.
But
anyway,
yeah
tom.
O
Yeah,
I
so
so,
if
I
understand
correctly
this,
this
includes
not
only
the
things
that
are
aesthetically
linked
into
the
library
itself,
and
not
only
the
tools
that
were
used
to
to
to
generate
the
the
the
artifact,
but
it
also
includes
basically
what
we
would
call
the
build
service
right
like
like
hey
it
needed
to
fetch
things
from
this
from
this
location,
and
so
it
has
curl
right.
O
My
my
understanding
is:
is
that
at
like
higher
salsa
levels
that
that
that,
like
those
that,
like
those
fetching
operations,
that
that
would
be
the
responsibility
of
of
the
build
service,
and
my
my
intuition
is
that
that
stuff
should
not
be
included
in
the
in
the
materials
at
the
higher
level.
Do
we
like
do?
We
generally
have
have
have
agreement
on
on
that.
B
Yeah
yeah,
so
I
I'm
not
just
following
the
materials
I'm
also
following
the
builder
just
this
specific
sort
of
use
case
just
to
kind
of
show.
Oh
geez
like
what,
where
like.
If
you
really
wanted
to
understand
everything
and
how
potentially
assuming
assuming?
Let's
say
you
don't
trust
your
builder
for
a
second
and
you
want
to
validate
that
your
builders
using
all
the
right
libraries,
that's
what
this
would
look
like.
K
Jack,
so
just
to
point
on
that,
if,
if
you're
using
a
builder
and
and
say
your
builder,
does
go
and
grab
mirrors
or
something
right,
maybe
you
don't
want
that
to
be
part
of
the.
You
know,
attestations
or
a
dependency
that
you
want
to
list,
but
fundamentally,
if
you're
building
in
a
hermetic
environment,
it's
not
going
to
be
able
to
go,
get
those
mirrors
or
it's
not
going
to
be
able
to
go,
get
these
resources.
K
So
that's
why,
with
nix
anything
that
is
a
remote
thing
needs
needs
a
fixed
output
and
that's
the
only
way
you
get
network
access,
I'm
not
sure
what
other
solutions
people
come
up
with,
but
but
yeah.
If
you
have
a
builder
and
it
needs
something
you
might
want
to
know
what
that
something
was.
I
don't
know.
B
Yeah
yeah
no
definitely
agree
with
you
there
there
there's
some
interesting,
also
it's
sort
of
insights
into
sort
of
how
nyx
does
certain
things
that
I
think
is
just
things
that
we
might
want
to
just
think
about,
because
you
know
like
like
to
some
extent
the
way
that
sort
of
knicks
works
is
like
their
way.
It's
like
you
rely
on
a
build.
B
You
don't
necessarily
rely
on
a
package
and
you
just
sort
of
if
somebody
says
hey,
I
built
this
thing
and
I'm
sort
of
asserting
that
I
built
it
a
certain
way.
You
could
just
sort
of
pull
that
down.
Based
on
that,
so
there's
some
interesting
stuff
there
and
then
yeah
the
way
that
sort
of
nix
also
works
is
you
know
you
have
to
sort
of
specify
the
hashes
of
the
of
the
source
and
whatever
that
you're
sort
of
pulling
in
or
get
that
through
some
other
upstream
build.
B
Cool
the
other
thing,
so
I
put
in
the
document
the
code
for
my
scq
tool,
which
is
the
supply
chain,
query
tool.
The
reason
why
so
one
of
the
things
just
to
kind
of
highlight
real,
quick
one
of
the
reasons
why
I
did
it.
Also
this
way
is
there's
not
many.
B
If
you
look
at
record,
most
sort
of
salsa
associations
are
just
at
a
single
level,
maybe
a
two
level
thing,
so
I
sort
of
went
in
recursively.
I
I
built
a
poc
to
just
sort
of
go
out
recursively
and
do
it
and
do
and
and
do
all
that
the
other
thing
is
I'm
also
so
the
scq
tools
there
there
there's
there's
the
poc
for
generating
all
of
this
sort
of
stuff
based
on
a
nics
thing,
very
much
poc
there
and
then
the
other
thing
is.
B
I
have
a
pull
request
which
I'm
I'm
working
to
kind
of
get
sorted
out.
I
right
now,
today,
sig
store,
doesn't
or
cosign,
which
is
part
of
the
six
store
project,
doesn't
have
the
ability
to
attest
a
blob
or
a
test,
just
a
hash.
You
have
to
give
it
an
image,
and
so
I
have
a
pull
request
to
add
the
feature
to
allow
it
to
sort
of
a
test.
You
know
any
sort
of
blob
with
any
sort
of
hash
there
cool
and
that's
it
any
other
questions
or
comments.
I
One
thing
that
I
I'm
trying
to
figure
out
with
the
road
map
is
to
pull
like
one
thing:
I've
over
for
the
project
is
to
pull
people
together,
who
are
interested
in
these
various
projects.
So
that
way,
instead
of,
like
you
know,
there's
a
thing
here-
a
thing
here,
but
like
kind
of
make
a
concerted
effort
toward
adding
value
because,
like
michael
you
said
like
this
is
this
is
an
example
of
like
showing
like
the
value
of
sauce
and
how
you
get
to
have
visibility.
I
I
don't
think
we're
gonna
solve
in
this
meeting,
especially
the
next
couple
minutes,
but
maybe
something
to
think
about
going
forward
is
forming
like
working
groups
or
something
for
various
sub
problems.
Like
various
folks
talked
about
how
like
one
of
the
things
we
want
to
solve
and
is
listed
in,
the
roadmap,
pull
request
is
figuring
out.
Provenance
storage-
that's
like
one
example
sub
problem,
and
then
we
get
relevant.
I
You
know
whoever's
interested
in
this
can
get
together
on
some
regular
cadence
and
kind
of
come
up
with
a
design
come
up
with
a
initial
prototype
and
actually
like
build
something
out.
So,
just
something
about
going
forward
and
like
how
should
we
organize
these
type
of
efforts.
B
Yeah
def
definitely,
I
know
on
my
end,
I
know
from
some
of
the
folks
at
google
right.
You
know
I've
been
working
with
brandon
lum
on
on
some
of
that
stuff,
and
I
know
that
there's
there's
definitely
interest
in.
I
know
like
coming
from
very
much
a
space
of
like
hey
as
an
end
user,
like
somebody
who's
mostly
consuming
the
stuff.
B
What
do
I
want
to
see,
and
you
know
to
some
extent
this
is
sort
of
what
I
want
to
see
is
I
want
to
be
able
to
see
that
graph
I
want
to
be
able
to
go
in
and
say:
hey
is
everything
in
my
graph
using
stuff?
I
trust
you
know.
I
do
want
to
know,
for
example,
the
the
the
upstream
thing
of
like
oh
wow,
even
though
I
don't
do
anything
bad,
you
know,
even
though
I'm
not
you
know,
including
something
like
somewhere
up
the
chain.
B
I
I
have
this
problem
and
these
are
the
things
I
want
to
solve.
I
would
like
to
move
some
more
towards
that
model
of,
because,
right
now
I
think
it's
more
of
like
you-
should
do
a
b
and
c,
and
I
think
it
would
be
good
to
explain
like
here's
the
problems
I'm
trying
to
solve
to
kind
of
connect
it
to
real
world
problems.
I
think
that
what
you
just
said
sounded
really
good.
N
Just
don't
call
it
working
group
because
there
is
a
work
underway
for
new
governance,
where
basically,
there
was
already
working
group
concept.
I
think
salsa
would
become
a
sig
under
a
special
interest
group
in
the
under
the
new
governance
structure,
and
so
just
pick.
Another
name
could
be
task
force
whatever.
I
think
this
is
a
good
idea
by
the
way,
but
don't
reuse
the
same
term.
B
Yeah
cool
yeah
definitely
agree
on
that.
Don't
want
to
overload
there's
enough
overloaded
terms.
Okay,
we
only
got
another
minute
or
two
here.
Any
other
final
thoughts,
questions.