►
From YouTube: SLSA Specifications Meeting (February 10, 2023)
Description
Meeting notes: https://docs.google.com/document/d/1kMP62o3KI0IqjPRSNtUqADodBqpEL_wlL1PEOsl6u20/edit#heading=h.yfiy9b23vayj
B
A
C
A
So
I'm
with
Anaconda,
we
distribute
packages
for
python
data,
science
and
other
forms
of
data
science,
and
we
are
working
towards
claiming
salsa
level.
Two
compliance
we've
got
some
steps
to
go
to
get
there
at
my
last
job
at
Microsoft,
I
was
working
with
a
standards
group
for
the
healthcare
interoperability,
spec
fire
and
so
I
have
some
experience
with
with
standards
and
I'm
interested
in
salsa,
so
I
thought
I'd.
You
know,
join
and
see
what
you
guys
are
up
to
and
see
how
I
can
contribute.
C
C
B
C
Okay,
so
it
sounds
like
only
like
one
or
two
people:
it's
like
Arno
and
maybe
Melba,
but
otherwise
there'll
be
no
one
else
for
them
to
talk
to
okay,
so
we'll,
let's
just
cancel
them,
and
if
anyone
wants
to
have
ad
hoc
meetings,
obviously
you
can
but
we'll
cancel
for
next
week,
I
marked
it
on
the
agenda
Can.
Anyone
like
I,
don't
know
how
to
do
the
as
openness
of
calendar.
If
someone
could
cancel
that
in
there.
F
C
Behind
schedule
with
the
release
candidate
I
was
talking
to
some
other
of
my
colleagues
and
we're
trying
to
figure
out
like
what's
what's
really
required
for
a
release.
Candidate
and
one
of
the
things
seems
to
be
like
one
of
the
the
last
major
pieces,
the
verification
story
which
was
added
to
1.0
and
is
probably
like
the
least
well
defined
and
I
wanted
to
think
about
like
is
there
any
way
to
carve
it
off
or
somehow
like
make
it
more
tractable?
So
that
way
we
could
get
the
release
candidate
out
the
door.
C
B
C
I've
gotten
so
good
at
that
and
now
I
feel
thank
you.
So
previously
we
added
a
requirement
that
was
not
present
in
0.1.
That
not
only
do
you
need
to
build
properly,
but
you
need
to
generate
like
set
expectations
for
what
it
was
supposed
to
be
built
like
and
then
some
Downstream
thing
has
to
verify
that
and
that
still
hasn't
been
fully
fleshed
out.
So
one
possible
idea
would
be
to
separate
the
verification
piece
into
it's
almost
like
a
separate
level,
but
not
really
it's
almost
like
a
qualifier
again.
C
C
Automatic
verification,
it's
just,
we
call
it
like
ad
hoc
or
something
like
that.
I
didn't
use
numeric
levels
because
I
think
it's
really
actually
tied
to
the
original
level.
It's
like
how
well
it's
enforced
and
probably
goes
along
with
that
also
to
prevent,
like
too
much
confusion
between
numbers,
but
ad
hoc
is
basically
what
we
have
in
0.1,
which
is
like
there's,
no
systematic
or
automatic
verification.
It's
just
like
attestations
are
available.
You
could
check
them
if
you
want,
but
it's
kind
of
on
the
consumer
to
do
that.
C
You
know
maybe
have
something
like
this
and
then
in
the
table
down
here,
there's
a
little
bit
more
text
but
the
but
yeah.
That
would
be
the
the
basic
idea
and
then
on
the
requirements
page
ignore
this
I,
don't
know
how
to
represent
it
in
this
table.
This
is
just
like.
What's
currently
in
my
working
draft,
the
the
levels
I,
don't
know
somehow
we
we
have
to
split
this
out
somehow.
C
C
Rest
of
that
page,
and
so
like,
for
example,
in
the
build
track,
a
change
was
like
I
added
this
piece
if
monitored
or
enforced,
because
before
the
text
was
a
downstream
system,
automatically
verifies,
and
here
it
would
be
like
if
Monitor
and
force
and
down
here
if
monitored,
are
enforced
automatically
the
outfit
anyway.
Any
thoughts.
B
B
Come
to
this
challenge,
I'm
thinking
of
the
common
criteria
for
I.T
techno,
which
had
to
deal
with
a
lot
of
the
same
kinds
of
challenge
what
they
did
is
they
had
a
whole
list
of
what
they
called
functional,
which
is
basically,
you
know
the
first
part
what
we
already
had
and
then
they
had
a
whole
separate
list
of
evaluation.
In
other
words,
how
what
are
the
methods
I
use
to
evaluate
to
determine
whether
or
not
it's
accurate,
and
they
in
fact
have
a
whole
list
of
those
which
were
separate?
B
You
could
actually
have
you
know
loaf.
You
know
only
a
few
require
functional
requirements,
but
I
evaluated
a
whole
lot
of
ways
separately
or
maybe
a
whole
lot.
I,
don't
evaluate
them
very
much
or
evaluate
them
a
lot.
They
originally
had
a
leveling
list,
I
think
technically
they
still
do,
but
a
lot
of
people
don't
bother.
They
just
do
the
pick
and
choose
of
the
evaluation
approaches
that
they
use
and
I
am
a
little
concerned.
I
wouldn't
call
no
automatic
verification,
ad
hoc
I'm,
actually
a
little
skeptical
about
your
term
enforced.
B
If
you
mean
enforced,
means
it's
never
possible
to
have
a
violation.
I
did
that's
kind
of
rough
to
go.
If
you
mean
it's
automatic
in
order
to
prevent
some
violations,
sure
you
know
I
and
at
least
I
would
separate
the
I
provide
attestations
from
I,
provide
attestations
and
someone
else
has
reviewed
it
and
in
many
ways
I
mean
you
you
know.
B
Is
that
better
than
an
automated
analysis,
it
depends
on
what
kind
of
level
you're
going
to
automated
album
analysis
always
has
the
big
plus
of
you
do
it
every
time
is
the
big
minus
of
usually
misses
Lots,
so
so
so
I
I,
don't
I,
don't
know
if
the
implied
leveling
makes
sense.
It's
more
of
a
just
a
you
know.
Maybe
just
a
list
of
these
are
the
things
that
are
done.
You
know
I,
provided
some
third
parties
evaluated
it.
C
C
You
could
put
it
on
like
in
monitoring
only
mode
where
you
could
go.
You
know
like
nothing,
will
stop
you
like
you.
You
declare
your
intent
or
expectations
that,
like
this
package
is
supposed
to
be
built
this
way
and
when
you're
first
turning
it
on,
you
might
want
to
turn
on
this
monitoring
mode
to
only.
G
C
Because,
like
you,
don't
want
to
break
stuff
and
then
once
you're
confident,
then
you
would
turn
it
on
enforcement
mode
and
then,
like
it'll
block
you
from
doing
stuff
that
violates
what
the
policy
says.
You're
supposed
to
do.
It's
I
mean
like
like
any
security
control
like
nothing,
is
perfect
right,
like
at
a
minimum.
There
could
be
like
if.
C
H
Obviously,
if
it's
under
the
salsa,
tooling
yeah,
yeah
I,
think
it's
under
well,
I'll
I'll
bring
it
up,
but
there's
the
Oracle
has
built
something
called
macaron,
which
actually
does
some
of
that
verification
stuff
already,
which
is
interesting
and
something
worthwhile
to
maybe
see,
see
what
they've
done
there.
Also
my
two
cents
on
the
sort
of
enforced
versus
monitored
versus
ad
hoc
I
think
some
of
it
I
do
Wonder
like
how
much
of
that
is.
H
H
H
The
next
thing
is,
as
far
as
the
monitored
I
think,
the
way
that
I
sort
of
view
monitor
versus
enforced
is,
could
it's
sort
of,
like
the
you
know,
scorecard
or
All-Star
kind
of
model
of
hey.
We
have
we're
not
saying
that
this
sort
of
thing
can't
happen
as
in,
like
somebody
couldn't
have,
let's
say,
mess
with
it,
but
are
there
adequate
security
controls
in
place
at
the
build
system
level
to
sort
of
prevent
this
sort
of
thing,
or
is
it
more
like
a
detective
control
right?
H
H
If
somebody
has
admin
into
the
control
plane,
they
could
potentially
mess
with
stuff.
But
if
you
use
stuff
like
spiffy
Spire,
we
can
detect
that
we
can
prevent
that.
We
could
do
you
know
yayada,
whereas
in
certain
contexts
hey,
we
can't.
Actually.
We
can't
actually
prevent
this
in
a
in
an
easy
way,
so
we're
just
sort
of
keeping
track
of
the
changes
and
that's
the
best
we
could
do
is
we
could
just
monitor
it.
C
H
H
Can
I
verify
at
the
different
levels
of
like
what
which
one
am
I
hitting
right,
because
there's
gonna
be
certain
things
that
are
just
conformant
of
let's
say
hey.
This
is
salsa
level.
Three
conformant
build
system,
but
remember
some
of
the
stuff
within
the
requirements
are
going
to
be
dependent
on
the
actual
project
right
so
like,
even
if
a
system
is
capable
of
level
three,
if
you
don't
configure
your
build
correctly,
it
could
still
be
purely
level
one
and
so
I
think
so.
There's
there's
still
two
pieces
to
that.
D
I
Oh
yeah,
thanks
thanks
right,
yeah,
exactly
I,
think
we're
talking
about
two
different
things
here
and
it's
important
to
make
that
distinction,
and
so
I
agree
with
calling
out
the
verification
separately,
because
it
is
different
from
what
the
build
system
is
doing
right
so
not
not
to
be
labeled
a
point,
I
think
I.
Think
again,
this
is
just
terminology.
We
don't
have
to
argue
too
much
about
it,
but
I
think
maybe
one
good
name
for
blocking
might
be
fail.
B
Couldn't
hear
the
one
word
I
heard
fail
closed,
that
is,
that
is
standard
terminology,
but
I
should
warn
you
that
different
communities
interpret
that
exactly
the
opposite
way.
So
I
would
suggest
not
using
that.
The
problem
is
that
the
word
closed
has
two
meanings.
Do
you
mean
a
closed
circuit?
Everything
always
goes
through,
or
do
you
mean
a
closed
door?
Nothing
goes
through.
Everyone
loves
this
term
fail
closed,
but
not
everyone
agrees
on
what
it
means.
Yeah.
D
B
I
E
Yeah,
hey
guys
so
again
a
couple
of
ideas.
What
I've
used
in
the
past
is
you
know,
governance
and
governance
is
a
big
word
when
it
comes
to
supply
chain.
The
governance
in
in
a
sense
of
hey
are
we:
do
we
even
have
any
any
kind
of
governance,
or
do
we
have
any
type
of
wood?
What
I
call
in
two
areas,
strictness
and
maturity
and
the
strictest
is
more
like
hey,
I'm,
just
advising
I'm
kind
of
giving
some
guidance.
Then
you
start
creating
those
standards.
E
Then
you
start
reporting
on
the
standards
and
then
you
start
auditing
and
then
governing
soft
and
governing
hard,
that's
kind
of
how
I
call
it
or
that's
kind
of
how
I
put
it
and
then
on
the
maturity
side,
it's
well.
How
mature
are
you
with
with
these?
With
these
controls
or
I,
don't
know
what
the
right
terminology
is,
but
you
know
that's
kind
of
how
how
I
how
we
built
this
in
the
past,
where
we
didn't
really
have
anything
in
the
past,
but
now
we
started
kind
of
the
first
level
is
like
hey
guys.
E
We
want
to
put
some
strictness
on
this.
We
want
to
start
advising
teams,
hey
team,
you
really
ought
to
think
about
you
know
doing
these
tests
or
you're
really
ought
to
think
about.
You
know
looking
at
these
tools
to
help
with
these
things
right
and
then
standards
would
be
hey
now
that
we
we've
had
these,
that
you
know
kind
of
recommendations,
we're
really
going
to
start
kind
of
writing
out
what
that
standard
looks
like
and
now
we're
going
to
start
reporting
and
letting
you
know
by
the
way.
E
This
is
deviating
from
that
standard
and
then
we're
going
to
start
doing
that
trust
and
verify
approach.
I,
don't
know
if
that
helps,
but
I'll
pause
there,
and
then
you
have
the
soft
and
the
hard
governance
which
is
soft.
It's
like
you're
slightly
applying
those
the
soft
rules
and
then
the
hard
rules
where
you
like
definitely
apply
the
rules.
E
C
C
And
then
something
like
actually
checks
it
that
Jeffy
actually
checks
the
the
provenance
and
that
the
Providence
matches
the
expectations.
So
Visa
talked
about
this
in
and
we
talked
about
those
various
times
of
previous
meetings
like
if
you,
if
you
have
a
Builder
that
is
level
three,
that
whatever
powers
that
be
decide
that
this
is.
We
accept
this
as
being
level
three
awesome,
Builder,
let's
say,
and
you
build
and
you're
trying
to
build
some
package.
Let's
say
Pi
animal,
which
is
a
python
package.
C
If
someone
uses
this
level
3
builder
but
builds
from
a
fork
that
should
be
stopped
somehow
that
concept
didn't
exist
in
0.1
and
I
want
to
add
it
to
1.0
and
like
with
the
current
wording
in
the
draft,
it
says.
Well,
it
doesn't
exactly
say
it's
intending
to
say
that
that's
a
required
thing,
but
the
downside
to
bundling
it
into
the
build
levels
is
one
if
you
want
to
just
like.
If
you
just
have
an
artifact
and
just
say,
tell
me
what
the
provenance
is.
I
don't
have
any
expectations.
C
I
just
want
to
know
like
what
you
where
this
thing
actually
came
from
then
like
you're,
not
doing
that
new
thing
of
checking
like
what
the
canonical
Source
repo
is,
and
so
you
can't
call
it
build
level
three
which
is
kind
of
some
bundling,
which
seems
unnecessary,
but
also
like
it's
a
bit
kind
of
confusing
about
like
what
exactly
the
build
guarantees
are,
and
it
also
makes
it
harder
to
get
out
the
door.
So.
C
G
All
right,
thanks
guys,
I
mean
so
I
I,
you
know
I,
think
I
know
what
you're
trying
to
to
get
to,
but
at
the
end
of
the
day
this
is
a
specification
and
the
whole
point
is
to
define
a
set
of
requirements
that
different
actors
in
the
ecosystem
are
going
to
claim
conformance
to,
and
so
I
think
you
know
adding
another
kind
of
way.
I
mean
there
are
many
ways
you
can.
G
You
can
splice
this
this
problem,
but
at
the
end
of
the
day,
it's
only
useful
to
the
extent
that
you
can
articulate
it
over
these
different
roles
that
we
currently
have
in
the
stake
and
I
I.
You
know
I'm
a
bit
afraid
that
taking
a
different
direction
from
the
one
we
currently
have
is
going
to
be
more
confusing
than
not
because
at
the
end
of
the
day,
what
is
going
to
matter
to
people
is
okay,
I'm,
a
you
know:
I'm
a
Builder,
Pro
I'm
a
build
service
or
platform
provider.
G
G
E
H
B
So
I
I
think
one
of
the
challenges
here
is
you
know
what
you
know?
What's
what's
the
threat
model?
What
are
we
trying
to
counter
if
what
we're
worried
about
is,
you
know,
unintentional,
accidental
mistakes?
You
know
I
built
the
wrong
thing.
That's
one
thing:
if
we're
trying
to
counter
malicious,
you
know
someone
who's
maliciously
trying
to
insert
a
you
know:
I
built
the
wrong
thing
me
I
I,
that's
that's
a
whole
different
level.
Maybe
that's
part
of
the
the
confusion
here.
I
mean
I'll.
B
I'll
give
you,
for
instance,
if
you
don't,
if
you
are
concerned
that
the
that
the
build
and
parts
of
the
build
environment
are
being
controlled
by
an
adversary,
you
know
the
the
you
know
trying
to
do.
The
fix
within
the
build
environment
seems
like
just
another
in
form
of
insanity.
What
you
want
is
separate.
You
know
we
immediately
come
back
to
the
reproducible,
builds
question
and
for
a
lot
of
rep.
B
B
H
Yeah,
so
so
now,
I
remember
it
it's
it's
a
little
related
to
that,
which
is
the
way
I
was
sort
of
viewing
and
I
think
we
had
this
conversation
prior,
which
is
like
for
me.
I
I
do
think
that
if
I
have
some
code
that
I'm
building
and
it's
like
I'm-
let's
say
the
you
know
Debian
right
and
I'm
building
the
Debian
package
for
this
python
package
for
me,
I
think
the
the
salsa
stuff
that
I'm
looking
at
is
I.
H
H
Let's
say
that
thing
down
and
I
can
go
and
have
other
mechanisms
to
monitor,
what's
happening
there
to
find
out
that,
yes,
it
actually
goes
out
pulls
down
code
from
this
repo
and
if
it
turns
out
the
network
or
whatever,
is
different
and
and
it
actually,
you
know,
you
think,
you're
pulling
from
X
but
debian's
build
servers
pull
from
y.
Oh
there's
a
discrepancy.
H
C
Yeah
the
like
what
is
it
supposed
to
be
built
from
so
for
a
Debian?
This
would
not
and
like
building
the
pie
yaml
package,
it
would
not
be
the
GitHub
repo,
but
rather
debian's,
mirror
because,
like
that's
where
it's
supposed
to
be
built
from
like
because
it
has
the
Debian
patches,
Etc
and
that's
kind
of
the
definition
of
canonical
for
because,
like
I
mean
because
it's
not
the
Pi
Pi
package,
it's
the
Debian
package.
Those
are
two
different
packages
in
terms
of
threat
model.
C
The
like
the
specific
thing
that
I
think
is
not
addressed
in
0.1.
That
I
want
to
be
addressed
in
1.0
is
the
case
where
a
a
maintainer
or
more
likely,
their
account
credentials,
become
compromised,
and
someone
from
you
know
packaged
Foo
uploads,
a
version
of
the
package
to
the
registry
that
does
not
come
that
contains
like
code
or
behavior
that
the
team
or
organization
or
whatever
that
owns
the
code
did
not
authorize.
B
C
I
I
think
the
level
describes.
The
the
point
of
the
level
was
to
do
that
like
level.
One
should
is
targeting
just
mistakes,
but
it
could
be
easily
bypassed
level.
Two
is
targeting
people
who
are
like
maybe
curious
or
low
skill
or
low
risk
tolerance,
because
there's
some
sort
of
control
in
place,
but
like
the
threat
of
detection
or
of
getting
fired
or
something
is
sufficient
to
deter
them,
and
then
three
would
be
like
a
relatively
Advanced
adversary.
Who
you
know
like
you,
you
really
have
to
find.
C
B
C
B
C
Any
one
of
those
account
credentials
can
be
used
to
do
an
a
upload,
a
package
and
it's
almost
impossible
to
detect
when
that's
bad,
because,
like
it's
a
binary
thing,
you
have
like
disassemble
it,
and
even
if
it's
source
code
like
no
one's
actually
inspecting
the
source
matches,
you
know
looking
for
bad
things.
Occasionally
people
do
detect
those
things,
but
not
often
we
want
to
just
like
systematically
eliminate
that
and
right
by
doing
that,
we
could
trace
it
back
to
the
source
code.
B
C
G
G
What
else
say,
maybe
a
bit,
maybe
a
bit
crazy,
bear
with
me.
You
know
because
I
think
it's
a
departure
from
the
way
salsa
has
been
built
to
date,
but
I
have
to
say
so
what
I'm
seeing
is
right
now
we
have
definition
of
different
levels
at
a
fairly
high
level,
and
then
we
try
to
you
know
Define
what
it
means
for
different
types
of
implementers
with
tying.
Actually
with
this
different
levels
are
between
the
different
categories
of
implementers.
G
G
Because
you're,
resisting
you,
you
add
this
verification,
which
makes
sense
from
a
functional
point
of
view,
and
you
say
I,
don't
want
to
call
it
different
levels
and
I'm
like
well.
Why
not,
and
the
reason
I
believe
is
because
levels
are
me-
means
something
else
and
are
tied
to
other
things
and
you've
done
defining
levels
there.
It
just
it's
hard
to
see
how
this
reconcile
with
the
levels.
A
G
G
C
So
you're
saying,
instead
of
here,
of
like
having
one
build
track
and
then
there's
like
this
orthogonal
dimension
of
like
how
verified
or
whatever
is
that
level
there'd
just
be
two
tracks:
there's
a
build
track
that
describes
where
the
responsibilities
are
on
the
producer,
meaning
like
like
the
package
owner
and
also
the
build
system,
and
then
a
second
level.
Actually,
let
me
go
to
the
requirements
page
like
this
part
would
be
the
build
level
and
then
this
stuff
would
be
oops.
Sorry,
the
package
ecosystem.
It's
almost
like
a
package
level.
G
Essentially,
yes,
that's
what
I'm
getting
at
and
maybe
there
are
different
levels
in
that
category.
You
know.
Maybe
it's
just
not
one.
There
are
a
few,
but
they
don't
have
to
be
tied
to
the
build
levels.
I
think
that's
where
you're
struggling
with
this,
like
you
know,
you're,
trying
to
insert
the
different
types
of
variations
and-
and
you
don't
want
it
to
be
tied
to
those
build
levels.
G
G
C
So
then
I
guess
question
is
like,
but
basically
for
for
1.0.
My
main
concern
is
like
I
want
to
figure
out
how
this
all
comes
together.
I
feel
like
once.
We
know
that
it
all
comes
together.
We
don't
have
to
define
those
other
tracks
right
away
like
just
like
the
source,
one
we
say:
okay,
we
know
it's
going
to
be
there.
We
could
just
draw
a
black
box
around
it.
That's
fine
once
we
know
how
it
comes
together.
G
It's
like
I,
don't
know
what
they
are,
but
what
I'm
saying
is
the
package
level
and
maybe
the
source
that
I
was
going
to
say
that
too
I
was
going
to
say.
We
talked
about
Source
levels.
There
is
no
reason
that
Source
level
one
would
match
the
yield
level.
One
right
you
could
have
different
types
of
association
between
the
different
categories
and
the
levels.
G
So
you
could
imagine
down
the
line
being
salsa
Source
level
one
and
build
level
two.
You
know
just
making
it
up
and
package
level
three
or
something
like
yo
level.
One
or
you
know
some
it's
this
idea
that
you
want
to
untie
those
things.
You
define
different
categories.
We
have
Source,
build
and
I
guess
now
package
or
something
along
those
lines
and
for
each
of
those
categories
you
define
different
different.
You
define
different
level
independent
of
the
other.
G
C
C
C
If
the
Providence
is
like
here's,
the
list
of
every
Unix
command,
that
I
ran
technically,
it's
correct,
but
the
it's
like
too
low
level
and
there's
no
way
to
know
whether
that's
legit
or
not,
because,
like
I,
don't
know
how
the
package
is
supposed
to
be
built
and
if
someone
inserted
something
malicious
of
like
they
did
all
the
normal
steps,
but
they
also
ran
some
extra
commands.
I'd
never
be
able
to
detect
that
and
so
I
think
the
like
a
good
design
of
the
build
system
would
be
to
have
a
like
minimal.
C
C
Like
the
parameters
are
like
the
inputs,
which
are
like
variables
and
vars,
but
it's
basically
just
this,
and
so
someone
could
know
like.
Oh
the
repo's
wrong
or
the
branch
is
okay
or
I,
don't
care
about
the
branch
or
something,
but
it's
not
like
too
low
level,
and
so
that's
basically
what
I'm
struggling
with
I
don't
know
if
any
of
that
made
sense.
H
H
H
It
is
practically
harder
to
lie
about
what
happened
right,
unless,
obviously
you
know
if
assuming
that
that
it
actually
is
hitting
level
three
right
build
level
three
right.
If
it's
hitting
build
level,
three,
some
of
the
things
are
practically
harder
to
lie
about,
especially
like
that.
Doesn't
stop
the
actual
build
service
itself
from
lying,
but
we're
assuming
that
a
conformance
program
and
some
of
those
other
things
are
sort
of
saying
like
hey.
H
We
check
this
or
we
self-attest
it
and,
and
you
know,
under
under
risk
of
legal
liability
or
whatever
you
know,
we're
we're
largely
as
in
you
know
the
the
folks
who
are
running
the
build
system
or
telling
the
truth,
which
is
separate
from
hey
somebody,
a
malicious
actor
coming
in
and
trying
to
to
to
compromise
that
build
system
versus
a
a
malicious
actor
running.
The
build
system.
H
What
is
the
expectations
of
the
conformance
program
for
the
build
system,
so
that
I
know
like
hey
if
they
claim
this
level
of
Social
conformance
and
they
claim
this
level
of
the
you
know,
then,
when
I
see
a
salsa
at
a
station,
what
should
I
be
able
to
expect
what
should
I
be
able
to
potentially
verify
and
then
separately,
I
think
that
there
is
but
I
think
that
there's
something
actually
yeah,
never
mind.
I!
Think
that
that
that's
that's
the
big
thing
from
my
perspective.
C
C
C
So
I
will
try
to
put
together
some
sort
of
draft
based
on
the
conversation
here,
just
to
see
what
it
looks
like
and
then
we
could
figure
out
like
well,
maybe
for
the
release
candidate
we'd
like
like
just
hide
that
part
yeah
and
just
go
with
like
what's
solid
and
in
1.1
we
could.
We
could
like
let
you
know,
write
out
the
details.
C
D
Yeah
I
think
this
was
mainly
I
was
talking
to
Michael.
Last
week
he
mentioned
that
there
was
the
chat
on
like
questions
on
that,
quite
as
he's
doing
so
mainly
I
think
my
my
kind
of
agenda
here
is
just
to
answer
any
questions.
If
there
is
anything
about
that,
I
think
I
can
give
a
very
quick
three
minute.
The
five
minute
update
on
what's
happening
with
that
and
then
I
think
you
can
just
like.
Have
it
open
for
questions.
D
So
just
to
quickly
share
so
the
built
svx3
built
profile
has
kind
of
been
looking
at.
You
know
how
do
we
represent
builds
and
information
about
builds
in
spdx.
A
lot
of
the
impetus
of
this
comes
from
the
safety
use
cases
where
they
have
to
provide
basically
step-by-step
information
on
how
they
build
a
certain
thing
in
the
configurations
that
go
into
it,
but
obviously
I
think
there
are
a
lot
of
other
use
cases
as
well.
D
D
F
It's
because
someone
might
need
to
provide
an
spdx
artifact,
whatever
it
might
be,
might
be
a
build
profile,
might
be
an
s-bomb
and
then
verify
whether
or
not
it
is
also
compliant.
So
are
you
helping
or
will?
Are
you
willing
to
help
the
salsa
Community
enable
us
to
link
to
an
spdx
in
their
specification
right
so
that
way
we
can
help
anybody
use
it
as
an
additional
artifact.
I,
don't
know
if
that
helped
or
not.
D
D
D
D
We
also
being
kind
of
like
a
already
a
big
use
of
SPX,
so
kind
of
just
mocking
up
what
I
looked
like
in
terms
of
that
and
being
able
to
show
like
what
would
it
look
like
if
you
know
for
safety
use
cases,
they
want
to
drill
down
to
that
command.
Specific
arguments,
that's
kind
of
extending
a
little
bit
further
than
the
I
think
the
the
supply
chain
security
case,
and
this
is
more
form
of
blinds,
but
yeah.
H
Yeah,
so
one
quick,
I
think
one
of
the
primary
use
cases
that
a
few
folks
have
brought
up
is
they
would
love
to
be
able
to
have
a
way,
both
in
salsa
or
away
in
salsa,
and
once
again
this
is
less
about
spdx,
as
opposed
to
just
sort
of
making.
Sure
that
we
can
collaborate
is
to
say
I
would
love
to
have
to
just
sort
of
say,
here's
my
s-bomb,
and
that
should
count
as
my
materials.
H
Right
so
you
know
as
as
a
not
not
as
the
materials
but
as
a
reference
for
what
the
materials
are.
So
as
opposed
to
having
two
separate.
You
know,
ways
of
recording
it-
and
you
know
in
certain
cases,
remember
like
for
folks
is,
is
in
certain
cases
you
could
be
as
as
granular
or
as
non-granular
as
you
want
in
the
salsa
in
a
salsa
document
about
what
the
materials
are
right.
H
You
could
just
sort
of
say,
hey,
here's,
a
hash
of
you
know
the
tarball,
that's
all
the
source
in
its
dependencies
and
I'm,
not
gonna.
You
know
it's
not
Salsa's.
Is
that
in
Salsa's
wheelhouse
to
actually
break
that
out
into
individual
things
and
what
they
are,
but
it
might
also
be
able
to
say
you
know
if
you
let's
say
you
are
generating
this
bomb,
it
would
be
nice
to
just
be
able
to
say.
Oh
actually,
here's
an
s-bomb,
the
s-bomb
says
what
the
source
is
all
the
dependencies.
That's
a
reference
to
to
that.
D
H
Pretty
much
so
yeah,
it's
almost
like
something
like
you
know,
as
opposed
to
an
actual
thing
similar
to
what
you
had
mentioned.
With
the
build
profile,
potentially
saying:
hey,
I,
don't
have
an
actual
build
profile.
I
have
here's
a
reference
to
a
salsa
document
which
essentially
describes
the
build.
It
would
be
useful
to
have
something
almost
like
the
other
way
around.
H
Yeah
and
and
and
I
know,
that's
something
we've
discussed
and
the
idea
here
is
like
it's
not
really
anything
on
the
salsa
side
that
would
be
required
outside
of
just
making
sure
that
generally,
those
things
are
would
be.
You
know,
compatible
yeah
and
then
also
I'm
sure.
From
a
tooling
perspective,
when
we
get
to
the
tooling
meeting,
we'll
have
to
make
sure
that
if
there
are
Loops
where
the
the
document
refers
to
the
build
profile,
we
all
need
to
make
sure
that
that
gets
dealt
with.
But
that's
a
different
yeah.