►
From YouTube: SLSA Specifications Meeting (September 26, 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
A
Let
me
go
and
double
check
if
Mark
or
Joshua
are
around.
B
B
It's
five
minutes
after
the
hour
hi
everyone
again
as
as
the
usual
reminder
that
actually
might
do
what
does
this
feel
that
you
usually
give.
A
B
Okay,
I
see.
Oh
Sean
also
asked
added
some
agenda:
I'll,
just
move
it
down.
I
think
I,
see
Sean
here,
I'll
move
it
down
to
the
to
the
to
the
list
of
agenda
items.
B
Are
there?
Is
there
any
other
gen
items?
Please
add
it
to
the
list
and
also,
please
remember,
to
to
check
into
the
meeting
notes.
I'll
put
it
in
the
a
bunch
of
people
have
already
pasted
the
meeting
notes.
B
So
if
you
could
check
in
D
appreciate
it,
the
I
wanted
to
call
out
the
I
created
a
pull
request,
link
to
the
doc
number
486
that
creates
a
new
1.0
directory.
I
could
just
present
it
now.
B
Just
so
folks
can
see
in
case
anyone
has
an
opinion.
I
just
need
one
or
two
reviews
on
it
to
be
able
to
get
it
submitted.
B
So
so
here's
the
the
preview.
B
It
doesn't
show
up
by
default.
You
have
to
specifically
type
the
URL
like
change
the
url,
to
view
1.0
to
find
it
I
had
this
warning
Banner
at
the
bottom.
Actually,
when
the
preview
it
doesn't
really
here,
we
go
it
conflicts
with
the
netlify
thingy
down
here
so
yeah
there.
We
go
gone
this
little
thing.
B
If
you
have
thoughts
on
what
that
looks
like
if
that's
sufficient
to
note
that
it's
a
the
unpublished
draft,
that
would
be
good
and
it
says
draft
in
the
name
and
like
the
little
version
picture.
So
if
we
go
to
like
security
levels,
you
know
it
says
1.0
draft
over
here
and
then
some
implementation
stuff.
B
So
if
anyone
could
review
that,
that
would
be
appreciated
and
then
once
we
have
that
I
think
we
could
start
sending
pull
requests
to
actually
address
issues
for
1.0,
and
my
feeling
is
that
being
that
we
have
this
banner
and
that
it's
not
linked
to
by
default.
It's
fine
to
just
serve
it,
and
then
you
know,
anyone
who
wants
to
look
at
the
latest
draft
can
just
go
to
the
website.
B
B
Should
we
switch
to
Sean's
question
about
the
Disney
envelope?
Spec
come
on.
C
D
So
this
stems
from
my
surprise,
at
seeing
the
spec
and
after
having
seen
well
mostly
in
Toto,
at
the
stations
with
Dizzy
envelopes
that
contain
the
certificates
that
it
wasn't
in
the
spec
and
then
I
noticed
there's.
Actually
this
pull
request
that
I
know
Mark
you've
had
some
back
and
forth
on
on
this.
D
It
seems
like
one
it's
already
common
practice
to
be
doing
this
and
two,
it
just
seems
like
a
good
idea
to
be
able
to
distribute
the
certificate
alongside
it
because
it's
you
know,
people
distribute
the
gpg
signatures
alongside
things
and
you
have
to
go
digging
for
the
keys,
whereas
this
gives
you
a
verifiable
path
back
to
a
trusted
source
for
the
key.
D
That's
signed,
the
attestation,
so
I
think
it
just
makes
it
terribly
convenient
to
at
least
do
a
verification
of
the
attestation
if
the
certificate
is
present
but
I'd
like
to
see
these
get
bogged
down
into
in
the
devil
as
a
details,
because
I
think
it's
just
really
useful.
A
So
I
I
thought
this
was
already
in
there
because
I
thought
in
the
The
Dizzy
envelope
markdown.
It
does
say
you
know
you
can
include
the
key
along
with
the
signal.
Oh
sorry,
the
key
ID
I
see
yeah.
B
Yeah
thanks
I,
to
be
honest
with
you
as
a
reviewer,
I,
add
my
comments
and
then
I
just
kind
of
evict
it
from
my
memory
and
I
wait
for
the
author
to
Ping
it
but
I'll
ping,
the
author
to
see.
If,
if
she
can
update
the
some
of
these
things
and
if
we
want
to
defer
some
changes
to
a
future,
pull
request.
I'm
fine
with
that
too,
but
I
think
the
ball
was
in
her
Court.
A
B
Let
me
I'll
set
a
reminder
to
that
right
now,.
D
D
B
Agreed
yeah,
let
me
let
me
ask
asra
and
see
if
she
wants
to
do
that
and
if
she's
not
interested,
then
you
know
we
could
just
copy
the
pull
request
and
and
make
changes
again.
But
I'm.
B
Most
issues
should
be
pretty
quick
to
fix,
sounds
good
thanks,
thanks
for
reminding
I
think
there's
also
one
around
this.
This
is
actually
related
to
the
cosine
has
their
own
like
envelope,
format
that
has
I
think
the
certificate,
but
also
I,
think
like
the
time
stamp
Authority
or
like
the
timestamp
thingy
that
that
one
would
be
another
one
that
we
could
add
a
field
to
I
think
we
just
need
someone
with
a
concrete.
You
know
like
concrete
use.
B
D
So
for
an
example,
you
know
Microsoft
uses
in
in
authentico
to
make
sure
that
code
keeps
running
if
the
signature
was
valid
at
the
time
that
the
certificate
was
valid
and
if
you
you
know,
laterally
invalidates
the
certificate.
Your
code
will
keep
running
and
you've
got
a
window
where
you
can
at
least
go
and
get
freshly
signed
bits.
D
B
The
the
changes
from
The
Proposal
in
order
to
talk
about
like
split
the
levels
I,
could
show
what
I
have
now.
It's
still
like,
I
I
had
to
stop.
My
work
day
ended
like
in
the
middle
of
like
writing.
A
paragraph
and
I
haven't
touched
it
since.
So
it's
like
totally
extremely
draft
right
now,
but
I
can
share
what
I
have
so
far
just.
B
Hopefully
get
people
moving,
so
one
thing
I
wanted
to
ask
was
like
I
need
to
name
these
things
like
what
are
all
the
different
sets
of
things
and
so
I
said
tracks.
B
I
thought,
maybe
that's
a
decent
name
like
salsa
levels
are
spinning
tracks
in
each
track.
Has
its
own
set
of
levels
that
measure
a
particular
aspect
of
security,
so
there's
a
build
track
and
a
source
track.
So
the
build
track
is
what
we
have
here:
I'll
replace
all
this
text
with
some
better
writing
that
was
one
of
the
to-do's
and
a
source
track
I,
still
not
written
any
thoughts,
one
way
or
the
other
early
feedback.
C
Yeah
I,
so
I
I
was
just
looking
at
the
GitHub
issue.
I
forget
the
number
where
we're
discussing
whether
or
not
to
defer
the
source
levels
for
1.0.
So
is
the
idea
that
there
will
be
sort
of
a
source
draft
for
1.0
that
isn't
officially
part
of
it,
or
should
we
just
not
mention
Source
at
all.
A
Yeah,
so
something
to
put
a
pin
in
for
for
this
particular
thing
and
I,
and
if
we
have
time
later
on
in
this
meeting,
I
do
want
to
talk
about,
is
I
do
think.
A
Even
if
we
we
don't
have
necessarily
a
draft
of
what
the
source
requirements
are
going
to
be
or
whatever
by
1.0
I
think
we
still
need
to
have
a
clear
definition
of
what
source
is
for
1.0,
because
it
that
specific
thing
like
source
and
dependencies
and
some
of
the
other
things
are
still
fairly
contentious
as
to
what
it
actually
means
and
I.
Think
that
should
be
made
clear
in
that
document.
At
the
least.
B
B
B
I
want
to
fully
flesh
that
out
and
we're
like
What
right
now
we
Define
build,
but
we
don't
Define.
We
don't
have
like
a
link
for
source
that
I
think
that
can
naturally
go
in
there
package
as
well.
B
B
Notion
of
when
we
have
like,
like
an
OS,
maintain
like
an
OS
distribution,
maintains
a
package
and
like
they
import
their
Source
into
their
own
repo
and
add
their
own
package.
Etc
I
think
that'll,
ideally
would
be
described
in
the
terminology
section.
So
I
have
a
model
for
how
that
all
works.
A
A
I
know
that
there's
there
are
a
couple
of
other
groups
out
there
like
a
wasp
and
and
some
others
that
have
potentially
defined
some
of
these
things
already.
So
it
might
be
something
that
at
least
we
can.
We
can
look
at
as
a
prior
art.
D
D
B
E
So
I
will
say
from
the
spdx
side
a
package
is
supposedly
a
collection
of
one
or
more
files.
E
Now
it's
it's
interesting,
because
the
difference
between
source
and
package
that
would
be
whether
depends
upon
what
you
are
Distributing.
So
in
the
end,
the
package
is
anything
that
you
are
Distributing
or
hosting
or
in
any
way
sharing
with
someone
else.
B
Yeah
I
think
the
package.
D
B
Have
terms
that
are
just
like
that
most
people
read
it
and
don't
get
the
wrong
impression
and
so
yeah
I
think,
if
my
guess
is,
it
might
be
good
to
avoid
that
anyway.
Well,
we'll.
E
Yeah
I
mean
I
like
I,
like
the
idea
of
just
like
trying
to
Define
what
the
thing
actually
does
or
where
it's
being
used
or
the
properties
of
it,
rather
than
focus
on
the
name.
E
E
B
So
so
we
don't
have
a
large
agenda
today.
I
think
we
could
either
I
don't
know
the
best
way
to
use
time.
We
also
have
what
16
people
here
so
I
want
to
use
our
time
wisely.
B
If
other
folks
have
thought.
Oh
Mike.
A
Oh
I
mean
I
think
the
one
thing
that
I
would,
if,
if
we
had
the
time
and
is
and
I
know
it's
another
sort
of
definition
thing
here,
but
us
to
kind
of
I
think
at
least
try
and
sort
out
a
little
bit
of
the
the
dependencies
and
materials
and
Source
discussion
just
so
that,
like
we
can
potentially
disambiguate
like
what
it
means
in
the
requirement.
A
No,
no
not
for
the
source
requirements.
The
the
sorry
I
I
said
this.
The
requirements
that
say
like
you
must
specify
the
source
like
what
is
even
a
source.
What
is
even
a
dependency
I
think
we
just
need
to
make
sure
that
we're
a
little
bit
more
clear
about
it.
Even
if
that
thing
is
anything
that
is
a
dependency
is
a
source
and
anything
that's
a
source
is
a
dependency.
A
A
Are
they
all
considered
the
source?
Now,
I
no
longer
have
a
single
way
of
specifying
The
Source
like
I
could
like
just
a
commit
ID
and
then
the
same
thing
with
dependencies
right
like
if
I'm
pulling
third-party
code
is
that
dependencies
is
that
the
source
I
think
there's
a
lot
of.
There's
been
a
lot
of
confusion
from
folks
about
what
what
that
means,
and
then
you
know,
as
I
think
even
sean
had
sort
of
mentioned
is
like.
Can
we
even
really
make
the
distinction
between
you
know
even
a
packaged
binary
as
a
dependency?
C
A
D
Yeah
I
think
this
is
this
is
complicated
when
you
think
about
most
build
systems.
You
end
up
with
you
start
with
a
piece
of
source.
You
start
with
a
a
build
script
and
you
have
all
the
dependencies
that
have
to
be
there
in
order
for
build
script,
to
succeed
with
the
source.
But
then
there
are
build
systems
like
well,
there's
not
so
much,
not
so
bad
now,
but
it
used
to
be
like
the
open
GDK
where,
before
you
could
even
start
I
guess
qt6
is
probably
similar
in
the
before
you
start.
D
There
are
a
whole
range
of
different
pieces
of
source
code.
You
have
to
gather
together
before
you
can
start
doing
it
and
each
one
of
those
individually
could
be
considered
a
source,
so
you've
got
different
ways
of
looking
at
these
things
and
we
need
to
try
and
Encompass
as
many
as
we
can.
But
you
know
I.
My
personal
definitions
are
that
you
know
the
source
is
what
is
acted
upon.
D
D
So
you
know
that
that's
kind
of
how
I
categorize
them
and
how
we
categorize
them
at
active
state.
But
it's
I
think
it's
highly
subjective
and
it's
one
of
those
things
that
potentially
could
end
up
being
a
bit
of
a
flame
wall.
B
Yeah
I
I
think
so
so
can
you
repeat
what
you
just
said
or
type
it
in
here
just
so.
We
have
like
a
proposal
I
think.
Basically,
we
just
need
well.
B
I
think
that's
similar
to
in
spirit
to
what
I
had
in
the
first
post
of
number
129.
But
if
you
could
write
what
you
said,
that'd
be
great
I,
think
in
terms
of
I,
so
I
had
proposed
in
in
terms
of
inputs.
I
think
there
is
the
and
we'll
see
if
this
agrees
with
Sean
the
build
configuration,
which
is.
B
Build
configuration,
build
parameters
source
so
like
the
build
configuration
would
be
like
the
config
as
code
of
the
build
system,
for
example
in
GitHub
actions.
This
would
be
the
workflow
definition
file,
the
dot
GitHub
workflow,
slash
whatever
you.
B
B
And
I
think
Sean
also
mentioned.
Like
then
there's
everything
else:
that's
needed
to
run
the
build
I.
Think
dependencies
are
maybe
the
there's
kind
of
a
blend
between
source
dependencies
and
environment
I
had
been
thinking.
I
think
we
may
have
a
definition.
Environment
is
like
the
things
that
are
on
the
machine
that,
like
the
user,
didn't
pick
so,
for
example,
in
GitHub
actions.
That
would
be
like
the
VM
that's
set
up
and
that
there's
different
versions
of
that,
and
we
should
record
that.
But
it's
not
like
arbitrary
things.
B
It's
kind
of
chosen
by
the
build
system-
and
maybe
you
pick
among
a
choice
of
them
but
you're,
not
just
grabbing
arbitrary
artifacts
dependencies,
would
be
things
that
are
needed
during
the
build
that
are
not
actually
the
code
itself,
like
libraries
tools,
Etc
anything,
that's
kind
of
fetched,
Over,
The
Wire,
and
then
that
leaves
a
weird
spot
for
Source
because,
like
how
do
you
tell
the
difference?
The
from
the
build
systems
perspective?
B
The
build
configuration
is
clear
because
it
read
it,
so
it
knows
what
it
read,
but
then
differentiating
between
sources
and
dependencies
is
sometimes
there's
like
a
trigger
for
the
source
of
like
you
know.
Whenever
you
see
a
commit
on
this
repo.
Do
this,
and
usually
the
action
is
to
fetch
that
source
and
build
it,
but
there's
no
guarantee
that,
for
example,
a
GitHub
actions
workflow
actually
builds
that
same
repo.
It
could
fetch
a
different
repo
and
build
it
entirely.
A
Okay,
yeah
I'll
go
real,
quick
yeah,
so
one
of
the
things
that
I
know.
If
we
look
at
some
of
the
like
prior
art
out
there
like
Nicks
and
Wix,
and
how
they've
sort
of
done
this
in
the
past,
they
they
don't
make
any
distinction
between,
like
the
literal
source
code
and
dependencies,
because
they
pretty
much
argue
that
you
can't
make
that
distinction.
A
But
they
do
make
a
distinction
between
build
dependencies
and
dependencies
that
are
either
included
in
the
artifact
or
our
runtime
dependencies
and
then
another
thing
that
they
do,
which
is
something
that
I
don't
think
we
we
can
do,
but
they
essentially
view
like
if
you
do
have
a
package
as
a
dependency,
something
that
would
be
like
a
binary
or
whatever
you
don't
rely
on
the
binary
directly
similar
to
bazel
and
a
lot
of
those
other
pants
and
a
lot
of
those
other
build
tools.
A
You
actually
rely
on
the
build
definition
of
that
package,
and
so
there
is
like
a
potential
there
for
would
somebody.
Is
there
the
option?
For
somebody
to
say:
hey,
I
rely
on
this
salsa
attestation,
which
defines
my
dependency
I,
don't
know,
I
I.
Think
we
probably
couldn't
do
that
generally
because
we're
trying
to
say
Salsa's
not
transitive
but
I,
wonder
if
that's
just
an
option
that
that
helps
simplify
things
for
some
people.
E
Maybe
make
a
distinction
between
you
know,
inputs
and
configuration,
but
I
wonder
if
might
be
easier
for
the
specification
to
say
that
to
use
inputs
as
a
generic
term
and
not
you
know,
distinguish
any
further
that
we,
you
do
not
have
to
make
a
distinction
between
inputs
that
you
know
of
which
can
include
source
code
and
direct
dependencies
and
inputs
that
you
don't
know
of
which
may
include
transitive
dependencies
and
things
that
are
being
fetched.
E
Over,
The,
Wire
and
probably
put
all
the
things
like
the
configuration
files
and
environment
variables
as
configuration
in
general
or
settings.
Something
like
that.
E
Yeah
so
maybe
use
some
genetic
terms.
There.
D
Yeah
I
think
at
a
technical
level
you
can
say
that
you
know
they're,
all
inputs
are
equal,
the
build
system,
some
build
systems,
might
disagree,
but
you
could
just
call
them
all
dependencies
and
say
that
everything
that
comes
in
in
order
to
build
the
the
artifact
that
comes
out
is
a
dependency
but
I
think
in
in
real
world
usage
that
might
come
off
as
a
little
confusing.
D
If
we
know
if
we
can't
say
as
a
group
that
I've
downloaded
The
Source
distribution
for
URL,
lib3
and
I've
built
URL
lib3.whl
as
a
wheel,
that
I
can't
point
at
the
original
Source
distribution
to
say
that's
the
source.
If
I
can
just
say.
Well,
no,
that's
just
another
dependency,
you
could
say
well,
you've
got
you
know
the
python
core.
You've
got.
You
know
your
bcm2
libraries
you've
got
it.
D
It's
I
think
it's
important
to
be
able
to
draw
a
clear
line
between
the
source
code
and
the
bits.
So
that's
kind
of
what
we're
trying
to
do
is
I
is
kind
of
is
give
you
that
chain
of
custody
between
the
source
code
that
the
author
produced
and
the
bits
that
are
finally
delivered
to
you.
E
But
that's
that's,
probably
a
distinction
between
what
you
know
and
what
you
can
control,
what
you
control
and
what
you
can't
control
so
sources.
The
input
that
you
control
and
everything
around.
It
is
stuff
that
you
can't
inputs
that
you
can't
control.
E
So
there's
a
like
a
hierarchy
over
there
dependent
on
you
know
the
thing
that
you
the
thing
that
you
have
created
like
the
the
person
who
had
authored
all
the
files,
the
stuff
that
the
author
has
created
and
the
stuff
that
the
author
has
reused.
E
D
Yeah
I
think
you,
the
the
argument.
Over
Control
depends
a
lot
on
where
you
sit
in
the
in
in
the
chain
of
custody.
So,
for
example,
if
you're
author,
you
have
control
over
what
we
what
we
might
consider
to
be
the
source,
but
if
you're
GitHub
or
someone
who's
who's
building
the
source,
you
probably
have
more
control
over
the
dependencies
that
are
put
in
than
you
than
you
do
over
the
source
code.
E
Yeah
I
mean
I'm
just
putting
these
terms
out
there,
so
maybe
there's
we
can
create
a
framework
around
how
we
Define
these
terms
for
the
specification.
B
Yeah
I
think
two
comments.
One
I
I
tend
to
agree
with
I
think
if
I
understand
you
shouldn't
Sean
I,
think
I
think
you're,
basically
in
agreement,
if
I
understand
correctly
and
I,
think
I
agree
that,
like
from
a
technical
level,
the
because
I'm
coming
at
this
from
what
can
a
builder
a
build
system
guarantee
when
when
they
the
tenant,
the
user
is
writing.
The
build
scripting
can
do
arbitrary
things
and
it
sounds
like
there
is
value.
B
I
think
this
matches
what
we
had
said
briefly,
there's
value
in
identifying
something
nominally
as
the
source.
Even
if
there's
no
real
technical
control
to
know
like
that
is
the
actual
thing
that
was
compiled
as
like
the
top
level
program
versus
some
other
artifact
with
actually
it
and
and
so
build
systems.
I
guess
there
would
be
a
requirement
that
they
do
identify
that
thing
and
there
doesn't
have
to
be
a
technical
Patrol,
because
we
can't
possibly
think
of
one.
B
What
that
would
be
sounds
like
my
other
comment
is
on
the
the
meaning
of
dependencies
and
and
I.
Think
this
also
again
why
I
wanted
to
Define
this
in
the
docs
I.
Think
what
we
mean
here,
Transit
versus
like
direct
dependencies
I
think,
is
a
little
bit
confusing.
B
It
is
all
the
things
that
were
needed
during
the
build
build
time
dependencies
and
if
it
was
needed
during
the
build
it's
there,
if
it's
not
needed
during
build,
it's
not
so,
for
example,
if
you
have
a
container
image
as
a
dependency,
then
you
just
leave
the
container
image,
but
not
the
things
that
were
in
the
container
image
or
if
you
have
like
vendored
source
code,
where
you've
checked
in
a
library
into
a
git
repo.
B
You
just
list
the
git
repo
and
not
all
of
the
sub
directories
that
are
found
within
the
gear
repo.
So
it's
yeah
I
think
that's,
that's
how
we
mean
it
and
then
doc
should
should
more
clearly
Express.
That.
C
So
I
had
two
things
one
is
we
really
need
to
choose
a
point
of
view
because
I
I
saw
I
heard
Sean
saying
you
know
like
from
a
GitHub
perspective
right.
The
build
system
wouldn't
necessarily
have
control
over
the
source,
but
if
we
want
to
take
the
point
of
view
of
build-
and
we
should
state
that
versus
the
people
actually
creating
the
code
or
using
the
code,
so
is
it
a
person
or
is
it
a
system
point
of
view?
D
Yeah
I
think
that's
we're
modeling
some
things
up
here
a
little
bit
and
that
there
are
build
time
dependencies
and
build
time.
Dependencies
can
be
direct
and
transitive
and
then
runtime
dependencies
as
well,
which
are
only
required
to
actually
when
you
come
to
use
the
the
artifact
that
you've
got
so,
for
example,
you
might
need
if
you're
building
something
with
building
a
python
module.
You
might
need
the
python
core
and
all
of
its
dependencies
plus
setup
tools,
Wheels
Tom,
all
some
of
those
packages.
D
You
need
all
those
at
build
time,
but
then
you
might
need
something
else
at
runtime
things
at
runtime,
I.
Don't
think
we
really
care
about
right
now.
Those
are
more
the
more
the
area
of
the
package
manager,
because
the
package
manager
needs
to
make
sure
that
when
it's
installing
artifacts,
the
runtime
closure
is
complete.
But
at
build
time
we
only
need
to
know
about
the
build
closure
so
yeah.
So
you
could
say:
I
need
setup
Tools
in
order
to
build
setup
tools,
needs
and
that's
a
direct
dependency
set
up
towards
need.
D
C
Yeah
because
I
mean
I
I,
think
of
like
OEM
code,
or
you
know.
Let's
say
we
use
a
red
hat
image
right,
we're
calling
that
image
and
it's
a
direct
dependency,
but
whatever
that
red
hat
image
needs
to
download.
We
we
wouldn't
call
right,
and
so
that's
why,
regardless
of
whether
it's
during
build
right
or
or
not,
something
that
you
explicitly
State
I
need
this
and
everything
else
it
has
to
get
pulled
in,
because
in
order
to
get
that
needed
object,
it
goes
and
pulls
that
other
information,
even
during
build.
A
So
I
think
what
complicates
that
then
is
the
only
dependency
that
would
be
included
would
literally
be
the
build
config.
So
I
would
because
everything
else
could
be
inferred
from
the
build
config,
but
then
I
think
the
problem
there
is.
We
also
run
into
the
issue
of
if
everybody's
not
completely
pinning
all
their
dependencies
by
hash,
then
you
potentially
lose
all
of
that
other
useful
metadata
about
like
what
you
know,
what
what
versions
of
what
packages
and
what
hashes
of
what
packages
you
end
up
with.
E
But
isn't
that
a
method
by
which
you
could
make
an
assessment
on
the
build
so
a
build
that
has
a
bill
definition
that
has
more
explicit
information
is
a
higher
quality,
build
than
a
build
that
has
less
of
it
so
like.
Even
if
you
were
to
point
to
just
one
configuration
file,
that's
still
a
definition
of
a
build.
It's
just
not
Rich
enough
for
you
to
make
a
reasonable
assessment
about
the
build,
and
hence
you
could
call
it
a
not
that
high
quality
build.
B
I
I
guess
you
know
in
terms
of
so
maybe
let
me
try
to
recap
what
what
we
just
discussed
first
to
see
if
we're
on
the
same
page,
about
the
proposal
in
terms
of
inputs
to
the
build
we
have
like
the
build
config
well.
First
of
all,
are
people
really
like
there's
a
build
configuration
that
the
build
system
actually
reads
and
knows
this
was
the
thing
I
actually
read,
which
is
sometimes
the
same
as
the
source
and
sometimes
different,
and
then
all
the
stuff
that
the
build
script
required.
B
Which
could
be
broken
up
into
The
Source,
the
nominal
source
that
was
being
built
and
like
declared
or
direct
dependencies
and
transfer
indirect
dependencies?
That
kind
of
came
along
as
part
of
that
and
that
there's
no
way
for
the
build
system
to
really
differentiate
between
those
three
Source
versus
directors
and
direct
dependencies,
but
that
it
could
be
useful
for
Downstream
systems.
And
so
the
kind
of
the
build
script
or
the
tenant
of
the
build
system
can
add
that
information
as
like
FYI.
A
I
I
think
so
I
think
the
only
thing
that
is
still
kind
of
an
ambiguous
there's,
a
little
ambiguous
is
I.
Remember
us
having
earlier
on
months
and
months
and
months
ago,
like
some
discussions
about
how
do
we
also
make
sure
that
it
is
like
some
of
the
information
that
we're,
including
inside
of
a
salsa
attestation,
is
also
for
Downstream
systems
to
potentially
consume.
And
even
if,
let's
say
a
lot
of
this
additional
metadata
can
be
inferred
from
the
source
if
and
by
the
source.
I
mean
like
the
build
config
itself.
A
If
folks
do
not
have
access
to
the
build
config,
because,
let's
say
it's,
the
vendor
build
config,
but
the
vendor
wants
to
tell
you
hey,
I,
yes,
I'm,
not
giving
you
access
to
my
actual
build,
but
I
am
giving
you
I
am
telling
you,
or
at
least
I'm,
making
claims
about
what
I
built
and
what
dependencies
I
used,
what
source
code
I
used
and
whatever
so
that,
if
I
ever
get
audited,
I
can
show
you
that
I
wonder
if
there's
there's
any
just
general
concerns
about
that.
E
So
I
I
think
that
maybe
something
that
you
could
probably
get
the
bill
system
to
provide
for
you.
E
So,
maybe
not
maybe
not
something
that
you
would
know
in
advance,
but
at
least
like
the
bill
system
would
be
able
to
give
you
some
some
of
that
information,
and
then
you
can
make
an
assessment
on
the
build
system
in
that
way.
So
there's
there's
I
mean
I.
Guess
my
point
is
that
it's
it's
not
necessarily
about
how
much
the
you
know
how
much
information
you
want
to
explicitly
put
into
the
specification,
but
you
can
make
it.
E
Yeah
so
the
way
that,
like
for
example,
you
could
have
you
could
create
references
to
other
provenance
statements
that
a
bill
system
May
create
for
you.
So
you
create
one
prominent
statement,
the
build
system,
and
then
you
can
say
like
okay,
here's
a
placeholder
for
the
stuff
that
the
build
system
creates,
and
then
the
build
system
says
okay.
This
is
all
the
things
that
I
know
of.
B
I
think
that's
I
mean
today
right
like,
besides,
like
the
next
inactive
State
and
like
the
handful
of
and
basil
based
ones
and
a
handful
of
ones
that
do
like
all
the
work
and
fully
specifying
I
think
the
state
of
the
art
for
most
limited
state
electron
order,
but
most
software.
Today's
built
without
that,
like
that
detailed
information
being
verified.
B
B
That
I
would
like
to
work
out
before
making
that
requirement,
but
since
we
only
have
a
few
minutes
left
in
in
terms
of
the
actual
levels
and
requirements,
where
does
this
put
us?
What
should
be
required
at
what
level
I
think
listing
all
of
the
dependencies?
B
Well
I
I,
think
I
already
have
agreement
here
will
not
be
required
at
level
build
level
three
because,
like
that
was
that
was
previously
required
at
salsa,
for
it's
too
big
of
a
jump
to
ask
to
do
at
level.
Three.
So
I
think
that's
that's
out
right
now,
I,
don't
remember
where
the
build
configuration
is
required.
If
it's
a
level
two
or
three,
and
the
question
is
where
should
the
source
go
like.
A
Oh
yeah
yeah,
that
was
one
of
the
things
that
was
brought
up
about
like
what
counts
as
materials.
Oh
sorry,
what
counts
as
Source
there
right
like
there
is
at
some
point
there
is
some
build.
That's
saying
to
do
a
thing
and
I
think
this
is
the
thing
where,
where
it
keeps
going
back
to
what
is
practical
versus
like
clearly,
if
you
have
a
build
config-
and
you
are
also
capturing
the
inputs
to
that
build
config.
A
If
there
are
external
inputs,
then
you
know
what
the
source
is
going
to
be
right
because
that
build
config
would
go
and
say:
okay,
download
this
thing
download
these
dependencies,
whatever
so
I
think
we
have
that,
but
I
think
that
there's
still
an
element
of
yeah
but
like
it's
still
useful,
to
have
that
additional
information
right
for
folks
and
some
people
might
want
to
specify
that
additional
information
so
that
people
can
go
back
and
say
hey.
There
are
certain
types
of
packages.
A
I
know
I
do
not
want
or
there's
certain
types
of
things
in
my
salsa
thing
that
based
on
a
policy
I
know
I,
don't
want
or
whatever,
or
we
could
just
say,
keep
it
very
generic
and
just
say
whatever
the
build
config
is:
should
capture
enough
information
to
do
the
rebuilding
and
just
leave
it
at
that
and
everything
else
that
kind
of
goes
from
there.
A
Another
practical
thing
is
potentially
just
some
way
of
capturing
the
entire
build
environment
as
a
hash
of
some
sort.
I
know,
I.
Think
a
few
folks
had
talked
about
potentially
saying
hey
if
I
have
a
container,
if
I
take
a
snapshot
of
the
build
container
I,
essentially
like
the
snapshot
of
the
build
container,
along
with
all
of
its
inputs
or
whatever,
especially
and
there's,
there's
hashing
mechanisms
for
that
recursive
hashing
mechanisms-
for
that
you
can
say
hey
here-
is
a
unique
identifier
of
all
the
things
included
in
that
build.
B
B
I'm
still
not
sure
where
that
puts
us
with
respect
to
the
levels
here,
let
me
present
what
you
know.
The
current
all
right
at
level.
One
we
have
identified
the
artifact
by
hash,
that's
straightforward,
identifies
the
Builder
straightforward
identifies
build
instructions
is
level
one
and
identify
source
code
at
level
two
and
the
entry
point
at
level.
Three.
B
B
B
Anyway,
we
don't
really
maybe
have
enough
time
to
play
discussions.
A
lot
of
people
are
dropping,
but
maybe
that's
something
to
think
about
going
forward
of
like
what
would
make
sense
and
what
would
be
a
good
path
like
that
that
could
be
incremental
like
if
at
level
one
if
we
don't
even
have
a
build
Service.
What
would
be
practical
to
list
here?
Is
it
practical
to
require
to
at
level
two
where
there
is
a
build
service?
Is
it
okay
to
requirement
right
away,
or
is
that
too
difficult
to
implement.
A
I
can
take
some
of
this
as
a
takeaway
to
try
and
write
up
a
proposal
on
on
some
of
the
changes.
I.
It
probably
won't
be
like
completely
defined
as
like
identifies
build.
Instructions
should
be
changed
to
this,
but
at
least
the
general
things.
A
A
Oh
there's,
a
lot
of
things
between
what
counts
as
Source
versus
what
counts
as
build
instructions,
especially
if
some
folks
are
saying
like
hey
here's,
our
internal
patches
of
the
Upstream
Source
stuff,
like
that
and
I
think
we
might
just
need
to
draw
a
line
in
the
sand
of
just
keeping
it
generic,
because
there's
no
easy
way
to
distinguish
between
them.
B
Sounds
good?
Could
someone
volunteer
to
recap
the
discussion
on
the
better
defined
source
issue.
B
Okay,
well
at
the
minimum
I'll
mentioned
on
the
issue
that
we
discussed
it
here
and
link
to
it,
and
if
anyone
has
the
the
time
to
be
able
to
comment
on
the
issue,
that
would
be
valuable,
too
and
and
then
we'll
have
I
think
the
next
step
would
be
to
actually
have
a
concrete
proposal.
A
pull
request
of
actually
defining
this
great
all
right,
I
think
we're
out
of
time.
Thanks,
everyone
and
I'll
see
you
I'll
either
talk
to
you
online
or
see
you
next
week
later.