►
From YouTube: SLSA Tooling Meeting (March 3, 2023)
Description
Meeting notes: https://docs.google.com/document/d/15Xp8-0Ff_BPg_LMKr1RIKtwAavXGdrgb1BoX4Cl2bE4/edit#heading=h.yfiy9b23vayj
B
D
B
D
D
The
meeting
just
doesn't
happen
and
I
just
want
to
make
sure
that,
like
hey,
if
I
get
run
over
by
a
bus
tomorrow
that
that
the
meeting
can
continue
on
so
yeah,
if
folks
are
interested
in
in
helping
co-lead
helping
facilitate
the
meeting,
definitely
you
know
open
to
adding
you
know
more
names
to
the
list.
There.
D
So
we
could
probably
start
off
with
the
tools
and
just
start
listing
some
of
the
tools
that
we
know
are
trying
to
hit
1.0,
or
rather
we
should
start
listing
the
tools
that
we
know
that
are
somehow
using
salsa
and
then
we
can
go
back
and
see.
Are
they
hitting
1.0?
Do
they
plan
to
hit
1.0
and
and
so
on?
The
one
from
my
end
that
I
reached
out
to
is
tecton
chains,
and
there
is
a
GitHub
issue
for
that.
Let.
B
D
D
Requirements,
and
so
obviously
some
of
the
tools
are
just
going
to
be
tools
that,
like
obviously
manipulate
the
the
provenance
or
do
stuff
with
the
Providence,
and
those
will
not
actually
have
to
those
tools
themselves
are
not.
Actually,
we
need
to
be
hitting
the
social
requirements
themselves
just
to
build
tools,
but
those
will
just
hit
the
Providence
spec,
but
then
there's
the
builds,
which
often
will
need
to
hit
both
cool.
So
do
folks
have
other
list
of
tools
that
they
want
to
add
in
outside
Docker
build
kit.
D
C
D
E
B
G
D
G
A
E
E
D
Yeah,
just
for
my
own
understanding,
so
what
is
your
so?
Do
you
know
if
so
I
know
it's
generating
the
spec,
but
then
with
some
of
that
stuff
right
like
like?
How
do
you
get?
Let's
say
a
salsa,
you
know
like
how
is
it
hitting
some
of
the
the
salsa
requirements
themselves
or
is
it?
The
idea
here
is
that
you
would
be
running
this.
D
H
D
So
one
of
the
things
I've
written
up
and
I
plan
to
redo
for
1.0
is
I,
wrote
up
a
q
spec
that,
like
essentially
just
sort
of
says,
hey,
is
this
well-structured
and
it'll?
Do
all
the
verification,
like
also
making
sure
that
hey
every
place?
That's
a
URI
should
be
an
actual
URI,
not
just
a
string.
It
should
be.
D
D
Take
that
cue,
spec
and
then
just
be
able
to
include
it
wherever
they
need
to,
and
just
you
know
they
automatically
get
the
verification
of
of
the
actual
spec,
because
I
I,
if
I,
if
I,
were
to
gather
what
you're
you're
implying
there.
It's
like
hey.
Are
there
things
we
can
do
to
make
it
very
easy
for
adopters
of
the
spec
to
say,
am
I
generating
ballots
also
exactly.
H
And
I
was
going
to
say
in
fact
it's
a
salsa
validator
that
I
want
oh
provenance,
validator
more
than
a
verifier
right,
which
is
the
first
level.
It's
like
you
just
said.
You
know,
making
sure
that
it's
well
formed
I
mean
my
colleague,
Matt
redkowski
actually
built
this
for
as
bombs,
because
when
we
started
trying
to
process
as
well,
we
found
that
you
know
there's
a.
F
H
Of
garbage
out
there,
and
so
obviously
with
salsa
one
zero
coming
up,
we
are
trying
to
entice
people
to
support
it,
but
I
think
it
would
be
wise
to
have
some
basic
tools
that
people
can
use
to
say
hey
by
the
way.
You
might
want
to
verify
the
output
of
your
tool
against
this
just
to
make
sure
at
least
it's
valid.
H
H
E
H
I
I
think
you
know
I
the
deeper
we
can
go
without
getting
this
lead
into
the
verifying
aspect,
which
is
you
know
where
the
you
have
the
right
signature
and
all
that
good
stuff
I
think
you
know
just
making
sure
it's
valid
at
least
on
the
surface
would
be
good
I.
You
know,
I,
don't
have
a
specific
idea
in
mind
as
to
how
far
this
should
go,
but
of
course,
the
deeper
the
better
but
different
linked
to
right.
That
I'm
talking
about
yeah.
D
Similarly,
when
when
seeing
that
a
lot
of
tools
that
we're
generating
s-bombs
weren't,
actually
generating
s-bombs
that
were
compliant
with
the
spec,
the
rust
tool
was
actually
really
good
because
it
could
take
in
like
actual
specification,
definitions
from
a
Json
schema
or
even
through
other
stuff
like
XML
and
be
able
to
generate
it
would
automatically
like,
like
a
lot
of
the
stuff
in
there
was
not
actually
written
by
by
people.
It
was
actually
just.
D
You
know
something
that
reads
the
literal
definition
of
the
spec,
which
is
something
that
we
should
probably
also
I
know
it's
one
of
the
things
for
for
salsa
that
we're
trying
to
do
is
like
actually
have
a
canonical
definition
of
the
spec
in
some
sort
of
language
so
that
somebody
can
go
in.
You
know
a
machine
can
go
in
and
look
at
that
and
be
able
to
to
parse
through,
which
is
why
maybe
something
like
Q
or
similar,
but
yeah.
D
The
the
thing
there
that
I
found
very
useful
was
like
it
was
able
to
do
stuff,
like
you
know,
even
in
stuff,
like
lists
for
for
or
not
lists,
but
Maps
inside
of
stuff,
like
the
s-bomb
hashes
right
spdx
says:
You
must
have
at
least
a
Shaw
one.
You
could
have
additional
things,
but
you
can't
not
have
a
shot
one,
and
so
it's
able
to
kind
of
you
know
figure
all
that
sort
of
stuff
out
which
was
really
useful.
H
That
sounds
good,
I
think
you
know,
as
I
said,
I
mean
if
we
could,
if
there
are
already
tools
out
there,
that
people
can
leverage,
maybe
building
a
list
of
those
already
could
be
a
first
step,
and
then
we
can
see
here
is
more
work.
That
needs
to
be
done
and
we
don't
necessarily
have
to
stop
from
scratch.
But
maybe
you
know
we
can
help
others
get
up
to
speed
this
with
the
latest
version
or
something.
H
H
I
mean
there's
this,
you
know,
there's
a
plan
to
develop
a
certification
program
or
conformance
of
salsa.
Eventually,
this
kind
of
tools
could
be
leveraged
in
the
context,
but
for
now
all
we
have
is
a
spec
and
I
figured
a
lot
of
people
are
going
to
say:
yeah
I
do
salsa
and
they'll
be
producing
garbage,
maybe
not.
F
A
D
That's
actually
looking
into
the
build
environment,
whereas
I
noticed
that
witness
is
mostly
happening
in
the
build
environment,
but
but
I'd
be
curious,
because
I
haven't
kept
a
close
eye
on
on
too
close
of
an
eye
on
on
all
the
developments
on
witness
recently,
but
yeah
I'd
be
curious
from
and
probably
worth
putting
in
there
as,
like.
You
know
on
in
the
document
as
like
a
potential.
You
know
like
reach
out
to
Cole
to
see
if,
if
he's
doing
that,
okay,
let
me
do.
C
G
G
No,
no,
no,
no,
no
well
I
wish
I
would
say
that,
but
I'm
not
saying
that
I
see
I
see
it's.
It's
only
related
to
npmc
lives.
Npmc
lifestyle
will
have
the
capability
of
generating
salsa
provenances
for
npm
packages
built
on
any
conforming
build
system,
which
today
is
heat
of
actions
only,
but
hopefully
we
will
expand
that
in
the
future.
B
A
So
sorry,
just
to
follow
up
with
Frederick
and
to
see
whether
I
understand
this
correctly
is
the
thinking
that
is
it
part
of
the
six
door,
npm
Roc,
that
the
idea
is
to
produce
the
salsa
or
in
total,
at
the
stations
during
bills,
using
build
servers
that
you
control
and
then
the
npm
CLI.
When
you
try
to
install
a
package,
would
maybe
try
to
see
if
these
attestations
exist
and,
if
so,
verify
them.
Before.
Installing.
G
That
is
correct,
so
almost
correct.
So
okay,
if
we
start
at
a
producing
side.
So
the
plan
is
if
npm
CLI
detects
that
it's
executing
in
a
compliant
build
system
that
can
integrate
with
six
store,
such
as
GitHub
actions
or
I.
Think
down
the
road
I
think
to
build
kite
and
git.
Love
is
also
being
integrated
with
six
store.
G
And
then
you
due
to
how
npm
install
is
working
and
it
will
not
verify
data
stations
prior
to
the
install
of
the
package.
But
it
will
do
it
post
install
of
the
package,
so
it
understand
and
then
yeah
taking
it
further
and
of
course-
and
there
would
be
more-
let's
say,
Advanced
policies
to
to
verify,
but
for
now
I
think.
If
you'd
run
an
npm
audit,
it
will
see
if
the
package
have
or
if
it's
expected
to
have
a
build
provenance
and
if
it
doesn't
have
it
will
sort
of
Make
Some
Noise
about
it.
A
That's
that's
very
interesting
now
when
you
say
a
certified
sorry
if
I'm
I'm
hugging
a
meeting,
let
me
know
if
I
should
clamp
up,
but
one
last
question
is
which
identity
do
you
plan
to
use?
So
let's
say
you
find
that
you're
running
on
gitlab
and
you
npm
build
and
upload
something
which
foods
your
identity.
Would
you
use.
G
A
G
So
it
works
by
a
the
CI
provider,
relying
on
open
ID
connect,
ID
tokens
where
sort
of
the
identity
already
exists
in
the
ID
token,
which
is
assigned
Json
web
token
and
fulcer
would
know
that.
Oh
this
token
is
coming
from
gitlab
and
here's
where
I
can
get
the
public
keys
for
gitlab
and
then
I
can
verify
the
token
and
then
fulsio
would
extract
the
claims
for,
for
instance,
the
subject
and
put
those
into
the
signing
certificate.
G
I
would
say
it's
primarily
for
SAS,
due
to
the
issue
of
integrating
your
self-hosted
open,
ID
connect
provider
with
falsia,
which
probably
won't
happen
due
to
let's
say
firework,
firewall
reasons
and
also
I,
think
and
arguing
over.
Let's
say
the
trust
about
your
self-hosted
Runners
would
be
harder
to
convey
the
community
that
you
can
trust
them.
Yes,.
D
D
You
might
be
able
to
go
back
and
say
well:
okay,
I
trust,
the
you
know,
I
think
on
that
front,
though
you
know,
a
lot
of
folks
are
looking
towards,
like
that's
also
conformance
program,
to
do
audits,
to
say:
hey,
I,
I,
looked
at
your
environment
and
your
self-hosted
Runners
are
running
quite
securely
or
or
hey
you're,
you're
self-hosted
Runners
are
not
running
securely.
I'm,
not
going
to
sign
off
that
that
you're
salsa
compliant
I
think
those
are
some
things
that
that
some
folks
are
starting
to
talk
about.
D
E
G
Github,
let's
see
so
I'm,
not
sharing
too
much
information
but
I'm
pretty
sure.
No,
it's
it's
public.
So
for
GitHub
actions,
the
ID
token
contains
a
claim
stating
whether
the
runner
is
self-hosted
or
GitHub
hosted,
and
that
would
be
carried
over
to
the
signing
certificate
as
well
so
based
on
the
certificate
identity.
You
can
understand
if
this
was
a
build
running
in
our
runners
or
some
random
Developers
message.
A
That's
a
good
one
and
then
maybe
in
the
future,
you
know
in
this
more
trusted
Hardware
you
could
do
some
sort
of
remote
attestation
of
the
of
the
I
already
see.
Brandon
is
like
yeah
sure,
but
yeah
remote
attestation
of
the
self-hosted
runner.
If
you
feel
really
worried
about
it's
run
time,
but
that's
the
whole
point
you
don't
need
to
in
in
a
good
scenario
with
things
like
npm
correct
me
if
I'm
wrong
here,
especially
if
it's
not
compiled
you,
don't
need
to
even
trust
the
self-hosted
runner
you
could.
G
Correct
and
and
and
as
I
said
like
in
the
end
of
the
day,
what
what
you're
getting
when
you're
downloading
an
npm
package
is
sort
of
code
that
will
be
interpreted
by
some
interpreter.
But
it's
I
mean
it's
definitely
the
cryptographic
link
between
source
code
repository
and
package,
which
we
tried
to
sort
of
close
the
gap
for
with
this.
But
still
if
the
runner
was
self-hosted.
We
couldn't
really
attest
to
that
because,
just
because.
G
D
Yeah
there's
there
are
some
also
there's
some
interesting
work.
I've
been
seeing
in
the
you
know,
the
confidential
container
space
and
similar
around
you
know.
If
you
can
verify
that
you're
coming
from,
let's
say:
An
approved,
secure,
Enclave
or
whatever,
then
that
self-hosted
Runner,
you
could
be
a
bit
more
confident
that
it's
only
doing
the
the
right
actions.
Because
of
of
how,
because
of
the
security
you
know,
constraints
placed
on
that
secure
Enclave.
D
You
know
you
would
be
able
to
go
back
and
say:
okay,
great
I'm,
I'm
I
know
that
it
only
ran
in
that
environment.
So
you
know,
even
though
it
didn't
run
on
my
literal
Hardware
under
my
control.
I
know
that
you
know
it
could
have
only
done
the
actions
I
I
told
it
to
at
least
once
again.
This
is
all
hypothetically
there's
lots
of
folks
who
you
know
have
lots
of
concerns
with
whether
or
not
the
guarantees
in
the
secure
Enclave
are
actually
valid
or
not.
H
So
you
were
talking
about
the
salsa,
Gita
generator
and
the
fire,
and
it
exhibits
some
of
the
challenges
that
I
think
we
have,
which
is
you
know
if
you
use
it
today
seems
to
be
doing
the
right
thing.
Do
you
have
no
idea
whether
it's
actually
you
know
it
complies
with
the
the
letters
version
of
the
spec
or
not?
You
could
claim
it?
H
Does
it
wouldn't
know
and
I
think
you
know
we
will
only
get
to
the
right
point
in
the
industry
when
we
can
mix
different
tools,
because
the
problem
here
is
done
by
the
same
set
of
people,
so
they
change
the
generator
they
change
the
verifier
along
the
same
way.
So
it
all
works,
which
is
great
I,
mean
it's
better.
Nothing
don't
get
me
wrong,
I'm
not
trying
to
to
bash
them
in
any
way,
but
ideally
we
would
want
to
be
able
to
mix
match
different
tools
from
different.
H
You
know
independent
implementations
and-
and
you
know,
I'm
a
stainless
guy-
a
lot
of
standard
organization
of
this
kind
of
requirement.
You
know
for
standards
to
become
standards
to
to
have
at
least
two
independent
implementations,
if
not
more
so
you
can
kind
of
do
this
test
of
interoperability
and
see.
If
actually
you
know
it
works
because
I
mean
it's
great.
H
We
have
all
these
different
like
package,
and
you
know
ecosystems
that
are
going
to
start
implementing
salsa
they're
going
to
produce
things,
but
if
they
also
put,
if
they
also
do
the
the
CLI
that
verifies
it
on
the
consumer
side,
you
fall
back
into
that
same
schema.
Every
time
where
it's
the
same
set
of
people
who
do
the
producer
and
the
consumer
side,
and
it
doesn't
mean
they,
it
does
the
same
thing
as
other
people
do
for
the
different
ecosystem.
D
Yeah
no
definitely
agree
there
well.
I
mean
I,
know
that,
like
there's
tecton
chains,
which
is
doing
some
of
it,
I
know
that,
with
some
of
that,
there's
been
some
push
on
the
tecton
chains,
folks
to
maybe
be
a
bit
quicker
in
in
in
adopting,
let's
say,
1.0,
because
with
some
of
it
it's
it's
been
quite
slow,
but
at
the
same
time
also
I
know
that
you
know
under
open
ssf.
D
D
Yeah,
that's
definitely
but
Brendan
brought
up.
I
think
is
yeah
the
the
big
issue
right
now
and
it's
something
that
I
know
that
we
wanted
to
do
like
of
a
what
we're
calling
the
salsa
Rebuilder
right,
the
ability
to
kind
of
go
back
and
say:
hey
can
I,
take
something
like
a
salsa
attestation
and
then
rebuild
do
stuff
and
do
do
all
sorts
of
things
like
you
know.
Could
you
transform
that
salsa
build
that
ran
in
some
way?
E
Yeah,
it's
non-trivial,
because
every
one
of
these
Builders
is
different.
So
it's
not
easy
to
say
if
I
build
it
in
GitHub,
try
to
build
it
in
gitlab
and
get
a
comparable
salsa
output
that
you
can
say.
Okay,
both
of
these
did
similar
things,
but
that
would
be
a
nice
endpoint
if
we
can
ever
get
there
at
some
point.
D
C
D
The
folks
who
are
working
on
that
are
APAC,
so
they
haven't
been
able
to
actually
demo
anything
but
we're
trying
to
kind
of
get
an
APAC
friendly
thing
there.
But
yeah
this
tool
was
actually
pretty
cool.
I
I
think
it's
there's
a
couple
of
things
that
they're
they're
trying
to
verify,
which
I'm
not
exactly
sure
if
they
can,
but
if
macaron
is
essentially
a
a
sort
of
salsa,
it's
a
it's
an
independent
salsa
verification
thing,
and
it
actually
does
it.
D
D
This
so
in
the
slack
there's
some
attachments
there
that
are,
like
a
you
know,
a
cube,
the
the
policy
and
HTML
and
sorry
the
reports
for
the
actual
salsa,
like
reading
through
the
salsa
and
trying
to
verify
and
trying
to
essentially
verify
that
it
is
in
fact,
you
know
using
the
approved
Builders
and
all
that
sort
of
stuff.
I
think
it
has
a
lot
to
do,
but
a
lot
to
go.
But
it's
it's
pretty
neat.
D
Yeah
and
yeah
I
think
that's
that's.
One
of
the
big
things
coming
from
salsa
is
like
who's
actually
generating
that
that
attestation
right,
because
the
the
view
from
like
the
secure
software
Factory
standpoint
is
that
you
need
to
have
something
outside
of
the
sort
of
secure,
I,
don't
say,
security
boundary,
but
outside
of
what's
running
the
build,
observing
the
build
like
actually
peering
in,
and
it
depends
exactly
what
your
your
threat
model
is
and
yeah
yeah
like.
D
If
you
run,
you
know
some
folks
might
say
yeah
the
container
is
a
security
boundary
which
I
know
for
most
folks
is
is
not
actually
true,
but
you
know
there's
some
stuff
there.
That's
kind
of
why,
with
like
the
secure
software
Factory,
the
thing
that
we
had
done
was
we
had
that
idea
of
the
workload
identity
plus
a
thing
that's
observing
the
build,
and
because
you
can
do
that,
you
can
say
well.
I'm
running
this
container.
D
And
then,
in
addition
to
that,
you
can
then
also
have
something
like
you
know,
using
ebpf
or
whatever
to
sort
of
verify
from
the
outside.
You
know
is
this
thing
trying
to
make
weird
Network
calls
and
so
on,
but
then,
of
course,
the
thing
there
right
is
just
the
more
isolated
and
ephemeral
you
can
make
that
environment
the
just
sort
of
safer
you
feel
because
if
you,
if
the
job
doesn't
have
network
access,
okay,
cool,
that's
a
whole
class
of
things,
I
don't
need
to
worry
about
anymore,
at
least
hypothetically.
A
G
I
I
can
add,
like
so
let's
say
in
this
case.
Like
your
example,
you
have,
let's
say
a
layered
approach
where
the
CI
provider
spins
up
VM,
and
in
that
VM
you
run
a
container,
and
in
that
container
you
run
a
build,
at
least
in
GitHub
what
the
workload
identity
would
be.
It
would
be
like
the
identity
of
the
ephemeral
VM.
Then,
whatever
you
run
in
terms
of
let's
say,
the
the
build
workflow
is,
let's
say
large
and
you
potentially
have
a
risk
of
leaking
artifacts
between
the
different
steps.
G
A
G
G
So
so,
if,
if
that
is
the
case,
the
actual
work
workflow
identity
from
fulsio
will
will
be
a
reference
to
the
reusable
workflow.
And
that
is
not
something
you
can.
You
can't
forge
so
so
that
is
a
way
of
getting
a
stronger
trust
model
on,
in
this
case,
GitHub
actions.
I'm
assuming,
let's
say
for
Circle
CI.
G
So
it's
not.
You
can't
really
Forge
the
provenance
per
se,
because
the
primary
parts
of
the
provenance
is
extracted
from
the
ID
token.
But
still
we
don't
really
know
that
you're
actually
uploading.
Let's
say
the
artifact
you're
supposed
to
be
uploading
that
you
still
have
the
traceabilities.
You
can
go
back
in
time
and
see
what
was
actually
uploaded.
You
know,
or
the
only
thing
or
put
it
like
this-
we
attest
to
that.
A
G
You're,
correct,
you're,
correct,
okay,
so
basically
the
approach
we're
taking
is
that
when,
when
you're
running,
npm
publish-
and
we
detect
that
you
are
let's
say
in
GitHub
actions
and
PMC
law
itself
will
generate
the
provenance
and
sign
it.
The
ephemeral
key
from
Full
com
and
publish
it,
but
still
you
could
easily
replicate
that
in
let's
say
a
few
manual
steps
and
and
I'll
upload,
whatever
you
want
and
that
is
sort
of
the
Gap,
we're
closing
or
Google
is
closing
with
the
reusable
workflows
they
are
offering.
G
D
That's
right,
yeah
and
that's
actually
one
of
the
the
big
complicated
things
right
is
because
it
it
pretty
much
limits
what
the
end
user
can
do
in
a
like
in
that
reusable
workflow
way,
because
it
has
to
be
supported
by
the
reusable
workflow
and
then
because
this
is
actually
something
that
what's
been
being
discussed
in
the
slack.
A
little
bit
is
some
folks.
You
know
who
work
at
various
Enterprises
are
like:
hey,
I
can't
use
the
openss
reusable
workflow
I
need
to
Fork
it
and
pull
it
into
my
own
environment
and
then
it's
like.
D
Well,
then,
you
lose
some
of
those
guarantees,
because
the
idea
right
is
if
you're
in
the
open
source
space,
somebody
can
always
go
back
and
audit
and
look
at
that
reusable
workflow
and
say:
oh,
that
reusable
workflow
came
from
openssf.
These
are
the
lines
of
code
and,
assuming
you
trust,
GitHub,
to
be
doing
the
right
things.
Then
you
know
that
it
only
ran
those
steps.
D
You
know,
whereas
even
if,
let's
say
the
like
in
the
case
of
npm,
it's
like
once
again,
salsa
doesn't
protect
you
against,
like
malicious
source
code,
doing
malicious
things,
but
it
does
sort
of
guarantee
that
the
malicious
source
code
was
only
Built
using
these
commands
so
that
it
you
know
if
you
have
additional,
let's
say
security
steps
in
there.
You
know
those
security
steps
still
ran.
Yeah,
yeah
and
I.
Think
that
sort
of
thing
is
is
is
also
an
interesting
challenge
that
some
folks
are
are
bringing
up
is
like.
Is
there?
D
Can
there
be
ways
some
of
it's
going
to
be
audit
and
yayada?
Oh?
So
this
is
so
technically
that
this
is
not
a
Google
product.
It's
actually
salsa,
it's
openss,
it's
it
is
under
us.
It
is
that
the
majority
of
devs
who
are
working
on
it
I
would
say,
like
you
know,
nine
out
of
the
ten
deaths
who
are
working
on
it
are
googlers,
which
is
another
thing
that
we
should
probably.
A
G
D
Yeah
yeah
because,
like
the
the
idea
behind
it
is
like
the
same
way
that
at
a
company
you
might
say,
here's
our
default
pipeline,
you
must
follow
the
steps
of
the
template
pipeline
right.
You
don't
get
to
just
go
in
and
say:
oh
yeah,
I'm
gonna,
remove
this
scanning
step
or
I'm
going
to
remove
this
linting
step.
It's
like
it's
part
of
the
template.
G
D
Now
now
there
is
definitely
some
stuff
I
think
that's
worth
investigating,
which
is
there's
all
probably
a
lot
of
interesting,
typo
squatting.
That
could
probably
be
done
to
give
folks
the
you
know
the
idea
that
they're
probably
like,
like
they
might
think
oh
I'm,
using
the
reusable
workflow
and
it
turns
out
like
they're
using
you
know
the
open.
A
G
So
for
that,
this
is
still
something
that's
sort
of,
let's
say
in
the
flight,
but
we
haven't
taken
a
hard
stance,
because
I
think
this
in
the
end
ties
down
to
verification
policies.
So
just
because,
let's
say
open,
ssf
provides
one
that's
ready
to
go,
maybe
maybe
we
can
endorse
it.
Maybe
we
won't,
but
let's
say
Oracle
as
an
example,
because
we
have
mentioned
Oracle
earlier
in
this
call.
Maybe
Oracle
produces
a
workflow
which
is
equally
good
and
a
random
maintainer
building
a
JavaScript
package
would
probably
trust
their
workflow
as
well.
G
G
G
Okay,
we
may
endorse,
let's
say
the
salsa
version
by
open
ssf
or
we
maybe
not
I,
don't
know
we
have
to
see
sort
of
what
approach
we're
going
to
take.
But
this
is
something
we
and
I
don't
know.
What's
about
pizza
has
been
working
on
this,
but
there
are
future
ideas
like
can
you,
as
a
maintainer,
say
when
I'm
building
my
package
I'm
expecting
to
see
this
workflow
being
used?
So,
let's
say
a
repository
attack
that
changes
The
Trusted
workflow
to
some
untrustable
workflow.
G
D
How
can
you
delegate
and
distribute
trust,
and
how
can
you
you
know
because
I
think
some
of
the
stuff
that
folks
are
starting
to
talk
through
as
well,
is
like
for
folks
who
are
like
yeah
I
can't
use
assass
to
build
my
stuff
because
I,
you
know
I
have
requirements.
I
need
to
build
it
internally
for
closed
Source
stuff
as
well.
Folks
are
talking
about.
You
know
like
with
the
salsa
conformance
program.
D
You
could
have
a
third
party,
that's
been
approved
by
let's
say
the
LF
to
do
these
Audits
and
they
can
audit
some
of
these.
You
know
companies
build
systems,
and
so
you
might
say
you
know
yes,
software
vendor
X
has
been
audited
and
you
know
so,
if
you
trust,
let's
say
dlf
to
do
you
know
to
to
sponsor
that
or
whatever
you
you
could
say.
Okay
great,
this
person
is
certified.