►
From YouTube: SLSA Bi Weekly (June 9, 2022)
Description
Meeting notes: https://docs.google.com/document/d/1cx3fOBfic6A0xc2on25ITK4vQHUdxgBmJoSS1LPqDJo/edit
A
C
C
A
All
right,
that's
for
next
time,
yeah
there
was
a.
There
was
a
cool
post
from
it's
suse
of
people.
I
don't
have
the
link
here,
but
how
they're
reaching
is
also
level
four
and
so
yeah.
I
see
avashek
added
a
potential
future
talk
on
this,
so
if
anyone
knows
about
that
or
can
speak
to
it,
that
would
be
awesome
to
see
in
the
future.
E
F
A
D
A
B
B
Some
of
the
open,
like
efforts
that
have
been
proposed
in
the
roadmap
so
and
you
can
see
in
a
minute
we've
we've
got
four
possible
groups
that
we
could
form
so
focusing
around
getting
the
1.0
version
of
the
spec
out.
One
focused
around
alignment
with
standardization
efforts,
particularly
the
ssdf
framework
from
nist,
I
think,
and
all
the
s-bum
efforts
that
are
happening
and
one
work
stream,
as
isaac
suggested
focused
around
tooling
and
another
focused
around
vulnerability
management.
B
F
F
We
want
to
make
sure
that
it's
clear
that
it's
not
like
some
sort
of
closed
group
anybody's
allowed
to
sort
of
participate
and
contribute,
but
we
do
want
to
make
sure
that,
like
hey,
your
participating
in
these
groups
should
mean
that
you
are
sort
of
dedicating
at
least
some
time
here.
There's
no.
Currently
you
know
once
again.
This
is
just
like
a
pitch,
I
believe,
there's
no
actual
times
for
anything
yet
and
yeah.
F
B
Yeah
so
good
questions.
I
think
nothing.
This
is
just
like
the
seat
of
an
idea
and
the
main
motivation
is
to
be
able
to
get
to
make
progress
on
some
of
the
things
that
might
require
discussion
in
consensus
building,
but
probably
don't
need
all
30
participants
in
the
cult
to
be
involved,
so
there's
definitely
no
intent
of
any
kind
of
exclusion.
B
And
if
you
have
ideas
about
how
to
achieve
this
recommendations
or
success
stories
from
other
similar
efforts,
then
we'd
be
happy
to
hear
them
and
learn
from
them.
And
and
as
for
the
question
of
like
alignment
with
other
openstaff
working
groups,
I
suspect
there
will
be
some
attempts
to
kind
of
interact.
B
F
H
H
To
show
up
and
participate
in
these
things
totally
welcome,
there's
no
exclusionary
intent.
I
think
it's
just
that,
like
the
intent
is
convergence
and
and
forward
motion
on
a
number
of
things,
so
I
think
I
mean
the
one
suggestion
I
would
have
is:
potentially
the
alignment
of
the
ssdf
and
s1
we
generalized
into
you
know:
alignment
with
you
know
adjacent
concerns
and
that
group
can
start
with
ssdf
and
s1,
but
potentially
over
time
we
may
want
to
look
at
skip.
F
F
Is
I
really
like
how
the
cncf
security
tag
handles
some
of
this
stuff,
which
is
they
sort
of
like
they
split
out
the
different
sort
of
work
streams
and
then,
like
a
meeting
like
this,
would
be
available
for
sort
of
updates
from
those
work
streams
like
that
would
be
like
the
first
like
15
minutes
of
the
meeting
or
whatever
is
usually
dedicated
to
you
know:
hey.
Are
there
any
updates
from
this
work
stream?
Anything
that
should
be
brought
to
the
larger
group
and
and
those
sorts
of
those
sorts
of
things.
B
I
Yeah
I
just
wanted
to
share
a
little
bit
about
like
how
we
hardly
say
cncf.
We
do
the
work,
the
working
groups
and
stuff
like
that.
I
think
we
found
that
having
a
kind
of
proposal
around
deliverables
would
really
help
drive
the
working
group,
if
not
it
kind
of
comes,
if
not
it
kind
of
like
goes
into
too
many
directions.
So
I
I
think,
that's
helpful.
If
we
have
anything
that
we
can
kind
of
like
list
out
as
like
a
particular
developers.
B
B
H
F
So
so
one
quick
thing-
and
I
think
it's
probably
sort
of
related
to
at
least
some
of
this
stuff
is-
is
I
have
a
feeling
you
know
most
likely
it'll
start
one
way
and
then
over
time
shift
a
little
bit.
I
think
one
of
the
big
things
here
that
I
know
we
want
to
that.
I
know
is
a
big
one,
like
the
salsa
1.0
thing
here
of
like
hey
there's,
you
know
as
since
we
started
a
little
less
than
a
year
ago.
F
A
lot
of
folks
have
you
know
a
lot
of
stuff
has
sort
of
changed
and
there's
also
been.
You
know
a
reasonable
amount
of
confusion
on
like
hey.
What
does
does
this
thing
count
as
salsa?
This
thing
not
count
to
salsa?
Oh,
hey!
Here's,
a
here's,
a
big
gap
in
what
we're
doing
so.
I
think
you
know.
A
lot
of
this
for
now
is
is
also
very
much
like
a
short-term
hey.
F
We
need
to
get
some
big
things
done
sooner
rather
than
later
to
to
stop
some
of
that
that
confusion,
because
you
know
if,
if
folks
are
keeping
an
eye
on
the
github
you'll
notice,
there's
there's
a
lot
of
folks
asking
the
same.
You
know
opening
up
similar
github
issues
about
either
a
confusion
with
a
thing
or
saying
hey.
How
are
we
mapping
to
other
things
and
and
that
sort
of
stuff?
So
I
think
we
want
to
also,
as
part
of
this
like
really
get
together
and
start
start.
F
You
know
pounding
out
some
of
that
work
and
then
I'm
sure
over
time.
You
know
if,
after
three
months
go
okay,
we
did
this
whole
bunch
of
stuff
and
now
some
of
those
work
streams
are-
maybe
you
know
not
don't
have
as
much
to
do.
We
can
probably
you
know,
switch
it
up,
make
it
more
part
of
the
regular
meeting,
whatever.
B
Yeah
and
the
the
work
streams
are
aligned
to
things
that
all
the
the
straw
person
work.
Streams
in
the
dark
are
aligned
to
like
scenes
in
the
road
map.
So
it's
entirely
possible
that
in
six
months
time
we
we
review
the
road
map
and
say
well
that
work
stream,
like
mike
said,
is,
is
wrapped
up,
but
we've
we're
going
to
start
a
new
road
map
with
a
different
work
treatment,
change,
change,
meetings
for
that.
A
H
H
C
J
So
I
just
wanted
to
take
it
to
this
group
and
get
your
thoughts
on
that.
What
exactly
that
should
be?
I
could
see
actually
potentially
three
different
things
that
that
could
be.
I
could
see
that
being
like
a
list
of
the
environment
variables,
especially
in
the
context
of
git
lab
and
building
something
inside
of
gitlab.
It
could
be
the
you
know,
those
environment
variables
that
are
passed
into
the
ci
job.
It
could
potentially
be
like
the
variables
itself
or
the
script
portion
of
the
build
job,
or
maybe
it
means
like
the
exact
command.
J
That's
used
like
if
it's
a
make
command.
You
know
what
parameters
are
passed
into
that
make
command
and
I
wasn't
really
sure
which
of
all
of
those
would
be,
and
then
it
also
was
brought
up
that
there's
some
potential
for
secrets
to
be
exposed,
because
actually
you
know
there
are
a
lot
of
different
builds
out
there
and,
if
we're
turning
this
on
by
default
for
all
of
the
builds
that
are
done
in
gitlab,
there's
the
potential
that
those
would
include
secrets
of
some
kind
for
any
of
those
three.
J
F
F
You
know
it
would
be
the
inputs
there.
Salsa
still
is
flexible
enough
where,
if
for
some
reason,
you
know
you're
not
doing
it
that
way
and
how
you're
just
sort
of
saying
like
hey,
I'm
I'm,
you
know
running,
you
know
some
shell
script
and
then
your
inputs
would
be
the
inputs
to
that
shell
script.
Something
like
that.
So
I
think
there's
some
flexibility
there,
but
if
you
combine
it
with
some
of
the
other
sort
of
build
service
should
be
doing
these
things
sort
of
requirements.
F
J
So
would
it
be
the
inputs
to
that
specific,
build
step,
or
would
it
be
so
again
like
in
gitlab
we
have
environment
variables
and
those
get
employ
applied
to
the
entire
ci
pipeline
when
it
kicks
off.
You
know
the
the
ci
pipeline
as
a
whole,
and
then
you
also
potentially
have
those
environment
variables
also
act
as
inputs
into
each
of
the
different
jobs
that
get
run,
and
then
you
have
your
individual
build
job
with
the
script
that
gets
executed
there.
J
F
Somebody
who
has
access
and
whatever
is
auditing,
can
go
back
and
say:
okay,
well,
the
shell
script
hook
that
they
used
was
this
one?
I
can
go
back
and
then
look
at
the
environment
variables,
look
at
the
shell
script
or
whatever
or
look
at
you
know
how
it's
called
and
and
be
able
to
pull
that
through
and
be
able
to.
You
know
determine
like
how
what
was
actually
run.
I
think
like,
because
at
the
end
of
the
day,
it's
all
about
like
the
goal
here
is
just
to
kind
of
figure
out.
F
J
Got
it
okay,
so
that
makes
sense
as
far
as
what
the
spec
is
requiring.
I
guess
the
follow-up
question
to
that,
then,
would
just
be
you
know,
of
course
it's
not
best
practice
to
expose
secrets
in
that
way,
but
we
actually
have
you
know.
Environment
variables
can
be
configured
as
protected.
They
also
can
be
configured
as
hidden,
and
so
generally
users
will
put
secrets
there,
and-
and
actually
it
is-
you
know,
considered-
you
know
reasonably
safe
to
put
secrets
in
that
are
protected
or
hidden.
J
A
lot
of
users
will
do
that
and
some
users
will
still
put
in
secrets
that
are
not
protected
or
hidden
variables,
and
it
sounds
like
what
we're
actually
looking
for
here
to
meet.
The
requirement
would
require
us
to
to
output
all
of
the
variables,
even
if
they
are
protected
or
hidden,
so
that
they
could
fully
reproduce
that
build,
but
then,
at
the
same
time,
if
we're
publishing
that
as
an
artifact
there's
some
potential
there
for
secret
exposure.
So
I
don't
know
what
are
your
thoughts
on
how
to
balance
that.
C
K
That's
that's
a
huge
issue
with
security,
so,
in
this
context,
using
tools,
as
I
noted
in
the
chat
like
whispers
or
blue
bracket
or
other
components
that
will
actually
scan
your
code
at
various
times
in
a
pipeline
to
verify
that
none
of
those
are
accessible
would
be
would
be
a
key
component.
I
don't
believe
that
any
of
the
reports
should
have
it
any
of
that
data
in
them.
It
should
note
that
there
is
a
potential
issue
and
where,
in
what
file
it
exists
in,
but
I
don't
know
that
we
ever.
I
K
K
I
don't
think
they're,
you
know
in
a
perfect
world,
if
you're,
following
kind
of
best
practices
or
good
practices,
as
the
case
may
be,
you
really
don't
want
to
have
any
any
of
those
critical
or
crucial
keys
or
identifying
or
secure
authentication
type
of
components.
Inside
of
any
of
your
files,
which
I
think
you
know,
I
certainly
heard
others
say,
but
you
know
it
really
should
be
part
of
the
maturity
or
the
level
to
decide
you
know.
J
Yeah,
so
just
a
minor
clarification
there,
these
variables
or
or
potential
secrets
would
not
actually
be
stored
in
files
in
the
repository,
but
they
would
just
be
being
passed
in
as
environment
variables,
but
it
sounds
like
your
suggestion
is
just
to
avoid
passing
in
secrets
of
any
kind
which
I
know
at
least
for
some
organizations.
Some
builds
may
still
require
those.
K
Well,
but
even
so,
if
you're
automating
this
this
process,
which
would
be
the
right
recommended
way
of
doing
it,
you
you
can
certainly
make
those
variables
that
are
passed
in
you
know
come
from
an
encrypted
source
and
they're
they're,
not
something
that's
being
manually,
entered
or
allowed
to
be
manually
entered
right.
This
is
the
conversation
about
at
what
level
are
we
fully
automated
versus
somebody's?
Doing
this
manually
would
be
the
the
conversation
point.
I
think
we
would
also
need
to
discuss.
C
K
Think
the
aim
for
for
doing
this
would
be
to
automate
as
much
as
possible
to
remove
the
potential
for
a
human
to
make
the
these
kind
of
mistakes
or
to
hack.
The
system
would
be
my
my
opinion,
but
certainly
you
know
point
taken
you
know.
Sometimes
some
people
will
manually
do
this,
but
in
an
automated
system,
there's
certainly
ways
around
that.
J
Right
so,
if
there's
an
automated
system
in
place,
do
we
still
include
those
those
you
know
those
variables
as
inputs?
You
know,
they're
they're
technically
are
like
build
instructions.
They
still
ultimately
get
passed
into
the
build,
even
if
it's
coming
from
an
encrypted
or
automated
source,
I'm
almost
wondering,
if
maybe
we
should
store.
Instead,
you
know
put
in
the
provenance
like
a
pointer
and
just
say
we
reference
this
variable
in
this
location.
B
Yeah,
the
point
is
to
be
able
to
reproduce
the
build
right.
So
if
your
build
service
can
reproduce
the
build,
it
has
enough
information,
whether
I
don't
think
it,
I
don't
think
anyone's
suggesting
you
store
all
of
that
secret
information
as
part
of
the
providence
metadata,
but
that
there
is
enough
information
in
the
province
metadata
that
you'll
be
able
to
reproduce
the
builder
at
life
point,
and
I
think
the
other
part
that's
worth
thinking
about
is
that
salsa
today
is
increasingly
like
we're
trying.
B
B
Can
I
recreate
the
same
subject
for
the
same
output,
artifact
and
so
how
many
of
those
secrets
are
actually
directly
influencing
the
produced
artifact
as
well.
So
you
wouldn't
necessarily,
if
you're
running
a
very
built
vulnerability
scanner
as
part
of
your
pipeline,
and
you
need
a
secret
to
authenticate
to
it.
That
secret
is
not
necessary
to
reproduce
the
artifacts
that
the
problems
metadata
is
describing
right.
F
No,
no
yeah,
no
yeah.
The
only
thing
I
was
just
gonna
was
just
gonna,
say
yeah,
like
the
way
that-
and
I
know
that
this
is
not
available
for
everybody
yet
but
yeah.
I
like
the
way
we've
sort
of
done.
It
is
like
often
the
the
secret
is
something
that
is
like
a
pointer
to
some
location
where
the
secret
is
or
whatever,
and
you
know
that's
how
you're
requesting
the
build.
You
know
the
build
itself
would
request
the
secret
get
a
token
that
kind
of
thing
yeah
I
think.
F
This
source
code
was
with
these
parameters
in
this
build
script
or
whatever.
That
means
I
can
go
in,
you
know,
and
this
was
also
the
build
environment.
So
now
I
can
go
in
and
repeat
that
build
you
know,
because,
because
the
the
spirit
of
what
we're
trying
to
get
across
here
is
yeah
like
can
you
if,
given
the
same,
build
environment
by
that,
I
just
mean,
like
you,
know,
container
image
os
whatever
packages
yeah
build
script,
source
code
and
parameters?
F
Could
I
rerun
the
thing
and
then
it's
okay
to
say
certain
things
like
secrets
are
things
you
need
to
essentially
re-request,
because
we
don't
you
know,
record
or
log
the
secrets
separately.
I
think
you
know
we
also
need
to
just
sort
of
like
if
folks
are
sort
of
worried
because
they're
like
oh
I'm,
not
sure.
If
I'm
putting
my
secrets
in
the
clear,
I
think
that's
sort
of
a
separate
problem
where
we
say
like
I
would
almost
be.
You
know
if
I
record
that
and
I
go
oh
wow.
F
I
should
not
be
doing
that
and
know
to
fix
it
rather
than
just
sort
of
say
hey.
I
don't
record
my
bills
because
I
might
be
doing
something
silly
in
those
builds
I'd.
Much
rather
know
that
I'm
doing
something
bad
and
go
and
correct.
It
then
just
say
you
know
what
I
might
be
doing
something
bad
I'd
rather
not
know.
J
Got
it
okay?
So
I
think
at
this
point
I
have
enough
information
to
to
bring
this
back.
It
sounds
like
what
I'm
hearing
is
that
the
key
piece
here
is
just
being
able
to
either
repeat
the
build,
as
you
said,
or
reproduce
the
build.
But
the
key
point
is
that
you
have
the
instructions
that
are
necessary
and
we
don't
necessarily
have
to
add
the
value
of
any
environment
variables
in
to
the
provenance.
J
J
J
You
know
we
have
a
lot
of
users
in
a
lot
of
different
scenarios
and
circumstances,
and
you
know
by
and
large
typically
we
don't
see
people
manually
putting
in
variables,
but
we
do
see
them
storing
them
as
environment
variables
and
they
may
even
be
taking
appropriate
precautions
to
mask
them.
You
know,
protect
them,
make
them
hidden
and
so
forth,
but
you
know
those
do
still
ultimately
get
fed
in
and
they
also
reference.
J
You
know
variables
from
other
systems
like
we
have
an
integration
with
vault,
so
they
may
be
referencing
secret
store
stored
in
vault
as
part
of
their
build
instructions,
and
so
you
know
even
if
it's
being
brought
in
in
an
encrypted
automated
fashion,
those
are
still
build
inputs,
and
so
that's
where
we're
running
into
that
confusion
about
how
might
we
meet
this
salsa
requirement
without
exposing
those
secrets?
But
I
think
I
have
what
I
need
here
to
to
move
forward.
A
B
A
A
With
there's
a
few
outstanding
issues
that
we
need
to
get
through
around
the
scope
of
salsa,
which
I
know
is
a
work
in
progress
thing
in
the
governance
because
we
have
a,
we
have
a
governance
structure
now
with
the
steering
committee
and
so
looking
at
that
again
so
hope
to
have
more
updates,
probably
next
meeting
and
then
the
one
thing
here
is.
We
do
need
some
points
of
contact
for
the
code
of
conduct
melba.
Thank
you
for
volunteering.
A
H
H
You
know:
we've
incorporated
some
feedback,
we've
taken
a
pass
today
tonight,
I'd
love
to
get
feedback
broadly
from
the
community,
and
the
link
is
in
slack
there's
a
little
bit
of
discussion
and
slack,
but
to
abhishek's
point
I
think
the
most
productive
thing
would
be
to
move
discussion
comments,
feedback
disagreements
ads
to
the
pr
itself,
and
so
I
invite
everyone
to
do
that.
Thanks
in
advance
really
appreciate
your
input
emmy.
I
appreciate
your
your
input
as
well.
H
I
know
you
gave
some
feedback
on
early
draft
michael
same
to
you
as
well.
I
appreciate
that
I'm
so
so.
Please
look
for
your
your
previous
feedback
to
incorporate
it
in
this
draft,
and
let
me
know
if
you
think
that
it's
not
and
yeah
looking
forward
to
getting
this
out
with
with
y'all's
review
and
approval.
Thank
you.
F
That
should
be
interesting
and
there's
a
bunch
of
initiatives
across
the
cncf
open
ssf
to
start
doing
some
of
these,
like
mappings
and
and
how,
like
you,
know,
who's,
you
know
what
standards
best
practices
are
responsible
for,
what
that
could
prove
to
be
really
interesting,
and
then
I
also
know
that
some
folks
have
been
chatting
about.
Could
we
do
like
a
salsa
oscar
model,
potentially
once
maybe
we're
a
little
bit
closer
to
like
something
like
1.0.
H
That's
a
it's
a
great
idea,
and
I
think
you
know
it
comes
back
to
the
idea.
You
know
joshua's
proposal
for
the
work
streams.
I
think
that
would
be
a
you
know:
alignment
with
adjacency's
work
stream
topic
could
be
hostile.
I
think
that
the
mapping
thing
has
been
super
interesting
to
think
about
ssdf,
because
there's
definitely
the
mapping
in
terms
of
the
you
know:
salsa
requirements
to
ssds
tasks
and
practices
and
there's
a
question
of
kind
of
the
scope
of
the
coverage
there.
H
Just
that
you
know
the
recommendations,
requirements
themselves
and
I
think,
there's
also
a
useful
comparison
to
be
made
between
ssdf
and
sales,
with
ssd
being
a
descriptive.
You
know
non-prioritized
non-sequenced
set
of
tasks,
whereas
salsa
is,
is
much
more
prescriptive.
It's
implicitly
sequenced
by
the
levels.
H
I
think
it
actually
makes
ulcer
an
interesting
and
useful
complement
to
ssdf
that,
if
salsa,
it
feels
to
me,
has
the
flavor
of
a
transformation
framework
where
you
know
you
can
grab
on
the
the
bottom
rung
of
the
ladder
and
whatever
rung
you're
on
the
next
rung
is
usually
within
reach.
You
can
climb
them
up
better
climb
up
these
rungs.
I
think,
just
from
a
a
pragmatic
standpoint,
I
really
like
the
approachability
of
salsa
and
for
folks
who
aren't
skilled
in
the
arts
of
interpreting
and
complying
with
government
regulations,
so
do
do
yeah.
L
H
That's
a
good
question.
I
mean,
I
think
that
the
last
last
blog
post
we
did
along
these
lines
was
with
salsa
and
s
bomb,
and
I
think
that
was
kind
of
that
was
in
this
review
period
for
about
a
week
or
so
it
would
be
great
to
aim
for
that
that
same
amount.
But
I
I
dare
say
you
know
we'd
like
to
get
you
know,
broad
consensus
and
then
folks
nodding
along
with
the
content
in
the
blog
post.
L
Okay,
so
a
couple
of
thoughts
here
I
made
an
a
note
in
the
in
the
document
itself
about
the
mapping
piece,
so
I
have
a
I
have
that
mapping
in
a
spreadsheet
of
like
each
control
and
which
ssdf
control
like
which
ssdf
line
it
goes
to,
but
there's
also
excuse
me
nist
sp
800-161r1
that
has
extensive
detail
in
it.
That
also
directly
maps.
L
H
Think
that
that
would
be
great,
would
you
mind
paying
that
to
me
at
me
and
I
can
I
can
take
a
look
and
where
we
might
anchor
that
in
the
blog
post,
that
would
be
great
yep.
I
think
the
other
thing
I
mean
since
since
you're
here
that
you
raised
a
really
interesting
input
on
the
last
draft,
around
automation
and
tooling
itself,
and
I
think
there's
I
think
it's
it's
a
good
point.
I
think
that
salsa
definitely
needs
an
automation
and
tooling
component.
H
It's
not
clear
to
me
the
extent
to
which
we
think
of
tools
and
automation
as
within
the
scope
of
salsa
itself
versus
you
know
the
enabling
ecosystem
around
salsa,
and
so
I
I
think
your
your
point
of
view
is
is
well
taken
that
you
know
tools
and
automation
are
an
essential
piece
of
making
salsa,
ultimately
scalable
and
adoptable,
but
the
specification
itself
doesn't
speak
to
or
or
cover,
automation
or
tooling.
I
don't
know
what
other
people
think
about
how
people
think
about
the
scope
of
salsa
in
that
frame.
K
I
could
make
a
comment
on
that.
This
is
eric
in
context.
You
know
in
the
best
practices
working
group
and
the
tooling
working
groups
for
openssf.
This
is
the
topic.
That's
come
up.
I
brought
some
of
this
up
before,
but
it'd
be
great
to
actually
have
some
cases
shown
with
some
example.
Pipelines
put
together
that
adhere
to
the
salsa
framework,
based
on
the
tools
that
are
suggested
in
those
working
groups
and
having
some
actual
actionable
workflows
and
cases
that
show
each
level
of
salsa
compliance.
K
H
Eric
I
mean
I
it
feels
like
I
mean
potentially
there's
I
mean
I
know
we
had
tooling
as
a
proposed
work
stream
and
and
potentially
that's
something
which
that
work
stream
could
pick
up
is
looking
at.
You
know
what
are
the
key,
you
know,
kind
of
user
or
practitioner
journeys
are
around
salsa
and
what
tools
today
support
them?
I
I
L
L
L
We
need
to
rethink
that
control
and
how
we're
putting
that
out
there,
because
it's
not
going
to
be
a
customer,
is
not
going
to
understand
that
we
can't
verify
that
salsa
requirement,
so
we're
never
going
to
be
able
to
meet
it.
So
having
automation
in
mind
at
the
same
time
as
we're
creating
a
framework
at
the
same
time,
we're
talking
about
the
framework
is
going
to
increase
adoption
right,
and
so
that's
that
was
my
intention
of
kind
of
highlighting
that.
H
That's
a
great
point,
and
let
me
take
that
and
make
sure
we
do
weave
that
in
to
to
explicitly
say
that
you
know
the
salsa
working
groups
considers
automation
as
a
as
a
critical
piece
of
adoption
we're
working
on
it.
We
have
our
attention
on
it
and
there
there
is
a
work
stream
around
it.
I
think
your
right
is
an
important
point
to
land
that.
Yes,
we
consider
that
the
tooling
ecosystem
around
salsa
is
critical
to
adoption
and
we
have
a
focus
on
it.
F
So
two
things
along
those
lines.
One
is,
I
think,
also
one
of
the
things
that
you
know:
it's
not
the
the
the
autumn,
not
just
the
automation,
tooling,
that
helps
us
sort
of
achieve
salsa,
but
also
like
there's
kind
of
a
a
hierarchy
of
like
you
have
your
ssdf,
which
is
very
descriptive.
You
have
your
salsa,
which
is
prescriptive,
but
still
sort
of
very
agnostic
on
how
you
sort
of
get
there
and
then
there's
kind
of
a
level
down
there
of
like
if
you're
in
the
cloud
native
space.
F
If
you,
if
you're
doing
these
sorts
of
things-
and
you
know
you
don't
have
signing
keys
or
whatever
we
can
do,
salsa
one.
For
you
know
this
is
what's
also
one
would
look
like
if,
if
you
have,
you
know,
signing
keys
and
a
build
service,
this
is
what
salsa
2
does
for
you
hey
if
you're
using
spiffy
spire,
and
you
know
very
short-lived
identities
where
we
can
sort
of
do
more
of
that
non-falsifiability.
A
E
No,
I
I
can
just
give
a
quick
overview
if
you
want
okay
yeah.
So,
let's,
let's
begin
so
last
year,
we
noticed
that
salsa
exists
basically
fresh
as
it
was
published.
We
went
and
presented
that
to
our
management
and
management
likes
it.
They
like
having
certifications
like
showing
something
off
and
so
on,
and
they
tasked
us
this
doing
gap
analyzers
to
see
what
exactly
is
missing
with
our
build
service
with
our
product
development
and
they
set
us
the
goal
to
have
something
to
announce
here
at
susicon.
E
So
we
implemented
this
from
looking
at
from
the
outside,
on
your
web
pages,
on
your
documentation
on
your
standards
and
so
on
so
and
and
worked
from
that
from
that
angle,
our
museum's
enterprise
products
are
built
by
a
build
service
that
we
also
call
it
build
service,
something
that
suse
has
developed
on
their
own
core
and
also
open
source
called
open
or
open,
build
service,
and
we've
been
doing
that
for
15
years
plus.
So
it's
also
second
generation.
E
So
there
was
something
before
that
it
was
derived
from
and
we
have
actually
been
through
criteria
certification
on
top
of
that
found
that
kind
of
similar
to
what
zeiss
is
achieving
saisa
is
more
descriptive,
more
focused
on
actually
the
build
service
parts
so
that
we
also
really
like
that.
That
part.
E
So
we
went
and
took
a
look,
so
what
the
build
service,
what
a
good
service
is
doing
for
us
at
zoos
is
that
it
manages
our
packages
that
in
turn,
gets
built
into
rpms.
Mostly,
it
stores
the
package
in
separate
projects
and
copying
them
between
projects
is
there's
an
abstraction
called
submit
requests.
You
can
think
of
it
like
a
pull
request
that
can
be
handled
by
that
can
be
yeah
that
can
be
monitored
by
that
can
be
reviewed
that
can
be
accepted
by
humans
or
bots,
depending
on
the
configuration.
E
E
So
the
build
cell
stores
these
sources.
It
actually
builds
them
in
these
kind
of
projects
in
this
kind
of
hermetic
setting,
and
even
as
I
joined
zuzer
like
20
years
ago,
it
was
already
doing.
Change
group
builds
that
turned
into
kbm
builds
that
turned
into
focusing
on
these
builds
in
the
build
cluster
in
a
separate
data
center.
E
So
it
does
the
source
management,
it
does
the
build
management
and
in
the
end
it
produces
and
also
science
rpms.
It
collects
rpms
into
ftp
trees
into
isos
into
container
images
these
days
or
several
forms
of
public
cloud
every.
So
it's
something
really
from
checking
in
resources
to
have
in
the
final
binary
site.
E
So
we
took
a
look
and
the
kind
of
build
part
like
the
semantic
ephemeral,
these
kind
of
conditions,
at
least
what
we
read
from
the
standard
we
are
meeting
and
we
communicated
that
back
to
our
management
management
said:
please
reach
out
to
level
four,
at
least
for
the
0.1
standard.
So
we
interpreted
that
and
went
through
that,
so
we
had.
E
So
that
was
a
bigger
change
that
we
had
to
go
through
and,
of
course,
the
whole
provenance
topic.
So
we
really
started
generating
provenance
from
scratch
in
our
tooling
so
that
the
build
service
was
keeping
this
kind
of
built
environment
structure
already,
but
in
an
internal
form,
an
internal
xml,
plain
text
blob.
So
that's
something
that
our
team,
our
build
service
implementation
team
worked
on
to
generate
in
total
provenance,
and
it's
something
where
we
reached
a,
I
think,
a
good
level.
We
still
need
to
think
with
the
actual
in
total
efforts.
E
If
that
is
all
meeting,
what
is
what
is
wanted
there?
What
is
needed
there,
yeah
so
with
with
administration
with
the
common
part,
is
this
fourth,
fourth
pillar.
That
was
a
bit
interesting
because
at
the
same
time
that
we
are
using
the
build
service,
a
separate
team
is
also
developing
it
and
operating
it.
So
that
kind
of
challenge
like
the
operation
challenge,
that
it
also
needs
to
have
the
similar
restrictions
similar
as
a
only
as
small
human
interaction
as
possible.
E
So
we
you
see
us
basically
as
implementers
that
just
looked
at
this
from
the
outside
took
all
the
points
and
went
through
it
and
of
course
we
want
to
continue
this
work.
So
we
see
that
we
can
join
the
community
calls
here
and
follow
up
the
further
standardization
approach.
So
they
are
looking
at
the
1.0
standard
that
you
mentioned
earlier
and
if
we
can
meet
that,
if
you
can
also
help
influence
that
a
bit
or
help
you
help
here
and
this
with
our
view
on
linux
distribution
development.
A
E
F
F
Oh
yeah
yeah,
I
think
one
of
the
things
I
know
I'm
very
interested
in
is
like
yeah,
it's
like
you're,
generating
this,
this
salsa
provenance
metadata.
You
know,
how
are
you
distributing
that
to
let's
say
the
end
users
or
how
can
they,
how
are
they
consuming
it
so
that
somebody
on
who's
consuming
these
packages
can
go
in
and
say
yep?
I
I
validated
that
this
is.
You
know
a
salsa
4
package
coming
from
susa.
E
So
currently
we
put
the
json
files,
besides
our
rpms,
so
on
our
ftp
trees,
not
sure
if
there's
anything
better
so
that
we
have
not
looked
into
that
deeply
yet,
and
also
how
to
do
this
for
isos.
If
we
can
merge
that
or
if
you
can
put
this
in
a
bigger
blob,
also
containers,
that's
something
we
have
also
not
not
yet
deeply
looked
at
yeah
and
the
real
angle
like
how
can
users
look
at
that?
That's
also
an
open
topic
that
we
need
to
investigate.
B
E
Had
a
bit
of
trouble
with,
I
still
have,
I
think,
on
my
item,
how
to
get
covenants
signed
and
how
to
verify
signatures.
That's
something
I
still
need
to
find
out,
but
so
we
are
still
we
are.
We
are
already
doing
this
wrapping
base,
64,
encoded,
strapping
and
signing,
but
how
to
if
the
signature
is
correct.
I
have
not
yet
looked
at
that.
This
was
an
open
topic
for
me.