►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Redesigning Notary in a Multi-registry World - Justin Cormack, Docker
Notary, used to secure container image updates, is the most widely adopted implementation of the TUF protocol. However, since Notary’s design around Docker Hub in 2015, container registries have proliferated and some of the design decisions don’t support the needs of a multi-registry world. This talk looks at redesigning the model to allow portability of container images between registries with signature data stored alongside the image data allowing it to be pushed and pulled alongside the image. This reworking of Notary will enable easier portability of images, and improve supply chain security by enabling mirrors and users of mirrors to validate image data, allowing users to easily work with cloud and local registries, offline caches and other common architectures.
https://sched.co/UacT
A
Thanks
very
much
yeah,
so
I'm
Justin
I
come
from
here.
This
is
Cambridge,
it's
a
small
tech
village
in
the
UK
and
I'm
security
leader
docker
at
least
I'm
a
said,
and
it's
been
a
bit
weird
last
week.
So
just
you
know
it's
it's
one
of
those
things.
So
yes,
I
still
work
at
darker.
Yes,
darker
still
exists.
Yes,
we
are
doing
all
the
fun
bit
still
and
we're
excited
to
work
with
the
open
source
community.
A
For
this
talk,
we've
had
a
lot
of
discussions
leading
up
to
it
with
Steve
from
Microsoft
is
here
the
ec2
T
registry
team,
Justin
Kappas,
is
also
here
and
a
bunch
of
other
people,
and
this
talk
is
cut
out
some
suggestions
and
my
thoughts
about
what's
going
on
and
and
and
it's
not
a
committed
roadmap
or
anything,
and
we
I'll
talk
a
bit
more
about
that
towards
the
end.
But
you
know
it's:
it's
things.
I've
been
thinking
about
just
to
kind
of
frame
it
and
had
just
mentioned
supply
chain
security.
A
A
Originally
tough
came
back
from
looking
at
the
Linux
package
repositories
really
and
what
the
kind
of
security
issues
with
them
were.
How
you
could
attack
those
and
and
basically
install
code
on
people's
computers
that
would
need
to
compromise.
So
obviously
things
like
serving
up
fake
packages,
it
completely
not
what
they
say,
but
other
things,
the
more
complicated
saying,
Isis
things
like
getting
someone
to
install
an
old
vulnerable
person
in
a
package
instead
of
the
current
one
and
very
lying
about
what
his
name
is
and
things
like
or
just
telling
them.
A
There
are
no
updates
and
they
don't
need
to
update.
And
you
know,
there's
been
a
security
issue
and
there's
a
whole
set
of
these
as
there's
a
set
of
tough
papers.
If
you
look
them
up
that
on
the
object
framework
website
that
cover
days
and
it's
really
interesting
and
just
just
having
TLS
or
signature
or
sign
does
not
really
stop
those
problems.
You
need
to
actually
sign
a
collection
of
items
and
you
need
to
resign
regularly
to
allow
freshness
checks
to
start
these
freeze
attacks
so.
A
Basic
stuff,
you
know
you
have
a
kind
of
the
sort
of
viewpoint
of
tough.
Is
that
you're
trying
to
update
your
software?
You
can
see
the
package
repository.
You
know
you
pull
metadata
from
it
look
and
see.
What's
going
on,
you
have
a
public
key
that
you
trust
to
give
you
signatures
and
you
can
validate.
A
You
can
validate
these
these
keys
and
then
there's
a
set
of
there's
a
set
of
there's
a
certain
keys
which
are
designed
to
basically
allow
you
to
delegate
an
update,
different
signing
keys,
I
mentioned
in
toto
briefly
as
well,
which
in
toto
is
kind
of
different
part
of
the
supply
chain
which
answers
questions
about
how
code
was
built,
who
built
it
and
was
it?
Did
it
go
through
the
right
process
and
that's
really
there
to
kind
of
help
you
I
stopped
people
attacking
so
during
the
build,
build
and
deployment
before
deployment
process.
A
So
this
is
this
talks
really
about
what
the
things
we
want
to
fix
and
the
lessons
we've
learned
from
nature,
as
as
it's
been
built
and
deployed
in
the
last
few
years,
nursery
was
originally
a
project
from
dhaka
implementing
tough
in
2015
and
which
is
I
was
not
involved
at
the
beginning.
I
was
that
I
just
joined
a
little
bit
after
around
when
the
launch
was,
and
the
idea
was
the
you
know
packages.
A
A
Some
of
the
issues
now
are
around
usage
and
I.
Think
you
know,
naturally,
is
not
used
as
much
as
we
would
like
it
to
be.
People
find
it
difficult
to
use
for
various
user
there's
the
first
usability
issues.
There
are
some
implementation
and
design
issues
that
are
kind
of
weird
that
we'll
talk
about
it's
difficult
to
understand.
What's
going
on
and
observe,
you
know
if
it's
actually
hard
to
see
the
metadata
and
what's
actually
going
on
so
it's
kind
of
hard
and
it's
not
terribly
modular
or
anything.
A
So
I
won't
talk
about
this
kind
of
registry
native
idea
as
well
when
when
we
as
part
of
building
docker
back
in
the
day
we
built
this
thing
called
registry
and
a
registry
is
effectively
a
content,
addressable
storage
mechanism
with
with
so
it's
a
basically
you
address
objects
by
their
shell,
t56
hash
and
then
there's
a
way
of
adding
tags.
So
it
it's
really
similar
to
get.
A
Apart
from
the
fact
that
it's
designed
for
really
large
sets
of
data,
we
didn't
make
the
mistake
of
using
sha-1
because
it
was
a
bit
later
on,
and
but
it's
conceptually
it's
it's
it's
very
similar
designed
to
get
and
then
and
it's
kind
of
nice.
It's
kind
of
nice
model
I
think
that
there's
a
whole
lot
of
guarantees
about
I
mean
one
of
the
reasons
it
works
is
that
containers
are
designed
to
be
immutable
objects
and
the
mutable
objects,
don't
change
their
content
so
addressing
them
by
that
content.
A
A
There's
a
bunch
of
ongoing
work
in
actually
expanding
it,
not
just
to
be
container
images
but
other
things
like
helm,
charts
and
all
sorts
of
other
items,
and
then
this
and
scene
app
and
artifacts
and
and
all
sorts
of
things.
So
there's
a
real
bunch
of
work
around
expanding
the
registry
kind
of
usage
use
cases
recently,
which
is
really
cool.
A
There's
a
set
of
JSON
objects
that
are
in
the
registry
that
basically
describe
the
actual
bits
and
how
to
use
them.
So
things
like
the
layers
in
the
docker
image
and
bits
of
metadata
and
so
on,
and
then
there's
actually
a
hierarchical
kind
of
layer
set
of
these
things.
So,
for
example,
when
we
introduced
support
for
multiple
architectures
in
darker
different,
you
know
different
platforms
like
Windows
and
arm
containers.
Things
like
that.
We
added
another
layer
of
indirection,
so
you
could
choose
which
of
them
at
which
of
the
actual
images
you
wanted
and.
A
There's
a
kind
of
they've
become
some
sort
of
ways
in
which
people
use
registries,
so,
for
example,
they
tend
to
be
very
archival.
People
don't
tend
to
delete
stuff
much
from
registries
so
because
one
of
the
advantages
of
containers
is
reproducibility
and
if
you
want
to
go
back
and
see
you
were
running
six
weeks
ago
or
six
months
ago,
you
can
do
it.
If
you
keep
everything
and
then
there
was
some
kind
of
bugs
I
think
in
the
implementations.
A
So
it
wasn't,
even
though
it's
content-addressable
often
clients
when
they
pull
and
push
things
will
just
pass
the
Jason
and
then
push
back
a
new
bit
of
Jason
which
could
because
Jason
doesn't
have
a
fixed
form
in
general,
sometimes
will
be
different
and
changed
the
hash
and
that's
really
annoying.
So
there
was
some
sort
of
bugs
in
the
in
the
ecosystem
as
well,
but
registries
were
built
originally
without
a
sort
of
signing
model.
I
mean
get
acquired
a
signing
model
over
time.
A
So
when
no
tree
was
introduced
because
there
was
nothing
built
into
the
register
specification,
it
was
built
effectively
as
a
sidecar
that
sits
alongside
your
registry
and
it
provides
it
has
a
it,
sits
there
with
a
separate
database
and
it
gives
you
the
signature
metadata
and
that
models
have
been
really
kind
of
inconvenient
in
many
ways.
First,
are
most
registries:
don't
actually
run
a
notary
server,
so
docker
hub
does
and
Azure
does
now,
but,
for
example,
the
AWS
registries
and
most
most
other
registries,
don't
actually
run
notary.
A
So
you
can't
sign
anything
if
your
registry
decides
not
to
support
it
and
that's
really
weird,
but
it
means
the
functionality
is
not
part
of
the
registry.
It's
not
native.
It's
not
like
you
know.
I've
signed
this
git
commit
it's
now
in
git.
It's
like
I've
signed
this
get
commit
it's
in
some
other
files
and
which
is
sitting
somewhere
else
and
that'd
be
really
inconvenient.
A
Cuz
you,
you
know
you
pull
and
pull
she'll
get
repository
all
the
time
and
if
you
have
to
separately
copy
the
signatures,
it
would
be
really
really
annoying,
but
that's
the
situation
we're
in
with
them
with
notary
way.
You
can
you
pull
and
push
images,
but
the
signatures
don't
come
with
them
and
there's
actually
no
easy
API
for
pulling
and
pushing
the
signatures
at
all.
So
I
mean
you
can
pull
them
to
check
them,
but
you
can't
actually
push
new
ones
back
easily
to
some
other
end
points.
A
So
the
most
important
part
is
actually
signing
content
pieces.
There's
actually
the
other
question
about,
say
how
you
saw
in
tags,
which
I'm
not
going
to
talk
about
much
because
but
gate
allows
you
to
sign
both
commits,
which
is
much
like
signing
an
image
in
many
ways
and
also
tags
so
that
you
can't
move
tags
around
and
things
like
that,
I'm
not
going
to
talk
much
about
tech
signing
there
in
this
talk,
but
there's
that's
kind
of
important
as
well.
A
In
some
ways
as
a
little
diversion
signing,
Jason
is
kind
of
weird
and
annoying
and
tough.
The
tough
spectres
chose
to
use
canonical,
Jason
and
canonical
Jason
is
a
standardized
format
for
Jason,
where
you
decide
exactly
how
its
laid
out
and
how
you
order
all
the
keys
and
things
like
that.
What
we
found
is
that
there's
not
a
there's,
there's
two
different
specs
for
canonical
Jason
and
I,
don't
believe
any
of
the
implementations
implement
either
of
them
correctly.
A
He's
laughing
he's
tried
yeah
and
the
problem
is
if
we
try
and
if
you
accidentally
make
an
error
and
you
decide
that
you've
got
a
bug
in
your
canonical
Jason
implementation.
All
your
signatures
then
become
invalid,
which
is
really
annoying.
There's
a
great
blog
post
called
how
not
to
sign
a
JSON
object
from
Asakura,
which
I
recommend
you
read
if
you
like
this
kind
of
problem,
but
I
think
in
a
Content
addressed
format.
The
best
thing
to
do
is
externally
sign
blobs.
A
A
A
It
you
can,
if
you
have
a
signature
as
a
separate
objects
in
the
registry,
that
just
points
that
the
object
you're
signing,
then
you
can,
for
example,
do
things
like
give
people
the
hash
of
just
the
object
without
the
signature
for
compatibility,
if
they
don't
understand
signatures,
because
you've
got
a
separate
thing
to
point
it,
which
makes
it
easier
for
us
to
experiment
with
different
signature
formats,
detach
signatures.
Look
something
like
this.
This
is
kind
of
a
kind
of
you
got
a
list
of
signatures
because
you
might
want
to
sign
things
multiple
times.
A
So
this
is
kind
of
quite
a
clean
model.
It
doesn't
mean
there's
an
extra
extra
fetch
from
the
registry,
but
and
we
need
to
have
some
meta,
we
need
to
standardize
some
metadata
so
that
we
can
put
do
things
like
handle
expiry.
Fortunately,
the
tough
formats
all
will
include
that
anyway,
and
then
we
need
with
multiples.
If
you
want
multiple
signatures,
it's
kind
of
easy
you
can
either
sign
at
once
or
multiple
times
you
can.
You
can
modify
the
signature
later
or
you
can
point
another
signature
at
the
first
signature.
A
If
you
want
that's
also,
you
can
kind
of
chain
signatures.
If
you
want
all
those
things
are
kind
of
valid
strategies,
depending
on
how
you
want
to
use
signatures
and
yeah
for
backwards
compatibility,
you
can
do
kind
of
weird
things
like
have
a
manifest
list.
That
has
points
at
a
signature
which
then
points
another
manifest
list,
and
so
that
better
clients
are
told
to
ignore
things.
They
don't
understand,
so
they
can
ignore
a
signature.
A
A
I
think
I
see
how
it's
not
a
very
good
place
to
define
new
things,
because
their
whole
role
is
to
standardize
things
that
already
exist.
So
my
kind
of
view
is
that
we
need
to
sit
down
and
implement
these
things.
Do
the
kind
of
IETF
style,
rough
consensus,
running
cage?
Let's
get
this
stuff
working.
Let's
get
everyone
agreed
that
that's
what
we
want
and
actually
kind
of
ship
stuff.
A
A
Obviously,
a
lot
of
the
stuff
in
notary
and
tough
is
about
signing
collections
of
things,
so
tough
signs
collections
of
things
because
you're
signing
effectively
the
current
set
of
packages
so
that
you
know
what
goes
together
what
things
you
need
to
mirror
what
names
things
have
registries
are
kind
of,
don't
sort
of
natively
work
like
this,
because
things
like
I
mean
ready.
The
I
mean
docker
hub
runs
on
s3
as
a
back-end,
and
you
know,
s3
does
not
have
consistent
listings
and
things
like
that.
A
So
you
know
it's
not
a
it's,
not
something
that
falls
naturally
out
of
how
you
implement
it.
But
it's
that's
kind
of
okay,
because
we
can.
We
can
still
kind
of
push
these
documents
into
the
registry
that
lists
all
the
current
contents
a
particular
time.
So
we
can.
We
can
push
effectively
a
snapshot
as
a
data
item
into
it.
A
A
So
just
you
know,
this
is
what
we
have
in
our
in
our
registry
at
this
time
is
that
this
is
the
targets
list
and
there,
but
you
kind
of
think
well
actually
there's
something
weird
going
on
here,
because
actually,
when
we
have
a
registry,
we
don't
tend
to
actually
have
you
know.
If
you
look
at
one
set
of
files,
we
usually
we
usually
stick
different
versions
of
the
same
thing
in
one
in
one
registry
repository
and
where
we
have
a
bunch
of
things
that
need
to
be
there.
A
A
So
we
made
each
so
things
like
docket,
I/o
library
Debian,
which
is
the
Debian
official
images.
We
made
that
a
single
tuff
repository
with
its
own
root
key,
and
that
was
just
a
really
really
really
stupid
idea,
because
that
was
the
wrong
thing
to
do.
We
should
have
made
the
whole
of
docker
library
a
tough
repository,
because
this
is
the
collection
of
things
that
that
the
maintainer
of
docker
library
are
producing,
and
it's
the
set
of
stuff
across
that
that's
important
and
we
ended
up.
A
So
we
ended
up
with
this
kind
of
stupid
strategy,
where
we
literally
have
hundreds
and
hundreds
of
root
keys
for
all
these
separate
things
that
we,
that
means
that
there's
not
actually
a
single
root
key
for
the
whole
of
Dokka
library,
I,
think
so.
Here's
his
the
we
rosin
carried
in
docker
Enterprise,
which
is
kind
of
weird
that
basically,
for
example,
you
could
set
it
to
trust
everything,
Dokka
library-
and
this
is
the
list
of
Ches
and
it's
a
really
stupid
list
of
Kay's
that
should
be
1k.
A
It's
also
not
one
key
for
per
repository,
because
some
of
the
people
who
were
setting
up
these
repositories
use
the
same
key
from
multiple
repositories
and
some
of
them
obviously
didn't
so
that
was
kind
of
weird
as
well,
because
I
expect
there
to
be
the
same
as
the
number
of
projects,
not
sure
that's
less
and
also
like
there's
other
weird
things
that
we've
done
with
usage
of
repositories.
That
I
think
it's
just
peculiar.
So
we've
put
all
that
we
put
all
of
Debian
into
one
repository,
because
we
haven't
got
any
more
net.
A
We
didn't
give
ourselves
any
more
hierarchical
namespaces.
We
kind
of
just
gave
ourselves,
you
know
library,
miss
out
library
in
there,
but
the
library
slash
Debian,
but
you
can't
have
library,
slash,
Debian,
sighs
stretch
or
something
like
that,
because
we
almost
every
rigidly
arbitrary
cuts.
You
off
at
two
levels
of
hierarchy,
which
is
again
kind
of
stupid
and
tough,
is
raise
it
up
to
a
support,
hierarchical
delegations,
and
it's
really
sensible.
A
So
you
can
you
can
delegate
different
people
ability
to
push
to
different
paths
but,
as
we
basically
only
have
like,
we
don't
allow
any
paths
in
our
tough
free
players
and
they
re
because
we
they're
all
at
the
top
level.
It's
totally
stupid
and
the
delegation
feature
is
almost
totally
useless
and
so
and
just
confuses
people
because
they
get
the
list
up
about
delegations
as
like
booked.
What
do
I
just
give
everyone
everything,
because
it's
the
same
repository.
We
don't
have
any
names,
so
I
believe
I.
A
It's
really
frustrating
that,
like
with
they
throw
everything
away
from
the
main
report-
and
there
is
an
archive
in
Debian,
but
it's
you're
not
allowed
to
use
it
in
production
because
it
doesn't
have
much
infrastructure
supporting
it.
It
is
really
kind
of
cool
because
you
can
set
so
I,
say
I
once
what
apt
would
have
given
me
on
the
3rd
of
September,
and
it
will
give
it
to
you.
It's
nice
I
wish
there
was
one
for
other
distros
I,
don't
think
they
have
anything
quite
like
that,
but
we
always
sign
all
the
stuff.
A
We
always
the
automated
signing
infrastructure
for
restyling
snapshots
and
nature.
He
just
signs
everything
so
for
some
reason:
we
or
we
sign
all
the
old
stuff
that
you
should
never
install
because
it's
out
of
date
and
that's
all
the
stuff
in
the
replay.
So
again,
the
kind
of
way
we
use
things
in
the
way
that
we
kind
of
design
nursery
when
we
didn't
know
how
we
were
going
to
use
things
was
all
it's
all
kind
of
a
bit
wrong.
A
So
there's
that
there's
other
pieces
as
well
I
mean
I,
think
you
know
so
I
think
anyway,
no
jury
was
kind
of
an
ambitious
project
to
get
tough
working.
When
we
didn't
know
how
people
were
going
to
use
things,
and
so
we
made
some
mistakes
at
the
time,
and
these
are
totally
fixable
I.
Think
it's
really
quite
exciting.
Now
that
I
think
that
we've
had
a
bunch
of
community
meetings
about
this
actually
recently
and
we
who
talk
to
people
they're,
never
one
agrees
that,
yes,
funding
is
great.
A
We
want
to
do
signing,
let's
get
something
that
everyone
can
use.
It
solves
people's
problems
and
fix
some
issues
and
actually
roll
this
thing
out,
so
that
it's
used
much
more
widely
and
as
much.
You
know,
you
know,
solves
solve
people's
problems
and
doesn't
have
kind
of
weird
design,
things
that
are
kind
of
weird
and
is
native
to
registries,
and
it's
something
that
you
can
everyone
can
everyone
can
use
easily.
A
So
this
is
kind
of
becoming
kind
of
the
design
phase
of
the
we're
in
really
is
just
beginning
for
notary
kind
of
2.0.
Where
so,
we've
there's
a
lot
of
work
to
do
around
other
pieces
as
well.
I
mean
I've.
This
talk
only
covers
some
other
sort
of
technical
issues.
That
I
think
wrong.
Doesn't
really
talk
about
some
of
the
dozen
talk
about
all
these.
Some
of
the
usability
issues
and
related
technical
issues
like
having
one
root
key
for
each
repository,
just
least
enormous
proliferation
of
root
keys,
which
makes
life
annoying.
A
So
those
those
directly
hinders
usability.
But
there
are,
there
are
other
issues
around
the
actually
one
things
we
talked
about
this
morning
was
why'd.
You
have
to
do
the
docker
content.
Trust
equals
one
environment
variable
well,
that
was
actually
just
a
temporary
kind
of
hack
because
we
were
supposed
to
just
turn
it
on
for
everything
all
the
time,
but
it
became
clear.
A
But
we
want
to
move
our
official
images
into
a
you
know
our
local
repository
and
still
know
that
the
official
images
and
still
use
signatures
and
is
like
well
you're
not
going
to
be
able
to
do
that
then,
and
so
there
were
all
these
kinds
of
issues
as
well,
so
so
those
for
example,
no
standard.
You
know
way
of
fusing
notary
in
kubernetes.
You
know,
there's
a
bunch
of
admission
controllers
that
have
their
own
kind
of
opinions,
but
it's
not.
You
know.
A
We
once
gets
a
stage
where
this
is
just
integrated
and
everyone
can
just
use
it.
And
it's
easy
and
you
know
it's
it's
obvious
where
you
get
your
keys
from
how
you
get
your
keys,
where
you
put
your
keys,
what
you
have
to
check
and
what
you
know,
what
the
what
the
model
is
and
maybe
and
the
kind
of
observability
of
things
like
I'm,
it's
really
hard
to
know.
What's
going
on,
because
for
some
reason
we
you
can
easily
inspect
the
metadata
or
ways
it's
kind
of
annoyingly.
A
A
We
can't
check
anything
but
yeah,
so
there's
lots
of
little
pieces
of
those
kinds
of
usability
pieces
and
just
standardization
that
we
need
to
do.
I
have
created
a
notary,
v2
channel
in
the
CN
CF
slack.
As
of
this
morning,
we've
got
a
doc
where
there
will
be
some
meeting
scheduled
we're
planning
some
more
meetings
soon,
with
probably
in
Seattle
around
the
12
of
December.
As
the
current
plan
with.
A
You
can
ping
me
that
I'm
just
in
Comicon
every
every
possible
thing
if
you've
got
questions
you
can
find
me
on
on
all
the
slacks
and
the
universe
and
I
think
you've
come
to
the
talk.
I
hope
you
enjoyed
it
and
I'm
sure
you've
all
got
questions.
If
I
can't
answer
your
questions
now,
I
happy
to
answer
them
just
drop
me
an
email
slack
whatever
at
any
other
point.
B
C
So,
looking
at
this
dr.,
Condon,
frost
notary,
like
next
generation,
something
that
always
annoyed
me
is
that
there's
some
there's
nothing
similar
to
like
HSTs
preload
of
images
that
you
know
are
signed
and
should
be
signed,
and
you
should
enable
content,
trust
for
those,
and
you
could
bake
that
into
the
client,
maybe
and
have
a
like
higher
degree
of
assurance
of
like,
for
example,
the
library
images
that
are
probably
going
to
be
signed.
Always
yeah.
A
That's
actually
yeah,
that
is
gonna,
do
because
I
mean
we
definitely
won.
You
know
the
doctor,
library
images
are
always
signed,
and
you
know
that
was
the
thing
that
we
wanted
to
do
to
turn
on.
First
was
enforcing
that
they
should
always
be
signed,
and
so
yeah
I
think
yeah,
including
image
metadata
says
that
you
should
have
checked
the
signature
for
this
at
this
point
would
be
yeah.
It
would
definitely
make
sense
yet
yeah
all.
D
D
A
lot
of
learning
experiences
happened
yeah
during
the
process,
and
one
thing
that
we
can
take
offline
if
it's
more
detailed
but
I
definitely
be
curious
to
talk
more
about
the
movement
from
having
lots
of
root
keys
to
having
a
single
root.
Key
I,
wonder
if
you
can
talk
about
that,
and
also
let
me
just
prompt
this
by
saying:
have
you
thought
about
doing
you
know
using
the
top
level
targets
role
in
the
same
way
that
you're
planning
on
using
this
new
single
root
role.
A
Yes,
I
mean
that
was
the
kind
of
the
point,
so
you
would
yeah
you
yeah
I
think
it
was
just
that
the
you
know
the
things
like
Daka
library,
taka
daka,
like
the
official
images
we
that
that
should
be
one
thing
with
one's
one
targets,
role
and
one.
You
know
this
is
something
that
you
know
we
we
maintain
all
of
these
images.
There
are.
There
are
thing:
it's
we
own
this.
You
know
we
own
that
thing.
We
guarantee
them
all.
A
We
Karen
see
them
all
equally
and
that,
yes,
absolutely
at
the
moment
they
were
all
just
totally
independent
in
the
lives,
an
independent
life
which
is
kind
of
stupid,
because
they're
they're,
just
they
are
a
chunk
of
things
that
you
would
like
you
would
want
to
mirror
together.
Do
you
want
to
you
might
want
to
you
know
you
you
want
to
you
know
we
want
them
to
be
available
on.
You
know
in
different
registries
and
being
able
to
check
the
signatures
on
them.
E
One
issue
that
we've
encountered,
at
least
in
the
darker
content
trust
model,
was
you're
dependent
on
the
content,
digest
that
the
registry
is
gonna,
give
you
for
an
image
that
is
not
necessarily
consistent
across
multiple
registry
implementations.
So,
even
if
you
have
the
same
content
itself,
multiple
registers
will
give
them
multiple
digests
for
the
same
content,
which
in
turn
will
result
in
multiple
signatures
that
no
II
wolves
have.
A
You
could,
basically,
just
if
you
created
a
collision
with
something
like
you
know
the
layers
of
a
bun,
so
you
could
just
you,
could
just
replace
them
with
any
content
because
it
wasn't
actually
kinda
address.
So
they
are
supposed
to
be
kind
of.
I.
Think
is
that
it's
mainly
a
I
mean
that
on
a
direct,
probably
the
person
to
answer
this
question
better
but
I,
really
they
supposed
to
be
content
addressed
and
and.
F
So
so
v-22s
fix
that
I
mean
the
the
and
also
the
content
itself
that
you're
pushing
is
content
addressable.
The
only
other
issue,
sometimes
that
you'll
see
that
the
digest
look
like
they
don't
match
from
registry
to
registry
is
unfortunately,
some
of
the
semantics
around
whether
you're
dealing
with
and
manifest
itself
and
the
digest
of
that
manifest
or
of
the
manifest
list
that
it's
pointing
to
so
sometimes
yeah
passes
right
through
some
of
those
things.
F
So
sometimes
you
could
actually
sign
the
manifest
list,
even
though,
when
you
actually
pull
something,
it
pulls
straight
through
that
top-level
manifest,
and
you
get
like
just
the
amd64
image
and
you're
now,
looking
at
the
digest,
yeah
and
those
don't
line
up,
but
they're
still
content
addressable.
Yes,.
A
A
A
G
G
A
I
think
I
think
yeah
I
mean
again
a
lot
of
it
comes
down
to.
We
didn't
realize
at
the
beginning,
how
important
this
whole
kind,
immutability
and
hashing
and
statics
that
virtually
was,
and
it's
kind
of
you
know
it
is
really
important
that
we
fix
these
things
across
the
universe
of
clients
and
things
over
time,
because
it
it
does
just
make
things
just
annoyingly,
broken
and
yeah.
A
There's
other
things
like
yeah,
just
kind
of
making
sure
that
you
can
kind
of
you
know
the
things
do
round-trip
properly
with
push
and
pull
and
there's
things
like
that,
so
yeah,
yeah
I,
definitely
has
been
frustrating
and
I
know.
You've
had
have
had
a
lot
of
issues
with
it
and-
and
it's
not
very
well
now-
this
does
very
well
documented,
it's
kind
of
and-
and
you
don't
actually
realize
that
some
you
know
the
some
registries
have
different
support
for
things,
because
there's
no
kind
of
from
you
know,
there's
there's
no
achieved
very
little.