►
From YouTube: SLSA Specifications Meeting (September 19, 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
A
C
Evidently,
there's
two
different
microphones
on
my
system
and
for
some
reason,
I
picked
up.
Okay,
perfect
all
right!
Well,
thanks
for
pointing
that
out.
C
So,
as
a
reminder,
please
sign
in
to
the
well
first
welcome
everyone
please
sign
in
to
the
attendance
list,
I'll
re-paste
in
the
chat
for
anyone
who's
joined
recently
and
a
reminder
that
I
by
joining
here
we're
agreeing
to
abide
by
the
salsa
frameworks.co
code
of
conduct.
C
I
only
have
one
quick
agenda
item
around
like
the
main
use
cases.
I
haven't
made
any
progress
on
the
1.0
spec
this
week.
I
was
busy
with
other
things.
Does
anyone
else
have
any
topics
to
discuss
foreign.
A
Yeah
I.
Actually,
this
is
Marcella
here.
I
actually
wanted
to
talk
a
little
bit
about
maybe
roadmap
and
sort
of
timeline
of
yeah.
Just
when
we
expect
to
have
a
draft
ready
versus
more.
Maybe
it's
too
early,
but
just
add
that
to
the
agenda,
if
possible,
I
wasn't
sure
where
to
add
it
sounds
good.
A
I
think
I
just
really
wanted
to
clarify
whether
or
if
when
we
get
thinking
about
doing
a
triage
on
the
open
issues
on
the
spec
to
see
whether
there
was
anything
that
we
wanted
to
address
left
for
1.0.
C
Okay,
so
the
the
first
topic
I
wanted
to
just
briefly
ask
about.
Was
we
currently
have
a
salsa
that
the
Slash
use
cases
I'll
link
to
it
in
the
meeting
notes
and
I'll
paste
it
here
for
convenience
in
the
chat,
and
we
call
out
three
main
use
cases
of
first
party,
where
you're
just
using
salsa
just
as
a
guideline?
C
No
one
is
verifying
that
you're
doing
it
you're
just
doing
it
for
your
own
reasons,
then
we
have
until
you
can
kind
of,
take
it
or
leave
it
as
you
want.
Then
we
have
open
source
and
where
you
are
reducing
risk
from
consuming
open
source,
and
then
we
have
vendors
where
you're
reducing
risk
from
some
third-party
vendor
usually
closed
Source.
C
The
reason
why
I
right
now
we
just
have
that
separate
page,
and
we
kind
of
mentioned
it
during
conversations.
But
it's
not
really
part
of
the
spec
I
was
wondering
if
anyone
had
thoughts
on
kind
of
threading
that,
through
the
spec
more
directly,
because
in
some
cases
we
have
kind
of
Divergence
between
what
works
in
open
source
and
what
works
in
closed
source.
C
If
not
that's
fine
I
was
just
figured
I'd
raise
it.
Michael.
B
Yeah
I
think
I
agree
with
you
that
it
should
be
a
little
bit
more
highlighted
either
directly
in
the
spec
or
somehow
threaded
through
there,
because
it
seems
to
be
a
fairly
consistent
problem,
which
is
like
exactly
where
the.
What
use
cases
me,
what
things
and
you
know,
are
there
certain
requirements
that
are
really
only
applicable
to
the
open
source
use
case
versus
the
vendor,
one
versus
internal
and
in
in
many
ways,
I
think
the
it's
also
I
think
a
little
unclear
to
folks
on.
B
You
know
how
they're
supposed
to
you
know,
because
I
think
to
take
a
step
back.
I
know.
One
of
the
big
things
is
also
from
where
the
use
cases
are
split
up
between
stuff,
like
foreign
service
provider
versus
the
person
who's
running
a
build,
and
things
like
that
that
are
just
I
think
need
to
be
made
a
little
bit
more
clear.
C
C
Okay,
that
that
that's
fine
when
we're
doing
the
spec,
we
could
just
maybe
think
about
this
as
a
possibility
for
calling
out
so
Marcela
on
the
the
road
map
you're.
Talking
about
like
further
down
the
line.
A
Yeah
just
I
mean
some
of
this,
and
and
thanks
for
putting
in
the
agenda
some
of
this
I
guess,
line
of
questioning
is
coming
also
just
like
internally
from
my
end,
is
just
to
get
an
idea
of
sort
of
what
the
expectation
is
for
when
you
might
have
a
draft
of
1.0
ready
to
yeah
start
looking
at
working
with
and
yeah
just
kind
of
in
general
I
I
looked
around
the
GitHub
issues
and
I
think
even
the
1.0
Milestone
doesn't
have
a
date
on
it.
Quite
yet.
A
So
that's
kind
of
just
why
I
was
bringing
this
up
is
now
that
the
spec
is
starting
to
crystallize
a
little
bit
more
yeah.
If
we
can
maybe
align
on
sort
of
a
fee
I'm
not
saying
we
need
to
sort
of
decide
the
entire
roadmap,
but
just
sort
of
maybe
start
to
yeah
just
decide
on
certain
Milestones
on
even
for
the
draft,
maybe
or
yeah.
C
C
Yeah,
that's
a
good
idea,
so
in
terms
of
Milestones
I
think
like
one
would
be.
C
C
Breaking
it
up
so
that
for
like,
like
we
or
the
site,
so
that
we
can
develop
1.0
because
I
feel
like
oh,
for
example,
1.0
branch
I
think
would
be
a
first
step
to
give
us
a
common
place
to
do
that,
and
and
I
can
try
to
do
that
next
week.
Maybe.
C
There's
going
to
be
actual
development
work
which
will
have
different
pieces
in
it,
and
then
we
will
be
what
kind
of
review
and
approval
process
or
like
ratification
process
so
like
on
the
tail
end.
We
figured
that
would
take
what
how
many
weeks
do
you
think
once
figure
once
we
have
a
draft,
we'll
probably
want
to
wait
several
weeks
before
we
stamp
it
as
official.
C
Maybe
four
weeks
so
development
work
on
the
draft
itself.
I
would
imagine
I
guess
one
question
is
like:
can
we
split
it
up
somehow
like
to
have
more
than
one
more
person
working
on
it.
A
Oh
I
was
just
gonna
agree
with
you
and
I'm
absolutely
able
to
take
on
this
section.
If
that's
what's
needed,.
C
Yeah
so
I
think,
like
that
figuring
out
how
we
can
do
like
splitting
that
up
and
like
the
high
level
of
like
what
changes
do
I
want
to
make
I
think
it's
I
guess
we
have
like
high
level
changes
to
the
spec
because,
like
reorganizing
stuff
and
then
there's
wording,
changes
and
those
are
I.
Think
pretty
orthogonal
like
a
lot
of
the
issues
on
the
on
the
issue.
Tracker
are
issues
with
particular
items
and
that
probably
is
going
to
just
be
moved
over
in
bulk.
C
So
maybe
we
could
split
it
up
that
way
of,
like
so
like
in
Branch
or
1.0.
It's
similar.
A
C
C
First
also
four
rename
levels
Etc
and
then
low
level
changes
from
the
issue.
Tracker
I
think
these
two
probably
could
be
happen
in
parallel.
C
Maybe
we
shoot
to
have
a
draft
in
mid-october,
realistically
speaking
initial
draft
and
then,
if
we
figure
there's
going
to
be
a
four
week
long
review
process,
that's
maybe
mid-november.
B
Michael
yeah,
no,
that
sounds
good
and
I
think
we
should
regardless
I
think
what
we
should
do
is
not
have
a
full-blown
announcement,
but
at
least
talk
about
you
know
for
the
folks
who
are
going
to
be
there
at
kubecon.
Make
sure
that
folks
are
hey
aware.
Like
you
know,
salsa
is
prepping
for
1.0
there's
a
draft
out,
and
so
that
folks,
like
know
that
this
stuff
is
coming
down
the
the
line.
C
A
C
Okay,
I
mean
considering
how
the
the
pace
of
this
that's.
This
might
be
optimistic,
but
I
think
it's
probably
good
to
shoot
for
that
as
a
goal
and
then,
as
things,
get
pushed
back
or
delayed
I
think
we
really
want
to
have
this
by
end
of
the
year.
C
I
think
there's
a
strong
desire
by
everyone
to
have
like
this
finalized
by
the
end
of
the
year,
and
so,
if
we
work
on
getting
the
draft
done
within
the
next
month,
and
then
you
know
iteration
and
approval
and
everything
within
the
within
the
following
month,
that
sounds
good.
C
Okay,
should
we
move
on
to
triaging
open
issues.
A
C
Really
annoying
yeah
125
is
a
lot,
so
if
we
can
always
like
bucket
them
into
you
know,
definitely
not
definitely,
yes,
and
maybe,
as
a
first
pass.
C
Maybe
we
could
just
like
right
here
just
go
quickly
through
there's,
probably
a
lot.
We
could
look
just
from
the
title.
It's
also
a
requirement
for
automation.
I'm
guessing
is
in
without
knowing
what
is
is
in
the
maybe
category
or
like
requires
further
consideration
at
least
diagram
sure
how
the
stations
are
generated.
Mike
filed
that
one,
you
think
it's
for
the
1.0
spec
or
now.
B
So
I
do
think
I'm
thinking
about
it
holistically
of
what
we
should
make
sure
is
available
by
1.0
I
think.
Yes,
we
need
to
have
some
of
that
for
for
1.0
and
just
to
kind
of
I.
Don't
want
to
harp
on
it
too
much.
But
one
of
the
things
that
kind
of
came
out
was
like
when
we
go
to
1.0.
We
want
to
make
sure
that
we
have
some
reasonable
documentation
on
stuff
like
patterns
and
how
the
tools
should
be
used
and
or
even
implemented,
not
implemented.
B
Sorry,
how
tools
should
be
designed
right
so
that
with
the
spec
in
mind,
so
that
folks
sort
of
are
hitting
the
spirit
of
the
law
as
well
as
the
letter
of
the
law,
because
I
think
there's
been
some
confusion
on
some
of
the
tools
and
some
of
the
ways
that
people
have
been
sort
of,
let's
say:
generating
salsa
attestations
where
they're
like
oh
I'm,
salsa
compliant,
and
it's
like
not
really
so
I-
think
that
we
just
need
to
make
sure
that
that
is
is
available
for
1.0.
A
All
right
sounds
good.
This
one
I,
don't
even
remember
that
one
was.
C
C
Actually,
I
don't
actually
I
should
undo
anyone
that
I
already
did,
because
we
didn't
do
that
in
this
group.
So
I
don't
want
to
unilaterally
say
that
so
maybe
just
two
tags,
one
for
maybe
1.0
and
one
for
definitely
and
then
as
if
it's
missing
the
definitely
tag,
that's
effectively,
something
that
we
haven't
decided
yet
and
we
can
either
remove
the
tag
or
or
or
otherwise.
C
So
it's
probably
generate
that.
Definitely
not
provenance
1.0.
No,
no
I'm
going
to
call
the
Providence
ones
out
of
scope
just
because,
just
as
to
limits
go
up
here,.
C
Address
it
for
yeah
that
sounds
good,
we'll
we'll
defer
that
one
positioning
positioning
dependency,
dashboard
mapping
between
provenance,
that
is
I,
would
say.
Yes,.
C
I
think,
like
this
one
I
think
will
probably
be
like
this
will
be
a
future
level
four
thing,
so
the
decision
will
be
but
I
want
to
discuss
it
with
the
group.
First.
A
I
don't
know,
Gmail
does
not
work,
okay,
which
ones
did
I
check.
I
was
so
worried
about
that
before
you
click
next.
C
C
See
like
even
the
actions-
oh
that's.
C
Oh,
this
one
works
now
all
right
mitigation
for
compromise
package,
repo
threat,
that
sounds
out
of
scope.
A
Yes,
yeah
reproducibility
is
important
level.
Four
yeah.
A
C
C
A
C
We
might
want
to
like
bucket
these
as
like
a
things
that
aren't
necessary
for
the
1.0,
but
that
we
do
want
to
do
quickly,
just
for
prioritization
reasons,
but
at
least
if
we
could
bucket
them
now.
So
we
don't
have
to
go
through
125.
A
C
Right
I'll
do
the
same
thing:
I
did
before
stop
sharing
share
the
new
tab.
C
A
A
A
All
right,
yeah
I'll,
do
that
right
now,
thanks
for
doing
that,.
C
C
Okay,
so
we
are
those
that
Pages
good
and
by
the
way,
obviously
it's
a
shout
out
if
you
see
anything
that
you
disagree
with
to
find
more
cases
review.
This
merges
a
two-person
review
out
of
scope.
A
B
A
C
I'll
put
it
on
to
discuss
platform
versus
project
configuration.
C
Oh,
this
one's
about
the
versioning,
so
I'm
going
to
include
it
because
we
talk
about
versioning.
C
C
C
A
A
A
C
C
A
C
C
Yeah
yeah
like
do,
would
it
be
helpful
for
folks
to
say,
like
oh
this
shouldn't
or
should
I
I
think
if
anyone
wants
to
go
through
and
like
tag
them,
just
let
me
know
and
I
could
just
grant
you
permissions
in
the
github.org
or
in
the
repo
I
think
you
just
have
to
be
marked
as
a
contributor
or
something
like
that.
So,
if
anyone's
willing
to
do
that
to
clean
up
these
labels,.
A
A
Taking
the
time
to
kind
of
wander
through
them
and
comment
on
them
and
then
maybe
discuss
those
that
are
contentious
next
week,
there's
the
there's
a
question
of
whether
or
not
we
want
to
resolve
them
and
then
there's
a
resolution.
C
Yeah
foreign.
C
I
think
there's
also
the
like
the
prioritization
between
them.
You
know
because
if
we
don't
have
time
to
address
all
of
them,
which
one
should
we
do
I
wish,
we
had
a
way
to
add
like
metadata
here:
I
guess
what
I
could
do
is
just
extract
these
all
to
a
spreadsheet,
and
then
we
could
just
like
tag
stuff
there
you
like
sort
it
that
way
and
kind
of
sort
by
priority
or
something
would
that
be
valuable.
I,
don't
know
I,
guess
yeah
as
a
first
pass.
C
Let
me
add
this
one
page
that
I'm
missing
for
the
labels.
I
couldn't
get
working
and
then.
C
If
you
could
comment
on
them,
if
you
think
like
either
they
should
be
in
1.0
or
they
should
not
be
in
1.0
or
something
about
the
resolution.
I
think
that'll
probably
be
valuable,
and
then
we
can
come
up
with
like
a
perspective
list
for
next
week
and
then
just
say:
does
this
look
good?
Does
everyone
agree
with
like
this?
Is
the
cut
that
we're
making
I'll
use
the
Milestone
as
the
potential
cut
I'll
just
Mark
everything?
C
C
If
you
could
go
through
and
just
review,
what's
already
in
there
to
see,
if
there's
anything
you
disagree
with
and
then
we
could
pull
that
out,
that's
probably
more
efficient
than
like
boating
on
every
single
one,
and
if
you
have
thoughts
on
like
how
to
actually
resolve
any
of
them,
that
would
be
good,
too
I.
Think
in
in
the
meantime,
before
we.
C
You
know
actually
have
the
new
branch
and
like
whatever
refactoring
we
need
in,
like
the
markdown
format,
I
think
a
lot
of
the
work
here
is
really
going
to
be
about
wording
and
content,
and
so,
if
we.
C
Actually,
how
about
this
for
for
a
process?
C
Why
don't
we
create
a
branch
that
where
we
just
edit
the
spec
in
place,
even
though
it's
under
the
0.1
directory
and
then
we
could
make,
we
could
review
wording
changes
there,
and
then
we
could
the
refactor
into
like
separating
by
use
case
or
whatever
we
could
do
separately,
but
that
will
hopefully
unblock
things
and
allow
us
to
make
like
make
independent
progress
on
most
of
these
issues,
which
were
designed
with
the
current
format
in
mind,
does
that
make
sense?
First
of
all,.
A
That
makes
sense
so
basically
go
ahead.
Aaron
that
does
make
sense,
just
to
you
know,
get
some
work
done
on
it,
even
though
it
technically
like.
C
Yeah
and
I
feel
like
we
could
I
mean
we
could
either
do
that
through
a
branch
or
Google
Docs
I
would
be
inclined
to
do
the
branch
I
mean
there's
drawbacks
to
each
one.
You
have
to
edit
and
mark
down
and
it
might
not
be
easy
to
merge.
The
other
is
like
a
kind
of
more
closed
system
and
the
history
is
harder
to
see.
C
I'd
be
inclined
to
do
the
to
do
the
branch
and
then
like.
We
actually
will
make
commits
on
that
branch
and
do
pull
requests
but
to
the
branch
instead
of
to
Main.
A
Yeah
I
agree,
I
I
just
wanted
to
to
say
actually
another
idea
could
be.
You
know
to
have
like
two
branches
like
for
one
for
high
priority
things.
Maybe
the
second
one
for
low
priority
things.
I
mean
I
I,
guess
that
in
some
cases
you
know
like
for
a
rewarding
of
phrases
of
sentences.
Maybe
it's
gonna,
be
you
know,
maybe
you
can
have
like
some
some
difficulties
while
merging
into
the
same
Branch.
While
if
you
keep
two
priority
levels,
maybe
it's
even
easier
I,
don't
know
just
just
a
proposal.
A
Yeah
for
the
review
process.
It's
definitely
the
same
note
that
maybe
you
know
when
it's
about
so
I,
guess
that
at
some
point
we
are
we'll
assign
some
priorities
to
the
issues
that
we
have
to
fix
and
to
the
things
that
we
want
to
integrate.
So
my
idea
was
okay,
even
though
the
the
review
process
is
the
same,
then
we
can
like
dedicate
some
to
separated
branches
and
for
high
priority
tasks
and
one
for
low
priority
tasks.
A
That
can
be
a
solution.
Maybe
I
was
not
meaning
actually
this,
but
it's
okay,.
C
A
C
A
A
C
Yeah
I'd
like
to
actually
refactor
the
implementation,
so
we
could
just
develop
per
Branch
instead
of
having
per
directory
and
then
we
would
allow
that.
But
that's
like
a
that's
orthogonal
to
this.
So
all
right.
So
so,
let's
any
other
thoughts
on
that
I'm,
leaning
towards
that
just
create
another
directory.
For
now,
with
a
warning
that
is
draft
and
all
of
the
edits
that
we
have
now
they'll
go
through
the
same
process,
we've
done
before
you
merge
it
into
main
just
on
the
1.0
directory
and
then
in
terms
of
the
refactoring
stuff.
C
That
part
like
the
major
structural
change
can
occur
on
a
branch,
but
the
kind
of
one-off
pull
requests
around
wording
and
clarifications
can
just
happen
in
the
directory
and
then
we'll
just
merge.
It.
A
Yeah
I
think
the
only
other
thing
in
the
comment
I
have
is
a
question
is,
is,
are
we
are
we
covering
everything,
I
mean?
Should
we
treat
the
issues
less
as
our
kind
of
list
of
work
items?
Have
we
got
anything?
That's
that
we're
currently
considering
working
on
or
actually
working
on?
That's
not
currently
tracked
in
an
issue.
C
The
only
thing
I'm
aware
of
is
the
stuff
that
was
in
the
dark
which
I
could
I
can
make
an
issue
for
so
where's.
The
notes
so
is
issue
tracker,
a
complete
I
think
if
there's
anything
that
you
know
of
that
should
be
in
there
file
an
issue
again
that
one
page
of
issues
I
still
haven't,
there's
ten
issues
that
I
haven't
moved
over
to
that
tag.
C
Yet
because
I
have
to
figure
out
how
to
do
it
without
losing
all
of
my
progress
again
and
then
there's
the
no
one
missing
ones.
Mark
will
add
ones
for
the
for
the
doc.
For
the
proposal.
C
So
there's
like,
if
you
go
back
to
the
zoom
page
on
the
your
screen
sharing
in
order
to
unmute
yourself,
you
have
to
have
it
look
like
a
mute.
It's
like
awkward
ux,
so.
C
Thanks
for
keep
telling
me
that,
so
everyone
go
through
the.
A
A
A
C
If
anyone
wants
to
work
with
me
on
that,
let
me
know
I
think
that's
the
type
of
thing
where
it's
like,
probably
in
a
big
group
like
this,
it's
not
very
useful
but
like
one
or
two
or
three
people
kind
of
discussing
and
iterating
is
probably
useful.
So
if
anyone's
interested
in
that,
let
me
know.
C
A
C
Okay,
any
other
things
to
go
to
say
before
we
leave.
C
Sure,
thanks
for
everyone's
contributions,
this
is
this
is
good
all
right,
so
we'll
discuss
I,
guess
online
and
I'll
see
everyone
next
or
at
the
next
meeting
or
next
week.