►
From YouTube: Notary v2 Outstanding Issues Working Session - Justin Cormack, Docker & Steve Lasker, Microsoft
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Notary v2 Outstanding Issues Working Session - Justin Cormack, Docker & Steve Lasker, Microsoft
The Notary v2 project is a rework of the infrastructure for container signing, supporting additional OCI Artifacts, such as Helm, Singularity and CNAB, and fixing usability and other issues. This session examines the current state of the project, discussing the design decisions as they relate to the target scenarios. This session is a working session to engage face to face discussions for all participants.
https://sched.co/Zexw
A
Hello,
this
is
well.
This
is
it's
the
notary,
v2
working
session.
Unfortunately,
due
to
the
difficulties
of
recording
and
live
everything,
we've
had
to
do
the
work
for
you,
but
we'll
be
doing
some
sessions
shortly
anyway.
So
do
come
along,
but
this
is
a
summary
of
the
work
in
progress
for
natural
ev2.
B
Hi,
I'm
steve
laskar
I'm
a
pm
architect
on
azure
container
registry.
I
work
on
things
like
you
know:
tob
for
oci
and
registry
work
like
oci,
artifacts
and
auras,
and
one
of
the
things
I
really
enjoy
is
just
the
whole
end
and
workflows
from
registries
for
dev
to
deployment
where
registries
play
a
key
part
of
that.
So
we've
been
engaged
in
this
notary
v2
thing
for
a
while
and
we're
excited
to
share
our
progress.
A
So
what
is
notre
v2
about,
though,
if
you
missed,
if
you
really
want
it
from
the
beginning,
we
had
an
intro
session,
but
you
could,
which
you
can
all
say
what
shall
attend,
but
the
key
things
that
we're
looking
for
in
notary
v2
that
we're
kind
of
missing
from
the
existing
nursery
v1
version,
first
of
all,
registry
native.
What
we
really
mean
by
that
was
that
notary
v1
was
actually
implemented
as
a
database
that
you
and
application
that
you
run
on
the
side
of
a
registry.
A
But
that's
because
there's
all
sorts
of
issues
it
turned
out
over
the
five
years,
or
so
we've
been
running
it
because
it's
not
a
native
part
of
the
registry,
and
it
doesn't
it's
not
part
of
the
registry
protocols
and
signatures
and
artifacts
are
not
actually
registry
objects,
and
that
makes
a
lot
of
things
more
difficult.
So
we
really
want
everything
to
be
natively
part
of
the
registry
security.
A
There's
a
bunch
of
security,
things
that
were
not
ideal
with
v1
trust
on
first
use
was
one
that
was
particularly
problematic
for
ephemeral,
ephemeral
servers,
trusting
things
the
first
time
they
call
them
well.
The
first
time
is
the
only
time,
and
so
it
doesn't
really
give
you
much
guarantees,
but
there's
other
other
security
guarantees.
We
want
to
add
as
well
portability.
A
We
want
as
part
of
being
registered
native.
We
want
every
registry
to
support
notary
and
we
want
to
be
able
to
move
artifacts
around,
which
was
not
a
design
criteria
at
all
for
notary
v1,
because
at
the
time
there
weren't
a
lot
of
registries,
and
there
wasn't
really
that
kind
of
registry
multi-registry
workflow
that
was
we've
seen
in
the
last
five
years.
Building
up
this
is
kind
of
multi-tenant
project
for
lots
of
people
run
very
large
registries
for
lots
of
users.
Some
people
run
private
registers
themselves,
but
they're
that
they're
often
multi-tenant
use
cases.
A
A
B
A
So
there's
a
bunch
of
requirements,
so
we've
spent
a
lot
of
time
working
on
requirements.
This
is
just
a
very
short
summary
of
them.
Really
there's
lots
more
in
the
in
the
repo.
So
what
some
of
the
things
that
you
know
we
want
is
support
for
offline
signatures.
We
want
support
for
multiple
signatures.
A
People
want
their
keys
to
be
secured
in
external
places,
like
cloud
providers
key
vaults,
notre
v1
has
ub
key
support,
but
not
it
wasn't
designed
for
widespread
use
of
external
key
storage
and
it
should
work.
You
know
whatever
kind
of
user.
You
are
whether
you're
a
hobbyist
or
an
open
source
project
or
a
large
vendor
or
anything
so
different.
You.
B
A
A
B
I
mean
just
from
cloud
vendors
that
we
want
you'd,
be
able
to
spin
up
containers
super
fast
and
the
idea
is.
We
have
compute
that's
sitting
there
waiting
for
all
customers
and
when
we
hand
it
to
you,
you
know,
like
justin,
gets
an
instance
to
run
his
container.
There's
nothing
on
it.
Yet
so
he's
got
no
previous
state
on
it
and
that's
what
we
kind
of
mean
by
the
ephemeral
clients.
Is
you
get
a
something
given
to
you?
You
use
it.
You
toss
it
and
there's
no
state
restored
from
a
previous
point,
but.
A
B
So
we
were
trying
to
put
together
a
workflow
that
we
would
be
able
to
communicate
and
we'll
spend
a
couple
of
slides
here
just
talking
about
the
communication
model,
because
when
you
have
so
many
people
working
on
something
that
has
been
the
the
core
effort,
so
we
have
this
example.
We
have
the
wabit
networks
and
company
and
they're
putting
together
a
network
monitor
software.
B
They
build
it
off
on
their
own
they've
got
their
own.
Build
environment,
doesn't
really
matter
whether
it's
in
a
cloud
or
not
point
is
they
have
a
build
environment,
they're,
generating
an
image,
their
network
monitor
software.
They
have
a
bill
of
materials
that
says
what's
in
it,
they
might
even
have
some
source
for
some
open
source
projects
for
gpl
licensing
requirements
and
so
forth
and
they'll
bundle
all
that.
B
So
when
they
put
these
things
together,
like
a
bill
of
materials
and
all
these
things
are
only
if
as
good,
if
you
can
trust
them,
so
we
want
to
make
sure
that
the
wabit
networks
can
sign
it
with
their
key,
so
they
now
have
their
software.
All
those
individual
artifacts
are
signed
and
the
index
is
signed
and
then
for
discoverability.
They
want
to
be
able
to
push
it
to
a
well-known
location
like
docker
hub
now
as
soon
as
you
push
it
to
docker
hub,
we
want
to
make
sure
those
keys
can
go
with
it.
B
This
is
the
transportability
thing
that
we
were
talking
about
so
now.
Wabbit
networks
has
got
some
content
up
on
docker
hub,
but
they're
kind
of
in
the
community
space.
We
don't
really
know
if
they're,
good
or
bad
or
evil
or
just
some
random
person.
They
have
a
key
okay,
but
don't
really
know
about
them.
So
what
we
want
to
be
able
to
do
is
support
scenarios
where
we
could
add
another
key
for
some
trust,
so
docker
hub
might
want
to
say.
B
I
want
certified
content
and
you
can
do
that
more
than
just
a
badge
on
the
the
page.
We
could
actually
have
it
signed
by
docker,
io
and
saying
all
right.
This
now
has
a
secondary
key.
So
if
a
company
like
acme
rockets
over
here
has
a
policy
that
you
could
only
bring
content
certified
content
from
docker
hub,
then
they
can
now
pull
that
and
they
might
be
blocked
by
pulling
it
when
wabbit
networks
wasn't
certified
as
they
get
to
you
know,
know
and
trust,
wabbit
networks
and
other
software.
They
might
trust
those
keys
as
well.
B
So
those
are
the
kind
of
things
we're
thinking
about,
but
now,
as
with
any
best
practice,
I
want
to
bring
that
network
monitor
software
into
the
acme
rockets
environment,
because
we
don't
want
to
you
know,
deploy
production
stuff
from
public
points
of
interest.
It's
not
just
a
matter
of
whether
you
know
docker
hub
is
up
or
the
dns
is
still
working
or
any
of
that,
even
in
the
best
case
scenarios.
If
wabit
networks
is
publishing
a
security
fix
which
is
still
from
them,
that
doesn't
necessarily
mean
it's
going
to
work
in
my
environment.
B
They
might
have
done
something
around
doing
security.
Patching
that
affects
how
the
software
would
run
in
my
environment.
It
might
fail,
so
we
always
want
to
have
a
certification
process
for
any
content.
We
depend
on
and
I
might
so.
In
that
case
I
would
actually
have
an
acme
rockets
key
or
a
signature
assigned
to
that
content.
So
now
I
know
that
I
only
trust
stuff
from
docker
hub
or
wabit
networks,
but
I'm
only
going
to
deploy
stuff
that
has
been
verified
and
proven
verified
by
an
acme
rockets
key.
B
I
might
have
a
deploy
artifact
that
I'm
also
signing
keep
track
of
what
I'm
deploying
and
then
you
would
have
something
like
a
policy
management
infrastructure
like
open
policy
agent,
and
the
idea
here
is
that
we
have
signatures
that
attest
to
what
it
is,
but
we're
not
stating
anything
about
policy
we're
not
stating
it
has
to
be
signed
by
three
entities
or
anything.
What
we're
saying
is
that's
more
of
the
policy
management,
software's
responsibility
and
it
can
take
that
content
and
say
all
right.
B
B
B
But
what
we're
seeing
more
and
more
is
customers
that
have
been
on
prom,
on-prem
and
reluctant,
maybe
to
go
to
the
cloud
because
they
always
have
their
private
and
ip
environment
that
we
can
provide
that
in
the
cloud
they
still
get
a
private
network,
so
they
have
more
trust
around
it
and
there
literally
is
not
no
public
endpoints
on
inside
of
those
environments
or
the
public.
Endpoints
are
very
tightly
controlled.
B
So
prototyping
things
is
the
interesting
one.
So
there's
as
with
any
of
these
complex
systems,
we're
trying
to
figure
out
how
do
we
communicate
amongst
ourselves,
because
we
want
to
enlist
experts,
there's
no
one
person
that
actually
understands
all
these
pieces
together.
So
how
do
we
establish
this
model
for
communication
to
bring
people
in
and.
A
B
So
if
I
said
we
as
everybody
watching
this,
we
want
to
build
a
house
together.
What
does
that
mean
to
you
like?
Clearly,
that's
not
the
extent
of
the
house,
and
I
guess
it's
close
to
an
a-frame,
but
you
know
if
everybody's
trying
to
picture
that
house
that
we're
going
to
build
what
is
your
you
know
bias.
What
is
your
background?
What
is
the
the
experiences
that
you've
had
that
make
you
think
about?
What
is
this
house
going
to
look
like,
and
you
know
I
can
write
words
down
right.
B
B
We
all
go
watch
the
same
movie
and
we're
being
told
what
to
think
and
see.
We
might
not
all
like
to
say
movie,
but
we
kind
of
all
saw
it
the
same
way.
So
that's
the
next
piece
that
we
wanted
to
iterate
on.
So
if
I
drew
this,
you
know
have
this
bathroom
drawn
up
and
it's
clearly
it's
got
two
sinks.
It's
got
the
separate
part
for
the
toilet,
it's
got,
you
know
a
big
shower
and
tub
and
the
doors
and
everything
and
like
we're,
ready
to
go
and.
A
B
Would
I
end
the
day
right,
it's
like
in
the
u.s.
We
don't
think
about
that
now.
Maybe
we
should,
at
the
whole
toilet
paper
covered
thing.
So
there's
definitely
some
learnings
here.
Isn't
it
to
think
about,
but
like
okay,
so
we
out
of
the
day
now
we
can
see
that
if
we
try
to
add
it
later,
it
really
doesn't
fit.
We
lost
our
door.
The
shower's
like
this
weird
closet.
Now
so
the
point
is
we
want
this
iterative
approach.
B
We
want
to
make
sure
that
we
can
bring
all
the
subject
matter.
Experts
in
I,
you
know
you're
one
of
our
key
masters
right.
You
know
all
of
our
security
work.
We've
got
neos
from
aws,
that's
been
awesome,
for
you
know,
thinking
about
key
management.
We've
got
the
the
notary,
folks
they're,
the
tough
folks
that
have
been
working
on
all
of
the
update
semantics
and
we
each
have
our
perspectives,
but
it's
really
hard
to
communicate
with
each
other.
You
know
without
sketching
these
things
out
turns
out.
Sketching,
isn't
just
enough.
B
B
But
there
was
just
really
massive
structures
and
anthony
gowdy
was
had
a
different
vision
for
what
he
wanted
to
see
and
he
couldn't
really
figure
out
how
to
communicate
that
vision
very
well
or
figure
out
how
to
build
it.
Quite
frankly,
so
he'd
make
sketches
and
you'd
look
at
going.
That's
awesome,
but
I
don't
know
how
to
how
we're
going
to
pull
it
off.
It's
like
going
to
collapse
on
itself
or
it'll,
just
be
so
bulky,
so
he
started
doing
modeling.
B
He
took
his
sketches
and
he
was
building
models
and
prototypes,
and
this
one
is
really
interesting.
So
when
we
can
all
travel
again
or
search
online,
if
you
go
to
the
scrota
familia,
that
you'll
see
that
this
is
actually
strings
that
are
hung
from
the
ceiling
with
little
shot
pellets
that
are
in
these
little
canvas
bags
that
help
shape
the
formation
that
becomes
the
pillars
that
holds
up
the
church,
that's
kind
of
familiar,
and
he
did
a
lot
of
these
iterations.
B
If
you
just
look
up
gowdy
models,
you'll
just
see
the
amazing
things
that
he
put
together
and
that
was
able
to
facilitate
all
the
different
trades
to
figure
out.
Where
are
they
going
to
put
the
lighting?
Where
are
they
going
to
put
the
gas
pipes
or
whatever
they
use
for
electricity
back
120
years
ago?
They
didn't
have.
B
I
can
put
the
pipes
here
because
the
things
are
not
there
and
so
forth,
and
you
know
it's
just
an
absolutely
amazing
sculpture
and
you
can
just
see
the
pillars
and
the
way
they
look
like
trees
and
so
forth.
So
the
point
here
is
not
just
to
appreciate
auntie
gowdy,
but
it's
that
you
know
communicate,
write
things
down
sketch
prototype
and
throw
it
out
and
start
over
again
is
the
approach
we've
been
taking
with
this
project.
A
So
we've
we're
in
this
prototyping
phase
at
the
moment,
so
prototype
one
kind
of
is
really
c
is
going
to
talk
about
in
a
second,
but
that's
a
kind
of
exercise
in
generic
signing
of
content
in
a
registry
context.
How
that
would
involve?
How
can
you
copy
signatures,
the
air
gap,
issues
we're
going
to
look
at
key
management
issues
and
what
kind
of
persistence
and
retrieval
there
is
for
for
signatures?
Are
they
separate,
artifacts
or
the
same
or
part
of
the
same
artifact?
A
B
A
The
signature
in
a
registry
and
then
that's
going
to
lead
into
in
parallel
we're
going
through
working
on
a
lot
of
design
decisions
and
then
registers
nearly
registered
a
bunch
of
other
prototyping,
so
prototyping.
What
tough
looks
like
in
a
registry
looking
at
the
issues
around
rollback
in
a
registry
context
and
ephemeral,
clients
we'll
talk
about
in
a
few
in
a
few.
B
Minutes
so
as
part
of
building
this
prototype
and
doing
this
iterative
model,
we
you
know
we
want
to
carve
out
what
we
really
want
to.
You
know
chew
on
right
now
and
what
we're
going
to
defer.
So
we've
got
a
prototype
for
an
nv2
client
and
all
it
does
is
sign
and
verify
it
actually
doesn't
even
know
about
a
registry.
It
just
knows
how
to
sign,
content
and
verify
that
content
related
to
that
key.
B
So
we've
started
with
x509
certs
and
justin
will
talk
a
little
bit
more
around.
You
know
how
we
want
to
expand
the
type
of
keys
that
we
supported
key
signing,
but
what
was
interesting
about
this
is
sheeway
who's
been
working
on
this
part
of
it.
You
know
if
we
use
the
bathroom
analogy
again.
You
know
he
created
some
artwork
on
the
wall
in
this
bathroom
that
we
weren't
really
expecting
and
we're
kind
of
all
grocking
it
now.
So,
let's
kind
of
take
a
look
at
what
this
all
happens,
so
we
take
an
ssl.
B
B
So
we
build
an
image,
we're
tagging
it
with
the
registry,
the
source
registry.
Now
this
is
where
to
support
offline
scenarios.
We
needed
a
manifest
locally
manifesto,
typically
generated
as
part
of
a
push
operation,
and
you
can
get
it
from
the
registry.
So
here
we
actually,
she
always
built
this
generate
manifest
tool
that
you
can.
You
know,
get
it
manifest
locally
and
you
just
pass
it
the
name
of
the
image
and
you
say,
output
it
to
this
net,
monitor
json
file.
B
B
I
give
it
the
wabit
networks,
key
and
the
registry
that
I
want
to
tag
this
thing
associated
with
and
I
pass
it
in
the
net
monitor
v1
manifest
json
file,
because
that's
what
it's
going
to
sign
and
then
the
signature
object
it
generates
is
the
netmonitor.signature.json
okay,
so
you
got
the
docker
build
generator
manifest
and
then
I'm
going
to
sign
it
so
that
net
monitor
signature,
json
object.
What
we
have
here
is
the
top
part
is
the
references
to
the
certificate.
B
You
know
the
expiration
not
before,
and
I
always
forget
what
I
t
stands
for
then.
What
we
have
is,
it's
called
an
oci
descriptor.
What
this
says
is
I
am
signing
this
artifact,
that's
in
the
registry.
It
has
a
media
type
for
the,
whether
it's
an
index
or
manifest
manifest
list
or
index
sorry
manifest
list
or
manifest.
So
this
is
representing
ocr
manifest.
B
It
has
the
digest
that
digest
is
the
digest
of
that
manifest
and
the
size.
Those
three
parts
are
referred
to
as
an
ocean
descriptor
and
then
here's
the
interesting
part
that
we're
playing
with
is
their
certificate
has
to
match
the
registry.
If
you
put
it
in
here
and
it's
only
for
assigning,
it
just
means
that
I
can't
use
the
a
different
key
just
as
x,
5
and
9
key
to
sign
a
different
registry
url.
At
that
point,
the
output
of
that
is
the
bottom
section
that
that
is
the
actual
signature.
B
So
this
is
the
basically
the
config
object
that
we
will
or
the
signature
object,
that
we've
generated
and
you'll
see.
We
have
lots
of
conversations
around
the
formatting
of
the
white
space,
no
white
space,
canonical
and
so
forth,
but
that's
one
of
the
debates
we're
having
so
now.
If
I've
got
that
file,
I
can
push
it
to
a
registry
as
a
notary,
v2
artifact.
B
B
B
A
A
Actually,
one
of
the
interesting
things
about
notre
dame
v1
is
that
it
give
you
could
choose
to
use
x509
or
kind
of
ad
hoc
case,
and
that
was
actually
kind
of
giving
people.
A
choice
was
actually
kind
of
weird,
because
it
meant
that
some
there
was
functionality
that
you
could
do
with
x509
like
see
who
had
signed
an
image
much
more
easily,
but
you
couldn't
rely
on
that
functionality
being
there,
because
some
people
didn't
use
x509.
So
it
was
a
kind
of
mixed
bag.
A
I
think,
like
some
of
the
functionality
was
quite
nice,
but
no
one
ever
liked
to
rely
on
it,
because
x,
509
keys
are
really
mostly
used
for
signatures,
as
opposed
to
for
tls
in
the
us
government,
and
a
few
other
large
organizations
they're
not
widely
used
elsewhere,
and
unfortunately,
you
can't
use
the
let's
encrypt
for
signing
a
normal
object
for
for
reasons
that
won't
talk
about
now.
But
it
does
give
this
useful,
potentially
useful
binding,
but
maybe
between
the
the
name
and
the
what
you're
signing
for,
but
maybe
there
are
other
means
we
can
use.
A
B
A
Probably
the
most
likely
option,
but
we're
anyway
we're
still
going
through
the
kind
of
options
there.
Definitely
we
know
we
want
to
be
able
to
manage.
You
know
keys
with
existing
tools,
particularly
hardware
security,
so
things
like
cloud
keys
or
stores
or
vault
or
parsec,
project
or
yubikeys,
which
I
have
noticed.
V1
had
support
for
so
there's
a
bunch
of
things
we
do
know
and
there's
a
bunch
of
things
that
you
know
we're
still
experimenting
with
there.
B
And
part
of
this
is
coming
because
you
know
like
we
showed
the
bathroom
and
it
you
know
with
the
bidet
conversation
or
the
multiple
keys.
You
know
it's
like
one
of
the
things
we're
debating
is
should
we
support
multiple
keys,
because
we
want
the
hobbyist
to
not
have
to
pay
anything
and
super
simple
and
have
maybe
the
appropriate
level
of
trust
associated
with
that,
where
larger
software
vendors,
where
it's
or
maybe
it's
a
more
critical
workload
or
even
a
company
that
wants
to
have
you,
know
their
certificate
more
trusted.
There's
that
realm
as
well.
A
A
If
we
use
external
signature
objects
rather
than
tough
signature
objects,
it's
tough
signatures
are
in
line.
If
we're
standardizing
on
external
signatures
in
the
registry,
then
that
makes
little
differences
to
the
layout.
I
mean
this
is
fine
as
long
as
it
it
maps
and
it
preserves
the
security
properties.
I
mean
tough
does
say
that
these
are
examples
and
not
required,
but
we
need
to
do
an
exact
mapping.
A
You
know
there
are.
There
are
a
bunch
of
options,
but
we
need
these
it
to
be
aci
structured
with
at
least
to
some
extent,
with
the
ocr
structure.
Because
that's
how
registers
do
garbage
collection?
We
don't
want
signatures
to
be
or
tough
metadata
to
be
garbage
collected
so
and
or
images
that
are
pointed
to
from.
B
A
Well,
yeah
eventually,
but
we
want
them
to
be
managed
in
the
normal
workflow
of
the
registry
and
then
there's
some
other
questions
about
putting
toughness
registry
that
we've
discussed
a
bit.
So
notary
v1
made
a
tough
repository
equal
to
a
registry
repository
I.e.
You
know
so
docker
hub,
slash,
justin,
cormac,
slash
my
program.
That
would
be
one
tough
repo
that
meant
they
were
a
huge
number
of
keys.
A
The
tough
team
think
that
the
whole
registry
is
the
right
scope,
but
I
don't
think
we've
we
haven't
convinced
the
registry
operators
that
that's
not
too
large
escape.
So
maybe
the
answer
is
in
between
it's
the
org
scope
or
anyway.
So
there's
still
some
work
there,
but
that
affects
things
like
how
delegations
work
and
there's
a
whole
a
lot
of
complex
issues
around
discoverability
of
information
about
signed
objects
and
things
that
also
affect
the
design.
So
it's
a
complicated
thing
that
we,
so
we
need
to
make
some
more
progress
on
that.
A
More
design
work
that
we're
having
an
ongoing
discussion
about
rollback
protection,
which
is
a
really
interesting
subject.
I'm
I'm
writing
some
blog
posts
on
this
at
the
minute
to
just
kind
of
sort
out
my
thinking
about
this,
but
this
is
and
there's
a
bunch
of
articles
that
justin
capos
has
written
on
this.
So
there's
a
problem
with
the
tough
models.
A
Kind
of
assumes
that
you
have
a
persistent
history
again
of
of
what's
been
going
on
and
then
so
someone
can't
come
along
and
you
know
just
say:
oh
no,
there
haven't
been
any
updates
for
the
last
three
years.
The
latest
version
is
the
one
from
three
years
ago
you
should
use
that
which
is
still
signed
by.
A
You
know
the
client
and
tell
it,
and
it's
basically
telling
that
where
the
state
of
the
world
was
when
it
was
created,
but
that's
more
work,
we've
also
been
looking
at
the
kind
of
there's
a
relation
between
transparency
logs,
which
are
kind
of
used
for
public
attestation
of
tls
keys,
and
this
is
sets
and
things
like
that
and
there's
a
very
interesting
relation
between
those
and
the
kind
of
the
rollback
protection,
but
it's
complicated
and
we're
still
working
on
that.
You
know.
I
think
this.
B
B
You
know
I
want
but
node
nine
and
when
there's
a
new
security
update
to
node
nine,
I
wanna
get
that
without
having
to
change
my
docker
file
to
reference
a
new
tag.
So
we
definitely
have
these
kind
of
semantics.
It's
just
it's
kind
of.
Where
is
it
in
the
priority
list
and
where
do
we
carve
off
and
we
need
to
solve
the
the
complexity
and
the
the
reliability
of
the
of
this?
This.
A
A
A
But
we
we
one
of
the
design
criteria
of
this
project-
is
we're
not
trying
to
change
what
people
do
we're
trying
to
make
what
they
do
secure,
because
changing
this
kind
of
thing
is
hard
and
if
you
tell
people
they
have
to
change
before
they're
secure
they're
quite
likely
to
just
not
change
and
carry
on
being
insecure.
So
we
we.
A
A
This
kind
of
thing
you
know
that
we
we're
discouraging
use
of
latest
and
and
we
and
people
want
immutable
tags,
but
actually
most
of
the
most
of
the
immutable
tags
are
mainly
for
historical
interest
and
you
shouldn't
actually
be
running
them
right
now,
because
they're
they
are
old.
So
you
know
I
actually
I've
been
thinking
about
this
quite
a
lot
recently.
I
think
we
did
make
some.
A
Well,
you
know
these
things.
Have
you
know
these
things
have
been
around
for
a
long
time
and
there
are
some
right
things
about
them
and
and
some
you
know,
I
think
we
need
to
tweak
them
a
little
bit.
But
it's
you
know.
These
things
are
kind
of.
The
usage
is
a
kind
of
in
in
the
sort
of
fabric
of
how
people
use
things
now,
and
it's
definitely
going
to
be
a
challenge
to
change
them.
A
So
we're
building
this
thing:
it's
not
going
to
take
as
long
as
cigar
familia
we're.
Actually
you
know
shipping
things
quite
fast.
Now,
we've
got.
You
know
we're
next
to
kubecon
we're
going
to
have
prototype
in
the
state
that
everyone
can
really
play
with
it
and
get
their
hands
on
it
before
we
shift
it
into
production,
so
come
and
join
us.
The
details
are
on
the
next
slide
yep.