►
Description
Don't miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from 18 - 21 April, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Package Transparency for WebAssembly Registries - Kyle Brown, SingleStore
WebAssembly (Wasm) is a significant advancement in the portability and security of code, but for Wasm to be useful we need a way to publish and distribute it. This presents a unique opportunity to correspondingly advance the state of the art in supply chain security. That's why the Bytecode Alliance, a Wasm-focused non-profit, is working on developing a new registry protocol for Wasm packages, with security at the center, called warg. Warg is designed to offer "Package Transparency" by building on verifiable data structures from the field of Certificate Transparency. This means that the entire state of a registry can be validated by monitors, replicated by mirrors, and operator compromise can easily be detected. Come attend the talk to learn more about it from two Registry SIG members and implementors!
A
My
name
is
Kyle
Brown
I'm,
an
engineer
at
single
store
and
today
I'm,
going
to
talk
to
you
about
package,
transparency
and
webassembly
registries
to
a
brief
overview
of
the
talk
structure,
we're
going
to
begin
by
explaining
what
webassembly
commonly
abbreviated
as
wasm
even
is
then
we're
going
to
step
back
and
ask
the
question:
what
is
a
package
registry
and
what
kind
of
package
registry
that
webassembly
needs?
I
want
to
propose
a
simple,
if
maybe
somewhat
surprising,
answer,
then
we'll
talk
about
applying
some
ideas
from
certificate.
Transparency
to
package
registries.
A
Talk
about
package
transparency
itself,
this
term
created
by
combining
the
two
and
Warg
a
protocol
implementing
it
and
wrap
up
by
showing
how
the
properties
of
package
transparency
help
us
mitigate
different
kinds
of
attacks
so
jumping
in
to
webassembly
what
is
webassembly?
Well,
the
simplest
way
that
we
can
really
explain.
It
is
that
webassembly
is
a
platform
agnostic,
compile
Target
or
in
other
words
it's
something
that
you
compile.
Programs
to.
You
could
write
it
by
hand,
but
you're
not
likely
to
write
a
lot
of
by
hand
for
the
same
reason.
A
You
don't
write
a
lot
of
machine
code
by
hand
right
it's
ergonaut,
it's
not
very
ergonomic.
It's
very
low
level
Instead
at
the
moment,
you're
likely
to
create
web
assembly
by
compiling
well-supported
languages
like
rust
and
C
plus
plus
to
wasm,
and
these
sort
of
got
support
earlier
than
a
lot
of
other
languages,
because
they
do
their
own
memory
management,
they're,
very
low
level.
You
don't
have
to
bring
along
an
interpreter,
there's
sort
of
the
simpler
side
of
the
problem
of
building
webassembly
modules.
A
With
that
said,
work
is
in
progress
for
a
variety
of
other
languages
and
we're
working
on
solving
sort
of
The
Interpreter
problem
and
there's
different
options
for
handling
garbage
collection.
Whether
walls
and
modules
bring
garbage
collection
with
them,
or
they
use
a
runtime
facility
for
doing
that.
A
For
a
little
bit
of
History
wasm
was
a
web
technology
was
created
in
the
web.
That's
why
it's
called
Web
assembly
after
all,
and
it
became
a
w3c
standard
in
2019.
Even
before
then
back
to
2017.
It
was
supported
in
all
the
major
browsers,
so
it's
been
out
there
for
a
few
years
now,
despite
being
a
web
technology
being
something
that
came
from
the
web
is
supported
in
browsers.
It
isn't
just
a
web
technology,
it's
not
just
for
the
web.
It
has
these
other.
A
These
valuable
properties
that
were
created
for
the
web
that
everybody
else
kind
of
wants
to
believe
it
or
not.
You
know
the
portability
that
it
needed
to
run
in
all
the
major
browsers
on
a
wide
variety
of
systems
is
useful,
no
matter
where
you're
trying
to
deploy
your
applications.
Portability
is
great.
You
need
to
be
fast
to
run
in
the
web.
We
expect,
for
example,
out
of
a
web
page
really
low
latencies
with
them
to
load
quickly.
A
Really,
we
should
hope
expect
that
more
and
so,
as
a
result,
wasm
has
a
really
low,
startup
latency.
In
fact,
you
can
actually
start
compiling
wasm
before
you've
even
finished
downloading
it
all
using
streaming
compilation.
It's
gonna
do
code
generation,
validation,
sequentially,
it's
also
capable
of
near
native
performance,
think
within
about
20
to
30
percent
of
native.
So,
there's
a
wide
variety
of
applications
that
are
capable
of
running
in
this
kind
of
environment
that
maybe
you
wouldn't
want
to
run
in
per
se
JavaScript
on
the
security
side
to
run
the
browser
it
needed
to.
A
You
couldn't
have
ambient
authority
to
the
entire
user's
permissions
right.
These
needed
to
be
sandboxed
in
some
way,
and
so
Walzem
does
that
by
being
capability
safe,
which
you
can
just
think
of.
As
you
know,
webassembly
modules
can
only
do
the
things
they've
been
given
permission
to
do.
You
feel
like
actually
give
and
you
satisfy
an
import
buying
some
capability
to
them,
for
them
to
be
able
to
call
something,
and
additionally,
they
have
sandboxing
each
wasm's.
A
Linear
memory
is
independent
from
any
other
ones,
and
a
web
assembly
module
can't
call
out
and
access
a
linear
memory
that
it
hasn't
been
given,
and
so
for
all
these
different
reasons,
you
could
sort
of
imagine
why
people
would
want
to
use
somebody
outside
the
browser.
The
company
I
work
for
a
single
store
uses
webassembly
for
database
extensibility.
We
let
you
know,
customers
compile
their
code
to
webassembly
and
run
it
in
process
in
the
database.
As
a
user-defined
function,
companies
like
cosmonic
are
using
it
to
create
distributed
application
systems.
A
Fastly
is
using
it
for
Edge
computing
fermion
is
using
it
for
service
runtimes
and
platforms.
Shopify
is
using
it
for
plugins
and
extensibility
and
Microsoft.
In
addition
to
the
Blazer
project,
was
about
running
webassembly
in
the
browser.net
style
also
supports
running
Wazi
modules
in
its
Azure
kubernetes
service.
A
All
six
of
these
companies
and
many
others
are
part
of
the
bytecode
alliance,
a
non-profit,
Foundation
working
on
implementations
of
these
Open
Standards
to
help
mature
and
Advance
the
ecosystem
and
the
sort
of
webassembly
that
we're
all
creating
that's
going
outside.
The
browser
needs
to
be
composed,
shared
and
deployed
in
a
bunch
of
different
environments,
and
to
do
that,
we
really
need
our
package
registry.
A
We
really
need
somewhere
to
publish
your
wasms
and
pull
them
down
and
that's
part,
that's
something
you
can
interact
with
at
build
time
as
you're
compiling
and
also
maybe
at
deploy
time
and
when
we're
creating
this
registry.
We
really
want
it
to
be
as
secure
as
webassembly
itself.
If
webassembly,
you
know,
has
these
really
nice
isolated
properties
and
capability
safety,
but
you
deploy
it
in
securely.
Then
you
sort
of
lose
all
the
advantages.
A
You
know
you
wouldn't
want
to
secure
a
vault
with
a
Cheeto
per
se,
so
stepping
back
now,
we've
said
that
websally
needs
a
package
registry.
What
is
a
package
registry?
What's
this
thing
that
webassembly
needs
at
a
more
sort
of
abstract
level,
the
main
role
of
package
registry
sort
of
as
the
in
the
kind
of
packages
we're
talking
about,
because
there's
diverse
kinds
of
Registries
out
there,
really
its
main
job,
is
to
delegate
names
like
you're.
A
Now,
the
owner
of
leftpad
I've,
given
you
permission
over
left
pad
to
package
owners
who
then
use
that
permission
to
publish
releases
that
are
versioned
of
those
packages
so
put
a
different
way.
A
registry
is
really
just
an
index.
It's
a
mapping
from
the
name
and
version
of
a
package
to
what's
there
to
the
digest
of
the
package
contents,
and
it
has
some
special
rules
about
how
it
gets
updated.
A
So,
fundamentally,
this
kind
of
registry-
that's
this
mapping
of
names
and
versions
to
contents,
has
to
own
the
metadative
packages.
It
has
to
be
the
sort
of
authoritative
place
where
that
info
lives,
that
you
can
establish
the
mapping
between
things
and
their
contents,
but
fundamentally
it
doesn't
actually
have
to
be
the
thing
that
does
the
content
storing.
Well,
you
can
actually
store
the
content
in
a
self-hosted.
You
know
location,
that's
with
the
registry.
A
A
So
the
rough
analogy
and
bear
with
me
a
little
bit
is
that
with
certificate
transparency,
people
are
able
to
detect
when
ca's
mississue
certificates
right,
whether
it's
accidentally
or
maliciously,
you
can
tell
that
something
was
done
incorrectly,
that
something
was
done
wrong
and
with
Registries.
It
wouldn't
be
kind
of
nice
if
clients
could
detect
when
Registries
except
invalid
package
updates.
So,
for
example,
somebody
else
tries
to
publish
an
update
to
your
package,
a
new
release
but
they're,
not
the
actual
owners
of
that
package.
They're,
not
the
ones
who
are
supposed
to
be
controlling
that.
A
That
name
so
packet
transparency
does
this.
It
applies
these
ideas,
some
tools
and
ideas
from
circuit
transparency
to
package
Registries.
To
give
us
these
properties
packet
transparency,
as
defined
by
Landmark,
who
coined
the
term
in
our
project,
is
you
know,
publishing
cryptographically,
verifiable
commitments
to
the
state
of
a
package
registry
and
bear
with
me
on
this
part
to
allow
auditing
of
the
actions
of
package
authors
and
the
registry
itself
over
time.
So
that's
a
bit
of
a
mouthful
we're
going
to
break
into
three
parts,
the
first
of
which
is
publicly
available
registry
State.
A
A
So
we
so
this
definition
came
up
with
what
we're
trying
to
do
and
we've
created
a
protocol.
That
is
an
implementation
of
these
ideas.
Warg.
It
stands
for
webassembly
registry
sort
of
is
the
idea
is
this
implementation
of
package
transparency
and
it
it
implements
these
three
different
steps:
you're
just
talking
about
and
we're
going
to
try
to
burn
through
explaining
them.
The
first
part
of
it
needs
to
have
publicly
available.
A
That's
what
that
right
to
left
arrow
is
and
can
do
things
that
affect
the
state
of
the
package
like
creating
releases,
but
also
like
granting
the
permission
to
do
releases
into
manage
authorization.
Now
that
Bob
sort
of
has
been
given
the
ability
to
do
a
release,
he
subsequently
can
do
that.
He
can
append
records
to
the
log
and
submit
them
to
the
the
registry
and
when
they're
accepted
these
releases
now
exist
and
they're
part
of
the
state
of
this
package.
Since
an
appendal
new
log,
you
might
think
well,
I
can't
get
rid
of
those
releases.
A
A
If
you've
still
got
it,
you
still
know
the
hash,
that's
fine,
but
for
most
clients
in
discoverability
and
things
treat
that
as
having
been
deleted,
and
so
really
registry
can
be
made
up
of
a
bunch
of
these
package
logs
a
collection
of
package
logs,
and
that,
then,
is
the
publicly
available
state
of
the
registry.
This
the
records
that
make
up
the
logs
for
each
package.
A
Now
we
need
to
make
cryptographically
verifiable
commitments
to
these
data
and
we're
going
to
start
by
somehow
making
the
registry
commit
to
what's
happened
in
the
past,
like
which
records
are
part
of
its
accepted
history
and
what
order
they
happened,
and
we
do
this
by
taking
a
data
structure
from
certificate
transparency
that
maybe
some
of
you
be
familiar
with
called
a
verifiable
log.
That's
based
on
the
idea
of
a
Merkle
tree
and
so
sort
of
the
abstract
data
type
of
a
verifiable
log.
A
That's
what
we're
going
to
get
out
of
it
and
here's
how
we're
going
to
do
it
right,
there's
a
sequence
of
records
and,
unlike
the
other
kind
of
log
we
had
here,
they
don't
have
the
hash
of
the
previous
one
they're
all
Independent
Records,
and
they
all
have
their
own
independent
hash
that
we
can
compute.
And
if
we
want
to
know
what
the
representative
checkpoint
is.
For
this
whole
log,
we
can
hash
together.
A
These
leaves
of
a
tree
to
form
branches
and
then
the
root
of
that
tree
in
a
particular
way
and,
as
we
add
more
records
to
this
log,
what
we
find
is
that
the
root
hash
that
represents
it
changes
and
sometimes
that
root
hash
is
a
sub
tree
of
the
future.
But
sometimes
it's
not,
and
it
has
to
do
with
whether
or
not
the
length
is.
A
You
know
an
even
you
know,
power
of
two,
but
we'll
show
later
on
that
that
doesn't
that's
not
an
issue,
that's
just
part
of
how
it
works,
and
so,
since
every
single
leaf
contributed
to
the
value
at
the
top,
we
can
show
that
a
given
value
is
in
the
root
by
reconstructing
the
root
from
the
leaf
right,
and
we
do
that
simply
by
hashing,
together
values
with
their
siblings
to
get
higher
and
higher
nodes
in
the
tree
until
we
get
to
the
top
and
if
that
matches
what
we're
expecting
we've
shown.
It's
been
included.
A
There's
also
something
called
consistency.
Proof
you're
going
to
want
to
generally
know
that
this
log
of
the
state
of
the
registry
only
fast
forwards.
The
history
doesn't
get
changed
and
you
do
that
by
showing
that
the
new
state
is
consistent
with
the
old
state
right
that
only
six
and
seven
have
been
added
and
changed,
and
you
do
that
essentially
just
by
showing
that
all
the
stuff
that
used
to
be
in
the
log
is
included.
We
don't
need
an
inclusion
proof
for
zero
through
five
individually.
A
We
just
need
inclusion
proofs
that
show
that
their
parent
branches
are
that
you
can
recompute
root
six
from
them.
So
what
does
the
registry
claim
has
happened
and
the
answer?
That
is
the
sequence
of
values
that
are
in
its
verifiable
log,
and
each
of
these
records
has
both
the
the
record
itself
hash
and
the
the
name
of
the
package
hashed
into
it.
So
you
can
tell
that
this
is
a0
was
put
into
a
right.
A
It's
been
appended
to
the
package
a,
but
one
thing
clients
can't
efficiently
do
here
is
tell
what
the
the
most
up-to-date
the
latest
record
is
in
each
of
these
logs.
They
have
to
walk
the
entire
verifiable
log
backwards
and
now,
in
the
worst
case,
that's
walking
everything
that
ever
happened.
If
your
package
has
not
been
updated
in
forever,
so
that's
just
entirely.
A
You
know
intractable
to
clients,
so
we
need
something
that
helps
us
solve
this
problem
and
that
tool
is
another
thing
from
transparency
called
a
verifiable
map
and
where
the
other
thing
was
a
log,
this
thing's
a
map.
It's
sort
of
that
straightforward.
Really
it's
a
key
value
mapping.
It's
also
described
by
unique
cache.
We
can
also
check
that
things
are
included
in
it.
A
Those
are
sort
of
the
fundamental
things
we
want
out
of
it
and,
unlike
the
other
one
where
we
had
this,
like
sequence
of
records,
that
built
up
a
Merkle
tree,
we
actually
have
sort
of
a
Radix
tree,
and
if
some
of
you
are
familiar
with
Radix
trees,
you'll
know
that
at
each
branch
you
decide
which
child
to
go
to
based
on
part
of
the
key
right.
And
so,
if
we
want
to
insert
0
0
1
into
this
tree,
we
go
left
then
left.
Then
right.
A
So
we've
walked
in
the
tree
to
the
correct
position
that
corresponds
to
that
key
now.
In
reality,
this
tree
is
actually
has
a
height
that
is
directly
equal
to
the
number
of
bits
in
the
hash.
So
it's
quite
large,
but
on
screen
we
can
fit
three
levels.
So
that's
what
we
do
and
we've
inserted
X
here
and
what
that
means.
Is
that
the
the
hash
that
represents
this
Leaf
is
the
hash
of
X
we'll
get
to
that
later?
A
And
if
we
insert
more
things
in
the
tree
we'll
see
it
fills
out
that
it
more
things
are
present,
and
this
tree
is
fundamentally
sparse.
It's
not
a
full
tree,
it's
a
tree
with
only
some
values
present
and
we'll
finally
insert
your
Z
here
at
one
one.
You
can
sort
of
see
how
this
is
working
and
like
the
other
one,
we
build
the
hash
of
the
root
it.
You
know
incrementally
from
the
bottom
up,
so
that
every
leaf
and
key
every
key
in
value
in
the
leaf
you
know,
contributes
to
the
root
value.
A
So
we
hash
in
this
case
all
the
leaves
to
get
their
value
with
a
unique
prefix.
Then
we
can
hash
branches
like
the
one
one
branch
over
there
and
show
you
know
that
it
combines
the
two
values
of
its
children,
but
we
also
have
these
branches
out
here
that
only
have
one
sub-child
right,
only
one
subtree
to
the
left
or
right,
and
in
that
case
we
prevent
Collision
attacks
by
modifying
the
prefix.
A
So
there's
a
bit
that
indicates
essentially
which
subtree
is
not
present
and
in
the
top,
both
subjects
are
present,
so
it's
the
normal
case
of
one
one
and
together
that
way,
we've
hashed
up
the
information
about
a
key
value
mapping
and
just
like
in
the
same
one,
we
can
do
an
inclusion
proof.
We
can
check
that
1
1
0
was
mapped
to
Y
in
this
root.
We
can
verify
that
in
log
n
hashes
by
simply
reconstructing
the
root
using
those
same
hashes,
we
were
using
before
to
construct
the
root
originally.
A
A
The
registry
knew
at
that
point
in
time,
that's
as
far
as
I
have
to
read
up
to
and
these
two
data
structures
get
combined
together
into
a
single
checkpoint,
which
is
sort
of
includes
the
hash
of
both
the
root
hash
of
both
and
a
signature
by
the
registry,
and
that
is
the
state
that
we're
committing
to
for
the
registry.
You
note
that
this
uniquely
identifies
the
state
of
every
package
at
one
point
in
time.
So
if
you
ask
the
question,
what
was
the
latest
version
of
Foo
for
some
checkpoint?
A
A
Clients
are
fundamentally
resource
constrained
right,
you
know
most
clients,
don't
have
you
know
super
computers
running
just
because
they
want
to
download
a
package,
that's
sort
of
a
insane
view
of
it.
Even
small
devices
should
be
able
to
be
clients,
and
they
only
really
care
about
some
things.
If
you're
a
client-
and
you
want
this
package-
it's
dependencies-
you
don't
want
to
verify
the
entire
registry.
A
State
that'd
be
absurd,
so
what
you
only
want
to
do
is
verify
the
relevant
package
State
and
that
that
package
state
is
committed
by
the
registry
that
the
registry
is
committed
to
that
information.
So
you
don't
care
about
a
slice,
and
you
also
want
to
know,
of
course,
that
the
commitments
are
valid
and
correct.
A
A
Then
they're
going
to
verify
the
package
logs
and
they're
going
to
sort
of
sequentially
process
each
one
using
that
sort
of
logic.
We
talked
about
earlier,
where
you
know:
if
I
grant
someone
a
key,
then
they
can
do
something
if
I
don't,
then
they
can't
and
releases
have
to
you
know
you
can't
release
two
things
in
the
same
version.
Instead
of
those
rules
that
you
sequentially
validate
on
for
all
the
packages
you
care
about
in
this
case
we're
processing
this
log.
A
A
We'll
continue
in
the
success
case,
where
the
logs
are
fine
and
show
you
what
would
happen
next,
but
you
could
already
have
bailed
at
this
point
if
you
detected
that
so
the
next
thing
you
get
is
the
checkpoints
in
this
case
sort
of
the
word
log
in
the
word
map
represent
that
root
hash
of
each
structure
for
compactness,
and
you
notice.
We
don't
have
any
of
the
other
information
about
the
logger
map.
We
don't
have
any
of
the
things
that
make
them
up.
A
Clients
will
sort
of
also
validate
the
signature
on
the
checkpoint
and
say
that
this
was
actually
committed
to
claimed
by
the
actual
registry,
not
some
random
third
party
that
made
up
a
registry
checkpoint
now,
oh
yeah.
In
addition,
one
thing
they
can
also
do
is
if
they
already
had
a
checkpoint,
then
for
the
log
at
least,
they
can
ensure
very
quickly
that
it's
a
fast
forward
that
all
the
records
they
previously
knew
about
are
still
part
of
the
registry.
A
The
one
thing
that
they
can't
really
do
is
verify
that
the
login
map
agree
with
each
other
right.
They
can't
they
can't
easily
check
that
there
isn't
some
record
in
the
log.
That's
not
represented
in
the
map,
that's
newer
than
what
they
know
about.
So
who
are
clients
going
to
call
monitors,
not
MythBusters,
but
so
the
monitors
are
able
to
do
this.
They
are
long
running
processes.
They
only
care
about
valid
and
cryptographic.
A
Information
in
a
stream
and
so
monitors
are
able
to
process
all
the
checkpoints
that
ever
were
and
make
sure
they
all
agree
with
each
other
internally
and
across
time,
and
so
that's
what
the
clients
can't
do
and
because
clients
can
talk
to
as
many
or
as
few
monitors
as
they
want.
You
can
add
security
by
simply
standing
up
more
monitors
and
sort
of
create
a
web
of
trust
right
so
revisiting
our
three
parts
of
package
transparency.
We
needed
publicly
available
registry
state
that
we
got
with
a
collection
of
package
logs.
A
A
So
we've
done
all
this.
How
does
it
hold
up
against
attacks?
Well,
let's
imagine
that
the
registry
gives
you
package
data.
You
download
package
data,
but
it
gives
you
an
a
modified
record
in
the
past.
How
are
you
going
to
know
that
they
modified
a
record
in
the
past?
The
answer
is
that
two
things
are
going
to
immediately.
Stop
being
true,
they're
stop
validating
correctly.
The
hash
linkage
from
A2
backwards
to
A1
will
no
longer
work
because
A2
didn't
contain
the
hash
of
this
modified
record.
A
A
What
if
a
registry
tries
to
hide
something
from
you
right?
If
it
tries
to
say
no,
this
thing
didn't
exist,
don't
worry,
there's
there's
not
a
security
patch
you're
fine.
That
version
wasn't
yanked.
If
it
does
that,
then
the
linkage
here
from
the
map
is
going
to
fail
right.
The
inclusion
proof
that
says
No
A1
is
the
newest
thing,
as
of
my
checkpoint
will
fail
because
it
wasn't
and
it
already
committed
to
the
fact
that
it
wasn't
now
you'll
note.
We
already
talked
a
little
bit
about
the
consistency
of
the
login
map
here.
A
So
the
idea
is
that
if,
if
the
registry
had
created
a
map
and
log
that
didn't
agree
where
it
did
say,
A1
was
the
latest
thing
in
the
map,
but
it
still
already
knew
about
A1
and
its
log.
Then
the
monitor's
job
is
to
catch
that.
At
this
point,
those
two
things
have
already
been
proven
to
be
consistent,
and
so
then
that's
how
you
know
that
you're
not
getting
indefinitely
Frozen,
for
example.
A
So
to
summarize
sort
of
the
broad
points
of
the
talk.
Wasm
is
a
promising
way
to
make
portable
and
secure
software
package
Registries,
or
at
least
the
kind
that
we
need
are
really
indexes
of
content,
that
map
name
and
version
to
what's
actually
there
packet
transparency
is
this
combination
of
certificate,
transparency
and
package
Concepts,
and
it
helps
us
provide
some
really
interesting,
defenses
against
different
kinds
of
attacks.
A
With
that
all
said,
I'd
like
to
give
a
special
thanks
to
a
few
people
who
helped
review
and
devise
this
talk
like
Land,
Martin
and
Luke
Wagner,
and
thanks
to
some
other
contributors
to
the
ward
project
like
Bailey,
Hayes
and
Peter
Hume.
Finally,
my
company
single
store
for
supporting
work
by
enabling
me
to
work
on
this
project
and
that's
all.
A
So
Warg
itself
is
really
about
managing
name
spaces
right
and
saying
that
this
name
is
owned
by
these
people,
and
this
version
is
authoritatively.
That
version
that
was
claimed
to
be.
If
you
want
to
claim
some
the
thing
that
you're,
probably
interested
in
and
I,
think
a
lot
of
people
want
and
are
currently
doing,
and
we
really
are
interested
as
well.
A
But
you
can't
trace
back
right,
because
the
signature
is
in
the
log
all
are
contiguous
right
and
they
sort
of
authorize
subsequent
signatures.
So
that's
how
you
can
know
that
the
people
you
originally
gave
it
to
gave
it
to
people
who
originally
gave
it
to
whatever,
and
this
is
not
that
different
from.
In
fact,
this
is
much
more
verifiable
than
like
npm,
for
instance,
if
you
want
to
know
the
people
that
you
gave
permission
to
be
left
pet
on
npm
are
actually
the
same
people
today.
A
A
So
the
way
we
currently
Envision
and
Visage
monitors
working
is
that
monitors
are
going
to
subscribe
to
a
stream
of
registry
data
from
the
Registries
that
they
monitor
and
they're
going
to
process
it
and
then
clients
actually
like
the
actual
API
client
you'll
set
you'll
pick
your
registry
that
you're
using
you'll
actually
pick
a
list
of
monitors
that
you
trust
and
when
you
do
that,
then,
whenever
you
pull
down
data
you're
actually
going
to
ask
that
monitor.
Hey
do
you
know
about?
Is
this
checkpoint
safe?
A
Yeah
and
the
monitors
actually
is.
Another
thing
are
one
of
the
defenses
against
indefinite
freezes,
because
what
a
modern
can
do
is
tell
you,
you
say:
hey
I,
just
installed
this
checkpoint
right,
this
checkpoint,
blah
blah,
you
can
say,
whoa,
that's
like
three
months
out
of
date,
buddy
somebody
is
holding
things
back
from
you,
but
yeah.
It
goes
from
client
to
monitor
is
the
direction
of
the
interaction.
A
A
Right
so
because
of
the
separation
of
namespace
and
content,
we
fully
expect
people
will
bring
their
own
storage
into
some
extent,
their
own
registry
systems,
but
when
they
want
to
be
part
of
the
name
spacing
that
we're
creating
for
webassembly
packages
when
you
say
like
this
is
so-and-so's
registry,
so
package
name
version
is
whatever
that
they
will
probably
choose
to
run,
that
on
top
of
their
existing
systems
and
that
we
actually
the
use
cases.
Registries
are
really
varied
because
we
start
to
see
some
a
general
purpose.
A
Good
Registries,
at
least
some
of
them,
potentially
one
run
by
the
bytecode
alliance,
but
maybe
not
we'll
see
we'll
see
different.
The
riskers
are
very
expensive.
Is
the
thing
Registries
run
by
different
individual
companies
and
projects
like
if
you're
a
company
or,
let's
see,
what's
that
if
you're
like
Envoy,
maybe
you
want
to
have
different
sort
of
like
your
own
registry
of
your
own
Envoy,
sort
of
extensions
and
things
right.
My
company
may
run
a
registry
at
some
point
of
database
extensions.
A
You
also
potentially
have
deployment
Registries
inside
your
company
that
are
the
only
place
that
you
go
to
download
things
that
mirror
content
from
other
places.
A
lot
of
companies
will
probably
run
their
might
run
their
own
monitor
because
monitors
what's
going
to
be
expected
to
be
relatively
cheap
and
as
a
result,
you
can
have
your
own
and
then
use
another
registry,
but
know
that
you're
always
monitoring
it
to
see
a
bunch
of
different
Registries
run
on
top
of
whatever
people
want
to
run
them.
On
top
of
yes,.
A
But
do
you
have
an
opinion
at
the
moment?
The
all
of
the
actions
that
are
taken
on
a
package
are
doable
only
by
the
people.
Who've
been
granted
those
permissions
directly
in
the
log
itself
in
log
authorization
there
is
another
tool
actually
as
well,
that
sort
of
adds
on
to
that
where
Registries
can
unilaterally
reject
anything.
Actually,
this
is
actually
just
a
fundamental
property
of
all
these
systems.
Anyway,
you
can
always
ignore
our
HTTP
request.
You
get
and
more
fundamentally
here
you
know
you're
able
to
just
not
include
something
in
your
locks.
A
It
didn't
happen,
and
so
one
thing
that
we
expect
is
that
Registries
will
use
this
in
actually
a
good
way
for
just
policy.
So
one
thing
you
do
is,
you
can
simply
say:
yeah
I'm
not
going
to
allow
you
to
release
that
thing
that
has
known
vulnerabilities.
You,
as
a
registry
operator,
can
choose
as
a
matter
of
policy
that
you
only
allow
things
that
are
signed,
have
no
known
full
movies
Etc
and
that's
the
thing
that
different
Registries
will
choose
different
answers
to
one
other
thing.
A
That's
sort
of
a
an
interesting
idea
that
we're
currently
thinking
about
is
that
the
registry
can
actually,
as
a
matter
of
policy,
reject
new
package
creation
that
doesn't
give
the
registry
operator
some
permission
in
the
log.
You
can
say
I'm
only
going
to
let
you
have
the
name
Fubar.
If
you
give
me
the
permission
to
yank
stuff,
and
so
it's
all
still
in
log,
but
in
combination.
This
idea
of
operator
policy
through
rejection,
you
can
actually
achieve
some
of
these,
like
higher
level
policy
ideas
about
like
giving
yourself
the
ability
to
yank
things.
A
We're
not
entirely
sure
the
there's
some
trade-offs
there,
especially
around
the
size
of
these
logs
and
besides
these
data
structures,
so
we're
not
sure
at
the
very
least.
This
will
give
you
a
strongly
identifiable
way
of
talking
about
packages,
so
you
can
build
tools
like
that
on
top
of
or
interoperate
with
existing
tools,
which
is
maybe
the
best
way
for
this
to
work.
A
A
Something
yeah:
how
do
you
recover
from
like
compromise
of
these
Keys?
That's
sort
of
a
big
question,
one
of
the
answers
once
it
goes
back
to
this
idea
about
like
initial
package
creation
policy,
where
you
could
say
actually
in
order
to
as
a
register
in
order
to
create
a
package
in
my
place,
you
have
to
give
me
the
ability
to
actually
reassign
key
permissions,
and
that's
really
scary
sounding
the
only
thing
that
helps
that
sound,
a
little
less
scary
is
that
you
can
tell
when
they
do
it
right.
A
So
you
can
actually
say
like
I'm,
not
actually
gonna,
I'm
gonna,
the
log
is
fine.
Log
is
fine,
and
if
the
registry
uses
this
power
that
they've
required
you
to
give
it
to
reset
the
keys,
then
it's
sort
of
like
an
oh
crap
moment
where
you
actually
are
going
to
want
external
information.
It's
going
to
Halt
the
next
poll
or
whatever.
A
There's
also
potentially
an
ability
to
make
a
special
kind
of
record
that
operators
can
always
do
that
like
takes
over
a
package,
and
that
would
obviously
be
very,
like
you
know
you
wouldn't
download
past
that
point
without
a
so
it's
a
reset
of
your
trust
in
the
package.
Authors
obviously
and
you'd
want
to
know
why
they
did
it,
but
that
has
some
interesting
complexity
actually
because
it
answering
the
question
what
operator
keys
were
allowed
to
do
that
at
some
point
in
time
requires
you
to
correlate
the
operator
log
in
the
package
log.
A
A
So
existing
Registries
may
have
a
hard
time
using
this.
Maybe
they
won't
I'm
not
entirely
sure,
because
you
have
to
go
back
and
like
rewrite
your
history
as
one
of
these
histories
and
I,
don't
know
how
tractable
that
is
for
most
of
them,
but
to
some
extent
what
we're
saying
here
isn't
really
very
wasn't
specific.
The
only
thing
that
you
really
have
to
do
with
work
to
run
some
other
type
of
content
is
to
add
a
new
content
type
and
describe
how
you
digest
it.
A
How
you
create
your
content,
digest
for
that
type
and
once
you've
done
that
everything
else
is
just
a
matter
of
policy
right,
so
no
you
could
do
you
could
use
work
for
something
else.
It's
not
very
reminiscently
specific,
but
we
came
to
it
from
the
direction
of
webassembly
and
solving
the
needs
that
webassembly
has
for
Federated
verifiable
namespaces,
but
if
everybody
else
also
needs
that
they're
welcome
to
come.
Take
a
look.
We're
happy
to
work
with
anybody.
A
A
Yes,
not
at
the
moment,
Warg
is
currently
written
in
Rust,
but
it's
a
protocol.
It
can
be
implemented
in
any
different
place.
It
has
HTTP
apis.
It
has
some
protobuf
that
describes
the
layout
of
these
records
in
the
log
and
some
abstract
semantics
for
how
these
hashes
are
created,
but
largely
you
could
create
in
any
language,
and
we
expect
at
some
point
that
we
will
actually
compile
our
rust
to
webassembly
and
there's
some
really
fun
bootstrapping
things
that
you
get
to
do
there.
A
Actually
another
thing
that
has
a
lot
of
people
excited
about,
having
sort
of
trying
to
be
really
thoughtful
about
supply,
chain,
security
and
webassembly
is
that
you
can
have
like
the
ultimate
version
of
a
build
pack,
where
you
have
like
a
Wazi
component
that
actually
takes
you
from
source
source
code
to
actual
artifact
in
very
verifiable
ways,
deterministically,
even
because
wasm
can
be
run
in
a
deterministic
mode.
So
there's
some
exciting
opportunities
there
for
maybe
something
similar
to
leverage
compiling
things.
It
wasn't
that's
really
how
it
gotten
attention
and
yeah.
A
Maybe
I
didn't
say
that,
but
clearly,
this
is
all
open
source,
the
registry's
out
there
by
code
Alliance.
You
know
github.com
registry,
you
know
org.io
if
you
want
the
short
version
of
getting
around
our
stuff
and
yeah,
and
if
we
can
share
an
implementation
of
these
things
that
compiles
to
webassembly
and
runs
quickly
like
why
not
use
a
singular
or
like
at
least
a
limited
number
of
clients
that
we've
audited
really
well
so.