►
From YouTube: SLSA Specifications Meeting (February 27, 2023)
Description
Meeting notes: https://docs.google.com/document/d/1kMP62o3KI0IqjPRSNtUqADodBqpEL_wlL1PEOsl6u20/edit#heading=h.yfiy9b23vayj
C
A
So
we
did
a
release
of
the
release
candidate
on
Friday
kind
of
at
the
end
of
the
day,
because
it
took
the
whole
week
to
get
all
the
changes
in,
but
we
announced
it
on
the
blog
on
this.
It's
also.dev
blog.
Thank
you,
everyone
who
contributed
both
to
the
specification
itself
and
also
comments
on
the
blog
post.
A
So
hopefully
we
could
we'll
get
feedback
on
the
spec
itself.
We
I
think
we
still
have
a
list
of
things
that
we
would
like
to
do
for
the
stable
release.
There's
like
there's
still
like.
If
we
look
at
the
project
board,
there's
still
a
bunch
of
bugs
open
around
Clarity
terminology,
consistency
across
the
site,
Etc
so
like
I'm,
still
planning
on
working
on
that
and
getting
that
out.
A
A
We
have
hired
a
company
cycle
to
do
a
layout
change
because
right
now,
there's
no
nav
bar
on
the
like
to
jump.
Between
pages,
and
so
they
have
a
they
put
together,
a
bunch
of
ski,
like
theme
changes.
So
that
way
you
could
kind
of
navigate
between
Pages
and
a
couple.
People
on
the
call
here
have
looked
at
their
initial
design
and
so
I
think
they
should
be
sending
out
this
week.
I
think
so
that
at
least
will
help
navigation.
E
A
G
We'll
working
through
the
the
conformance
program
stuff,
so
that's
going
well.
I've
got
a
first
draft
of
the
terms
of
service
and
compliance
guidance,
stuff
and
then
I've
Chris
I
got
some
comments
out
for
you
on
that
point,
but
hopefully
we
can
get
back
to
the
Linux
Foundation
lawyers
and
keep
the
progress
moving
forward
on
on
that
item
there.
A
A
G
A
A
E
A
A
Here
it
is
I'll,
make
the
window
a
little
bit
smaller
too,
so
it's
not
so
tiny.
The
I
think
there
is
so
just
kind
of
summarizing.
What's
here,
we'd
like
there
should
be
a
proper.
What's
new
page,
that's
kind
of
missing.
We
have
the
blog
post.
We
just
didn't
get
this
out
in
time
and
we
aired
on
the
side
of
sending
out
the
release
candidate
without
it
rather
than
having
this,
but
we
have
the
blog.
We
reference
the
blog
post
currently
for
a
summary
of
the
differences.
A
There's
like
tracking
changes,
I
think.
Actually
these
two
should
be
marked
as
duplicates
one
another
around
like
I.
Think
there's
another
one
about
semantic
versioning,
basically
how
we
version
the
spec
that
we
should
get
in
before
the
final
compare
you
know
showing
where
salsa
is
making
sure
that's
also
1.0
and
s2c2
ever
aligned
that
that
also
we
need
to
do
I.
Think
the
verification
story
is.
A
A
Like
where
like
do
the
build
levels,
include
verification
like
expectations
or
is
that,
like
a
separate
thing,
that
I
think
needs
to
be
worked
out
compliance
program,
I
think
we
should
now
Mark
as
not
part
of
the
1.0
release.
So
maybe
we'll
remove
that
same
thing
here
we
need
to
resolve
that
question.
A
A
A
B
A
A
Yeah,
actually
so
one
so
one
I
guess
the
big
piece
of
feedback
that
came
up
that's
right
because
we
didn't
meet
last
week.
So
we
didn't
discuss
was
the
the
build
levels
and
expectations
like
the
expected,
for
example,
expected
Source
repo
right
now
it
is
listed
as
part
of
the
build
level.
So
it's
also
does.
A
A
Since
you
can't
see
my
URL
set
like
setting
expectations
is
part
of
the
track
and
then
what
the
track
gives
you
is
checking
that
it
was
built
like
according
to
those
expectations
and
then
like
evading
verification
like
that
is
part
of
like
the
guarantee.
Oh,
oh
crap.
Sorry,
click
the
wrong
button.
Thank
you.
Melba,
okay,.
A
So
let
me
say
again
so
setting
X
now,
can
you
see
the
the
levels
did?
Okay.
Thank
you.
Sorry.
So
like
setting
expectations
and
checking
against
those
expectations
like
again
sort
like,
for
example,
Source
repel
as
the
most
likely
thing
is
part
of
the
track,
and-
and
we
say
like
that-
you
check
against
those
as
part
of
the
requirements
and
then,
when
you
go
to
the
requirements
page
like
the
producer.
A
A
F
Are
you
pulling
it
in
or
are
you
pushing
it
in
as
well
right
because,
like
if
you're
pulling
it
in,
then
it's
the
build
the
Builder's
responsibility,
essentially
to
make
sure
that
you
know
it's
pulling
in
only
from
you
know
reliable
places
and
that
it's
it's
operating
in
you
know
relatively
secure
environment
where,
like
DNS,
is
not
being
spoofed
and
whatever
else,
but
if
the
idea
is
that
the
you
know
something
external
to
it
is
packaging
it
up
and
pushing
it
into
the
build.
Then
yeah
I,
don't
know.
A
What
they're
trying
to
write
some
notes?
Yeah
they
so
the
yeah
I,
think
that's
right,
like
the
the
param
or
we've
been
calling
parameters
is
effectively
the
stuff
that's
being
pushed
in
and
like
dependencies
are
kind
of
like
the
things
that
are
being
pulled
in
yeah
I.
Think
I,
like
the
push.
First
of
all
so
like
what
this
kind
of
slight
change
in
philosophy
would
mean.
A
If
we
go
down
this
road
would
be
effectively.
You
can
look
at
an
artist
and
sorry
if
this
is
like
two
like
philosophical
theoretical,
but
like
if
you,
if
you
could
just
have
an
artifact
as
Providence
in
isolation
of
where
it's
supposed
to
be
pushed
published
to
like
no
package
name.
Anything
just
like
artifact
is
provenance
that
that
thing
has
a
level,
and
you
know
where
the
thing
came
from
kind
of
just
in
isolation.
A
That's
the
property
that
we
had
in
the
previous
version
of
the
spec
and
and
there's
and
that's
kind
of
an
there's,
some
nice
attributes
to
that
where
I
had
been
kind
of
pushing
toward
is
like
with
just
that.
You
don't
get
this
like
you,
don't
address
these
threats,
see
in
the
diagram
and
so
I
was
and
I
think
Joshua.
D
A
A
There
is
something
nice
about
like
an
artifact
can
just
be
checked,
and
that
part
has
a
name
and
you
could
call
it
something,
and
so
the
question
is
like
if
we,
if
we
call
that
just
like
kind
of
this
piece,
the
level
do
we
give
this
thing
a
separate
name.
Is
that
a
track?
Is
it
like?
How
do
you
kind
of
get
the
end-to-end
guarantee?
I,
don't
know.
F
F
F
Right
because,
like
let's
say,
I
I
pull
down
some
source
code
with
a
particular
commit
cool
that
has
to
like
assuming
the
build
itself
is,
is
secure,
then
you're
pulling
in
a
bunch
of
stuff.
Let's
say
you
pull
in
also
the
dependencies
and
you
can
able
to
take
the
hash
of
those
dependencies
so
like
in
Nix
and
Nix
OS.
They
just
sort
of
do
the
recursive.
F
B
Yeah
I
was
just
gonna
say
you
know.
This
is
exactly
how
the
Sunburst
attack
happened.
Right
so
I
think
I'm
in
agreement
with
with
Mark
that
this
is
the
the
piece
connecting
all
the
different
tracks
together
stores
Bill.
What
what?
What
have
you
I
think
should
be
a
separate
meta
track
for
the
for
the
lack
of
a
better
way.
A
She
can't
speak
up,
but
one
idea
she
brought
up
was
basically
lump
C
into
the
source,
the
future
source
track
that,
like
maybe
something
like
level
one,
is
that
you
know
what
source
repo
is
supposed
to
come
from.
That's
I
think
that's
a
I
had
at
least
I
hadn't
considered
that
I
think.
That's
that's
a
that's
worth
considering
I
think
that's
a
pretty
good
idea.
E
Yeah
I
just
wanted
to
react
to
this
notion
that
you
know
there
is
so
much
dependency
put
on
the
location
which
I'm
not
completely
convinced
is
the
right
thing
and
I
know
it's
kind
of
a
traditional
thing
in
the
security
space.
You
want
to
know
the
original
thing
so
where
it
comes
from,
but
fundamentally
going
back
to
the
the
the
the
scenario
Mike
just
talked
about.
You
know
what,
if
I
go
back
and
it's
not
there
anymore,
I
know
something
is
fishy.
Fundamentally,
that's
not
really
the
that
shouldn't
be
the
criteria.
E
What
matters
is,
has
it
been
modified?
What
you
know
is
it
the
same
thing
that
is
really
what's
important
right
and
so
I
just
wanted
to
hint
on
the
fact-
and
you
know,
Mark
I
I
brought
that
up
before
in
a
different
discussion.
There's
you
know
there
are
different
work
going
on
in
terms
of
identifying.
E
Artifacts,
independently
of
the
location
yeah,
to
provide
an
ID
for
a
piece
of
code
and
and
for
those
who
don't
know,
as
software
Heritage
does
that,
because
they
they
want
to
archive
all
sorts
because
they
can
put
their
hands
on
and
they
can't
afford
to
duplication.
So
it
was,
you
know,
a
matter
of
survival
for
them
to
be
able
to
deduplicate.
E
You
know
copies
of
the
same
code
and
finally,
they
say
well.
We
need
some
identification
of
every
piece
of
code
out
there
with
that.
You
know
carrying
where
it
really
is,
and
so
the
location
is
a
different
attribute.
It's
separate
from
the
identity
of
the
the
code
and
so
I.
You
know
I
just
want
to
every
time
I
hear
people
talk
about
the
location
as
the
key
I
feel
we
are
missing
out
on
something.
A
A
A
Sorry,
but
what
we
I
mean,
what
we
need
to
every
time
you
build
it's
going
to
be
from
a
different
digest,
right
and
I
guess.
The
problem
is
that
we
need
to
know
whether
that
digest
is
okay,
right
and
I.
Think
that
the
fact
that
that
digest
was
located
at
this
particular
git
repo
and
ref
brancher
tag
is
an
indication
that
the
the
people
who
had
Authority
to
kind
of
make
that
determination
to
do
that.
G
F
So
so
one
other
thing,
I
think
I
mean
that's
related
and
I.
Think
it's
something
that
was
one
of
the
core
pieces
of
salsa
I.
Think
that
that
was
that
what
we're
kind
of
at
least
for
the
provenance
piece
right
is
we're
trying
to
say
we're
trying
to
eliminate
the
build
system,
potentially
as
an
attack,
vector
right
where
you
know
something
like
the
build
system
itself
doing
something
nefarious
to
make.
F
You
think
you
downloaded
these
dependencies
when
you
didn't
where,
where
I
think
that's
kind
of
the
thing
there
where,
where,
where
you
know,
there's
nothing
to
prevent
I
think
right
now
from
salsa
to
a
salsa,
build
service
from
downloading
malicious,
Source
or
malicious
dependencies
and
still
building
a
malicious
artifact
right.
It's
just
that
it
helps
with
protecting
against
the
build
system
itself.
Let's
say
GitHub
actions
from
telling
you
it
builds
X
when
it
really
built
y.
H
Ep
yeah,
coming
back
to
the
identity
of
source
code,
I
agree
that
the
digest
identifies
the
bits,
but
what
it
doesn't
answer
is
the
question
is:
are
these
the
bits
that
we
should
be
using
and
that's
Mark's
point?
We
need
to
know
more
than
just
the
identity
of
of
source
code.
We
also
need
to
know
where
it
came
from
or
who
created
it
or
something.
I
Yeah,
so
a
lot
of
this
I
mean
if
we
we
have
a
issue
there,
where
we're
going
to
take
a
look
at
s2c2f
and
then
and
then
salsa
version.
One
I'm
gonna
make
sure
that
there's
proper
alignment,
but
in
doing
that,
I
think
what
gets
accomplished
is
a
lot
of
the
the
a
policy
and
procedural
items
that
should
happen
beforehand.
I
Is
that
are
we
going
to
say
that
that
should
be
one
of
the
requirements
that
that
should
be
built
into
any
organization?
That's
going
to
be
using
open
source
of
third-party
binaries
right.
If
we're
saying
that
and
then
we're
constructing
salsa.
With
these
things
in
mind,
then
I
know
that
those
are
included
and
s2c12,
for
instance,
when
it
comes
to
ingest
ingestion
and
scanning
and
all
that
kind
of
stuff,
so
so
coming
back
into
salsa.
I
There
are
certain
things
like
yes,
location
is
important
from
that
standpoint
right,
our
our
Engineers,
going
out
of
band
to
pull
in
components
like
there's
a
lot
of
ifs,
going
going
on.
There's
a
lot
of
ips
here
that
that
are
creating
a
lot
of
the
arguments
that
that
we're
having
that
what
that
let's
say
arguments
but
the
discussion,
that's
facilitated
right
now,
is
being
facilitated
by
a
lot
of
its
that
we
can
dispel.
I
You
can
dispel
some
of
these
ifs
and
then
create
an
environment
saying
this
is
what
should
be
happening.
Of
course,
we
can
also
say:
well,
we
don't
know
if
that's
happening
or
not,
let's
operate
it
as
if
it
is
or
it
isn't
and
then
construct
it
that
way,
but
I
think
that
creates
a
lot
of
a
lot
of
the
the
confusing
trains
of
thought
as
we
go
as
we
go
through
this
now,
that's
that's.
The
only
commentary
I
have
I
have
with
that.
There.
B
I
propose
something
like
the
source
attestation,
which
we
don't
quite
have
yet
in
indoto,
but
which
might
cover
exactly
use
cases
like
this,
so
you
have
a
source
at
a
station
that
signs
things
like
the
the
commit
tree
digest,
and
then
you
glue
it
with
the
the
verifier
will
put
these
pieces
together
the
sources
at
a
station
and
build
at
the
station
to
see
that
what
went
out
of
source
matches
what
went
into
source.
Does
this
make
sense.
J
J
We
should
be
able
to
have
that
repeatable
process
right
regardless
of
I.
Don't
just
try
to
think
out
loud
here,
like
just
like
we
do
social
securities
or
people
that
come
from
different
countries
and
we
track
them
as
well
right.
But
how
do
we?
How
do
we
just
track
and
as
a
first
phase
as
opposed
to
trying
to
say
yes,
you
know
Gilbert
came
from
I,
don't
know
Mexico
or
Gilbert
is
now
here
in
the
US,
and
just
it's
just
some
some
food
for
thought.
F
There's
also
stuff
that
can
be
done
at
the
source.
Independency
side
to
sort
of
indicate
am
I
pulling
something
that
is
trustworthy,
but
those
two
things
are
somewhat
separate
and
also
involve
a
lot
of
other
things,
and
so
I
just
want
to
make
sure
that
folks
also
recognize
that
that's
kind
of
like
or
do
folks
that
view
it
as
being
different
or
they
view
it
all
sort
of
being
one
and
the
same,
that
like
source
and
dependencies
are
just
as
intertwined
as
as
the
rest
of
the
build
is.
J
I'd
say
in
it'd
be
independent
Mike
because
it's
that's
always
going
to
change.
You
know.
I
can
go,
buy
a
new
car
tomorrow
and
that's
going
to
be
different
from
you
know
what
exists
today
and
but
you
know
what
we
have
a
freeway,
that's
always
repeatable
and
that
I'm
always
going
to
get
on
the
freeway
I'm
always
going
to
get
off
on
off
ramp.
So
I
I
know
I'm
making
analogies
here,
but
there's
always
going
to
be
software.
That's
for
people!
Now,
if
you
get
on
a
freeway,
that's
kind
of
shaky
like.
J
If
you
go
on
a
toll
road
versus
a
non-polar
road,
I,
don't
know
I'm,
just
trying
to
kind
of
get
the
first
phase
would
be.
Can
I
can
I
take
the
sources
and
can
I
build
it
always
the
same
way.
Even
if
the
sources
are
different,
it's
always
going
to
be
built
the
same
way
but
I'm.
Looking
now
at
the
sources
that
are
different,
not
at
that,
and
also
eventually
later
I'll.
Look
at
the
build
as
well
I.
Don't
know
just
okay
I'll
pause
that.
A
A
Let's
say
we
have
a
version
of
it
that
everyone
in
the
world
somehow
magically
agrees.
Yes,
that's
bash
version,
4.4
or
whatever.
If
I
fork
it
and
change
a
file.
Is
that
still
Bash?
Is
that
the
official
Bash
I
think
no,
it's
not
the
official
bash
because
it
has
been
somehow
accepted.
But
how
do
we
record
the
fact
that,
like
it's,
officially
The
Bash
code
or
not
and
like
what
it's
supposed
to
be?
A
That's
I,
guess
I
think
that's
almost
like
an
abstract
concept
and
we
have
approximations
of
that
like
one
is.
It
can
be
found
at
this
particular
locator,
and
that
is
a
sign
that
it's
official,
although
there's
ways
to
get
together,
another
could
be
it
is
signed
by
this
particular
identity,
public
key,
for
example.
That
is
another
approximation
that
it's
official
but
again
the
signing
Cube
could
be
used
or
something
like
that.
F
Yeah
go
ahead,
yeah
and
I.
Think
one
other
thing
to
you
know:
I
I
think
that
I
I
also
don't
want
to
open
back
up
the
transitive
problem
either,
because
then
that
becomes
a
thing
of
how
far
along
does
that
go
right,
because
you
can
very
easily
say
well,
like
you
know,
just
as
an
example,
you
know
dead.
Ian
has
some
patches
for
a
thing,
so
it's
really
not
the
the
normal
Source.
F
It's
it's
some
additional
things
here
that
that
that
that
change,
some
of
it
as
as
well-
and
it
also
opens
up
right
like
it-
also
uses
a
library-
that's
not
the
normal
Library.
That's
normally
used
as
a
dependency,
for
you
know
some
other
build
of
that
same
software,
which
I
think
kind
of
you
know
complicates
some
of
it,
which
is
like
I,
think
I.
F
K
A
I'm
not
sure
I
followed.
Let
me
try
to
repeat
it
to
see,
but
I
suspect
I
got
it
wrong.
Are
you
saying
that,
like
foreign,
the
consumer
thinks
that
they
got
it
from
some
location,
I'm,
pretty
sure
I'm
getting
this
wrong,
but
I'm
going
to
say
what
it's
probably
wrong,
that
they're
getting
from
a
location
and
so
to
them?
That
makes
it
official.
Is
that
what
you're
saying
well.
K
D
D
F
So
I
do
think
that
it's
probably
worthwhile
to
Think
Through
a
little
bit,
maybe
then
I
so
so,
if
we're
assuming
right
now
at
least
source
and
dependencies
are
sort
of
a
separate
thing
from
the
actual
build.
Do
you
view
that?
Do
we
view
that
now
as
something
like
a
high
level?
Let's,
let's
just
assume
you
know,
salsa
2.0
for
a
second
like
not
saying
you
know,
for
getting
there
anytime
soon,
but
like
something
like
salsa,
you
know
in
the
future.
F
You
would
expect
something
like
a
salsa
compliant
build
system
to
take
in
as
its
input
at
a
high.
Like
you
know,
a
higher
salsa
level,
a
high
salsa
build
level
should
take
in
stuff
that
has
been,
you
know,
salsa
Source
levels
or
something
like
that
or
social
dependency
levels,
and
so
that
would
the
interface
there
would
be
something
like
salsa
level,
one.
Let's
just
say,
for
the
sake
of
argument.
F
A
Yeah
the
implications
of
time
together,
I
guess
how
I've
been
thinking
of
that
like
thinking
on
all
this
idea
would
be
like
effectively
right
now
in
this
release
candidate.
We
say
you
have
to
compare
to
like
the
parameters
to
expect
expectations
like
that
would
be
maybe
like
a
source
level,
one
at
the
inputs
to
the
build,
meet
some
expectations
and
there's
maybe
different
ways.
You
could
do
that
you
could
just
come,
make
sure
that
it
hasn't
been
changed
from
the
previous
version.
You
can
match
it
to
some
expected,
like
locator,
you
could
match
against.
D
A
A
So
I'm
trying
to
think
like
how
would
like
be
like
iterate
on
this
idea
if
we
made
the
what's
currently
called
threat,
C
in
the
diagram
here,
let
me
present
this
again
into
Source
level
so,
like
basically,
the
build
level
would
kind
of
cover
these
threats.
Dfgh,
The,
Source
level
cover
ABC,
but
really
level,
one
or
or
the
first
level
only
covers
threat,
C
and
doesn't
say
anything
about
tampering
of
the
source.
F
Yeah
I
I
think
that
yeah
I
think
that
sort
of
depends
on
how
deep
you
want
to
go
right
because-
and
this
is
something
that
I
think
Isaac
Isaac
hepworth's
diagram
shows
pretty
clearly
and
some
of
the
other
stuff
that
I
know
with
like
Google's,
Beyond
Corp
and
some
of
the
other
stuff.
That's
coming
out.
Also
sort
of
think
highlights
right
where
you
know
you
can
go
as
deep
as
you
want
to
go
right
where
you
can
have
say:
hey
actually
developers
never
run
Dev
on
their
own
workstations.
F
It
should
be
an
approved.
You
know
remote,
isolated
Ides.
You
know
whether
it's
Eclipse
J
remote
vs
code.
You
know
that
I
know
Google
has
a
bunch
of
their
internal
stuff
and
and
so
on.
Like
does
it,
you
know
we
can
go
as
deep
as
we
want
to
on
there,
but
I
think
to
start
off
with
at
least
I.
Definitely
think
that
step
C
piece
is
is
important
and
we
just
should
just
say
you
know
we
we
might
say
right
like
I,
can
imagine
it
going
step.
F
Two
hits
like
just
is
it
coming
from
a
trusted
party
and
then
I
could
see
something
like
step
2.5
becoming
something
like
the
expectation
from
that
trusted
party
is
for
Source.
It
has
gone
through
a
trusted.
You
know
linting
procedure
or
two-person
code
review,
and
you
know,
and
some
additional
things
there
right.
F
Some
of
it
is
going
to
be
easy
to
hit
from
an
attestation
and
verify
the
an
attestation
just
based
on
well,
actually,
even
some
of
that's
not
quite
you
couldn't
quite
do
that
because
of
yeah
anyway,
I
think
doing
something
like
yeah.
The
expectation
is
you
have
two-person
code
review
and
that
two-person
code
review
is
trustworthy,
not
just
like
two
random
service
accounts
on
the
same
thing
can
just
approve
whatever
and
then
over
time
right
that
can
turn
into
other
stuff
as
well.
K
A
That's
a
good
question:
I,
don't
know,
I
I
would
I
would
guess,
like
I'd,
be
really
hesitant
to
call
something
a
level
in
the
1.0
like
the
efficient
in
the
middle
level.
Maybe
how
we
organize
it
like
that.
We
take
what
we
already
have,
but
just
lump
it
together
and
say:
we'd
have
to
see
how
it
looks
and
and
but
maybe
we
could
start
kind
of
doing.
The
conversation
like
that
of
like
this
is
in
the
source
track.
A
We
don't
yet
have
levels
to
find,
but
here
is
something
that
we
think
should
be
part
of
it
and
then
in
the
future
release
we
actually
start
to
define
the
levels.
I
think
that's!
My
guess
is
like
that's
the
most
that
we
would
do
because,
like
we
just
haven't
had
enough,
you
know
like
if
we
want
to
have
a
release
within
a
month.
F
Yeah
actually
yeah
before
I,
get
to
my
other
point.
I
actually
really
agree
with
what
martial
said.
There
I
think
it's
really
yeah
I
think.
That's
also
another
reason
why
you
keep
it
separate,
because
you
could
still
have
yeah
I,
think
the
the
it
helps
sort
of
determine
which
of
the
the
areas
is
the
the
area
where
the
the
attack
is
most
likely
to
happen
right.
F
F
The
second
thing,
I
think
is
also
when
it
comes
to
the
source.
Stuff.
I
do
agree
that
maybe
we
weighed
off
a
little
bit
because
I
think
there's
a
lot
of
stuff
and
there's
a
lot
of
work
happening
like
you
know,
sent
a
link
for
the
stuff
that
he's
looking
at
with
the
in
total
attestation
regarding
Source
attestations,
there's
a
few
other
attestation
types
that
are
being
sort
of
built
that
are
doing
similar
sorts
of
things.
There's
git
sign.
F
G
It
sounds
kind
of
like,
if
you
have
a
bunch
of
you,
have
literally
tons
of
dependencies
that
go
into
a
build
and
it
takes
forever
to
download
npm
anyway
on
your
machine
right.
Sometimes
it
can
be
gigabytes
and
gigabytes,
and
only
some
of
it
is
used.
Would
we
require
someone,
a
consumer
who
wants
to
verify
to
to
download
all
the
dependencies
and
hash
them
on
their
own
machine?
A
Yeah
yeah
I
feel
like
that
should
be
in
the
principle,
because
we
have
these
like
guiding
principles
section
if
it's
not
already
I,
don't
know
if
it
is
I
feel
like
that,
should
be
part
of
the
guiding
principles
that,
like
you,
can
verify
things
without
having
to
download
it
all,
and
do
it
all
yourself.
That's
like
kind
of
the
the
concept.
G
A
A
Yeah
that
would
be
good
to
reference
here,
yeah
that
all
that
sounds
like
a
separate
conversation
to
me,
but
one
that
we
ought
to
be
having
as
well
I,
think
like
in
my
inclination,
would
be
to
split
like
the
source
which
would
be
the
in
in
the
provenance.
Is
the
external
parameters
from
the
resolved
dependencies
just
because
they're
both
difficult?
A
A
Okay,
well,
as
always,
it
was
a
pleasure
talking
to
you
all
and
I
look
forward
to
getting
out
of
1.0
a
stable
release
and
we'll
just
kind
of
continue
iterating
on
the
the
1.0
polishing
it
addressing
kind
of
the
the
next
level
of
priority
items
and
then
hopefully,
release
by
the
end
of
the
month.
So
thanks
everyone
and
I'll
talk
to
you
soon.