►
From YouTube: SLSA Specifications Meeting (July 10, 2023)
A
A
B
C
C
C
A
I
think
we've
come
to
a
consensus
that
we
should
do
a
version
bump,
because,
even
though
the
the
specification
texts
arguably
haven't
changed,
but
we
are
informing
the
reader
then
assumption
that
they
may
have
made
may
need
to
be
reevaluated
right.
So
I
think
there's
a
strong
reason
to
have
a
1.1
release
and
I
wanted
to
bring
that
to
the
group
and
discuss
whether
there
are
other
things
we
should
include.
I
would
advocate
for
doing
the
release
relatively.
A
C
A
My
comment
was
great
clarification
because
I
couldn't
find
I
seem
to
remember
us
talking
about
Folsom
for
versioning
in
the
past
and
deciding
that
patch
releases
didn't
make
sense,
because
we
were
going
to
not
want
to
do
that
for
every
clarification
to
the
spec,
and
we
only
wanted
to
bump
version
when
we
were
making
like
a
a
feature
change
for
one
of
the
best,
because
that's
the
center,
the
center
terminology
and
I
kind
of
personally
went
back
and
forth
on.
Was
this
a
feature?
A
Change
or
not,
and
I
fell
on
the
my
position.
I
kind
of
concluded
was
that
because
this
may
cause
a
reader
to
reinterpret
things,
that
we
should
signal
that
somehow
and
the
version
numbers
the
best
way
we
have
to
sign
up,
but
I
yeah,
I
I
was
thinking
minor
rather
than
patch,
because
I
thought
we'd
ruled
out
patches.
C
Have
I
guess
we're
taking
that
the
commit
convention
for
like
we
classify,
commit
or
pull
requests
is
either
like
content
or
editorial
or
blah
blah
blah.
Anything
with
a
Content
which
is
like
the
most
highest
Priority
One
would
require
a
release
notes
and
if
we
have
any
such
changes,
where
we
change
to
something
after
release,
if
we're
already
doing
that,
would
it
be
worthwhile
just
calling
it
a
patch
release
in
the
in
the
notes.
B
E
F
C
A
I
think
that's
I'm,
yeah
I
think
it
is
somewhere
related,
and
maybe
we
need
to
capture
this
discussion
in
our
conventional
commits
related
documentation,
but
I
had
assumed
that
spec
content
would
mean
a
minor
or
major
version.
Number
increment
would
be
required
and
the
spec
editorial
were
effectively
patch
releases
and
that
we
had
kind
of
agreed
in
the
past
not
to
make
practical
uses.
But
yeah
I
can
see
an
argument
for
wanting
to
be
able
to
check
ones
outside
sanity.
Did
I
am
I
misremembering?
A
D
F
C
C
D
G
Sorry
I'm
trying
to
take
this
my
car,
so
I
apologize
for
the
noise
I
feel
like
if
there's
any
spec
changes,
whether
it's
content
or
editorial.
It
warrants
a
change,
log
release
notes,
but
I
would
say
that
for
editorial
it
you
it
wouldn't
it
shouldn't
require
a
version
change
because
there's
nothing,
that's
actually
changing.
G
So
not
until
there's
content
should
a
version
like
a
the
minor
version,
at
least
be
bumped,
but
make
sure
that
if
there's
any
changes
to
the
specification
pages
that
that
change
is
made
aware,
so
that
it
can
be
tracked
in
order
to
help
that
discovery
of
oh
that
there
might
be
Clarity
in
this
play,
displacement.
Clarity.
G
Get
logs
might
be
helpful,
but
I
I
think
that
some
way
of
being
able
to
surface
it
through
salsa.dev
would
be
beneficial
and
the
release,
notes
or
a
changelog
would
be
would
be
helpful.
So
if,
if
you
had
a
editorial
change
that
is
introduced,
you
can
put
it
on
there,
but
not
tied
to
a
version
and
then
once
there's
a
minor
version
bump,
then
it
can
be
associated
with
a
version,
but
until
there's
that
minor
version
bump
it
would
be
associated
with
whatever
latest
is.
C
What
we
consider
editorial
about
is
kind
of
a
blurry
line,
and
so,
if
you
go
to
read
something
it's
like,
oh,
it
doesn't
read
like
I.
Have
it's
the
first?
If,
if
it's
clearer
to
readers
that
they
can
look
into
the
change
log
and
see
changes
that
might
make
it
easier
and
I
don't
we
could
talk
about
exactly
how
best
to
represent
that,
but
I
do
think
something
that's
on
the
website,
either
on
a
single
page
or
like
the
bottom
of
each
page.
C
C
A
I
think
it's
a
cleaner
kind
of
separation
of
Duty,
so
to
speak
with
the
git
Hub
project
and
get
being
the
you
know,
the
implementation
piece
that
we
focus
on.
But
then,
if
users
see
a
change
logo
on
the
website,
that
kind
of
matches
that
being
the
user
presentation,
layer
and
sure
it
might
bounce
them
through
to
get
hope
to
see
the
diff
if
they
want
to
see
exactly
what
changed.
But
it
feels
like
a
clearer
boundary
between
the
tool
and
the
output.
This
way.
C
So
so
to
clarify
I
think
what
we're
saying
is:
if,
if
I
don't
know,
if
anyone
has
read
the
conventional
commits
can
thing,
but
the
standard
terms
are
I,
think
feet
short
for
a
feature
and
anything
that
that
is
like
a
minor
release.
I
think
is
that
true,
and
then
they
also
have
bug
which
I
think
in
our
case
would
be
editorial.
C
I,
think
it
kind
of
maps
somewhat
well
to
editorial,
and
then
you
could
have
other
stuff
and
there's
like
conventional
commits
talks
about
kind
of
auto-generating
things,
but
and
something
kind
of
oh
there's
like
you
know
like
this-
is
just
a
doc.
It's
not
like
hard-coded,
but
I
think
we
could
have
something
like
you
know.
Every
editorial
and
above
gets
a
change
log
entry
and
everything
which
is
equivalent
to
maybe
a
patch
release
and
everything.
That's
content
or
above
requires
a
minor
release
and
we'll
have
to
figure.
D
C
H
A
H
A
A
lot
of
the
desire
for
having
that
two-week
period
initially
is
because
1.0
was
quite
a
significant
change
from
the
initial
release
where
a
lot
of
attention
had
been
on
the
project.
You
know
people
were
still
talking
about
some
of
the
requirements
from
0.1,
even
after
we
had
removed
them
from
the
kind
of
draft
releases
of
1.0.
A
C
A
C
C
How
big
should
they
be
and
how
frequent
should
they
be?
So
the
things
that
we've
we're
talking
about
to
possibly
include
in
a
release
like
this
one
is
like
just
clarifying
was
it
which
is
authoritative?
It's
not
really
a
major
change.
The
VSA
one
is
changing
some
required
fields
to
optional,
but
it's
not
a
major
change.
C
I,
don't
know
if
there
were
other
ones
and
ultimately,
with
the
version
numbers
we're
just
we're
using
this
as
a
communication
mechanism
right,
because
we
want
there's
kind
of
a
balance.
Any
thoughts
on
that
like
is
it
better
to
just
not
do
the
minor
release
to
not
have
noise,
or
is
it
better
to
do
more
minor
releases
to
have
a
clear
kind
of
protocol
for
when,
when
things
breaking
changes
happen.
A
So
I
can
jump
in
and
just
yeah
reiterate
that
I
think
it's
better
to
have
the
communication
mechanism
and
semantic
versioning
convention
is,
if
the,
if
there's
not
a
breaking
like
if
you're
introducing
new
functionality,
but
it's
in
a
Backward
Compatible
way.
That's
when
you
get
the
minor
version
number
increment,
and
that
feels
like
what
we're
doing
certainly
With
The
Changes
we've
discussed
here
and
because
they
are
not
backwards
incompatible.
If
someone
has
implemented
salsa
one
and
we've
then
pushed
salsa
1.1
and
they
choose
not
to
implement
it.
C
C
F
I'm
also
in
favor
of
of
doing
the
minor
release
relatively
soon
I
think
the
question
is:
is
there
anything
coming
up
that
we
would
want
to
batch
into
it
and
does
it
make
sense
to
say
we
won't
do
minor
releases
more
than
like
I,
don't
know
once
a
month
months,
a
quarter
that
sort
of
thing,
because
you,
you
I
wonder
if
having
minor
versions
having
minor
versions
doesn't
create
noise
having
them
unexpectedly
creates
noise.
Perhaps.
A
Yeah
I
think
trying
to
batch
them
up
so
that
we're
already
making
them
periodically
does
make
a
lot
of
sense
and
I.
Think
even
quarterly
would
be.
You
know,
kind
of
sufficient,
like
none
of
the
changes
that
we're
making
right
now
are
shattering
they're,
just
nice
for
the
most
part,
they're
nice
to
have
so
saying
we'll
we'll
do
that
a
quarter
after
or
we'll
do
that
within
the
quarter
after
the
initial
one
that
they're
releasing,
then
we'll
not
make
another
similar
release
for
another
quarter.
C
C
In
terms
of
feel
free
to
steal
the
discussion,
if
your
wife,
you
want
to
talk
about
something
else
when
satyanu
is,
is
on
leave,
Tiana
is
the
one
who
wrote
the
did
you
link
to
it
from
here
the
branch
strategy
thing
originally
in
this
meeting
we
had
talked
about
like
developing
on
a
branch
and
then
building
that
into
a
website.
Tianu
looked
into
it
kind
of
looked
at.
He
did
the
proposal
and.
C
C
And
then
there
was
concerns
about
like
complexity
there,
and
so,
where
we
landed
was
we'll
just
build
on
Main
I'm.
Sorry,
we
just
contribute
on
Main
diversion
directories
like
we
have
now,
and
then
you
could
kind
of
use
some
sort
of
get
something
rather
subtree
or
something
like
that
to
to
build
like
the
actual
kind
of
infer
the
real
history
from
the
merge
thing,
which
is
kind
of
weird.
C
A
When
I
skimmed
The
Proposal
early
while
I
was
thinking
about
this,
it
talked
about
having
a
branch
for
a
release.
So
I
could
see
you
know
having
I,
don't
know
if
it
makes
sense
to
put
we,
we
could
choose
a
granularity
at
which
to
published
versions
of
respect
and
have
a
branch
track
of
that
version.
Corinularity
and
so
I
think
you
could
decide
that's
an
option.
A
A
G
B
G
C
C
A
E
C
C
Or
the
one
that
you
just
sent
there,
the
892.,
you
naturally
would
do
it
for
the
current
thing.
We
decide.
Oh
no.
This
requires
a
minor
version
bump
and
then
what
do
you
do?
Then?
We
don't
have
a
one
point.
Well,
two
things:
one:
we
don't
have
a
1.1
directory
yet
and
two
we
don't
have
and-
and
it's
not
proposed
to
have
like
a
latest
thing
and
so
in
order
to
see
that
new
version
there's
nowhere
to
view
it
which
we
could
do,
but
we
need
to
change.
G
G
The
burden
would
be
on
the
maintainers
to
ensure
that
we
have
appropriate
updates
of
the
versions,
and
so
you
would
have
I
think
that,
even
if
you
have
a
branch
per
major
version,
then
once
you
get
to
your
quarterly
minor
or
your
monthly
minor
version,
just
cherish
pick
everything
over
and
update
that
the
the
branch
tracking
that
main
are
tracking.
That
main
version.
H
Okay,
maybe
what
we
can
I,
don't
know
if
it
was
discussed
before,
but
I
think
so
using
main
for
contribution,
knowing
that
most
contributions
are
not
on
the
websites
or
stuff
related
to
the
web,
but
on
the
spec
contents.
So
we
keep
the
spec
there
and
I
have
a
special
Branch
for
the
for
the
website.
There
is
only
one
website
that
will
list
the
stuff.
We
want
to
publish
the
branch
we
want
to
publish.
C
H
H
C
B
It
I
would
say
for
Simplicity,
unless
you're
planning
on
going
back
and
applying
Hot
patches
to
previously
released
branches
out
there,
then
I
wouldn't
do
a
branch
per
release.
I
would
just
do
a
tag
and
then
the
next
time
we
need
to
do
another
release.
We're
just
doing
a
tag
with
the
next
current
version.
C
Yeah
back
porting
actually
is
my
I
guess
implicitly
my
my
concern
that
like,
if
we
have
an
editorial
change,
we've
I
think
probably
want
that
to
go
well.
I
guess
we
could
make
a
decision
like
do.
We
just
leave
the
text
as
is,
and
do
quarter
releases
and
just
batch
all
the
changes
until
next
quarter,
release
I
think
if
we
do
that
it
becomes
simple.
We
just
have
a
thing.
We
use
tags,
Auto,
build
it,
it's
straightforward.
C
So
thanks
for
calling
this
out,
I
was
assuming
possibly
incorrectly
that
we
would
want
to
have
some
changes.
Go,
live
right
away
and
some
hold
until
the
next
release.
So,
like
anything,
editorial
and
Below
style
changes
Etc.
We
want
them
to
go
out
right
away,
but
then
anything
with
the
content
tag
which
would
require
patch
release.
A
I
I
just
wanted
to
say
that
my
my
assumption
matched
yours,
which
is
that
we
would
have
some
changes.
Just
go
live
straight
away
because
they
didn't
really
impact
the
implementation
effectively
and
that
it
would
only
be
content.
Changes
I
think
it's
the
right
tag
that
would
be
batched
I'm,
trying
to
think
whether
having
a
branch
per
major
version
would
and
then,
like
tagging.
The
minor
version
releases
would
help
be
a
compromise
between
having
too
many
directories
and
being
really
messy
or
not
and
I'm,
not
sure,
honestly.
So.
C
D
E
A
Thanks
for
doing
that,
I
I
want
to
I
feel,
like
we've,
probably
hit
the
ecological
conclusion
of
that
description.
Unless
anyone
else
has
strong
opinions,
it
feels
like
we
are
agreeing
that
we
want
to
make
a
minor
release
a
batch
minor
release
soon
for
a
1.1
for
the
changes
that
are
in
flight
now
and
that
we
recognize
that
we
probably
need
to
rethink
proposal
six
as
a
consequence
of
this
idea
of
batching
minor
releases
once
per
quarter
or
so.
F
Let's
try
that
sorry,
we
we've
got
quite
a
few
this
time.
So,
let's
start
with
891
that's
discussion
on
verifying
package
names,
so
there's
been
a
lot
of
discussion
on
this
issue
already,
but
I.
Think
a
rough
summary
is
that
they're,
due
to
a
quirk
in
the
way
that
npm
handles
package
names,
it's
it's
possible
to
install
a
package
and
verify
its
provenance,
but
get
the
have
the
package
installed
under
a
different
name
than
you
expect.
I
know,
Mark
you've
been
active
on
this.
You
should
does
that
sound
like
a
fair
summary.
A
C
Yeah
yeah
there's
basically
when
in
npm
and
maybe
other
ecosystems,
the
name
is
there's
two
different
look.
The
name
is
in
two
places:
one
is
the
artifact
itself
contains
its
own
name
and
the
tooling
that
does
the
package.
Installation
gets
a
name
from
some
external
Source,
like
the
user
running
npm,
install
blah
and
some
things
like
npm,
don't
actually
make
sure
that
they
both
match
and
if
they
don't
match.
C
If
it
doesn't
give
an
error,
one
will
win,
and
so
the
question
is
for
the
salsa
verifier
tool,
which
name
should
it
be?
Checking
against
my
feeling
is
that
well
I,
guess
there's
the
the
question
about
what
should
the
specification,
Say
and
What
should
the
salsa
verifier
tool
actually
do,
because
that's
just
one
implementation.
C
My
my
feeling
is
that
this
well
I
mean
because
this
comes
up
like
we
should
the
spec.
It
would
be
good
to
have
this
clear
in
the
spec
of
like
that.
This
is
a
thing
I
wonder
if
maybe
it
makes
sense
to
almost
have
like
a
like
an
annotated
rulings
or
something
like
that,
where
you
kind
of
talk
about
cases
that
come
up
that
are
not
necessarily
like
you
don't
need
to
know
for
the
spec
but
or
it's
almost
like
a
free
class
questions
kind
of
thing.
C
My
feeling
here
is
that
there
exists
one
name
for
real.
Like
the
packet
like
when
you
go
to
install
a
package,
one
is
going
to
win,
and
that
is
what
you
should
compare
against
and
if
there's
any
sort
of
discrepancy,
that's
kind
of
a
tooling
problem,
but
I
guess.
Maybe
it
would
be
useful
for
the
spec
to
be
to
note
that
such
a
thing
can
can
come
up
if
that
makes
sense.
So,
for
example,
the
salsa
verifier
tooling
Ian
said
down
below
like
when
you
go
to
invoke
it
on
a
package.
C
All
you
have
is
a
tarball,
so
you
don't
know
the
other
name
like
you,
don't
know
what
someone
typed
on
the
command
line,
and
my
feeling
is
that
is
a
tooling
problem,
because
it
ought
to
be
integrated
into
the
npm
dueling
and
so
that's
kind
of
an
implementation
Gap,
as
opposed
to
like
some
fundamental,
like
salsa
spec
thing,
so
I
I,
wouldn't
that's
anyway.
How
my
feeling
is,
but
do
other
folks
have
thoughts.
G
My
thought
on
the
matter
was
that
one
of
the
expectations
that
I
think
users
would
have
is
that
there's
one
name
for
the
package
and
so
to
me
it
makes
sense
that,
if
we're
it,
it
makes
sense
to
in
the
the
salsa
verifier
to
also
verify
that
that
expectation
that
there's
one
package
name.
That
makes
sense.
G
D
G
That's
downloaded,
and
so
if
the
Providence
like
I
I,
feel
like
if,
if
the
Providence
is
installing
some
kind
of
artifact
or
if
the
Providence
is
indicating
the
the
instant
installation
of
the
dependency
of
some
kind
of
artifact,
that
has
a
potential
for
a
name
mismatch.
Then
this
seems
like
a
reasonable
expectation
for
the
salsa
verifier
to
enforce
that
expectation.
Just
so
that
anybody
else
who
depends
on
it
would
be
aware
of
the
violation
of
or
the
confirmation
of
that
expectation.
A
E
Well,
thanks
no
I
wanted
to
also
mention
something
else
which
is
like
the
pub
so
I
think
the
publish
at
this
station
is
not
yet
part
of
salsa,
which
I
think
complicates
a
little
bit.
The
discussion
because,
like
today,
we
have
salsa
provenance,
but
we
don't
talk
about
publish
at
this
station
and
in
the
package.
E
There's,
if
you
trust
the
registry,
do
you
can
you
just
verify
the
publish
attestation
and
not
verify
what's
inside
the
the
double
versus,
if
you're,
trying
to
verify
the
same
way
that
the
registry
should
verify?
For
example,
if
you
have
a
network
of
other
entities
that
are
trying
to
keep
the
registry
honest
and
do
the
same
verification
that
in
that
case,
it
clearly
makes
sense
to
like
to
verify
consistency
in
the
turbo
versus.
What's
in
the
what
what
the
published
attestation
is
claiming.
E
So
I
wonder
whether
that
makes
a
difference
or
not
in
practice,
even
though
I
kind
of
agree
that
if
we
like,
if
we
want
verification
to
work
for
everyone,
even
even
before
the
registry,
fixes
the
problem,
we
might
also
want
to
to
verify
it
in
all
the
the
two.
In
the
two
cases
that
I'm
mentioning
I'm,
not
I'm,
not
sure.
If
that
makes
clear
what
I'm
saying
I
see,
Mark
and
Chris
have
there
their
hands
raised.
C
You
are
calling
something
bash
and
you're
it's
giving
the
name.
You
know
user
bin
bash
and
that,
and
you
know
to
know
some
sort
of
privilege,
and
so
that
is
the
thing
that
you
should
be
comparing
against
expectations.
They're
like
what
do
I
expect
bash
to
be
under
the
hood.
If,
if
there
are
like
publish,
attestations
or
or
like
whether
or
not
you
trust,
the
registry
seems
like.
F
F
G
G
But
what?
What
so
from
a
build
platform?
I
think
that
the
build
platform
itself
is
capable
of
understanding
the
provenance
that
it
generates.
But
then
what
Ian
commented
on
it
is
it
part
of
the
issue
during
salsa.
Verification
is
that
they
have
the
Char
ball
and
not
a
package
name.
So
it
seems
like
that.
The
issue
is
on
the
verification
side.
They
don't
have
the
metadata,
that's
in
the
npm
registry
and
and
so
if
the
build
platform
uses
that
metadata.
G
That's
in
the
npm
registry,
the
whether
that's
the
publication,
attestation
or
or
whatnot,
there's
still
the
the
possibility
that
there's
going
to
be
a
mismatch,
because
maybe
the
the
build
platform
uses
that
metadata
of
which
the
verification
doesn't
use
and
so
you're
going
to
have
you're
not
going
to
be
able
to
to
verify
the
provenance.
That's
generated.
C
Maybe
what
would
make
sense
for
the
spec
is
to
say
more
explicitly
that
you
can't
well
I'm
gonna,
say
something
controversial,
I'm,
not
sure.
If
everyone
here
will
agree,
you
can't
verify
an
artifact
which
is
just
a
file
or
blob
of
data.
You
can
you
have
to
verify
an
artifact,
comma
resource
or
URI,
or
some
package
package
name
I.
C
Like
npm
packages
happen
to
have
the
name
and
tooling
might
be
able
to
kind
of
Auto
do
it,
so
you
don't
have
to
pass
in
both
explicitly,
but
it
sounds
like
that
is
the
case
here
that,
like
the
it's
with
the
automatic
thing,
and
sometimes
the
automatic
thing
doesn't
work,
I'd
be
interesting.
Thoughts
on
that,
but
Laura
also
had
his
hand
up
as
well.
E
Wait
I
wanted
to
reply
to
what
Chris
said
about
like
he
said.
The
registry
has
nothing
to
do
with.
If
you
have
a
local
double
I
guess.
Maybe
we
didn't
explain
the
issue
well,
but
when
you
install
you
can
download
the
toggle
from
the
registry,
so
the
Registries
is
involved,
so
you
can
download
the
toggle
and
then
you
can
download
the
attestations
which
include
the
provenance
and
the
publish
attestation,
and
so
the
registry
is
involved.
It
has
a
policy
that
says
that
the
registry
accepted
that
table
and
its
maps
to
that
package.
E
F
C
A
Lauren,
did
you
have
your
hand
on
first,
or
is
that
remaining
so
I
I
think
I
think
what
you
described
Mark
makes
sense,
because
we
have
documentation
on
this
within
Celsius.
Already
that
says,
like
you,
don't
just
verify
in
artifacts,
you
verify
an
aspect
with
this
provenance
against
a
set
of
expectations,
so
I
think
we
we're
narrowing
in
on
being
able
to
describe
some
more
about
what
it
or
some
of
the
like
expectations
that
must
be
set
up
and
I.
A
A
I
guess
just
filling
a
bit
of
the
silence
we
have
the
the
terminology.
Page
has
a
verification,
model,
description
and
diagram,
as
well
as
the
verifying
artifacts
page.
So
it
feels
like
we
could
add
something
or
make
sure
that
we're
not
when
we
add
something
to
address
this,
we
should
make
sure
it's
reflected
in
both
those
places.