►
From YouTube: SLSA Specifications Meeting (October 31, 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
Let's
get
started,
thank
you,
everyone
for
joining
again.
Please
register
your
attendance
in
the
the
meeting
notes,
which
are
pasted
into
the
chat
and
a
reminder
that
we'll
abide
by
the
Linux
Foundation
code
of
conduct.
A
Does
anyone
have
have
topics
for
today?
I
actually
have
made
no
significant
progress
on
the
V1
stuff,
because
I
was
busy
with
with
other
work,
I
I've
been
working
on
as
I
mentioned
last
at
the
end
of
last
week,
an
update
to
the
proposal,
the
Providence
form
actually,
which
I
see
Heron
listed.
A
Like
Sean,
for
example,
took
a
look
at
it
and
gave
some
feedback
I
got
some
feedback
from
some
people,
but
like
it's
not
undergone
formal
review
or
like
is,
is
particularly
good,
but
here's
a
I
I'm
doing
the
schema
in
proto
format,
because
just
easier
technically
and.
A
D
And
Mark
that
508
is
the
manual
verification.
D
D
D
Yeah
I
guess
Marco's,
just
my
simple
question:
there
you
know
around
the
attestation
spec.
Are
we
including
that
as
well
within
the
skip
for
this
Bodywork.
A
I
mean,
ideally,
we
would
we're
kind
of
I
think
we
really
want
to
get
this
I
think
pressure's
mounting
to
have
some
release.
A
I
I,
don't
know
if
anyone
has
other
thoughts,
I,
don't
view
it
as
a
hard
blocker
for
1.0
unless,
like
there's
a
reason
that,
like
the
current
format,
is
insufficient
and
we
we
need
to
make
a
change.
I
did
start
looking
at
it
just
independently,
because
I
was
having
parallel
conversations
with
a
couple.
Other
teams
who
were
confused
by
the
current
format
like
I.
You
know
they
kept
getting
caught
up
on
the
same
rough
edges
of
the
0.2
format
and
so
I.
A
Gather
everything
that,
like
in
my
head
for
changes
and
like
aggregate
that
all
and
just
like,
put
it
in
a
a
schema
together
to
see
if
that
would
work
better
for
these
couple,
integrated
cells,
Integrations
that
we've
been
working
on
and
so
far
the
feedback
has
been
positive,
and
so
maybe
we
should.
We
should
do
that.
A
I
just
haven't
got
if
you
look
at
the
the
thing,
there's
like
a
bunch
of
to-do's
in
there
and
like
open
questions
and
like
I,
just
made
a
change
today
and
I
refactored
all
things,
so
it's
like
very
in
Flight,
but
so
far
it
seems
like
a
positive
change,
and
so
maybe
we
should
just
do
that
and
call
it
draft,
and
that
way
we
have
something
we
could
do
that
in
parallel
to
the
spec
work.
D
And
just
the
last
piece
on
the
agenda
item
that
I
put
on
there,
you
know
the
the
outcome
of
Chris's
and
Marcella's
conversation
in
that
issue.
I
thought
it
was
an
excellent
conversation
in
there
and
you
know
Chris
proposed
some.
B
Spec
so
I
thought
that.
B
A
A
So
here
is
the
well.
A
To
look
at
an
example
rather
than
the
Proto
is
like
very
verbose,
but
his
full
documentation.
A
A
better
scheme
of
language
like
protobuf
and
then
parse
that
and
turn
it
into
markdown
I,
just
haven't
figured
out
the
tooling.
Yet
for
that,
so
the
the
idea
would
be
so
one
thing
or.
E
A
Might
look
like
I,
don't
know
if
this
is
a
museum
in
a
bit
the
the
main
change
would
be.
We
add
two
levels
of
nesting,
because
right
now
the
build
type
is
a
top
level
field.
A
We
have
one
thing
called
config,
what's
called
config
Source
I
think,
and
it
assumes
that
you
have
a
single
top
level
input
artifact
and
there's
an
entry
point
parameters
which
is
unchanged,
and
so
the
couple
of
changes,
I,
we
thought
I
thought
would
be
valuable
and
based
on
feedback
would
be
one
at
a
high
level.
Separate
the
kind
of
the
pure
inputs
from
the
impure
inputs
or
like
the
build
definition,
would
be
the
thing
that
is
like
the
input
to
the
build.
A
Every
time
like
different
parties
can
run
this
build
definition
and
get
an
output.
If
it's
reproducible
it'd
be
the
same
bit
for
bit
identical
output.
If
it's
not
reproducible,
you
get
a
different
output,
but
still
that's
kind
of
like
the
definition
of
what
you're
doing
and
then
the
Run
details
would
be
the
stuff
that,
like
every
invocation,
is
going
to
be
different
so
like
who
performed
the
build.
What
their
run
ID
was.
The
time
stamps
Etc
also
I
had
to
buy
products.
A
We
should
talk
about,
but
then
within
build
definition,
and
this
is
a
change
I
made
this
morning.
So
again,
I,
don't
I,
don't
know.
If
there's
any
good,
it
seems
like
it
would
be
valuable
to
have
top
level
inputs,
which
are
kind
of
like
the
independent
inputs
that
we
have
to
verify,
because
those
are
like
the
knobs
that
users
can
change,
and
so
you
need
some
expectation
of
like.
Was
this
good?
A
And
ideally
you
make
that
part
as
small
as
possible,
because
the
fewer
parameters
there,
the
fewer
things
that
you
have
to
verify
and
then
dependencies
would
be
like
all
of
the
resolved
things
that,
like
that
either
the
build
environment
provided
like
the
build
system
provided
or
like
resolving
dependencies,
Etc
and
so
I'm,
hoping
that,
like
this
kind
of
nesting,
makes
a
little
bit
more
clear
like
what
the
purpose
of
each
thing
is:
yeah
Michael.
G
Do
we
want
to
allow,
for
example,
the
those
inputs
to
be
definable,
also
like
to
be
scheme
to
have
us
potentially
have
a
schema
based
on
the
build
type,
because
that
was
one
of
the
things
that
we
were
kind
of
talking
about,
potentially
so
that
someone
knew
like
a
Rebuilder
can
go
and
say:
yep
I
am
a
Docker
Rebuilder.
So
if
I
see
build
type,
Docker
build,
I
know
how
to
ingest
things
like
because
there
might
be
some
additional
metadata
that
might
be
specific
to
individual,
like
Docker
built
Rebuilder
inputs
or
go
Rebuilder
inputs.
G
A
Is
what
I
did
here
is
I
called
it,
which.
A
G
Oh
okay,
yeah,
yeah,
and,
and
do
we
wanna
is
there
anything
we
can
do
to
sort
of
I
guess
encourage
actually
defining
that
I
mean
I,
think
not
necessarily
for
1.0,
but
I
know.
One
of
the
things
that's
been
happening
lately
is
is
a
lot
of
folks
have
lots
of
different
build
types,
but
none
of
them
are
actually
defined
by
a
schema.
Yet
I.
A
See
yeah,
that
would
be
good
yeah.
We
should
do
that
another.
So
one
a
couple
changes
like
one
is
input
artifacts.
Instead
of
just
having
a
single
top
level
thing
which
seems
in
practice
like
there's,
we
keep
running
into
the
issue
that
there's
not
there's
like
often
multiple
things
like
The
Source,
that's
being
built,
but
then
in
this
case,
like
a
Docker
image
that
you're
running
the
build
on
that's
an
independent
input
and
then
maybe
a
third
one
which
is
like
the
the
binary,
that's
putting
them
together.
A
The
version
of
the
binary
that's
putting
together,
and
so
these
would
be
kind
of
all
three
independent
inputs,
but
you
wouldn't
list
all
the
result,
dependencies
that
would
have
go
down
here.
Optionally,.
A
The
other
and
then
like
the
meaning
of
entry
point
just
like
in
the
current
version,
would
be
dependent
on
the
build
type,
and
so
these
names
here
would
have
like
special
meaning,
based
on
the
build
type
of
and
I
listed,
some
suggested
convention
for
what
possible
names
are,
but
you
could
put
arbitrary
names
here,
it's
a
map
and
then
the
other
Main.
A
The
other
real
significant
change
was
the
byproducts
which
would
be,
and
this
and
it's
this
is
the
term
from
the
in
Toto
link
format,
additional
outputs
that
are
not
like.
The
main
output
like
I
listed
two
example:
things
in
the
schema
logs
is
a
common
one.
A
I
think
Sean
might
have
suggested
that
and
then
also,
if
you
have
like
a
resolved
configuration
of
like
you,
parse
this
thing,
and
then
you
do
a
bunch
of
stuff,
and
you
have
some
actual
object
that
maybe
you
need
for
reproducing
or
something
like
that
you
could
list
it
here.
If
you
want
to
like
make
the
hash
of
it,
you
could
list
here
which,
which
could
be
useful
for
like
debugging
or
something
like
that,
but
you.
A
Anyway,
that's
what
I
had
so
far
I
don't
expect
everyone
to
like
take
it
in
warm
thoughts,
but
I
want
to
kind
of
share
this.
In
case
people
want
to
dig
in
and
again
the
schema's
here.
Hopefully
it's
understandable
if
you're
not
familiar
with
product
Buffs.
F
Jack,
all
right
so
would
every
single
builder
ever
need
to
have
its
own
definition
like
here
we've
got
a
Docker
Builder.
What
happens
if
I
have
you
know
a
different
package
manager?
I've
got
webpack
beats.
You
know
all
these
different
things
do
builds.
Are
we
gonna
have
to
have
top
level
definitions
for
everything.
A
A
I
think
I
think
there's
a
trade-off
here,
because
what
we
want
to
effectively
this
build
type
is
encoding,
a
bunch
of
information
and
the
more
information
we
encode
in
the
build
type,
the
less
information
it
has
to
go
here,
which
makes
it
easy
to
verify
because
you
just
know:
oh,
this
is
a
webpack
build
or
like
or
or
more
generally,
an
npm,
build
and
I
know
how
to
do
that,
and
it
has
like
all
sorts
of
logic
of
like
okay.
A
First,
maybe
it's
like
you
run
npm
publish
or
if
there
exists
a
script
called
build.
You
run
that
or
whatever
that
is,
and
that
has
value.
But
then
yes,
you'd
have
to
Define
one
per
whatever
thing.
You're
doing
an
alternative
would
just
be
like
run
an
arbitrary
command
and
then
the
entry
point
would
be
like
an
arbitrary
shell
command.
But
then
the
difficulty
is
well,
the
advantage
would
be.
You
would
only
have
to
have
one
build
type
and
would
cover
a
bunch
of
things,
but
the
disadvantage
would
be
there's
a
lot
of
complexity.
A
In
the
entry
point
it
would
be
like
again
an
arbitrary
shell
command,
and
so,
if
someone
was
building
with
say
make
and
then
they
or
like
they,
it
was
like
you'd
run
like
make
build,
and
then
they
changed
the
name
of
the
target
to
make
something
else
like
just
for
a
pure
refactor
that
might
show
up
here
and
look
like
a
significant
change.
It
would
be
kind
of
difficult
to
know.
What's
significant.
A
F
You
not
just
have
most
of
the
benefits
by
defining
what
the
result
is,
so
you
have
like
an
A,
P
or
l
or
whatever
that
says.
I
am
outputting
this
and
then
you
know
this
was
my
entry
point
where
whether
the
entry
point
changes
from
running
this
script
or
that
that
script,
you
know
the
result
is
this:
you,
you
still
want
to
review.
F
G
So
this
is
actually
something
that
I
know
in
my
my
notes,
for
that
one
thing
I
was
talking
about
before
was
the
I
think
it
might
be
worthwhile
to
say
there
might
be
some
regardless
of
build
type.
G
There
probably
should
be
some
set
of
default
things,
and
then
you
can
have
additional
things
defined
in
each
built,
like
a
build
type
can
Define
extras,
but
there
should
be
like
a
minimum,
so
as
Jack
mentioned,
so
that
somebody
who
doesn't
have
the
tooling
that
let's
say,
knows
how
to
do
a
Docker
Rebuilder
can
still
parse
through,
let's
say
everything,
but
the
dark.
The
docker
Rebuilder
specific,
specific
attributes
does
that
make
sense.
G
Oh
I
I
think
to
you
mark.
A
A
A
Don't
know
I,
don't
know
nothing
about
Mac.
My
only
worry
is
things
like
like.
Let's
say
you
were
running
a
GitHub
action
command
doesn't
really
make
sense,
because
that's
not
the
interface
that
you
invoke
a
GitHub
at
GitHub
actions
workflow.
You
invoke
it
with
this
config
file
and
subtrigger,
or
something
like
that.
So
it's
not
really
running
on
a
single
system
where
you
run
a
command,
that's
really
actually
a
distributed
system.
G
Oh
yeah,
I
I
think
in
this
particular
context,
I
think
the
idea
is
just
to
say
there
might
be
shared
elements
across
all
build
types
right.
There
might
be
just
some
shared
elements
so
that
if
I
have
a
tool
that
only
like
that,
does
it
understand
like
it's
just
a
parser
and
it's
parsing
through
some
some
interesting
information.
It's
only
going
to
pull
out
information
it
understands
and
if
the
idea
here
is,
we
need
to
understand
all
build
types
right
that
it
could
potentially
ever
interact
with.
That
could
be
an
issue
compared
to
hey.
G
G
F
Yes,
so
the
next
thing
that
comes
to
mind
now
that
you
mentioned
GitHub
actions
is
this
then
confuses
everything
because
I
may
be
building
a
Docker
container,
so
you'd
maybe
put
the
docker
build
top
level,
but
I'm
doing
that
in
actions
or
tecton
or
Jenkins,
or
you
know
any
kind
of
CI
platform.
So
now
the
top
level
is
always
going
to
be.
The
CI
is
slightly
confusing.
A
Yeah
that
would
be
I
think
it
depends
I
what
you
are
doing
so
this
one.
This
was
again.
This
is
specific
to
a
project.
We
were
working
on,
so
there's
not
enough
documentation
here.
A
A
If,
like.
That's
like,
you
just
call
that
whole
thing
the
build,
and
that's
like
the
part
that
that's
trusted,
which
in
a
lot
of
cases
like
those
things,
are
complex,
and
so
that's
kind
of
where
you
drive
around
in
other
cases,
which
I
think
is,
you
know
like
most
services
like
that
is
the
thing
and
everything
inside
of
it
is
opaque,
and
so
that's
really
all
that
the
service
can
attest
to
is
that
it
ran
the
whole
thing.
Other
ones
like
this
would
be.
A
The
context
here
is
I
I.
Think
more
reproducible
builds
that
where
you
have
a
some
input,
some
container
image
that
in
which
you
run
some
command
again,
this
is
like
very
hand.
Weighted
I
don't
know
if
this
isn't
actually
the
real
design
and
they're
like
this
would
be
some
specific.
Maybe
this
is
too
confusing,
I
think,
but
another
one
might
be
like
an
npm
build
where
you,
you
know,
have
some
heuristics
for
how
to
run
it
again.
A
Maybe
you're
right.
Maybe
in
most
cases
we
could
just
Define
a
simple
thing
like
a
like
run
a
command
and
the
command
is
like.
If
we
keep
that
thing
simple,
like
npm
publish,
you're
done
and
it's
an
easy
enough
entry
point
that
you
don't
really
need
additional
things
and.
F
Yeah
yeah
well
I'll
be
tough,
but
not
to
retype
I,
just
think
I
I,
usually
so
I'm
more
used
to
the
next
method
of
building.
So
like
the
the
kind
of
reproducible.
Part
of
this
provenance
is
kind
of
also
combined
with
like
the
s-bomb
elements
of
of
your
inputs,
and
that's
one
thing
and
then
the
impurities
of
which
system
did
the
build.
Who
did
the
build?
Is
it
totally
separate
kind
of
recording.
A
Yeah
that
that's,
in
fact,
how
I,
with
the
inspiration
of
this
split
between
build
definition,
top
print
details,
I,
don't
know
if
I
forget
I,
don't
know
if
it's
you
or
someone
else
when
presenting
about
NYX
said
that
specific
thing
about
the
salsa
Province,
and
so
that's
why
I
did
that
split
who
are
like
this?
Is
the
I
don't
know
the
next
terms?
F
That
what
it's
called
yeah
the
the
derivation
is
the
term
yeah,
typically
I.
Think
of
anything,
that's
like
reproducible,
I,
always
think
of
it.
As
you
know,
a
build
input.
You
know
this.
What
what
you
run
to
do
the
build
is
is
important,
as
you
know,
what
other
inputs
you
have
like
libraries
and
whatever
so
I
I
feel
like
it
all
fits
better
with
that
kind
of
data,
and
then
the
Run
details,
yeah,
I,
I.
Think
of
it
as
like
a
separate
document.
F
A
I
discussed
that
some
with
one
of
my
colleagues
I
don't
think
because,
like
ultimately,
this
whole
thing
is
a
sign
statement,
saying
that
so
and
so
attests
to
the
fact
that
you
got
you
know
this
input
and
the
subject
which
doesn't
isn't
shown
here
was
the
output.
F
You
take
this
top
bit,
you
put
it
in
a
file,
you
get
its
hash.
You
then
put
that
in
your
Run
details
and
then
you'd
have
assigned
Run
details,
so
the
the
signed
Run
details
would
point
to
the
specific
other
file
that
you
have
and
it
should
be
linked.
A
Yeah
I
think
that
would
be
a
fine
way
of
doing
it.
I
don't
know
if
yeah
I
mean
I'm,
certainly
open
to
it.
The
the
I
think
that
one
or
two
people
I
talked
to
originally.
A
It
was
more
around
like
the
until
we
need
the
like,
because
that
adds
extra
complexity,
because
we
have
to
do
another
hash
operation
and
explain,
and
then
you
also
have
to
you
now
have
this
thing
as
an
out
of
band
or
like
not
at
a
band
but
like
a
separate
document
that
has
to
get
propagated,
whereas
right
now
the
whole
attestation
fits
is
like
one
unit
and
you
could
parse
it,
and
then
you
have
all
the
information.
You
need
to
compare
this
to
some
sort
of
policy
or
expectations.
A
If
you
split
it
out,
you
then
need
to
send
both
of
them
like
the
attestation,
which
is
the
currently
called
The
Run
details,
which
includes
the
hash
of
the
other
thing,
and
then
the
other
thing
itself
I
think
it's
a
fine
way
of
doing
it.
It's
just
more
like
do.
We
have
a
use
case
for
what
for
why?
We
would
need
that.
G
A
Foreign
yeah
yeah,
my
inclination
is,
is
to
include
it
in
one
document,
just
because
it's
easier
to
work
with,
because
I
think
the
consumers
of
this
would
be
expected
to
want
that
most
of
the
time
like
they
would
almost
never
want.
Just
this
without
the
Run
details
or
without
the
build
definition.
F
I've
been
thinking
about
the
the
separating
stuff,
just
some
other
things
as
well
like
yeah.
It
would
be
a
bit
more
of
a
pain
to
keep
track
of
these
documents,
but
I
mean
you're.
Gonna
have
a
separate
s-bomb
at
some
point.
F
B
F
I'm
using
this
go
then
I
have
an
s-bomb
for
that
copy
of
go.
You
know
how
am
I
going
to
link
to
that
so
I
think
there's
going
to
be
quite
a
few
cases
of
you
have
multiple
documents
you
need
to
chain
together,
or
you
end
up
with
like
a
mega
document
and.
F
A
Yeah,
for
sure
that's
I
mean
my
inclination
was
to
do,
as
you
said
in
like
have
at
the
top
level,
like
even
just
two
hashes
like
one
for
this
thing
and
one
for
this
thing
or
something
like
that,
and
so
you
could
like
split
them
out
and
only
include
the
pieces
that
you
care
about
and
I
think
my
colleague,
here's
on
the
other
side
of
like,
like
the
unique
and
Anita
type
of
thing
of
like.
Let's
try
to
keep
things
simple
until
we
know
we
need
it.
A
G
Yeah
not
to
complicate
things
but
I
know.
A
lot
of
folks
are
talking
about
stuff
like
when
it
comes
to
all
these
attestations
and
stuff,
like
that,
does
like
separate
from
salsa
right.
Does
it
make
sense
to
have
a
salt
like
a
attestation
at
a
station
or
whatever
right
like
something
that
says:
hey
here's,
the
category.
You
know
we've
seen
all
these
out
of
stations
regarding
this
thing,
an
s-bomb.
G
You
know
salsa
attestation,
whatever
like
in
total
layout
that
we
you
know
whatever,
and
so
all
of
this
is
stuff
that
we've
seen
and
here's
us
signing
off
or
or
also
stuff,
where
folks
I
said
Hey
in,
like
the
oci
case
stuff,
like
you
can
list
the
attestations
just
in
the
Manifest
in
this,
you
know
in
the
in
the
Manifest
and
be
able
to
do
it
that
way.
So
there's
a
bunch
of
different
things
that
I
think
folks
are
are
talking
about
there.
G
So
I
think
I
would
kind
of
personally
I
think
it's
kind
of
external
to
this
right,
where
you
might
just
say
there
needs
to
be.
You
know
we
want
to
suggest
folks
to
be
able
to
say.
Yes,
it's
also
attestation
and
exists
here
and
there's
an
s-bomb
and
it
exists
here,
and
you
know
whatever,
as
opposed
to
just
sort
of
tying
it
all
together
in
a
single
document.
G
Oh
no
did
Mark
just
get
disconnected
laughs.
D
A
G
A
My
I
gotta
set
up
some
better
wi-fi
situation
in
my
house,
so
once
Michael
started
stopped
talking,
that's
when
my
thing
dropped,
so
I
didn't
hear
anything
that
happened
since
then.
G
Oh
yeah,
that
was
about
it.
It
was
just
just
sort
of
saying
I,
you
know
I
think
wait
until
there's
some
use
cases,
because
I
think
there's
a
lot
of
other
folks
who
are
saying
hey
I
would
rather
have
that
in
a
Docker
manifest
or
whatever.
A
Sounds
good
so
in
in
terms
of
next
steps,
I'll
I'll
read
through
the
issue
508
any
Aaron
was
there
more.
You
want
to
talk
about
here.
A
Okay,
I'll
try
to
read
through
it
and
see
if
there's
any
more
to
do
it
and
then
I'll
I'll
get
into
a
decent
enough
State
there,
where
we
could
start
a
pull
request
and
that
way
we
could
actually
start
commenting
on
it
but
feel
free
to
like.
If
you
want
to
look
at
it
now,
Fork
it
and
play
around
with
it
or
talk
to
me
or
whatever.
B
Yeah
I
mentioned
this
in
the
the
last
salsa
meeting.
I
did
create
an
issue,
for
essentially
there
seems
to
be
a
discrepancy
in.
E
B
Where
the
draft
that
for
for
level
one
it
makes
no
claims
about
not
being
on
the
a
user's
workstation
versus
level,
two
says
it's
not
on
a
developer's
workstation,
but
one
of
the
benefits
that's
called
out
for
build
level.
One
is
that
it
says,
prevents
mistakes
during
the
release
process,
such
as
building
from
a
client
with
local
modifications,
I'm
interpreting
that
to
mean
a
developer's,
workstation
and
I
feel
like.
D
A
Yeah
so.
A
The
word
like
it's
it's
unclear,
I
could
say
what
was
like
going
on
in
my
head
at
least
so
I
was
thinking
that
at
level
like
at
the
top
level
and
I,
don't
think
it's
explainable
enough,
I'd
like
to
figure
out
how
we
could
do
this
better
like
level
one
would
be
controls
that
are
in
place
to.
A
Like
you
publish
provenance
and
you
do
things
to
stop
people
from
making
mistakes
so
like
you're,
you
set
some
expectation
where
it's
supposed
to
be
published
and
there's
some
sort
of
control
to
prevent
them,
ideally
prevent
or
at
least
detect
when
people
do
the
wrong
thing
by
mistake,
but
it
is
like
trivial
to
evade.
You
could
just
like
change.
It's
like
an
unsigned
five
just
change.
One
thing:
it's
like
lower.
A
No
no
effort
is
meant
to
like
stopping
people
from
evading
it,
but
they're
the
the
preventing
mistakes
I
was
thinking
would
be
something
like,
for
example,
if
a
package
repository
has
a
thing
that
says
like
upload
time.
It
checks
that
it
was
built
from
this
particular
git
repo.
A
Without
you
know,
from
like
a
commit
in
that
repo
and
the
client
tooling,
sets
creates
a
problem
and
saying
it
was
built
from
there.
You
know
where
it
was
built
from
and
then
at
upload
time
it
checks
that,
and
so,
if
you
build
from
your
local
machine
that
would
be
allowed
at
level
one,
but
it
would
not
allow
you
to
have
like
a
dirty
State.
A
You
know
like
make
sure
that,
for
example,
the
the
there's
no
untracked
changes
in
git
and
the
thing
the
local
commit
matches,
at
least
one
of
the
remotes
in
git
I.
Think,
for
example,
rust
does
this.
If
anyone
here
knows
rust,
there's
like
cargo
dash
dash,
allow
dirty
or
something
like
that
versus
versus
at
level
two,
you
wouldn't
that
check
would
still
happen,
but
there
would
be
more
controls
in
place
so
that
way,
you'd
have
to
actually
so
the
difference.
A
A
A
To
lock
down
a
local
machine
other
than
some
sort
of
trusted,
Computing,
something
or
other,
but
we're
going
to
ignore
that
for
now
so
like
run
it
on
a
service
and
the
secrets
are
specific
to
that
service,
and
so
in
order
to
attack
it
you'd
have
to
like
do
some
sort
of
exploit
to
withdrack.
The
keys
is
not
particularly
difficult,
but
it
would
be
like
a
fireball
offense
if
you're
an
employee
and
so
there's.
A
You
know
like
policy
and
there's
some
amount
of
work,
there's
some
barrier
to
entry,
and
so
not
everyone's
going
to
just
do
it.
Not
everyone
will
know
how
to
do
it
and
there's
some
disincentive
for
doing
it
and
then
level
three
would
be
like
a
stronger
security
where
you
really
need
to
be
pretty
Advanced
to
know
how
to
evade
it.
Anyway,.
B
A
A
B
Okay,
so
then
I'll
I'll
update
the
GitHub
issue,
because
that
makes
more
sense
now
based
off
of
that
wording.
So
I'll
update
the
GitHub
issue
and
try
to
push
up
a
different
wording
for
that
benefit.
F
I
might
be
missing
something
here,
but
so,
if
I
understand
correctly,
the
the
benefit
of
was
it
level.
One
is
that
you
don't
have
these
modifications,
but
what
in
level
one
is,
you
know
picking
up?
Oh
you've,
you've
changed
yet
in
some
way.
You
know
you
change
the
the
files
locally.
A
Yeah,
that's
I
think
something
we
need
to
work
out
so
either
Define
that
in
the
requirements
or
remove
that
from
the
benefit.
A
My
thinking
would
be
that
it
would
be
some
sort
of
within
like
to
call
Something
level.
One
means
that
there
exists
that
control
in
the
end-to-end
flow.
So,
for
example,
if
let's
take
cargo,
for
example,
with
cargo,
it
already
has
client-side
tooling.
That
prevents
you
from
doing
that
already,
although
I
think
there's,
it
doesn't
check
that
the
commit
actually
exists
in
the
Upstream
so
that
that
would
still
have
to
exist.
It.
A
You
from
doing
it
from
like
having
uncommitted
changes
in
your
local
client
and
if
cargo
at
say,
upload
time
or
or
even
in
the
client-side,
tooling
or
I,
know
somewhere
in
the
end-to-end
flow.
If
there's
some
sort
of
Roadblock,
where,
if
you
build
from
something
that
doesn't
that's,
not
the
Upstream
a
commit,
that's
on
the
Upstream
repo
or
equivalent
and
other
Version
Control
Systems
that
it
would
block
you.
F
Yeah
yeah,
that
sounds
good.
It's
just
yeah
I
hadn't
seen
that
on
on
the
website,
just
yet
but
yeah.
If
we're
going
to
add
that
that
sounds
good.
C
C
I
think
the
use
of
local
here
might
be
confusing.
In
fact,
what
you
mean
is
the
build
environment
right.
You
want
the
Bill
environment.
You
know
the
code
that
you're
building
is
matches
the
the
repository,
the
master
or
the
main
Repository,
because
local
you
know
is
that
I
mean
yeah
local
to
the
build
right,
but
it
could
be
in
Cloud
for
all
I
know
and
I
could
still
modify
the
code
there
and
build
from
this,
and
so
I
I
think
that's
not
the
right
qualification.
A
For
certain
thanks,
if
anyone
wants
to
take
a
crack
at
better
wording,
both
I
think
we
need
I
think
it's
clear
that
we
need
both
the
changes
on
the
levels
page
of
talking
about
the
benefits
to
better
explain
this,
as
Arnold
said,
and
also.
A
Side
to
show
that,
like
this
type
of
thing,
actually
gets
stopped
because
both
of
those
I
think
are
missing.
A
Okay,
one
last
thing:
we
talked
in
the
past
about
the
terminology
I
put
together
a
document.
Let
me
present.
A
Containing
just
a
a
proposal
for
for
terminology
that
we
would
add
to
the
existing
terminology
page
right
now.
If
you
look
at
the
terminology
page,
we
have
a
whole
section
on
build
and
what
the
model
is,
which
probably
could
do
some
work,
but
that's
a
separate
question,
but
nothing
around
package.
We
just
say
package
and
that's
it
similarly
for
dependency.
But
although
I
didn't
get
into
that
in
this
thing,
I
think
ideally
for
Source
packaging
dependency.
We
kind
of
go
into
those
details
and
we.
A
Around
this
of
like
ironing
out
of
like
different
model
things,
but
but
this
doc
concerns
itself
just
with
package,
because
the
term
is
ambiguous
like
is
it
an
artifact
like
a
thing
that
can
be
hashed
like,
for
example,
a
tarball
or
a
debit,
a
Deb
file,
or
something
like
that?
Or
is
it
the
kind
of
like
The
Logical
concept
of
you
know,
curl
or
is
it
like
literally
the
curl
version,
whatever
tarp.gz?
A
And
so
what
I
proposed
here
is
that,
basically,
we
never
use
the
word
package
unless
that
ambiguity
is
okay
and
then
that
we
use
more
specific
terms,
artifact
I
mean
the
actual
hashable
thing
and
project
to
be
like
the
cut
effectively
the
name.
That's
that's
the
term
that
python
uses
I
believe
like,
for
example,
in
Python,
the
requests
package.
A
I'm
sorry
project
is
the
thing
under
the
name,
pipi.org
quests,
and
so
it's
kind
of
like
the
thing
that
you
could
attach
a
policy
or
expectations
to
it's
like
a
thing
that
has
a
source
location,
an
owner,
Etc
and
then
also
because
if
we
need
these
terms,
Define
like
what
do
we
mean
by
ecosystem?
What
do
we
mean
by
registry,
because
different
ecosystems
well
ecosystem
would
be
good
to
say
what
we
mean
by
that
and
then
registry.
Some
things
call
this
a
registry,
some
things
call
it
repository.
A
Yeah,
yeah
I'll
just
delete
that
Authority
in
my
opinion,
would
be
a
completely
final
tournament
and
so
I
started
to
list
some
examples
here.
Let
me
turn
on
comments.
I
realize
I'm,
not
getting
notifications,
I,
didn't
see
any
of
these
notifications
and
I
think
it'd
be
valuable.
A
If
we
could
like
list
out,
you
know
all
any
ones
that
we
know
about
and
and
put
them
here
so
that
way,
when
we
talk
about,
you
know
you
can
make
it
concrete,
because
if
you
know,
for
example,
Maven
you
could
say
okay
when
salsa
says
registry,
it
means
the
repository.
It's
also
says
project.
It
means
this
or
whatever
I
don't
know.
If
any
of
these
are
correct,
and
so,
if
you
know
any
of
these,
that
would
be
good
to
fix.
A
So
hopefully
this
is
a
start
for
something
that
we
could
do
I'm
open
to
changes
the
terminology
again.
This
is
a
starting
proposal
because
it's
easier
to
start
with
something
than
to
start
with
nothing.
Michael.
G
Yeah,
this
might
be
something
we
want
to
get
the
LF
a
bit
more
involved
with
more
broadly
because
a
couple
of
had
a
couple
of
conversations
with
a
few
folks
over
at
kubecon
about
this
problem
and
I
think
the
problem
that
we're
calling
it
like
the
ontology
problem
of,
like
everybody,
calls
stuff
a
little
bit
differently.
Even
if
semantically,
they
kind
of
mean
the
same
thing
and
yeah
yeah,
and
so
there
was
Docker
so
like
Justin
Carmack
from
Docker
brought
this
up.
G
Matt
Young,
Who
I
think
is
at
Apple
now,
but
if
he
he
was
doing
a
bunch
of
stuff
from
the
cncf,
he
was
bringing
this
up.
Justin
capos,
who
from
NYU,
who
does
stuff?
Oh
nice,
yeah,
so
I
think
that
this
was
something
that
was
was
kind
of
a
big
issue
that
was
brought
up
at
kubecon.
Is
that,
given
that
everybody's
terming
things
slightly
differently
inside
of
some
of
these
things,
it
becomes
difficult
to
sort
of
understand
the
mapping
to
say
hey.
A
Yeah,
could
you
it
starts
a
thread
or
something
like
that
with
the
various
folks
sure
yeah,
because
Jay
White
mentioned
last
week
that
he'd
sort
of
I
haven't
heard
from
him
since
and
oh
Jace
right
here,
cool.
E
You
know
I
was
hoping
to
get
someone
from
they
their
act,
there's.
Actually
a
glossary
being
worked
on
and
I
was
hoping
to
get
the
one
of
the
individuals.
That's
working
on
that
glossary
on
this
call.
Today
they
had
a
bit
of
a
scheduling
conflict
this
morning,
so
they
couldn't
so
they
couldn't
be
here,
but
the
idea
is
to
get
them
on
this
call
with
us
to
go
over
what
they're
working
on
in
the
glossary.
E
That's
supposed
to
be
a
governing
glossary
for
all
of
these
kind
of
terms
across
the
open
ssf
right,
so
so
that
so
that's
what
we
and
the
idea
and
I
pitched
this
to
them.
Like
we
talked
about
last
week,
you
know
these
terms
here
versus
the
term
being
worked
on
the
glossary
and
sort
of
cross
reference
one
another.
So
they
can
take
terms
from
this.
Put
that
in
there
and
take
those
terms
we
bring
bring
them
here
so
that
everything
is
on
one
sheet
of
music
right.
E
There's,
not
the
different
terms
going
across
different
different
projects
underneath
the
same
open,
ssf
umbrella
right,
so
that
that
was
the
that
was
their
general
idea
like
that.
But
but
I'm
you
know
trying
to
get
those
schedules
to
sync
up
so
that
way
they
can
come
on
and
and
present
what
they've
been
working
on
philosophy,
wise.
E
I
was
even
attempting
to
get
a
copy
of
the
of
the
a
copy
of
the
glossary
in
its
current
form
that
wasn't
able
to
I
wasn't
able
to
snag
that
so
I
figured
the
next
best
thing
would
be
to
get
someone
working
on
it
to
come
on
over
and
actually
talk
about
what
what's
all
been
done
so
far,.
A
Yeah,
thanks
and
and
I,
you
know
we
talked
last
week
about
you
know
not
getting
blocked
on
any
sort
of
larger
agreement.
A
The
first
step,
I,
think,
would
be
like
talking
and
seeing
ideally
for
salsa
we'd
have
the
fewest
terms
necessary,
like
we'd,
only
do
the
ones
that
are
necessary
to
get
the
job
done
like
the
fewer
terms
you
have
to
learn
the
better,
and
so
that
would
be
valuable
because,
like
we
could
just
if
we
could
agree
on
like
well,
although
there's
all
sorts
of
other
Concepts
that
you
might
want
to
Define
but
salsa
needs
is
assuming
that
these
are
the
ones
that
we
actually
want
like
package,
artifact
project,
reg
ecosystem
and
publish,
let's
say
which
you
know
that
might
make
the
problem
a
little
bit
more
tractable.
A
Yeah
I,
don't
love
the
word
project.
To
be
honest
with
you,
oh
you're,
just
saying:
I
had
a
registry
project
yeah
in
general,
I,
don't
love.
A
It
yeah
it
came
up,
come
up
with
a
a
term
I
like
here.
Actually
I
didn't,
listen
originally
like
resource
was
the
term
I
used
where,
like
the
resources,
the
like
very
abstractly,
the
resources,
the
thing
that
you're
applying
you're
associating
with
an
artifact
and
so
like
when
you
publish
a
package,
you
know
like
Foo
version,
one
two,
three
dot,
tar,
gz
you're
associating
the
resource,
which
is
that
name
for
one
two,
three
Target
Z
with
this
artifact,
which
is
the
blob
of
this
hash.
A
It
was
very
abstract
and,
like
it
made
sense
to
me,
but
I,
don't
think
it
made
sense
to
most
other
people,
and
so
a
lot
of
people
read
resources
just
like
too
too
abstract
and
so
project
seems
to
be
one
that,
like
that's
like
what
python
uses
often
like
this.
Doesn't
this
this
concept
doesn't
even
have
a
name
in
most
things
like
in
in
Debian.
As
far
as
I
can
tell
a
package,
it's
just
the
package
name.
That's
this
concept
like
a
lot
of
ones.
A
A
Okay,
so
I
think
we're
out
of
type
of
position.
I
have
a
typo
there
thanks
everyone
for
for
joining,
so
next
steps
here,
I'm
I'm
working
on
the
requirements.
How
about
this?
A
For
the
next
steps
for
this
language
here
I'm
planning
on
doing
an
update
on
the
requirements
anyway,
I'll
try
to
take
care
of
that
this
one,
because
if
anyone
has
suggestions
on
the
levels,
Melba
or
or
anyone
else,
if
you
want
to
send
a
pull
request
to
kind
of
address
that
that
would
be
great
to
deconflict
and
what
were
the
other
next
steps
for
this
one
again.
A
If
people
have
thoughts
or
ideas,
you
could
send
them
my
way,
I'm
going
to
try
to
clean
it
up
into
like
a
pullable
thing
Also.
If
anyone
has
knows
a
good
way
to
like
Define
a
schema
in
an
actual
language
and
then
translate
that
to
markdown
and
wants
to
set
that
up.
That
would
be
great
I
use.
Proto
I
also
started
looking
at
Q
as
well,
but
again,
I
want
like
a
something
to
take
the
schema
in
the
schema
definition
language
and
make
good
document
nice
looking
documentation.
G
Yeah,
that
was
actually
something
that
was
being
discussed
also
at
kubecon
I
was
brought
up
actually
that
some
of
the
folks
at
the
atq
were
there
and
we
had
a
meeting
and
I.
Don't
know
about
the
markdown
thing.
That's
actually
an
interesting
thing.
I
can
I
can
see
if
it's
available,
but
they
they
do
have
some
of
that.
That
can
automatically
generate
into
back
and
forth
between
protobuf
and
Q,
as
well
as
a
few
other
things,
but
I'll
check
with
them
to
see
if
they
have
like
a
markdown
one.
A
A
There's
a
you
know
some
amount
of
work
there
cool
all
right.
Well,
that's
good!
Seeing
everyone
thanks
for
coming
and
I'll
see
I'll
talk
to
you
soon,
bye.