►
From YouTube: SLSA Specifications Meeting (January 9, 2023)
Description
Meeting notes: https://docs.google.com/document/d/1kMP62o3KI0IqjPRSNtUqADodBqpEL_wlL1PEOsl6u20/edit#heading=h.yfiy9b23vayj
C
C
Yeah
I
created
the
new
ones.
This
morning,
apparently
I
have
bright
access
to
open
ssf
community
calendar,
so
I
I
took
it
upon
myself
to
create
the
specification
meetings
for
the
rest
of
the
year.
So
hoping
everybody
can
see
that.
E
E
Yeah,
what
what
one
thing
to
look
out
for,
because
this
happened
with
the
cooling
meeting,
is
check
to
see
if
the
specification
notes
actually
allow
updates.
We
had
an
issue
where
the
Google
Doc
got
locked.
A
E
A
A
Why
don't
we
just
get
started
because
usually
most
most
folks
show
up
pretty
much
on
time?
I
think
Melba
had
the
first
topic.
C
I
do
so.
This
is
something
that
it
was
I,
think
the
last
supply
chain,
Integrity
working
group
meeting
and
the
last
salsa
meeting
of
the
year
that
I
brought
up
and
I
think
for
the
folks
that
were
on
those
meetings.
They
had
agreement
about
it
and
so
I
wanted
to
make
sure
that
all
the
salsa
sigs
were
also
included
in
this
conversation.
C
Essentially,
what
I've
noticed
in
2022
is
that
there's
a
lot
of
work
being
done,
good
work
being
done,
but
not
everybody's
talking
to
each
other
and
not
everybody's,
going
towards
the
same
vision
and
so
I
recommended
for
the
supply
chain,
Integrity
working
group
to
create
that
vision
for
2023,
so
that
Salsa
Fresca,
s2c2f,
they're
all
working
towards
a
common
goal,
and
so
in
the
next
supply
chain.
Integrity
working
group
meeting
I'll
bring
it
up
again.
I
know
Isaac
already
started
doing
a
draft
on
what
the
charter
is
for
supply
chain
Integrity.
C
What
are
we
actually
driving
towards
and
then
that
will
set
the
priorities
and
then,
once
that
happens,
and
obviously
us
at
Salsa,
we
have
to
figure
out
and
the
cigs.
How
do
we
communicate
better
communicate?
What
we
were
seeing
in
the
positioning
working
group
is,
we
would
be
writing
a
developer
blog
on
this
also
one
spec
and
then
we're
almost
done,
and
then
we
find
out
that
something
was
changed
fundamentally
changed
in
the
middle
of
that
and
now
we
have
to
go
back
and
change
it.
C
So
we
I
would
like
tighter
alignment
between
at
least
a
Sig
leads
and
having
making
sure
that
we
have
representation
across
each
of
the
meetings.
So,
for
example,
I
joined
this
meeting
a
lot
of
times,
but
if
I
can't
I
should
probably
get
Bruno
or
somebody
else
that
regularly
joins
the
positioning
group
to
join
this
meeting
the
same
as
tooling
or
you
know,
tooling,
and
and
spec
join
the
positioning.
C
So
that
way
we
know
what
we're
working
towards
outside
of
that,
we
could
potentially
use
the
a
Sig
lead
meeting
as
an
example
just
to
say:
okay,
this
is
what
we're
doing,
but
I
think
we
could
get
a
lot
more
done
and
and
have
more
alignment
if
we
work
this
way.
E
So
so
one
thing
so
yeah
I,
largely
agree.
I
I
do
think
that
we
just
need
to
figure
out
how
to
make
sure
that
we
do
it
efficiently.
I
think
folks
are
going
to
say
hey
if
we
have,
if
we,
if
we
start
to,
have
more
and
more
meetings,
it's
gonna,
especially
given
that
I
go
at
least
from
the
intent,
the
salsa
community
meeting,
the
first
you
know
whatever
it
is
15
minutes
of
it
is
supposed
to
be
around
like
essentially
ensuring
that
that
stuff
is
aligned.
E
But
I
I
do
think
that
there's
ways
we
can
do
that.
Also
one
thing
to
probably
I
want
to
make
sure
that
that
we
do
also
it's
something
that
folks
are
aware
of
is
is
just
also
the
2023
Tack
and
governing
board
alignment
for
the
open.
That's
a
staff
in
general,
because
we
want.
E
C
C
Positioning
meeting
oh
and
I
was
thinking
about
doing
a
a
repo
for
the
positioning
meeting,
so
I
don't
mind
starting
that
right
now
it
is
late.
I
think
that's
what
what
was
voted
on,
but
the
audience
has
changed
or
the
participants
have
changed.
So
we
can
revisit
that
that
meeting
and
when
it
happens.
C
A
There
because
I
know
there's
periodically
talk
about
merging
that
with
the
the
supply
chain,
Integrity
positioning,
any
update
on
that.
C
No
I
suspect
we'll
probably
talk
about
that
in
the
next
meeting,
when
we
talk
about
Charters
and
priorities
and
how
the
three
align,
but
nothing
as
of
yet
yeah
I
I
will
say
that
in
the
last
meeting,
in
line
with
the
you
know,
trying
to
be
one
as
a
positioning
group,
we're
trying
to
create
topics
for
salsa
or
open
SS,
Opus,
sorry,
open
source,
Summit,
North
America
for
us
as
Sig
leads
or
major
participants
to
talk
about
salsa.
C
We
have
one
for
salsa
level,
one
draft
or
level
one
if
it
gets
published
and
there's
some
other
ones
that
we
took
note
of
to
say,
okay,
you
know
Mark
and
Josh
could
talk
about
this
right
and
in
terms
of
like
tooling,
you
know
Mike
Lieberman,
and
somebody
else
could
talk
about
this,
so
we're
even
trying
to
get
a
sense
of
okay
for
conferences.
As
a
salsa
group,
we
can
talk
about
these
different
topics.
We
can
submit
it
under.
You
know
one
person
but
submit
it
as
a
salsa
specification
group
or
salsa
positioning
group.
E
Yeah
something
to
think
about
there
and
I,
don't
know
exactly
if
open
source
Summit
is
gonna.
Do
this
because
I
know
as
it's
growing,
it
probably
will
start
to
like
at
least
for
the
open
ssf
related
stuff
like
they
might
do
something
that's
similar
to
what
we
do
in
the
cncf
where
the
cncf
has
maintainer
like
they
have
stuff.
E
That's
you
know
times
and
stuff
associated
with
projects
that
are
underneath
that
org,
so
you
can
imagine
it
for
the
in
line
with
with
what
the
open
ssf
might
have,
just
generally
for
in
their
own
schedule,
like
they'll,
be
allowed
at
a
certain
amount
of
time,
whether
it's
part
of
the
co-located
event
or
or
whatever,
and
so
that
might
just
be
something
that
you
know
you
don't
necessarily
need
to
submit
directly
and
get
sort
of
approved
to
be
clear.
E
I
think
that
it's
still
obviously
worthwhile
to
to
push
folks
to
submit
talks
about
salsa
and
related
to
salsa,
but
it's
probably
also
worthwhile
to
make
sure
that,
from
the
open,
ssf
side
and
just
the
LF
in
general
that
we
have
the
ability
to
say,
hey
look,
we
want
you
know
as
an
official,
you
know
officially
saying
this
is
Salsa's
stance
on
a
thing.
It's
also
want.
This
also
group
wants
to
give
a
talk
about
the
state
positioning,
about
the
state
of
tooling
and
so
on.
F
C
A
Let
let
me
know
if
you
need
anything
from
me
or
from
anyone
else,
I
think
I.
Think
the
assumption
is
that
we'll
wait
to
hear
from
you
or
others
but
yeah
just
let
us
know.
A
Okay,
so
the
second
topic
I
want
to
talk
about
the
1.0
release,
schedule
which
we're
like
six
months
behind.
We
wanted
to
release
it
back
last
year
in
the
middle
of
last
year.
It's
now
the
beginning
of
2023.
A
A
1.0
release,
like
sooner
rather
than
later
so
I
think
we're
at
the
point
where
we've
kind
of
agreed
on
the
basic
concepts
we're
close
to
having
all
the
core
content
there.
A
It
just
needs
some
well
there's,
there's
a
couple
major
gaps
mentioned
which
which
I'll
talk
about
in
a
second
but
then
otherwise
the
main
concepts
are
there
and
we
could
start
getting
review
on
those
and
agreement
on
those
and
then
we
could
start
from
there
move
towards
more
editorial
changes
of
making
sure
it's
clear
and
we've
covered
all
the
edge
cases
Etc.
A
A
A
We
probably
need
to
have
the
three
major
missing
pieces
merged
like
we've,
have
an
initial
review
and
merge
by
the
end
of
this
week
and
I
think
there's
three
missing
major
missing
pieces
or
one
is
the
provenance
spec
which
there's
an
open
pull
request
out
for
originally
we
talked
about
splitting
it
out,
but
in
the
current
design
we
effectively
delegate
from
the
spec
to
the
province
on
the
requirements
instead
of
duplicating
content.
A
Any
other
is
artifact
verification
and
system,
verification,
Joshua
and
Chris
respectively.
Have
volunteered
to
author.
The
initial
draft
and
I
know:
there's
been
some
some
amount
of
work
there
and
then
I
think
I.
Think
all
of
this
is
optimistic,
but
if
we
are
able
to
get
those
pull
requests
have
an
initial
review
and
merge
this
week.
A
We
then
have
the
kind
of
the
core
content
there
and
well
maybe
there's
like
two
there's
that
accounting
to
do's
and
things
like
that,
then
we
could
spend
the
rest
of
the
month
kind
of
going
through
them
in
a
prioritized
order.
Eliminate
all
of
the
to
Do's.
Do
the
highest
priority
issues,
make
sure
they're
resolved
and
like
the
clarity
things
that
we
wanted
out
of
1.0,
that
we
actually
get
them
out
of
1.0
and
then
at
the
beginning
of
February.
A
Like
end
of
January,
beginning
of
February
that
week
announced
to
the
community
that
it's
ready
for
review
and
during
that
period
in
February,
we
could
continue
to
make
further
Clarity
changes.
But
but
we
basically
ideally
would
have
all
of
the
actual
content
terminology
Etc
kind
of
solidified
by
then
and-
and
there
wouldn't
be
two
major
changes
during
February
and
then
after
the
1.0
released.
A
I
think
we
could
continue
to
edit
to
like
we
have
done
with
the
original
release,
address
edge
cases
address,
inconsistencies,
Clarity
Etc,
but
just
don't
change
like
the
significant
meaning.
So,
okay
Michael.
E
Yeah,
the
only
thing
I
just
want
to
add
in
there
is
something
that
we
wanted
to
from
the
tooling
side
wanted
to
get
some
feedback
on.
Did
you
think
that
we
could
like?
E
Do
you
think
by
and
large
the
spec
will
probably
be
accepted,
as
is
or
with
like
relatively
minor
changes,
because
I
think
from
the
tooling
side
we're
starting
to
think
of
like
hey?
We
want
to
be
ready
so
that
when
1.0
comes
out,
it's
not
going
to
be
like
two
months
before
anything
supports
the
1.0
spec.
E
We
want
to
make
sure
that
it's
like
you
know,
even
if
we
adopt
let's
say
hey,
we've
adopted
the
draft
and
then
once
you
know,
if
there's
a
couple
of
naming
changes
in
a
couple
of
small
things,
it
shouldn't
be
massive
PR's
there,
except
to
maybe
a
couple
of
the
tools
that
do
have
longer
release
Cycles.
A
We
should
absolutely,
in
my
opinion,
we
should
tie
this
to
tooling
because,
like
we
won't
know
if
the
spec
is
good
until
you
go
to
implement
it
right,
like
you
spend
all
his
work
thinking,
it's
perfect
and
the
first
time
you
go
to
go
crap.
This
I
forgot
this
case
or,
like
it's
not
implementable,
do
you
think
that
right,
right
and
same
for
blogging
position,
I
think
it
should
be
aligned?
It's
not
just
like
spec
by
yourself,
I.
A
Vision
when
I
wrote
this,
do
you
think,
okay,
so,
first
of
all,
I
guess
considering
that
that
you
know
we
want
to
get
like
tooling
and
communication
everything
aligned.
E
I
I
think
it
depends
on
how
you
define
it
and
and
what
what
Line
in
the
Sand
we
as
a
group
are
sort
of
taking
right
because
I
mean-
and
this
is
not
what
What's
I
I
can't
remember
the
the
thing
that
they
say
about.
You
know
these
sorts
of
things,
but
it's
like
you
know.
If
you
say:
hey,
there's
a
you
know
a
four
week,
let's
say
period
that
will
take
feedback.
E
A
ton
of
folks
are
going
to
give
feedback
literally
four
weeks
from
now
all
of
a
sudden,
you
know
and
then
and
then
you're
gonna,
be
like,
oh
okay,
because
that's
just
the
way
these
things
work
but
I
I.
Think
if
we,
you
know,
say,
hey,
look
we're
looking
for
feedback
and
that
feedback
is
going
to
be
voted
on
by
the
steering
committee
of
salsa
right
then
that
just
sort
of
says
yeah,
like
your
feedback,
might
be
good.
But
we
might
still
say
it's
not
really.
What
we're
looking
to
change.
I
So
yeah
I
guess
the
I
think
we
can
really
gauge
it
pretty
well
by
just
kind
of
understanding.
What's
the
rest
of
the
work
needed
for
46
and
508
right,
because
Mark
you're
saying
that
525
is
pretty
much
ready
for
review,
I
feel
like
that's
kind
of
the
biggest
hurdle
and
then
the
rest
is
just
review
and
tweaking
based
on
the
review
right.
A
Yeah
yeah
Chris
is
I.
Think
Chris
is
here
right,
I
think
I
saw
his
name.
J
Yeah
Chris
is
here:
I
can
speak
quickly
to
46,
while
Chris
is
coming
off.
You
and
say,
like
I,
have
content
for
the
terminology
page
that
I'm
planning
to
submit
as
a
like
draft
PR,
maybe
today
and
then
I'm
still
working
on
what
to
change
it.
What
the
changes
in
the
requirements
are
to
reflect
that
kind
of
terminology
and
those
Concepts
so
I
think
this
week
is
a
reasonable
goal
for
having
their
content
authored.
But
review
may
be
trickier
within
that
time
frame.
J
The
other
thing
I
I
wanted
to
suggest
is
that
actually
no
I'll,
let
Chris
speak
first.
I'll
keep
my
hand
raised
for
the
second
point.
G
The
reviewing
systems
DACA
is
in
about
the
same
place.
It's
it's
a
good
I,
have
it
as
a
Google
doc.
It
still
has
some
outstanding
feedback
that
I
need
to
address,
but
I
can
have
it
as
a
PR.
Today
or
tomorrow.
It's
just
a
matter
of
whether
it's
approved
by
the
end
of
the
week.
A
All
right
so
then,
then,
maybe
the
just
to
set
up
like
intermediate
milestones
for
us
to
try
to
you,
know
time
box
efforts
if
we
say
get
the
then
out
for
review
by
the
end
of
this
week,
so
like
number
508
out
for
a
review
of
but
and
like
merged
next
week.
A
Is
is
too
too
tight
turn
around,
but
ideally
you
know
get
reviews
early
in
the
week
and
be
able
to
address
feedback
so
effectively.
The
January
20th
like,
hopefully,
have
everything
an
initial
draft,
even
if
there's
outstanding
dues
to
Do's
I
think
it's
probably
worthwhile
at
this
point
to
if
there's
a
tricky
like
a
particular
tricky
thing
like
oh
I'm,
not
sure
how
to
resolve
that,
that's
going
to
take
a
lot
of
thinking
to
do
what
is
it
to
do,
submit
it
in
the
markdown
as
a
to-do?
A
That's
what
I've
been
doing
and
then
we
can
come
back
to
it
later
and
then,
when
we're
getting
closer
to
the
end
of
the
month-
and
we
have
a
bunch
of
these,
we
could
prioritize
and
say
which
ones
do
we
really
need
to
address?
Which
ones
can
we
defer?
Which
ones
can
we
just
say
it's
good
enough.
A
Okay,
you.
J
J
Yeah
I
didn't
have
a
follow-on
kind
of
suggestion,
which
is
dude.
Would
it
I
I,
don't
know
how
attached
we
are
to
the
proposed
February
date,
but
we
could
thinking
more
of
this
thinking
of
this
more
like,
like
traditionally
developed
software,
we
could
think
of
the
February
date
or
we
could
think
of
the
review
period.
J
Closing
as
the
like
when
the
beta
period
starts,
and
then
we
integrate
review
We
integrate
the
outstanding
review,
while
any
tooling
is
progressing
during
that
period,
so
the
spec
is
kind
of
more
complete,
but
not
then,
once
the
beta
period
is
over
feedback's
integrated
and
tooling's
ready.
That's
when
we
make
the
release
with
the
blog
post
and
the
positioning
updates
and
things
I,
don't
know
how
well
that
would
work,
but
it's
just
an
idea
that
I
thought
it
was
worth
airing.
E
Yeah
I
I
really
like
that
idea,
especially
for
some
of
the
the
simpler
tools
that
can
very
easily
integrate
both
a
draft
or
a
beta
and
then
eventually
the
real
thing.
I
think
some
of
the
tools
are
going
to
say,
hey,
look
given
our
release
cycle.
It
probably
really
only
makes
sense
for
us
to
implement
the
full
1.0,
but
I
think
a
lot
of
other
tools
are
going
to
say
you
know
like
I'm,
just
thinking
of
all
the
GitHub
generator
stuff
that
we
just
have
for
for
salsa
it'll.
E
J
Yeah
I
think
we
should
Define
which
tools
we
care
about
or
have
sufficient
control
over
to
include
in
that
kind
of
time.
Boxing
effort
right.
We
have
two
well,
we
have
two
demo
repositories
and
then
two
like
non-demo
repositories
in
the
salsa
framework
organization,
there's
the
Jenkins
generator
and
the
GitHub
generators
are
not
demos,
whether
whether
we
want
to
try
and
reach
out
to
the
maintainers
of
those
tools
and
see
how
they
fit.
In
with
this
proposal,.
H
A
The
the
verifying,
like
the
three
I,
think
major
pieces
here
are
the
the
provenance
format,
which
is
the
most
direct
where
we
would
get
the
feedback.
It's
like.
We
got
a
lot
of
feedback
so
far.
Hopefully
the
new
thing
is
clear,
but
it's
not
clear.
Maybe
it's
a
either
side
step
or
a
backward
step.
A
The
artifact
verification
piece
probably
is
the
most
underdeveloped
because
we
don't
really
have
a
good
story
so
far
on
that,
like
the
only
tool
there's
something
kind
of
some
like
ad
hoc
verification,
things
like
implementing
a
queue
Etc,
the
salsa
verifier
thing
has
stuff
on
the
command
line,
but
it's
not
really
integrated
in
a
way
that
we're
hoping
for
the
1.0
of,
like
you
know,
there's
like
conventions
and
expectations,
and
things
like
that,
so
that's
probably,
and
but
doing
that
in
time
for
1.0
is
going
to
be
tough,
so
I'm
not
sure
what
we
it
would
be
good
to
think
about
like
if
we
have
like
some
sort
of
prototype
or
something
like
that
for
that.
A
I'm
I'm
less
concerned
about
that,
because
that's
kind
of
like
an
offline
process
anyway
and
you
could
kind
of
initially
you
could
just
kind
of
fake
it
with
here's.
The
key
that
I
trust.
D
So
if
I
manager
dictate
I
mean
one
question
I
have,
is
you
know
what
what
is
essentially
the
criteria
to
decide?
Okay,
we're
ready
to
call
it
one
zero
and
be
done
because
you
know
if
it's
just
well,
we
don't
have
any
open
issues
on
GitHub.
That's
one
way
to
do
it
or
we
don't
have
any
git
pull
requests
open.
That's
that's
a
different
criteria,
but
if
you
say
hey,
we
want
at
least
some
number
of
people
reporting.
They
have
actually
implemented
it
whatever.
That
means
you
know,
that's
different
criteria.
D
If
you
look
into
how
standards
get
developed
nowadays,
they
often
have
pretty
stringent
criteria
even
going
as
far
as
an
interrupt.
You
know,
criteria
where
they
actually
tested
different
implementations
do
the
same
things
and
I'm
not
saying
we
want
to
do
all
of
this,
because
clearly
this
would
push
Way
Beyond.
J
I
think
the
power
is
that
we
have
achieved
the
things
we
set
out
to
achieve
in
The,
Proposal
or
or
at
least
enough
of
them
right
that
that
was
the
they
were.
The
goals
we
set
out
with
for
the
1.0
release
or
get
release.
J
A
If
we
could
have
a
couple
implementation
well,
I
guess
maybe
I
don't
have
a
hard
idea
of
like
if
you
do
X
it's
good.
My
inclination
would
be
something
like
we
consensus.
You
know
book
this
group
and
also
steering
committee,
something
like
that
and
if
we
kind
of
agree
if
it
feels
right
that
that's
kind
of
begging
the
question
now
what
I
would
feel
comfortable
with
is
if
we
had
at
least
a
couple
implementations,
do
a
draft
version
and
say
they've
done
it.
A
It's
working
without
that
I
wouldn't
be
very
confident
and
then
I
think
we'll
have.
If,
if
the
implementations
aren't
there
and
it's
kind
of
coming
towards
end
of
February,
my
inclination
would
be
to
just
extend
the
review
period
and
just
have
a
longer
in
review.
Because
then
it's
basically
you
know
it's
out
there.
People
could
look
at
it.
We
don't
know
of
things
that
were
going
to
change,
but
there's
some
indication
that
you
know
we
might
see
issues
and
it
might
change
before
we
call
unstable.
D
Yeah
I
think
something
like
this
sounds
reasonable
to
me.
There's
also
a
corollary
to
this,
which
is,
what's
your
you
know,
tolerance
to
having
to
to
do
a
1.1
pretty
quickly,
because
you
messed
up
something-
and
you
say:
oh,
we
have
a
problem
here.
We
need
to
fix.
You
know
is
that
tolerable
or
not
some
people
might
have
different
expectations
in
this
regard
they
feel
more
tolerant.
Then
you
can
take
a
higher
risk
and
say:
okay,
we're
not
Nestle.
D
I
mean
just
do
it
for
background.
You
know
what
you
just
said:
if
you
look
at
the
whatever
she
does
it
before,
they
call
it
a
standard
what
they
call
Standard,
which
is
a
recommendation
they're
this
candidate
recommendation,
which
actually
has
no
time
limit
it's
like
well,
we
need
at
least
two
implementation
of
every
feature
in
the
spec
and
it
takes
whatever
it
takes
and
I'm
not
saying
this
is
what
you
want
to
do
here
again:
I'm,
not
trying
to
push
a
specific
model.
I'm
sharing
this
as
put
for
thoughts.
D
A
Yeah,
that's
a
good
question.
Maybe
we
should
get
more
feedback
on
this
from
the
community
of
how
desirable
is
it
to
have
something
called
1.0?
Now
that's
marked
as
table
with
some
high
amount
of
risk
that
you're
going
to
have
to
do
a
1.1
or
1.2
in
not
that
long
or
how
much
would
people
want
to
wait
for
a
you
know
like
a
really
stable,
1.0,
I?
Guess,
that's
kind
of
like
the
lowest
Colonel.
A
D
D
K
Yeah
I,
just
for
the
sake
of
experiencing
I,
think
we
have
to
compromise
a
little
and
say
if
enough
of
the
stand
of
the
spec
has
been
implemented,
not
all
of
it
not
multiple
times,
but
if
enough
of
the
spec
has
been
implemented,
that
we
have
confidence
that
should
be
sufficient,
because
full
coverage
is
a
thing.
That's
that's
a
lot
of
work.
C
So
I
wanted
to
Echo
some
of
that
where
I
feel
if
we
release
the
parts,
only
the
parts
that
were
truly
competent
in
I
think
I
mentioned
this.
When
we
first
started
this
level,
one
level
two
right
forget
about
level
three
level:
four,
because
if
you
don't
have
that
solid
base,
it
doesn't
matter
what
you
do
in
level
three
level.
Four,
it's
gonna
constantly
change.
So
if
we're
super
confident
on
level,
one
okay,
that's
going
to
go
into
version
one
level
two.
Are
we
confident
in
that?
C
C
C
Some
people
have
already
gone
through
this
process,
even
though
it
wasn't
well
defined,
but
we
don't
want
to
make
people
do
extra
work
because
we
are
constantly
changing
level.
One
or
level
two
as
an
example,
which
is
pretty
much
the
foundation.
E
Yeah
no
I
I
agree
with
that
and
I
I
I
also
think
that
you
know
there's
some
things
that
from
a
I
think
a
lot
of
that's
also
going
to
be
part
of
you
know,
blog
articles
and
and
some
of
the
education
making
sure
that
folks
understand,
because
without
getting
into
too
many
details,
there's
definitely
I.
E
Think
all
of
us
have
found
our
fair
share
of
either
blog
articles
or
YouTube
videos
of
someone
saying
here's
how
we
did
all
the
stuff
with
salsa
and
it's
clear
to
the
folks
who
are
in
this
meeting
that,
like
not
really
and
I
know
with
some
of
the
salsa
conformance
work
that
some
folks
are
working
on.
E
You
know
there
might
be
some
additional
stuff
where
we
might
come
in
and
actually
say,
hey
look.
You
can't
claim
to
be
salsa
compliant
and
use
the
open,
ssf's
trademarks
unless
to
at
least
provide
this
level
of
stuff
there.
But
I
think
to
to
your
point
like
we
want
to
make
sure
that
that's
crystal
clear
because
of
the
worst
that
could
happen
is.
E
Is
you
know
if
even
among
this
group
there's
a
lot
of
like
well
sort
of
they
comply
and
it's
like
yeah
that
that
that's
gonna
kill
any
sort
of
emerging
standard
or
whatever
you
want
to
call
it.
A
So
so
canelo's
point
any
thoughts
on
what
we
are
confident
versus
what
we're
not
like
the
levels.
One
two
versus
three
would
be
a
clear
thing
to
delineate,
but
is
that,
like
are
the
things
in
level?
Three
that's
right
now,
for
example,
here
I'll
link
to
the
requirements
in
the
chat
just
so
people
can
click.
Is
there
anything
in
level
three
like
dropping
at
level?
Three,
for
example,
would
it
increase
our
confidence
very
much?
A
It's
basically
the
non-forgeable
piece
and
the
ephemeral
and
isolated
piece
I
think
that's
the
only
major
well
I
guess
that
and
the
verifying
systems
we
had
talked
about
and
I,
don't
know
if
there's
agreement,
but
we
had
talked
about
the
idea
that,
like.
C
I
My
opinion
we
we
have
to
launch
1.0
with
level
three
with
these
factors,
because
if
we
only
launch
1.0
with
two
levels,
the
second
level
is
nice.
But
it's
not
very
strong.
So.
I
Three,
so
if
that
means
delaying
I
think
it's
worth
it
I
plan
on,
you
know.
C
C
A
The
desire
like
that
I
keep
hearing
that,
like
lots
of
organ
companies
like
just
want,
they
want
something,
and
so
that
was
just
picked.
C
Got
it
because
if,
if
there's
a
conference
as
an
example,
I
know
the
open
source,
Summit
is
May.
But
if
there's
something,
let's
say
in
April
or
in
March
that
we
can
aim
towards
and
then
I
can
understand,
because
we
would
want
to
be
ready
for
those
conferences.
As
an
example.
E
I
think
we
should
be
ready
for
for
the
conferences
that
are
coming
up,
but
I
think
also.
One
of
the
other
reasons
why
we
want
to
kind
of
get
the
1.0
out
is
is
also
to
to
clear
up
some
confusion
caused
by
0.1
and
what
we
currently
have
today.
I
just
say
that
like
because,
having
looked
at
some
of
the
proposals
for
some
of
the
talks
for
cloud
native
security
con,
some
of
them
showed
a
very
clear
lack
of
understanding
of
of
salsa,
or
at
least
the
you
know.
E
Some
of
that,
but
also
you
know,
we
are
seeing,
for
example,
more
and
more
folks
give
talks
about
Tulsa
and
obviously
we
would
want
to
see
talks
on
salsa
1.0.
For
example.
E
There
is
I
think
a
few
talks
on
salsa
that's
going
to
be
happening
in
a
couple
of
weeks
in
Seattle,
like
Cloud
native
security,
con
I
know,
there's
a
bunch
of
talks
that
have
been
submitted
for
kubecon
Europe,
which
is
in
April,
and
then
I
know
that
there's
upcoming,
which
I
believe
the
cfp
is
is
ending
sooner
than
than
we'd
like
for,
for
the
open
source
Summit
out
in
Vancouver.
A
That's
a
really
good
point,
like
part
of
the
1.0
design
1.0
is
to
address
those
concerns.
Is
there
any
way
we
could
reach
out
to
some
of
those
folks
to
see
if
the
changes
that
we've
made
in
1.0
actually
achieve
that
effect
of
making
it
more
clear.
E
I
I
think
that
there's
probably
you
know
I
know,
Susa
has
done
some
stuff
and
a
few
other
folks
have
like
very
publicly
said,
hey
we're
doing
a
lot
of
salsa
I.
Think
that's!
That's
that'd,
be
a
good
idea.
J
Yeah
agreed
I
think
we
could
easily
find
at
least
the
Susa
and
flat
car
folks
that
have
implemented
cells
are
undocumented,
how
they
believe
they've
achieved
the
requirements.
D
So
I
know
we're
all
leaning,
12
1-0,
but
would
it
be
conceivable
to
have
a
maybe
0.9
or
something
like
this?
That
would
be
able
to
publish
sooner
rather
than
later,
and
that
would
be
kind
of
a
middle
ground
where
we're
not
saying
hey,
it's
completely
ready
yet,
but
it's
way
better
than
zero
one,
which
is
the
only
thing
that
people
have
so
far
and
we
give
us
a
bit
more
time
to
finalize
one
zero,
I
kind
of
agree
with
that.
D
What
Aaron
said
by
the
way,
I
think
one
zero
with
that
level
three
is
a
bit
weaker
is
going
to
you
know
people
most
people
are
going
to
say.
That's
all
they're
going
to
feel
that
down
honestly.
So
from
that
point
of
view,
it'll
be
better
to
have
a
zero
nine,
which
is
maybe
not
perfect
and
as
some
you
know
that
that
comes
sooner,
they
still
better
than
zero
one
and
and
then
we
take
the
time
to
finalize
the
one
zero
that
has
level
three
and
is
more
solid.
J
So
I
I
want
to
agree
with
the
state
the
sentiment
that
level
three
should
be
in
one
zero
and
I
I'm
quite
comfortable
with
level
three,
as
is
personally
I.
Think
we've
had
some
recent
wording,
changes
that
have
made
it
a
lot
clearer.
J
The
other
thing
I
want
to
say
is
that
I
worry
that
if
we
keep
like
I,
think
we've
seen
a
flurry
of
folks
who
are
interested
in
this
space,
Implement
Implement
salsa
their
interpretation
of
salsa
0.1
and
then
a
bunch
of
folks
who
are
interested
but
holding
off
until
it's
more
fully
baked
and
I.
Don't
know
that
a
an
interim
release
helps
because
yeah
so
I
think
I
know.
J
You
said
earlier
something
along
the
lines
of
like
you
kind
of
need
that
1.0
for
people
to
start
implementing
it,
and
once
you
get
that
feedback
you
can
make
updates
and-
and
you
asked
how
we
felt
about
making
a
fairly
quick
1.1
or
a
similar.
J
So
I
I
actually
think
the
I'm
I
feel
that
the
the
implications
of
the
version
number
is
what
it's
holding
some
folks
back
from
from
implementing
salsa.
So
in
some
ways
we
just
kind
of
need
to
get
to
that
one
zero
and
make
a
release.
H
So
I
throw
a
middle
middle
ground
to
the
release
number
I
I
as
far
as
which
version
it's
irrelevant.
As
long
as
long
as
it's
usable.
For
me,
the
from
Elite
release,
side,
I
heard
two
one
so
I
mentioned
earlier.
We
need
to
go
to
the
community
and
ask
for
feedback
on
things,
so
it
almost
feels
like
we're
at
a
pre
version.
H
One
release
request
for
comment
stage
which
could
allow
us,
you
could
I,
think
I've
heard
a
lot
of
people
say
we
feel
pretty
confident
up
to
three
where
there
might
be
some
changes,
but
it's
fairly,
you
know
close
so
for
for
close
release.
Why
aren't
we
not
at
a
pre
1.0
release
out
for
request
for
comment?
We
can
have
two
or
three
versions
of
pre-releases
as
we
go
through
multiple
stages,
so
it
gives
us
whatever
time
you
need
for
it,
but
at
least
we're
acknowledging
it's
close
to
there.
J
That
aligns
with
the
notion
of
calling
something
a
beta
or
whatever
and
then
giving
folks
time
to
work
on
tooling
and
positioning,
and
things
like
that
as
well.
I
think.
E
Yeah
yeah
I
think
calling
a
b
to
release
a
draft
or
whatever
is
is
good.
I
think
the
only
thing
that
I
know
we
want
to
avoid
is
we
want
to
avoid
the
churn
of
one
more
thing
before
it's
ready
for
1.0
and
I?
Don't
know
if
folks
have
thoughts
around
helping
that,
but
I
know
from
a
lot
of
the
LF
related
projects.
E
One
of
the
things
that
constantly
has
happened
is
is
a
little
bit
of
that
paralysis
right
before
a
release,
because
some,
you
know
something
else,
comes
up
and
just
I
think
on
that
end,
we
just
want
to
make
sure
that
we
can
be
very
clear
like
if
we
do
open
up
a
request
for
comment
that
it
ends
at
a
very
specific
date
and
so
on,
because
we
also
don't
want
to
end
up,
like
you
know,
perfect,
as
the
enemy
of
the
good.
E
We
don't
want
to
end
up
in
a
situation
where
we're
constantly
trying
to
make
sure
that
it's
perfect
just
as
and
you
know-
and
we
do
want
to
do
what
we
can
to
make
sure
that
we
get
feedback.
E
So
that's
also
another
thing
that
I
really
want
to
make
sure
it
gets
heard
because
in
a
lot
of
the
open,
ssf
and
Linux
Foundation
cncf
stuff,
so
one
of
the
things
that
sometimes
happens
without
the
right
communication
is
a
lot
of
folks
say:
wait,
the
the
RFC
was
done,
I,
never
even
heard
it
happened,
and
so
all
of
a
sudden,
a
lot
of
folks
get.
You
know
a
little
grumpy
that,
like
they
had
no
idea
that
that
there
was
this
request
for
comment.
A
Yeah
I,
don't
I
originally
had
an
opinion,
but
then
I
I
now
no
longer
I
have
a
strong
opinion.
Foreign
I
guess
after
that
I
maybe
might
I'd
be
kind
of
inclined
to
keep
it
calling
at
1.0.
But
as
draft
because.
A
And
1.0
release
candidate
or
draft
or
beta
or
whatever,
or
just
two
two
names
for
the
same
thing
and
1.0
release
can
at
least
makes
it
more
clear
like
this
is
not
intended
to
be
stable
or
less
less
stable.
A
One
question,
assuming
that
we
do
that,
so
we
continue
what
were
the
current
plans,
possibly
just
extending
the
period.
That's
called
draft
the
RFC
period,
any
thoughts
on
how
we
indicate
that,
like
you
know,
we
could
change
the
url.
So
it's
like
V1
hyphen
draft,
which
is
kind
of
annoying.
H
A
Yeah
sorry,
I,
yeah,
I,
sorry
I
I
think
either
way
we'll
have
that
such
a
banner,
like
that,
both
a
thing
at
the
top
saying
this
is
like
the
the
status
field
and
also
the
big
pop-up
Banner
that
we
have
now
I,
guess,
I,
guess
more
specifically
in
like
the
URL,
should
we
call
it?
Should
we
should
we
change
a
URL,
or
is
it
fine
leaving
that
URL?
Let's
just
be
one
hey.
G
Michael,
maybe
I'm
the
only
one
that.
H
D
If
all
the
principle
of
cool
URLs
don't
change,
yes,
you
should
have
a
different
URL
for
the
draft
and
the
final
move,
because
you're
actually
changing
the
content
underneath,
but.
J
Yeah
I
think
I
also
prefer
a
URL
to
a
parameter.
A
I
get
some
questions
like
how.
How
much
is
that
worth,
because
it's
going
to
take
some
amount
of
effort
to
implement
it?
Yes,
ideally
you
know.
Ideally,
we
would
have
something
that,
like
automatically
builds
at
every
version
and
everything
like
these
tags
and
like
you
could
do
like
down
to
point
releases
and
or
the
V1
goes
to
the
latest
release,
but
it's
just
not
implemented.
So
we
don't.
D
A
A
The
consensus
seems
to
be
call
it
1.0
have
the
the
draft
banner
and,
like
the
status
field,
thing
in
review,
possibly
changing
the
text
of
the
banner
to
make
it
more
clear
that
it's
like
in
the
RFC
period
and
when
the
RFC
period
will
end
Arnold,
you're
gonna.
D
Say
something
yeah
I'm,
sorry
I'm
going
to
deter
because
I
want
to
slightly
take
back
what
I
said.
There
is
one
important
aspect
to
this,
which
is,
if
you
want
to
be
able
to
go
back
to
an
older
version.
So
if
we
have
a
1-0
draft,
that's
up
for
review
and
then
you
have
a
new
version
of
the
final
version
and
at
some
point
you
want
to
say
oh,
but
look
in
the
previews,
the
in
the
draft
version
we
added
this
way
of.
A
A
D
A
Yeah
or
like
a
minor
Point
release
like
right,
like
we
would
have
to
change
how
we
build
right
now,
what
we
always
build.
We
have
a
directory
for
each
major
version
or
either
minor
version
whatever
and
always
build
it
head,
and
so
all
the
different
versions
are
just
different
directories
and
our
release
just
always
built
ahead.
A
I
think
a
theoretical,
better
thing
unless
you're
in
practice,
but
better
would
be
like
to
have
each
spec
have
its
own
repo,
maybe
and
tag
them,
and
have
some
build
process,
pull
in
all
the
different
repos,
build
it
all
the
different
versions
and
mash
them
together
or
not
match,
but
like
combine
them
together
into
one
side.
A
I
think
that's
the
right
way
to
do
it.
I
think
spdx,
for
example,
is
doing
that
with
their
site.
I
think
William
both
follow
me.
Who
said
something
about
that.
That
seems
like
a
better
system,
but
we
just
don't
have
it.
D
A
Yeah
I
guess
I
guess
you
could
do
that
like
instead
of
just
editing
the
draft
continually
as
during
the
comment
period
yeah
you.
D
A
Okay,
so
I'm
going
to
assume
we're
not
going
to
do
that,
but
if
anyone,
if
you
or
anyone,
feels
strongly
and
I'm
gonna,
let
someone
else
make
it
happen.
Yeah.
E
So
I
don't
feel
strongly,
but
I
do
think
that
for
folks
who
are
interested
one
of
the
things,
that's
that's
probably
a
point
of
discussion
for
the
1.0
tooling
implementations
because
right
like,
if
there's
going
to
be
an
expectation
that
we're
using
certain
things
in
the
implementation
and
if
the
idea
is
that
certain
things
might
like
the
certain
things
from
a
URL
perspective
of
like
yeah
1.0
might
change
that
could
cause
some
issues.
I
think
regardless
we're
going
to
have
a
discussion
in
this
in
the
tooling
meeting
yeah
so.
A
Like
the
provenance
spec,
what
I
it
was
currently
in
the
pull
request-
and
this
is
like
I
said
for
comments-
is
I-
just
include
like
question
mark
draft,
because
it's
like
a
free
way
of
doing
it,
like
the
the
server
just
ignores
that
query
parameter
and
it's
a
super
cheap
way
of
doing
it,
and
then
anything
with
that.
It's
not
documented
I,
guess
I
need
to
document
it.
A
I
would
assume
like
it's
just
a
floating
version
and
there's
no
guarantee
about
compatibility,
and
once
we
finalize,
we
don't
support
it
anymore
versus
having
like
some
version
thing
and
then
the
tooling,
like
do
you
support
all
these
intermediate
drafts?
Or
do
you
only
support
the
final
thing,
although
I
guess
calling
them
like
release,
candidates
would
make
them
more
clear,
but
yeah.
A
A
So
there's
some
question
about
the
permalinks
sounds
like
we'll
call
it
1.0
like
release
candidate.
It
would
be
good
to
reach
out
if
anyone
can
once
we
have
it.
You
know
in
in
the
coming
weeks,
if
you
know
like
Michael
mentioned
some
talks,
it'd
be
good
to
reach
out
to
them
and
see
if
the
new
version
helps.
A
It
sounds
like
including
level.
Three
we'll
assume
we'll
include
level
three
for
now,
although
we
could
be
on
the
lookout
for
other
things,
that
we
could
possibly
defer.
A
Okay
and
well
also
plan
for
to
have
some
sort
of
tooling
ready
in
the
same
time
period.
Maybe
in
a
tooling
meeting
we
could
we
could
talk
about
implementing
some
of
the
like
the
draft.
The
draft
versions.
J
Sounds
good
I
can
try
and
reach
out
to
a
couple
of
folks
like
I,
spoke
to
Souza
about
their
implementation
and
flat
car
as
well
great.
A
F
A
Implementation
that
sounds
good,
so
just
I
I,
don't
think
we
should
spend
time
talking
about
it
here,
but
I
just
want
to
call
the
attention
to
the
again
the
prominence,
pull
request,
there's
a
bunch
of
to-do's
in
it
and
like
it's
not
written
in
a
format
like
it's
written
in
a
protobuf.
Probably
you
want
to
be
converted
to
markdown.
A
There's
there's
a
lot
of
things
we
could
do
for
editing,
but
I
wanted
to
see
if
the
schema
here
I'll
here's
the
link,
it's
in
the
CH
in
a
dock
as
well,
but
that
the
top
post
on
that
has
a
link
to
the
preview
that
you
could
look
at,
and
so,
if
I'd
be
interested
in
feedback,
I
guess
this
is
where
implementations
actually
would
be
really
valuable.
A
But
I
think
if
we
do,
my
thinking
was
as
long
as
people
who
read
it.
Look
at
it
and
say
yeah
that
looks
that
makes
sense
to
me.
We
could
at
least
submit
it
Mark
it
as
draft
no
it's
unstable
and
then,
instead
of
implementations
having
to
refer
to
a
pull
request,
they
could
at
least
refer
to
something
on
the
website.
E
Yeah
I
generally,
like
it
I,
think
the
the
main
things
I
know
we
wanted
to
make
sure
of
because
it
makes
implementation
of
use
or
use
of
the
spec.
Simpler
is
stuff
like
making
making
sure
that
that
things
that
are
intended
to
be
like
temporal
or
non-reproducible,
those
sorts
of
things
should
go
into
their
own
sort
of
separate.
You
know
metadata
section
or
something
like
that,
just
because
it
makes
it
easier
for
folks
who
are
comparing.
E
You
know
two
documents
that
just
have
different
time
stamps
and
be
able
to
say
well.
Take
me
the
hash
of
all
the
stuff
that
should
be
reproducible,
and
you
could
just
sort
of
take
that
all
out,
as
opposed
to
what
some
folks
I've
noticed
been
doing
today.
Is
they
go
like
field
by
field
and
say
well,
these
fields
should
be
reproducible
and
then
try
and
pull
that
in
and
it
becomes
a
huge
mess,
whereas
I
think
this
makes
at
least
from
a
draft
perspective.
E
This
makes
it
a
lot
more
ingestible
and
and
I'm,
hoping
in
the
tooling
meeting.
We
can
kind
of
have
some
discussions
about.
You
know.
Are
there
any
other
small
tweaks?
We
would
make
to
this
to
make
it
even
nicer
to
use.
A
A
There's
things
like,
for
example,
on
GitHub
actions.
When
you
invoke
it,
there's
the
build
can
view
these
the
GitHub
context,
which
is
like
a
variable
that
the
the
build
process
can
query,
has
things
like
the
actor
who
triggered
the
the
action,
the
like
ID
numbers
of
the
repository,
a
run
number
things
like
that
that
are
kind
of
a
run
detail,
but
also
available.
A
It's
actually
an
input
to
the
build
process,
so
it
kind
of
spans
both
it's
not
exactly
a
parameter,
but
it's
it
doesn't
feel
right,
so
it
doesn't
fit
very
cleanly
into
any
of
these
when
I
was
trying
to
do
it.
So
that
might
be
something
if
folks
have
an
idea
on
like
how
to
tweak
the
model
to
incorporate
that
or.
F
So
so,
hey
Mark,
this
is
Gilbert,
so
I
we
well.
Our
team
has
experience
with
GitHub
actions
and
collecting
insights
on
GitHub
actions.
Sorry,
are
you
I
just
so
I
can
understand
better.
Are
you
trying
to
just
kind
of
look
at
the
volume
of
actions
based
on
who
created
that
GHA
I'll
call
it
pipeline
or
workflow
and
then
Trace
back
everything
around
it?
Is
that
the
intent.
A
Yeah,
by
the
way,
if
anyone
wants
to
go
we're
at
the
time,
so
thanks
everyone
for
for
attending
I,
don't
want
to
keep
people
past
the
time
the
the
idea
is
to
capture
basically
everything
that
that
went
into
the
build
theoretically,
so
you
could
reproduce
it.
Although
that's
not
the
primary
motivation,
the
primary
motivation
is
to
capture
all
of
the
things
that
were
like
externally.
The
number
one
motivation
is
capture
all
the
things
that
were
externally
input.