►
From YouTube: SLSA Tooling Meeting (May 19, 2023)
Description
Meeting notes: https://docs.google.com/document/d/15Xp8-0Ff_BPg_LMKr1RIKtwAavXGdrgb1BoX4Cl2bE4/edit#heading=h.yfiy9b23vayj
A
A
B
All
right,
I
guess
we
can
get
started
here,
probably
be
a
a
quick
one,
because
I
think
most
of
us.
The
feedback
has
been
regarding
some
of
the
GitHub
stuff,
but
so
just
as
a
reminder,
this
meeting's
being
recorded
it'll
be
uploaded
to
shoot
yeah
YouTube
shortly
after,
and
your
participation
in
this
meeting
is
an
agreement
to
abide
by
the
open,
ssf
code
of
conduct
all
right.
B
So
the
only
thing
I
had
on
the
agenda
was
just
you
know,
going
over
open
source,
Summit
North
America
feedback
specifically
around.
Like
the
stuff
we
heard
about
some
of
the
tooling
coming
out
of
salsa,
but
if
anybody
else
had
any
other
agenda
items,
they
wanted
to
add
feel
free
to
add
it
on
there
as
well.
B
So
I'll
just
go
quickly
and
then
I'll
open
it
up
to
the
floor.
So
most
of
the
feedback
got
on
salsa.
The
salsa
1.0
stuff
was
was
really
good.
The
stuff
you
know,
there's
a
lot
of
different
things
about
the
spec
and
some
things
that
can
maybe
be
clarified
or
additional
examples,
and
and
that
kind
of
a
thing.
B
If
there's
you
know,
if
there's
any
updates
anything
that
they're
they're
working
on
on
that
end,
because
yeah
I
think
I
know,
one
of
the
big
things
is
like
Hey
we're
doing
all
this
stuff
with
1.0.
If
we
don't
have,
if
folks
are
not
using
V1
of
the
spec
like
it,
you
know
how
like,
what's
that
sort
of
Journey
look
like
how
do
we
make
sure
that
we
also
don't
confuse
people,
because
people
might
look
at?
Oh,
it's
v0.2
of
the
spec.
B
That
means
they're
not
using
V1
of
the
requirements,
and
that
might
not
be
the
actual
case.
We
want
to
make
sure
that
we
can
sort
of
clear
up
some
of
that
that
confusion
and
if
we
can
get
V1
support
sooner
rather
than
later
it
would
be
great
and
then
the
second
piece
was
a
lot
of
folks
were
asking
for
something
along
the
lines
of
you
know
test
examples
of
sorts
of
attacks.
You
know
the
salsa
could
prevent
to
help
with
testing
of
salsa
tooling.
B
B
So
this
was
something
like
some
folks
were
saying:
hey
I,
think
I
built
something
that
is
salsa
conformant,
I'm,
not
sure
and
I,
don't
know
how
to
actually
like
what
sorts
of
attacks
could
you
know
what
is
an
example
attack
that
somebody
could
run
against
this
build
system
that
this
should
detect,
prevent
yeah
yeah
provide
you
know,
we'd
have
the
data
around
so
that
that
was
another
thing.
That's
that
folks,
there
were
asking
about.
A
B
B
Cool,
if
there's
nothing
else
on
the
open
source,
North
America
side,
what
other
agenda
items
did
folks
have
regarding
salsa
tooling,
as
you
know,
as
a
reminder,
we're
open
to
you
know
whatever
open
source
salsa
tooling
folks
have
been
building.
If
folks
have
questions
around
integrating
the
tooling
or
using
the
tooling
or
generating
new
tooling.
You
know
this
is
a.
This
is
the
place
for
it.
C
B
Oh,
no,
no
anybody
can
so
we're
building
a
conformance
program.
So
if
you
publicly
state
that
your
your
tool
is
salsa
conformant,
the
idea
would
be
you
would
provide
either
a
self
attestation
or
you
would
provide
proof.
Vienna
auditor.
That
said
you
know,
yep
I,
looked
at
their
build
system
and
I
believe
it
to
be.
B
You
know
doing
those
you
know
doing
those
things
and
like
with
some
human
readable,
like
content
as
to
why,
right,
because,
even
with
the
GitHub
actions
right,
if,
for
example,
GitHub
itself
was
not
doing
the
right
things,
it
wouldn't
matter
that
there's
a
workflow,
a
reusable
workflow
right
like
that,
the
trust
doesn't
come
for
that
reusable
workflow.
The
trust
comes
from
a
couple
places.
B
One
is
that
the
GitHub
like
actions
platform
right,
is
doing
the
largely
the
right
things
from
a
security
perspective
and
then,
secondarily,
in
order
to
prevent
right
like
because
you
know
the
workflow
is
needed,
because
people
are
the
the
workflow
is
needed,
because
GitHub
itself
does
not
have
built-in
sort
of
salsa
support
like
if
GitHub
as
the
actions
platform
had
built-in
salsa
support
that
when
you
run
a
build
it
automatically.
You
know
injects
salsa
Providence.
That
would
be
good
enough
as
well.
B
So
you
get
that
as
well,
and
once
again
this
is
based
on
assuming
GitHub
itself
is
doing
the
right
things
like
if,
for
some
reason,
it's
discovered
that
the
GitHub
action
can
mess
with
the
the
reasonable
workflow,
then
it
all
falls
apart.
We
don't
believe
that
to
be
the
case,
but
in
the
future
we
imagine
with
a
conformance
program.
B
You
know
GitHub
would
go
and
say:
yep
we're
gonna.
You
know
make
a
couple
of
assertions
or
you
know
we're
going
to
make
a
couple
of
you
know
we're
going
to
self
a
test
or
whatever
that
we've
done
all
the
right
things
here
and
here's
why
we
want
you
to
believe
that
you
know
some
information
there,
or
maybe
they
get
a
third-party
auditor
to
do
it,
and
so
all
that
will
go
through
and
then
assuming
that's
all
good.
B
Then
you
know-
and
you
accept
that,
then
you
know
that's
kind
of
salsa,
and
so
when
it
comes
to
other
folks,
whether
it's
a
build
platform
like
Fresca
or
you
know
some
other
build
platform,
You're
Building
or
whatever
you
would
pretty
much
just
need
to
provide
information
to
the
end
user
to
you
know
so
that
they
can
kind
of,
say,
yep,
I,
believe
you
or
I
don't
believe
you,
whether
it's
just
hey.
We
went
through
an
audit
with
this
company
and
this
company
is
saying
they're
good
or
it's
I.
B
C
C
A
trust
level
that
salsa
gives
by
a
defining
the
build
system,
needs
to
to
create
this
piece
of
evidence
and
it's
not
affected
by
the
Builder,
the
producer
of
the
software
and
then
GitHub
I,
say
it's
a
trick
because
it
allows
me
to
basically
put
in
my
own
action
into
the
same
place.
You
would
put
like
the
same
results.
I
could
put
my
own
action
really.
It
could
be
another
Providence
Creator,
but
for
salsa,
but
it
also
can
be
anything
else.
C
On
my
mind,
at
least
in
my
view,
yep,
but
like
it
in
other
build
systems,
I'm,
not
sure
it's
going
to
be
like
that,
for
example,
in
Fresca,
Fresca,
I
guess
you're
going
to
like
how
to
code
this
salsa
provenance
into
your
build
system.
It's
not
going
to
be
extendable.
It's
a
question.
I'm
not
asked
and
I
don't
actually
anymore,
but.
B
B
There
is
you
know
in
addition
to
that
right.
There's
there
is
discussion
in
the
tecton
side
to
say:
can
we
make
that
user
definable?
Can
we
say
that,
and
by
user
definable
like
I
would
say
not?
Maybe
that's
a
bad
word
like
build
platform
owner
definable,
like
the
person
who's
actually
running
the
build
platform,
whether
you
know
in
this
case
Fresca
is
an
open
source
tool.
B
There
is
discussion
among
the
tecton
folks
about
making
some
certain
things
like
salsa
user
definable.
If
I,
if
I
understand
your
correction
of
your
question
correctly,
where
you
know
folks
might
not
want
salsa
Providence,
they
want
something
else,
but
they
still
want
to
follow
that
same
sort
of
pattern.
Where
you
know
you
have
a
thing,
this
thing
sort
of
generates
some
sort
of
security,
metadata
yeah
that
that's
something
that
that
I
know.
Tecton
is
looking
at
a
lot
of
the
other
tools
are,
are
starting
to
look
at
as
well.
B
You
know
something
like
making
you
know
whether
it's
salsa
or
similar
make
something
that
is
like
a
just
something
like
reusable
workflows
or
or
similar
of
like
hey.
This
is
like
a
or
a
plug-in
system
into
some
of
these
tools,
so
you
might
have
something
like
a
salsa
plugin,
for
example,
for
Jenkins
that
wraps
your
pipelines
in
a
bunch
of
stuff,
and
then
you
could
take
that
same
sort
of
plug-in
and
change
it
up.
And
now
it's
you
know
an
Acme.