►
From YouTube: SLSA Biweekly (April 13, 2023)
Description
Meeting notes: https://docs.google.com/document/d/1cx3fOBfic6A0xc2on25ITK4vQHUdxgBmJoSS1LPqDJo/edit
B
D
B
B
B
B
B
A
B
A
B
Really
really
I
I
do
want
to
commend
Mark's
hard
work.
Really
it's
it's
awesome
to
see
we're
doing
a
big
push
to
make
people
aware
of
it
and
I
mean,
of
course
the
risk
is
hey
great.
It's
coming
to
oh
and
and
there's
more
work
to
do,
but
but
I
do
think.
Congratulations
you
know
of
where
we
are
now
is
absolutely
in
order.
F
G
E
H
Okay,
it's
five
past
the
hour.
I
think
we
should
get
started
as
always.
Please
register
attendance
in
the
Minimates
which
are
just
pasted
in
the
chat
and
a
reminder
to
buy
by
the
Linux
Foundation
code
of
conduct,
which
is
in
a
link
two
inches
thanks.
Everyone
for
joining
for
our
monthly
salsa
community
meeting.
First
I'd
like
to
take
time
to
welcome
any
new
members.
If
you
want
to
briefly
say
hi.
H
It
might
not
be
anyone
there.
Well
if
you,
if
you
want
to
speak
up,
we're
always
happy
to
say
hi.
If
I
missed
someone,
we
could
jump
into
the
special
interest.
Group
updates.
I,
look
at
the
list.
I
think
most
folks
are
already
aware
of
this,
but
we
have
a
1.0
release
planned
for
next
week.
The
plan
is
to
merge
the
changes
in
Market
as
approved
on
Tuesday
April
18th,
and
then
send
out
an
announcement
on
Wednesday
April
19th.
H
H
H
Changing
the
okay,
I'll
I'll
give
a
summary
a
second.
We
had
a
long,
a
bunch
of
feedback
that
results
in
editorial
changes
that
doesn't
really.
It
wouldn't
be
a
breaking
change
to
the
specification,
and
so
in
order
to
get
something
out
the
door,
we
decide
to
release
what
we
have
and
then
kind
of
work
through
the
editorial
cleanup
works
like
there's
things
around
turn,
can
more
consistent
terminology
and
making
things
a
little
bit
more
clear.
H
H
The
other
major
changes
are
division
into
multiple
tracks,
which
I'll
talk
about
in
a
second
simplifications:
new
guidance
on
verification
and
updated
schemas
for
our
recommended
formats.
So
in
terms
of
stability,
1.0
is
a
stable
release.
It
is
not
necessarily
one
point:
it
doesn't
Mark
like
it's
complete.
H
It
contains
everything
we
want
to
do,
but
rather
it's
a
stable
foundation
on
which
we
could
add
further
breath
and
depth
in
the
future,
in
particular
the
what
was
in
the
Old
Source
requirements
like
two-party
review
and
retention
of
source
code
is
not
currently
in
the
1.0
spec.
What
was
called
Salsa
level
four
before
hermetic
builds
is
also
not
a
requirement,
because
we
kind
of
undefined
that
level
temporarily
and
also
what
was
previously
in
the
common
requirements
are
now
more
guidelines.
H
It
doesn't
mean
they
can't
become
requirements
of
future.
Just
that
we
didn't
get
have
enough
consensus
to
be
able
to
like
solidify
that
and
call
something
stable,
that
we
know
won't
change
in
the
future.
The
other
major
change
is
tracks.
Previously
we
had
a
just
logically
one
track:
salsa
levels,
one
two,
three
four
and
everything
was
bundled
into
this
one
set
of
levels.
We
decided
to
break
it
down
into
different
tracks,
each
with
our
own
set
of
levels
that
describe
particular
aspects
of
supply
chain
security.
H
H
H
G
G
Sure
so,
the
the
past
month
we've
Jennifer
Bligh
on
the
final
press
release
for
the
1.0.
It
was
finalized
and
blessed,
it
seems
and
it
will
go,
live
April
19th,
given
that
salsa
gas
on
April
18th
in
terms
of
other
announcements,
around
1.0
there's
been
a
series
of
blogs
that
we've
been
working
on.
Mike
created
the
breadth
and
depths
of
salsa,
which
is
now
live
separately.
G
G
G
Any
questions
on
that
before
I
continue
nope
so
for
the
road
map
discussion,
as
you
may
or
may
not
be
aware
of
I'm
going
to
share
this
actually
I'm
not
going
to
share
it,
because
I
have
too
many
Chrome
windows
open
and
last
time,
I
tried
to
share
I,
put
something
IBM
confidential,
so
I
I'm
not
going
to
share
my
screen,
but
there's
a
link
to
the
roadmap.
If
you
go
to
slide
three
flight
two
and
slide
three
are
almost
the
same.
G
G
I
Yeah
I've
been
thinking
more
about
this,
and
a
colleague
suggested
that
perhaps
it
could
be
useful
instead
of
doing
exact
dates
or
even
half
recorder
estimates.
We
do
something
like
we're
working
on
this
now
we're
working
on
this
next
and
then
we'll
never
work
on
this.
So
you
have
three
buckets
that
are
ordered
against
each
other,
but
not
necessarily
with
deadlines
that
we
could
miss
and
okay.
F
I
definitely
like
that
it
kind
of
flows
in
with
with
the
way
I've
seen
a
lot
of
successful
projects
sort
of
work.
Any
kind
of
Flo
follows
that.
Also
it's
slightly
different
than
you
know,
your
must
should
could
would
won't,
but
I
I've
seen
this.
That
sort
of
model
be
quite
successful
so
that
folks,
don't
constantly
say
Hey.
You
missed
the
date
on
this
thing
and
I
was
prepping
for
it,
especially
when
you
know
it's.
That's
not
the
intention.
G
A
I
E
E
G
Okay,
so
then
I,
don't
I,
don't
know
how
you
want
to
handle
this
Mark
in
in
this
meeting.
I
would
like
to
get
some
feedback
on
this.
We've
been
trying
for
some
time
to
do
it
asynchronously
and
offline,
and
we've
not
gotten
any
feedback
so
I'm,
hoping
that
we
can
kind
of
just
plow
through
this.
Now,
not
sure
if
you,
if
you
want
to
do
that
or
not.
H
H
F
Sure
a
couple
things
from
the
the
tooling
group
there's
a
desire
from
a
lot
of
the
folks
who
are
working
on
stuff
like
the
salsa
generator,
the
salsa
verifier.
That's
within
the
salsa
repo
itself,
a
lot
of
those
folks
work,
West,
Coast
time
or
a
few
of
them
actually
work
out
in
Asia,
and
so
there's
desire
to
have
an
APAC
friendly
meeting.
F
Ian
Lewis
has
sort
of
volunteered
to
sort
of
help
lead
up
that
meeting,
he's
one
of
the
folks
from
Google
working
out
of
Japan,
so
the
trying
to
kind
of
just
organize
what
what
time
works
best,
because
originally
we
were
looking
to
kind
of
maybe
make
a
time
that
worked
best
and
it
seemed
like
half
the
folks
wanted
something
that
was
APAC
friendly
and
the
other
half
wanted
something
that
was.
You
know,
east
coast
and
Europe
friendly.
F
So
we'll
we'll
just
kind
of
split
up
into
two
meetings
and
have
in
every
other
meeting
thing
also
generally,
the
right
now
I
think
because
there's
been
all
this
Focus
to
get
the
1.0
spec
out,
it's
been
quite
kind
of
quiet.
On
the
tooling
side,
we
expect
that
to
pick
back
up
once
1.0
has
been
officially
released
because
then
folks
are
going
to
start
saying:
okay
great,
where
are
all
the
1.0
compliant
tools
separately?
F
I'm
gonna
be
super
busy
for
the
next
few
weeks
between
kubecon,
which
starts
next
week
and
was
it
open
source,
Summit
n,
a
which
is
a
couple
of
weeks
after
that
so
I'm
gonna
be
super
busy
and
might
not
be
able
to
sort
of
manage
those
meetings.
So
if
somebody
can,
you
know
help
out
there
definitely
interested
in
getting
some
help
to
kind
of
help
run
those
meetings
while
I'm
unavailable.
F
Next
there
was
a
desire
from
end
users
for
fully
open
source
salsa
Builders,
not
a
lot
of
work
in
that
space.
A
few
end
users
said
Hey.
What,
if
I,
don't
use
GitHub
there
doesn't
seem
to
be
a
lot
there
and
that
desire
also
seemed
to
be
mostly
from
folks
who
were
interested
in
salsifying
their
existing
like
Ci
systems,
as
opposed
to
adopting
something
new.
F
Yeah,
so
this
is
stuff,
like
you
know
you,
you
know,
there's
a
lot
of
companies
that
are,
you
know.
Let's
say
your
your
big
Enterprise
of
the
world
who
are
like
yeah
I'm,
not
using
GitHub
actions,
I'm,
not
using
git
lab,
especially
as
a
service
I'm
running
self-hosted
Builders,
and
you
know
whether
it's
I'm
running
a
Jenkins
server
with
a
bunch
of
stuff
and
it's
it's
or
I'm,
running
tecton
or
in
certain
cases
a
handful
of
folks
running
Fresca
like
Hey.
F
H
Yeah
a
related
thing
is
a
topic
that
was
recently
brought
up
when
we
added
to
the
Future
directions
page
around,
like
possibly
a
future
like
operations
tracker
similar,
because
the
current
salsa
build
requirements
are
around
kind
of
the
application
layer
like
the
behavior
of
the
application.
But
it
doesn't
say
we're
kind
of
quiet
on
how
you
run
such
a
service.
But
running
such
a
service
is
like
really
half.
H
Equally
as
important
right
and
and
so
if
you
have
like
a
fully
salsa
open
source
Builder,
but
then
you
run
it
and
everyone
at
the
company
has
access
to
it
can
sh
to
it
or
something
like
that
or
they
can
all
access
the
private
Keys.
It
doesn't
do
any
good,
and
so
so
that's
probably
an
area
where,
like
future
specification,
work
can
might
also
help
as
well.
F
F
You
know
builds
in
very,
very
specific,
secure
sorts
of
ways
and
I'm
hoping
you
know,
maybe
closer
to
June
I'll
have
something
to
show
off
on
on
that
front,
and
so
the
idea
was.
It
would
be
something
that
you
call
from
Jenkins
or
you
call
from
tecton
to
then
run
the
actual,
secure,
build
piece
and
it's
not
intended
to
be
sort
of
a
generic.
F
You
know
task
Runner
like
like
tecton
and
Jenkins
are
so
that's
that
there
is
a
tooling
1.0
support
tracking
issue.
Just
you
know,
once
again,
there's
there's
some
a
bunch
of
folks
who've
been
looking
at
the
release,
candidates
and
sort
of
prepping
code.
So
this
is
like
folks,
like
cosine
and
and
the
various
salsa
generator
stuff
that
we've
been.
You
know,
working
with
and
some
other
tools
in
there.
F
Npm
has
a
tracking
issue
for
this
as
well,
so
there's
a
bunch
of
things
there
that
folks
do
plan
to
support
salsa
from
a
it's
a
lot
of
folks
in
the
sort
of
like
how
do
I
generate
salsa
provenance,
just
even
like
as
a
library
or
whatever.
There
also
seem
to
be
some
interest,
as
in
maybe
the
salsa
framework,
providing
something
like
a
a
go
Lang.
F
F
But
in
addition
to
that,
you
know
it
helps
with
salsa
adoption,
because
if
a
few
folks
see
hey
kubernetes
has
adopt
the
Tulsa
other
folks
might
be
a
bit
more
inclined
to
and
in
addition
to
that,
I
think
helping
out
with
some
of
those
projects,
even
just
in
like
helping
Point
them
in
the
right
direction
and
helping
some
of
that.
We.
K
F
F
F
I
think
the
thing
that
folks
have
brought
up
is
they.
They
want
something
consistent
and
once
again
getting
the
open
source.
We
totally
recognize
that
getting
the
open
source,
Community,
especially
different
package
ecosystems,
to
agree
to
anything
is,
is
quite
difficult,
but
even
a
set
of
General
guidelines
like
oh
the
rest,
endpoint
or
not
rest
endpoint
I,
don't
want
to
say
rest
because
I
want
to
say
API,
but
the
routes
or
the
the
areas
that
these
things
should
be
downloaded
from
have
generally
relatively
consistent
naming.
F
Maybe
hopefully,
if
everything
turns
out
right
and
then
that
will
help.
Folks
who
are
looking
to
consume,
you
know
documents
like
salsa,
so
they
don't
have
to
have
a
ton
of
custom
Logic
for
every
single
ecosystem.
That
stuff
is
still
going
to
be
I,
think
a
very
long
long
set
of
conversations
and
that's
it
for
me.
J
F
Sure
so,
there's
a
couple
things
from
my
end,
I
think
a
handful
of
it
and
I
know
there
is
some
interest
there
of
having
something
like
a
dictionary
of
I
know
from
like
I'm
just
talking
from
like
an
end
user
perspective.
What
folks
are
looking
for
is
something
like
a
here
are
a
set
of
in
Toto
attestations
that
are,
let's
say
well
supported
right.
Anybody
can
make
their
own
in
Toto
attestation
and
having
a
library
that
can,
you
know,
maybe
have
additional
logic
in
there.
That's
you
know
specific
for
those
attestations.
F
F
The
things
I
know
folks
have
been
looking
at
is
hey
it'd,
be
really
great
if
there's
a
way
to
encode
the
the
schema
for
a
particular
in
total
attestation
via
that
URL,
so
that
folks,
who
are
consuming,
can
just
sort
of
say
great
if
I
don't
have
that
information
locally,
can
I
just
reach
out
to
that
URL
fetch
information
about
how
to
parse
and
then
can
kind
of
continue
on
I
think
those
are.
Those
are
some
big
things
on
on
on
that
front,
Okay.
J
L
L
C
Yeah
I
am
but
I
think
the
highlights
were
mostly
covered
by
Marcel
I
was
you
know,
gonna
speak
up,
but
we're
still
almost
to
cover
those
points.
Two
two
Michael's
point
to
an
extent
about
eventually
mapping
predicates
to
natology
and
things
like
that.
We're
certainly
looking
at
it
from
the
internal
perspective
as
well,
especially
as
we're
now
working
on
updating,
internal
layouts
or
policies
to
support
attestations
and
things
like
that.
Yeah.
You
know
how.
C
F
You
know
that
has
been
sort
of
doing
this
is
we've
been
ingesting
right,
all
the
salsa
attestations
we
can
find
and
there's
not
a
ton
of
public
ones
that
but
kubernetes
actually
has
a
lot,
and
you
know:
we've
been
parsing
through
them
and
and
sort
of
mapping
them
into
sort
of
walks
internal
data
model.
But
you
know,
there's
definitely
the
the
case
of
like
hey.
H
D
B
I
put
some
little
notes
in
there
I
I,
just
some
quick
notes.
Just
basically
you
know
begging
everybody
else
to
spread
the
word
I'm,
certainly
going
to
you
know
in
the
19th
thing
and
also
just
long
term
and
I
know.
Jay
will
be
happy
for
me
to
say
this,
but
you
know,
let's
I
just
want
would
love
for
you
know
self.
So
folks,
please
take
a
look
and
let's
make
sure
that
s2c2f
and
salsa
you
know
I'm
not
expecting
to
say
exactly.
You
know,
cover
exactly
the
same
topics.
I
mean
it's
fine.
B
H
G
It
might
be
quicker
than
the
roadmap,
because
a
road
map
can
get
into
all
sorts
of
different
things,
and
so,
if
we
I'm
going
to
open
up
this,
this
PR
was
around
an
FAQ
item
on
s-bombs,
and
so
when
I
I
looked
at
the
language.
I
put
my
comments
in
here
the
salsa.dev
website
the
way
they
Define
it
is
very
similar
to
nist,
but
the
actual
FAQ.
G
H
Yeah,
so
the
briefly
that
someone
asked
about
whether
that's
you
know
salsa
has
anything
to
salsa
says
nothing
about
s-bomb
I
mentioned
I,
think
it's
that
we
really
should
say
something
about
s-bomb,
because
it's
like
on
top
of
people's
mind
and
so
I
put
it
in
the
comment
of
like
well.
My
personal
take:
is
this
I,
don't
know
if
it's
you
know,
consensus
I.
E
H
G
G
G
Is
okay,
so
this
is
what
it
talks
and
what
it
talks
about
s,
phones
right
so
when
it
says
that
s-bomb
is
typically
focused
on
understanding
the
software
right
and
known
vulnerabilities
that
that's
partial
right
per
the
definition
on
salsa.dev,
which
is
very
similar
to
nist.
S-Bomb
is
also
about
provenance
of
that
software,
and
so
the
definition
of
provenance
here
is
different
than
what's
on
salsa.dev,
and
so
that's
what
I
I
was
trying
to
show
here.
That
Wonder
seems
to
be
a
discrepancy
between
salsa.dev
and
this
FAQ.
G
S-Bombs
are
good
practice,
blah
blah
blah
I,
don't
necessarily
agree
with
that,
because
again
s-bomb
is
it
can't
handle
provenance
and
therefore,
if
we
think
about
the
build
system,
the
provenance
of
the
build
system
not
of
the
actions
it's
doing,
but
the
software
that
makes
the
build
system
s-bomb
can
be
used
for
that.
Additionally,
to
say
that
you
know,
s-bomb
is
not
Suited.
G
You
could
probably
say
that
it's
not
as
bomb
is
traditionally
not
well
defined
for
build
actions
and
configurations.
If
that's
what
you're
intending
because
there
are
other
specifications
that
are
trying
to
do
that,
so
there's
I
think
there
needs
to
be
a
little
bit
more
clarity
and
then
also
fixing
the
discrepancy
between
this
FAQ
and
the
salsa.dev
I
like
this
also.devs
definition.
It
is
closely
aligning
with
what
the
industry
is
looking
at
right
now,
but
not
so
much
with
this
FAQ
says.
H
Yeah
I
yeah
I
haven't
had
time
to
comment
on
the
particular
programs
and
the
reason
why
I
had
said
my
original
thing
in
a
GitHub
comment,
as
opposed
to
sending
a
PR
is
because
I
think
it
it's
going
to
be.
You
know
take
some
time
to
like
really
come
up
with
wording.
That
is
clear
and
we
all
agree
with.
H
H
H
What
people
I
think
when
people
usually
think
of
an
s-bomb,
they
think
of
kind
of
more
finer
grained
information
than
the
salsa
provenance
would
give
them,
and
so
yeah
I
agree.
That's
not
accurate
to
say
that
Aspen
can't
support
it,
because
that
spawn
is
very,
very
general
can
contain
lots
and
lots
and
lots
of
different
type.
E
H
Abstraction
so
I
guess
in
my
mind
it's
more
about
like
in
most
cases
today,
as
tools
exist
today
there
will
likely
be
prominence
generated
by
the
build
system,
that's
just
like
the
overall
thing
and
then
more
fine-grained,
s-bomb
tooling.
That
is
about
the
kind
of
the
more
detailed
steps
of
what
happens,
but
it's
more
of
like
in
practice
rather
than
theoretically
that's
what
ought
to
happen.
At
least
that's
that's
my
mind.
I,
don't
know
how
to
word
that
and
I
also
don't
know
if
others
agree.
F
Yeah
yeah
no
I
agree
with
Mark
like
it's,
it's
more
of
we're,
talking
more
about
build
provenance,
so
it's
the
provenance
of
how
an
artifact
kind
of
went
from
source
to
this
thing-
and
it's
also,
you
know,
there's
a
bunch
of
other
properties,
whereas
you
know
I,
think
nist
really
did
a
bit
of
a
disservice
by
lumping
like
a
lot
of
things
in
there,
because
I
mean
if
you
look
at
sort
of
the
proliferation
of
all
the
different
bombs
right.
We
have
Network
bombs
and
and
d-bombs
and.
F
Bombs
and
like
there's
a
lot
of
these
different
things
that
are
trying
to
each
say:
no,
no,
we're
a
superset
of
of
all
of
this
and
I
think
where
Salsa's
strength
is
actually
no.
We,
we
are
laser
focused
on
this
thing
and
that's
kind
of
where,
where
we're
coming
through
I,
don't
know
how
I
would
word
that,
because
I
agree
like
there
is
an
element
there
of
like
s-bombs,
do
describe
an
element
of
provenance
like
hey.
This
thing
depends
on
a
thing,
and
this
is
where
it
came
from.
F
You
know
you
talk
to
everybody
and
everybody
has
a
bomb
format
that
does
everything
and
and
we're
trying
to
say
well,
actually,
we
view
that
to
be
maybe
not
very
helpful,
because
we
think
that
that
you
know
the
the
key
here
is
about
really
hitting
these
things.
And
what
can
you
prove
about
those
things?
Yeah.
G
Yeah
completely
agree
and
that's
why
I
started
to
question
this
right,
because
s-bomb
is
a
huge
Focus
right
and
I.
Think
today
is
supposed
to
be
a
major
announce
day
for
the
executive
order
on
whether
or
not
June
is
the
official
time
where
everybody
has
to
comply
with
s-bombs
and
other
things,
and
so
it
will
be
top
of
mind
for
the
next
couple
months.
G
So
we
have
to
make
sure
that
we're
very
clear
on
okay,
we're
talking
about
build
provenance
which
includes
things
like,
like
you
said,
The
Trusted
control
plane,
give
examples
like
you
know
what
tecton
tasks
it's
doing,
et
cetera
et
cetera.
If
you
give
examples,
then
verses
a
software
bill
of
material
which
is
more
tailored
towards
the
software
components
that
make
up
the
thing
that
you're
building
or
the
thing
the
the
software
that
it
comprises
of
the
build
right
so
Jenkins
right
there
should
be
an
s-bomb
of
Jenkins
and
that
maybe
at
a
future
date.
G
M
Yeah
so,
as
I
said
in
my
comment,
I
think
you
know
what's
important
is
to
recognize
those
things
are
moving
quickly
right
and
so,
in
my
opinion,
what's
more
more
important
is
to
to
acknowledge
that
you
know
these
are
moving
Parts
I
mean
in
provenance.
We
all
already
have
some.
You
know
option
to
to
have
dependencies,
which
is
clearly
the
realm
of
as
bombs
and
as
bombs
are
evolving
towards
having
some
kind
of
provenance
information
I
mean
the
Cyclone
DX,
a
formulation
that
they
claim.
Does
everything
I
mean?
M
If
you
ask
them,
they'll,
say
I
challenge
you
to
come
up
with
something
you
have
in
provenance.
That's
not
you
know
in
formulation
and
I
I
don't
want
to
get
into.
You
know
a
pieceing
contest
as
to
which
one
is
better,
but
so
I
think
we
have
to
acknowledge
that
these
things
are
moving
parts
and
we
don't
really
know
how
things
will
end
I
think
we
have
to
we're
better
off.
G
So
yeah
I,
just
wanted
to
to
you,
know,
bring
this
to
light
and
and
try
to
explain
verbally,
sometimes
slack
or
you
know,
PRS,
don't
necessarily
get
my
point
across
so
usually
I
do
better
when
I'm
speaking
with
someone
about
you
know
why
this
is
bothering
me
so
much
and
and
we
we
need
to
change
it,
because
this
I
think
we're
going
to
get
a
lot
of
pushback.
If
it's
written
this
way.
H
L
Oh
sure,
yeah
yeah,
so
sorry,
sorry
I
should
I
should
also
mention
it
in
the
meeting
yeah.
So
the
S
bombing
project
is
a
project
that
that
we're
planning
to
incubate
under
open,
ssf
I,
don't
think
it's
fully
official
yet
so,
but
the
idea
is
to
have
s-bombs
that
you
could
verify
technically
within
Toto
and
so
I.
Don't
think,
there's
any
contradiction
between
things
like
s-bombs
and
salsan
and
Toto.
Let
me
post
a
link.
G
I
think
the
next
item,
if
no
one
has
anything
else,
is
the
road
map.
We
only
have
a
couple
minutes,
but
hopefully
we
can.
We
can
make
some
progress.
Let
me
zoom
in
here
and
try
to
get
rid
of
some
of
these
comments.
How
do
I
anybody
knows
how
to
get
rid
of
the
comments.
I
would
appreciate
this
weekend.
F
E
F
H
G
G
F
But
I
do
think
yeah
I
mean
I.
Think
the
one
of
the
based
on
based
on
the
conversation,
especially
given
a
lot
of
folks,
are
going
to
be
asking
this
I.
Think
one
of
the
the
top
priorities
is
I'm
blanking
on
his
name,
so
I
I
apologize,
the
the
I
think
it
was
from
Susa
who
had
talked
about
like
we
need
a
salsa
Builder
build
system
specification.
F
I,
think
that
would
probably
be
the
number
one
thing,
because
a
lot
of
folks
are
going
to
start
asking
like
okay
cool.
How
do
I
make
my
build
system
secure
in
a
way
that
you
know,
we
would
feel
confident
that
it
is
generating
accurate,
salsa
prominence
and
not
just
telling
us
that
it's
you
know
generating
salsa
V3.
F
F
It
would
be
different
because
it's
just
here's
good
ways
to
make
a
secure,
build
and
here's
how
it
then
integrates
into
allowing
you
to
make
a
a
you
know:
salsa
level,
three
or
whatever,
but
it's
different,
because
you
know
you
it's
it's
it's
different
audiences
one
audience
is
hey.
I
have
a
project
I
want
to
make
sure
that
the
provenance
is
secure
against
this
thing,
I
use
the
salsa
build
track.
I
want
to
make
sure
that
the
builders
are
providing.
F
G
Yeah
we
can
Circle
back
on
that,
because,
even
with
that
description,
I
still
think
it.
It
fits
under
there,
but
we'll
table
that
what
about
the
source
level,
one
I
just
put
level
one
two.
It
doesn't
have
to
be
level
one
and
two.
It
could
be
level
one
to
four,
but
there
was
some
thought
that
this
could
be
done
in
parallel
with
social,
build
level.
G
G
I
Oh
right,
so
for
what
it's
worth,
if
people
are
willing
and
available,
I
I
certainly
hope
that
we
try
to
parallelize
build
level
four
and
the
source
track,
because
that
is
one
of
the
one
of
the
purported
benefits
of
splitting
into
tracks
in
terms
of
priority.
I
suspect
that
Source
levels,
one
and
two
would
come
together
faster
than
build
level
four.
So
if
we're
not
able
to
parallelize
it,
I
would
guess
that's
happening
first,
but
that's
just
a
hunch.
E
G
M
G
G
A
K
L
H
Between
like
working
on
Source
or
build
or
whatever
other
track,
I
would
imagine
because,
like
this
is
like
we
are
not.
This
is
an
open
source
project
and
we're
not
paying
people
to
do
this,
that
it
would
be
whatever
contributors
are
willing
to
work
on
it
and
so
I
think.
If
people
have
the
bandwidth
to
think
about
source-
and
they
think
it's
important,
then
they
would
kind
of
start
and
try
to
get
momentum.
H
There
I
think,
if
there's
folks
who
have
a
desire
to
define
a
level
four
because
they
have
a
need
for
it,
they
could
get
momentum
there
and
I.
Think
it's
hard
for
me
to
know
like
which
direction
we
go.
I
would
also
Imagine.
Source
would
come
first
because
it
seems
like
a
higher
priority,
but
I
think
there's
I,
guess,
there's
hard
questions
in
both.
H
Neither
seems
like
an
easy
thing
to
add,
because
the
big
question
is
like
how
we
would
verify
how
it
actually
work,
but
so
I
would
imagine
it
might
be
kind
of
some
like
we
make
some
progress
here.
We
make
some
progress
there
and
eventually
it
materialize
into
something
that
we're
pretty
confident
with
that
we
could
yeah.
We
could
actually
release
okay.
G
Yeah
I
know
we're
at
time,
but
if,
if
folks,
can
kind
of
take
a
look
at
this
and
put
like
put
comments
on
what
you
think
the
bucket
should
be,
then
we'll
be
that
much
closer
to
having
this
not
only
for
open
source
Summit,
but
for
the
next.
You
know
supply
chain,
Integrity
working
group
positioning
meeting
so
that
people
can
take
a
look
at
as
well
as
the
bi-weekly
and
the
specification
call
for
that
matter.