►
From YouTube: OCI Weekly Discussion - 2020-07-29
Description
Recording of the weekly meeting of the OCI from Wednesday, 2020-07-29. Notes and agenda here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg#July-29-2020
B
A
A
A
C
So
I
put
some
links
in
the
hack
nd,
but
this
is
we
took
we
took
what's
in
the
rewrite
and
put
it
into.
We
created
a
fork
of
the
new
oci
site
and
added
a
specs
menu,
and
this
is
live.
You
can
go
to
it
now
and
check
it
out,
but
here's
like
the
new
layout
of
the
spec
table
of
contents
really
try
to
remove
a
lot
of
stuff
and
make
it
more
succinct
and
have
just
as
much
information
as
we
need
if
we
want
to
add
more
information
later
after
1.0.
C
So
here's
how
to
push
a
blob
at
a
manifest
there's
several
different
ways
to
do
it,
and
each
of
these
has
these
endpoints
and
we
have
identifiers
for
each
of
these
endpoints
now
in
a
table.
So
if
you
click
on
this
it'll,
take
you
down
to
this
table
of
endpoints
you
can
see.
4B
is
the
post
to
the
blob,
upload
endpoint
and
then
we've
updated
the
accepted
failure
codes
to
allow
for
what
most
registries
were
doing.
C
C
We
changed
the
language
to
say
that
if
there
is
a
response
body
in
json
format
that
it
must
adhere
to
this
error
code
section,
but
many
registries
are
just
returning
a
400
status,
antibody
and
things
like
that.
But
we
say
if
you
do
use
this
format.
These
are
the
actual
code
must
be
one
of
these
values.
C
So
I'm
wondering
what
people's
thoughts
are
on
that,
but
just
to
close
up
yeah,
if
you,
if
you're
interested
in
like
getting
you
know
you
like
how
this
looks
and
want
this
to
get
in,
we
have
a
number
of
open
pull
requests
that
are
under
number
tracked
under
number
163,
and
these
are
just
each
of
these
updates
as
miniature
updates
built
on
top
of
the
last
one.
So
it's
a
lot
easier
to
review
each
of
these
individually.
A
C
A
So
this
is
kind
of
in
the
subject
of
the
refactoring,
so
you're
kind
of
focused
on
the
formatting
of
the
doc,
without
refactoring
content
per
where
content
lives.
It's
just
the
format
of
the
content,
so
you're
kind
of
keying
into
we're
using
the
manifest
and
the
manifest
list
as
things
that
can
contain
an
image.
But
they
can
contain
things
that
aren't
an
oci
image
as
well
and
that's
that's
kind
of
what
you're
getting
at.
C
I
yeah
I
I
guess
so.
We
started
by
writing
the
conformance
tests
a
few
months
ago
and
we're
building
the
spec
based
on
what
we're,
testing
and
we're
testing
for
a
certain
format
of
the
manifest
that's
based
on
the
image.
Spec
go
libraries,
I
believe
peter.
I
don't
know
if
you're,
if
you
can
verify,
but
that
yeah,
so
I'm
I
just.
I
know
there
was
a
discussion
with
the
distribution
spec
maintainers
like
how
much
we
should
reference
that
spec,
but
I
think
it
sounds
right.
I
think
I
believe
to
be
fair.
D
Guys,
the
intention
of
the
distribution
spec
was
to
write,
implement
distribution
of
the
images
correct,
so
yeah
we
shouldn't
take,
make
it
upside
down
and
say:
no,
you
can't,
we
shouldn't
refer
to
it.
It's
it's
perfectly.
Fine,
though
also
to
say
you
know,
other
types
of
artifacts
will
also
be
supported
by
the
distribution
spec.
Thank.
C
D
No,
no,
I
would
just
say
it:
it's
not
that
yeah,
it
doesn't
say
you
can
only
use
oci.
You
know
image
references
it
just
it
just
you
know,
isolates
the
oci
declaration
so
that
you
can't
you
can't
use
it
for
something
else.
Besides
that
right,
it's
not
it's
not
saying
you
can't
add
additional
mind
types.
A
Because
I
don't-
or
maybe
it
goes
with
so
mike-
had
opened
up
a
good
or
my,
I
think
it
was
mike-
opened
up
a
good
one
as
the
result
of
this
conversation
of
having
manifest
the
manifest
definition
and
the
manifest
list
definition
pulled
up
to
another
repo.
So
it
can
be
referenced
by
these
two
and
maybe
the
definition
of
a
digest
should
be
pulled
up
as
well.
C
So
well,
in
any
case
I
mean
this.
This
is
all
up
for
review,
so
your
comments
in
writing
would
be
much
appreciated,
but
I
mean
just
just
to
you
know,
for
example,
in
the
image
spec,
it's
talking
about,
digest,
doing
different
types
of
shas,
not
just
256,
which
I
believe
we
aren't.
You
know
docker
distribution,
I
think,
expects
sha-256,
but
I
think
it's
designed
in
a
way
it
could
allow
different
types
of
digests.
C
Yeah,
so
that's
pretty
much
it
just
a
summary,
so
just
working
on
pushing
this
all
through.
If
you
have
comments
on
the
general
approach
to
this,
we
are,
you
know,
attempting
to
rip
out
a
lot
of
language
from
the
existing
spec
just
to
make
it
a
lot
easier
to
consume.
So
if
you
see
value
in
certain
parts
that
have
been
taken
out,
all
ears
to
you
know
reverse
that.
A
C
A
A
A
A
Artifact
support,
oc
artifact
support
there,
whereas
in
notary
v1,
it's
this
whole
additional
service
that
you
have
to
run
and
it's
pretty
heavy
weight
for
an
operator
run,
and
it
has
a
bunch
of
issues
associated
with
tags
exist
in
both
places.
There's
two
different
databases:
there's
a
whole
bunch
of
details.
There's
actually
another
slide
that
I'll
go
through
in
that
detail.
A
We
certainly
want
to
have
things
be
secure
and
we're.
What
exactly
does
that
mean?
So
that's
been
an
interesting
conversation
as
well
as
what
we've
been
scoping
is
there's
an
attestation
to
its
authentic
authenticity.
It
came
from
I'm
staring
at
mike,
so
it
came
from
ibm.
It
came
from
red
hat,
it
came
from
docker
wherever
it
may
be,
or
actually
the
daca
one's
even
more
interesting
one.
A
Usability
was
a
big
problem.
I
actually
should
invert
this.
So
if
I'm
gonna
use
portability
as
one
of
the
biggest
problems
that
we
have,
if
you
find
some
certified
content
or
sign
content
on
docker
hub
or
if
you
take
software
from
microsoft
on
mcr
to
microsoft.com,
that's
our
the
registry.
We
serve
things
from.
A
You
should
be
able
to
run
microsoft,
software
that
you
got
from
mcr
or
any
software
you
got
from
docker
hub
in
your
private
registry.
It
doesn't
support
that,
so
we
needed
to
be
able.
We
need
to
be
able
to
support
portable
signature
movement
within
a
registry.
Would
you
promote
it
within
a
registry
or
across
registries?
A
So
if
you
can
get
past
that,
then
we
also
need
the
commands
to
be
simple
usable.
You
know
it
shouldn't
be
a
rocket
science
to
be
able
to
use
these
things.
Multi-Tenant.
I
use
the
mcr
in
the
docker
ones.
Scenario
is
obvious
ones.
We
want
to
make
sure
that
this
content
isn't
just
the
signature,
isn't
just
for
azure
that
doesn't
make
any
sense.
It
doesn't
make
any
sense
right
just
for
docker
or
aws.
A
We
need
to
make
sure
that,
as
you
get
content
sign
content
from
registry,
one
that
it
can
move
to
registry
two
and
I'll
have
an
animation
that
shows
that
part
of
that
is
an
on-prem
is
part
of
that,
as
well.
By
the
way
and
then
offline
in
air
gapped,
we
tend
to
refer
to
air
gap
as
these
like
really
esoteric
submarines
and
oil
platform
kind
of
things.
A
As
many
of
you
have
seen
the
we
have
customers
that,
like
they're
willing
to
move
to
the
cloud
if
they
can
get
the
same
kind
of
private
ipv
environments
that
they
have
on-prem,
so
we're
seeing
more
and
more
customers
going
there,
but
there
can't
be
any
public
internet
access
so
whether
it's
physically
air-gapped
and
and
some
of
the
more
constrained
environments
or
the
customer
makes
an
air
gap
inside
a
public
cloud.
We
have
to
be
able
to
support
those
kind
of
scenarios,
so
notary
v1
doesn't
need
it.
A
That's
okay,
like
we've
learned,
but
that's
what
we
want
to
solve
with
notary
v2.
So
if
we
look
and
by
all
means
folks
just
jump
in
and
interrupt,
if
you
have
questions,
that's
fine.
It's
helpful
to
get
that.
So
for
v2.
We
really
want
to
support
offline
signing
when
offline
signing
isn't
just
air
gapped
it's.
I
could
sign
something
in
a
secure
environment
that
has
no
connectivity
and
because
the
keys
might
be
so
secure
that
I
can't
actually
get
to
them
in
any
kind
of
outside
of
a
secure
environment.
A
We
need
to
be
able
to
support
multiple
signatures,
so
we'll
we'll
see
this
again
in
the
animation
will
make
a
little
more
sense,
something
that's
iterated
about
some
things.
I've
come
up
with
referred
to
as
ephemeral
clients
in
this
serverless
world.
We're
trying
to
get
to
the
point
where,
in
a
compute
environment
we
could
take
some
very
general
vanilla,
type
of
compute
thing.
That's
there
for
any
customer
and
say
mike.
A
This
is
now
yours,
you
own
it
for
the
for
the
life
of
that
thing,
running,
there's
no
previous
state
on
it
and
you
can
run
a
container
run.
It
fast
run
it
as
a
function,
get
it
securely
and
then
as
soon
as
you're
done
with
it,
that
is
released
back
to
the
ecosystem
and
you're
not
paying
for
anything.
So
we
really
can't
assume
that
there's
state
on
the
clients
we
talk
about
cross-cloud
air
gap
so
forth.
The
keys
that
we
want
to
be
able
to
use,
which
has
been
an
interesting
topic
as
well.
A
We
need
to
make
sure
that
every
cloud
provider
can
or
wherever
it
is
including
open
source
solutions,
can
have
a
key
vault
solution
that
it
retrieves
and
provides
the
management
of
those
keys,
and
then
the
last
one
that's
come
up
that
we've
been
having
some
conversations
on
recently
is:
what
does
it
mean
to
get
a
key?
What
kind
of
keys
do
we
support?
A
We
want
to
make
sure
that,
and
that
was
using
josh
as
an
example
when
he
was
building
auras.
He
shouldn't
need
to
spend
lots
of
money
or
do
something
big
to
be
able
to
get
a
key.
He
should
be
able
to
get
something
that
he
could
sign
this
content
with
and
be
acceptable,
and
it
needs
to
scale
all
the
way
up
to
the
large
vendors
that
might
use
you
know
x,
509
and
cas
and
so
forth.
So
we
want
to
make
sure
that
there's
no
barrier
to
entry
there
as
well.
F
F
A
Hope
others
digested
as
well,
so
the
workflow
that
we
want
to
be
able
to
support
is
we
have
this
webits
network
and
their
create
a
net
network
monitor
software.
They
have
their
own
build
environment,
they
have
their
own,
where
it
doesn't
matter
whether
it's
on-prem
or
some
cloud
doesn't
matter
they're
building
software.
They
happen
to
build
an
image,
that's
how
the
software
runs.
They
have
a
software
bill
of
materials,
they
associate
it
with
that
image.
So
it
has
everything.
That's
in
it.
A
I
want
to
sign
it
with
the
wabbit
networks
key
so
now
I
know
that
this
software
and
ignore
docker-
I
didn't
mean
to
bring
that
in
at
the
same
time,
so
docker's
not
there.
Yet
I
I've
signed
it
offline
in
my
environment
with
the
wabit
networks.
Key
and
now
you
can
see
that
content,
and
it's
got
some
authenticity
that
it
came
from
that
now
I
want
to
publish
that
content.
I
want
to
put
it
up
on.
A
I'm
using
the
word
aggregator,
it's
probably
not
the
right
term,
but
I
want
to
be
able
to
not
agitate
or
aggregate
her.
I
want
to
put
some
content
up
there
for
discovery
now,
when
I
first
put
it
up
on
docker
hub,
it's
got
the
wabbit
networks
key,
but
who
knows
who
that
is
like?
It
doesn't
mean
anything
to
anybody.
It
could
be
bad
evil.com
that
posts
something
up
there
as
well
evil.com,
whether
it
doesn't
usually
say
something
like
that
or
say
something
else
that
makes
it
seem
friendly.
A
A
This
might
become
certified
content
and
docker
does
something
that
it
decides
that
it's
certified
content
instead
of
just
giving
it
this
little
glyph
on
it.
Now
you
could
say
that's
got
an
extra
key
and
I
can
only
pull
content
that
has
the
docker
cert
on
it.
That
might
be
a
policy
a
company
rolls
out.
A
So
now
I
got
the
acme
rockets
company.
This
is
the
consumer
of
all
this
content.
They
have
their
private
registry
that
they
want
to
deploy
stuff
to,
and
so
now
I'm
going
to
pull
this
wabit
networks
network
monitor
software
into
my
environment.
It's
got
the
dockers
key.
It's
also
got
their
key,
that's
great!
Inside
of
my
environment,
I
might
have
a
deploy
script
like
a
helm
chart
that
I
want
to
deploy
this
with.
A
So
I
author,
that
I
push
it
into
my
own
registry
and
I
sign
it
because
I
want
to
know
that
this
content
really
came
from
me
and
I'm
also
going
to
sign
all
of
the
other
content
as
well,
because
I'm
going
to
take
that
network
monitor
software,
I
want
to
validate
it
works
in
my
environment.
I
might
get
a
security
update
from
it,
but
the
security
update
may
not
work
in
my
my
environment,
so
I'm
not
going
to
blindly
roll
it
out
I'll.
A
A
My
policy
manager
says
I'm
only
going
to
let
content
that's
signed
by
acme
rockets.
Go
out,
it
actually
doesn't
care
that
it
came
from
docker
or
wabit
networks,
because
that
was
a
pre
pre-check
earlier
on.
At
this
point,
only
acme
certified
content
can
be
deployed,
and
the
idea
is
that
some
kind
of
policy
manager,
maybe
open
policy
agent,
can
do
some
validation
on
some
of
these
things
as
well.
A
So
that's
the
workflow,
oh,
and
this
whole
thing
is
in
an
air
gap
environment,
so
all
of
those
keys
and
certificates
and
everything
needs
to
be
able
to
work
in
that
environment.
The
things
for
sorry
for
colorblind
people.
This
is
not
I'm
not
being
very
aware
here.
There's
the
the
blue
stuff
is
what
we're
scoping
is.
Actually
this
isn't,
but
the
the
icons
for
signatures-
the
registry-
that's
the
stuff
that
we're
scoping
for
notary
v2,
the
policy
agent
policy
manager.
A
E
B
E
A
Okay,
I
actually,
I
want
to
show
you
some
of
the
way
we're
thinking
about
signatures
might
I'll
be
really
curious
about
what
you
think
about,
because
we
actually
did
look
at
some
of
the
ibm
signature
stuff
too.
So
the
biggest
thing
that
we've
noticed
as
we've
been
delving
into
this
project
is:
how
do
you
establish
that
communication
across
a
whole
bunch
of
people
that
have
their
own
expertise,
so
I've
been
kind
of
using
this
is
actually
we've
spent
a
lot
of
time
on
figuring.
A
How
do
we
do
this
because
it's
been
a
challenge,
so,
let's
just
say
I
want
to
build
a
house
and
we're
all
going
to
build
it
together.
What
does
that
mean
like?
What
exactly
does
that
mean
to
you?
Is
you
know
you
probably
have
some
assumption
of
a
style.
I
can
draw
a
little.
You
know,
triangle-ish
square
house
and
you're
gonna
go
I'm
obviously
not
building
that
maybe
we're
building
an
a-frame,
you're
gonna
have
some
opinions
or
thoughts
or
biases
around
what
you
think.
A
That
means-
and
you
have
some
expertise
that
also
influences
your
thoughts
about
what
that's
gonna
be
and
the
bathroom
one
was
interesting
when
we
were
talking
about
this
and
making
some
assumptions
around
some
things.
So
one
of
the
we
were
talking
about
sketching-
and
I
put
this
thing
out-
cormac,
because
tommy
justin's
made
some
comment.
It
was
asking
about
something
like
okay
and
he
basically
was
building
on
the
analogy
he
goes
where's
the
bidet
like
we
don't
have
bidets
in
the
u.s.
We
hadn't
thought.
A
We
probably
do
need
bidets
after
the
toilet
paper
thing
in
covid,
but
that's
not
something
I
would
even
think
about
adding.
So
if
we
just
went
through
an
assumption
of
what's
in
a
bathroom
or
what's
in
a
key,
I
would
have
never
have
thought
to
even
put
that
in
there
where
to
him.
He
probably
wouldn't
even
mention
it,
because
it's
just
assumed
to
be
there.
So
we
really
want
to
be
able
to
facilitate
this
kind
of
conversation
and
writing
things.
A
A
A
So
this
is
not
new
to
do
this
right
if
anybody's
been
to
barcelona,
there's
anthony
gowdy,
who
had
this
vision
on
how
he
wanted
to
build
churches
and
other
buildings
actually
in
barcelona,
and
he
had
a
pretty
creative
way
of
doing
things.
So
the
example
here
is:
he
wanted
to
build
a
church
and
the
churches
in
europe.
Overall,
I
guess,
have
these
big
huge
butchers
buttresses
yeah
now
I
need
amy's
helper
or
fills
on
how
to
pronounce
that,
but
anyway,
to
support
these
massive
buildings,
and
these
are
hundreds
of
years
old.
A
A
Okay,
I'm
not
sure
I
can
read
how
it's
pronounced
there,
but
thank
you
josh.
I
need
to
click
one
of
those
things
to
figure
it
out
anyway,
so
he
had
this
vision
and
he
started
sketching
this
thing
and
you're.
Looking
at
this-
and
this
isn't
the
most
best
sketched
up
some
of
the
things
that
he's
shown,
but
it
was
the
only
thing
public
domain
I
could
find
at
the
time
and
there
what
was
happening
is
like.
How
do
we
build
this
thing
like
this?
This
spire
in
the
center
is
huge.
A
A
So
he
built
this
model,
which
is
really
amazing,
where
he
wanted
to
see
this
natural
curve,
and
he
just
uses
string
with
birdshot
in
these
little
bags
that
he
was
able
to
kind
of
form
the
structures
and,
if
you
rotate
it
around
and
when
you
go
to
the
the
the
cigar
familiar
there's
like
a
mirror
on
the
bottom,
so
you
can
kind
of
see
how
this
is
formed.
If
you
can
sketch,
you
know,
make
your
mind
kind
of
make
the
this
the
bags
go
away
and
you
just
focus
on
the
lines.
A
You
could
see
this
very
natural
curve
kind
of
forming-
and
you
know
here
and
here
and
here
and
so
forth,
and
that's
what
he
was
using
to
facilitate
this
and
then
he
went
off
and
built
more
models
and
more
models
and
the
different
trades
would
come
in
and
figure
out.
Okay,
if
that's
what
you're
trying
to
build
now,
I
know
where
to
work.
A
So
that's
the
biggest
thing
that
we've
been
trying
to
do
to
kind
of
get
this
iterative
approach
and
every
commit
is
not
the
design.
It
is
a
prototype.
It's
a
model.
It's
a
way
for
us
to
facilitate
the
conversation
and
one
of
the
things
that
we've
been
struggling
with
over
the
last
several
weeks
was:
how
do
we
support
the
update
framework,
which
is
part
of
notary
v1,
specifically
for
rollback
protection
and
the
more
we
were
digging
into
it?
A
So
we've
kind
of
said
all
right:
we're
going
to
focus
more
on
this
phased
approach
because
we're
going
to
focus
on
the
core
requirements
of
what
we
really
need
for
a
signing
of
content.
And
so
now
you
see
it's
like
right.
We're
going
to
assign
content
we're
going
to
allow
content
to
be
moved
between
within
and
across
registries,
and
now
we're
getting
into
this
interesting
conversation.
The
type
of
keys
will
support
and
then
we're
we're
trying
to
get
that
done
before
we
drill
into
some
details
around
registry
persistence
and
retrieval.
A
A
A
We
have
an
nv2
client
and
this
thing
will
do
signing
and
verification.
That's
it
it's
it
doesn't
do
any
push.
Push
me
pull
use,
doesn't
do
any
of
that
stuff,
it's
just
it
can
sign
content
offline
and
it
can
verify
the
content
that
it's
that
it's
signing.
So
therefore
you
can
give
it
an
artifact
and
it'll
generate
a
signature,
and
then,
when
I
have
those
two
separate
artifacts,
because
one's
an
artifact,
the
image
which
helm
chart
a
singularity
whatever
marky
mark,
I
I
gotta
find
your
marky
mark
josh.
A
Give
me
a
link
for
that
again
because
I
look
up
marky
mark.
I
get
all
kinds
of
results,
so
the
idea
is,
I
can
take
any
kind
of
artifact
and
I
can
sign
it
and
then
I
have
these
two
things
and
I
can
now
push
them
to
a
registry
and
we're
just
using
the
auras
client
to
be
able
to
push
those
things
up
to
a
registry.
A
So
I
can
take
that
and
I'm
curious
what
you
guys
think
about
where
the
starting
point
there
is-
and
if
I
this
is,
this
was
the
interesting
one.
So
if
you
tell
somebody
you
need
this
bathroom
and
you
need
a
shower
and
you
know
bidet
and
you
know
the
the
toilet
off
to
the
side
or
whatever
you
know,
but
there's
like
lots
of
wall
space,
and
you
know
somebody
puts
a
creative
pattern
on
the
wall.
I
hadn't
thought
about
that.
That
works
really
well
or
maybe
it's
a
glass
shower,
that's
open
and
no
door.
A
A
A
Nope,
okay,
so
if
I
take
a
docker
build
and
I
give
it
a
docker
file-
and
I'm
sorry-
I
realized
I
didn't-
I
didn't
keep
these
consistent,
so
assume
this
says
registry.example.com
and
now
I
can
generate
so.
The
next
part
was:
we
realized
that
docker,
the
current
docker
client,
pre-container
d
doesn't
actually
have
the
manifest
anywhere
local,
so
sheeway
was
able
to
create
this
plug-in
to
docker
that
basically
generates
a
manifest
from
an
image.
A
A
And
now
the
experience
we've
been
playing
with
is
this:
nv2
can
sign
it.
The
method
is
x509,
because
we
want
to
support
multiple
methods
and
then
it's
got
a
key,
and
then
it's
got
the
registry,
and
at
least
here
I'm
doing
it
consistent.
So
I
want
to
sign
it.
That's
the
tag
that
I'm
signing
and
I'm
going
to
output
a
signature
file,
and
I'm
signing
this
with
this
manifest.
A
So,
as
a
result,
if
you
format
the
output,
because
the
other
interesting
topic
has
been
about
the
whole
formatting
of
json
and
encoding
and
so
forth,
but
we'll
keep
that
aside
for
a
second,
as
I
take
this
sign
block,
this
is
what
gets
generated.
It's
got
a
digest
of
the
manifest.
So
this
is
the
image
manifest.
It's
digest.
A
G
F
A
A
Not
it's
not
a
that's
a
runnable
image,
it's
the
oci
image,
manifest
type,
so
it
becomes
a
fully
formatted
descriptor
and
then
what
we're
saying
is
at
this
point,
this
image
has
these
tags
associated
with
it,
because
one
of
the
other
requirements
that
we've
said
is
signing
should
not
change
the
digest
or
the
tag
that
it
is
signed
because
we
want
to
be
able
to
have
a
developer,
build
something
push
it
to
the
registry.
I
add
a
signature
to
it
later
and
I
can
also
add
another
signature.
A
As
you
saw
inside
of
acme
rockets,
a
signature
is
added
to
something
that
isn't
even
rebuilt
because
they
already
have
it.
So
the
idea
is
that,
at
this
point,
this
signature
is
referring
to
these
tags
registry
name
and
tags.
So
you
can
see
that
align
there
now.
What
gets
generated
is
this
is
the
signature
and
of
course
it
fills
the
whole
screen.
So
I
just
short
truncated
it
here,
but
in
this
object
here
is
the
actual
output
of
the
signature
that
signed
this
content.
F
A
That's
great
okay,
so
key
acquisition
is
something
that
I've
purposely
ignored
right
now
and
let
nia's
work
on
the
key
management
portions
of
it.
So
yes,
there's
a
bunch
of
waving
here
that
we're
building
a
bathroom
without
a
floor.
We
haven't
55
the
floor
is
just
there.
Somehow
we
haven't
we've
ignored
that
part.
A
F
A
But
that's,
but
you
have
the
option
of
doing
both,
because
that's
the
thing
that
we
hear
a
lot
of
people
get
into.
Is
they
a
lot
of
people
wind
up
deploying
with
digest,
because
the
only
thing
they
trust
that
doesn't
change
it
doesn't
make
very
good
usability
for
when
you're
looking
in
cube
control
and
all
these
other
dashboards
anything
that
just
this
long
long
string,
that's
not
even
if
you
can
get
the
whole
thing,
you're,
certainly
not
going
to
memorize
it.
So
you
want
something
short
and
usable.
A
A
So
I'll
go
a
little
bit
further
just
to
explore
some
more
ideas
or
conversations,
so
we
want
to
persist
it
as
an
artifact.
So
basically
we
just
take
the
media
type.
We
generate
a
manifest,
so
this
manifest,
if
you
notice,
did
I
put
it
in
here?
No
okay.
So
if
you
look
closely
the
media
type
here
of
the
rather
the
config
object
is
the
content
of
that
config
object
is
this:
this
is
what
we're
actually
going
to
take
the
whole
signature
and
save
it
as
a
media
type.
A
Oh
sorry,
save
it
as
a
config
object,
and
it
is
a
manifest
with
zero
layers,
and
if
we
look
closely
you'll
see
that
the
config
media
type
says
it's
a
cncf
notary,
config
v2.
So
this
is
how
we're
basically
saying
this
is
a
notary,
v2,
formatted
signature,
object
or
media
type,
artifact
type,
and
then,
of
course
its
digest
is,
is
this
here?
So
the
idea
is
now
you
can
put
those
two
things
in
the
registry,
as
I
showed
before,.
H
Yeah
go
so
on
that
that
oci
manifests.
Have
you
put
thought
into
users
who
who
or
clients
who
who
maybe
aren't
interested
in
the
signature
and
just
want
the
layers?
Because
I'm
thinking
about
the
round
trips
required
to
actually
get
the
image
content?
And
it's
already
a
lot
today.
And
this
just
added
at
least
one
more.
A
H
So
so,
let's
say
this
this
manifest:
that
is
the
signature
that
points
to
the
the
final
manifest
and
objects
and
everything
right.
Let's
say
this
got
pushed
to
a
specific
tag
when
I
go
docker
pull
that
tag.
If
I'm
not
interested
in
the
signature,
it's
got
a
well
even
if
I
am
it's
got
to
grab
grab
this
first
manifest.
A
H
Follow
the
the
pointer
and
grab
the
second
manifest,
which
is
gonna,
be
that
signature
object.
Then
it's
gotta
follow
that
pointer
to
get
the
manifest
list.
Then
it's
got
to
follow
that
pointer
to
get
the
actual
image
manifest
for
the
architecture
I'm
interested
in
then
it's
got
to
go.
Get
the
image.
Config
object,
plus
every
layer
object.
A
Yeah,
so
let
me
er
there
is.
There
is
some
that
we're
not
changing,
but
to
be
fair,
I
was
just
looking
for
the
picture
that
described
this
so
the
way
this
goes
back
to
the
distribution
spec
that
we're
we'll
propose
here.
So
the
the
model
is
that
this,
this
signature
object,
doesn't
actually
need
to
get
tagged.
It's
actually
just
it
happens
to
be
in
the
registry
with
a
think
of
it
as
an
untagged
artifact,
that's
in
the
registry,
and
you
don't
actually
ask
for
it.
A
What
you're
going
to
do
is
you're
going
to
ask
for
the
that
you're
going
to
ask
for
the
tags.
Sorry,
the
signatures
for
this
artifact,
because
your
deployment
script
says
I'm
trying
to
deploy.
Example,
v1.0
so
as
part
of
the
nv2
client.
What
it
does
is
says:
hey
well,
not
the
mp2,
the
full
workflow,
what
the
full
workflow
does.
It
says:
hey
registry,
what
signature
objects
do
you
have,
for
example,
colon
v1.
H
A
Docker
workflow,
you
know
your
normal
artifact
workflow,
where
it
just
says
hey.
Yes,
I
do
ask
for
a
tag
I
can
ask
for
dodges
and
then
it
comes
back
and
says
you
know:
here's
the
the
layers
that
make
up
this
thing
and
but
before
it
you
know
it
gets
that
information
back.
One
of
the
things
that
client
the
nv2
client
would
do
when
you
plug
it
into
the
whole
workflow
is
that
you
would
have
this
flag.
That
says
hey.
I
only
support
trusted
content.
A
So
now
it's
before
even
starts
pulling
the
layers.
It's
gonna
say:
hey
registry.
What
signature
objects
do
you
have
and
it
could
even
say
by
the
way
I
only
care
about
the
acme
rocket
signature.
So
do
you
have
an
acme
rocket
signature
for
this
tag?
And
the
registry
says
yes
here
it
is
you
take
a
look
at
it.
You
can
evaluate
the
signature.
Does
the
signature
match
the
manifest
for
the
example
v1
and
if
it
does
and
you're
happy,
then
you
would
proceed
to
pull
in
the
layers.
A
I
didn't
get
the
slides
complete,
so
in
the
so
here
we're
using
signing.
We
sign
offline
verification,
so
the
idea
here
is
that
I
can
say
nv2
verify
I
pat,
and
this
is
sorry.
Let
me
do
this
one
right.
They
were
not
all
up
to
date.
Yet
so
I
say
verify
this
config
this
file.
That's
basically
the
config
file
that
I
got
because
remember
we're
right
now
we're
breaking
smaller
components.
This
isn't
we
don't
have
a
docker
with
notary,
v2
client
built.
A
Yet
so
we're
just
saying:
there's
a
nv2
client
that
knows
how
to
verify
manifest
to
signatures.
So
we
say
verify
this
signature
object
to
this
manifest
with
this
cert
and
as
long
as
that
will
pass
or
fail
based
on
the
certain
matches.
You
know
the
contents
of
the
registry
name
for
the
cname
has
to
match,
and
as
long
as
that
comes
back
up
and
it's
val,
then
you're
good.
A
The
interesting
things
that
we've
been
kind
of
you
know
chewing
on
as
we've
got
the
sketch
and
we're
trying
to
figure
out
and
people
come
in
going
hey.
What
about
this?
One
of
the
things
that's
it
was
kind
of
interesting
is
everybody's
kind
of
picking
up
on
this
interesting
pattern.
You
know
that
I
can
make
the
analogy
of
shoei
putting
on
the
wall
of
hey.
I
can
use
the
c
name
for
the
validation
and
we
kind
of
think
it's
interesting,
but
what
does
it
really
mean
like?
Is
it
something
you
has
to
be
enforced?
A
A
That
when
I
put
the
acme
rocket
signature
on
this
thing-
and
it
has
an
acme
rockets
cert-
and
it's
got
the
registry
name
of
registry.rockets.com
or
io
whatever
that
on
this
with
the
policy
manager,
it
could
implement
something
that
says
by
the
way.
Not
only
does
that
to
be
signed
by
me,
but
the
policy
manager,
not
the
mb2
client,
could
say.
I
will,
because
it's
signed
with
that
registry
c
name
I'll
only
allow
content
to
be
pulled
from
that
registry.
So
it's
like
another
idea
that
says
you
can't
go
pull
from
docker
docker
hub.
A
You
shouldn't
be
pulling
from
duck
robin
production.
You
shouldn't
be
pulling
from
evil.com's
registry
either.
So
even
if
somehow
the
cert
got
on,
you
know,
let's
say
the
shirt
got,
you
know
compromised
or
something
and
on
evil.com
it's
got
bad
content
for
that
cert.
Whatever
and
key
verification
didn't
kick
in
whatever
the
magic
pieces
are,
this
policy
manager
could
enforcing
I'm
only
going
to
pull
from
the
acme
rockets
registry,
so
there's
just
some
interesting
things
that
are
kind
of
becoming
a
good
conversation
piece.
A
Of
course,
this
is
the
more
interesting
one
the.
How
do
we
serialize
json
to
get
a
digest
is
not
at
all
interesting,
but
we
have
to
get
closure
on
it
because
there's
all
kinds
of
gnarly
sharp
glass
on
that
one
to
figure
out
and
the
other
one
we're
getting
into
this
conversation,
I
said,
is
like
the
keys,
because
x509
is
something
that
is
expensive.
A
F
F
A
Yeah,
it's
fair.
We,
we
did
say
the
beginning
of
notary
v2
when
we
started
the
effort
that
it's
not
we're
not
meant
to
be
compatible.
Nv1
was
just
it
has
too
many
limitations
for
us
to
try
to
do
any
compatibility.
We
are
reassessing
the
requirements
and
the
fact
that
things,
weren't
movable
kind
of
made
the
whole
thing
dead.
On
arrival,
the
usability
doesn't
work.
A
The
the
other
problem
that
we're
facing
is
that
the
way
the
rollback
capabilities
work
assumes
some
state
on
the
client,
because
I
need
something
else
to
compare
with
it.
The
registry
is
compromised
and
you
have
to,
and
somebody
rolled
it
back
to
what
was
still
signed
by
debian.
Let's
say
I'll
pick
on
debian,
but
it's
now
considered
vulnerable
and
I've
assigned
it
to
that
tag.
A
You
don't
really
want
to
take
an
update.
That's
got
the
same
tag
and
deploy
it.
What's
it
really?
Interesting,
though,
is
you
do
on
your
from
statements
right
like
if
I
say
from
node,
9
or
whatever
the
number
is
now
I
do
want
to
get
an
update
when
node
9
has
a
security
patch
to
it.
So
there
is
some
capabilities
that
we
actually
do
believe
we
certainly
don't
want
node
9
to
be
rolled
back
and
we
are
getting.
You
know
a
lot
of
this
content
from
public
registries,
even
though
we
validate
them
in
private
registries.
A
A
So
that's
that's
you're
right,
there's,
definitely
a
layered
approach
and
we
are
the
way
I
think
about
it
is
notary,
is
a
signing
solution
and
then
there's
the
update
framework,
so
we're
kind
of
peeling
it
in
that
layer
and
saying
the
notary
part
we're
definitely
going
to
do
some
signing,
and
if
we
can
get
the
update
portions
in
there
you
know
in
a
way
that
makes
sense,
then
we're
absolutely
going
to
do
it.
The
other
knowledge
I
make
is
like
look.
A
You
can
put
lots
of
security
things
on
it
like
say
on
a
door
if
it's
so
difficult
to
open
and
close
every
time,
then,
what's
the
first
thing
that
people
do
they
put
a
brick
in
front
of
the
door
to
keep
it
open.
So
we
want
to
make
sure
that
the
security
solutions
that
we're
putting
together
for
notary
v2
really
meet
the
requirements
and
the
usability
so
that
it
can
actually
be
used.
A
Yeah
there's
some
the
iot
one
is
also
interesting,
because
when
you
get
into
this
nested
network
stuff
you
you
really
need
a
lighter
weight.
You
know
registry
to
be
able
to
run
and
the
the
notary
infrastructure
is.
You
know
pretty
bulky,
but
you
know
every
first
iteration
of
something
like
the
first
computer
was.
You
know
monstrous
portable
computer,
all
these
things,
so
the
idea
is,
we
can
scale
it
down.
Now
that
we
know
more
derek
did
I.
A
A
That
has
been
like
almost
one
of
the
biggest
debates
that
I've
seen
this
so
far
going
on
in
the
on
the
pr
the
x,
the
certain
one
is
the
next
one
we
we
haven't
had
a
lot
of
time
to
kind
of
drill
into
that
into
what
the
next
steps
would
be
there
other
than
we
we
recognized.
We
need
to
do
something
and
I'm
very
interested
in
what
other
people
think
like
what
what
do
people
feel
that
they
could
sign
with
what
would
they
say
is
acceptable.
F
E
Yeah
I
mean,
I
also
wonder
if
it's
worth
you
know,
looking
back
at
the
notary
current,
you
know
notary
project
issues
and
pr,
as
you
can
see,
contributions
from
big
companies
and
folks
who
care
about
ubi
keys
and
everything
in
between
on
kind
of
the
different
formats
and
hardware
they
wanted
to
support
so
that
that
may
be
a
good
indicator.
People
that
were
trying
to
use
notary
v1
had
a
pretty
discreet
list
of
things
that
met.
A
A
A
All
right
well
for
those
that
are
interested
more,
we
do
have
the
monday
meetings,
they're
generally
10
a.m.
On
monday,
we've
been
doing
them
earlier
at
7
a.m,
because
some
of
the
folks
between
either
an
apac
region,
there's
the
notary,
slack
channel.
So
I'll
I'll
put
the
links
in
the
notes
that
people
can
go.
You
know
keep
up
with
us
there
and
we're
we're
keeping
on
churning.
I
appreciate
the
feedback.
A
A
I
haven't
had
time
to
go
wrestle
that
voting
conversation
so
unless
somebody
else
can
volunteer
to
help
there
at
this
point,
we'll
just
we'll.
I
hope
we'll
come
back
to
that,
but
right
now
we'll
just
we'll.
Stick
with
10a
sorry
2
pm
same
time
same
channel
for
next
wednesday,
and
if
there's
topics,
please
put
it
on
the
agenda
and
we'll
go
through
it.