►
From YouTube: SLSA Meeting (February 9, 2022)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Sweet
looks
like
we
have
a
couple
demos
today,
I'm
just
looking
at
the
meeting.
The
meeting
notes
agenda
that
I
can
paste
in
the
chat.
A
Cool
all
right:
let's:
let's
kick
it
off,
joshua,
lock
and
treshank.
Do
you
want
to
kick
it
off
with
your.
C
It's
a
discussion,
sorry
guys,
no
demo
yet,
but
hopefully
you
know
once
we
solidify
discussion
a
bit,
we
can
show
you
some
nice
demos
joshua
feel
free
to.
Could
you
would
you,
would
you
mind
presenting
a
bit
I'll
I'll?
Do
the
introduction
lead
a
bit
and
then
I
can
take
over
from
concepts?
What
do
you
think.
C
C
Yeah
yeah
no
worries.
I
can
do
the
whole
thing.
Okay,
so
so
the
problem
is:
there's
a
ticket
open
for
it's
called
salsa
101,
I'm
sure
we
have
a
more
readable
name
for
it,
but
the
basic
idea
is:
how
do
we
distribute
attestations?
They
are
certainly
signed
by
some
keys
and
then
the
the
problem
is
okay.
Let's
give
you
a
visual
example
of
the
problem,
so
I've
got
all
these
artifacts
we've
got
statements
about
the
artifacts.
C
We've
got
sign
envelopes
about
the
attestations
and,
at
the
end,
what
you're
doing
what
you're
doing
is
shipping
a
bundle
of
attestations
and
each
of
this
attestation
could
map
to
something
like
a
job
in
your
ci
cd
pipeline
right
and
and
and
you
you
might
even
bundle
the
artifact
together.
Actually
so,
by
the
end
of
the
day,
what
you
want
to
do
is
know.
Okay,
somebody
signed
the
attestation.
Why
should
I
trust
it?
C
C
So
that
people
can
start
commenting
right
away.
This
is
what
we
want
people
to
do
and
I'll
paste
it
in
the
chat,
great
okay.
So
there's
some
goals
right.
So
that's
the
context
now
there's
some
goals
for
this.
We
we
want
a
mechanism,
a
simple,
yet
powerful
mechanism
to
discover
public
keys
used
to
verify
salsa
at
the
stations,
and
we
want
to
reduce
the
need
for
com,
complex
key
management
right.
You
want
some
some
some
properties,
a
key
management
like
maybe
you
want
keys
to
expire.
Maybe
you
want
things
like
threshold
signatures.
C
Maybe
you
want
to
say
things
like
three
out
of
five
of
these
keys
must
must
sign
for
the
other
stations
and
you
one
key,
revocation
built
into
the
system,
because
you
know
keys,
get
lost
and
stolen
and
whatnot
okay.
So
what
we
recommend
is
basically
something
that
we
tentatively
call
in
total
policies
and
the
idea
is
as
follows:
if
you've
seen
in
total
layouts,
the
idea
is
very
similar,
so
you
can
kind
of
think
of
in
total
layouts.
Okay,
so
salsa
has
got
something
called
in
total
attestations
right
in
the
classic.
C
In
total
world
they're
called
links.
Now
you
can
think
of
attestations
as
generalizations
of
the
links
idea.
Link
is
just
another
predicate
if
I
got
a
terminology
correctly
in
the
wall
of
in
dodo
attestations,
so
similarly
we're
taking
in
total
links.
Let
me
pull
that
out
actually,
instead
of
hand
waving
and
so
in
in
the
world
of
in
doto.
You
basically
have
all
of
these
links,
which
in
salsa
they
map
to
attestations,
okay,
so
just
think
of
this
as
data
stations.
C
C
Now
all
the
policy
says
is
there
are
all
of
these
steps
in
my
pipeline
and
each
one
will
produce
an
attestation
and
they
will
use
certain
keys.
So,
for
example,
oh
diana
is
going
to
use
a
set
of
keys
and
bob's
going
to
use
a
different
set
of
keys
and
so
on
now
we're
not
going
to
do
anything
as
complicated
as
an
inspection
at
all.
That's
not
the
point,
and
this
is
where
we
stop.
C
This
is
really
the
important
thing
we're
stealing
the
idea
of
in
total
layouts
to
basically
one
talk
about
the
shape
of
your
pipeline.
What
do
the
jobs?
What
are
the
steps
forget
jobs?
What
are
the
steps
of
your
supply
chain?
Look
like
number
one
number,
two
in
each
step,
who
I'm
sorry
what
what
keys
are
trusted
to
sign
that
attestation?
C
Great
feel
free
to
stop
me
and
interrupt
me
anytime
with
questions.
So
that's
really
it
it's
just
a
higher
level
layer
above
attestations
where
we
break
down
where
we
break,
we
break
the
pipeline
down
into
steps.
There
are
no
inspections,
we
break
things
down
into
steps
and
simply
map
for
now
which
keys
are
allowed
to
sign,
which
attestations.
That's
it.
C
C
First
of
all,
we
like
the
idea
that
the
rich
key
management
model
it
has
in
there.
You
can
do
things
like
threshold
signatures.
You
can
make
the
policy
expire,
so
you
don't
trust
it
indefinitely
and
we
want
to
open
the
door
in
the
future
to
something
like
inspections,
if
the
community
so
desires,
but
I
don't
think
well,
at
least
we
don't
have
to
worry
about
it.
C
Okay,
it's
a
function
f
and
x
is
all
of
the
art
all
of
the
source
code,
and
things
like
that
f
is
what
your
pipeline
is
supposed
to.
Do
you
get
an
artifact
called
y,
and
by
defining
this
infection
inspection
the
the
pipeline
cannot
misbehave,
that's
that's
it
but,
like
I
said
we're
not
worrying
about
this.
Now
all
we're
doing
with
policies
right
now
is
using
it
purely
for
key
management.
C
Good
now,
there's
only
one
little
problem
left,
which
is
that
the
policy
itself
is
self-signed,
so
that
makes
it
interesting
because
then
the
question
becomes
okay.
I
need
the
policy
to
tell
me
which
attestations
to
which
keys
I
should
use
to
to
verify
each
of
the
other
stations,
and
you
can
do
a
simple
thing,
like
all
attestations
are
signed
by
one
key
sure
why
not,
or
if
you're,
really
worried
about
separation
of
duties,
you
can
have
each
of
the
attestation
produced
by
different
steps
and
produced
by
literally
different
could
be
different.
C
Sorry
in
total
layouts
in
total
policies
are
also
self-signed,
so
we
have
solved
the
problem
with
distributing
many
keys
for
attestations,
but
now
we
have
to
worry
about
how
to
securely
bootstrap
the
initial
set
of
keys
that
you
need
to
to
trust
in
total
policy
for
that
we're
still
working
on
it.
That
is
not
the
point
of
the
discussion
today.
We're
working
joshua
and
I
are
working
on
several
policies.
C
Several
sorry
several
recommendations
which
we've
not
fully
thought
about
and
finished
yet
so
that's
work
coming,
but
we
want
to
focus
on
one
problem
at
a
time.
We
want
to
get
consensus
on
policies
before
we
even
discuss.
How
do
you
securely
bootstrap
policies,
because
otherwise
it
doesn't
make
sense
about
you
know
we
should
first
nail
this
problem
before
nailing
this
one
great
I'll,
stop
here
and
I
already
see
there's
some
questions.
Let
me
let
me
try
to
answer
them.
Jacques
said
life
model,
all
cryptosystems
are
key,
yes,
yes,
this
is
true.
E
Can
you
clarify
what
you
mean
by
you
want
to
solve
the
question
of
policies?
First,
I
didn't
quite
follow
that
part,
oh
sure,
sure
sure.
So
in
in
salsa
we
have.
C
C
E
So
this
is
independent
of
the
specific
layout.
This
is
simply
a
a
way
to
have
granular
claims
being
made
and
signed
by
different
keys
and
then
a
way
to
specify
and
check
that
after
the
fact
see
whether
or
not
it
complies
to
the
policy.
C
Correct
correct
exactly
you
can
think
of
it
as
a
way
to
compose
what
your
pipeline
looks
like,
which
I
think
salsa
doesn't
yet
have
right
now
I
could
be
mistaken.
Someone
please
correct
me
if
I'm
wrong,
I
see
I
see,
mark
has
raised
his
hand.
Let
me
let
me
quickly
finish
this
point.
Yes,
it's
a
way
to
compose
what
the
shape
of
your
pipeline
looks
like
right
now.
That
is
the
way
to
think
about
it.
F
Yeah,
I
I
think
it
would
help
to
write
out
what
the
use
cases
are
and
like
what
problems.
This
is
solving,
because
that's
not
clear
to
me
right
now,
the
like
this
is
proposing
a
particular
implementation,
but
I'm
I
think
salsa
could
be
used
in
a
variety
of
different
contexts
and
so
it'd
be
good
to
go
through
like
a
specific
example
of
like
like
so
for
one
like
it.
F
Would
this
be
used
within
a
company
for
like
their
first
party
builds,
or
would
this
be
used
for
open
source
projects
or
or
maybe
multiple,
and
if
you
could
describe
like
here,
is
the
properties
we
want
to
verify?
And
here
is
or
like
the
invariance?
We
want
to
ensure
through
salsa,
and
here
is
how
this
thing
accomplishes
that
or
plays
a
piece
in
accomplishing
that.
I
think
that
would
that
would
help,
because
I'm
I'm
having
a
difficult
time
like
making
that
connection.
C
Okay,
yeah.
No,
that's
that's
a
fair
comment.
Joshua
and
I
can
easily
work
on
that
sure
yeah
and
I
think
I
think
it's
also
worth
distinguishing
between
private
and
public
use
cases.
C
Yeah,
this
doesn't
have
to
take
a
lot
of
time.
Really
it's
actually
a
very
simple
idea:
it's
just
something
higher
level.
This
is
literally
what
the
policy
looks
like.
We
already
have
the
attestation
and
all
the
policy
says
is
hey,
for
example,
I
expire
on
this
date
and
time.
Don't
trust
me
beyond
that?
Please
read
me
for
what
I'm
about
here
are
all
the
keys
used
for
all
of
the
attestations
and
then
in
each
step
you
would
give
it
a
name.
C
You
would
give
it
a
threshold
signatures
and
just
say
refer,
which
key
id
you
mean
are
used
to
verify
each
attack
station
the
station
for
the
step
as
specified
here.
So
all
of
the
keys
are
mapped
earlier
beforehand
and
then
for
each
step.
You
just
map
and
say
hey.
I
want
to
threshold
this
keys
to
to
to
sign
off
on
this
station.
That's
it
it's
very
simple.
It's
deadly,
simple.
G
Can
I
ask
a
clarifying
question,
maybe
sure
so
is
this
sort
of
like
I'm
trying
to
like
sort
of
parse
the
like
the
proposal,
it's
kind
of
like
a
a
new
format,
implementation
that
other
people
can
understand
using
the
same
update
principles
that
tough
does
for
the
rest
of
the
metadata,
like
normal
metadata
in
normal
tough
distribution
and
this
basically
formats
metadata,
that's
understandable
to
clients
using
salsa
like
as
in.
G
C
That's
a
is
that
you
azra
yeah,
hi,
hi,
sorry,
because
I'm
not
able
to
see
who
was
talking
so
so.
Yes,
that's
a
that's
a
great
comment
thanks.
So
all
of
this
so
far,
although
it
looks
very
similar
to
tough,
because
that's
what
tough
and
in
total
share
they
share
a
lot
about
how
they,
how
they
talk
about
keys
literally,
has
nothing
to
do
with
talk.
Yet
that
comes
at
the
end.
C
Here
we
haven't
talked
about
how
to
securely
bundle
the
policies
and
and
the
policies
and
the
attestation,
the
bundles,
actually
so
far
we're
just
reusing
the
same
key
distribution
mechanism.
This
is
this
is
all
in
dodo
stuff.
Actually,
if
you
look
at
in
total
layouts
today,
the
original
in
dodo,
it
looks
exactly
the
same,
except
for
a
few
things.
We've
removed
to
simplify
the
problem
right
now,.
B
Yeah,
hey
trishan
joshua,
so
I
think
one
of
the
things
that
kind
of
I
had
question
about
is
like
what
the
extent
of
the
policy
is,
whether
you
know
it's
just
for
attestations,
or
should
it
go
deeper
into
it,
because
there
are
like
so
many
ways
in
which
you
can
use
keys,
to
extend
the
trust,
and
I
think
I'm
trying
to
figure
out.
You
know
what
what
do
you
envision?
B
Are
these
like
only
root
keys,
plus
the
x549
chains,
or
is
there
a
need
to
configure
how
certain
keys
are
being
used
and
so
on.
C
That's
that's
actually
a
very
good
question.
So,
in
fact,
if
you
look
at
it
today,
there
are
several
so
nothing
here
so
far.
I
should
clarify
nothing
here.
The
reason
why
we're
bringing
policies
that
is
actually
very
neutral
about
how
you
distribute,
let's
say
the
root
keys
of
the
system-
very
good,
excellent.
You
can
think
of
policy
as
your
in
dota
root
keys
and
then
you
can
reuse
x,
509.
In
fact,
if
you
look
at
i7.
C
C
Option
number
two
here
will
clearly
be
things
like
x509
or
option.
Number
three
might
be.
Oh,
I
don't
know
six
store
record
yeah.
There's.
Certainly
several
options
make
sense.
B
C
H
Yeah
my
question
was
essentially
the
same.
It
was
just
about
kind
of
rootkey
distribution,
but
I
guess
that's.
Yeah
we've
already
covered
that.
C
I
Yeah
I
mean,
I
think,
there's
several
different
things
here.
First
of
all,
I
I
do
want
to
foot
stomp
on
an
agreement
with
what
mark
ladonna
said.
You
know,
what's
the
use
case,
what's
the
problem
you're
trying
to
solve,
you
know
drilling
into
here's
the
format
of
the
json
don't
care
if
it's
not
solving
a
problem
and-
and
I
think
more
specifically,
I'm
deeply
uncomfortable
with
mandating
a
particular
format
unless
it's
absolutely
vital
to
do
so.
I'm
not
saying
it's
never
a
good
idea,
but
you
know
you
know.
I
I
think
the
goal
is
what's
the
requirement
for
what
are
you
trying
to
accomplish?
Why
and
then
hey
here's
a
format
that
might
be
useful
to
do
that
if
it's
going
to
be
mandated,
that's
a
whole
different
level
of
of
pain.
I
mean
right
now,
there's
a
should
on
in
toto
and
even
that
may
be
a
little
too
strong.
So
I
mean
I
is
I'm
not
saying
it's.
Never
a
good
idea.
Just
just
you
know,
wait
a
minute.
You
know
that's.
I
You
know
we
want
people
to
have
strong
supply
chain,
strong
supply
chain
integrity,
the
exact
formatting
on
how
they
represent
that.
Is
it
really
critical?
We
have
everybody
to
use
exactly
the
same
format.
I
don't
think
so.
I
C
Yeah,
no,
that's
a
very
good
comment.
Yeah,
maybe
maybe
maybe
I'm
not
sure
whether
we
said
must
here,
but
if
we
were,
we
were
not
careful
in
making
sure
that
this
is
a
recommendation.
We
will
certainly
clarify
that
yeah.
I
I
I'm
not
saying
you
can't
make
it,
but
just
you're
gonna
need
a
good
one
right
now,
I'm
not
even
sure
I
understand
the
use
cases
right
now,
so
you
know
not
even
being
sure
what
the
problem
is
you're
solving
and
it
makes
it
really
hard
for
me
to
believe-
and
this
is
the
one
way
it
must
be
done
if
that
makes
sense,.
C
J
C
I
C
C
Yeah,
and-
and
so
we
should
also
make
it
clear
that,
yes,
we're
not
mandating
anything.
This
is
this
is
the
same
level
of
prescription
as
attestations
are,
but
we'll
make
it
clear.
C
I'm
sorry
before
I
forget,
michael,
I
think,
had
a
comment.
Although
oh
there
we
go.
K
Oh
yeah,
I
I'm
sort
of
meandering
my
way
through
this
and
trying
to
figure
things
out.
I
think
that
what
david
said
is
probably
more
articulate
than
what
I
would
have
said,
but
I
like
I
look
at
the
various
tool
chains
and
I
think
that
you
know
you
talked
about
this
as
salsa
key
distribution.
I
think
this
is
a
key
distribution
mechanism
that
fits
into
one
of
the
possible
tool
chains
around
the
salsa
framework.
K
David
said
it
much
better
than
I
did
I'll
back
off.
Thanks.
K
Just
to
be
very,
very
direct
calling
this
salsa
key
distribution
puts
the
frame
of
the
reader
in
this
is
now
mandated
as
part
of
thing,
whereas
a
key
distribution
solution
called
fred
that
works
really
well
with
framework
salsa
in
concert
with
the
in
total
attestation.
Details
that
changes,
the
like
everything
you
just
said,
still
fits,
but
now
you've
contextualized
it
to
being
one
of
the
many
ways
that
this
can
be
done
for
david's
eloquent
speech.
I
Oh
my
gosh
yeah,
so
so
a
way
to
do
you
to
use
in
toto
to
support
salsa.
I
mean
something
like
that.
I
think
mike
windsor
is
exactly
right,
though
the
title
immediately
gets
you
off
on
the
wrong
foot
and
I
would
also
add
you
know
you
mentioned
use
cases.
You
said
use
cases
several
times,
but
I
I
think
it's
important
to
note
that
both
mark
and
I
didn't
just
say,
use
cases.
I
We
said:
what's
the
problem
you're
trying
to
solve
and
then
the
use
cases,
because
I
actually
don't
care,
I
still
don't
care
about
use
cases
unless
you
make
it
clear.
What
is
the
you
know
attack
or
what's
the
neat
reason
that
you
need
this?
I
think
that
you've
got.
I
I
think,
you've
got
it
in
your
head,
but
it's
not
showing
up
well
cease
is
not
clear
to
me
how's
that
it
may
be
a
problem
of
mine,
but
it's
not
it's
not
immediately
clear
to
me.
I
C
C
Great
okay,
so
we'll
make
we'll.
So
how
should
we?
How
should
we
discuss
this
going
forward?
Do
we
open?
Do
we
continue
on
at
github
ticket
or
do
we
should
we
have?
I
don't
know
another
discussion.
I
don't
know
two
weeks
from
now
that
is
joshua.
What's.
K
I
think,
come
back
in
a
couple
of
weeks
with
like
a
clear
articulation
of
the
problem
and
then
fleshing
out
from
there
would
be
fantastic.
That's
just
my
preference
I'd
love
to
see
it
that
way,
but
I'm
not
speaking
canon
here,
I'm
just
suggesting
how
I
would
see
progress.
C
F
I
I
think
this
actually
gets
into.
I
know
we
have
other
things
on
the
agenda,
but
because
it's
sailing
into
this
conversation
we
have
an
open
issue
about
having
a
like
an
enhancement
proposal
process
there.
F
I
forget
what
issue
number
it
is,
and
I
feel
like
this
would
be
a
good
candidate
for
that
where
we
have
various
folks
who
are
it's
not
necessarily
changing
salsa
itself,
but
we
want
to
get
feedback
on
this,
some
idea
in
the
salsa
ecosystem
and
we
it
would
be
valuable
to
have
a
way
to
like
loop
in
other
people
who
are
interested
and
want
to
participate
and
contribute
either
by
writing
it
or
reviewing
or
generating
ideas
or
etc.
F
F
I
might
recommend
that,
like
folks,
who
are
interested
in
this
like
either
being
reviewers
or
contributing
to
ideas,
could
maybe
tag
themselves
in
the
doc
or
contact
trishank
some
other
way
and
like
kind
of
iterating
in
that
smaller
group
and
then
once
it
kind
of
like
fleshes
out
ideas.
We
could.
We
could
present
to
the
larger
group
again.
M
A
I,
like
it
cool
awesome.
This
is
great
thanks
for
kicking
this
discussion
off.
H
Okay,
let
me
share
my
screen
here.
A
Maybe
just
give
a
quick
high
level
background
for
folks
that
weren't
on
the
call,
maybe
last
week,
what
you're
going
to
do.
H
So
going
to
be
demoing
the
active
state
platform,
which
is
our
kind
of
build,
a
build
system
for
pretty
much
or
the
aim
is
to
go
for
as
much
of
the
open
source
ecosystem.
As
we
can,
I
mean
we're
starting
out
with
our
traditional
ecosystems,
which
are
pearl
python
and
now
we're
moving
out
into
ruby
and
there's
some
java
work
on
the
horizon,
so
we're
kind
of
slowly
working
our
way
through
all
the
kind
of
major
ecosystems.
H
H
H
It's
the
auto
version,
which
basically
picks
out
the
latest
appropriate
version
based
on
all
the
other
constraints.
You've
got
in
the
system,
so
you'll
notice
that
we've
kind
of
populated
some
additional
dependencies
here
when
we
brought
this
in
what
happened
is
we
went
out
to
our
component
called
the
solver,
which
is
our
sat
solver
for
doing
dependency
resolution?
H
It
then
picked
out
everything
so
it
goes
across
and
it
picks
out
all
of
the
dependencies
required
for
that
module
in
the
perl
ecosystem.
But
we
go
one
level
deeper
in
that.
We
will
then
pick
up
things
like
levex
crypt,
which
is
required
to
make
sure
that
we're
compatible
with
all
the
different
versions
of
linux
that
you
can
install
this
on.
We're
also
going
to
need
openssl
and
zlib.
H
H
So
that's
my
project
updated
and
then
click
to
view
status
and
that'll.
Take
us
to
downloading
build
so
what
just
happened
there.
We
then
made
a
request
to
build
farm
to
go
and
build
these
two
things
and
it
went
off
and
discovered
that
we'd
already
built
all
these
things
and
basically
delivered
us
cached
output
from
previous
builds.
H
M
H
Okay,
so
what
we're
trying
to
do
is
provide
people
a
way
to
build
runtime
for
runtime
environments
from
open
source
components
so
that
they
can
then
develop
on
top
of
those,
it's
basically
dealing
with
dependency,
how
it's
dealing
with
making
sure
that
you
get
consistent
trusted
builds
and
it's
yeah
and
we
kind
of
wrapping
up
all
this
kind
of
some
of
the
some
of
the
stuff
that
comes
out
of
salsa,
like
the
hermetic
builds.
H
The
parameter
list
builds
and
all
of
those
kind
of
things
are
things
that
we've
been
thinking
about
for
a
while
and
we've
kind
of
brought
together
into
this
into
this
framework.
So
that
eventually
the
idea
is
that
you'll
be
able
to
kind
of
build
any
piece
of
open
source
with
with
the
platform,
and
you
will
be
able
to
use
it
as
a
foundation
for
the
development
that
you're
doing
on
top.
D
Okay,
you're
trying
to
solve
the
problem
of
instead
of
relying
upon
the
binaries
published
by
the
maintainers
in
their
releases
you're
building
from
source
for
your
entire,
your
entire
dependency
tree
exactly.
H
Got
application
so
yeah
we
we
download,
we
ingest
source,
we
verify
the
source,
we
maintain
all
the
metadata
about
the
source,
so
we
have
an
offline
cache
of
all
the
source
that
we
build
and
that
you
can
see
what
you
can
see
a
little
bit
here
and
how
it's
working
so
the
first
thing
that
it
does
is
it
downloads
builder?
So
that's
our
build
script
and
in
these
downloading
it
also
validates
them
against
their
checksums.
H
We
then
download
into
so.
This
is
running
each
one
of
these
builds
is
running
an
isolated
container.
That
container
is
bare
bones.
It
doesn't
contain
anything
else
from
the
build
out
of
the
out
of
out
of
the
box,
so
we
provide
it
with
a
configuration
file
to
say,
okay.
Well,
this
is
what
you're
building
this
is
what
you're
building
it
with,
and
these
are
its
build
time
dependencies
and
then
the
build
time
dependencies
are
downloaded
individually
into
this
container.
So
you
can
see
it's
downloading
a
whole
bunch.
H
It's
downloading
some
patches
and
you
see
yeah
it's
bringing
down
like
okay,
so
that
it
needs
the
mozilla
ca
in
order
to
fulfill
net
ssl
airway.
So
there
all
the
build
time
dependencies
are
there
some
of
the
things
that
we
do
as
well.
I've
got
some
questions
about
later,
which
I'll
bring
up
in
a
bit
is
because
we
build
in
these
isolated
directories
quite
often
well,
in
fact,
for
a
large
number
of
our
ingredients,
we
need
to
relocate
them
on
install.
So
basically
we
do
things
like
okay.
H
So
if
you've
got
paths
burnt
into
something
like
pearls,
libslash
config
heavy.pl,
they
would
typically
represent
the
build
environment
and
what
we
need
to
do
is
when
we
come
to
deploy
them.
H
We
can't
rely
on
something
like
the
way
that
nixos
does
it
with
a
sim
link
farm,
because
this
one
is
being
done
on
windows
and
sim
links.
Just
don't
work
on
windows,
so
we
actually
rewrite
some
parts
of
the
artifact
on
deployment.
H
H
This
runs
in
this
case.
It's
a
bootstrap
script
called
build.bat,
and
these
parameters
here
are
drawn
from
our
constrained
set
of
parameters
that
you
can
provide
to
to
builders.
So
we
have
for
for
this
one.
We
need
to
tell
net
sslea
why,
where
to
find
the
open
sales
ssl
library?
So
we
do
this
with
an
environment
variable
that
is
understood
by
the
builder
for
net
ssl
ea
and
then
the
builder
basically
bootstraps
running
the
makefile.pl.
N
Could
I
ask
you
sean
quick
question,
john,
oh
david.
Go
ahead.
I
Okay,
I
was
just
gonna
ask:
would
you
argue
that
your
current
environment
meets
salsa,
say
salsa,
one.
H
I
think
I
think
we
could
get
as
far
as
salsa
three.
I
think
the
problem
that
we
have
is
we
have.
We
have
an
ingestion
problem
in
that
we
cannot
take
attestations
for
the
source
provenance
too.
H
Well,
at
the
moment,
we
don't
know
whether,
for
example,
the
rehab,
the
repo
is
configured
for
multiple
reviewers,
so
that
level,
you
know
we
kind
of
a
step
up
in
the
in
the
in
the
chain
from
there,
and
we
don't
necessarily
know-
and
at
the
moment
we
can't
extract
the
information
about
commits
or
pull
requests
or
any
any
of
that
configuration
about
how
the
source
code
works
or
how
the
source
code
has
been
created
and
released
so
that
we
we
still
struggle
with
a
little
bit
and
at
the
moment
we
don't
do
kind
of
any
of
the
attestation
part.
H
So,
although
that's
something
that
we're
planning
to
kind
of
build
in,
I
think
you
know
in
terms
of
the
spirit
of
it,
we've
got
the
mechanics
to
do
everything
to
salsa
level,
three,
maybe
even
source
level.
Four,
but
a
moment.
We
can't
even
really
claim
source
to
level
one,
because
we
don't
have
the
data
on
the
the
source
code
that
we've
ingested
to
to
the
right
level
of
detail
and
we're
not
providing
attestations
about
what
we're
doing.
F
Yeah,
yes,
so
yeah.
I
guess
for
that
particular
point
I
think
also
just
as
a
reminder,
the
the
salsa
spec
like
doesn't
require
any
particular
format.
So
if
the
data
is
there
and
it
kind
of
meets
the
requirements
I
feel
like,
we
should
clarify
in
the
spec
that
if
an
organization
is
doing
this
and
achieving
like
effectively
meeting
the
levels
and
stopping
the
threats,
if
it
doesn't
have
to
be
in
any
particular
format
as
long
as
kind
of
whoever's
consuming
it
and
it
you
know,
has
it
accepted
in
that
format.
F
I
had
a
question.
You
said
something
about
rewriting
something
or
other
on
deployment,
and
I
didn't
follow
that.
Could
you
go
into
a
little
bit
more
detail.
H
Yes,
so,
for
example,
so
what
we're
doing
here
is
it
we
will
build?
Let
me
see
if
I
can
show
you
but
yeah.
We
will
build
into
an
isolated
directory.
So
when
we
build
our
output,
let's
take
a
look
at
where
the
output
goes
for
this
particular
build.
H
We
have
an
isolated
output
directory
which
goes
into
this
outputs
directory,
which
is
unique,
and
so
all
of
the
code
that
we
build
gets
deployed
there
during
the
build
when
you
come
to
deploy
it
on
a
user's
machine
or
when
you
want
to
come
to
consume
that
artifact
in
any
other
way,
any
paths
that
are
hard
coded
into
the
artifact
as
part
of
the
natural
build
so,
for
example,
pearl
bundles
in
a
whole
bunch
of
things
about
you
know,
parts
to
compilers
passed
to
where
the
perl
core
lives
and
things
like
that
they're
all
in
a
config
file.
H
We
take
that
we
we
have
information
about
that
config
file
and
where
it
has
hard-coded
paths
and
how
they
should
be
rewritten,
and
we
write
that
into
a
metadata
file
that
we
put
alongside
inside
the
artifact.
H
F
Yeah,
so
is
this
is,
is
this
for
so
this
is
for
cases
where
there
is
some
hard-coded
path
in
the
build
process
like
ideally,
there
would
not
be
such
a
path,
but
this
is
a
work
around
for
cases
where
there
is.
H
There
are
a
lot
I
mean
even
going
down
to
c
libraries
like
libxml,
you
know,
xml,
the
xml2
comes
with
like
a
little
config
script,
called
xml2
or
xml
config
dot,
sh
that
you
run
to
find
out
what
your
link
line
would
be
and
so
similar
for
package
config
files,
where,
if
you
want
to
do
package,
config
libs,
whatever
library-
and
it
will
tell
you
which
libraries
you
want
to
link
against
so
that
you
can
get
a
full.
H
You
know
you
can
get
a
full
link
of
something
those
things
typically
have
hard-coded
paths
burnt
into
them
and
we
need
to
rewrite
them
so
that
they're
accurate
for
the
deployed
environment.
So
that
was
you
know.
That
was
one
of
the
questions
I
had
is.
Does
that?
Does
that
step
need
its
own
kind
of
attestation,
but
yeah
we'll
come.
F
H
For
those
things
that
do
I
mean
you
can
see
that
you
know,
there's
we
rewrite
some
files
from
some
other
distributions,
but
others
we
don't
so
yeah.
There's
like
there's
a
whole
bunch
here
where
we
do
it
don't
do
any
rewriting-
and
here
we
do
kind
of
some
of
that,
because
because
our
build
system
not
only
produces
the
artifacts,
but
it
consumes
them
as
inputs
to
other
builds.
We
have
to
do
that
right.
We
have
to
do
that.
H
Relocation
on
build
as
well
so
yeah
you'll,
see
it
happening
in
here
and
you'll
see
the
the
actual
tools
that
we
use
to
deploy
it.
I
think
it.
You
know
it's
probably
true
of
any
installation
mechanism
where
you
will
make
modifications
to
the
things
that
you're
deploying
partly
based
on
where
you're
deploying
them
and
partly
based
on
other
other
things
that
are
specific
to
the
environment
you're
deploying
in
so
anyway.
This
gets
us
to
not
necessarily
ey
and
everything
else
having
been
built.
Here's
another.
H
There's
another
thing
where
we,
you
know
another
case
where
hermeticity
is
something
we
might
end
up
breaking
as
we
discussed
last
week,
sometimes
test
suites
require
you
to
break
out
of
the
hermeticity.
H
So
at
the
moment
we
are
modeling
tests
as
a
separate
step
so
that
we
can
give
the
tests
their
own
security
requirements
so
that,
if
we
do
want
to
run
them,
we
can
run
them
with
degraded
security
in
order
to
allow
them
to
do
what
they
need
to
do.
H
So
that
gets
us
to
a
build
and
that
build
is
essentially
the
same
modules
with
slight
variations
for
platform
compatibility
on
all
the
platforms
you
put
in
and
you
can
put
in
there's
a
variety
of
different
linuxes.
There's
windows:
there's
a
mac
as
well,
which
supports
a
variety
of
mac.
Os
releases
once
you've
actually
built
this.
H
Well,
I
want
to
demonstrate
one
other
thing
that
we've
got
an
experimental
feature
that
we've
got
at
the
moment
which
you're
working
on
the
moment,
which
is
generating
software
builder
materials
for
any
build.
So
we
have
an
endpoint
with
our
mediator,
which
is
a
graphql
endpoint
for
the
platform
where
I
can
say:
okay.
H
Again,
we're
still
yeah
one
of
the
things
that
we're
still
looking
at
you
know,
which
is
why
I
was
interested
in
in
trishank's.
Prevention
presentation
is
selecting
a
pki
for
signing
these
things
and
for
other
for
signing
our
artifacts,
so
we're
working
on
that
too,
but
yeah
there's
so
there's
mechanism
that
we've
got
built
in
based
on
the
metadata
that
we
hold
about
all
of
these
things
that
we
can
generate
software
builder
materials.
H
So
the
idea
of
these
is
that
we
are
initially
generating
completely
virtualizable
environments,
so
something
like
pip-m,
something
like
pearl
brew
or
something
like
that.
We're
building
virtualized
environments
for
running
your
your
distributions
and
those
include
the
kind
of
the
the
lower
level
dependencies
as
well,
whereas
pearl
brew
and
and
pie
m
will
only
take
you
down
to
those
components
that
live
within
the
ecosystem.
We
will
take
you
down
to
the
c
libraries
as
well,
so
we're
virtualizing.
H
We
can
virtualize,
you
know,
mysql,
we
can
virtualize
postgres.
We
can
yeah
as
part
of
all
of
all
of
these
things,
we'll
virtualize
all
the
way
down
to
the
level
that
we
build.
H
This
one
is
again
going
back
to
our
solver.
This
one
hasn't
actually
downloaded,
but
then,
basically
because
of
all
of
those
individual
items
were
built
as
separate
artifacts,
it
downloads
them
all
and
installs
them
all,
and
so
basically
you
know
in
terms
of
using
it
in
a
cicd
pipeline.
We
keep
our
caches
pretty
warm.
So
if
you
wanted
a
consistent
runtime
for
your
project,
usually
it's
just
a
few
seconds
of
download
away
and
again
it's
completely
virtualized.
H
One
of
the
things
that
we
do
on
linux,
at
least
is.
We
are
quite
cunning
with
things
like
our
paths
so
that
we
don't
have
to
set
ld
library
path
as
part
of
our
virtual
environments,
so
yeah,
okay,
you
can
pull
in.
I
o
socket
ssl,
for
example,
without
having
to
set
ld
library
path,
pretty
sure
this
one
time
doesn't
set.
It.
I
I
vaguely
remember
that
being
controversial,
setting
our
paths,
it
is
it
isn't
it
isn't,
I
mean,
forbids
it,
so
their
packaging
system.
H
Ld
library
path
overrides
our
path,
so
you
can
use
it
in
preference,
but
we
have
customers
who
are
already
using
ld
library
path,
and
so
they
are
doing
that
for
their
own
reasons
and
for
their
own
libraries
and
so
to
avoid
interfering
with
that
and
having
to
modify
their
ld
library
path.
On
top,
we
burn
our
paths
in
so
that
everything
is,
is
internally
consistent
and
we
burn
them.
We
don't
burn
them
in
as
full
paths.
We
burn
them
in
as
relative
paths
to
dollar
origin.
M
I
had
just
a
follow-up
question
at
a
point
you
made
before,
which
is
you
mentioned
that,
like
you,
don't
have
the
ability
to
verify,
for
example,
if
a
project
has
two
two
approvers
right
and
things
like
that
around
the
actual
project,
so
my
understanding
was
that
salsa
is
not
transitive
right.
So
are
you
implying
that
you
need
to
know
that
about
all
the
things
that
you're
building
or
just
what
you're.
H
There's
some
interesting
there's
some
interesting
nuances
around
that
yeah.
M
H
Yeah,
so
I
mean,
I
think,
the
other
thing
that
we're
discovering
as
well
is
that
if,
if
we
do
get,
if
we
do
start
to
have
transitive
effects
of
sorts
of
levels,
you
then
have
to
worry.
You
start
to
think
about
closures
within
delivered
artifacts,
because
you
may
say:
okay.
Well,
you
know
this
entire
build
that
I've
got
here.
H
Not
everything
depends
on
everything
else,
so
you
couldn't
necessarily
say.
Okay,
there
is
one
salsa
level
that
applies
to
this
entire
build
because
you
may
have
different
sorts
of
levels,
for
you
know
all
of
the
individual
components
and
if
they
have
transitive
relationships
and
that
affects
their
social
level,
you
can't
say
as
much
about
each
well,
you
can
say
more
about
the
ones
that
appear
at
the
top
level,
but
because
they're
not
necessarily
related.
H
You
know,
if
I
add
in
another
package,
so
if
I
added
say,
for
example,
dbi
the
database
connectors,
that's
not
necessarily
related
to
ios
socket
ssl
and
we
might
get
a
build
of
complete
build
of
io
socket
ssl,
which
is
also
level
four,
but
because
some
dependency
of
dpi
is
only
source
of
level
three,
if
it
has
a
transitive
effect
on
dbi's
level,
that's
a
different
closure,
and
so
it
has
a
different
source
level.
So
this
build
may
well
have
different
source
levels
within
it.
H
H
What
we
currently
do
is
we
draw
the
source
direct
from
the
ecosystem
repository,
so
whether
the
ecosystem
tells
us
these
these.
These
are
that's
where
we
get
them
from
so
for
pearl,
we'll
get
them
from
cpan
from
will
it
at
least
get
the
locations
from
cpan
and
for
pipi
the
same
if
the
source
code
is
uploaded,
we'll
get
it
from
pipeyi
the
you
know
the
underlying
things
that
don't
have
an
ecosystem
like
c
libraries,
we
will
get
direct
from
their
their
source
repositories.
H
Yes,
you
know
we,
some
of
those
repos,
don't
actually
contain
anything
like
a
checksum
or
a
or
a
digital
signature
for
these
things.
So
we
are
looking
at
now
because
we
get
the
one
of
the
things
that
we
scrape
off.
H
The
reboot
is
the
the
source
code
repository
where
it's
available
then
we're
starting
to
look
at
moving
the
ingestion
pipeline,
such
that
it
will
look
further
back
so
we'll
go
back
to
github
and
go
and
get
artifacts
from
github
organic
source
artifacts
from
github
and
there
we
will
get
checksums
and
potentially
gpg
signatures
that
we
can
validate
so
we're
looking
at
you
know,
that's
that's
something
that
we're
kind
of
extending
out
to
now,
but
initially
all
of
our
pointers
are
coming
from
the
the
ecosystems,
because
that's
the
one
central
place
we
can
go
and
get
everything.
M
Got
it
sorry,
one
more
question,
so
the
idea
here
is
like
this
active
state
platform
right
you'll
build
it
once
and
then
you
might
have
hundreds
or
thousands
of
consumers
of
that
securely
built
package,
not
for
everybody
to
like
kind
of
do
it
on
their
own,
which
is
what
the
industry
has
been
doing
until
now.
M
H
Yep-
and
you
know,
I
was
wondering
as
well
whether
whether
the
the
the
you
know,
the
log
files
that
we
actually
collect
are
also
valuable
data.
I
mean
we
think
they
are
better
and
some
of
our
users
think
they
are.
We
wondered
whether
this
was
additional
evidence
about
us.
Having
done
what
we
said,
we'd
do
in
an
attestation
and
whether
whether
logs
should
be
treated
as
a
as
artifacts
in
their
own
right.
H
Okay,
mark
you
have
another
question.
H
Okay,
so
yeah,
I
think
you
know
that
kind
of
shows
where
we
come
where
we're
coming
from,
and
you
know
the
the
ideas
we
had
before
we
even
kind
of
came
across
salsa.
H
You
know
we
were
drawing
from
things
like
next
things
like
things
like
basil,
we're
looking
at
kind
of
hermeticity,
reproducibility
and
basically
guaranteeing
that
sort
of
thing
and
making
sure
that
our
environment
provided
everything
needed
to
do
that
and
then
yeah
okay,
then
we
threw
berlin
python
at
it
and
discovered
that
you
know
some
of
those
things
aren't
quite
as
nice
and
hermetic
as
you,
as
you
might
think
so
yeah
and
we're
working
around
that
we've
we've
found
the
case.
I
think
the
only
case
so
far
we've
got
is
test.
Suites
and
authenticate.
M
Yeah
for
test
suites,
could
you
distinguish
between
maybe
tests
that
are
like
critical
and
actually
are
testing
things
that
are
important
right,
like
I'm
saying
from
a
security
perspective
versus
and
actually
having
that
network
access
could
be
harmful
because
somebody
could
go
in
and
make
the
test
succeed
where
it
really
should
have
failed
versus
maybe
tests
that
are
just
more
like
feature
specific.
H
Yes,
are
we
happy
it's
hard?
I
think
you
know
for
things
like
okay,
the
io
socket
ssl
one
we
would
have
to
you
know
we
would
have
to
kind
of
build
a
sandbox
and
that
we
could
do
that,
and
we
would
have
to
potentially
do
that
for
everything
that
went
outside
so
at
the
moment,
we're
starting
to
do
some
monitoring
on
our
on
our
build
instances
to
make
sure
that
you
know
where
we're
denying
egress
we're
recording
it
so
that
we
know
which
packages
are
trying
to
get
out
onto
the
internet.
H
To
do
certain
things.
Yeah-
and
you
know
like,
like
I
mentioned-
I
think,
before
we're
treating
running
the
tests
as
a
separate,
build
step,
and
so
the
output
of
that
build
step
is
a
set
of
test
results
that
we
would
probably
treat
as
a
separate
artifact
in
its
own
right
as
well.
M
I
I
actually
have
a
similar
question
we're
running
out
of
time,
but
I
would
love
to
have
some
idea
of
some
categories
of
you
know.
Here's
where
the
hermetic
stuff
doesn't
work,
because
I
mean
there's
already
discussion
in
there.
You
know
I
think
hermetic
stuff
has
its
place.
If
it's
too
hard,
can
we
separate
out
the
things
that
are
important
and
the
things
that
are
less
important?
I
D
I
For
certain
kinds
of
tests,
as
long
as
they
don't
affect
the
build
result,
they
may
affect
the
test
result,
but
then
it
won't
affect
the
build
result.
So
we
we,
it
would
be
helpful
to
have
more
information
about
what's
actually
going
on
so
that
you
know
there
is
the
question
about
what
should
there
be
tweaks
to
the
salsa
definitions?
But
first
step
is:
what's
the
real
world
situation,
so
we
we
don't
want
to
back
off
where
it
doesn't
make
sense,
but
maybe
we
do
need
to
back
off.
H
Yeah
I
mean
we're
gathering
that
information
now.
So
that's
that's
part
of
the
thing
we're
doing
with
our
egress
monitoring
is
to
see
whether
whether
these
things
so
far,
we
don't
have
anything
that
fails
to
build
that.
We
haven't
been
able
to
work
around
so
like
pearl's
alien
ecosystem.
So
there's
like
a
alien
lib,
xml,
they're
kind
of
shims
to
pull
in
external
libraries,
so
they'll
be
alien,
lib
xml,
which
goes
off
and
literally
downloads
the
source
code
to
lib
xml2
and
builds
it
in
line.
H
H
We
are
carving
out
into
separate,
build
steps
so
that
things
like
authentico
signing
you
know
the
initial
idea
was
that
we
would
do
that
in
line
in
the
container,
but
because
it's
non-hermetic
and
because
we
want
to
also
have
different
security
requirements
on
the
node
in
the
cluster
that
manages
the
key
material.
H
We
split
those
out
into
a
separate
step
that
runs
on
a
different
node,
so
things
like
that.
We
are
carving
these
things
out
so
that
you
know
the
core
of
our
bills
are
always
as
hermetic
as
we
can
make
them,
but
where
we
get
other
use
cases,
we're
carving
them
out
into
separate,
build
steps,
and,
as
we
gather
the
information,
then
yeah,
I'm
happy
to
kind
of
provide
that
feedback
on
what
it
and
what
use
cases
we
have
that
are
not
reasonably
achievable.
Hermetically.
A
Well,
thanks
sean.
This
is
this
is
awesome
good
discussion
too
tom,
I'm
gonna
give
you
the
last
five
minutes.
If
you
want
to
follow
up
with
anything
tom
said,
I
want
to
plug
your
the
request
for
comment.
I'm
not
sure
if
you
want
a
screen
share,
but
I
can
copy
that
in
the
in
the
chat.
O
O
Someone
else
has
has
certified
that
that
artifact
as
as
meeting
and
in
addition,
it
captures
the
salsa,
the
transitive
salsa
level
of
the
dependencies
of
those
of
those
artifacts,
so
that
so
that
with
his
attestation
you
can
say:
okay,
the
the
the
top
level
artifact
is
salsa
3
and
it
has,
and
it
has
the
minimum
transitive
level
of
all
of
its
dependencies
is-
is
salsa
2.
2
for
for,
for
example,
this
has
this
has
a
couple
of
advantages
which
are
described
in
the
in
the
pr.
O
I
think
it
I
think
one
of
the
use
cases
is
is
is
what
sean
was
was
showing
us
earlier
where,
where,
where
there
are
all
of
these
different,
build
steps
that,
like
might
that
like
different
salsa
levels,
might
might
might
apply
to
to
to
to
different
steps
and
that
it
lets
you
make
a
like
it
lets
you
make
the
decision
in
like
one
place
and
then
reference
that
decision
later,
without
needing
to
bring
all
of
the
evidence
along
for
all
of
the
dependencies
in
the
entire
build
graph,
which
can
be
very
which
can
be
very
cumbersome.
A
Cool
awesome.
Well,
I
think
I'll
give
you
guys
two
minutes
back
thanks
everyone.
We
can
try
to
do
some
more
intros
next
week
or
next
meeting.
If
we
have
some
time,
I
think
we
already
are
lining
up
a
few
more
demos
for
our
next
meeting
and
hope
you
all
have
a
great
day.