►
From YouTube: SLSA Specifications Meeting (August 15, 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
Hey
everybody,
as
always,
if
you
haven't
already,
if
you
could
put
your
name
in
the
meeting
notes,
which
I
just
pasted
into
the
chat.
B
I
appreciate
it
who
else
who's
here
so
far,.
A
Okay,
I
don't
know
if
any
more
folks
are
going
to
join
the
welcome
everyone.
Thanks
for
joining
good,
to
see
you
all
again.
A
I
the
only
items
added
to
the
agenda
were
the
salsa
1.0
proposal,
so
continuing
from
la
where
we
picked
up
last
week,
there's
been
some
discussion
in
the
dock
if
you've
seen
it
mostly
around
the
splitting.
So
since
last
week
I
had
split,
we
we
had
the
the
the
idea
of
splitting
out
like
postponing
the
definition
of
salsa
four,
so
I
added
that
to
the
doc.
I
also
had
a
suggestion,
based
on
what
we
discussed
last
week,
of
like
splitting
out
like
source
levels
for
versus
build
levels.
A
So
we
could.
We
could
discuss
that
and
see
what
it
looks
like
and
also
I
I
wanted
to
note
that
I
added
a
reviews
line
to
each
section
just
so
we
could
record
people
who
have
like
explicitly
looked
at
it
and
either
kind
of
gave
it
a
thumbs
up
or
thumbs
down.
You
could
maybe
dig
that
through
comments,
history
or
something
like
that,
but
that's
a
huge
pain
to
do
so.
It's
easier
to
just
like
record
recorded
that
information.
A
There,
and
so
if
you,
if
you
do,
have
thoughts
done
in
any
section,
adding
your
name
with
like
some,
I
would
say
a
couple
suggested,
emoji
or
comments
would
be
appreciated,
just
just
little
brief
things.
So
I
oh,
I
see
someone's
adding
also
the
policy
model
from
from
last
week.
So
let's
add
time
to
to
discuss
that
at
the
end.
So
let's
maybe
start
with
the
thing
that
I
think
maybe
most
agreement
on
quickly
and
I
could
present.
A
Okay
in
the.
A
So
hopefully
this
is
big
enough
to
see.
So
as
a
reminder,
we
talked
about
versioning
that
I
marked
as
decided
the
evidence
of
security
claims.
I
want
to
talk
about
later
if
we
have
time
so,
the
one
proposal
is
to
postpone
the
definition
of
salsa
4.
effectively
in
the
1.0
specification,
we
would
define
the
first
three
levels
and
list
perspective
requirements
for
future
levels
like
the
two-party
review,
hermetic
reproducible,
possibly
some
other
things
that
are
under
discussion,
but
don't
formally
define
salsa.
A
Yet,
basically,
we
undefined
salsa
4
with
some
sort
of
footnote
explaining
like
what
happened
to
it
and
and
what
our
thoughts
are
and
then
we
will
finalize
salsa
4
in
a
future
release.
A
I
believe
this
is
what
we
had
discussed
and
I
didn't
get
any
other
further
comments
on
the
doc,
but
I
just
wanted
to
bring
up
now
just
to
make
sure
yeah
like
mike.
C
Oh
yeah
yeah,
so
so
I
think
I
agree
with
with
the
postponing
of
the
definition
of
solos
4,
but
I
still
think
we
should
at
least
have
somewhere
where
like
where
our
current
thinking
is
for
salsa,
for
so
that
folks,
who
are
looking
to
you,
know,
go
above
and
beyond,
and
go
to
that
next
level
that
they
can
sort
of
prepare
themselves
for
like
hey
where
we
might
be
thinking,
not
necessarily.
C
You
know
we
agreed
on
it,
but
where
we
might
be
thinking
because,
like
for
example,
was
it
a
sousa
rate
has
more
or
less
you
know,
it
seems
like
they're,
more
or
less
salsa
4
for
most
things,
and
we
still
think
that's
good
work
right,
like
you
know,
that's
that's
not
good
work,
and
but
I
do
agree
with
the
other
pieces
of
a
lot
of
the
confusion
around
it,
since
there
are
folks
who
are
also
claiming
salsa
for,
but
you
in
also
a
nebulous
sort
of
way
and
given
a
lot
of
the
confusion
around
it.
A
That
sounds
good.
I
think
the
main
thing
I
want
to
avoid
is
having
something
that
people
start
calling
salsa
for,
even
if
we
say
it's
informal,
so
as
long
as
we
get
the
messaging
right
to
make
it
clear
like
please
don't
call
the
salsa
for
yet
because
it's
subject
to
change
that
sounds
good
to
me.
B
A
A
Okay
and
to
be
clear,
decided
here,
just
means
among
this
group.
We
still
put
the
full
proposal,
you
know
to
the
public
group
and
get
it
approved,
but
just
for
our
own
tracking
purposes.
So
we
don't
kind
of
you
know.
We
know
what
we've,
where
the
decisions
need
to
be
made
and
where,
where
we've
already
made
decisions.
A
A
So
the
other
is
this
notion
of
separate
build
versus
source
levels.
I
don't
the
the
idea
being
that
we
rename
what
we
currently
have
to
terminology
pending
build
levels
or
providence
levels
or
build
integrity
levels,
or
something
like
that.
A
So,
instead
of
saying
salsa,
3
you'd
say
it's
also
build
level
3
or
build
integrity,
3
or
something
like
that,
and
the
guarantee
is
about
the
trustworthiness
of
the
build
process
and
the
resulting
providence
and
the
only
where
source
comes
to
play
would
just
be
that
the
builder
identifies
what
the
source
is,
but
does
not
necessarily
say
any
properties
of
the
source.
Like
that.
So
two-party
review
retention
of
the
sources
separate
et
cetera,
it
would
be
a
separate
property.
A
And
then
we
would
similar
to
the
level
four
discussion
around.
Like
a
tentative
level.
We
would
have
a
source
levels
that
we
would
define
in
a
future
revision,
but
not
in
1.0,
and
so
this
would
be
the
current
source
requirements
we
have
now
would
be
the
start.
There's
also
some
discussion
around
like.
Should
we
add
more
requirements
like
should
you
have
commit
signing?
A
Should
you
have
something
about
testing
of
the
source
code
like
how
you
know
if
it's
any
good,
we
could
decide
all
of
that
down
the
road,
but
we
would
just
call
it
like
draft
or
something
for
1.0,
but
wouldn't
actually
lock
in
the
definition.
Yet
so
that's
the
proposal
that
we
have
written
it
seems
like
we
got
some
feedback
from
folks
that
it's
generally
positive
the
it
adds
complexity,
which
I
don't
love
and
I
don't
think
I
think
no
one
loves,
but
it
seems
like
it's
a
decent
compromise.
A
A
Those
were
the
main
ideas
so
far
and
and
the
source
one.
D
A
Could
just
figure
out
later,
I'm
not
too
worried
about
the
naming
there
and
then
should
we
have
a
term
for
like
shorthand
for
salsa
three
means
build
level,
three
plus
source
level,
three
for
something
because.
E
Yeah-
and
I'm
not
sure
whether
this
this
has
been
talked
about
before,
but,
like
so
other
than
the
sauce
and
build
levels,
do
we
envision
kind
of
having
other
other
kind
of
classifications
as
well.
E
So
I
just
I'm
just
wondering
all
right
like
that
right
now,
I
think
I
saw
spill
provenance
in
just
more
general
and
would
we
be
scoping
out
the
general
stuff
and
the
and
combining
the
provenance
of
the
the
build?
How
would
that?
How
would
that
work.
C
So
I
mean,
I
think,
to
to
brendan's
point
is:
is
I
think
it's
like
the
general
salsa
scoping
question
of
like
is
salsa
gonna
get
into
you
should
be
doing
software
composition?
Analysis
right?
I
think
it's
that
kind
of
thing
that
we
just
wanna
figure
out
like.
Are
they
gonna
also
be
doing
stuff?
Like
I
don't
know
like
when,
when
running
your
build,
you
should
do
this
sort
of
security,
linting
or
or
whatever.
C
I
think
that
that's
kind
of
where
we
we
want
to
sort
of
set
those
bounds,
and-
and
like
I
mean
my
sense,
is
always
like,
if
there's
something
out
there,
that
already
does
this,
I
think
the
salsa
security
or
whatever.
However
else
we
want
to
kind
of
like
word,
that
could
be
some
other
thing
and
just
sort
of
cite
that
other
thing,
whether
it's
you
know
something
coming
out
a
nist
or
something
coming
out
of
some
other
thing
or
it's
something
that
we
want
to
eventually
get
to.
C
And-
and
I
say
that
just
because,
as
folks
start
to
adopt
the
build
provenance
and
start
to
add
up
some
of
the
other
pieces,
there's
going
to
be
an
open
question
of
okay.
Well,
what's
like
is
it
on
is
is
build
like
general.
Build
security
like
use
software
composition.
Use
this
other
thing.
Yayata
is
that
on
the
roadmap,
even
if
it's
not
something
that
you're
looking
at
right
now
or
is
it
something
you're
saying?
No?
No.
This
is
completely
out
of
our
scope
and
we're
not
going
to
address
it.
F
Yeah
I
I
have
so
I
I
like
having
this
separation
between
source
and
build.
One
worry
I
have
is
what
happens
if
someone
builds
from
a
table
and
not
a
like
a
git
repository
like
even
if
you
have
build
level
three,
I
don't
think
you
can
do
any
sort
of
verification,
because
you
don't
really
have
the
the
ground
truth
of
what
you
build
from.
Let's
say
if
the
source
is
a
table
in
a
gcb
bucket
in
a
gcp
bucket.
F
A
It
makes
sense
to
me
in
my
mind,
the
the
build
level
is
just
identifying
what
those
inputs
were
like
at
level.
Three
would
be
the
top
level
config
of
the
four
like
the
sort.
You
know
all
of
the
transit
dimensions
that
are
required
at
build
time
and
so
like.
If
it's
a
tarball
it'll
be
identified
by
hash.
A
I
guess
whether
it's
available
for
an
inspection
later,
I
would
put
as
tentatively
in
the
source
requirements
and
that
actually
kind
of
comes
to
the
other
thing
I
wanted
to
bring
up,
which
is
like
first
party
versus
or
enterprise
versus
open
source
versus
vendor.
We
might
want
to
split
the
ladder
out
there
because,
like
making
sources
available,
doesn't
work
if
it's
not
open
source.
So
anyway,
that's
what
I
was
thinking
michael
or
did
someone
else,
raise
your
hand.
A
E
E
G
I
think
the
current
proposal
is
that
if
you
refer
to
just
sells
a
level
x,
then
that's
everything
at
the
same
level
and
if
you
have
things
at
different
levels,
you
have
to
refer
to
them
by
the
individual
ladder.
And
that's
that's.
Why
there's
some
reluctance
about
the
proposal
because
it
adds
to
that
complexity,
particularly
around
communication,
which
is
why
the
proposal
suggests
that
we
go
out
in
front
of
naming
by
saying
by
stating.
If
you
collect
salsa
level
x,
then
you
have
to
meet
all
requirements
of
that.
C
Yeah
one
thing
just
to
to
really
sort
of
drive
home
is
we
really
want
to
make
sure
that
there
is
some
element
of
an
outcome
right?
You
know
these
salsa
levels
are
generally
doing
things
for
you
and,
and
you
know
whatever
that
takes
and
so
like
yeah,
you
might
be
salsa
level,
three
build
providence,
but
let's
say
in
the
future
your
salsa
level,
one
some
other
thing
you
probably
are
not
getting
the
full.
C
This
is
what
salsa
three
gets
you
we
just
wanna
make
that
clear.
E
I'm
wondering
also
whether
it's
maybe
beneficial
to
not
have
explicit
like
across
about
salsa
levels,
because,
like
I
think
like
the
scoping
of
salsa,
also
is
meant
to
be
pretty
narrow
and
so,
like.
I
think
once
we
like,
when
we're
doing
the
mapping
against
all
the
compliance
stuff
right,
we'll
be
mapping,
you
know
the
specific
levels
of
the
specific
areas
of
salsa,
so
I'm
just
wondering
whether
whether
it
would
be
we
would
want
to
say
to
to
kind
of
not
refer
to
that
as
a
broad
like
salsa
tube
means.
E
You
have
everything
yeah
so.
A
So,
are
you
suggesting
I'm
not
sure
if
you're
suggesting
but
there's
one
of
the
alternatives
considered,
which
is
effectively
the
only
salsa
levels
would
be
the
build
levels?
A
And
then
we
just
call
that
salsa
three
and
then
we
describe
all
these
other
sets
of
stuff
would
just
not
be
leveled
and
they
would
just
be
kind
of
individual
properties
like
was
it
two-party
or
you
know,
two-party,
review,
availability
of
the
sources,
slash
retention,
vulnerability,
scanning
sca,
etc.
E
Yeah,
I
I
think
I
think
at
least
like
the
way
I'm
seeing
this
is
when
we
start
to
include
additional
kind
of
pillars
with
sauce
built
and
everything
else,
like
I'm
not
sure.
Besides
for
marketing
purposes,
whether
it's
beneficial
to
have
a
labeling
on
you
know,
I'm
salsa
3
across
the
board,
rather
for,
like
kind
of
practical
policy
making
decisions.
E
This
I
I'm
kind
of
seeing
this
as
a
way
to
maybe
reduce
the
complexity.
By
saying
that
you
know
you
shouldn't
refer
to
like
salsa
is
defined
as
like
the
pillars
and
not
as
like
general
general
levels,.
C
A
C
D
I
think
it's
going
to
tend
towards
that
way,
no
matter
what
we
try
and
do
here,
I
do
not
want
to
drop
the
source
code
out
of
out
of
this
also
levels
period.
I
think
we're
going
to
add
more
as
time
goes
by
like
where
your
bootstrap,
compilers
and
tools
come
from,
aren't
really
a
build
specific
thing.
D
I
think
we
need
to
keep
the
source
in
there
and
and
be
very
clear
that
it's
part
of
the
whole
package,
because
I
don't
think
bundling
at
all
and
dropping
things
out,
because
they're
hard
to
explain
they're
going
to
help
anybody,
because
we
kind
of
need
the
levels
and
if
we
want
to
continue
to
break
them
up
hard
as
a
this,
is
source
versus
build.
We're
going
to
get
more
classifications.
As
we
go
forward.
A
Record-
I
am
I'm
really
split
on
this.
I
I
don't
really
like
either
option.
I
don't
see
anyone
as
like.
Looking
particularly
good,
I
think
the
complexity
of
having
multiple
build
versus
source
levels
is
kind
of
undesirable,
bundling
it
all
together
is
undesirable
for
the
reasons
that
we
already
listed
now
so
just
just
to
get
opinions.
There's
this
alternative
of
like
effectively.
We
have
one
set
of
levels
and
then
a
bunch
of
like
kind
of
check
boxes
for
other
things,
any
thoughts,
positive
or
negative.
On
that.
G
Yeah
there's
just
too
much
to
say
and
all
right.
I
I
think
it
like
the
granularity
is
only
going
to
explode
and
it's
going
to
be
almost
impossible
to
describe
you're
going
to
end
up
with
like
two
sides
in
your
document,
just
describing
which
files.
B
Marcel
yeah,
I
I
think
I
tend
to
agree
with
joshua.
If
someone
has
two-party
review
and
source
availability
now
you
sort
of
have
to
tack
on
two
additional
things,
or
at
least
have
a
way
to
start
specifying
all
of
the
additional
checkboxes
that
they've
marked
right,
and
so
then,
eventually
we
end
up
honestly,
starting
to
just
need
a
way
to
express
any
such
thing,
which
is
kind
of
what,
in
my
mind,
sauce
is
already
trying
to
do.
B
F
G
For
me,
personally,
it's
one
is
describing
which
salsa
level
you
adhere
to.
If
there's
some,
if
there's
a
bunch
of
kind
of
add-on
options,
but
also
one
of
the
strongest
appeals
of
salsa
is
detractability
with
the
leveling.
You
just
go
one
two
three,
and
if
you,
if
it's
not
one,
two
three,
it's
one
plus
well,
I
I
can't
even
imagine
how
how
the
additional
constraints
fit
into
the
leveling,
and
I
really
like
the
leveling
and
the
kind
of
incrementality
of
it.
So
that's
a
concern.
F
F
You
know
best
practices
and
requirements
that
need
to
be
met.
But
then,
when,
once
you
move
to
artifacts,
it
seems
that
that's
where
there's
a
lot
of
differences
in
practice,
but
but
I
think
the
requirements
on
artifacts
themselves.
Are
they
don't
have
that
much
like
there
isn't
a
lot
of
freedom
or
degrees
of
freedom?
It's
basically
three
or
four,
I
guess
maybe
requirements.
F
C
I
I
agree
with
with
you
there
I
I
think,
for
me,
one
of
the
things
is,
and
I
think
you
hit
on
it
is
like
I
can.
I
can
definitely
see
right
because
we've
already
been
talking
about
the
differences
between
salsa
builders
versus
salsa
builds,
like
builds
that
happen
with
the
salsa
process
and
in
certain
cases.
C
One
of
the
reasons
why
we've
even
been
pushing
back
against
the
source
requirements
is
trying
to
better
understand
what
tools
even
support
certain
things
today,
like
two-party
code
review
or,
as
you
sort
of
mentioned
like,
if
you
know,
if
we're
pulling
the
code
from
git
versus
something
else
like
what
does
that
actually
look
like,
and
so
there's
like
almost
like
a
an
element
of
salsa
builder
versus
an
approved
salsa
store.
C
You
know,
co,
you
know,
code,
repo
or
whatever,
and
then,
but
one
of
the
things
that
that
still
seems
to
be
here
is
is
like
there's
potentially
new
requirements
that
increase
the
scope
of
salsa
like
there's
things
that
we're
not
exactly
sure
how
we
want
to
define
it.
And
so
we
don't
want
to
look
at
it
as
a
requirement,
and
then
we
probably
want
to
increase
the
scope.
To
then
include
those
things,
and
how
do
you
communicate
that
in
a
clear
and
consistent
way
where
you
know
folks
don't
feel
like?
C
A
Okay,
so
in
terms
of
making
progress,
it
sounds
like
we'll
go
forward
with
this
proposal
of
like
having
the
two
different
sets
of
levels,
because
I
think
that's
what
I
heard
that
most
people
seemed
like
that
was
their
preference.
A
I
think
we'll
probably
get
a
better
idea
once
we
actually
see
it
written
down,
but
I
think
we
discussed
enough
that
we
have
some
idea.
This
is
still
kind
of
an
issue.
I
think
it
maybe
will
come
down
to
communication
there
of
like
how
we
communicate
what
that
shorthand
means.
Maybe
we
discourage
saying
that
but
say
if
someone
says
it
should
mean
this.
D
D
Yeah,
basically,
all
you're
doing
is
bundling
into
a
let's
say
a
nugget
or
an
npm
package,
the
stl
library
right,
it's
just
source
code,
which
is
header
only
library,
there's
nothing
built
out
of
the
product.
You
have
somebody
claiming
that
it's
safe
and
secure
because
they've
hand
audited
and
did
two-party
code
reviews.
That's
the
only
thing
you've
got
the
base,
that's
safe
on.
A
I
I
think
the
I
mean
the
build
there
would
be
transforming
in
something
that
is
like
from
the
original
form
that
it's
modified
in,
like
they
give
us
a
git
or
material
or
whatever,
into
a
tar
ball
or
a
zip
or
an
npm
package
like
that
is
a
build
because
it
is
not
like
you
can't
just
look
invert.
A
You
can't
compare
the
two
and
say:
oh,
this
tarball
is
definitely
comes
from
the
source
code
because
it's
transformed
in
some
way
it's
not
big
for
a
bit
identical
like
if
you
were
distributing
literally
a
get
tree
then
like
the
hash,
is
the
same
as
trivial
to
check.
But
if
you
have
a
zip
file
with
a
bunch
of
files,
you
need
like
that.
Transformation
is
the
build,
and
so,
if
it
is.
D
But
it's
its
value
is
a
hell
of
a
lot
diminished
than
it
is.
If
we
actually
built
a
binary
right
and
I'm
saying
hey
the
fact
that
you
would
have
very
little
build
attestation
or
evidence
means
that
the
source
levels
become
super
important
and
therefore
what
the
end
user
or
the
the
person
validating
auditing
come
back
with,
saying
hey.
This
is
a
social
level.
Three
or
four.
D
C
Yeah,
we
definitely
do
expect
there
to
be
stuff
for
the
for
the
build
it's
yeah.
I
agree
with
you
that
it's
sort
of
less
useful
information,
because
if,
if
at
the
end
of
the,
if
at
the
end
of
the
day,
it's
just
a
tar
ball,
you're
like
okay,
great,
you
didn't
really
do
a
whole
lot,
but
I
mean
it's
still
useful
to
know
that
yeah
this
thing
was
actually
tarred
up,
but
and
yeah.
It
does
make
oh
go
ahead.
D
C
F
Yeah,
I
wanted
to
add
as
well
that
it's
in
in
some
npm
packages-
well,
maybe
a
few
of
them.
Sometimes
it's
not
at
the
root
of
the
directory
that
that
the
turbo
creation
happens
so
salsa
level.
3
can
actually
give
you
the
exact
command
that
you
can
use
to
reproduce
it
without
having
to
like
manually,
look
up
the
source
code
and
try
a
combination
of
options
to
to
rebuild.
So
I
think
in
that
sense
it's
it's.
It's
also
a
transformation
and
it's
valuable.
D
I'm
not
arguing
that
it's
not
value,
I'm
just
saying:
hey
the
importance
of
a
completely
isolated,
build
step
with
tools
you
understood
and
that
all
the
same
security
patches
doesn't
necessarily
apply
to
a
header.
Only
library
where
all
you're
doing
is
a
packing
step,
because
you
could
be
sidestepping
the
the
fact
that
you
don't
have
to
use
a
git,
repo
or
sub
module
with
credentials
to
go
and
retrieve
the
content.
D
A
Oh
yeah
yeah,
I
don't
think,
there's
any
clean.
That's
why
I
think
we
should
be.
We
need
to
be
clear
about
like
what
salsa
the
build
levels
do
and
don't
provide,
and
we
should
not
make
any
claims
like
if
this
code
is
secure
or
is
good
or
something
just
that
you
have
confidence
that
this
artifact,
that
you
have
really
came
from
this
source.
That's
really
all
it's
claiming!
I
actually
would
argue
that
even
in
a
source,
only
distribution,
the
build
levels
still
matter
because
people
could
inject
code
that
wasn't
in
version
control.
A
So
even
if
you
have
two-party
review
and
every
etc,
it's
not
meaningful.
If
they're.
Well,
not
that
not
meaningful.
There
is
a
significant
threat
that,
during
the
tarballing
process,
someone
could
inject
code
that
doesn't
at
all
reflect.
So
even
if
you're
reviewing
everything
that
goes
into
the
git
commit
you
know
into
into
the
git
repo
there's
no
guarantee
well
that
it's
actually
reflected
in
what's
distributed
to
users
until
you
have
a
sufficient
salsa
build
level
but
yeah.
A
Definitely
I
agree
with
your
point
that,
but
I
think
we
maybe
made
this
other
place
too,
that
we
need
to
be
clear
on
what
salsa
does
and
doesn't
buy.
You.
B
Marcela,
I
also
wanted
to
just
add
that
we
probably
really
want
to
be
clear
what
we
mean
by,
and
I
think
this
is
what
a
few
people
are
saying
before
clear
what
we
mean
by
source
and
build,
because
when
we
say
source
we're
not
actually
talking
about
the
source
code
files
themselves
right
we're
talking
about
how
the
source
is
managed,
even
though
maybe
source
is
shorthand
for
source
management,
or
something
like
that.
But
yeah
just
wanted
to
add
that.
A
Yeah,
let's
try
to
add
a
comment
in
the
doc
they
might
be
misleading.
I
think
it
depends
what
we
ultimately
choose
to
make
the
levels
but
yeah.
I
agree
with
you.
Similarly,
how
like
build
the
build
level,
isn't
very
accurate
because
it's
kind
of
just
identifying
it's
kind
of
really
about
the
provenance
of
like.
If
you
have
providence,
you
can
trust
it
or
like
the
level
of
confidence
in
the
providence.
A
I
guess
is
maybe
the
most
accurate
way
to
say
that
the
maybe
I'll
just
for
the
proposal,
I'll
just
pick
one
of
these
names,
since
it
seems
like
we're
pretty
split
on
what
the
naming
should
be
and
then
leave
that
to
the
broader
community
to
vote.
So
we
have
just
more
more
opinions
on
the
naming
and
leave
it
still
as
like
a
tbd
when
we,
when
we
actually
kind
of
publish
the
proposal,
does
that
sound
okay
since
there's
not
like
overwhelming
support
for
any
one
of
these
names.
A
A
A
And
clean
up
the
comments,
if
you
have
anything
else,
that's
in
the
comments
that
you
want
that
it's
that
should
be
reflected
in
the
doc.
Please
just
make
a
suggestion
or
say
so
otherwise
I'll
mark
the
comments
as
resolved
and
for
this
question
I
think
we'll
just
come
up
with
something
in
a
pull
request
that
actually
implements
okay.
This.
A
A
This
is
the
next
kind
of
one
to
get
agreement
on
within
the
next
minute
or
two
well.
First,
let
me
ask
that
folks
kind
of
look
at
this
and
add
thoughts
if
you,
if
you
think
this
is
just
good
to
go.
A
If
you
could
just
add
your
name
down
here
or
if
you
think
that
there's
something
else
to
do,
add
a
comment
and
then
we
can
discuss
it
next
week
and
if
there's
any
suggestions
you
want
me
to
make
in
the
in
the
doc,
you
could
either
suggest
it
yourself
or
ask
me:
do
that,
but
we'll
do
that
offline,
because
I
don't
want
to
take
time
now,
because
I
want
to
have
time
for
the
topics
and
then
let's
handle,
there's
a
question
about
like
whether
the
prominence
format
is
calling
that
1.0
is
a
blocker
for
calling
the
specification
1.0
any
thoughts
on
that
this,
the
problems
being
the
the
particular
in
toto
schema
versus
like
the
level
definitions.
A
G
B
G
A
That
was
my
inclination
as
well
that
like
they're
not
necessarily
tied
to
each
other,
we
probably
want
to
develop
a
draft
for
both
to
make
sure
they
agree.
But
I
wouldn't
say
it's
a
hard
blocker.
B
Oh,
I
think
it
was
kind
of
like
capturing
all
of
there's
been
a
lot
of
comments
throughout
the
document
about
this,
but
it
was
basically
treating
the
issue
of
how
are
people
going
out
and
saying
that
they've
reached
salsa
level
whatever
and
that
we
should
probably
sort
out
how
to
reach
it
or
like
what
you
have
to
provide
in
order
to
reach
it
prior
to
coming
out
with
version
one
like
that,
should
be
kind
of
a
just
something
we
sort
out.
I
think
that's
where
I
was
going
with
that.
G
Yeah,
so
I
think
that's
the
evidence
of
security
claims.
Peace
at
least
part
of
it
is
that
yeah.
B
B
Okay,
thanks.
A
E
H
What
I
presented
last
week
was
the
first
few
items
in
in
a
design
that
that
I've
been
working
on
joshua
locke
commented
on
my
slides,
thank
you
josh,
but
he
was
commenting
on
something
way
at
the
end
where
the
details
are
that
I
did
not
discuss
so
what
I
did
was.
I
translated
the
part
that
I
presented
actually
the
highlights
the
highest
level
concepts.
I
translated
that
into
english
text
for
easier
discussions,
so
it
is
the
same
material
it's
just
easier
to
to
to
digest,
and
I
would
like
to
solicit
comments
on
this.
H
So
that's
what
I
have
I'm,
not
I'm
not
going
through
the
to
the
presentation
again,
that
would
not
make
sense,
but
it's
basically,
why
do
we
need
a
policy
that
binds
the
source
code
to
the
artifact
and
what
kind
of
policy
can
we
expect
to
use
for
this
without
going
into
details
of
formats
and
management
and
so
on,
because
those
details
are
really
really
tricky.
H
D
It
sounds
more
like
heading
towards
the
classical
and
total
model
of
here's
the
recipe
and
you're
gonna
check
as
you
go
through
it
and
that
doesn't
work
in
a
lot
of
the
incremental
cash
build
scenarios
that
we're
working
through,
and
I
think
that's
going
to
bog
down
and
stall
out
if
we
try
to
bring
it
in
into
here.
At
this
point,.
A
B
Question
is:
is
the
statement
to
be
agreed
with
that
salsa
for
malware
can
be
distributed?
H
Oh,
the
example
shows
that
you
can
distribute
salsa
for
malware
if
you
have
a
policy
that
does
not
look
at
the
source
profiles.
Okay,
thank
you
for
making
that.
C
H
A
Yeah,
I
think
the
how
we
include
if
and
how
we
include
this
into
the
latter
is
a
somewhat
independent
question
that
we'll
do
as
part
of
the
1.0
proposal
to
roy's
point
for
this
doc.
Here
I
think,
and
actually
actually
I
was
going
to
raise
this
question
of
what
do
we?
What
do
we
want
to
do
with
this
doc
and
like?
How
do
we
incorporate
that
into
into
the
salsa?
A
You
know
site?
One
way
could
be
that
we
have
this
in.
We
have
this
like
model
and
terminology
page
that
could
be
one
way
or
create
something
around
control,
salsa
controls,
or
something
like
that.
We
have
like
a
very,
very
bare
bones,
page
in
the
repo
that's
not
actually
published
on
the
website.
It's
like
in
some
folder,
that's
not
the
docs
folder
that
has
like
a
a
couple
sentences.
This
is
obviously
like
a
much
more
detailed
version
of
that
yeah.
A
Oh,
and
in
particular
the
notion
of
like,
can
you
distribute
malware?
I
think
this
is
particularly
for
a
like
if
we
think
about
the
npm
proposal,
where
we
have
salsa
integration
into
an
npm
ecosystem.
Node
package
manager
is
that
if
you
do
like
signature,
checking
and
verification
of
provenance
like
in
the
tool
at
install
time
or
at
upload
time,
you
need
to
have
a
some
notion
of
what
the
expected
source
repo
is.
A
And
without
that,
you
will
be
subject
to
these
significant
attacks
where
someone
could
build
with
the
proper
build
process.
Let's
pretend
github
actions,
because
that's
the
one
that
was
named
in
the
in
the
proposal,
but
it
would
still
be
bad
and
so
there's
still
threats
that
are
not
addressed.
Unless
you
do
this,
and
so
I
think
what
we'd
be
agreeing
to
is
that
that's,
ultimately
what
we
want
to
build
toward?
I
guess.
A
C
Oh
yeah,
as
you
just
say,
I'm
gonna
spend
some
time
reading
over.
I
hadn't
seen
the
this
policy
before
so
I'm
gonna
I'll
make
some
comments,
but
I
I
think
generally
it
makes
sense
and
I
think
also
some
of
it
where
you
can
kind
of.
I
think
we
need
more
of
the.
C
What
does
salsa
not
do
so
that
folks
really
understand
like
where,
where
does
salsa
begin
and
end,
because
I
think
that
there
has
been
some
you
know
like
hey.
I
did
all
the
salsa
stuff
and
you're
like
yeah,
but
did
you
actually
look
at
what
you're
building
you
have
provenance?
So
you
could
always
go
back
and
audit,
but
did
you
actually
really
look
at
what
you're
building?
Because
you
know
garbage
in
is
garbage
out.