►
From YouTube: SLSA Tooling Meeting (March 17, 2023)
Description
Meeting notes: https://docs.google.com/document/d/15Xp8-0Ff_BPg_LMKr1RIKtwAavXGdrgb1BoX4Cl2bE4/edit#heading=h.yfiy9b23vayj
B
C
B
A
A
Yeah,
let
me
just
change
the
notes
just
so
that
folks
know
that
we
did
have
a
meeting.
It
just
did
and
ended.
Pretty
early
I
know
that
there's
there's
starting
to
be
this
like
all
day:
Soul
sub
1.0,
let's
squash
all
the
outstanding
issue
stuff,
so
I
was
probably
gonna
right
after
this
anyway
start
going
to
the
going
heading
over
to
that
meeting.
Oh,
it
looks
like
a
few
more
folks
might
be
joining,
but.
A
Yeah
so
I'm
also
looking
to
maybe
make
a
quick
and
dirty
sort
of
salsa
1.0
provenance
format,
validator,
probably
in
something
like
go,
but
I
was
looking
at,
maybe
updating
a
while
back.
I
had
made
one
in
queue,
the
Q
language
and
which
is
very
useful
for
this
sort
of
thing.
The
problem
is
Q
as
far
as
I
can
tell
still
doesn't
have
some
support
for,
like
certain
things
like
URL
validation
and
those
sorts
of
things.
A
A
Does
it
make
sense
to
just
pull
out
the
the
the
spec
elements
from
there
into
something
like
a
library
and
so
that
other
folks
can
just
sort
of
include
that,
without
necessarily
needing
to
include
the
entire
verifier,
because
for
some
folks
it's
just
like
hey
I'm,
generating
salsa,
Providence
and
I
just
want
to
know.
I
just
want
to
validate
that
I'm.
A
Actually,
following
the
the
spec
correctly,
which
is
always
we're
already
noticing
it's
it's
a
pretty
common
issue,
it's
like
even
with
like
spdx
and
Cyclone
DX,
a
lot
of
tools
that
are
generating
it
like
generate
mostly
conforming
to
the
spec,
but
they
miss
a
few
things
here
or
they
they
add
stuff
in
like
cert,
you
know
they
certain
types
don't
line
up,
which
then
leads
to
all
sorts
of
problems.
Downstream
for
for
clients
and
consumers,
foreign.
C
A
A
You
know,
one
of
one
of
my
primary
comments
to
the
to
the
creators
of
the
language
is
some
of
the
documentation
and
some
of
the
stuff
involved
in
it
feels
a
little
like
because
it's
it's
made
by
the
the
some
of
the
folks
who
made
the
Borg
configuration
language
for
Google,
and
it
feels
very
like
academic
in
some
spaces,
where
it's
like,
sometimes
I'm,
just
like
how
do
I
just
validate
a
URL
and
they're
like
well.
You
know
that
makes
it
impure
or
whatever
it's
like.
A
It
is
growing
in
top
popularity
because,
like
for
example,
istio
uses
Q
I
believe
to
generate
their
API,
some
others
use
it
as
well.
Fresca
uses
it
who
else
it
is
growing
in
popularity.
The
the
problem
is
I
think
it's
been
a
while,
since
there's
been
a
up,
not
an
update,
but
since
the
release
of
Hugh
so
they're
supposed
to
be
a
q,
0.5
I
think
coming
out,
but
yeah
like
there
is.
A
A
Obviously,
when
it
comes
to
a
language,
it's
a
little
different
than
I,
don't
know
just
like
a
a
little
tool
where
you
might
expect
a
little
tool
to
get
updated
every
month
or
something
like
that,
but
yeah,
it's
it's
I
also
does
it.
You
know
the
release
of
it
has
been
pushed
back
quite
a
few
times,
I
like
q,
a
lot
I
just
think
it
needs,
maybe
a
bit
more
TLC,
as
they
say,
especially
around
documentation.
Their
documentation
is
is
not
particularly
great.
A
Yeah
well
it's
funny
because
in
what
was
it
cubecon
in
last
year,
you
know
kubecon
North
America
in
Detroit
they
had.
You
know
they
had
somebody
who
was
like
Hey
I'm
now
the
head
of
community.
What's
the
biggest,
you
know
things
that
you
want
everybody's
like
better
documentation,
better
examples,
better
yeah,
yeah
and
I.
Think
they're
prepping.
All
of
that
for
the
0.5
release.
A
C
A
A
C
A
A
Think
the
big
thing
is
is
more
like
not
necessarily
the
language,
that's
important,
just
making
the
the
the
usability
for
the
end
user
simple
and
whether
the
backing
thing
is
q
or
something
else
is,
is
sort
of
whatever
to
me.
You
know
just
I
think
for
the
the
end
user.
The
the
thing
that
we
want
to
make
sure
is,
we
don't
want
end.
A
Users
have
to
have
to
say:
hey,
I
wrote
a
bunch
of
tecton
config,
plus
a
bunch
of
kiverno
config,
plus
a
bunch
of
you,
know,
spiffy,
spire
and
and
Vault
config
and
so
on
and
so
forth.
If
there's
some
way
to
say
like
the
the
big
goal
is
to
say
it's
all
one
Deployable
unit,
you
know
so
that
when
somebody
comes
up
with
a
new
pipeline
or
whatever
it's
not
like,
they
have
to
think
about
these
50
things.
A
A
So
no
no!
This
is
not
the
old
day
meeting.
There's
supposed
to
be
an
all-day
meeting
for
specification.
Mark
is
supposed
to
send
some
stuff
out,
but
he
just
said
something
a
couple
of
minutes
ago
saying
that
he's
not
feeling
well
today,
so
he
might
take
the
day.
So
maybe
not
today,
but
but
today
this
is
just
the
the
salsa
tooling
piece.
His
thing
was
more
the
specification
stuff,
and
so
we
wanted
to
squash
some
of
that.
A
There's
another
thing
just
around
looking
at
like
either
taking
some
of
the
stuff
from
the
existing
like
salsa
verifier,
that
we
have
or
similar
and
just
pulling
out
the
actual
validator,
the
validation,
the
format,
spec
validation,
piece
into
something
like
its
own
Library,
so
that
we
can
so
that
folks
can
just
sort
of
like
import
that,
as
opposed
to
you,
know,
there's
a
couple
of
different.
Like
libraries
out
there.
A
A
So
the
release
of
1.0,
so
this
is
the
tooling
meeting.
So
this
is
just
more
around
like
coordinating
with
the
the
folks
who
are
building
salsa
tools
to
make
sure
that,
like
are
you,
you
know,
salsa,
compliant
and,
and
also
saying,
like
you
know,
developing
stuff
like
hey.
Can
we
help
with
some
of
the
folks
who
are
building
like
salsa
distribution
mechanisms
and
yayada
like
what
can
we
do
on
that
front?
A
A
It's
looking
for
feedback,
we've
gotten
some
feedback,
and
so
the
only
thing
that's
really
stopping
us
from
release
is
just
waiting
for
the
rest
of
the
feedback
and
clearing
up
a
couple
of
you
know
things
mostly
around
folks
who
are
like
a
little
on
like
to
some
language.
That
might
be
a
little
unclear
that
we
just
need
to
make
more
crisp.
A
Github
officially
supporting
salsa
I
know,
there's
some
discussions
about
like
salsa,
just
being
something
that
could
be
inside
of
the
GitHub
system
itself,
as
opposed
to
it
being
part
of
the
GitHub
reusable
workflow,
because
we
have
a
bunch
of
reusable
workflows
and
that
hits
the
salsa
requirements.
But
there
is
sort
of
conversation
about.
A
Yeah
and
that's
there's
a
there's,
a
tracking
issue.
So
in
the
in
these
notes,
Here
there
is
a
a
tracking
issue:
574
in
salsa
and
in
574
there
is
a
npm
CLI
6268,
which
is
the
one
that
is
supposed
to
track.
You
know
some
of
this
supporting
salsa
1.0
inside
of
npm's
CLI,
yeah,
yeah,
so
I
and
and
on
that
front
I
think
the
main
thing
is
just
yeah:
we've
been
reaching
out
just
to
see
like
hey.
Is
there
anybody
who
needs
any
help
with
anything?
A
A
Yeah
yeah
and
beyond
that,
there's
not
a
whole
lot.
I
think
the
idea
was
also,
if
there's
other
tools
that
folks
wanted,
they
could
definitely
sort
of
throw
stuff
in
the
notes,
and
then
we
can
see
you
know
if
anybody
has
any
time
to
work
on
them
or
or
if
there's
features
that
are
in
the
official
salsa
stuff
that
or
rather,
if
they're
feature
requests
or
bug
fixes
or
whatever
in
the
official
salsa
tools
like
the
GitHub
workflow
and
some
of
those
things
we
can
work
on
that
as
well.
C
That's
actually
been
a
problem
with
this.
Is
you
know?
How
do
we
position
it
because
you
talk
about
the
GitHub,
so
there
is
this.
You
know
GitHub
action,
salsa,
generator
thing
and
I
expect
that
eventually,
Gita
will
Define
their
own
way
of
doing
this,
and
maybe
it
is
also
an
action
that
you
can
just
use
and
then
it's
like:
what's
the
status,
how
do
you
explain
to
people
which
is
which
and
cool?
So
we
have
to
be
careful
how
we
position
those
things,
because
if
there
is
one
from
GitHub
that
will
be
the
official
one?
C
A
Yeah
we,
we
might
have
a
couple
of
implementations
and
examples
of
things
but
they're
not
necessarily
like
we.
We
don't
want
folks
to
think
that
this
is
the
one
way
of
of
doing
it
and
in
fact
there
might
be
multiple
ways
and
in
fact
there
might
be
even
within
GitHub
right.
Github
might
have
some
sort
of
like
you
know,
I'm
just
saying
like
GitHub
might
say:
hey
our
our
official
mechanism
is,
you
know
only
for
Enterprise
customers
or
whatever,
but,
like
you
know,
there
might
be
lots
of
different
ways
of
of
going
about
that.
B
C
Sense,
there's
another
one:
that's
like
marked
as
contributed
one
for
the
cloud
build
and
the
Google
Cloud.
Yes,
yes,
what
I
discussed
it
with
him
like?
What's
the
status
of
this
should
be
in
Google
and
it's
like
well,
it's
just
my
thing:
I
haven't
I,
don't
know
they
even
approve
it
in
Google,
Cloud,
yeah,
there's
a
so
it's
the
same.
Eventually
yeah.
B
C
B
A
D
A
We
don't
want
to
give
folks
the
wrong
thought,
because
yeah
there's
I
know
some
folks
have
already
said.
Hey
some
folks
have
said
they
can
use
the
official
GitHub
actions
stuff
that
is
officially
maintained
by
GitHub,
but
they're
not
authorized
to
use
anything
yeah
yeah,
and
so
it's
like
I
I,
get
that,
but
there's
also
a
thing
of
hey.
A
A
An
end
user
can
use
in
order
to
interact
with
salsa,
which
is
is,
is
also
complicated,
because
some
folks,
right,
like
the
the
whole
thing
with
Fresca
right
is,
is
tecton
and
tecton
chains.
If
you
use
it,
the
correct
way
gets
you
up
to
salsa
too,
adding
in
spiffy
Spire
gets
you
to
salsa
three,
but
for
a
lot
of
folks,
it's
like
well,
oh,
does
that
mean
tecton
is
salsa
three
well
no
tecton,
plus
this
plus
this
configured
the
right
way
is
also
three
okay.
A
So
it
didn't
sign
anything,
and
so
it's
actually
only
salsa
one,
but
that's
on
the
end
user
to
say
hey,
and
so
how
do
you
sort
of
wrap
that
all
up
and
say?
Well,
no,
this
is
a
salsa
3
build
system,
and
so
it's
not
just
using
GitHub
actions
or
this
that
and
the
other
thing
it's
using
it
in
this
way
means
it's
also
three
or
salsa.
Two.
A
You
know
we're
saying
no,
no,
we're
keeping
this
our
scope,
small
and
then
expanding
out
a
little
bit
on
the
fringes
to
say
what
are
the
inputs,
what
are
the
outputs
and
doing
that
sort
of
thing
to
say
security,
but
anyway
doing
some
stuff
on
that
end,
and
then
one
of
the
other
things
is
writing
up
a
Blog
on
hey.
What
does
what
does
what
it
wrote?
A
What
really
is
a
salsa
build
system
and
trying
to
say
that
hey,
it's
actually
and
and
the
the
definition
does
a
good
job
of
it.
I
think
the
definition
does
a
good
job
of
explaining
it
to
folks
who
understand
a
lot
about
build
systems,
but
they
don't
do
a
very
good
job.
At
explaining
it
to
folks
who
are
just
like
hey,
I'm,
an
end
user
of
this
thing,
I
just
like
can
I
just
use
my
Jenkins
and
it's
like
well.
A
C
A
A
A
Oh
no,
it's
it's
maintained
by
azra,
who
I
believe
is
no
longer
on
that
team,
but
I'll
double
check
and
also
Ian,
and
the
problem
is
Ian
Works
in
Japan.
So
getting
gay
there's
like
about
an
hour
or
two
each
day
that
that
there's
any
sort
of
overlap.
So
it's
not
the
easiest
to
get
a
hold
of
him,
because
I'll
look
through
here
and
see
if
there's
some
way
that
we
can
pull
out.
Some
of
this,
oh
it
looks
like
Laurent,
is
also
working
on
it.
I
can
reach
out
to
him.
A
This
is
how
you
distribute
salsa
from
a
pack
for
for
packages,
but
I
think
if
folks
largely
follow
similar
practices,
or
at
least
the
majority
of
them
follow
similar
practices.
Then,
when
folks
come
in
with
clients
for
like
verifier
things
and
they
say,
hey
I
want
to
pull
I
want
to
pull
down
all
attestations
associated
with
this
package
in
gem
or
Pipi.
We
don't
want
to
have
the
right
completely
different
code
and
logic
to
to
do
that.
A
We
want
to
just
be
able
to
say:
I
should
be
able
to
look
up
this
on
this
end
point
and
be
able
to
pull
that
in
hopefully,
so
that's
kind
of
I
think
the
way
we're
trying
to
to
do
that,
but
that's
going
to
probably
based
on
some
conversations.
Nobody
has
enough
time
to
do
it,
so
I
might
need
to
come
in
with
like
here's
like
a
mostly
baked
spec
or
mostly
base
baked
best
practices,
and
can
folks
just
follow
that
and
go
from
there.