►
From YouTube: SLSA Specifications Meeting (September 12, 2022)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right,
it's
five
minutes
in
so
I
think
we
could
get
started.
Welcome
everyone
good
to
see
you
again.
I
was
out
the
last
three
weeks.
Sorry
I!
Guess
we
had
two
weeks
off
right
for
the
two
different
holidays,
so
it's
been
a
while.
So
welcome
back
everyone
as
a
reminder,
if
you
could
add
your
name
to
the
attending
list
in
the
meeting
notes
which
I
just
pasted
in
the
chat
that
would
be
appreciated.
A
People
here,
I
synced
with
Joshua
Locke
briefly
this
morning,
so
he
kind
of
filled
me
in
a
little
bit
what
what
went
on
in
the
previous
meetings?
A
The
first
item
Joshua,
wanted
to
briefly
just
talk
about
Rules
of
Engagement
for
the
for
the
meeting
and
kind
of
the
purpose
of
the
meeting,
just
to
remind
everyone
that
were
intending
these
meetings
to
get
like
high
level
agreement
on
approach,
but
then
we'll
work
out
like
the
actual
details.
You
know
and
pull
requests
or
something
like
that,
and
so
we
don't
necessarily
need
to
agree
on
all
the
details.
Just
as
long
as
we're.
A
Generally,
in
the
right
direction
enough
that
people
could
go
off
and
start
start
doing
things
just
to
avoid
kind
of
like
rat
holding
and
specific
issues.
A
To
be
said
about
that,
the
first
item
on
the
agenda
was
by
Emmy
Joshua,
Mulliken
and
Laura
about
trademarking
and
Licensing.
C
Just
kind
of
going
back
to
I
know
it
was
a
previously
discussed
topic,
but
I
thought
it
might
be
valuable
to
kind
of
bring
up
an
idea.
I
know
part
of
the
the
issue
originally
discussed
was
well.
You
know
it's
hard
to
obviously
attest
or
assess,
assess
compliance
with
salsa
for
everyone
who
claims
salsa
compliance.
C
However,
I
was
thinking
about
an
approach
to
some
other
organizations
have
taken,
which
is
where
they
will,
where
you
can
specifically
license
a
badge,
for
example,
where
the
badge
can
only
be
used
if
you
meet
certain
requirements,
and
so
that
would
get
legal
at
companies
involved
before
they're
able
to
use
the
the
badge
legal
would
have
to
do
a
review,
otherwise
they
could
get
in
trouble
at
a
future
date,
and
that
would
take
all
the
burden
off
of
you
know
this
organization
to
assess
anything
and
so
and
then,
if
they
were
not
complying-
and
you
know
a
customer
potentially
of
a
company
found
that
they
accompany
their
buying
products
from
or
Services
was
not
fully
compliant,
then
there
would
be
a
kind
of
some
sort
of
argument
to
remove
that
badge.
C
So
I
was
wondering
what
everyone
thought
about
that
potential
use
case.
For
you
know
kind
of
using
licensing,
trademark,
trademark
law
license
law
in
order
to
ease
our
burden,
but
also
gain
consistency
in
organizations
claiming
to
have
High
compliance.
D
C
You
know
attestation
through
some
sort
of
license
agreement
would
be
fine
for
a
smaller
organization
because
they
would
have
full
knowledge
of
what
they're
doing
or
or
maybe
even
an
open
source
organization
could,
you
know,
would
be
able
to
do
a
would
be
able
to
do
a
good
face
understanding
of
themselves,
but
I
think
the
really
the
risk
here
is
that
salsa
is
going
to
get
claimed
by
every
company
out
of
the
Under,
the
Sun
in
order
to
sell
product
and
they're
going
to
kind
of
we're
gonna
end
up
in
a
situation
where
everyone's
claiming
it's
also
level
four
and
no
one's
actually
doing
salsa
level
four
and
then
who
can
trust
salsa?
C
It
doesn't
really
it's
going
to
be
used
as
a
marketing
tool
and
I.
Don't
think
open
source
communities
have
that
kind
of
incentive
to
to
do
that
from
a
malicious
standpoint,
but
we'll
definitely
be
taken
advantage
of
by
companies
with
a
market
driving
perspective.
So.
B
A
Universal
agreement,
I
mean
I,
think
so
I
guess
maybe
I'll
start
with
I.
Think
that's
a
good
idea
and
I.
Don't
I'd
not
thought
of
that
before.
So
that's
I
think
that's
interesting
and
we
should
definitely
keep
it
in
mind,
and
maybe
that
solves
like
the
technical
enforcement
piece,
but
I'm
not
sure
that
we
have
Universal
agreement
on
like
even
the
standard
of
what
would
actually
meet
it.
A
So,
for
example,
yeah
fifth,
you
run
if
someone
runs
I,
won't
name
it
any
specific
brand,
but
like
XYZ
build
service
and
they
you
know
lock
it
down
to
some
extent,
but
are
there
operational
practices
and
implementation
and
design
sufficient
I
feel,
like
that's
kind
of
a
judgment,
call
and
some
organizations
might
say
yes
and
some
might
say
no,
and
so
even
if
there
were
like
a
legal
argument,
I
don't
know
what
standards
we
would
be
applying
like
that.
C
I
think
that
could
be
where
you
know
part
of
the
trademark
idea.
If
salsa
is
trademarked,
then
no
one
can
use
it
and
then
we
can
kind
of,
as
we
think
about
you
know,
hey
what
what
evidence
is
needed
to
say
that
your
salsa
zero?
We
haven't
thought
about
that
or
it's
also
one.
Sorry,
we
haven't
thought
about
that.
Yet
really
we
don't
quite
know,
we
don't
know
exactly
what
that
would
look
like,
but
as
we
understand
it,
more
and
people
continue
to
to
discuss
it.
Oh
well.
C
Maybe
we
can
come
out
with
a
badge
for
salsa
level,
one!
Oh!
Well
now
we
understand
level
two
better.
We
understand
it
enough
to
say
this
is
how
you
comply.
Well
now
we've
come
out
with
salsa
level
two
badge
and
the
licensing
allowing
you
to
use
it
as
a
company
right,
so
I
think
we
can
do
it
without.
We
don't
have
to
understand
it,
but
I
think
we're
going
to
be
taken
advantage
of.
C
If
we
don't,
you
know,
we
don't
quite
know
what
would
meet
the
standard.
It
is
a
judgment
call,
but
that
needs
to
be
ironed
out
and
if
it's
not
ironed
out,
then
it
will
be
in
a
situation
where
we
could
be
in
a
situation
where
it
becomes
all
of
a
sudden.
It's
also
meaningless
because
everyone's
also
level
four,
because
they
went
and
judgment
called
that
they're
salsa
for,
even
though
it's
not
even
clear
how
you
get
there
yet
well,.
A
I
guess
I
guess
it's
a
question:
I,
don't
know
if
it's
for
the
salsa
organization
or
for
the
larger
open
ssf
of
do
we
want
to
be
in
the
business
of
certifying
specific
services
implementations
or
do
we
want
to
say
that?
No,
that
is
not
the
business
we
want
to
be
in
and
offload
it
to
another
organization
that
does.
C
Yeah
I,
don't
think
we
want
to
be
probably
want
to
be
in
the
business
of
of
doing
auditing.
You
know
that's
not
necessarily
our
area
of
expertise,
but
I
do
think
that
providing
controls
to
prevent
the
salsa,
the
salsa
guide,
the
standard
having
it
be
well.
This
is
a
standard
that
helps
you
build
your
build.
A
solid
security,
build
solid
security
controls
around
building
your
software
versus
this
is
a
marketing
term
that
you
can
use
to
trick
people
into
using
your
product,
even
though
it
might
not
actually
meet
all
the
controls.
That's
the
danger.
C
I
see
is
that
people
are
going
to
see
it.
Oh
it's
also
level.
Four,
it's
also
level
four
is
a
good
standard.
I
read
it
it's
pretty
cool,
they
must
be
doing
a
great
job
and
then
they're
going
to
get
duped
into
buying
something
that
might
not
be
and
I
don't
want
to
participate.
I,
don't
think
we
should
put
ourselves
in
a
position
where
we
can
participate
in
that.
You
know
kind
of
potentially
nefarious
use
of
of
the
standard.
A
Yeah,
maybe
put
it
another
way
if,
in
the
absence
of
having
such
a
badge,
that
has
like
some
sort
of
trademark
enforcement,
people
will
just
start
to
do
anything
and
there
won't
be
anything
for
consumers
effectively
to
pick,
and
so
it
would
probably
be
wise
to
get
ahead
of
it.
Yeah.
E
E
We're
talking
a
lot
of
we're
talking
about
a
lot
of
stuff
that
should
be
talked
about
in
the
positioning
meeting
and
not
the
specification,
meaning
as
a
matter
of
fact,
the
implica.
The
implications
of
what
we're
talking
about
is
exactly
what
should
be
discussed
in
this
meeting.
For
instance,
whether
or
not
the
controls
that
are
within
salsa,
whether
whether
or
not
they
are
written
with
enough
rigor
to
potentially
become
some
type
of
a
compliance
article
that
companies
would
use.
E
You
know
with
maybe
a
third-party
organization
to
to
receive
some
type
of
compliance,
then
maybe
a
badge
would
be
issued
that
could
be
defensible
later
on
right,
but
but
once
again
the
controls
is
inspect.
The
specification
itself
is
what
we
talk
about
here.
All
the
rest
of
that
stuff
is
positioning,
I,
think
that
might
be
out
of
scope
for
this
meeting.
C
Sounds
good
yeah,
we'll
readdress
in
the
positioning
then.
A
So
I
wanted
to
continue
to
talk
about
the
1.0
proposal,
but
Sebastian
and
Preston.
If
you're
the
follow-on
item
is
relatively
short.
Maybe
we
could
talk
about
that.
First.
F
Don't
necessarily
have
to
jump
the
schedule.
It's
it's
up
to
you,
folks.
F
Okay,
so
we
were,
we
were
trying
we're
trying
to
decide.
You
know
where
our
build
system
Falls
at
Anaconda
in
terms
of
current
salsa
level,
and
it
run
into
two
places
where
things
were
a
little
vague
and
one
in
particular.
F
That
was
that
I
thought,
at
least
through
some
comment
or
we
both
thought
drew
some
comment
here
and-
and
maybe
this
is
more
of
a
subject
for,
as
you
mentioned,
I
think
for
issues
or
PRS
or
something,
but
you
know
I'm
having
really
discussed
it
here
before
so
I
thought
I'd
get
a
sense
of
you
know.
F
What's
the
level
of
you
know
certainty
about
these
things
and
how
fixed
they
are
so
the
level
two
there's
a
link
in
the
agenda
item
the
level
two
Providence
authenticated
Criterion
has
a
should
clause
in
it.
I
don't
I,
don't
know
Preston,
you
have
it
currently
up,
but
let's.
B
F
Right,
it's
just
like
the
the
private
key
is
accessible
only
to
the
service
generating
the
provenance
which
so
I.
This
did
something
that-
and
this
is
also
the
thing
that
came
up
in
tough
conversations
previously,
but
it
sort
of
doesn't
distinguish
between
like
key
exfiltration
risk
and
like
key
use
risk-
and
you
know-
maybe
that's
fine-
maybe
that's
part
of
the
design,
but
it
I
think
it
can
easily
be
interpreted
in
a
way
that
makes
it
sort
of
impossible.
F
You
know,
because
you
have
to
be
able
to
access
the
key
in
order
to
rotate
the
key,
for
example,
by
installing
in
the
first
place
and
maintain
the
system
that's
on
whatever
that
is,
but
it
also
I
think
can
be
seen
as
pretty
loose
so
I.
F
F
A
Yeah
I
I
see
yeah.
Can
you
file
an
issue
for
this
and
then
tag
it
with
the
or
or
CC
man?
I'll
tag
it
with
the
clarification
one
I
think
this
is
something
that
should
be
addressed
for
1.0
I
agree
with
what
you
said.
B
A
I'm
trying
to
find
it
but
I
can't
KMS
requirement
is
to
there's
there's
this
similar.
It's
somewhat
similar
issue
around
it
being
too
prescriptive.
A
If
you
want
I,
don't
know
if
it's
useful
or
not
having
two
separate
issues
or
just
merging
the
issue
and
expanding
it
to
be
to
cover
to
cover
the
issue
more
broadly,
either
way
works,
but
I
agree
that
we
should
Do
It
having
examples
is
another
yet
another
issue
that
we
want
to
do
for
1.0
and
and
being
more
clear
on
what
the
guidance
is,
would
be.
F
B
Right
I'll,
we'll.
F
Look
at
those
and
add
some
that's
great
great
meeting
notes,
similar
issue.
A
A
Yeah
and
again,
if
we're
working
out
the
details
of
the
wording,
Let's
Do
It,
any
other
comments
on
that.
A
So
for
the
1.0
proposal,
I
I,
my
goal
is
to
try
to
get
toward
being
able
to
actually
start
implementing
it,
meaning
updating
the
website.
Excuse
me
and
so
I
think
the
two
remaining
well
I
think
there's
there's
three
major
remaining
things.
One
is
the
evidence
of
build
security
claims.
I
know
it's
just
I
think
it
was
discussed
at
last
meeting
I.
We
haven't
mostly
agreement
on
it.
There's
some
open
questions.
I
think
Melba
is
here
right.
A
Yeah
Melba's
here
who
had
a
couple
open
questions
I
propose
that
we
Mark
that
as
basically
decided
and
we
work
out
the
details
in
the
actual
you
know,
write
up,
but
I
think
we're
basically
on
the
same
page
around
the
idea.
Any
objections
to
that.
A
Okay,
I
will
take
that
as
a
agreement.
A
Decided,
okay
and
and
I'll
leave
the
the
existing
comments
open
and
if
you,
if
you
have
any
comments
here,
if
you
could
resolve
them,
that
would
be
great
either.
Updating
the
text
or
just
marking
as
a
result,
I
think
we'll
try
to
incorporate
the
ideas
that
were
discussed
in
the
comments
in
the
actual
pull
request
the
and
feel
free
to
interrupt
by
the
way.
A
The
next
was
redefine
levels
as
outcomes,
not
requirements
that
one
generally
didn't
have
any
traction
in
this
group
or
with
anyone.
I
propose
that
here
actually
I
could
present
my
screen.
So
you
could
see
what
I'm
talking
about.
A
Okay,
all
right,
I'm,
no
longer
muted.
All
right,
you
can
hear
me
right,
so
this
section
redefine
levels
as
outcomes.
I
propose
that
we
just
chop
it
out.
I
think
the
idea
might
still
work,
but
we
could
just
do
it
in
a
pull
request
and
see
if
people
like
it
as
opposed
to
having
to
agree
on
this
meeting,
any
I
guess.
A
A
Okay,
go.
D
Ahead
so
I
think
one
of
the
comments
that
I
had
was
the
original
intent
of
salsa
is
for
it
to
be
prescriptive,
and
so,
if,
if
we're
not
giving
that,
you
know
deep,
I
wouldn't
say
detailed
prescription.
But
if
we're
not,
if
we're
giving
more
detail
than
nist
as
an
example
right,
then
it
helps
people,
because
that
was
one
of
the
arguments
that
I
think
I
heard
at
the
beginning,
when
I
first
heard
of
Soul,
so
I
was
like
well.
D
This
is
just
you
know,
giving
you
guidance
of
what
you
should
do,
but
it's
not
prescriptive
enough,
and
so,
if
we
don't
give
that
level
of
detail,
then
we're
kind
of
back
to
the
state
of
where
nist
is
and
it's
not
as
helpful
or
is
not
as
how
should
I
say,
people
are
looking
for
more
guidance
unless
you
should
do
this,
but
not
tell
you
how
to
do
it.
If
that
makes
any
sense.
A
Yeah
yeah
I.
The
intention
was
not
to
move
away
from
that,
but
it
was
more
like
a
theoretical
thing
of
which
is
the
like.
The
I
don't
know
the
right
term
for
it
like
kind
of
the
axioms
or
whatever,
like
the
first
principles
in
which
follow
from
that
of.
Like
do
you
start
with
the
requirements
and
then
the
threats
that
you
address
follow
from
the
requirements.
A
Or
do
you
start
with
the
threats
that
you
must
address
and
therefore
you
must
do
these
requirements,
but
I
think
it's
just
a
very
theoretical
discussion
anyway,
and
so
it's
probably
not
worth
the
the
time,
I
agree
with
you
and
I,
don't
think
we
should
move
away
from
being.
You
know
the
level
of
prescription
that
we
currently
have.
A
Okay
sounds
good
and
I
think
the
last
remaining
item
so
I'll
move
this
one
I'll
update
the
doc.
A
Is
this
policy
verification
piece?
First,
we
need
a
better
term,
because
the
word
policy
and
verification
are
both
overloaded
and
different
people
have
different.
It
comes
to
mind,
I,
don't
know
what
term
that
is,
but
I.
So
I'll
continue
saying
policy
for
now,
but
I
propose
for
this
piece
actually
I'll
stop
presenting,
because
it's
not
useful
that.
E
What
do
we
mean
by
policy
verification
like
what?
What
is
what
is
the
the
intent?
What's
what
what's
the
meaning
of
that
policy
verification?
What
does
that
mean
exactly.
A
Yeah
the
wording
is
poor.
A
The
intent
that
I
was
trying
to
get
at
was
that
there
in
order
to
achieve
the
goals
and
like
address
the
threats
that
are
listed
simply
generating
provenance
is
not
sufficient
because,
like
you
generate
data
and
then
no
one
ever
looks
at
it
and
that's
not
stopping
anyone.
That's
not
detecting
any
attacks.
It's
not
preventing
any
taxes,
not
doing
anything.
So
some
some
systems
somewhere
has
to
actually
take
the
Providence
and
look
at
it
and
make
some
sort
of
decision,
whether
that's
blocking
an
action
or
sending
an
alert
or
doing
something
with
it.
A
E
E
What
that
means
so
so
there
are
a
few
terms
that
we're
using
in
salsa
and
I'm
just
noticing
this
across
all
the
meetings.
There
are
a
few
terms
that
aren't
Universal
terms
they
in
in
there.
These
terms
mean
different
things
in
different
places,
depending
upon
the
context
in
which
they're,
using
what
you're
talking
about
now,
for
instance,
we
talk
about
like
open
source
components,
specifically
provenance
just
means
that
you
can
trace
this
component
back
to
its
or
back
to
its
origin
period
and
you
and
it's
licensing
and
everything
else.
E
That
means
that
you
know
where
this
component
came
from.
You
know
you
know
from
its
licensing
down
to
where
it
was.
You
know,
whatever
repo
was
in.
You
can
trace
this
component
back,
that's
the
that's
the
the
definition
of
providence.
When
we
talk
about
Providence
here
for
salsa,
what
are
we
talking
about?
What?
What
specifically
does
provenance
mean
in
salsa.
A
A
We
list
specifically
the
things
that
have
to
go
in
it,
so
this
includes
things
like
so
basically
when
describing
a
software
artifact
file
or
binary
is
a
container
image.
Something
like
that,
what
system
produced
it
and
what
were
the
inputs
to
it
and
how
is
it
produced.
E
Okay,
so
so
this,
so
there's
no
difference
in
the
based
on
what
I
just
read:
there's
no
difference
in
the
definition
of
providence.
Here
when
we
talk
about
policy
verification,
then,
with
respect
to
provenance,
what
policy
so
I
now
keep
in
mind.
I'm
asking
this
question
because
I
don't
know
that
I
disagree
with
the
with
with
the
terminology
specifically,
unless
that
the
ends
don't
justify
the
means.
E
A
Yeah
so
I,
and
that's
the
reason
why
one
of
the
reasons
why
I
think
the
word
policy
is
poor,
a
poor
choice
of
words
here,
although
I'm
struggling
to
come
up
with
a
better
word,
I
think
in
order
to
address
the
threats
which
again
are
listed
here.
A
Let
me
list
send
the
link
in
the
chat
here
in
order
to
address
like
these
threats,
we
need
to
have
there's
certain
things
that
must
be
done
at
like
checks
that
have
to
happen
to
make
sure
that
those
threats
have
been
adjusted
whatever
term.
We
call
that
some
of
those
things
are
like
you.
A
Well,
well
so,
like
the
specific
things
that
I'm
expecting
are
one
like
by
policy
I
for
a
given
software
package-
and
this
was
presented
maybe
about
a
month
ago,
but
if
it's
he
had
a
proposal
here
that,
like
we
for
a
specific
software
package,
we
need
to
know
what
the
canonical
Source
location
was,
because
if
you
consider
building
a
library
or
any
sort
of
package
doesn't
matter,
let's
say
Pi
yaml
python
package,
it's
supposed
to
be
built
from
github.com.
A
If
you,
instead,
if
someone
Forks
it
and
adds
additional
code
to
it
or
just
builds
from
something
completely
entirely,
then
that's
not
built
from
the
correct
package,
and
so
we
need
to
have
some
mapping
or
canonical
information
to
know
what
the
proper
Source
location
is
for
a
given
package
like
what
to
expect
the
expected
Source
location
and
that,
like
definition,
should
be
resistant
to
tampering.
A
So
that
way,
if
someone
can
because
if
someone
has
the
permissions
to
upload
a
malicious
version
of
a
package,
they
shouldn't
also
have
the
permission
to
just
unilaterally
change
the
expected
value
or
else
otherwise
the
check
doesn't
really
have
much
meaning,
and
so
that
is
I
think
that's
like
the
most
important
bit
of
what
needs
to
be
done.
I,
don't
think
it
needs
to
be
explicitly
like
written
in
like
a
policy
format,
that's
in
whatever
language
I
think.
A
As
long
as
that
map
thing
exists,
and
it
is
checked,
that's
kind
of
what
we
want
Melba.
Also,
you
also
raised
your
hand.
Sorry
I.
D
I
was
gonna,
say
something
similar
to
what
Sebastian
said
right.
It's
it's!
It's
like
you.
You
mentioned
checks
right
so
before
you
go
ga
as
an
example
or
you
do
a
final
build.
You
have
policy
as
code
that
checks.
Do
you
have
any
critical
high?
Do
you
are
you
getting
like
Mark
said?
Are
you
getting
your
packages
from
this
this
internal
repo?
D
As
an
example,
are
you
scanning,
with
all
the
correct
scanners,
so
I
see
it
almost
like
as
policy
as
code
within
the
organization
that
one
would
have
to
check
against,
but
I
think
it's
about
the
way
Sebastian
defined
it
in
the
chat.
I
think
is,
is
a
really
good
way
of
thinking
about
it.
Foreign.
A
Yeah
I
think
there's
kind
of
two
pieces
here.
There
is
the
without
because
they're
like
the
minimal
piece,
which
is
how
do
for
a
given
package,
which
is
identified
in
some
way,
for
example,
a
particular
name
on
Pi
Pi
or
a
particular
Maven
package,
or
a
container
image
packaging
at
registry.
A
What
I
think
at
a
minimum?
You
need
to
be
able
to
point
to
some
Source
location
where
it's
supposed
to
be
any
additional
check.
That's
done
by
the
maintainers
I
think
are
at
least
I'll
speak
for
myself.
I
think
are
valuable
and
people
will
want
that
I,
don't
know
if
it's
strictly
required
to
address
the
threats
that
are
listed
in
the
salsa
thing
like
around
doing
vulnerability.
Scanning
Etc,
it
seems
like
North,
is
not
specifically
to
address
the
tampering
threat.
A
D
A
You're
saying
you
and
Sebastian
had
mentioned
that
like
having
some
policy
of
like
here's,
the
checks
I
expect
to
happen
before
a
package
is
supposed
to
be
released.
Yes,.
F
I
didn't
necessarily
mean
it
as
pre-release.
I
meant
it
as
sort
of
like
an
end-to-end
like
what
can
be
verified
by
the
final
user
of
the
package
or
what.
F
Of
stages
that
occur
right
so
I
guess
you
could
do
that
pre-build,
but
and
it's
not
really
build
I,
guess
Source
attestations!
You
could
do
before
build
so
so
yeah
I!
Guess
if
you
so,
if
you
had
a
Nintendo
style
layout
kind
of
thing,
which
is
what
I've
sense
that
you
folks
are
talking
about
with
policies,
then.
A
F
I
guess
you
could
also
verify
pre-build,
because
if
there
are
any
requirements
made
about
the
source,
so
you
can
always
verify
at
each
step.
You
know
what's
supposed
to
happen
at
the
End
by
before
that
stuff,
but
but
ultimately,
like
all
of
it
needs
to
run
I.
Think
all
of
it
needs
to
be
verifiable
by
the
the
end
user
who
receives
it.
So
so
it's
not
just
about
you,
know
Rebuilder,
maybe.
A
Yeah
I
think
this
is
the
biggest
kind
of
source
of
disagreement
where,
like
I,
never
really
disagreement,
but
lack
of
a
common
understanding
that
we
have
among
our
group,
because
I
think
we
each
kind
of
have
a
different
notion
of
how
this
works
and
what
it
does
I
suspect.
The
best
way
to
do
this
would
be
to
actually
write
something
down.
A
We
could
read
it
and
see
what
it
looks
like
and
then
kind
of
shape
that
and
then
we
could
just
kind
of
iterally
do
it,
especially
because
discussions
every
time
I,
you
know
every
time
someone
says
it,
you
kind
of
start
from
scratch
at
and
so
I
guess
maybe
for
this
group
in
order
to
start
drafting
something
one
I
guess.
One
big
question
is
like:
if
we
have
this
this
concept.
A
Question
is
this
piece
part
of
the
requirements
of
like
the
check
boxes
of
like
there's
some
difference
between
level
one
level,
two
level
three
level
four
or
is
it
like
a
kind
of
a
separate
thing,
that's
like,
in
addition
to
the
requirements,
you
also
need
to
do
that.
I
guess
like
exactly
how
we
put
it
in
the
documentation
is
open.
F
I
guess
one
way
to
think
about
it
is,
you
know,
do
you
have
if
I
think
about
it
in
our
salsa
requirements,
kind
of
way?
It's
like?
Do
you
sorry
yeah,
do
you
have
do
you
have
a
way
for
the
you
know,
for
the
end
user
or
for
whatever
tooling
they're
using
do.
A
F
Have
a
way
for
that
to
authenticate
the
provenance
and,
and
what
does
that
mean
all
right,
so
I
think
that
way
you
might
be
able
to
express
it
as
like
a
social
requirement
instead
of
just
like
a
general
guidance
thing,
but.
A
Expanding
the
Providence
of
elbow
requirement,
yeah,
something
like
that.
So
so.
The
challenge
I
guess
here
is
that,
with
the
current
version
of
salsa,
it's
defined
on
an
artifact
Basics,
meaning
like
each
a
thing.
That's
identifiable
by
hash
has
a
level.
If
you
have
two
different
versions
of
package,
I
mean
two
different
Blobs
of
data.
A
They
kind
of
different
when
we
talk
about
I'll
use
the
intuitive
term
like
the
layout
or
like
the
expectations
of
what
it
is,
that's
no
longer
about
a
specific
thing,
but
it
almost
like
a
template
of
all
future
versions
are
expected
to
meet
these
requirements.
F
I
I
don't
want
to
belabor
it
sorry,
but
you're.
F
B
F
Now,
okay,
sorry,
hopefully
I
can
retain
what
I
was
just
thinking
very
short,
I.
Suppose
you
could
you
know
you
could
issue
these
kinds
of
things
for
individual
artifacts
right.
F
So
suppose
you
know
it's
the
same
way
that
you
know
you
go
to
a
website
and
let's
shop
for
256
hashes
for
artifacts
you're
about
to
download
in
a
sense
each
one
of
them
is
a
separate.
You
know
a
separate
statement
about
what
to
expect
from
the
artifact
that
you
obtain
right.
So
you
you
could
do
that.
You
know
I.
Think
most
of
the
value
lies
in
not
doing
that
and
having
something
general
but
but
but
I
guess
you
could
have
like
an
intodo
layout
for
one
artifact.
A
I
think
the
big
question
is
like:
how
do
you
know
that
the
layout
itself
is
authentic
and
if
it's
changing
every
time,
that's
kind
of
the
big
question
is
like
if
it
if
these
things
these
layouts
or
expectations
or
policies
change?
How
do
you
know
that
the
change
is
legit?
A
One
thing
that
kind
of
thought
about
is
like
a
trust
on
first
use
model.
For
example,
if
you
get
a
particular
package
and
it's
built
from
a
particular
Source
location
from
each
particular
builder,
then
you
would
expect
future
versions
to
also
be
built
from
that
same
thing.
So
you
almost
have
like
an
implicit
layout
or
implicit
policy.
A
Then,
when
those
things
do
change,
if
it's
rare,
maybe
there's
some
way
of
identifying
safe
ones
of
like
you
could
have
like
pointers
from
the
old
location
to
the
new
location
or
something
like
that
that
or,
alternatively
just
say
like
if
you
have
to
do
a
hard
break.
That's
like
changing
your
SSH
key
and
like
people
get
prompts
and
like
just
don't
do
that
because
it's
like
a
security,
relevant
thing.
G
Isaac,
thank
you.
One
of
the
questions
I'd
have
about
this
is
I
mean.
Have
we
categorically
decided
that
this
problem
is
in
scope
for
the
social
specification
and
I
I
asked
because
I
mean
it
seems
to
me
this
is
this
is
similar
in
a
way
to
you
know
cryptography
where
you
know
there's
some
mechanisms
of
key
exchange,
but
you
know
not.
All
specifications
are
going
to
specify
how
you
do
the
key
exchange.
They
may
start
from
the
proposition
that
you
have
exchange
skills
securely.
Okay,
once
you've
done.
G
A
Yeah
I
personally
I,
don't
think
I
would
say
that
salsa
should
require
a
particular
means
of
setting
that
I,
at
least
in
my
head.
It
would
be
something
like
using
your
key
exchange
analogy
of
like
there
must.
You
know
you
must
do
a
secure
key
exchange
but,
and
maybe
recommend
like
unless
you
have
reason
to
do
otherwise
like
this
is
how
we
recommend
it
or
for
open
source.
This
is
a
particular.
A
But
I,
wouldn't
you
know,
preclude
other
implementations
that
do
it
a
different
way.
At
least
it's
me.
G
So
it
could
I
mean,
could
could
this
be
a
recommendation
that
you
know
consumers
you
know
should
do
some
validation
of
this,
and
then
we
we
leave
it
unsaid
as
to
the
mechanism
or
or
do
you
feel
strongly
that
we
need
to?
There
needs
to
be
a
recommendation
that
are
specified
around
how
that
should
is
accomplished.
F
I
think
what
happens
when
we
leave
this
to
end
users,
you
know
is
historically
demonstrated
by
you,
know:
gpg
signing
and
keys
and
Shaws
on
websites
and
stuff
and
I
know
that's
easy
to
say
it's
harder
to
solve
the
problem,
but
like
at
a
minimum.
If
you
don't
have
a
way
of
mapping
like
expected,
keys
to
artifacts
or
namespaces
of
artifacts
or
something
then
you've
sort
of
constructed.
A
system
where
you
know
the
signing
and
verification
are
a
little
bit.
Theater
fine
yeah.
G
Yeah
I
mean
I
I,
I
think
the
gpg
example
is
a
good
one.
You've
kind
of
left
the
hard
parts
to
to
everyone
else
and
gosh
I
mean
ultimately,
adoption
is
going
to
succeed
or
fail
based
on
how
people
are
able
to
accomplish
the
hard
Parts
consistently
and
well,
and
with
that
error.
B
A
So
I
suggest
that
basically
similar
to
the
previous
year,
I
think
what
might
be
useful
is
just
to
start
putting
something
together,
put
a
draft
together
and
see
what
people
think
my
inclination
is
to
start
with,
like
a
I,
don't
know
if
it's
a
different
page
or
what
but
something
that's
not
in
the
I,
don't
know,
and
whether
or
not
it's
in
a
checklist,
something
that
describes
the
overall
flow
of
like
in
the
model
of
like
not
just
through
source
and
in
a
build
and
an
output
artifact
but
like
when,
in
the
salsified
version,
there's
a
source
there's
a
build
that
produces
the
artifact
and
provenance.
A
And
then,
when
you
go
to
publish
it,
gets
checked
somehow
against
some
expectations.
Vita,
if
you
remember
Visa,
had
a
diagram
I
can't
pull
it
up
easily
and
say
that
like
to
do
salsa
you
you
do
that
and
then
the
requirements
can
kind
of
go
into
the
details
of
like
what
once
you're
in
that
frame
of
reference
into
that
model.
Here's
the
kind
of
the
check
set
that
happen.
A
Okay,
so
then
in
the
V1
document,
I
will
basically.
A
A
So
then,
finally,
the
last
thing
in
terms
of
implementation,
I,
there's
a
list
of
like
clarifications
and
resolving
like
what
specific
things
like
the
one
from
before
that
we
just
talked
about
a
minute
ago
or
half
an
hour
ago,
like
triaging.
What
issues
are
going
to
be?
A
You
know,
make
the
cut
for
1.0
and
which
ones
don't
that
we
could,
just
in
the
future,
in
terms
of
how
we
actually
do
the
1.0
implementation
I
suggested
a
doc
that
would
create,
like
a
draft
branch
that
doesn't
I
would
say
it
doesn't
even
require
code
review.
We
push
it
out,
we
iterate
on
it
and
then
we
kind
of
review
it
in
bulk.
A
Instead
of
having
folks
review
every
single
commit
for
every
single
pull
request,
we
kind
of
iterated
on
there
and
then
just
kind
of
review
the
file,
the
mostly
final
doc.
A
We
could
always
break
it
up
into
chunks,
then,
but
I
suspect,
there's
going
to
be
a
lot
of
iteration
where
the
you
know
before
we
fully
release
it.
That
it'll
be
easier
to
just
do
that
and
and
publish
that
to
some
website.
That's
not
the
official
website
but,
like
I,
said
some
draft
website
with.
A
That
it's
draft
and
unreviewed,
you
know
I
think
also
maybe
help
these
discussions
a
little
bit
better
because
then
you
know
you
could
have
like.
We
could
have
ideas
and
say,
like
oh
I
wrote
this:
what
does
this.
A
Okay,
Melba
and
Company,
hybrid
OSS
and
proprietary
scenario.
D
Yeah
I
am
going
to
share
this.
D
D
So
after
you
know
much
discussion,
this
is
kind
of
what
it
came
out
to
based
off
of
two
different
scenarios.
Obviously
we
would
like
input,
but
not
certain
if
this
is
what
was
what
you
were
looking
for
in
terms
of
how
the
hybrid
approach
would
potentially
be
tackled,
slash
visualized,.
D
Additionally.
You
know
during
the
build
process,
depending
on
which
scenario
it
is
right.
There's
the
internal
repo
that
has
proprietary
software
along
with
you
know
any
open
source
dependencies
and
again
depending
on.
If
it's
an
area,
one
or
scenario,
two,
it
would
go
and
copy
that
open
source
code,
whether
it
be
directly
to
the
internet
or
via
the
internal
mirror,
and
then
obviously
complete
the
build.
So
this
is
just
kind
of
a
high
level.
D
D
B
Yeah
I
think,
hopefully
you
can
hear
me
I.
Think
one
of
the
next
steps
I
mean
I,
I
kind
of
gotten
a
chance
to
look
at
this
cleaned
up
version,
but
I
think
it
makes
a
lot
of
sense
when
you
captured
our
discussion
very
well.
B
But
what
I've
been
trying
to
think
about
as
well
is
how
do
we
translate
this
back
into
salsa,
Providence
requirements
right
and
yeah?
How
do
we
essentially
capture
this
in
the
provenance
yeah
that
that's
kind
of
what
I've
been
thinking
about
and
I?
Think
that
should
be
the
goal.
D
B
B
B
I
think
it's
honestly,
both
you
know,
on
the
one
hand,
from
the
sort
of
Enterprise
proprietary
perspective.
What
can
we
learn
about
the
provenance
of
Open
Source
Code?
We
are
consuming
and
also
once
we
publish
that
what
does
this
hybrid
sort
of
provenance
look
like
to
the
downstream
consumers
of
this
hybrid
code,
I
yeah
I
think
it's
both
personally.
A
Yeah
I
I
guess
I
could
just
give
you
money.
Personal
thoughts.
A
I
had
been
thinking
of
these
as
kind
of
two
somewhat
separable
problems
where
the,
if
we
think
of
salsa
as
like
a
an
individual
like
Adam,
that
we
have
to
like
use
to
assemble
some
larger
secure
system
with
the
consumption
like
the
ingestion
of
Open
Source,
there
we're
using
salsa
to
make
sure
that
the
input
software
hasn't
been
tampered
with
and
if
you're
importing
from
source,
then
I'm,
not
I,
guess
there's
one
question
like
especially
if
we
remove
the
source
requirements
like
is
this
also
even
apply
or
just
it
was
I
think
the
build
requirements
are
kind
of
trivially
met
because
it's
all
the
code
isn't
built
right,
like
you're,
just
import
doing
get,
for
example,
and
it's
you
know,
has
the
same
hash,
so
you
know
it
hasn't
been
tampered
with.
A
Maybe
there's
something
about
like
what
the
Upstream
repo
is
because,
like
once
it
comes
in
your
doors.
Now
it's
like
an
internal
problem
as
opposed
to
external
for
publishing
of
closed
Source
software
kind
of
like
on
the
outside
I
I.
Think
that's
an
open
question.
Like
then,
an
organization
could
use
it
on
like
the
insertal
side
of
like
you
know,
come
my
company
doesn't
want
months
to
make
sure
that
no
internal
users
have
the
ability
to
like
publish,
tamper
with
and
publish
any
stuff
that
we
give
to
our
users.
A
But
that's
like
a
purely
internal
thing,
but
for
consumers
I,
don't
know
if
there's
a
way
for
them
to
know
like
how
did
we
build
our
closed
Source
software
according
to
our
own
internal
stuff,
that
they
can't
look
at
I?
Don't
know
it
enumerating
what
all
the
open
source
things
were
in.
A
Yeah
or
maybe
another
way
of
like
to
say
like
if
you
have
a
closed
Source
build,
meaning
that,
like
the
consumers
of
the
software,
that
you're
building
can't
look
at
the
build
service
or
or
all
of
the
inputs,
then
instead
of
outputting,
like
the
salsa
Province
directly
you'd,
probably
output,
an
s-bomb
which
is
like
some
sort
of
aggregate
attestation,
which
is
like
an
s-bomb
or
the
VSA.
The
verification
summary
at
the
station
saying
like
we
did
do
salsa.
D
Okay,
I
know
we're
over
our
our
at
the
top
of
the
hour.
A
Okay
sounds
good,
so
I
guess
we'll
see
everyone
at
the
next
next
meeting
thanks
everyone.