►
From YouTube: Lightning Talk: SIG-Registries and Standardizing Package Management in...Bailey Hayes and Kyle Brown
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. 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.
Lightning Talk: SIG-Registries and Standardizing Package Management in WebAssembly - Bailey Hayes, Cosmonic and Kyle Brown, SingleStore
A
Our
goal
is
to
eventually
provide
a
bicotal
lines
instance,
so
that
we
have
a
set
of
building
blocks
of
canonical
components
that
everyone
is
able
to
extend
and
build
on
top
of.
But
we
don't
just
stop
there.
We
want
to
make
it
so
that
we
can
collaborate
across
different
instances
so
that
maybe
an
individual
company
is
able
to
host
their
own
private
components,
and
we
can
also
foresee
several
different
communities
out
there
that
build,
for
example,
specifically
Envoy.
A
A
So,
let's
take
an
example
of
I:
have
a
company
called
acne
and
I
also
am
working
with
in
the
envoy
ecosystem?
My
business
wants
to
write
an
authorization.
Library
I've
got
a
lot
of
specific
business
rules
in
there
and
Envoy
gives
me
a
lot
of
cool
out
of
the
box.
Http
filters
like
open
tracing
now.
Both
of
these
components
will
probably
need
another
key
building
block.
This
is
a
hypothetical
one.
A
So,
let's
imagine
that
this
works
like
a
Lego
base
plate
that
we're
able
to
build
on
top
of
and
assemble
these
components
that
Define
the
ecosystem
that
I
want
to
be
able
to
have
a
sidecar
proxy,
that's
running
with
authorization
and
open
tracing.
That's
the
entire
idea
behind
our
our
protocol
and
apis
for
worg.
Now
those
are
the
first
two
key
features
that
we
want
to
provide,
but
there's
one
that's
incredibly
important
that
Kyle's
going
to
share.
B
So
we
just
talked
about
component
orientation.
You
know
working
with
the
component
model
and
what
how
that
lets
us
build
building
blocks
and
a
little
bit
about
sort
of
federation
and
the
way
these
can
interoperate
between
different
registry
instances,
I'm
going
to
talk
a
little
bit
about
how
we
can
some
ideas
that
we
can
steal
from
significant
revocation
transparency
and
what
that
lets
us
do
so.
First,
we're
going
to
go
over
a
little
bit
of
background
instrument,
transparency
when
a
CA
issues
a
certificate.
B
B
What's
it
like
right
now,
in
addition
to
what
the
history
was,
and
this
data
structure
is
really
useful
and
we're
going
to
borrow
it
in
a
second
so
now
the
question
is:
how
can
we
make
a
registry
that
says
transparent
as
a
CA
and
Achieve
package
transparency
as
we're
calling
it?
B
The
first
thing
is
that
we
make
the
state
of
every
package
a
log
with
events
that
cover
things
from
the
initial
creation
of
that
package.
To
you
know
adding
and
removing
maintainers.
You
know
releasing
and
sort
of
unreleasing
different
versions
of
the
package
and
potentially
annotating
the
log
with
other
information
and
auditing
data.
B
B
It
might
look
like
this
and
if
you
have
another
package,
this
authorization
package
that's
being
used
to
have
this
custom
business
Logic
for
our
Acme
company,
then
maybe
they
have
a
release,
that's
dependent
on
lib
URL
like
we're
just
talking
about,
but
if
something
goes
wrong,
we
find
a
vulnerability
in
lib
URL,
there's
a
potential
that
we'll
be
able
to
put
an
audit
entry
in
its
logs
that
everybody
can
tell.
We
found
something
and
correspondingly
we
expect
that
you
know
you
probably
put
that
same
a
very
similar
entry
on
the
dependent
package.
B
It
has
the
same
problem
now,
because
the
maintainers
of
URL
are
good
people
and
they're
doing
good
work,
they're
going
to
release
a
new
patch
and
yank,
which
is
sort
of
our
term
for
unreleasing
marking,
something
is
not
fit
for
use.
The
bad
version
and
off
the
office
package
will
do
the
same
right.
We
expect
that
you
would
say:
okay,
cool.
Here's
our
new
version
that
doesn't
have
the
problem.
B
B
B
So
let's
say
that
the
operator
is
compromised,
and
so
now
it's
somebody
got
the
keys
to
the
kingdom
right.
They
can
sign
things
on
behalf
of
the
operator
of
this
registry,
so
what
they
might
be
able
to
do
then,
is
start
lying
to
you.
B
What
isn't
consistent
is
the
old
Route
with
the
new
root
and
the
old
Route,
with
this
new
package
element
and
the
client
can
easily
detect
the
malfeasance
that's
occurred
here,
so
really
excited
about
sort
of
bringing
state
of
the
art
in
transparency
to
package
Registries
in
a
way
that
I,
don't
think,
we've
ever
seen
before.
A
Worg
itself
is
going
to
be
an
open
API
built
on
Open
Standards,
and
so
what
we
hope
to
see
and
kind
of
expect
to
see
is
that
many
of
these
existing
projects
will
Implement
work
so
that
we
can
bring
an
entire
set
of
projects
and
ecosystems
into
a
world
where
we
can
build
with
components.
Now
our
our
entire
tenants
behind
all
of
this
right
is
to
provide
components,
give
a
way
for
interoperability
across
Registries
and
Federation
and
to
provide
package
transparency.
A
One
of
the
key
reasons
why
everybody
is
so
excited
about
webassembly
is
the
principle
of
security,
has
been
something
that
has
been
a
key
part
of
the
the
language
and
later
the
ecosystem,
and
so
this
is
really
just
an
extension
of
that.
We
want
to
make
it
so
that
everybody
has
a
bucket
of
Lego
bricks
that
they're
able
to
build
on
top
of
that
creates
an
entire
new
ecosystem.
So
thank
you.