►
From YouTube: SLSA Meeting (September 1, 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
B
A
But
yeah
I
figured
we'll
give
it
a
couple
minutes
for
some
more
folks
to
join
and
get
started.
C
A
So
we
could
probably
get
started.
I
posted
the
meeting
notes,
hey
David
posted
the
meeting
notes
in
chat
here
feel
free
to
put
your
sort
of
name
in.
A
So
as
we
get
started,
first
things
are:
is
there
anybody
who
is
new
to
the
salsa
community
meeting
here?
Who
wants
to
maybe
introduce
themselves
actually
actually
sorry
before
I?
Do
that?
Let
me
do
the
Spiel
here,
so
so,
just
as
a
as
a
reminder,
this
meeting
is
being
recorded,
it'll
be
uploaded
to
YouTube
shortly
thereafter,
and
also
your
participation
in
this
meeting
is
an
agreement
to
abide
by
the
open,
ssf
code
of
conduct,
yeah,
okay.
A
D
Hi
I'm
Nisha,
hey
Michael
yeah.
This
is
my
first
salsa
meeting
Nisha
Kumar
and
Oracle
cloud
foreign.
A
Anybody
else,
or
we
can
get
right
into
the
agenda.
A
Okay,
so
we
can
get
into
the
agenda
here
so
the
before
so
I
know.
Aaron
has
a
little
bit
of
a
presentation
regarding
some
salsa
stuff
with
gitlab,
but
before
kind
of
doing
that,
I
think
we
want
to
just
mostly
give
a
couple
of
updates
from
the
other
work
streams
and
just
so
that
we
don't
get
off
track.
A
I
think
we
do
want
to
make
sure
that,
like
these
are
mostly
just
updates
and
a
couple
of
clarifications
and
if
folks
are
interested
in
sort
of
some
of
the
details,
feel
free
to
attend
the
actual,
the
different
special
interest
groups
for
like
whether
it's
the
specification,
the
positioning
or
the
the
tooling
working
group
cool.
F
I
was
just
gonna
say
that
I
know
this
week's
meeting
was
canceled,
but
myself
and
a
couple
of
other
folks
met
for
the
hybrid
model
when
you're
talking
about
proprietary
code
and
open
source
code
and
so
I,
we
did
come
up
with
a
diagram
and
I
put
it
in
slack.
So
any
comments
on
it.
F
Suggestions
on
on
how
to
improve
or
maybe
other
use,
cases
that
we
haven't
considered,
please
feel
free.
That
was
the
only
thing.
I
was
going
to
say
thanks
foreign.
A
That's
definitely
something
that
is
I
know.
Super
interesting
is
one
of
the
big
open
questions
is
salsa
open
source
salsa,
you
know
closed
source
and
then
what
about
stuff,
hybrid,
cool,
so
so
I
know
we
didn't
have
the
meeting
this
week
because
a
bunch
of
folks
are
out
of
office
and
then
we're
also
not
going
to
be
having
a
meeting
next
week
because
of
the
U.S
holiday
for
the
salsa
specification
thing,
but
there
are
feel
free
to
and
I
know
it's
somewhere
in
the
I.
A
Don't
have
the
the
link
with
me
right
this
second,
but
there
is
the
salsa
specification
notes,
as
well
as
a
1.0
proposal
for
folks
to
kind
of
take
a
look
at
and
and
see
if
it
makes
sense
and
right
now,
I
believe
we're
kind
of
just
trying
to
mostly
clarify
some
1.0
specific,
like
requirements
and
makes
clarifications
on
some
of
those
things
pull
out
requirements
that
maybe
were
like.
You
know
what
we're
not,
including
that
in
the
scope
for
1.0
right
now.
A
That
sort
of
thing
so
just
feel
free
to
to
sort
of
comment
on
that
Melba.
Did
you
want
to
talk
about
positioning.
F
Sure
so
we
finalized
the
chart
or
almost
done
finalizing
the
charter
for
the
positioning
put
a
link
there
and
we
kind
of
need
the
steering
committee
members
to
kind
of
look
through
the
charter.
I
think
there's
only
one
section
that
needs
to
be
rewarded,
but
the
rest
seems
to
be
okay
in
terms
of
the
content.
F
In
terms
of
our
efforts
for
positioning,
we
are
going
to
attempt
to
map
the
spreadsheet
that
several
of
us
did
for
mapping
salsa
to
ssdf
and
other
framework,
slash
regulations
and
using
Osco,
which
was
something
Mike
that
you
made
us
aware
of.
Additionally,
there's
one
to
two
blogs
in
progress:
I
think
it
was
Sean
if
I
remember
correctly
had
shown
off
something
that
was
pretty
interesting,
and
so
we
all
recommended
that
there
would
be
some
sort
of
blog
posting
about
it.
F
We
weren't
sure
if
it
was
going
to
be
one
or
two
so,
but
that's
in
progress
and
the
questions
that
we
had
from
I
think
it
was
yesterday's
meeting
or
the
day
before
Mike
I
think
you
had
mentioned
that
originally
oscow
was
used
potentially
for
salsa
conformance
or
could
it
be
used
for
social
conformance?
I
think
that
was
the
question
is
that
right,
Mike
yeah.
A
So
I
the
idea
would
be
so
oscal
for
folks
who
are
not
familiar
is
a
language
and
sort
of
a
model
built
by
nist
and
the
primary
there's
a
few
primary
goals,
but
the
the
goals
of
it
are
stuff
like
have
a
unified
language
for
describing
controls,
control,
catalogs
and
those
sorts
of
things
and
mappings
of
controls
and
all
that
sort
of
stuff,
so
that
you
can
have
everything
in
something
like
XML,
Json
yaml
have
and
then
be
able
to
easily
have
automation
sort
of
generate
the
views
into
it.
A
So
you
know
one
of
the
big
issues
right
today
is
people
copy
paste.
You
know,
oh
here,
I'm,
applying
this
nist
control
or
or
I'm
doing
this
salsa
thing
and
they
just
copy
paste
and
then,
if
salsa
updates.
Okay,
now
I
need
to
copy
paste
the
new
one-
and
you
know,
do
that
sort
of
stuff,
whereas
it's
more
of
an
automated
way
of
of
kind
of
managing
that
and
then
with
the
further
like
you
know,
goal
being
stuff
like
and
IBM
has
been
doing
stuff
with
this
with
their
Trestle
tool
is
ways
to
actually
tag.
A
Let's
say
code
that
you
could
say:
oh,
this
is
essentially
me
tagging
this
piece
of
code
or
doing
this
sort
of
thing
is
proof
or
or
this
is
the
proof
that
I
am
you
know
that
my
build?
Is
this
sort
of
thing
which
makes
it
salsa?
A
Oh
I
took
a
screenshot
of
my
my
my
build:
that's
that's
salsa
compliance
or
whatever
yeah,
so
so
that's
kind
of
oscow
in
a
nutshell,
and
so
it's
it's
very
much
in
line
with
what
we're
trying
to
do
from
an
automation
perspective
and
make
it
less
manual
like
somebody,
somebody
asserting
they
did
a
thing
and
more
of
looking
at
the
actual,
build
tool
and
saying
yep.
It
did
the
thing.
F
And
the
only
other
thing
was,
while
we
were
going
through
the
charter,
there
was
two
sections
which
we've
since
condensed
into
one
talking
about.
You
know
educating
and
doing
evangelism,
and
the
question
came
up
of:
isn't
that
the
intent
of
the
adoption
fig
which
isn't
formed
yet,
but
when
reading
the
adoption
Sig
description,
it
seemed
more
focused
around
tooling,
and
so
we
thought
maybe
education
and
evangelism
currently
is
in
within
each
Sig.
F
Currently,
until
we
get
more
adoption
more
folks
participating
and
then
we
would
potentially
split
up
those
two
things
from
each
of
the
six
into
a
formal
group.
So
that
was
something
that
we
wanted
to
get
clarified.
If
that
was
the
intent
of
adoption
or
if
we
are
thinking
about
education
and
evangelism,
not
not
in
a
proper
way.
G
I
think
that
adoption
was
would
include
some
level
of
education
and
evangelism,
but
was
more
about
working
to
actually
integrate
social
tooling
into
communities
or
ecosystems.
G
I,
yeah
I,
don't
think,
there's
a
clear
split
for
which,
which
kind
of
workstream
education,
Falls
Within
kind
of
definitely
there's
some
aspect
in
the
tooling.
We
develop
and
the
documentation
around
that
and
how
we
position
relative
to
other
emerging
standards
and
things
in
the
ecosystem
and
definitely
will
have
to
educate
people
and
evangelize
or
advocate
for
salsa.
As
we
approach
communities
and
talk
about
adopting
a
bit
of
an
unanswer.
F
Yeah
and
that's
fine,
we
were
just
trying
to
clarify
because
a
lot
of
what
you
said
is
in
the
charter
for
positioning,
but
we
were
trying
to
frame
it
in
the
sense
of
you
know,
educating
and
saying
you
you
should
be
using
salsa
because
of
x
y
z,
it'll
help
you
meet
these,
you
know
framework
or
regulations
and
being
compliant
Etc,
et
cetera,
but
then
I
started.
Thinking
about
blogs
and
I
was
like
well
I.
G
Yeah,
that
makes
sense
yeah
adoption
I'm
just
looking
at
the
document.
It
was
mostly
kind
of
pause
for
now,
because
we
don't
have
I,
want
those
arrows
back
or
tooling
to
recommend,
but
the
idea
was
to
focus
on
early
prototyping
and
Outreach
to
open
source
projects
specifically.
B
A
I
guess
we
can
switch
to
Melba.
Do
you
have
anything
else
for
positioning
or.
A
Cool,
so
we
could
get
to
I,
guess
tooling,
so
I
have
I,
have
a
link
to
what
we've
been
currently
working
on
in
the
meeting
notes,
which
is
just,
is
essentially
we're
trying
to
kind
of
build
out
a
list
of
requirements
for
sort
of
some
of
the
the
pieces.
A
There
is
that
the
tooling
working
group
is
looking
at
a
bunch
of
different
categories,
but
right
now
we're
really
really
focused
on
the
distribution
and
Discovery
piece,
because
you
know
there's
a
lot
of
being
work
being
done
to
do.
Builders
right,
you
know,
there's
there's
the
GitHub
Builder
Aaron's
going
to
be
giving
a
little
bit
of
a
presentation
in
a
little
while
on
some
of
the
work
he's
been
doing
to
integrate.
A
Git
lab,
there's
a
lot
of
stuff
on
that
end,
but
there's
really
not
a
lot
as
far
as
the
sort
of
distribution
end
or
there's
still,
you
know,
there's
a
lot
of
work
in
progress
on
the
distribution
end
and
sounds
like
there's
a
lot
of
stuff
there.
So
past
couple
of
weeks
been
talking
with
a
few
different
folks.
A
A
Because
now
you
can
actually
have
like
a
salsa
type
in
the
in
the
Manifest,
and
it
can
point
to
this
salsa
attestation,
which
would
then
allow
folks
to
even
do
lots
of
nice
little
things
like
you
can
sort
of
verify
that
hey
does.
Is
there
a
salsa
attestation
for
every
layer
or
does
that
matter?
Right
and
that's
kind
of
some
of
the
discussions
we've
been
having
is,
is
thinking
through
like
how
do
folks
sort
of
view
that,
and
also
you
know
we
plan
to
sort
of
integrate.
A
You
know
have
some
additional
conversations
with
oci
folks
on
what
makes
the
most
sense
from
a
salsa
perspective
like
how
do
we
distribute
these
attestations
via
oci
long
term,
because,
right
now
you
know
to
be
clear.
Like
you
know,
certain
projects
like
six
door
are
doing
it
by
sort
of
that
naming
Convention
of
you
know
the
the
digest
dot
ATT
as
the
way
of
Distributing,
salsa,
attestations
but
longer
term.
A
You
know
you
want
to
have
that
baked
into
oci
via
the
Manifest,
because
it's
just
much
nicer
to
use,
and
so
you
know
we're
looking
through
like
hey.
How
does
that
work
and
are
there
ways
to
eventually
then
do
some
of
the
other
things
that
we
know
we
want
to
do
like
transitive,
salsa,
eventually
through
stuff,
like
the
Manifest,
because
you
just
kind
of
you
know,
look
through
the
layers
stuff
like
that,
so
we
had
some
conversations
on
that
end,
we'll
need
to.
A
They
also
suggested
by
the
way
I
mean
Mike,
suggested
that
we
registered
the
salsa
predicate
or
in
Toto,
or
something
like
that
as
an
artifact
type
with
Iana
it'll
make
a
lot
of
stuff
a
lot
easier,
but
he
said
we
want.
We
want
to
make
sure
that
we're
pretty
well
solidified
with
what
we're
doing
there
like
what
like.
A
We
have
a
pretty
good
understanding
of
what
that
would
really
really
look
like
there's
still
some
additional
work
happening
on
the
npm
side,
so
there's
that
RFC
is
still
open
about
integrating
with
salsa
and
Sig
store.
A
So
on
that
end,
they
are
currently
saying
that
most
likely
it'll
be
a
separate
file,
but
potentially
the
npm
tool
would
automatically
know
when
I
pull
down
this
package
also
look
at
this
over
here
and
that's
how
I
can
pull
down
a
salsa
attestation
and
and
do
that
sort
of
stuff.
So
there's
some
stuff
on
on
that
front.
A
I
can't
remember
who
it
was.
Somebody
was
saying
that
they
they've
been
working
with
Maven
Central
to
oh,
no
sorry,
some
folks
from
Google
had
said
that
they
have
been
doing
some
work
on,
including
the
attestation
in
the
maven
package,
and
some
folks
have
been
talking
about
reaching
out
to
you
know
the
folks
who
run
Maven
Central
like
sonotype
after
the
POC
has
been
built
out
to
actually
say
hey.
Does
this
make
sense?
A
A
Is
there
a
general
process,
slash
tool
that
we
should
be
telling
folks
to
kind
of
push
right
in
Toto,
recommends
Json
lines
for
actually
distrib
Distributing
stuff,
like
in
Toto
attestations,
which
salsa
is
a
type
of
Distributing
in
total
attestations
as
files.
So
if
we
were
to
say,
hey
great
we're
going
to
do
it
that
way.
A
Are
there
some
best
practices,
some
basic
tools
that
we
can
sort
of
build
out,
so
that
folks
can
say:
okay,
great,
we
are
going
to
expect.
If
you
distribute,
let's
say
your
packages
on
GitHub,
then
we
expect
your
Json
lines,
files
to
be
living
next
to
your
actual
package.
A
There's
some
discussions
that
we're
having
on
on
that
front
to
kind
of
figure
out
some
of
those
details
and
then
finally-
and
this
is
kind
of
more
of
a
longer
tail
thing
of
so
as
a
reminder,
recore
is
mostly
focused
for
proof
that
this
thing
happened
in
a
certain
thing
and
it
hasn't
been
tampered
with
like
a
tamper,
evident
log
of
that
thing
happening,
but
it's
not
really
intended
to
sort
of
distribute
or
discover
attestations
of
just
whatever
right.
A
So
we're
talking
to
a
few
folks
and
there's
some
work
being
done
on
what
would
maybe
some
mechanisms
for
holding
on
to
attestation
so
that
folks
can
say
before
I.
Even
look
at
a
particular
package,
I
want
to
know.
Does
that
package
have
a
salsa
attestation,
because
before
I
even
download
it
start
exploring
that
thing
I
want
to
know?
Are
they
building
via
salsa
and
so
there's
some
stuff
here
about?
A
You
know:
how
do
we
distribute
you
know,
distribute
those
sorts
of
things
be
able
to
run
queries
out
of
band
so
on
that
front,
but
that's
much
longer
tail.
So
that's
everything
from
the
tooling
side.
D
Hi
Michael
I'd
like
to
give
a
little
bit
of
clarification
on
the
oci
spec.
So
the
reason
why
folks,
like
cosine
are
using
the
the
tag
is
because
the
registry
itself
does
not
support
the
refers
API.
So
once
we
have
Registries
that
adopt
that
new
API,
you
can
actually
use
the
refers
field
in
the
Manifest
to
say
that
this
is.
This.
Is
a
salsa
attestation
to
this
container
image
or
this
other
kind
of
artifact.
A
Yep,
thanks
for
the
the
clarification
yeah
yeah
that
that
that
makes
sense
and
and
yeah
so
for
for
other
folks,
just
to
make
sure
that
it's
clear
yeah,
it's
just
we
need
you
know
with
the
oci
stuff
being
merged
in,
as
you
should
just
mention.
We
just
need
to
make
sure
that
those
things
are
actually
now
implemented
in
the
oci
registry
tools
that
that
are
out
there
and
once
they
are
then
it'll
be
really
easy
for
for
salsa
to
to
to
to
leverage
it.
B
A
Any
other
questions
about
that
otherwise
or
or
any
other
comments.
Otherwise,
we
can
move
on
to
Aaron's
presentation.
D
I
have
one
more
question:
is
in
total
the
only
tool
that
generates
salsa
attestations
right
now
or
is
there
like
any
other
thing
that
we
are
looking
at
on?
Well,.
A
So
in
Toto
is
just
the
the
spec
that
we're
using
and
we
recommend
it
it's
not
required,
but
it
does
seem
to
be
essentially
de
facto
right
now,
where
pretty
much.
As
far
as
I've
seen
the
only
folks
who
you
know
we
have
in
the
spec,
you
just
need
to
make
sure
that
those
fields
exist,
and
you
can
then
say
your
your
salsa
compliant.
But
with
that
said
practically,
you
know
everybody's
just
sort
of
using
the
in
Toto
specification
for
that.
A
But
from
a
tooling
perspective,
you
know
anything
that
supports
the
in
Toto
stuff
that
works
with.
So
that's
anything
from
you
know
various
command
line
tools
like
cosine
or
the
salsa
generator
stuff.
That's
in
the
salsa
GitHub,
as
well
as
tecton
chains,
there's
I
believe
also
there's
a
bunch
of
other
tools
as
well
that
that
support
it.
So
anything
that
supports
the
in
Toto
specification
supports
that,
but
also
for
folks
who
are
you
know
if
you
are
generating
that
metadata
in
another
way?
A
D
Okay,
so
basically,
your
recommendation
is
be
conformant
with
the
in
total
specification
and
you
should
be
interoperable.
G
The
recommendation
is
to
be
conformed
with
the
in
total
attestation
specification,
which
is
different
to
the
format
that
the
in
Toto
tool
currently
generates.
So
that's,
nice
and
confusing
for
everyone
involved.
I
can
drop
a
link
to
on
the
salsa
website.
We
try
to
describe
like
the
attestation
model
and
the
different
specs
or
yeah
specifications
involved
and
how
they
kind
of
fit
together.
D
Thanks
Joshua,
so
just
to
clarify
the
reason
I'm
asking
all
these
questions
is
because
a
bunch
of
us
are
working
on
an
spdx
3.0
build
profile
and
we
are
trying
to
make
this
compatible
with
salsa
and
it's
a
little
difficult
because
of
the
way
that
this
attestation
is
worded
and
the
things
that
we
are
trying
to
munch
into
it.
Things
like
packages
well,
basically,
products
and
services
together,
so
in
in
some
ways
it's
like
trying
to
combine
together
two
different
concepts,
but
thanks
for
that.
G
Yeah
I
I
know
some
folks.
Working
on
salsa
have
I
think
like
Marco
polodato
from
Google
has
started
attending
those
Bill
profile
meetings.
D
I'm
sure
it'll
be
shared
by
by
Brandon
and
others.
I
am
specifically
trying
to
understand
it
from
the
spdx
point
of
view,
so
I'm
also
learning.
A
Yeah
and
I
think
there's
been
still
some
conversations
that
have
been
going
on
about
you
know.
There
was
some
original
discussions
of,
should
salsa,
adopt,
build
profiles
or
make
it
interoperable
or
whatever
or
if
generally,
for
example,
if
they're
doing
things
that
are
separate
enough,
that
all
you
need
to
do
is
just
let's
say,
have
a
citation
of
a
hash
of
saying,
hey.
A
You
know
they
both
point
to
the
same
hash,
and
you
know
that's
that's
what
kind
of
you
know
they're
supporting
different
use
cases
and
they
don't
necessarily
need
to
be
100,
interoperable
David.
H
Yes,
man,
I
think
again,
as
as
Mitch
was
saying,
I
think
we're
hoping
that
the
googlers
attending
the
spdx
profiles
calls
are
well
communicate
that
or
help
to
be
in
intermediary
or
coordinate
on
those
things
and
I.
I.
Think
what
we're
hoping
is
that
it
at
least
I'm
not
sure
what
interruptly
we
don't
want
to
be
contradictory.
In
other
words,
we
don't
we
we're
hoping
that
I
guess
there's
some
sort
of
a
superset
of
those.
H
You
can
use
this
information
and,
have
you
know
a
subset
of
a
point
you
know
used
for
profiles
and
stuff
so
used
for
salsa.
It
may
be.
You
know
the
whole
is
just
exactly
identical,
which
would
be
ideal
but
that
at
least
we
don't
end
up
with
definitions
that
are
contradictory,
and
that
are
you
know
confusing
and
don't
allow
you
know,
don't
allow
the
interoper
going.
Nothing
is
that
you,
you
know
some
definition
in
one
just
completely
prevents
it.
A
A
little
bit
of
a
thing
there
so
just
as
reminded
salsa,
is
a
whole
community.
D
I
mean
beyond
the
be
on
the
folks
who
represent
Google
I.
Think
there
is.
There
is
some
well
the
way
that
we've
been
looking
at
the
salsa
specification
and
examples
take
into
account.
Things
like
manage
services
that
are
offering
that
are
offering
the
like
to
build
somebody's
package
and
not
all
ecosystems,
fit
that
model
and
we're
trying
to
get
this
profile
to
fit
that
model,
while
at
the
same
time
trying
to
it
represent
the
same
things
that
the
attestations
represent.
Does
that
make
sense.
A
It
does
and
I
think
on
that
end.
I
think
you
know,
there's
a
whole
lot
of
debate
about
what
we
can
do.
You
know
exactly
you
know
what
belongs
in
what
documents
and
at
what
level
and
yeah
it
makes
sense
to
not
be
contradictory.
A
Think
out
of
scope
of
of
this
meeting
of
you
know
stuff,
like
is
an
s-bomb
that
is
scanned
after
the
fact
still
an
s-bomb
versus
an
s-bomb,
that's
based
on
inputs
or
whatever
and
I
think
there's
lots
of
things
there,
because
you
know
even
among
those
tools,
they're
still
contradictory
information,
that's
kind
of
being
in
there,
but
I
I
do
agree,
at
least
generally
that
that
you
know
we
want
to
make
sure
that
the
metadata
is
interchangeable
and
that
it
should
still
represent
largely
the
same
sorts
of
things
and
make
sure
that
there's
not
confusion
that
if
somebody
looks
at
an
s-bomb
with
this
information
and
an
a
salsa
thing
with
other
information,
largely
if,
if
they're,
both
being
built
in
the
same
sort
of
way,
should
not
be
contradictory.
D
Yeah
I'm,
sorry
to
take
this
on
a
tangent.
It's
just
something
that
I'd
like
this
community
to
keep
in
mind
that
not
all
software
is
built.
You
know
using
somebody
else's
managed
Service,
as
especially
the
case
with
operating
systems.
A
I'm
not
sure
I
I
follow
I
mean
salsa
is
just.
You
can
generate
a
salsa
attestation
from
your
laptop.
If
you
wanted
to.
H
It's
not
about
the
locations
about
how
it's
a
matter
of
that.
It's
not
always:
okay,
here's
some
button
to
press
or
here's
some
script
or
it.
This
is
an
automatic
artifact
that
comes
out
of
something,
as
I
normally
was,
but
theoretically,
I
can
just
be
even
like
looking
at
the
transcript
of
a
make
file
output
and
then
just
typing
that,
in
manually
step
by
step
into
a
shell
prompt.
H
A
I
mean
I'm,
just
not
sure
so,
like
with
salsa
right.
It's
just
about
you
know,
there's
different
requirements
for
salsa,
and
then
you
have
as
long
as
you're
following
those
requirements.
You
know
you
could
be
a
different
level
of
salsa
and
so
like,
for
example,
you
can
be
salsa
one
running
it
locally
or
or
generating
the
metadata
locally
in
some
way
right.
But
as
you
kind
of
go
up
higher
and
higher,
there's
increased
sort
of
restrictions
on
stuff
like
what
metadata
is
being.
You
know
how
the
metadata
is
being
generated.
D
Yeah
I
think
Michael.
It
would
actually
make
sense
for
you
maybe
to
join
the
spdx
build
profile
meeting,
but
in
the
meantime
I
think
folks
would
like
us
to
move
on
so
I'm.
Moving
on.
B
Thanks
Michael
yeah
Nisha.
B
On
this,
or
it
looks
like
the
specification
working
group-
would
be
another
good
place
to
bring
this
up
and
yeah
just
just
to
catch
you
up
on
the
slide,
Channel
too
I'm,
not
sure
if
you
saw
it
maybe
you're
already
familiar
with
the
link
said
Adolfo
like
some
of
the
issues
where
some
of
this
is.
B
Maybe
that
was
part
of
the
earlier
point,
but
all
right,
so
we
will
yeah
we'll
we'll
come
back
to
that.
Aaron
I
wanted
to
give
you
the
stage
now,
since
you
were
the
first
one
in
the
in
the
agenda
topic
to
take
us
on
your
presentation
of
gitlab
and
cosine
cool.
I
Sounds
good!
Thank
you
and
I
haven't
rehearsed
this
so
we'll
see
how
long
it
is,
but
probably
shouldn't
take
too
long.
Gonna
share
my
screen.
I
Hopefully
you
all
can
see
my
title
slide:
cool
all
right,
so
I'm,
Aaron
Bakke,
a
lot
of
you
know
me
been
in
the
meetings
pretty
often
I'm,
pretty
happy,
because
I
was
successful
with
as
far
as
I'm
interpreting
it
using
gitlab
and
cosine
to
achieve
salsa
level
2..
So
I'm
going
to
step
you
through
kind
of
at
a
high
level
how
I
was
able
to
do
that
so
I
just
kind
of
threw
some
of
the
verbiage
from
the
salsa
website.
I
I
So
the
salsa
level
tier
requirements
are
pretty
straightforward
as
far
as
I'm
concerned
right,
so
the
source
being
version
controlled
the
build
having
a
scripted
build
and
the
build
having
a
built
service
itself,
not
running
on
a
laptop
the
provenance
itself
being
available
in
the
way
that
cust,
the
consumer,
expects
it
to
be
available
and
formatted
having
it
be
service
generated,
and
then
lastly,
this
is
where
the
cosine
piece
comes
in,
having
it
be
authenticated
the
provenance
itself.
I
So
the
first
three
requirements
are
pretty
easy
to
hit
using
gitlab
right
or
you
know,
even
GitHub
right
so
with
gitlab,
this
Source
being
Version
Control,
so
we're
using
gitlab
as
the
SCM
system
for
the
Repository,
the
build
being
a
scripted
build
so
we're
using
a
gitlab
CI
yaml
file
to
have
that
as
a
scripted
running
there
and
then
the
build
service
being
What's
called
the
gitlab
runner.
So
this
is
sort
of
a
dedicated
machine
that
is
running
as
the
build
service
and
not
just
on
my
developer
style
laptop.
I
So
next,
the
provenance
being
available,
the
requirement
is
being
met
because
the
the
actual
git
lab
CI
job
is
generating
an
artifact.
In
the
salsa
0.2
provenance
spec
in
that
in
Toto
format,
so
we're
able
to
work
with
the
gitlab
organization
and
formatting
that
and
bringing
those
appropriate
variables
into
the
provenance
itself
and
making
that
available.
I
So
when
you
have
the
GitHub,
Runner
and
you're
using
your
builds
your
build
script
right,
the
left,
CI
file,
you
can
set
an
environmental
variable
that
says:
Runner
generate
artifacts
metadata
equals
true,
and
this
will
tell
the
gitlab
runner
to
generate
a
Json
file
which
will
store
that
provenance
in
the
in
the
salsa
0.2
format
and
that
jobber
to
factor
the
actual
metadata
artifact
is
the
job
ID.
So
the
gitlab
CI
job
ID
artifacts
Dash
metadata.json.
I
I
So
finally,
the
last
requirement
having
that
actual
salsa
metadata
authenticated,
so
the
authenticity
and
integrity
can
be
verified
by
the
consumer
of
that
artifact
and
of
that
provenance
metadata,
so
I'm,
using
cosine
to
sine
the
salsa
provenance.
Note
that
you
know
the
in
on
our
requirements
for
salsa.
It
should
be
through
a
digital
signature,
accessible
only
to
the
service
generating
that
provenance.
I
So
I'm,
not
exactly
meeting
that,
because
the
cosine
private
key
and
the
cosine
password
are
these
environmental
variables
that
I
have
inserted
into
the
CI,
and
so
those
are
available
right
and
those
are
being
used
as
the
private
key,
obviously,
and
the
password
for
that
to
do
that
signature.
One
thing
that
I'm
doing,
though,
is
scoping
those
variables
to
an
environment
within
gitlab,
so
that
is
kind
of
creating
a
little
bit
of
a
boundary.
J
I
So,
let's
see
here
so
what
do
I
get
from
achieving
salsa
level?
Two,
not
just
a
lousy
t-shirt.
All
right!
So
now,
I'm
able
to
have
my
consumers
gain
a
greater
confidence
in
in
the
origin
of
the
software
that
I'm
producing
right.
So
now
they
can
review
and
authenticate
the
provenance
and
that's
also
a
format,
and
they
can
use
a
policy
engine
to
verify
that
the
build
Integrity
is
a
little
bit
higher
caliber
or
you
know,
hopefully
what
they
expect
to
see.
I
You
know
for
that
metadata
itself
of
the
artifact
that
they're
going
to
be
consuming.
So,
that's
you
know,
bringing
the
confidence
level
up
rather
than
salsa,
zero
or
negative
one
salsa,
and
you
know
now
we're
able
to
have
a
little
bit
more
information
about
the
artifact.
I
So
the
roadmap
for
salsa
3
right
I'm
not
able
to
exactly
get
there
by
myself,
so
I'm
working
with
Sam
white
who's
on
the
call
from
git
lab
they're
actually
seems
like
they're
getting
there
pretty
soon
to
gen
to
meet
some
of
the
salsa
3
requirements,
specifically
the
non-falsifiable
provenance
requirement.
I
So
this
is
that
thing
that
I
was
talking
about
where
the
the
should
hadn't
wasn't
met
before,
because
now
the
gitlab
runner
is
going
to
be,
the
build
service
is
going
to
be
generating
the
provenance
and
also
using
hopefully
cosine
to
do
the
I
believe
the
keyless
signature
onto
the
actual
provenance
itself,
so
I
won't
even
have
to
do
that
job
or
that
step.
That
I
was
showing.
H
I
Because
now
the
build
service
will
be
signing
that
and
providing
the
signature
for
the
metadata
So.
In
theory,
out
of
the
box,
you'll
able
to
you'll
be
able
to
get
salsa
level.
Two
requirements,
kind
of
like
I,
just
showed
just
from
having
the
metadata
generated
and
signed
by
the
build
service
right
along
with
meeting
some
of
those
other
requirements
are
viewed
and.
G
I
B
B
I
I,
don't
have
it
publicly
available.
I
know
that
these
meetings
are
recorded
put
on
YouTube,
so
at
least
we
can
do
that
might
be
talking
to
gitlab
about
making
some
sort
of
blog
and
also
maybe
six
store
about
making
some
sort
of
blog
post
about
it.
Cool
thank.
B
C
Yeah,
we
can
always
use
help,
reviewing
things
to
make
sure
that
our
implementation
plan
is
good.
The
lab
is
open
source
and
these
are
going
in
our
free
edition.
So
you
know,
of
course,
on
the
development
side.
Community
contributions
are
always
welcome.
I
will
just
add.
Our
eventual
Vision
here
is
to
have
to
flip
the
variable
so
that
these
things
generate
attestation
and
are
signed
by
default,
and
then
you
can
opt
certain
jobs
out
of
it
if
it
doesn't
make
sense
to
generate
attestation
and
find
artifacts
for
a
certain
job.
C
You
know
thinking
about
the
long-term
vision
of
where
software
supply
chain
security
is
headed.
We
really
see
a
need
for
all
packages
to
have
salsa,
II
attestation
produced
and
and
to
be
properly
signed,
and
so,
rather
than
relying
on
individual
projects
to
adopt
this
one
by
one
by
one.
That's
going
to
be
a
really
long,
uphill
battle,
we're
trying
to
make
this
set
up
in
a
way
that
it
can
be
turned
on
by
default
as
much
as
possible.
So
that's
our
vision.
J
Yeah,
so
it's
a
question
about
signing,
so
the
first
one
I
guess
is
for
Sam.
So
do
you
do
you
think?
Are
you
are
you?
Is
it
in
your
plans
to
support
providing
your
idcs
that
we
can
already
see
tokens
that
we
can
use
for,
kill,
assigning
with
six
store.
C
Yeah,
so
just
to
clarify
on
that
issue,
the
plan
at
the
moment
is
actually
to
use
full
po
to
generate
a
short-lived
20
minute
long,
private
key
for
signing
and
then
we'll
just
sign
it
natively.
So
that
way,
the
only
entity,
the
only
thing
that
ever
has
access
to
that
private
key
would
be
the
gitlab
runner
and
the
gitlab
runner
only
you
wouldn't
even
need
necessarily
to
pass
in
a
private
key
to
do
that.
Signing.
J
But
but
are
you
planning
on
offering
that
to
the
the
ODC
tokens
to
get
the
identity
of
the
runner
during
the
build.
C
J
C
J
A
I
Yeah
so
like
you're,
asking
why
I'm
kind
of
like
storing
the
dot
signature
file
later
I
kind
of
try
to
just
keep
it
simple.
So
you
know
my
consumer
can
take.
It
is
a
laundry
list
of
files
right
and
then
validate
that
later.
I'm.
Definitely
keen
and
interested
in
learning,
more
I,
honestly
just
don't
know
as
much
about
the
envelope.
J
Yeah
all
right,
yeah,
I'm
I'm,
not
questioning
it.
It's
just
that
I'm
dealing
kind
of
the
same
thing
about
just
as
opposed
to
attaching
the
attestations
to
images.
How
do
I
provide
those
attestations
to
when
they're
about
files
so
actually.
I
Yeah,
well,
you
know
just
to
quickly
kind
of
jump
on
that.
The
way
that
you
know
these
These
attestations
are
being
created.
If
you
have
a
lot
of
artifacts
coming
out
of
your
build
you're,
actually
going
to
have
a
lot
of
salsa
attestations
right
at
the
end
of
the
day,
it's
not
just
one
attestation
the
hand
over.
So
maybe
that's
what
you're
kind
of
referring
to
with
the
envelope
which
I
want
to
look
into
more
as
well.
Keep
it
simpler,
yeah.
B
Nope
cool
David,
I'm
gonna,
put
you
on
the
spot,
while
you're
here,
because
I
noticed
I
have
an
action
item
from
last
time
to
get
an
update
on
what's
happening
at
the
tack
level.
B
I
think
we
had
Melba.
Do
you
remember
the
specific
questions
we.
F
Had
it,
it
was
around
what
they
were
gonna
do
with
salsa,
because
salsa
isn't
the
way
it's
organized
is
very
different,
and
so
they
were
considering
potentially
bringing
out
salsa
or
somebody
had
mentioned.
Maybe
we
should
bring
out
salsa
out
from
under
the
supply
chain.
Integrity
working
group,
so
I
was
just
wondering
what
what
they
were
going
to
do
with
salsa.
E
I,
don't
me
if,
if
that
was
mentioned
in
passing,
it
certainly
hasn't
raised
up.
If
anything,
the
way
that
salsa
works
is
now
increasingly
the
way
everybody
else
is
working
so
I
mean
he
really
just
comes
down
to
working
groups,
typically
work
on
multiple
things
and
start
firing
up
other
groups
when
they
get
too
big,
and
so
salsa
I
mean
salsa
is
not
the
only
one.
The
best
practices
badge
and
scorecards
have
their
own
meat
have
their
own
gatherings.
E
The
best
practices
working
group
has
an
education
Sig.
That
is
then
split
into
three
other
groups,
because
after
a
certain
point,
having
a
meeting
of
thousands
trying
to
do,
everything
is
not
nearly
as
efficient
as
having
a
small
group
focused
on
something
specific,
so
I
don't
I
the
tech.
E
Most
recently
I
mean
the
attack
has
been
trying
to
kind
of
keep
up
with.
What's
going
on,
but
they're,
almost
wrapped
up,
they're
voting
right
now
and
I
think
it's
about
to
get
approved
on
a
pull
request
called
112,
which
is
basically
going
to
try
to
formalize
a
lot
of
stuff.
That's
been
happening
in
the
past,
and
so
so
I
mean
there's
I
mean
salsa
is
part
of
as
far
as
I
know.
It's
also
is
absolutely
still
part
of
the
supply
chain,
Integrity
working
group
and
so
the
intent
is.
E
The
salsa
should
occasionally
report
up
to
the
working
group
The
working
group,
which
occasionally
pour
up
the
pack
more
just
so
that
people
are
at
least
so
that
the
right
hand
at
least
is
vaguely
aware
of
what
the
left
hand
is
doing
yeah.
So
right
now,
they're
they're
I,
one
thing
that
is
coming
to
fruition,
but
I
mean
it's
a
naming
thing.
It's
not
anything
serious
I,
don't
think
is.
If
something
is
primary,
it
does
a
lot
of
code.
E
F
E
You're,
not
the
only
one
with
that
challenge:
I
lead
the
best
practices
badge
same
issue,
we've
got
code,
we
also
have
a
spec,
but
the
codes
allow
the
actual
work
at
this
point.
So
I'm,
probably
just
gonna,
leave,
calling
it
a
project.
But
of
course
it
has
a
spec.
Scorecards
is
the
same
problem.
Salsa
I,
don't
know
if
it's
a
problem
but
same
situation,
so
I
I
think
I
probably
would
raise
back
up
to
the
to
the
attack
all
right.
E
What
do
you
mean
when
we
do
both
but
I
I
think
I?
Think
in
cases
where
you
do
both
well
I
mean
I'm?
Not
the
tech
I
would
suggest,
try
to
make
a
reasonable
determination
justify
it,
mention
it
and
see
if
anybody
screams
knowledge
but
calling
something
a
project
or
a
Sig.
It's
the
goal
is
to
be
helpful
to
help
other
people
understand
it's,
it's
not
you
have
to
be.
E
You
know
you
have
to
be.
You
have
to
name
things
instantaneously
or
somebody
will
beat
you
over
the
head,
foreign.
E
You
know
help
folks
up,
but
I
I
can't
firmly
speak
for
the
pack,
but
that's
I
mean
really
right
now.
You
know
you
know
in
the
transition
from
no
money
to
actual
money
they
wanted
to
formalize
stuff,
which
is
fine,
but
that's
kind
of
been
taking
up
some
of
their
time,
but
yeah
I
know
of
nothing
that
says
you
know
hey.
It's
also
kick
out.
No!
No!
No!
No!
No!
No!
No
you'd
say
it's
a
hey.
We
may
rename
do
a
Sig
I.
G
Think
there
was
some
informal
discussion
in
a
kind
of
sidebar
or
an
attack
meeting
about
whether
salsa
fits
or
how
salsa
fits
in
the
new
like
proposed
structure
in
that
PR,
you
mentioned
one
one:
two,
oh
okay,.
E
I
think
that's
fairly
straightforward:
we've
got
several
working
groups
and
the
working
groups
routinely
kick
off
other
groups
inside
them,
calling
them
either
projects
or
six
projects,
meaning
more
code
focused
Sig,
meaning
not
code
focused
and
obviously,
in
the
case
of
something
like
salsa
or
even
worse,
the
best
practices
badge
and
scorecards.
They
do
both.
My
I'm
I
have
to
admit
I,
think
of
salsa
as
more
a
not
code.
There
is
code,
but
the
spec.
That's
that
I
think
everybody
focuses
on
at
least
in
the
past.
E
Now
I,
you
know
as
more
and
more
code
and
tools
gets
involved.
Maybe
that's
wrong,
but
you
know
if
we
decide
to
have
one
name
and
rename
to
something
else:
that's
not
really
a
problem.
They
just
want
to
have
a
way
of
your
within
this
working
group
and
that
reports
the
attack
so
that
there's
an
opportunity
to
hear
about
other
things,
as
opposed
to
the
big
surprise,
12
months
later.
That's
what
they're
trying
to
avoid.
G
Yeah
I
think
it's
mostly
about
making
sure
that
all
the
groups
are
connected
right
and
so.
E
That's
right,
that's
right,
and
it's
not
I,
even
I
can't
show
up
at
every
meeting
in
spite
of
rumors
to
the
contrary,
but
yeah
it
so,
no
matter
what
there
will
always
be
something
you
heard
about
more
recently
than
when
it
happened.
It's
just
the
nature
of
bigger
projects,
but
trying
to
limit
it
to
five
people
is
not
a
solution
and
a
big
problem
like
this.
So
we're
trying
to
let
people
move
forward
fast,
while
at
least
giving
an
opportunity
to
to
share
information
as
we
go.
E
B
E
Well,
any
kids,
regardless
of
that
particular
day
I
mean
the
goal
is
to
you
know,
hey
occasional
report
through
the
working
group
up
to
the
tech
and
that
way
at
least
there's
some
awareness
and
by
all
means
you
know,
blog
posts
and
other
things
to
try
to
keep
people
aware.
What's
going
on.
B
Cool
alrighty
I
think
that
is
it
for
today.
Any
last
minute
questions
comments,
nope
all
right:
everyone
have
a
good
day
and
thanks
again
Aaron
and
Sam
for
the
great
demo.
It
was
awesome
and.