►
From YouTube: CNCF Notary Project Meeting 2020-08-24
Description
CNCF Notary Project Meeting 2020-08-24
A
B
A
A
A
C
A
A
The
one
I
was
hoping
we'd
spend
more
time
was
on
the
distribution
api,
and
I
was
thinking
a
little
bit
about
it
in
the
sense
of
I'm
not
sure
if
this
group
is,
as
particular,
about
the
details
as
the
oci
distribution
owners,
but
before
I
brought
it
the
proposal
there,
I
figured
I'd
run
up
by
here
the
script
to
see.
If
there's
any
feedback,
we
should
incorporate
some
folks
overlap
both.
So
that's
great,
so
we
kind
of
pre-vet
it
here.
A
A
Yeah
share.
Okay,
am
I
sharing
this
time?
Can
folks
see
yep?
Okay,
great
all
right,
so
this
one
is
basically
the
pr
we've
been
talking
about
for
a
while.
Now
the
only
diff
we
we
originally
had
it
as
a
separate
pr.
We
had
a
couple
different
pr's
and
we'll
talk
about
pr's
on
top
of
pr's,
but
basically
this
takes
the
discussions.
We've
been
having
around
the
encoding
of
the
json
object,
which
is
basically
how
do
we
take
this
and
sign
it,
and
just
take
that
formatting
and
put
it
into
an
actual
jwt.
A
A
A
So
if
we
go
back
sorry
just
for
context,
we
go
back
to
this
diagram
where
we're
trying
to
get
an
end
in
workflow,
going
that
we
use
the
nv2
client
to
sign
an
artifact
and
push
the
artifact
to
the
registry
right
now.
This
pr
really
focuses
on
these
two
pieces
to
sign
and
verify
generating
a
jwt
now
in
the
other
proposal,
we'll
talk
about
using
something
like
whereas
to
push
into
the
distribution
spec.
A
A
A
Okay,
I
think
we'll
we'll
focus
more
on
the
distribution
spec
I
mean
like,
so
I
think
we've
covered
everything
in
here
in
the
pull
requests
there
are
ignore
this.
This
is
this.
Is
this
one
that
we've
talked
about
here?
There
is
a
new
thing
that
we're
working
on
doing
a
tough
proposal.
It
is
very
much
a
work
in
progress.
I
wasn't
ready
to
talk
about
it
this
week,
so
I
really
want
to
focus
on
these
two.
A
So
if,
if
everybody's
cool,
maybe
the
next
part
of
the
conversation
I
want
to
have
is
around
how
we
actually
not
make
prs
on
top
of
pr's
and
have
some
kind
of
base
to
work
from
so
we'd
really
like
to
get
this
one
merged.
In
this
way,
we
can
open
up
issues.
We
can,
you
know,
do
additional
prs,
but
we
have
something
in
the
route
because,
right
now
we
have
an
empty
shell
thoughts.
Conversations
comments.
I.
D
Oh,
I
see
so
we
could
have
a
branch
for
a
whole
proposal
that
could
be
merged
into
and
then
reviewed
as
a
whole
at
various
stages.
Rather,
and
then
we
could
merge
to
master
rather
than
having
work
in
progress
because
or
or
we
could-
I
mean.
Alternatively,
we
could
have
separate
repos
for
prototypes
or
proposals
that
people
could
then
open
issues
against
more
easily.
A
A
I
guess
what
we
could
say
is.
We
could
create
a
branch
that
the
branch
is
the
prototype
and
then
the
nv2
becomes
the
final
thing
that
we
decide
that
we
want
to.
When
we
read
the
prototype
into
an
actual
reference
implementation,
we
can
make
the
master
of
nb2b
that
reference
implementation,
as
opposed
to
the
prototype
that
we
can
throw
out
and
make
an
md
2.1.
I
actually
hadn't
really
thought
that
far
out.
A
So
I
so
the
main
reason
I
was
thinking
of
merging
from
the
pr
was
so
that
we
had
a
stable
base
that
we
could
build
from
and
then
do
subsequent
pr's
on
it
with
comments
and
issues
and
so
forth
to
track.
There's
nothing
that
says
that
we
couldn't
do
that
exact
same
thing
on
an
nv2
with
a
proto
one
branch,
because
then
we
merge
into
that
branch
and
then
we
can
evolve
from
there.
A
A
Implementation,
okay,
cool
all
right,
that's
good,
and
then,
if
I
can
and
if
there's
anything,
it's
obvious
open
issues
for
open
topics
in
this
pr
in
the
in
this.
What
is
this
number
two
pr,
and
if
I've
missed
anything,
then
people
can
open
up
additional
issues.
That'll
be
good
I'll,
try
to
capture
the
ones
I'll.
Do
the
legwork
there
all
right!
So
that's
the
jwt
conversation.
A
The
next
one
was
the
distribution
spec.
I
can
get
my
mouse
in
the
right
place.
This
one
is
a
little
more
interesting.
There
is
a
bunch
of
discussions
here
to
be
fair
and
we're,
and
I
would
very
much
appreciate
the
feedback,
but
I
think,
as
sam
was
looking
at
it,
in
fact
I
was
making
a
a
fun
common
response
is
that
his
question
was
exactly
what
I
was
kind
of
expecting
so
all
right.
What
we
have
here,
all
right,
let's
kind
of
go
through
this.
A
This
is
what
I
wanted
to
spend
the
most
time
on.
I
we've
been
working
through
now
that
we
have
the
workings
of
a
signature.
I
will
evolve
the
different
signature
types.
So,
let's
not
get
focused
on
the
format
of
the
signatures
per
se,
because
we'll
have
multiple
formats
and
we'll
work
through
those.
Once
we
have
a
signature,
we
do
need
to
figure
out
how
to
push
it,
how
to
find
what
signatures
are
available
and,
of
course,
how
to
full
a
pull,
pull
a
signature.
A
A
A
signature
in
the
registry
and
I've
had
a
couple
of
different
thoughts
and
some
new
thoughts
when
we
start
thinking
about
metadata
storage,
which
we'll
ultimately
want
to
deal
with
as
well.
So,
first
of
all,
the
one
is
the
one
we've
been
working
with
so
far
because
it
just
works.
Well,
the
persistence
works.
The
discovery
doesn't
work,
so
the
persistence
works.
So
it
is
using
the
oci
pattern
where
you
take
a
manifest,
because
it's
the
only
thing
we
support.
A
We
don't
support
index
yet
and
I
can
put
a
diges
a
config
media
type
on
it.
That
effectively
says
that
this
is
a
notary.
V2
object
in
the
config
object
itself.
I
would
store
the
jwt
and
I
just
noticed
this
is
no.
No,
it
is.
It
is
right.
So
all
this
is
saying
is
this
is
an
image
manifest?
I
you
don't
actually
need
to
specify
it
there,
but
I
put
it
there
for
clarity,
but
the
media
type
of
the
config
says
it's
a
notary,
v2
and
notice.
A
We've
changed
it
to
jwt
for
the
most
recent
thing
inside
the
config
object
is
the
signature
which
did
I
put
it
here
yeah.
So
here's
the
the
actual
signature
has
the
digest
that
it
refers
to.
So
sam
was
kind
of
asking
the
question
going
hey.
This
is
kind
of
confusing
that
a
manifest
points
to
another
manifest,
which
is
what
this
arrow
indicates
and
it.
A
A
If
you
want
to
delete
the
index,
you
can
delete
the
manifest,
but
you
shouldn't
be
able
to
delete
the
manifest
if
an
index
still
references
it,
because
then
you
kind
of
wind
up
with
an
orphaned
index.
The
the
only
challenge
with
that
is
today
an
index
doesn't
have
a
way
to
say
it's
anything.
Other
than
a
multi-arc
manifest,
so
what
we've
always
said
with
the
artifact
approach?
Is
we
always
wanted
to
take
the
pattern
that
we
did
on
manifest?
That
say
this
manifest,
isn't
just
a
isn't
a
runtime
image,
it
is
a
helm
chart.
A
A
If
you
will
so
that's
what
we've
been
trying
to
propose
here
and
then,
if
we
do
that,
then
there's
actually
two
options:
one
the!
How
do
I
wanna
walk
down
this?
I
haven't
thought
how
to
explain
this.
The
index
references
the
manifest
that
it's
it
is
signed.
Then
the
question
is:
where
is
the
signature?
That's
what
I
was
trying
to
get
at.
We
can
follow
the
same
pattern
we
had
with
the
one
above
here
where
the
signature
itself
is
in
the
config
object.
A
A
A
I
I
forgot
his
name,
I'm
sorry.
On
the
oci
conversation,
we
were
having
this
whole
conversation
with
alexa.
Sorry,
that's
what
it
was
I
relax
on
alexis
alexa
was
making
a
comment
that
it
was
kind
of
weird
that
a
config
object,
which
is
supposed
to
be
configuration,
can
store
something
else
that
could
then
you
know
it's
actually
just
another
blob
and
while
true,
we
have
lots
of
things
like
that
layers
or
blobs.
A
So
that's
kind
of
one
way
to
do
that.
The
pros
and
cons
were
kind
of
called
out
here.
The
pro
is,
it
does
conform
to
a
purest
view
of
how
we
have
registries
being
a
reformed
dba.
I
really
like
purist
data
structures
this
one,
but
the
con
is
all
it's
really
doing.
Is
taking
the
blob
that
we're
storing,
we
would
store
it
an
index
config
object
which
we
want.
The
config
object
anyway.
A
Instead
of
storing
the
blob
there,
which
is
what
indexes
are
it
moves
it
to
another
manifest
and
requires
another
layer
of
indirection
that
both
adds
garbage
collection,
work
we'd
have
to
do
in
registries
and
additional
api
calls,
so
you
would
effectively
say
hey.
I
want
all
the
signature
objects
for
this
thing,
it's
going
to
return
a
collection
of
indexes,
because
the
index
is
the
way
it
refers
to
individual
signature
objects
and
then
I'd
have
to
go,
get
the
manifest
to
then
go
get
the
blob.
A
So
that's
kind
of
the
pros
in
con
and
the
last
piece
that
I'll
just
mention,
because
I
think
I
teased
up
the
question.
The
reason
we
don't
use
the
index
to
reference,
a
collection
of
manifests
is
we're
trying
to
make
sure
everything
is
immutable
and
we
don't
want
to
go
back
and
change
digest
of
things
that
point
to
lots
of
things.
So
each
one
of
the
signatures
are
independent
signatures.
A
We
got
it,
we
got
a
lot
of
great
feedback
from
derek
and
I
was
hoping
to
get
to
this,
but
he
we
kind
of
left
it,
and
I
wanted
to
end
the
conversation
about
making
sure
there
was
an
odor
of
the
great
conversations
as
opposed
to
getting
into
this.
So
I
was
actually.
I
think
I
have
this
on
the
agenda
for
this
wednesday
to
discuss
with
that
working
group.
But,
like
I
said
it's,
you
know
chicken
egg.
I
think
car
course
eventually
becomes
cart
horse.
A
Conversation
are
you
coming
from.
You
know.
A
registry
operator
perspective
this
one
I
never
really
loved
because,
as
you
know,
just
as
sam
was
kind
of
looking
at
it
very
confused,
I
think
anybody
understands
registries
would
kind
of
barf
on
this
and
there's
some
real
cons
too.
It's
not
just
logically
it's
that
now
we
have
to
put
something
to
parse
media
config
objects
as
they
come
in
just
to
reference
it,
while
the
underlying
infrastructure
for
reference
counting
and
garbage
collection
would
be
the
same.
A
You
still
have
this
other
entry
point
that
makes
me
uncomfortable.
I
don't
have
to
write
any
of
that
code,
so
I
I'm
somewhat
proxying
my
team,
the
and
honestly
the
team
itself
was
going
like
hey.
This
depends
on
something
the
oci
hasn't
agreed
to.
Yet
you
know
with
index
like
yes,
that's
true,
it
requires
more
changes.
Yes,
that's
true!
A
B
I
think
that
the
things
that
I
wrote
in
the
comments
are
still
true,
which
is
I'm
not
entirely
clear
on
there's
some
some,
I
think,
lacking
clarity
in
the
description
for
those
these
options
and
I'm
not
understanding
what
all
of
the
implications
are.
In
particular,
I'm
interested
in
understanding
whether
like.
A
Right,
but
I
so-
and
this
is
why
I
want
to
have
the
conversation
rather
than
texting,
back
and
forth
because
well
to
be
fair,
I
just
read
your
feedback,
so
in
fact
I
didn't
get
a
chance
to
read
at
all
to
be
fair,
too
the,
but
the
example
here
is.
We
actually
aren't
updating
signatures,
the
the
approach
that
we're
doing
here,
and
actually
it
doesn't
matter.
That's
all
three
options
is
a
signature
is
a
new
thing
that
gets
pushed
to
a
registry,
and
you
would
never
update
the
signature.
A
A
We
said
we
don't
want
to
have
anything
change
on
the
user's
description
of
what
they're,
deploying
if
they'd
apply
with
the
digest
or
deploy
the
tag,
and
I'm
trying
to
be
really
careful
to
not
do
anything
where
any
referenced
information
other
than
you
know,
whatever
change
and
digest
by
definition,
don't
change,
because
in
azure
we
have
geo-replications
that
we
want
to
keep
in
eventual
consistent
state,
but
also
that's
just
a
microcosm
of
we're
doing
where
we're
saying
content
needs
to
move
or
not
move.
I
keep
on
saying.
A
B
A
A
The
index
wouldn't,
and
I
and
I
appreciate
that
in
a
multi-arc
index
kind
of
space
that
indexes
do
get
updated
or
the
tags
from
an
index
get
updated.
In
this
case
there
is
we're
actually
saying:
there's
no
tags
which,
which
could
say,
is
a
different
conversation,
but
the
index
never
gets
updated.
So,
as
I
add
new
signatures,
I
add
new
indexes
and
then
I
think
the
next
question
is
well.
How
do
I
get
these?
That's
the
conversation
below
of
you
know
we're
proposing
a
new
api
on
distribution.
A
E
A
E
A
So
what
I
will
let
you
echo
back
what
I
think
you
asked
and
how
I
would
see
it,
and
I
will
make
a
note
to
put
it
into
the
spec
into
this
example
as
well.
So
if
I
have
the
hello,
what
do
I
have
here?
I
have
the
net
monitor
software.
So
let's
say
the
net
monitor
software
was
just
a
manifest.
It
would
have
an
index,
that's
a
signature,
but
now,
let's
say
which
the
thing
is.
What
you're
asking?
A
If
the
net
monitor
software
has
both
linux
and
windows,
I
just
like
using
those
for
the
most
simplistic.
Instead
of
different
variations
of
production,
then
there
would
be
a
multi-arc
index
for
that
net,
monitor
software
and
that's
a
standard
multi-arc
index
that
we
all
know
and
love
or
know,
and
hate
and
love
want
to
hate,
want
to
love.
Sorry,
just
having
fun
with
last
week's
conversation
the
and
then,
if
I
wanted
to
sign
that
index
the
multi-arc
index,
I
would
have
another
index.
A
That
was
a
type
signature,
and
if
I
wanted
to
sign
the
linux
and
windows
images
individually,
there
would
be
another
index
of
types
notary,
v2
signature.
That
could
also
get
persisted
so
I
can
show.
I
will
paint
a
diagram
of
that
to
show
that
in
its
extr,
exacerbated
exploded
view
all
right.
Thank
you,
but
is
that
what
you
were
asking
or
and
was
there
a
concern?
Are
you
just
asking
for
clarity.
A
A
A
Okay,
let's
make
sure
everybody's
comfortable
with
it
with
a
you
know,
get
answers
to
their
questions
and
and
run
that
so
that's
kind
of
the
model
there
is
that
us,
an
index
is
of
type
notary
v2
and
it
has
pointers
to
content,
and
I
guess
it's
probably
more
of
the
oci
conversation
group,
we'll
probably
more
passion,
whether
we
go
this
one
or
this
one,
so
the
the
apis
that
we're
now
going
to
talk
about
actually
don't
matter
so
now.
Let's
talk
about
there's
two
part
with
linking,
I
think,
leaking
we've
basically
resolved
there.
A
Originally
the
thing
with
option
one
is
in
order
to
link
the
signature
with
the
thing
it's
signing.
We
were
gonna
have
to
parse
the
config
object.
I
don't
think
anybody
likes
that
idea
from
the
way
it's
proposed
manifest.
Don't
reference
manifest
and
I
think
we
don't
want
to
get
into
the
business
of
parsing
object.
Config
objects
if
we
don't
want
to
or
make
it
required
the
option,
two
there's
a
distinct
linking
api,
because
it's
the
way
index
just
work.
So
that's
really
nice.
A
There
was
another
option
for
actually
putting
these
things
individually
and
then
uploading.
Oh
there's
a
completely
separate
signature,
upload
api,
which
I
think
justin
cormack.
When
we
have
one
justin
k,
cormack
was
suggesting
like
hey.
Why
are
we
making
things
unique
to
signatures
when
we
don't
have
to?
Because
your
question
before
is
more
on
the
auth
model?
If
I
wanted
to
put
a
limitation
on
who
can
upload
signatures,
then
I
might
want
to
put
a
limitation
on
who
could
upload
helm,
charts
or
other
things
also.
A
A
So
that's
the
linking
conversation
I'm
covering
it
more
for
pers
for
completeness,
as
opposed
to
now.
What
we're
really
talking
about
is
the
discovery,
signature,
okay,
so
signature
discovery.
So
now
this
is
what
you're
kind
of
I
think
asking
about
sam
is
when
the
idea
is.
I
have
the
net
monitor
software.
I
know
I'm
referencing
net
monitor
colon
v1.
I
can
also
say
net
monitor.
You
know
digest.
If
I
want
we're
not
excluding
either
one
of
those
that's
the
thing
I
want,
please
give
me
all
the
signatures
related
to
that.
A
So
that's
what
we're
proposing
here
is
you
basically
get
it's
very
specific
to
signatures.
In
fact,
you
notice
that
it
says
you
know:
here's
your
repo
name,
so
net
monitor
manifests
and
then
this
is
the
digest
and
then
there's
a
signatures,
object
that
hangs
off
of
it
and
then
you
would
get
a
collection
of
that's
monday,
a
collection
of
descriptors-
and
you
have
all
of
these
that
are
in
here,
so
we're
we're
kind
of
playing
a
little
bit.
A
A
However,
one
the
the
thing
that
we
don't
really
know
about
this
one
yet
is
we
don't
know
which
signature
this
is,
so
we
don't
think
there'll
be
more
than
five
or
ten
signatures
for
a
particular
object,
because
basically
we're
saying
for
every
release
digest
how
many
entities
actually
want
to
sign
that
thing
over
time.
We
know
that
there'll
be
updates
to
the
net,
monitor
software,
and
but
each
update
would
have
new
signatures,
but
we
know
that
there
will
be
more
than
one.
A
There
will
be
there's
a
high
level
of
n,
so
it
is,
there
is
a
paging
api
in
it,
but
regardless
what
I
don't
like
about
this
so
far
is
there's
no
way
to
actually
know
what
which
signature,
because
if
I
only
want
the
acme
rocket
signature,
then
why
do
I
have
to
get
five
signatures
back
just
to
figure
out
which
one
to
get
and
that's
what
you're
starting
to
see
is
there's
a
little
bit
of
leakage
because
we're
trying
to
figure
out
hey.
Can
I
put
some
extra
metadata
on
this?
That
says.
A
A
A
Did
this
stuff?
At
the
end,
honestly,
we
tried
to
put
some
examples
in
here
to
try
to
help
to
disambiguate.
In
fact,
I
was
trying
to
figure
out
trying
to
put
comments
in
the
middle
as
to
reference
which
one
this
is
yeah,
so
let
me
try
to
explain
it
and
then
tell
me
how
we
think
how
I
could
actually
make
this
one
more
clear.
So
what
this
is
saying
is.
Let
me
remember
the
res
what
it's
saying
so
I'm
asking
for
this
digest
and
this
digest
it
should
be.
A
A
Correct
to
your
to
milo's
previous
question:
if
I
had
a
multi-arc
index-
and
I
signed
that
this
will
be
the
digest
of
that
in
that
multi-arc
index,
I'm
going
to
start
using
the
word
multi-arc
index
just
to
make
sure
we're
talking
about.
It
is
a
collection
of
images,
in
this
case
we'll
just
say,
windows
and
linux.
So
if
I've
signed
an
index,
that's
what
this
would
be
if
I've
only
signed
the
windows
or
linux,
individual
images
and
those
are
manifest
that
then
I've
specifically
asked.
I
want
the
signature
for
that
one.
A
A
A
A
So,
what's
so
now,
I've
got
the
the
collection
of
signatures,
and
now
you
know
we're
kind
of
going
all
right.
Now
we
have
to
figure
out
well.
How
do
I
get
the
one
I
actually
care
about,
because
I
probably
don't
care
about
all
the
signatures,
I'm
probably
looking
for
a
specific
signature
on
it
and
we
don't
have
a
good
answer
for
that.
A
Yet
the
other
one
is,
and
I
was
trying
to
build
on
what
cormac
was
kind
of
bringing
up
last
week
about
being
generalistic
on
some
of
these
things
is:
there's
nothing
really
unique
to
signatures
that
I
want
to
get
a
list
of
dependency
objects
on
it.
So
should
we
have
a
generic
listing
and
what
I
try
to
do
there
is
I,
if
it's
generic,
then
I
don't
really
have
a
place
to
put
specific
things
in
it.
A
A
If
I
have
multiple
signatures,
I
get
multiples
and
I'm
getting
multiple
indexes
over
time.
The
index
itself,
because
there'll
be
no
there's
a
proposal
of
no
tags.
Of
course
you
could
tag
it,
but
from
the
signatures
api
or
the
get
signature
flow,
you
wouldn't
get
a
you're,
not
really
asking
for
a
specific
signature,
you're
asking
for
the
signatures
of
a
thing
and
if
anything,
you're
asking
for
the
key
type
or
who
signed
it,
we're
actually
implicitly
trying
to
say
that
the
fact
that
it
gets
persisted
as
a
digest.
The
fact
that
you
could
technically
tag.
D
A
So
it's
not
that
I
want
to
be
able
to
get
the
signature
and
ultimately,
of
course,
I
know
what
I'm
getting
you
want
to
actually
you're
saying
I'm
explicitly
referring
to
that
particular
signature
and
whatever
it's
signed
is
what
I
I
want
as
opposed
to
hey
I'm
trying
to
get
this
thing,
and
I
want
to
make
sure
it's
signed
by
the
entity.
I
trust
and
it
happens,
to
have
a
digest
on
it.
You
actually
want
to
go
from
the
signature
as
a
scenario.
C
D
I
mean
in
in
the
all
the
tough
use
cases
are
like
that,
where
you
refer
to
signed
objects
and
because
you
know
which
signature
you
want
them
to
be
designed
with,
because
it's
part
of
the
it's
very
cool
design
and
then
other
cases
where
you
know.
I
want
to
refer
to
the
exact
image
that
sam
signed
for
me
last
week,
not.
D
D
Not
this
I
want
to
specify
sam
gave
me
a
signed
object
last
week.
This
is
it
as
opposed
to
sam
recommended
an
object
for
me
last
week
and
signed
it,
which
is
a
slightly
different
question
because
it
might
be.
It
might
then
have
a
different
signature
by
sam,
and
I
I
need.
I
want
to
be
able
to
talk
about
the
specific
one.
A
What
I'm
kind
of
listening
for
I'm
trying
to
figure
out
is
this
wind
up
in
this
pinning.
I
guess
it's
part
of
the
pitting
model
and
there's
times
where
you
do
want
pinning
to
something
specific,
and
I
was
sort
of
hoping
to
be
clear
and
hadn't
really
think
about
following
through.
Is
that
what
you're
pinning
to
is
the
object,
you're
trying
to
ultimately
deploy
and
either
the
tag
is
locked
or
you
can
reference
it
at
its
digest
and
the
signature
is
the
signature
of
the
entity.
You
trust,
in
other
words,
you're,
saying
hey.
A
I
trust
acme
rockets
and
I'm
trying
to
deploy
this
you're
trying
to
say
that
I
actually
have
this
very
specific
signature
that
I'm
referencing
and
I
guess,
if
you're
going
that
way
or
going
through
the
digest
of
the
thing,
you're
referencing
or
a
lock
tag
either
in
either
case.
You
can't
do
a
security
update
to
it,
because
you're
you've
made
an
explicit
choice
to
pin
it
and
it's
I
don't
know
if
it's
any
better
or
worse,
either
way
so.
E
I
would
say
for
that
for
individual
management
of
signatures.
You
would
of
course,
refactor
them
individually
and
once
you
do
that,
the
signature
contains
the
manifest
digest,
so
you
can
get
to
an
image
from
it,
but
for
most
of
the
workflows,
if
you
are
referring
to
an
image,
I
would
just
go
for
with
the
manifest
digest
of
the
image.
E
A
A
The
thing
is,
when
I
tell
the
docker
container
d,
client,
hey,
deploy
this
thing
and
I'm
referencing
it
by
a
signature,
or
I
have
some
other
infrastructure
that
I
and
I
want
to
reference
it
by
its
signature,
but
my
deployment
would
still
be
hey.
I'm
trying
to
deploy
this
manifest
and
it
happens
to
have
a
signature.
I
trust
we're
trying
to
figure
out
how
this
gets
into
the
workflows
and
are
we
making
things
more?
Are
we
going
to
create
more
confusion.
A
I
was
also
kind
of
thinking
of
another
scenario.
Let's
just
say
that
somebody
wanted
to
build
that
tool
chain.
That
says
I
do
want
to
reference
my
keys,
my
signatures,
sorry,
and
it
does
go
figures
out-
that
manifesto
would
ultimately
deploy,
and
in
that
case
what
happens
if
I'm
saying
this
out
loud,
I
probably
will
finish
realizing.
I
said
something
stupid,
but
if
I
have,
if
I'm
referencing
a
signature
and
ultimately
I'm
revoking
that
signature,
does
that
mean
the
manifest
is
no
longer
valid
or
what,
if
I'm,
that
signature
or
even
the
signature
expired?
A
D
A
The
thought
process
I'm
kind
of
going
through
is
like
you,
have
this
shirt
and
it's
got
a
tag.
That's
the
physical
tag
that
hangs
out
the
shirt
and
it's
got
good
intentions
for
providing
like
how
to
wash
it
and
what
it's
made
from.
But
is
it
sticking
out
so
far
that
it
becomes
something
you
keep
on
pulling
on
and
it's
annoying
and
did
we?
Is
there
something
about
this
design
that
is
annoying
and
creates
confusion,
as
opposed
to
there's,
there's
a
there's,
a
piece
of
what
justin's
pulling
on
that
actually
gives
some
like
powerful
capabilities.
A
A
A
C
A
A
A
Itself
to
be
completely
clear,
I
mean,
I
think,
there's
an
example
up
here,
yeah,
so
here's
the
digest
of
the
config
object,
but
ultimately
you're
trying
to
reference
the
digest
of
this
thing,
or
this
thing
so
in
what
we
were
just
discussing.
What
justin
was
discussing
is
this
index.
If
we
go
with
the
proposal
that
I
that
I'm
proposing
with
examples-
but
you
know
the
other
examples
is
this-
would
be
the
signature,
this
one's
signed
by
wabbit
networks,
this
one's
signed
by
acme
rockets
and
yes,
sorry.
A
A
Okay,
and
if
you
wanted
to
reference
this
by
its
digest
or
tag
of
the
signature
itself,
you
can
absolutely
find
the
thing
it's
signed.
The
way
I've
been
kind
of
go
about
it
is.
I
want
the
signatures
for
this
thing
and
of
course
I
want
the
webbing
network.
Signature
which
I
might
have
a
couple
of
weapon
network
signatures,
because
I
have
the
old
one
in
the
new
one,
but
I
guess
what
I'm
kind
of
getting
is.
A
C
A
A
A
Okay,
so
sounds
like
there's
some
interesting
thoughts
that
we
want
to
experiment
with
putting
tags
on
signatures
and
we'll
see
where
that
goes,
the
the
thing
of
whether
we
do
a
generic
one
or
a
signatures,
one
right
now
we're
kind
of
thinking
of
doing
a
signature
specific
one,
because
the
generic
one,
I
know
has
got
holes
already,
the
other
place,
just
for
the
sake
of
time
that
we
definitely
need
some
feedback
is
there's
a
couple
of
ways
to
do.
Paging.
A
We
absolutely
recognize
that
we
must
have
a
paging
api
in
here
and
it
shouldn't
be
optional.
It's
you
know
whatever,
meaning
that
if
you
only
want
one
result,
that's
fine,
but
we
make
sure
that
the
api
has
paging
built
in
there's
different
ways
of
doing
paging,
so
we're
looking
for
feedback
in
which
people
want
the
tag
listing
has
a
specific
way
of
doing.
Paging.
A
The
google
designs
have
a
different
one.
The
microsoft
apis
have
a
different
one.
I
couldn't
find
I'm
sure,
there's
an
amazon
api
guidelines.
We
couldn't
specifically
find
one.
If
somebody
has
it
great,
we
just
need
some
feedback
on
which
one
people
prefer.
I
actually
don't
have
a
particular
preference.
I
just
want
one.
I
think
that
there
was
some
issues
with
the
way
that
tag
listing
did
it.
That
was
not
fully
thought
out.
I
don't
remember
exactly
where
it
is
so
that's
where
we
can
use
some
feedback
and
folks.
A
A
What
we'd
like
to
do
is
move
forward
with,
and
I'll
obviously
have.
The
conversation
with
the
ocr
group
wednesday
is
move
forward
with
this
design,
where
we
will
rev
the
rev
the
index,
we
will
add
a
config
object
to
it
and
we'll
make
prs
on
the
disk
the
fork
of
the
distribution
spec.
We
have
under
the
notary
project
and
we
would
go
with
the
api
listing
of
signatures
and
the
only
question
we
kind
of
really
have
is
which
api
paging
api
we
would
go
with.
A
I
think
there
was
a
lenience
towards
the
google
apis,
I
think
is
where
I
can't
remember.
If
I
was
leaving
there,
somebody
else
was
leaving
there
or
whatever,
but
we'd
like
what
we'd
like
to
do
is
over
the
next
week
or
two
is
get
this.
The
rest
of
this
end
to
end
working
and
what
I
mean
by
the
end.
Rest
of
this.
A
A
We'd
like
to
get
this,
this
workflow
completed
end-to-end
in
this
picture.
I've
been
talking
with
the
opa
folks
they're
interested
in
writing
an
opa
policy
manager
that
can
look
at
the
content
like
a
signature
that
comes
across
and
says
hey.
If
this
thing,
if
the
signature
doesn't
match
the
registry
I'll
cause
a
failure,
if
there's
an
s-bomb,
that's
in
it
that
references
a
package,
it
could
cause
a
failure,
so
we
want
to
really
try
to
get
these
end
to
ends
working,
even
though
we
know
there's
quirks
that
we
want
to
work
on.
A
We
want
to
see
what
the
whole
picture
looks
like
and
again,
the
analogy
is
back
to
that.
You
know:
you're
building
a
house,
a
socrata,
familiar
kind
of
thing
until
you
can
kind
of
see
the
bigger
picture.
You
can't
see
that
oh
this
little
microcosm
thing
over
here
is
that's
not
even
the
beginning
of
the
issue.
This
other
thing
is
huge,
or
this
whole
thing
looks
so
great
that
actually
I'm
okay
with
that
little
thing
now,
so
we
really
want
to
get
work.
A
A
E
A
Okay,
that's
a
good,
that's
a
good
place
to
start
right
and
we've
been
having
jesse
here.
Thank
you,
jesse.
I
keep
on
forgetting
to
reference
you
also,
so
we
have
jesse
here
from
aws
no
worries,
I'm
I'm
just
trying
to
catch
up
and
try
to
hopefully
be
useful
here
soon.
Okay,
so
our
goal
is
like
we
know
what
it's
like
to
try
to
make
changes
to
aw,
ecr
or
acr
or
the
other
register,
certainly
dockerhub.
So
we
want
to
experiment
here
and
get
comfortable
with
this
indent
experience.
A
So
that's
why
we
originally
did
the
fork
of
docker
distribution
over
here
was
we
wanted
to
make
sure
that
we
had
a
ref
a
place
to
do
reference,
implementation,
changes
and
experiment?
So
we'll
get
this,
you
know
as
we
make
the
prs
for
the
new
apis,
we're
talking
about
we'll
we'll
make
him
here.
So
this
way
we
can
all
experiment,
and
only
after
we're
really
really
really
really
happy.
Will
we
start
looking
at
things
to
do.
A
You
know
on
our
individual
registries
and
josh
bilicky
was
we
had
this
conversation
in
some
place?
I
can't
lost
track
of
where
that
he
was
actually
thinking
of
using
this
and
bundle
bar.
So
we'd
actually
have
like
a
fun
incubation
project
that
we
could
maybe
test
out
some
of
these
experiences
as
well.
A
So
that's
that's
what
I
had
for
today
by
all
means.
So
the
plan
is,
as
we
put
the
notes,
we'll
make
a
branch
we're
going
to
merge
this,
not
this
pr,
the
the
jwt
pr
j,
w
t
p
r
into
that
branch.
If
anybody
has
a
recommendation
for
the
branch
name
prototype
something
prototype
prototypical,
I
don't
know
we'll
figure
out
something
and
then
open
up
issues
and
other
things
on
it
and
then
we'll
hopefully
get
the
distribution
portion
working
this
week.
A
There
is
a
bunch
of
pieces
that
will
fall
out
of
it
because
we've
been
ignoring
index
for
a
while,
because
we
knew
we
had
to
solve
this
index.
Config
object,
we'll
have
to
add
index
support
into
auras
there's
some
other
cleanup.
We
wanted
to
do
with
auras
that
came
up
around
submarine
or
as
to
oci.
So
just
getting
this
piece,
this
next
piece
will
take
us
a
bit,
but
we're
hoping
we'll
make
good
progress
on
that
going
forward
quickly.