►
B
D
B
C
C
C
C
F
E
Okay,
cool
yeah.
I
think
I
think
I
have
this
working,
but
if,
like
the
slides,
don't
move
or
something
somebody
please
like
shout,
okay,
so
yeah,
I
guess
I
also.
I
should
raise
my
hand
as
a
new
person
here.
I've
not
been
to
this
meeting
before
and
I
very
much
appreciate
being
invited
to
talk
to
y'all.
Today,
I'm
bobby
holly,
I'm
a
distinguished
engineer
at
mozilla,
and
I
guess
something
about
me.
E
So
this
tool
is
running
in
production
for
firefox.
Today,
however,
we
haven't
really
done
like
a
general
release
yet,
and
I
would
say,
strictly
speaking,
we
haven't
even
really
announced
it,
but
nevertheless,
like
people
lurk
on
our
email
lists
and
word
spreads.
We've
already
got
a
fair
amount
of
inbound
interest,
which
I
generally
take
is
a
good
sign
that
we're
on
the
right
track.
E
Our
near-term
objective
with
this
is
to
secure
firefox,
but
our
long-term
objective
is
to
secure
the
ecosystem,
and
so
it's
very
important
to
us
that
we
build
the
tool
that
people
actually
like
and
want
to
use,
and
it's
especially
important
given
the
design
of
cargo
vets,
because
the
dual
has
very
strong
has
network
effects
so
the
more
people
that
use
it,
the
less
work
that
anybody
has
to
do
so
did
the
slide
transition
there,
yeah,
okay,
so
yeah.
So
why
are
we
doing
this?
E
Firefox
has,
of
course
you
know
been
around
since
long
before.
Rust
was
the
thing
and
has
always
had
its
share
of
third-party
c
plus
plus
code,
but
it
was
never
really
all
that
much
because
there
was
just
like
a
ton
of
friction
involved
in
pulling
something
in
like
you
had
to
have
lots
of
discussions,
and
maybe
you
had
to
talk
to
a
lawyer
and
then
maybe
had
to
figure
out
the
build
system,
integration
and,
like
all
that
kind
of
stuff,
and
so
as
a
consequence.
E
But
of
course,
it
may
be
the
case
that
the
developer
needs
to
audit
the
code
themselves
and
that
can
take
some
work.
But
cargo
vet
streamlines
the
process
of
auditing
to
make
it
as
easy
as
possible.
So
often,
somebody
will
have
already
audited
a
different
version
of
the
same
crate,
in
which
case
cargo
vet
computes
the
relevant
diffs
and
identifies
the
smallest
one
for
you
to
review
and
then,
regardless
of
whether
you're
auditing,
a
diff
or
the
full
crate.
It
helps
you
pull
up
the
goods
for
inspection
and
record
the
results.
E
So
another
thing
that
cargo
vet
does
to
minimize
friction
is
to
store
the
audit's
entry,
and
this
means
the
developers
don't
have
to
navigate
or
even
authenticate
with
any
sort
of
external
system
like
they
already
have
a
change
set.
That's
adding
the
new
third-party
code,
and
with
this
they
can
just
submit
the
relevant
audits
directly
as
part
of
that
change
set
and,
of
course,
as
mentioned
before,
cargo
vet
has
these
sharing
and
discovery
features.
E
But
these
affordances
are
built
on
top
of
that
system
and
they
do
that
by
pointing
to
the
audit
files
in
the
repositories
of
the
other
organizations.
So
this
also
means
that
there's
no
central
infrastructure
for
any
kind
of
attacker
to
compromise.
The
only
way
that
you
can
spoof
an
audit
from
mozilla
is
to
compromise
the
firefox
repository
itself,
and
I
can
assure
you
that
you
know
we
have
lots
of
people
who
make
sure
that
that
doesn't
happen.
E
E
You
know
just
sort
of
does
what
you
expect
so
yeah,
I
would
say:
that's
the
high
level.
I
was
told
that
I
only
had
maybe
like
15
minutes
total
for
the
presentation.
Q
a
so
I
didn't
go
into
too
much
more
detail
than
that.
But
obviously,
questions
are
welcome,
happy
to
elaborate
on
any
of
the
aspects
of
motivation
or
the
design.
You
know
you
know
at
this
point
and
of
course,
we'd
love.
E
A
A
B
A
E
I
mean,
generally
speaking,
you
probably
want
it.
The
audit
needs
if
you're
using
cargo
vet
as
like
a
linter,
and
that
lender
is
getting
check-in.
Then
the
audit
needs
to
be
part
of
the
store
before
the
commit
lands.
So
it
could
be
a
follow-up
commit
you.
Could
you
could
certainly
record
the
audit
ahead
of
time?
You
know
even
in
its
own
push,
there's
no
there's
no
restriction
on.
E
You
know:
recording
audits
that
aren't
strictly
necessary
yet,
but
the
basic
workflow
of
how
it
works
is
you
know
the
developers
there
they're
trying
to
do
the
push,
and
that
says
like
oh,
like
as
when
you're
running
your
linters,
either
locally
or
you
know,
on
ci,
it
will
say:
cargo
vet
failed
and
you
type
like
okay
cargo
vet,
and
then
it
tells
you
well.
This
is
you
know
this
dependency
is
missing
an
audit
and
then
right
there.
It
provides
you
like
a
command.
E
And
then,
when
you're
done
with
that,
you
type
cargo
vet
certify.
And
then
it
will
remember
what
you
had
just
inspected
and
provide
you
sort
of.
You
know
the
a
textual
description
of
the
you
know
the
stuff
you're
supposed
to
be
auditing
for-
and
this
is
kind
of
like
in
a
it's
kind
of
like
a
git,
commit
thing
where
it
opens
up
an
editor.
E
A
I
don't
want
to
monopolize
question
time,
but
I
will
ask
or
make
one
more
before
I
get
off
the
queue
and
wait
to
come
back
in
later.
One
thing
we've
talked
about
in
this
group
before
is
the
idea
that
six
store
should
record
for
sig
store,
should
record
far
more
than
just
signatures
right,
where
signatures
are
really
an
attestation
of
authorship
or
committership,
but
we
also
want
to
see
events
committed
to
the
transparency
log
like
this
dependency
was
pushed,
but
also
this
dependency
was
inspected
by
person
x
and
they
said
opinion
y.
A
E
E
E
A
E
E
F
E
Right
and
there's
also
there's
also
a
github
repository,
which
I
think
is
linked
to
somewhere
in
the
book,
but
it's
the
mozilla
github
repositories,
slash
cargo,
vets
and
so
that's
sort
of
where
the
the
code
is
happening.
Right
now,
I
will
say
that
we
have
intentionally
there's
a
there's:
a
dummy
hello
world
crate
under
cargo
vet
right
now,
that's
published
to
crates.io
and
we
specifically
have
like
avoided
publishing
one
just
because
you
know
we're.
E
We've
got
a
couple:
people
that
are
just
kind
of
like
iterating
on
the
features
and
making
sure
like
you
know
it
handles
all
the
edge
cases
and
that
sort
of
stuff
anybody
that's
using
it
right.
Now
we
kind
of
want
to
be
like
really
in
the
loop
and
filing
issues,
but
probably
like
in
maybe
two
weeks
or
something
we'll
do
a
general
release.
F
E
Yeah-
and
I
would
also
say
that
you
know
the
thing
about
the
cargo
vet
system-
is
that
the
basic
flywheel
is
you
know
designed
to
be.
You
know,
projects
that
are
trying
to
sort
of
manage
their
own
dependencies
and
you
know
in
the
process
of
managing
their
dependencies,
they're,
auditing
them
and
then
they're
sort
of
sharing
that
work.
That
they've
already
done,
however,
there's
totally
space
in
the
system
for
an
entity,
that's
simply
like
whose
job
it
is
to
like
just
audit
stuff
right
so
like.
E
Even
if
you
didn't
you
know,
if
you
wanted
to
go
and
audit,
you
know
the
top
100
crates
on
crates.io,
and
then
you
were
a
well-known
entity
that
people
trusted
and
you
published
an
audits.tamil
for
that.
Then
everybody
could
go
and
pull
that
in.
Even
if
you
weren't,
strictly
speaking,
using
those
dependencies
yourself.
F
G
No,
no!
No!
No!
No,
I
I
see
sort
of
decentralized
dimension
in
terms
of
like
the
individual
organizational
repositories
would
have
audits
of
adventures
that
they've
done,
but
there's
a
registry
area.
I
I
was
a
little
unclear
about
how
that
registry
works.
How
could
I
find
an
audit
that
organization
has
done.
E
E
I
think
we're
just
gonna,
restoring
it
in
the
cargo
that,
like
source
repository
itself,
but
it's
a
list
that
cargo
that
fetches,
that
just
maps
like
entity
names
to
the
url
of
their
audit
files
right
so
there's
it
doesn't
actually
contain
any
audits
themselves.
It's
just
a
directory
service.
But
what
that
means
is
that
when
cargo
vet
is
like
trying
to
run
it's
like.
Oh,
like
I
don't
have
an
audit
for
version
1.3
of
foo.
E
It
can
just
check
the
registry
and
it
can
go
just
fetch
all
of
those
audits
from
the
organizations
whether
you
trust
them
or
not,
because
it's
not
you
know
pulling
them
in
as
part
of
your
trusted
set
it's
just
sort
of
looking
around
and
then,
if
it
finds
one,
then
it
can
say.
Oh,
hey,
look
like.
Google
has
already
audited
foo
version,
1.3.
or
point
three.
G
E
Sorry
I
mean
it
would
just
be
a
name
and
then
the
ur,
like
you
know
you
know
your
organization
and
the
url
of
your
auditing
of
your
audits
file
and
then
cargo
vet.
Would
then
you
know
when
somebody's
cargo
event
failed,
it
would
go
and
just
fetch
everything
from
the
directory
and
then
if
it
noticed
that
your
organization
has
actually
audited
the
thing
that
was
needed
or
something
that
was
perhaps
very
close
to
what
was
needed.
E
And
then
you
could
just
like
audit
a
little
diff
on
top
of
that,
then
it
would,
you
know,
inform
you
and
then,
depending
on
like
the
organ,
you
know
how
big
the
organization
is
like,
I
would
say
in
mozilla's
case,
you
know
if
some
developer
ran
into
this
issue
and
then
it
was
like.
Oh
like
I
want
to
go,
pull
in
like
open
ssfs,
like
audits,
individual
developers
wouldn't
have
the
authority
to
you
know
add
an
entity
to
the
trusted
list,
or
rather
they
could
add
it.
C
I
think
it
might
be
me,
I
think
the
question
kind
of
was
addressed
by
jason's
question
before
and
I
apologize
because
my
laptop
decided
it
needed
to
restart
immediately
after
you
started
talking.
So
you
might
have
said
this,
but
I
guess
maybe
you
could
just
sort
of
summarize
what
you're
imagining
the
like.
C
You
know
it
seems
like
this
is
mostly
team
focused
for
now,
but
the
like
the
upstream
model
for
like
how
there'll
be
a
shared
vet
amongst
a
community
of
of
resources
there,
and
I
think
you
kind
of
described
it
like
if
you
have
trust
in
some
organization's
project
you
adopt
their
their
vet.
Is
that
sort
of
the
idea.
E
Yeah,
the
basic
idea
is,
you
know,
different
organizations
like
wellness
organizations,
you
know
like
mozilla
is
you
know,
we've
got
our
audits
file
up
there
already.
You
know
the
bytecode
alliance
is
going
to
be
doing
one
with
wasm
time
shortly.
I've
had
a
number
of
back
general
organizational
conversations
with
wellness
organizations
that
are
potentially
interested
in
doing
this
as
well,
and
so
the
idea
is
that
you
know
organizations
are
producing
their
own
audits
and
they
can
choose
or
not
choose
to.
C
Sure,
okay,
cool
so
kind
of
a
follow-up
question
there,
since
this
group
is
sort
of
like
broadly
focused
across
lots
of
different
ecosystems,
the
the
model
of
then
mechanics
and
maybe
like
this
format
for
the
policy
file
and
the
audit
or
whatever
it
might
be
like
how
tied
to
the
rust
ecosystem
is
that
or
how?
How
much
could
it
extend
into
other
ecosystems?
Do
you
think.
E
E
You
know
just
to
make
the
ergonomics
better
for
people
and,
as
we
figure
out
how
it
scales
and
then
I
think,
if
we
can
get
this
thing
working
in
rust
and
we
can
really
demonstrate
yeah
like
a
very
wide
community
of
stakeholders.
Like
is
interested
in
using
this
and
getting
value
out
of
it,
then
I
think
that
would
be
a
useful
proof
point
to
then
go
and
look
at
one
of
these
other
language,
ecosystems
and
then
say
based
on
what
we
learned
and
how
cargo
vet
worked.
B
C
B
E
So
the
basic
trust
model
is,
I
mean
fundamentally
I
mean
it's
the
it's.
The
domain
trust
model
right
of
of,
like
you
know,
who
controls
the
files
on
the
domain,
but
the
you
know
the
the
thing
that
you
import
is
a
is
a
url,
and
so
it
would
depend
a
little
bit
of
like
whether
google
decided
to
publish
you
know
separate
audit
files,
for
you
know,
team,
x
and
team
y
or
whether
they
wanted
to
publish
a
consolidated
google
audit
file.
E
E
You
know
smaller
projects
like
including
cargo
vet
itself.
You
know
in
the
mozilla
github
repository
and
the
question
of,
like
you
know,
how
much
do
we
combine
these
or
you
know,
do
people
you
know
have
separate
imports,
for
these,
you
know
is
something
we
have
to
figure
out,
but
I
would
lean
towards
you
know
the
the
high
level
like
you
know
this.
This
carries
mozilla's
stamp
of
approval.
I
think
that's
kind
of
the
the
most
understandable
granularity.
E
There's
a
directive
for
the
audit,
where
you
know
the
normal
thing
you
do
when
you
audit
is,
you
say
like
this
looks
good,
but
you
can
also
say
like
no,
this
is
a
violation.
Audits
are
defined
in
terms
of
criteria
right,
so
this,
like
you,
know,
you're
auditing,
for
a
given
set
of
criteria
and
there's
there's
some
built-in
criteria
and
if
you
say
like
no,
this
crate
actually
violates
those
criteria.
E
You
can
mark
that
and
then
that
will
just
like
prevent
the
thing
from
from
being
allowed
on
anything
that's
pulling
in
those
imports
and
the
reason
we
have
this
like
exclusion
thing
that
I
mentioned
just
a
minute
ago.
Is
you
know
in
case,
like
two
organizations
get
into
some
like
fundamental
disagreement
of
like
well,
this
is
unsound
but
like
well.
It's
like.
We
think
it's
like
totally
fine.
You
know
or
something
like
that.
E
G
Yeah,
it's
kind
of
it's
kind
of
a
follow-on.
Maybe
you've
answered
this
partly,
but
when
you
introduce
the
term
audit,
that's
usually
very
loaded,
it
implies
that
there's
a
standard
with
a
framework,
a
set
of
controls
with
checklists
certifications
for
people
followed
up.
You
know
certain
steps
they
have
to
follow,
control,
lists
and
things
like
that
ways
of
recording
your
audit
results
and-
and
things
like
that,
I
mean
it.
G
You
see,
it
seems
like
this
trust
change,
trusting
an
org
that
at
that
level,
granularity
is
not
enough
that
there
has
to
be
some
rigor
behind
it
and
such
frameworks
and
controls
to
ensure
that
audits
are
performed
uniformly
across
different
orbs
or
at
least
an
attempt
to
do
those
things.
Have
these
things
been
discussed
at
all.
E
Yeah,
so
I
will
say
you
know,
as
part
of
the
system
like
I
mentioned
before,
like
audits
are
defined
relative
to
criteria
I
didn't
get
into
into
the
talk,
because
it's
you
know
it's,
it's
perhaps
a
level
of
detail
more
than
I
could
fit
in
10
minutes.
But
yes,
there
are.
There
are
some
built-in
audit
criteria,
which
you
know
have
specific
text
of
like
what
is
what
you
should
look
for
and
what
is
allowed.
E
These
are,
and
I
think
they're
specified
in
the
book
and
also
showed
to
you
on
the
command
line
when
you're
doing
this,
but
the
built-in
ones
are
safe
to
run
and
safe
to
deploy.
The
main
difference
is
that
safe
to
run
is
that
this
thing
is
not
actively
going
to.
You
know:
compromise
you
on
its
own
and
safe
to
deploy.
Is
this
thing
is
hardened
against
untrusted
inputs
and
therefore
like,
even
if
it's
exposed
inputs
in
the
wild,
it
will
also
not
compromise.
You
is.
E
Not
at
that
level
granularity,
no,
so
the
way
it
basically
works
is
that,
like
you
know,
I
can
say
you
know
in
firefox,
you
know
we
have.
The
audits
are
well
all
of
cargobed's
metadata
is
stored
in
a
directory.
The
default
directory
is
the
top-level
supply
chain
directory,
and-
and
so
we
have
a
specific
governance
module
that
governs
that
and
whenever
somebody
submits
something
to
that,
we
look
at
it
and
we
perhaps
go
and
talk
to
the
person
like
depending
on
you
know.
E
Our
level
of
you
know
like
whether
this
is
a
very
senior
engineer
that
we
have
a
huge
amount
of
confidence
in
versus
like
a
relatively
junior
person.
Certainly
if
it's
an
external
contributor,
you
know
that
that
might
be
something
we
just
wouldn't
accept,
but
so
we
have
some
degree
of
governance
processes
like
around
what
audits
go
in
and
get
the
mozilla
seal
of
approval,
but
there
is
not
an
attempt
to
standardize
what
the
seal
of
approval
means
across
organizations.
I
don't
think
that
that
is
particularly
tractable,
but.
G
You're
implying
that
that
there
are
people
involved,
so
it
would
still
require
some
level
of
recording
of
signatures
and
things
like
that
right
signatures,
signatures
of
the
people
you
approved
to
perform
the
audits.
You
know
I
perform
this
audit
and
I'm
and
I'm
submitting
this
audit
or
these
people
contributed
to
the
audit
right.
So
it's
like
the
trust
chain.
You
know
it
goes
back
to
org
level
back
to
you.
Basically,
you
rely
back
to
individuals
to
go
back
to
individuals.
G
E
Yeah,
but
the
way
that
the
identities
are
managed
is,
by
the
same
way
that
identities
are
managed
in
our
existing
code
development
processes.
Right,
like
people
have
you
know,
people
have
authenticated
with
our
code
repository
that
allows
them
to.
You
know,
submit
code
to
it,
and
certainly
that
also
allows
them
to
do
reviews.
So
when
people,
when
somebody
submits
an
audit
or
you
know,
submits
a
patch
that
you
know
adds
an
audit
to
the
tamil
file,
we
know
who
they
are,
and
so
it
goes.
E
A
A
Yeah,
so
I
think
matt
is
thinking
in
terms
of
like
what
we
talk
about.
A
lot
is
attestations,
which
is
some
statement
of
fact
with
an
attached
signature
that
has
an
identity
like
some
proof,
something
can
be
proved
that
the
attestation
was
created
by
person
x
or
by
identified
workload
x
in
some
cases.
A
E
C
A
E
Yes,
I
or
well,
I
think
that
the
the
baseline
design
of
cargo
vets
is
to
rely
on
the
repository
right
that
this
repository
is
the
thing
that
the
organization
is
putting
forward
as
something
that
it
is
standing
behind.
You
know
that
this
is
you
know,
whatever
the
the
the
by
code
alliance,
github
organization,
there's
the
wasm
time
repository.
That
is
the
thing
that
people
are
pulling
releases
from
and
sort
of,
implicitly
trusting
whenever
anybody's
using
code
from
them,
and
so
that
that
is
sort
of
that
is
the
attestation
point.
E
A
Okay,
so
I
think
there's
a
there's
a
further
conversation
we
can
have.
I
don't
know
whether,
today
or
or
it's
on
on
the
slack
about
what
kinds
of
method
of
attestation
people
want.
So,
for
example,
you
know
at
the
moment
we
have
a
tool
called
git
sign
which
creates
a
digital
signature
that
is
written
also
to
a
transparency
log.
So
there's
a
very
strong
public
record
that
person
x
was
responsible
for
commit
y
that
doesn't
rely
on
the
commit
itself,
but
I
won't
go
into
that
too
much.
E
E
Okay,
specifically
because
it
is
a
concern
about
like
friction
and
then
making
it
much
more
difficult
for
developers
to
participate
in
the
system,
because
you
know
if
I'm
a
mozilla
developer
and
I'm
just
like
you
know,
working
on
firefox
code,
I'm
landing
firefox
code,
all
the
time.
I
have
my
little
workflow
on
that
and
if
suddenly,
I'm
in
the
thing
where
I
have
to
you
know
create
like
a
new
public
identity
or
get
a
you
know,
figure
out
a
public
key
or
all
that
kind
of
stuff.
A
E
A
E
Yeah
and
that's
that's
something,
yes
again,
something
we've
we're
very
excited
about
as
a
possibility.
I
think
you
know
the
first
mvp
of
this
I
mean
is
getting
to
the
point
where
you
can
import
most
popular
crates
on
crates.I
o
and
at
least
one
entity
will
have.
You
know
signed
off
on
that
which
is
a
strict
improvement
over
what
we
have
today
and
then
once
we
do
that,
then
we
can
start
adding
the
redundancy
in
of
having
multiple
entities.
E
A
Because
I
imagine
I
I
mean
extending
on
this-
I
imagine
there'll
be
like
a
lot
of
out
of
band
arrangements.
This
is
this
is
also
slightly
touching
on
what
matt's
asking
about
auditing,
I
think,
like
the
definition
of
voting
in
some
sense
is
not
technologically
described
it's
it's
out
of
band
agreements
between
different
parties
that
they
will
recognize
each
other's
audits,
because
they've
agreed
to
some
some
approach.
So
I
had
a
question
is
there's
a
terminology?
We
use
a
lot
when
we're
talking
about
attestations,
which
is
predicate.
E
Yes,
so
the
there
is
only
one
verb
which
is
audited
in
accordance
with
the
associated
criteria
here,
but
audit
records
specify
what
the
criteria
are,
and
so,
if
you,
you
know,
I
would
say,
I
would
say,
probably
like
the
the
default
here-
is
security
audit
and,
like
I
sort
of
described
before,
there's
those
two
levels
of
security.
Audit
of
you
know
like
actively
malicious
versus
hardened
against
interested
input,
and
but
you
can
certainly
there's
affordances
for
specifying
your
own
criteria
and
for
mapping
those
custom
criteria
across
different
projects.
E
B
E
A
Yeah
you're
taking
me
back
yeah,
I
I
guess
in
the
long
run,
I'd
hope
that
this
group
can
help
to
suss
out
some
common
terminology
or
common
taxonomy,
because
one
of
my
goals
in
participating
in
this
group
is
that
my
peers
in
abstech
and
infrasec
should
not
need
to
run
multiple
monitors
to
deal
with
different
ecosystems.
They
should
run
one
monitor
that
has
a
common,
a
common
language
to
the
degree
it's
possible.
The
last
one
question
I
had
was
about
private
auditability.
Like
can.
E
You
know
you
point
to
github
slash,
buy
code
alliance,
you
point
to
ht.mozilla.org
mozilla
central
and
you
you
that's
where
you
find
the
audit
file,
it's
just
you're,
pulling
it
out
of
the
source
tree
and
nobody
has
to
do
any
extra
work
to
publish
it.
Obviously,
if
you
have
some
sort
of
private
project
that
doesn't
work,
and
so
what
you
would
do,
then
is
you
would
have
a
mechanism
by
which
you,
you
know,
pull
the
audit
file.
E
You
know
you
pull
out
you
sync,
the
audit
file
out
of
that
private
repository
into
some
known
public
location
that
you
then
add
to
the
registry.
There
is
there's
an
additional
affordance
which
again
was
a
detail.
I
didn't
get
into
of
handling
multi-repository
organizations
that
want
to
consolidate
them.
E
You
know,
microsoft
or
meta,
or
something
like
that,
and
I
know
that
these
organizations
have
a
whole
bunch
of
different,
like
repos,
a
whole
bunch
of
different
software
repositories
under
the
roof,
and
it
is
not
a
particular
you
know
it
may
not
be
a
detail
that
I'm
interested
in
of
you
know
exactly
which
one
it
is,
and
so
that's
what
that
aggregation
affordance
is
but
yeah,
generally
speaking,
oh
go
ahead.
Sorry.
A
I
I
I
don't
know
if
I
heard
what
I
was
trying
to
try
to
do
for
and
joseph
I
promise
this
is
the
last
interruption
I'll
have
which,
which
was,
if
I'm,
if
I'm
meta,
I
might
want
to
reveal
some
of
my
audits,
but
I
might
not
want
to
be
revealing
all
of
my
audits
because
I
don't
want
to
signal
to
potential
attackers
what
dependencies
I
have
you
know.
Different
different
companies
have
different
levels
of
paranoia
around
this.
A
You
know
we've
had
informal
discussions
with
other
companies
about
doing
like
this
general
idea
for
ruby
and
it
has
come.
One
of
the
sticking
points
has
been
some
of
our
peers
are
like.
We
don't
want
to
publish,
we
don't
want
to
publish
what
dependencies
we
have.
We
do
want
to
do
audits
and
we
want
a
recording
mechanism
for
it,
but
we
don't
have
to
share
that
publicly.
E
Right,
and
so
I
guess
what
I'm
saying
is
that,
assuming,
if
you're
in
a
world,
if
you
have
some
project
as
a
company,
that
you
don't
want
people
to
know
what
the
dependencies
are,
I
would
assume
that
that
project
is
not
open
source
right,
because
if
it
was
open
source,
then
somebody
could
just
look
at
this
or
you
know
if
it
was
public.
Somebody
could
just
go.
Look.
E
B
Sorry,
I
think
actually,
meanwhile,
all
my
questions
were
answered,
but
actually
maybe
let
me
summarize-
if
I
understand
this
too
well
so
currently,
it's
just
a
tumblr
file
with
audits,
right
and
there's
cli
tool
around
this
file,
which
you
can
manipulate
with
the
predefined
structure
and
also
the
cli
tool,
is
capable
of
helping
you
doing
the
audit.
So
it
can
actually
show
you
the
differentiations
between
two
cargo
versions
of
crates
right.
B
So
in
the
end,
it's
totally
non-invasive
right,
because
how
do
you
version
that
file?
How
people
are
changing?
That
file
depends
on
your
approach,
just
nothing
actually
around.
It
really
depends
it's
the
same
as
your
oh,
it
can
follow
the
rest
of
the
project
and
how
do
you?
How
do
you
version
your
code
right.
E
Exactly
yeah
yeah,
that's
that's
really.
The
idea
is
that
we
want
this
to
not
take
headspace
from
people
right,
because
it's
going
to
be
something
you
know
mozilla,
we
have
hundreds
of
developers
that
work
on
firefox,
and
you
know
to
make
this
a
not
very
to
make
this
a
very
a
sort
of
cheap
investment
for
us
to
make
we
the
easiest
way
to
do.
That
is
to
avoid
adding
like
two
hours
of
friction,
the
first
time
like
each
of
those
developers
like
bumps
into
this
thing
and
has
to
figure
it
out
right.
B
E
Yeah,
I
will
also
just
say
that
there's
the
audits
file
and
then
there's
also
a
separate
config
file
that
allows
you
to
do
things
like
specifying
different
policies
for
parts
of
your
subtree
and
that's
also
where
your
list
of
exemptions
is
stored.
But
the
basic
idea
is:
there's
conceptually.
There's
sort
of
two
files,
like
the
audits
file,
is
the
thing
that's
shared
with
the
ecosystem,
and
then
the
config
file
is
the
thing.
G
E
C
Cool
bobby,
thank
you
so
much
for
coming
and
talking
to
us.
I
think
everyone
is
super
interested
in
the
topic
and
we'll
be
excited
to
see
where
cargo
that
goes
and
maybe
how
we
can
sort
of
generalize
it
across
some
other
ecosystems,
because
I
think,
there's
definitely
a
demand
there.
So
yeah
thanks
again
super
cool
project.
Please,
please
keep
in
touch
with
us.
I
see
you're
in
the
slack
but
like
let
us
know
as
things
progress
or
has
things
changed,
definitely
clue
us
in.
E
You
know
who
are
using
rust
and
would
be
interested
in
using
this
sort
of
concretely
to
secure
the
rest
supply
chain,
but
if
you
all
are
familiar
with
any
other
companies,
your
companies
or
ones
that
you
work
with,
or
organizations
or
projects
for
which
this
might
be
a
good
fit,
definitely
reach
out.
And
let's
talk
about
the
use
case,
because
you
know
the
more
organizations
that
use
it,
the
more
successful
it'll
be.
C
C
C
F
Yeah,
I
I
slipped
in
a
quick
additional
agenda
item
request,
if
you
don't
mind
yeah,
so
it's
in
the
notes
here,
but
basically
I
think
many
of
you
know
that
the
open,
ssf
mobilization
plan
was
put
out
as
10
streams.
The
question
obviously
is
what
to
do
next.
At
the
time
we
were
just
focused
on
the
what
to
do
and
not
how
and
who,
but
that
doesn't
need
to
get
answered.
One
thing,
that's
being
looted.
F
No
decision
made
anything
like
that,
but
basically
trying
to
come
up
with
a
bunch
of
of
groups
calling
them
sigs
and
stream
10,
which
involves
supply,
improved
supply
chains,
looks
like
something
that
maybe
could
be
created
in
support
to
this
report.
Up
to
this
working
group,
as
I
said,
nothing,
nothing
set
in
stone
or
anything
like
that,
but
just
to
want
to
give
folks
a
heads
up
that
that's
a
topic
of
discussion.
C
F
D
Together,
we're
looking
for
things
to
kind
of
sanity
check
it
again.
So
if
folks
do
have
ideas
of
of
things
that,
if
you'd
like
to
kind
of
request,
funding
or
resources
or
or
map
up
to
some
of
the
evangelization
and
the
the
recruiting
that
has
been
done
to
get
more
people
interested
in
funding.
This
we're
trying
to
figure
out
the
exact
logistics
there.
F
C
You
know
that's
great
and
I
know
we
had
talked
a
little
bit
about
that
when
the
for
the
folks
that
were
in
person
in
dc
back
when
we
were
talking
about
the
streams
we
so
we're
like
yeah,
there's
a
lot
of
overlap
here.
So
I
think
that
makes
sense
cool
anything
else
for
the
agenda.
Otherwise,
a
couple
minutes
back.