►
From YouTube: SLSA Specifications Meeting (November 21, 2022)
Description
Meeting notes: https://docs.google.com/document/d/1kMP62o3KI0IqjPRSNtUqADodBqpEL_wlL1PEOsl6u20/edit#heading=h.yfiy9b23vayj
A
B
A
All
right,
why
don't
we
get
started
thanks
everyone
for
joining,
welcome
to
the
salsa
specification,
Sig,
meaning
as
a
reminder.
Attendance
here
is
agreement,
abide
by
the
lynx,
Foundation
code
of
conduct
and
also
please
sign
in
in
the
specification
meeting
notes
which
we
just
pasted
a
link
in
here
or
salsa.dev
notes:
spec,
that's
a
quick
little
redirect
I,
don't
know
if
if
anyone
has
any
other
agenda
items
Zach
who
I
think
I
saw
here,
asked
a
question
on
slack
around
salsa
Source
requirements.
A
That
would
be
valuable
to
discuss
as
a
group
that
I
could
then
incorporate
into
the
into
the
writing
rather
than
like
making
it
really
nice,
and
then
someone
would
say:
oh
no,
that's
completely
rewrite
everything.
So
that's
that's
it
on
the
agenda
so
far.
If
anyone
else
has
something
please
please
add
it.
A
D
Love
to
yeah,
so
we
are
huge
fans
of
the
salsa
framework
at
GitHub.
We
have
spent
a
fair
amount
of
time
figuring
out
how
to
support
the
build
portions
of
it,
and
then
the
you
know
the
way
these
things
go.
We
sort
of
like
identify
a
need
for
like
Cloud
CI,
CD
platforms.
We
work
with
the
GitHub
actions
team
to
have
them
influence
support
for
it,
and
then
you
know
it
goes
on
their
roadmap
and
they
eventually
are
able
to
work
on
it.
D
D
I
haven't
really
spent
that
much
time
thinking
about
source
and
how
that
might
tie
into
you
know
parts
of
sem
products
like
GitHub
and
then
you
know
maybe
I
should
be
talking
to
teams
inside
of
GitHub
to
to
figure
out
what
features
we
should
be
talking
about
today
that
we
could
Implement.
You
know
in
the
next
three
to
six
months.
That
would
eventually
be
part
of
some
sort
of
like
end-to-end.
D
You
know
salsa
story,
but
then,
but
then
doing
some
research
I
I
did
I
saw
that
you
know
very
rightly,
this
group
has
been
very
focused
on
a
lot
of
the
plexes
are
on
build,
so
I,
don't
really
have
a
specific
request,
or
at
least
not
like
one-
that's,
not
particularly
timely
or
urgent,
but
in
general
the
way
that
we
were
sort
of
thinking
about
what
this
might
look
like
is:
how
would
you
attest
to
Source
properties?
Was
you
literally
walk
through
every
commit?
D
Would
you
potentially
walk
through
all
the
different
code
reviews
that
had
happened?
You
know
looking
for
certain
things,
or
would
you
query
like
the
the
sem
system
about
what
security
properties
were
enabled
over
a
time
period
and
then
trust
that
that
SCM
platform
had
correctly
implemented
those
security
properties?
D
C
A
Like
we
do
need
to
start
thinking
forward
and
like
there's,
probably
some
amount
of
like
just
talking
through
just
the
general
idea,
because
I
think
what
we
have
in
the
one
0.1
spec
is
not
really
workable,
as
I
mentioned
on
the
slack
thread,
the
the
requirements,
as
stated,
don't
really
explain
how
back
far
in
history
and
there's
not
at
least
in
my
mind,
there's
not
like
an
Obviously
good
solution.
You
could
say:
okay,
well,
every
single
commit
needs
to
be
reviewed.
A
Well
then,
that's
just
not
practical,
because
almost
every
existing
project
doesn't
have
every
single
commitment
or
if
they
do,
there's
no
formal
record
of
it.
So
how
do
you
know
so?
You
can
say:
okay
well,
go
back
and
review
every
commit
or
just
review.
Well,
that's
just
not
gonna
happen.
It's
not
worth
time.
A
Another
option
could
be
okay.
Well
just
have
someone
review
the
current
state
of
the
code
base
and
attest
to
that.
Maybe
that's,
maybe
that's
okay,
but
I
think
in
large
Coast
basis.
That
is
again
a
huge
amount
of
time
and
probably
not
worth
the
effort
and
in
practicing
it's
just
not
going
to
happen.
A
Another
option.
I
think
could
say:
okay,
we'll
just
review
the
latest
commit
I.
Please
come
is
just
a
little
diff
and
that
doesn't
really
mean
a
whole
lot
in
the
grand
scheme
of
things
you
could
say:
okay,
the
last
six
months
or
n
months,
but
then
it's
like
it
feels
very
arbitrary
and
it
also
has
the
effect
of
like
once
you
enable
it's
also.
Then
you
have
to
wait
six
months
before
you
get
the
check
box
like
that's,
that's
no
good
either.
A
A
A
D
D
D
E
E
Some
of
these
things
is
even
if
you're
to
cryptographically
sort
of,
like
you
know,
use
git
notes
or
whatever
to
sort
of
add
information
about
code
review
or
other
sort
of
information
directly
into
the
code.
Anything
as
simple
as
like
a
rebase
or
reordering
of
the
commits,
obviously
sort
of
invalidates
all
of
that,
and
it
can
often
become
difficult,
especially
when
you
have,
in
certain
cases
like
like
automated
tools,
like
let's
say,
Tibet
dependabot,
or
something
like
that.
E
That
is
actually
doing
the
commit
on
on
your
behalf
or
whatever,
or
certain
sorts
of
commits
that
are
like
hey.
This
is
a
commit
against
like
this
is
a
commit
against
the
readme
that
just
updates
a
typo.
We
don't
need
to
have
a
three-person
review
or
or
whatever,
but
then
it
becomes
hard
to
know
like
okay.
Well
is
you
know?
How
do
you
sort
of
codify
that
in
a
way
where
to
the
user,
to
the
sorry,
to
the
like
to
the
end
user?
D
D
I
should
have
I
should
have
looked
this
up
before
I
started
this
call,
but
again
you
know
the
this.
It
depends
on
what
VCS
and
scma
are
using,
but
but
for
this
reason
we're
we're
starting
to
investigate
this
idea
of,
like
authenticated,
pushes
so,
instead
of
looking
at
individual
commits
for
a
good
history
that
could
be
Rewritten,
it's
like
what
user
pushed
what
range
of
changes,
or
we
wrote
what
part
of
git
history
over
like
what
period
of
time,
but
you
know,
there's
no,
there's!
No,
there's
no
public
interaction.
A
Another
one
could
have
some
attestations
on
every
single
review.
They
all
if
we
could
clarify
exactly
what
property
like
what
outcome.
We're
trying
to
achieve.
What's
a
realistic
goal,
and
maybe
and
I
tried
to
say
in
the
slack
Channel
I
think,
there's
two
main
goals.
One
is
when
initially
taking
on
choosing
to
use
a
package
like
either
as
a
dependency
or
to
install
it,
having
some
indication
that
it's
safe
or
good,
and
there
you
might
want
to
know
like
the
the
history
of
how
long
it's
been
reviewed.
A
That's
like
probably
one
of
many
different
signals.
The
open,
SF,
scorecards
project
I
think
also
has
a
lot
of
those
type
of
signals,
and
so
maybe
we
integrate
with
that
or
it'll
be
great.
You
know
I
feel
like
we
should
align
with
that,
the
scorecards
there
and
then
there.
The
other
thing
is
for
updates
once
you've
already
made.
That
decision
you've
already
determined
that
I'm
going
to
take
on
this
dependency.
A
You've,
like
said
whatever
the
risk,
is
I
accept
it
any
future
updates.
You
don't
want
to
increase
your
risk
so
like
if
all
of
a
sudden,
a
new
update
doesn't
have
reviewed
code
when
you
are
assuming
all
the
things
were
reviewed.
That
would
be
the
type
of
thing
I
think
salsa
can
add
value
to
where,
like
scorecards
doesn't
capture
that,
because
scorecards
is
kind
of
like
in
a
moment,
whereas
salsa
would
be
like
a
harder
requirements
like
I'm,
assuming
this
and
I
want
that
to
be
true,
going
forward.
A
E
So
related
kind
of
going
back
to
some
of
the
things
about
also
like
being
practical
and
making
sure
that
we're
not
you
know,
saying
hey,
you
need
to
have
done
this
since
the
beginning
of
History,
one
of
the
things
I'm
just
thinking
through
of
what
we
had
done
in
a
previous
life
at
at
a
hedge
fund,
I
used
to
work
at
the
the
way
that
they
had
sort
of
handled
this
same
sort
of
problem
and
we
weren't
using
salsa
salt.
It
didn't
exist
and
we
weren't
using
six
door.
E
Six
door
didn't
exist,
but
we
were
kind
of
created
some
internal
tools
that
were
similar.
One
of
the
things
that
I
think
worked
well
was
one.
Is
you
don't
necessarily
need
to
encode
the
sign-offs
directly
into
the
into
like
something
like
git
notes
or
whatever
into
the
VCS?
One
of
the
things
that
we
had
done
was
we
actually
had
a
transparency
log,
and
so
we
recorded
you
know
the
commit
hash
plus
information
directly
into
the
transparency
log,
and
it
was
all
signed
off
and
and
whatnot.
E
But
the
other
thing
that
we
did
for
practicality
reasons
was
one
was
we
sort
of
said
hey
at
a
certain
standpoint.
Yes,
we
went
back
and
did
a
deep
sort
of
review
of
the
code
and
then
just
sort
of
said
signed
off
on
all
the
previous
commits
and
then
moving
forward.
One
of
the
things
that
that
happened
was
individual,
commits,
didn't
have
to
get
reviewed,
but
releases
had
to
get
reviewed.
D
D
We
thought
very
carefully
about
what
our,
what
our
trust
boundary
was
going
to
be,
and
we
sort
of
landed
on
cloud,
cstv
providers
and
and
Sig
store,
and
so
you
know
we
we
sort
of
deliberately
are
saying
there
that,
like
you,
can't
do
an
npm
build
on
your
laptop
use,
six
store
with
oauth
and
then
say
that
okay,
this
is
you
know,
this
has
the
same
security
properties
and
so
I
think
I.
Think,
as
we
talk
more
about
these
Source
properties,
we're
gonna
have
the
same
sort
of
problem
where
it's
like.
D
D
And
then
the
other
thing
I
was
thinking
about
is
again
kind
of
contrasting,
build
and
Source
properties
right
now,
a
lot
of
the
build
properties
are
sort
of
like
binary
decisions.
Like
you
know,
this
was
your
Source
repo
or
it
wasn't
or
you
know
you
built
on
a
cloud
platform
or
you
didn't
I
I
like
the
idea
of
human
reviews
as
a
way
to
sort
of
like
get
back
to
green.
D
If,
if
you,
you
know
accidentally
land
a
commit,
that's
not
signed
you're
like
oh,
no
everything's,
ruined,
that's
terrible,
but
then,
as
soon
as
we
start
introducing
these
human
processes
we
kind
of
get
out
of
this,
like
you
know,
I,
don't
want
to
say
black
and
white,
but
you
know
more
more
binary
representation
of
what
these
security
properties
are.
They
become
more
subjective
and
I
I
worry
about
trying
to
standardize
the
behavior
of,
like
you,
know,
tens,
hundreds
or
thousands
of
humans.
In
that
case,.
A
Yeah
I
I
I
guess
one
first
note
for
the
record,
with
the
npm
thing
that
like
that
is
the
first
version
right
like
it's,
not
that
six
door
and
GitHub
action
is
the
only
thing
to
be
supported
but
like
rather
than
say,
first
I,
think
just
for
the
record
and
yeah
the
in
terms
of
like
what
has
I
guess
like
prior
art.
Here
I
could
speak
to
what
Google
has
been
doing.
A
We
you
you're
right
like
boiling
it
down
into
you,
know
this
complicated
property,
they've
reviewed
or
not
is
difficult
and
I
think
it's
a
lot
harder
in
open
source
than
it
is
for
within
a
company,
and
we
may
need
to
like
split
the
requirements
there
because,
like
within
a
company,
you
know
well,
if
it's
first
party
code,
you
know
all
the
contributors
and
you
can
have
like
strong
authentication
map
every
account
to
an
individual
person
on
the
internet.
That's
not
really
possible.
A
But
within
Google
we
have
been
using
reviewed
as
a
simple
proxy
like
what
what's
secure
or
not,
is
certainly
there's
a
much
broader
determination
than
that.
But
simply
knowing
that
at
least
two
people
have
been
involved
in
a
change
is
really
valuable
by
itself
and
to
know
that,
like
to,
in
our
case
two
employees
or
two
trusted
persons
like
it
requires
in
order
to
make
a
change
to
a
production
system.
It
requires
at
least
two
people
like
to
to
be
collude
or
compromised,
or
something
like
that.
A
I
think
it's
a
valuable
property
and
it's
probably
a
valuable
thing
for
salsa
to
kind
of
like
strike
toward
both
both
not
just
at
the
source
code,
but
throughout
the
throughout
all.
The
systems
like
the
build
systems
as
well
should
should
be
designed
in
a
way
that,
like
that's
the
kind
of
property
that
we're
trying
to
achieve-
it's
not
perfect,
but
it's
it's
like
a
good
first
step.
E
Yeah
and
I
think
to
build
on
on
top
of
that,
a
little
bit
is
I.
Think
to
what
you
were
talking
about.
Zach
is
I.
Think,
generally,
you
know
users
are
going
to
want
to
be
able
to
especially
launch
our
organizations
are
going
to
want
to
be
able
to
also
say
who
they
trust
and
and
what
services
they
trust
and
and
and
so
on.
I
know
when
it
comes
to
like
different
package
managers,
they're
going
to
want
to
keep
their
stuff
relatively
clean,
so
they're
gonna,
say
hey.
E
E
This
and
hey
I
trust,
Google
or
here's
a
third-party
audit
firm
that
took
a
look
at
this
project
and
they
think
that
you
know
hey
based
on
their
assessment,
they're,
pretty
sure
that
everybody
there's
no
sock
puppet
accounts
in
this
project,
and
then
you
know
an
organization
might
say
cool.
You
know
I'm
going
to
look
at
that
certification
and
say:
okay,
now,
I'm
going
to
take
a
look
at
their
stuff.
F
I
did
have
a
Mark
I
tend
to
agree
with
the
the
value
of
the
two-person
review
is
super
important,
the
one
some
of
the
more
advanced
scenarios
where
people
do
a
pull
request
into
somebody
else's
pull
request.
Does
that
negate
them
being
one
of
the
two
people?
Reviewers
is
an
interesting
set
of
questions
that
I
don't
know
the
answer
to
or
how
to
figure
out
the
problem
space,
but
we
have
a
lot
of
challenges
and
I
think
we
have
a
lot
of
small
people
here
that
can
help
us
with
that.
F
G
H
On
how
about
now,
oh
there,
he
is
all
right,
there's
a
there's,
a
separate
switch
that
somehow
got
moved
and
I
never
used
that
switch.
So
okay,
soccer
I
was
gonna
comment
quickly.
That
sock
puppetry
is
very
hard
to
counter,
depending
on
the
level
of
assurance.
You
want
to
claim
you
know
if
it's
simply
that
you
know.
First
of
all,
having
a
second
reviewer
I
mean
we've
got
a
tack
issue,
I
think
101.
H
H
If
you're
going
to
have
multiple
people
review
more
than
one
person
review,
what's
the
confidence
level
that
you
need
to
make
sure
that
that's
a
second
person
I
think
it's
much
easier
within
a
company
I
mean
within
Microsoft
within
Google.
Hopefully
you
can
figure
out
when
different
employees
are
actually
different
employees,
it
does
become
much
harder
for
a
straight
up
open
source
project,
especially
since
there's
a
large
number
of
people
well,
I
mean
I.
Think
it's
a
minority,
but
it
is
a
an
important
minority
who
really
really
are
private
people.
H
They
do
not
want
their
Pub,
their
real
names
out
there
for
a
variety
of
reasons,
and
if
the
only
issue
is
you
just
want
to
make
sure
that
they
are
not
sock,
puppets
I
mean
simply
having
two
different
accounts:
I
think
for
a
lot
of
risk
mitigation.
That's
adequate!
If
you
don't
want
to
go
there,
then
you
need
to
say
well
who
can
determine
whether
or
not
that
is.
H
Well,
I'm
kind
of
I
I'm
I'm,
inviting
this
discussion
about
how
strong
do
you
need
this
assurance
to
be
I
mean
you
can
simply
have
the
requirement
that
hey
it's
got
to
be
two
people
and
leave
it
up
to
others
Judgment
of
how
far,
and
if
you
want
to
make
a
requirement
well
now
we
need
to
be
specific
about
how
hard
we
want
to
be
I.
I
would
worry
about
level
three,
you
know:
hey.
We've
got
to
have
some
sort
of
independent
audit.
Of
of
that
there
are
two
people
are
actually
two
separate
people.
H
H
The
LF
actually
have
a
requirement
with
for
the
Linux
kernel,
but
we
also
don't
impose
that
I
mean
you
can't
impose
that
on
all
open
source
projects,
and
we
simply
impose
hey
I,
know
for
sure
that
somebody
knows
who
you
are
not
the
public
does
so
you're
gonna
have
to
trust
us
that
in
fact,
they're
separate
people,
it's
not
something
you'd
be
able
to
independently
vet
because
they
don't
want
to
be
known.
Some
of
these
people
don't
want
to
have
their
public
identities
known.
D
I
know
I,
know,
there's
a
there's.
A
second
topic,
so
I
think
I
think
maybe
we
should
yield
the
floor.
It
seems
like
the
conclusion
that
we're
coming
to
is
that
Source
salsa
properties
are
complex.
We
need
to
have
some
more
discussions
about
what
they
are
and
what
they
actually
look
like
in
practice
and
I.
Think
that'll
be
that'll,
be
sort
of
part
of
this
ongoing
effort,
and
you
know
it's
it.
We
maybe
already
knew
that
we,
we
weren't
ready
yet
to
come
to
a
conclusion
on
some
of
these
questions.
A
Yeah
but
I
do
think
it's
it's
valuable
to
continue
like
talking
about
this
periodically
because
like
if
we
serialize
everything
and
do
all
the
build
stuff
then
get
the
source
it's
going
to
be
a
long
time
before
we're
really
ready,
and
so
it's
probably
a
good
day,
like
think
about
some
stuff.
You
think
about
a
couple
weeks.
Months
later,
like
oh
I,
have
an
idea,
yeah
I
one
thing:
I
want
to
mention
that
or
like
to
put
it
up
for
for
a
thought.
Just
kind
of
going
forward
is.
A
Can
we
describe
like
it
could
be
the
case
that
we
just
say
higher
levels
like
projects
open
source
projects
that
can't
meet
that
requirement
just
never
get
to
that
level,
and
that's
okay
and
it
just
represents
a
higher
risk
level
and
people
who
take
on
that
dependency,
choose
to
accept
that
risk
level
and
that's
exactly
what
the
source
level
is
trying
to
represent.
Is
this
this
risk
level
that
could
be
one
solution.
A
Another
possible
solution
could
be
an
alternative
to
two-party
review
where
we
could
kind
of
get
at
the
same
risk
level,
because,
ultimately,
that's
what
we're
trying
to
do.
I
think
is
is
not
necessarily
two-party.
Review
is
the
goal,
but
that's
a
means
to
reducing
risk,
and
if
we
have
some
other
means
of
doing
that,
like
maybe
post
review
or
other
people
vetting
it
or
maybe
number
of
people
who
are
depending
on
it
or
I,
don't
know.
I
could
believe
that
be
the
case.
A
H
Yeah,
it
might
be
helpful
to
kind
of
step
back
I'll.
Just
a
little
bit
I
mean
you
have
to
be
careful
about.
You
know,
let's
step
back
to
the
beginning,
that's
not
what
I'm
trying
you
know
but
try
to
work
out
some
of
the
threat
and
you
know
threaten
use
cases.
I
do
agree,
it's
totally
fair
to
say
Hey,
you
know
it's
not
that
you
can't
use
is
that
there's
a
differentiated,
Threat,
Level
I,
do
think.
There's
a
different
case
between
you
know.
H
I
I
do
believe,
at
least
in
my
experience
that
the
vast
majority
cases
when
there's
multiple
reviewers
they're,
actually
different
people,
I
mean
I'm,
not
going
to
say
soccer
doesn't
happen,
but
it
is
not
the
most
obvious
risk
right
now.
I
mean
you
know.
Screw-Ups
by
people
who
write
bad
code
is
way
more
common
than
someone
creates
sock
puppet
and
if
your
threat
is
malicious,
nation-state
actor
sock
puppetry
is
not
actually
your
bigger
problem
there.
You
know,
there's
a
whole
organization
of
a
hundred
people
who
are
helping
to
write
this
malicious
code.
H
For
you,
the
fact
that
has
multiple
person
review
is
not
the
solution,
so
I
I
don't
want
to
get
to
the
idea
of
oh
look.
We
vet
for
sure
there's
no
stop
cup
puppetry
there.
First
there's
no
risk
a
yeah.
Let's
go
back
to
the
threat
model
here.
If
your
threat
State
model
is
nation
state
actors,
you
know
that
is
not
the
end.
In
fact,
that
doesn't
really
help
very
much.
C
A
Relative
difficulty,
right
of
like,
if
it
increases
the
bar
of
you,
have
to
compromise
two
maintainers.
Instead
of
one
it's
an
increase
right,
it
increases
the
attacker's
cost,
it
increases
the
risk
of
their
detection,
so
yeah
I
feel
like
for
all
of
us.
Also.
We
should
always
be
thinking
in
terms
of
like
relative
increases,
as
opposed
to
absolutes.
A
A
A
Okay,
last
time,
I
talked
I
showed
kind
of
like
an
idea
of
like
having
a
table.
There
were
some
pros
and
cons
of
having
getting
rid
of
the
check
boxes,
I,
re-added
the
check
boxes
and
but
tried
to
collapse
it
into
simple,
like
one
row
per
level,
and
so
what's
in
my
current
draft,
based
on
what
the
feedback
I've
gotten
so
far
is.
A
A
Then
the
build
system
generates
provenance.
There's
like
a
level
one
two
three.
We
need
to
come
up
with
probably
better
names,
and
last
time
we
also
mentioned
hosted
and
fully
isolated
are
not
good
names.
We
got
to
come
up
with
better
names,
but
some
thing
to
kind
of
show
the
isolation
strength,
and
this
also,
we
also
mentioned
last
time
around
having
like
a
possible
level
four
column,
something
like
that
yeah
those
are
all
still
noted,
but
just
not
implemented
yet,
and
similarly,
the
packaging
ecosystem,
we
kind
of
show
what
they
do.
H
C
A
One
would
be
like
a
formal
packaging
distribution
system
like
like
a
language
one
like
Pi
Pi,
the
python
package
index,
an
OS
specific
one
like
the
Debian
project,
which
produces
Debian
packages
or
oci.
The
open
container
initiative
is
that
what
it's
called
for
Distributing
container
images
like
it
could
be
a
formal
thing
like
that
it
could
be
an
informal
one
within
a
company
or
an
organization
like,
for
example,
within
Google.
A
A
E
Like
hey,
I'm
I'm,
using
like
red
hat,
you
know
RPMs
to
install
you
know,
Python
and
some
basic
python
packages,
but
then
I
use
pip
after
that
and
there's
a
lot
of
confusion
as
to
what
does
that
look
like
and
and
and
should
those
things
be,
even
interoperable,
you
know
or
whatever
and
like
generally.
Obviously
we
want
to
make
sure
that
a
salsa
attestation
for
one
package
should
be
the
same
as
any
other
package,
but
I
know
that
sort
of
thing
has
has
gotten
folks
a
little
confused.
D
Sec,
yeah
I'm
I'm
a
little
bit
newer
to
this
part
of
the
conversation,
but
thinking
back
to
our
previous
conversation,
you
know
the
the
idea
is
like.
Can
we
can
we
articulate
General,
Security
capabilities
for
security
properties
such
that
it?
You
know
it
almost
doesn't
matter
if
you're
using
a
language
packed
to
enter,
or
you
know,
clicking
a
URL
to
download
and
I'm
thinking
of
like
this
is
very
off
the
cup
things
like
Integrity
checks.
Like
you
know,
the
the
package
manager
has
some
way
to
determine
if
the.
F
Something
stepping
into
the
world
in
which
s-bombs
are
meant
to
solve
right,
s-bombs,
we
believe,
are
signed
and
they
have
the
hash
of
the
content,
so
that's
their
phone
functionalities.
So
this
is
where
we're
kind
of
bleeding
between
two
different
Technologies.
So
we
have
to
be
very
carefully
well.
D
D
F
But
if
we're
seeing
openssf
and
the
community
saying
s-bombs
for
every
package,
then
why
are
we
fighting
Upstream?
Well,
should
we
just
not
accepted
and
said
that's
solved
by
that
problem,
space
and
move
on
this
is
where
I'm
really
pushing
on
hey.
If
we
already
have
to
have
s-bombs
and
that's
the
way
of
the
future,
why
are
we
fighting
it.
A
I
I,
don't
think
I,
guess
I
I
kind
of
half
agree
and
have
disagree.
Roy,
like
I'm
kind
of
split
here,
I,
agree
that
it
is
undesirable
to
have
two
different
things
that
are
very
similar
and
overlapping,
and
if
we
could
do
it
with
one
that
would
be
better
where
I
struggle
with
is
that
s-bombs
are
not
designed
to
solve
the
same
problem.
S-Bombs
are
designed
for
Integrity
I'm,
sorry
for
vulnerability,
management
and
Licensing,
and
that's
like
the
primary
purpose,
because
you
want
a
high
signal
to
noise
ratio
like.
A
C
H
David
yeah
I
was
gonna,
say
I
I
view
these
as
somewhat
different
I
mean
Salsa's
going
in
and
saying
hey
in
order
to
have
you
know
strong
Integrity,
you
need
to
do
X,
Y
and
Z.
No
one
to
my
knowledge
is
saying
you
know
you
know:
I'm
I'm
from
organization,
X
I
will
only
accept
s-bombs
if
they
come
in
this
particular
way.
I
mean
frankly,
a
lot
of
organizations
are
grabbing
bags
of
bits,
running
analysis
tools.
H
You
know,
sometimes
the
the
analysis
tools
get
get
it
right
in
a
couple
cases
and
there's
your
s-bomb,
and
so
you
know
the
the
whole
notion.
The
s-bomb
for
a
lot
of
folks
is
a
list
of
dependencies.
Not
necessarily
a
proof
of
you
know
a
list
of
here's
how
we
ensured
that
we
produced
it
with
a
certain
level
of
Integrity.
F
Look,
you
may
not
agree
with
it
I
and
I.
This
is
where
I'm
pushing
back
saying:
hey.
We
have
an
intersection
between
other
Technologies,
where
other
groups
like
Vex
and
and
so
forth.
Here
we
have
to
be
cognizant
that
we're
about
to
overlap
between
them
and
we
shouldn't
try
and
make
it
more
confusing.
F
It
already
is
the
fact
that
that
all
the
files
in
the
package
have
to
be
listed
in
the
s-bomb
is
its
fundamental,
because
it's
called
Ebola
materials,
not
a
dependency
graph
right,
the
dependency
stuff
is
there,
so
we
just
when
we
have
these
intersections,
because
we
still
have
git
bomb
out
there
too,
as
well.
There's
places
where
we're
going
to
intersect.
E
A
A
Zach
brought
it
up
that
you
know
like
around
like
download.
You
know
like
when
you
download
Over
the
web.
You
have
some
tooling
or
something
like
that.
I
think
it's
orthogonal
to
like
the
ecosystem,
specific
thing.
So
if
I
say
I
suggest
that
maybe
we
kind
of
shelved
that
for
now
does
that
sound
good
to
folks,
Roy.
F
Everyone
yeah,
there
is
a
discussion
of
post-production.
What
do
we
do
like
anti-malware
plans?
Are
they
salsa
claims
and
they
update
and
I'm
hedging?
My
bets
as
in
my
mind
where
salsa
Fitz
is
up
to
production.
The
s-bomb
then
carries
off
and
then
we
get
into
Vex
and
and
additional
claims
that
aren't
necessarily
salsa
or
maybe
they
are
and
I
don't
know.
I
think
that's
pretty
nebulous
to
me
Mark
at
that
point,
when
we
transition
from
from
a
to
something
new.
H
Think
about
that
David
yeah,
so
just
just
to
quickly
wrap
this
up.
I
agree
with
Roy
that
we
want
to.
You
know
separate
out
different
Technologies
to
reduce
confusion,
but-
and
hopefully
the
position
folks
can
do
this
I
actually
had
a
minor
Point
earlier
Mark
you
listed
different
types
of
Packaging
Systems
system,
language,
ecosystems,
containers,
I,
would
also
add
virtual
machine
images.
They
have
exactly
the
same
kinds
of
properties.
So,
as
you
know,
except
and
now,
there's
a
kernel
in
there
so
and
and
same
challenges.
A
Yeah
thanks
yeah
I,
don't
want
to
dismiss
Roy's
Point,
because
I
think
it's
very
good
and
important.
It's
also
I
think
really
hard,
like
one
reason
why
we
haven't
used,
for
example,
like
bring
us
back
to
specific
specification
meeting
in
terms
of
formats
of
like
why?
Don't
we
just
use
spdx
or
Cyclone
DX
instead
of
inventing
our
own
provenance
format,
I
can
speak
specifically
to
that
which
we
there's
an
issue.
A
If
we
had
enough
bandwidth,
we
would
sync
with
them
and
we
would
all
come
up
with
something
that
works
for
all
the
use
cases,
and
that
would
be
great.
It
just
takes
a
lot
of
time
and
so
I
think
the
route
that
seems
to
make
sense
and
everyone
seems
to
be
okay
with
which
is
to
for
now.
We
have
different
formats
for
different
use
cases.
It's
not
ideal
because,
like
it's
confusing
that
there's
like
a
salsa
provenance
and
the
s-bomb,
ideally
once
they.
A
Iron
Out
The
Kinks,
we
kind
of
know
the
use
cases
they
get
Battle
tested
and,
like
the
rate
of
change,
slows
down.
I
think
we
could
then
maybe
try
to
ideally
align
them
yeah.
So
anyway,
that's
that's
kind
of
what
what
I
was
thinking
there,
but
I
do
think.
The
explanation
of
how
they
relate
is
super
murky
and
that's
one
thing
that
they
specific
the
positioning
Sig
should
be
responsible
for.
A
I
just
haven't
written
it
yet
and
there's
basic
things
that
they're
doing
like
build
systems
are
really
doing
two
things
generating
provenance
and
isolating
between,
builds
they're
related,
but
not
quite
the
same,
and
then
there's
effectively
one
row
per
level,
and
we
don't
have
like
multiple
rows
per
level
because
it
just
gets
too
confusing
and
effectively.
This
is
like
the
degree
to
which
this
is
done,
like
available
authenticate
and
unaffordable.
C
F
If
you
think
of
the
classical
installer
for
Windows
and
you're
installing
to
make
a
container
and
install
software,
you
typically
have
to
run
as
admin
which
kind
of
violates
that
there's
no
admin
on
the
box
sort
of
Paradigm,
because
it
was
designed
to
be
a
user
action
of
elevated
proportions.
Right
until
we
move
to
here's
a.
How
do
you
then
consider
that
as
part
of
the
packaging
system,
or
is
it
another
build
step
of
the
package?
F
E
A
I
think
there's
also
by
the
way,
a
difference
between,
at
least
in
my
mind,
a
difference
between
you,
take
some
inputs
and
then
transform
them
in
some
way
and
then
create
some
output.
That
is
then
distributed
like
if
you're
creating
a
container
image
by
doing
like
installs
and
whatever
ecosystem
and
mash
them
together,
and
then
you
have
this
container
image
or
VM
or
whatever,
and
then
that
gets
distributed.
That
would
be
a
build
in
the
salsa
model,
and
so
the
new
output
thing
is
a
different
package
than
the
input
ones.
A
That's
something
I
would
like
to
it's.
Also
to
cover
eventually
but
I,
don't
think
we're
there.
Yet
I
was
like
because
that's
effectively
like
an
aggregate
of
salsa,
but
there's
no
output,
artifact
there
you're
kind
of
like
running
as
a
service.
That's
something
like
we
haven't
gone
into
here.
I
feel
like
salsa
is
just
about
packages
of
like
you
transform
one,
some
input
packages
to
an
output
package.
A
A
H
A
B
A
Would
it
be
valuable
for
me
to
like,
because
I
feel
like
I,
keep
saying?
Oh,
it's
not
good
enough
to
publish
I
keep
doing,
should
I
just
put
on
GitHub
now,
like
the
current
state,
with
like
a
mess
of
text
and
like
a
bunch
of
animated
stuff.
Okay,
yes,
all
right!
I'll
just
do
that
and
with
a
clear
comment
like
there's
a
bunch
of
garbage
text
here,
but
it's
at
least
a
half
written
thing.
Yeah.
B
I
I
think
the
like
what
you
did
with
the
province:
One
spec,
where
you
share
that
with
all
the
to-do's
and
we
got
a
bunch
of
feedback
and
at
some
point
we're
going
to
have
to
say
this
is
you
know,
we've
got
some
kind
of
consensus
is
good
enough.
Let's,
let's
merge
something
but
I'm
more
than
happy
to
provide
feedback
on
early
drafts.