►
From YouTube: SLSA Specifications Meeting (March 27, 2023)
Description
Meeting notes: https://docs.google.com/document/d/1kMP62o3KI0IqjPRSNtUqADodBqpEL_wlL1PEOsl6u20/edit#heading=h.yfiy9b23vayj
A
A
B
A
A
A
A
I
suspect
we
should
not
be
any
major
restructuring
or
changes,
but
like
typo
fixes
small
little
Clarity
fixes
seem
okay
to
me,
but
nothing
that
anyone
like
would
want
to
like
re-review
I
I
did
a
pass
through
the
project
board
and
I
created
a
new,
oh
they're
called
labels.
Sorry
I
thought
they
were
called
Tags
I
create
a
new
tag,
called
V1
blocker
with
things
that
I
thought
we
can't
change.
Post
1.0
like,
for
example,
a
schema
change
like
changing
the
name
of
a
field.
A
A
A
Some
of
the
things
we
could
post
as
like
just
a
minor
follow-up,
because
they're
Clarity
things
that
don't
really
change
the
meaning.
They
don't
really
change
the
spec.
They
don't
change
the
schema
at
all,
but
that
would
just
be
good
to
do
afterward
that
are
not
going
to
like
hamper
anyone's
ability
to
understand
the
spec,
but
that
would
be
nice
to
have
so
the
ones
I
tagged
as
a
V1
block
just
to
kind
of
go
through
the
I
guess
I
could
go
through
all
these
issues.
A
This
is
just
a
meta
issue
about
the
1.0
release
same
thing
with
this
one.
This
is
a
meta
issue
about
tracking
for
tooling,
so
I,
don't
think,
there's
any
work
there,
except.
Let
me
actually
cut
the
release,
one
about
explaining
consumers
responsibilities
that
want
to
block
her.
Maybe
that
should
be
a
blocker.
A
We
have
a
thing
on
salsa
versioning.
Actually
that
one
should
probably
it
would
be
one
block
or
two
and
I
think
there's
already
a
pull
request
out
for
this
s2c
to
F
and
salsa
I
think
would
be
nice
to
have
I
if
we
have
to
cut
something
I,
don't
I,
don't
think
it's
a
blocker
update
the
threats
as
in
progress
already
Providence
Discovery,
I,
guess,
I'll,
I,
guess:
I'll
I'll
call
these
a
blockers,
but
we
already
have
pull
requests
for
them
and
they're
already
assigned
unified
variant
across
this
one.
A
A
Record
information
about
the
Builder
guidance
should
look
on
it
here.
I
feel
like
these
are
all
things
that
we
don't
need
to
do
for
1.0
that
like,
if
we
do
it
after
the
1.0
release,
is
not
going
to
cause
backwards
compatibility
problems,
but
it
would
be
good
to
have
folks
review
them
and
verify
that's
the
case,
and
if
you
could
like
comment
or
something
saying
that
that
would
be
helpful,
but
for
the
VSA
we
I
think
won
backwards.
Incompatible
thing
is
indicating
it
aversion.
A
A
A
A
A
huge
deal
to
change,
and
then
all
these
open
ones,
I
went
through
the
ones
that
that
I
tried
to
clarify
whether
it's
just
a
Clarity
thing
or
actually
something
that
requires
a
backwards
and
compatible
change,
and
it
seems
like
about
half
of
them.
Are
some
of
these
need,
like
they're
kind
of
like
a
long
thread,
for
example.
Builder
name
is
this:
is
the
Builder
name
one?
A
C
A
I
think
if
there's
actually
something
that
we
really
want
to
get
to,
and
we
can't
do
then
I
think
we
should
push,
but
we
technically
have
three
weeks,
and
so,
if
something
during
the
two-week
comment
period,
if
we
want
to
make
some
sort
of
change,
I
I
feel
like
we
should
use
that
time.
But
we
shouldn't
plan
on
using
that
time.
That
should
be
like
a
buffer.
A
D
Yeah,
one
of
the
other
things
outside
of
you
know
the
the
pull
request,
even
if
we
were
to
get
some
of
these
things
all
done.
Let's
say
the
miracle
that
we
we
all
we
pulled
this
off.
We
also
need
to
make
sure
that
comms
is
okay.
We
don't
want
to
rush
comms,
so
I
know,
we've
been
working
on
the
side
with
openssf
and
we
have
some
blogs
that
are
going
to
be
coming
out.
D
D
It
does
yeah
I
just
want
to
make
sure
that
you
know
we
we
have
I
know
Jennifer
I'll
have
to
find
a
date
for
Jennifer
bly's,
like
announcement
he's
like
April
17th,
or
something
like
that.
I
don't
remember,
but
we
can
probably
put
that
on
the
agenda
so
that
people
know
that
we
plan
to
have
openness
of
stuff
analysis
at
a
certain
time
and
that's
what
we're
aiming
for.
A
C
A
A
E
Oh
yeah,
there
are
actually
two
things
that
seem
to
be
controversial.
The
first
was
having
patch
versions
so
1.0.0
versus
1.0.
The
second
was
putting
some
sort
of
of
schedule
in
when
it
comes
to
patch
versions.
I,
don't
have
a
super
strong
opinion,
but
I
thought.
David
wheeler
said
that
they
are
common
in
the
open
ssf.
The
last
time
we
spoke
about
versioning
I
figured
there's
no
reason
to
be
special
as
to
a
schedule.
E
I've
been
trying
to
sync
up
with
I'm
blinking
I
think
it's
Melba
and
Joshua
on
on
the
timeline
on
the
roadmap
yeah
there.
It
is
in
the
chat,
add
to
the
salsa
road
map.
Having
a
release.
Schedule
is
nice
for
having
a
road
map
I
feel
like
they're
they're
kind
of
intertwined,
but
we
don't
have
to
put
that
on
the
on
the
specs
page.
A
A
G
G
C
So
I'll
I
I
think
I
kind
of
agree
with
Mark
I
mean
this
is
not
a
piece
of
software
and-
and
you
know,
a
lot
of
Standards
now
managed
in
the
live
way,
and
you
know
there's
things
like
leaving
standards
concept
where
you
know.
Essentially,
everybody
wants
the
letters,
the
thing
that
is
fixed
anyway,
the
bus
stop
to
date.
In
this
case,
if
we
don't
add
any
features,
we're
not
modify
salsa
we're
just
clarifying
things,
fixing
errors,
I,
don't
know
that
we
need
to
change
anything.
C
G
B
C
G
G
C
It
feels
like
there
is
a
distinction
in
the
sense
that
the
website
is
bigger
than
the
spec
right.
The
spec
is
only
one
or
there's
a
couple
of
specs
today,
but
there
are
different
subfolders,
but
if
you
I
mean
the
blog,
the
home
page,
the
we
have
a
community
page.
All
of
this
is
outside
the
specs,
so
you
can
spot
the
website.
G
But
like
I
I
guess,
I
was
thinking
in
terms
of
of
the
the
threat
model
and
and
any
kind
of
non-specification
or
anything.
That's
not
on
the
specification
page
itself,
that's
associated
with
the
specification,
while
it's
just
post
pushing
it
to
website,
still
feels
like
it
should
be
tied
to
a
specification
version.
A
A
I
So
I
don't
think
it
is
their
end
up
like
if
you
quote
a
web
page,
if
I'm
sorry
about
the
vacuum.
In
the
background
you're
supposed
to
put
the
date
that
you
copied
whatever
text
it
was
from
the
website,
if
you're
using
like
proper
citation
stuff
and
like
in
GitHub,
you
can
go
see
the
history
of
the
Page
by
looking
at
literally
the
history.
I
So
I
feel
like
to
your
point:
if
we're
just
making
minor
changes
that
don't
impact
the
actual
spec
like
it's,
not
a
change
that
anyone
would
really
notice
other
than
someone
comparing
two
versions
of
the
page
I'm,
not
sure
that
we
need
a
patch
version.
People
can
just
reference
a
date
if
they
need
the
festivals.
A
G
Anybody
looked
at
the
possibility
of
changing
from
the
directory
configuration
to.
Instead
a
branch
configuration
I,
don't
know
if
it's
possible
to
do
with
injectle,
but
then
it
it
could
flow
that
any
PRS
are
made
to
main
branch
and
then
on
whatever
this
Cadence
is
that
we
want.
We
can
submit
a
PR
to
the
version
branch
and
and
bump
the
version.
A
A
Yeah
yeah
I
mean
I,
really
just
like
how
we're
doing
it
now
like
it
I.
It
would
solve
a
lot
of
problems.
It
would
also
allow
us
to
change
it.
Would
that's
a
BL
like
a
necessary,
but
not
sufficient
step
for
changing
our
rendering
engine,
because
jet
we're
using
like
whatever
old
version
of
Jackal
GitHub
Pages
uses,
which
is
like
really
painful
to
write
templates
in
yeah.
I
As
a
side
note,
I
gave
a
talk
about
Plus
at
a
conference
recently,
and
a
lot
of
people
asked
like
how
do
I
participate
and
I
think
they're
terrified
of
just
going
into
the
issues
and
touching
something
I'm
wondering
if
we
could
take
some
of
these
items,
which
don't
necessarily
require
them
to
be
like
in
the
spec
and
understand,
like
all
the
impacts
and
tag
them
with
like
good.
For
someone
to
start
with
or
something
on,
some
requests
or
issues.
I
B
C
C
Point
Nicole,
I
I
can
only
support
that
I
thought
I
mean
you
know.
Mark
and
I
have
done
some
of
the
changes
that
really
just
UI
related
trying
to
get
the
website
a
bit
better
easier
to
maintain
the
content
and
stuff
like
this,
and
you
know
there
are
other
people
who
have
some
jkl
skills.
For
instance,
liquid
is
a
pain
in
the
butt
to
work
with,
and
so
if
there
are
people
who
are
more
experienced
they're
more
than
welcome-
and
there
are
things
like
this
version
selector
that
you
know
Mark
was
talking
about
earlier.
C
I
did
that
this
weekend
and
it's
kind
of
like
you
know,
there's
a
design
aspect.
They're,
probably
better
people
than
me
are
doing
graphical
design
for
websites.
So
if
some
people
have
this
kind
of
skills,
they're
more
than
welcome
to
come
and
help
us-
and
this
requires
no
knowledge
of
salsa
per
se
right.
A
H
C
So
there
is
a
one
thing
or
single
page
version
that
I
worked
on
that's
available
now
from
the
menu
and
I
was
thinking.
The
next
step
is
to
work
on
the
print
version
of
that.
To
that
you
could
you
know
there
are
ways
with
CSS
right
to
to
to
fine-tune
the
style
sheet
so
that
when
you
actually
print
that
page,
it
looks
better
but
or
maybe
use
some
tool
if
we
want
to
have
links
and
all
that
to
work.
C
H
B
A
A
A
I,
don't
know
if
Joshua's
here
I
don't
see
Joshua,
we
have
an
old
PR
from
a
couple
months
ago.
I
just
wanted
any
objection
to
closing
it.
I'm
just
trying
to
keep
the
list
of
pools
only
have
fresh
ones.
That
way
when
you
know
like
what
needs
to
be
reviewed,
it's
it's
the
one
on
the
conformance
program,
because
I
think
when
we
first
opened
it
we
we
thought
that
would
be
part
of
the
spec.
Now
we're
saying
it's
kind
of
like
outside
this
deck.
C
C
A
A
A
Yeah
and
I'll
just
ping
the
thread
and
if
there's
no
work
on
this,
then
maybe
we
just
close
it
and
then
reopen
it
again
when
work
resumes
on
it.
I
don't
know:
I
listed
a
couple.
Other
open
pull
requests
that
just
need
reviews
I,
don't
think
we
necessarily
need
to
discuss
them
here,
but
they're
just
yeah.
They
don't
think
they're.
Anything
controversial.
A
A
F
So
originally
they
were
going
to
separate
it,
but
I
think
it's
it's
simple
enough
to
just
have
the
one
blog
that
just
sort
of
describes
the
breadth
and
depth
of
salsa
and
then
saying
like
hey.
Why
did
we
start
to
split
up
like
because
I
think?
The
reason
why
we
split
it
up
is
is
not
the
long
enough
for
an
entire
blog.
It's
more
like
a
a
paragraph
or
two,
so
I
included
it
all
in
in
the
one
in
the
one
Vlog
article.
F
B
A
I
A
C
C
H
A
Yeah
I
think
I
think
it
is
very
useful.
I,
don't
I
did
not
tag
that
one
as
a
blocker,
because
I
think
no
it's
not
changed
later
and
it
would
be
fine
post
1.0.
It
wouldn't
require
Like
a
Virgin
bump,
but
yeah
I
do
think
it's
something
that
we
should
use
consistently
and
the
inconsistency
causes.
Confusion
like
I
see
it
a
lot
that
we
you
know,
for
example,
like
platform
versus
system
versus
service
process.
You
mentioned
a
bunch,
it
was
I
think
it's
good
feedback.
A
Yeah
and
I
think
they're,
like
the
next
step,
would
be
to
come
up
with
like
a
set
of
consistent
terms
like
ideally,
we
have
as
few
terms
as
like
you
know.
We
want
the
the
terms
that
we
need
and
know
more.
For
example,
there's
an
open
pull
request
that
Cara
just
sent
out
earlier
today.
I
think
that
result
here
we're
seeing
pull
request
is.
A
A
We
don't
use
maintainer,
except
in
this
very
limited
case.
We
don't
use
author,
except
in
a
very
limited
case,
so
I
think
we
need
to
do
the
same
thing
with
build
and
so
coming
up
with,
like
what
are
good
terms
for
that,
like
a
proposed
set
of
terms
and
in
avoiding
all
of
the
use
of
all
of
the
terms
except
for
those
would
be
would
be.
A
D
A
Feedback
is
actually
probably
more
actionable
than
than
others,
but
it's
still
not
like
a
list
of
changes,
changes,
changes,
changes,
changes
and
so
I
think
we
need
to
take
the
these
issues
of
like
well.
This
is
confusing
that's
confusing
and
synthesized
that
into
okay.
Here's
the
proposed
difference.
We
used
to
say
this.
We
now
would
say
this.