►
From YouTube: CNCF Notary Project Meeting 2020-04-27
Description
CNCF Notary Project Meeting 2020-04-27
A
Just
for
inclusiveness,
Nia's
was
pinging
me
offline.
Trying
to
figure
out
who
are
signing
gurus
were
so,
of
course,
I
threw
your
name
there.
All
right
I'll
follow
up
with
you
and
he
had
some
other
windows,
verification
e
thing,
which
I'm
not
sure.
If
is
the
Claire
thing
that
they've
been
working
on
or
what
but
don't
follow
up
with
you
all.
A
So
Justin,
just
for
your
visibility
in
the
last
meeting
Kappas
had
brought
up.
You
know
the
concern
around.
You
know
going
forward
with
that
design
and
so
forth,
and
you
know
I
tried
to
balance
that
you
know.
Of
course
you
know
we
we'd
like
and
Trish
shanks
here
who's
actually
bringing
up
I
just
want
to
make
sure
that
we're
getting
the
right
balance
between
requirements
and
scenarios
and
think
learning
things
we
don't
know.
So
that's
about
it.
A
So
I
I
did
promise
that
we
were
gonna.
Try
to
keep
that's
a
couple
of
us.
I
know
that
Omar
has
been
helping
where
you
can
also
just
try
to
make
sure
we
balance
out
the
the
direct
engineering
work
that
we're
committing
as
well
as
like
is
this
grounded
in
the
scenarios
and
the
requirements
that
we've
been
trying
to
do
so
we'll
we'll
try
to
keep
keep
this
full
circle
kind
of
complete.
You
know
other
work.
We
want
to
do
here,
yeah.
A
Basically,
we
just
wanted
to
get
you
know
you
and
Nina's,
and
some
others
had
brought
up
some
stuff
that
we
hadn't
actually
even
thought
of.
So
it's
you
know.
We
have
plenty
of
things.
We
know
we
have
plenty
things.
We
know
we
don't
know,
and
we
don't
know
of
the
things
we
don't
know
so
we
wanted
to
get.
It
seemed
like
a
good
time
to
kind
of
get.
A
This
thing
started
where
we
get
some
prototype
in
place
to
flush
out
giving
like
a
sketch,
so
the
people
that
keep
it
refer
to
the
subject
matter,
experts
to
come
in
with
things
like
hey:
where
can
you
and
others
plug
in
the
key
signing
efforts?
You're
working
on
this
effort,
certainly
for
an
area
that
we
hadn't,
even
thought
of,
and
how
you
do
offline
key
management
I
had
everybody
while
we
still
work
in
the
counters,
the
basic
persistence
happen
in
a
registry.
A
What
would
the
UX
kind
of
look
like?
How
do
how
do
we
deal
with
things?
We're
tough
brings
in
a
more
detailed
verification.
Where
is
there
a
line
there?
Is
it
part
of
the
core
where
s
bombs
come
in
and
so
forth?
So
by
getting
something
started,
we
can
start
iterating
and
bringing
that
back
to
the
scenarios
and
requirements
so.
B
I'm
right
right,
based
on
our
discussion
about
what
was
the
kind
of
minimal
thing
that
would
make
sense
in
sei
that
we
could
actually
put
in
without
making
a
lot
of
registry
changes
which
was
kind
of
what
we're
kind
of
wants
to
start
prototyping.
Because
I
see
the
question
came
like:
how
do
we?
How
are
we
gonna
store
signatures
and
what?
How
are
we
going
to?
B
What's
actually
going
to
look
like
in
that
week
at
how
many
new
API
is
a
winner
build?
So
the
kind
of
conversation
we
had
was
around?
What
can
we
do
without
changing
very
much
at
all,
so
that
we
have
a
standard
way
of
having
signatures?
That
doesn't
make
any
particular
assumptions
about
what
you're
going
to
do
with
the
signatures
that
we
can
then
prototype
using
this
as
a
layer
to
build
up
I
mean
my
plan
is
to
implement
a
version
of
this,
that's
as
minimal
as
possible,
and
they
use
that
to
build.
For
example,
a.
B
Something
which
has
the
same,
which
basically
is
tough
but
with
slightly
different
documents,
because
so
they
fit
it's
only
in
a
registry
in
native
registry
format,
with
using
this
native
registry
signing
proposal,
so
I
drafted
a
targeted
finish
now,
which
is
basically
a
minimal.
This
is
what
this
is.
What
assigning
in
the
registry
would
look
like,
assuming
that
we're
not
going
to
make
any
other
changes?
The
registry,
and
so
the
minimal
possible
changes.
B
Using
annotations
in
the
short
term,
but
extending
the
extending
that
for
the
descriptors
later
to
have
actual
signature
native
things,
but
it's
just
using
annotations
in
the
very
short
term
too,
so
that
we
can
actually
import
it
without
any
kind
of
difference
to
standard.
It
needs
a
few
more
details
at
the
bottom
but
which,
but
that
was
kind
of
what
I
was
going
to
work
off
to
praise
at
iPad.
We.
C
D
B
B
The
answers
yes,
so
then
you
should
be
able
to
then.
Basically
that
was
those
and
then
I
decided.
I
was
writing
my
document.
Those
were
the
two
important
questions
and
therefore
I
tried
this
fresh
in
the
document
that
just
stated
what
I
thought.
The
most
sane
thing
to
prototype
was
and
see
if
we
think,
there's
any
reason
not
to
do
this.
B
Yeah,
the
answer
is
it's:
it's,
the
normal
outcome
of
having
content
address,
store
and
we
need
to
go
and
introduce
abnormal
means.
If
we
don't
want
that,
and
therefore
it's
kind
of
the
implied
default
and
the
discussion
we
had
was
kind
of,
do
we
really
have
to
produce
a
new
mechanism
and
registries
to
do
signatures,
or
can
we
just
use
existing
mechanisms,
which
is
obviously
way
simpler?.
C
B
A
A
E
B
No
longer
has
the
same
hash
as
the
blunt
object,
because
it
has
additional
signatures,
but
it
contains
a
reference
to
the
ubuntu
object
that
you
can
compare
for
hash
equality
view
ones,
and
you
can
check
the
signatures
on
the
ubuntu
object
independently,
because
it's
the
same
of
ones
who
object
that.
The
the
one
two
of
Jake
and
Josie
niches
is
a
new
object.
And
this
is.
A
B
I
know:
no,
we
know
that
that
proposal
here
is
that
we
don't
do
that.
That
was
adding
an
alternative
API
that
can
point
your
signatures
was
the
other
thing
we
discussed
that's
substantially
more
complex
and
requires
essentially
more
register
changes,
and
this
is
a
straw
man.
If
we
don't
need
to
do
that.
What.
A
B
Yeah,
yes-
and
we
got
to
make
this
as
a
choice-
we've
got
to
make
a
choice
of
whether
we
go
along
with
this
path
that
doesn't
involve
substantial
registry
changes.
If
any
or
we
go
to
a
path
that
says
that
signatures
are
a
new,
require
new
API
functionality
and
potentially
more
substantial
registry
changes
and.
E
B
So
the
question
is:
is
this
the
question
I
mean
my
my
working
hypothesis?
Why
I
want
to
experiment
on
this
is
to
see?
Is
this
usable
for
in
practice
for
doing
the
kinds
of
things
we
need
to
do,
or
is
it
really
too
massively
inconvenient
to
not
have
the
kinds
of
API,
as
we
were
also
talking
about
last
week
which,
where
you
can
ask
for
all
the
signatures
they're
pointing
at
an
item
for
example,
or
have
tags,
have
some
sort
of
scheme
around
that
you
reuse
his
tags
to
provide
that
kind
of
functionality,
and
we.
A
Just
try
to
follow
the
premise
here
and
just
you
know
you
know
before
we
were
writing
the
code.
I
think
there's
a
couple
of
things.
We
could
just
experiment
here,
just
if
I
take
the
for
the
winter
1404
image
and
it's
got
digest
a
I'll.
Just
we'll
keep
things
super
simple
and
it
came
from
a
bun
that
way.
Let's
just
let's
start
a
is
signed,
it
came
from
a
bun
now
I
want
to
sign
it.
A
So
I
push
a
new
index
with
B
so
that
that's
a
new
index
digest
that
has
its
new,
but
it
points
to
digest
A's
so
that
and
then,
when
staging
and
prod
get
added
on
each
one
of
those
machines,
the
layers
don't
change.
So
there's
no
new
caching
of
no
new
poles
happening.
It
mostly
becomes
an
index
pole
and
it'll.
Ask
for
the
layer,
IDs
and
let's
say:
oh
I
already
have
those.
So
it's
really
just
looking
at
that
index
bear
that
index.
That
has
a
signature
in
it
and
points
to
the
existing
content.
Yeah.
B
A
A
B
A
A
Mean
I
still
the
thing
that
I'm
so
basically
you're,
making
an
explicit
call
that
one
I'm
trying
to
destroy
something
I'm
trying
to
say
this
is:
is
it
a
collection
of
signatures
like
when
I
push
yeah?
That
can
be
a
matter
that
multiple
signatures
yeah,
so
the
the
a
bunch
of
signature?
So
by
the
time
it
became
production?
The
index
then
has
a
bunch
of
dead
staging
and
production
signatures
in
its
index
orders.
The
last
indexes
point
at
the
previous
one
and
I
have
to
walk
all
of
the
trees
to
see
my.
B
A
A
Know
it's
fair.
There
is
a
bit
of
an
assumption
of
how
we're
all
implementing
garbage
collections
with
using
these
and
I
think
as
far
as
I
know
we're
we're
all
fairly
consistent
and
that
there's
a
different
style
choices
of
the
direction
people
come
in,
but
I
think
we
all
were
pretty
sure.
We
all
do
the
right
garbage
collection,
stuff,
the.
What
I'm
wondering,
though,
what
is
the
is
there
another
approach
where
we
can
just
push
an
since
you're,
basically
just
pushing
an
index.
Actually
we
I'm
making
assumption.
A
A
B
B
A
On
the
content
that's
being
pushed
was
I
was
wondering
if
it
could
be
reversed
done
I
could
could
we
actually
push
the
the
aspect
of
its
signing
and,
if
any
content
that
backs
up
that
signing
as
an
artifact
and
it's
pointing
through
its
index,
pointing
back
that
we
could
add.
You
know
something
to
registry.
That
says,
give
me
all
the
things
that
reference
this
digest,
which
we
we've
all
been
feeling
pressure
and
some
more
than
others
have
done
more
work.
A
I
think
ways
probably
done
the
most
work
here
where
they
know
more
about
like
when
I
have
a
digest.
I,
we
get
customers
asking
all
the
time
like
what
was
the
history
of
this
tag.
Great
the
tag
now
points
to
this
digest,
but
what
to
talk
to
before,
so
that
I
could
roll
it
back.
What
are
so
keeping
track
of
that
is
an
indexing
problem
and
being
able
to
say
here's
the
abun
two
images,
the
bun
to
image
this
particular
one.
A
What
are
the
things
that
point
to
it
so
that
a
I
could
find
out
what
all
the
signatures
are?
What
are
the?
What
are
the
content
verifications
for
this
thing,
or
it
might
just
be
hey
I,
try
to
free
up
some
space.
This
takes
up
two
gigs
in
my
registry.
What
do
I,
if
I
delete
just
this
one
thing?
I'm,
not
gonna,
free
up
any
space?
My
point
of
the
latter
is.
B
We
can
make
that
decision,
yeah
I,
think
it's,
but
then,
but
if
my
hypothesis
is
if,
if
this
is
good
enough,
then
we
can
implement
it
easily
and
it
has
the
limitation
which
we
could
decide
to
work
around
later
potentially,
but
we
don't
and
we
don't
have
to
require
everyone
to
implement
these
extra
IP
eyes
now.
To
do
right
now
is
repeat
a.
F
B
F
F
The
JWT
and
then
it
would
recreate
the
original
content
and
use
that
so
like
the
problem
is
always
like
when
you're
embedding
this
like,
how
do
you,
how
do
you
actually
recreate
the
JSON
that
you're
signing
so
like
there
was
bugs
there
where
you
could?
If
you
didn't
process
the
JSON
in
the
right
order,
you
could
basically
get
it
to
overwrite
the
part
of
the
content
that
was
actually
being
signed.
Yeah.
F
Just
any
anytime
you're
like
using
content
before
you
verify
it,
there's
always
like
more
surface
area
for
those
type
of
bugs
to
creep
in,
and
the
implementations
yeah
I
mean
yeah
generally,
like
we
use
that
solution
for
a
reason
and
that
it
was
because
everything
was
signed
and
we
moved
to
schema
to
I
mean
that
was
one
thing
that
a
lot
of
us
work
too
happy
about
when
we
move
this
schema
to
is
in
schema
one.
There
was
always
a
signature.
The
problem
is
like.
F
We
didn't
have
a
good
way
to
like
map
that
signature
to
the
keys,
yeah
yeah,
but
like
schema,
we
got
rid
of
it
as
part
of
dota.
Eveyone
essentially
schema
to.
So
much
is
much
better.
So
like
adding
signatures
back
I,
don't
necessarily
think
it's
it's
I
I,
don't
think
it's
a
bad
idea.
I
mean
I.
Think
there's
a
lot
of
good
reasons
to
have
it
there
and
I
know.
F
The
registry
doesn't
really
have
too
much
of
a
problem
with
it,
but
I'm
just
saying
that
we
had
a
couple
years
of
essentially
prototyping
a
solution
like
this,
like
how
tags
change
when
signatures
change
and
how
content
hashes
work
in
this
type
of
world.
So
we
can.
We
can
look
back
a
little
bit
on
that,
but
yeah
I
mean
the
the
problem
was
a
host
just
getting
back
to.
How
do
we
know
the
keys
are
actually
valid
in
this
case.
F
B
B
F
G
G
Just
to
raise
a
meta
point,
which
is
that
so
I
think
this
is
an
important
organization
to
have
right
part
of
the
deal-breaker
requirement
in
note,
3
b2
is
that
we
gotta
keep
the
signatures
to
metadata
whatever
we
call
it
in
the
same
place
as
their
registry,
like
that's,
non-negotiable,
I
totally
get
it
and
I
think
that
how
we
do
this
in
the
most
elegant
way
going
forward.
Whether
now
is
to
add
new
API,
is
a
very
important
discussion
right.
This
is
the
problem.
G
We're
gonna
need
to
solve,
eventually,
I
think
what's
missing,
as
both
Derek
and
Justin
we're
losing
to
earlier.
Is
that
we're
missing
we're
missing
meta
questions
about
key
management?
Ok,
so,
let's
assume
that
we've
solved
this
problem
right,
assume
that
we
have
this
nice
elegant
way
that
doesn't
break
backwards
compatibility.
We
know
where
to
stick
in
signatures
great
now.
The
question
is:
what
do
we
sign?
What
types
of
metadata
who
signs?
What?
How
do
we
handle
threshold
signatures?
G
E
A
I'm
not
sure
what
gap
it
is
that
you're,
referring
to
that
we
haven't
captured
I,
mean
there's
a
style
that
we've
talked
about
that
if
I
once
I
get
the
artifact
stuff,
spec
wrapped
up
I'll
come
back
and
work
on
the
the
other
doc
we've
been
reviewing,
but
I
think
we're
there's
a
what
I'm
hearing
here
more
is
this
balance
between
what
is
the?
What
is
the
implication
to
existing
registries
and
and
the
changes
that
we
want
to
make?
A
E
E
The
threat
model,
or
without
really
understanding
the
threat
model
and
like
really
what
we're
trying
to
achieve
in
this
scenarios
it's
hard
to
know
if
we're
hitting
the
target.
It's
like
the
goal,
isn't
to
isn't
it
just
put
signatures
here
or
there
to
do
things
it's
to?
Have
those
actually
protect
you
from
an
attacker
who
wants
to
achieve
certain
things?
And
so
you
know
like
like
true
shanks,
saying:
hey,
we
need
to
support
threshold.
Signing
I
am
99.9%
sure
that
what
that
tree,
strong
statement
is
correct.
E
If
you'd
had
a
threshold
of
people
going
in
doing
an
operation,
this
would
have
been
much
less
likely,
and
so
the
you
know,
like
I,
feel,
like
we've
all
kind
of
skipped
ahead,
a
few
steps
in
the
process
here
and
and
we're
we're
already
like
starting
to
put
things
together,
without
bothering
to
think
about
where
we're
what
we're
building
towards
in
some
cases,
or
at
least
we
need
to.
We
need
to
finish
that
part
of
the
process.
It
feels
like.
A
Well,
you
know
we
talked
in
the
earlier
call.
We
are
trying
to
make
some
incubations
to
try
to
learn
more
there's
some
gaps
in
what
we
don't
know.
You
know,
and
so
far
we've
been.
Yes,
we
coded
and
blah
blah
blah,
but
we've
been
talking
about
this
since
December
and
we
need
to
actually
start
getting
some
code
in
place
to
learn
some
of
the
gaps
that
we
don't
know.
A
Some
of
the
things
that
there's
some
pieces
around
registry
implications
that
we
need
to
understand
how,
if
we
may
need
to
make
new
api's,
there's
some
understanding
around
key
management,
there's
some
people
that
want
to
be
able
to
start
delving
in
and
already
delving
in
with
a
delving
into
a
space.
We're
not
investing
in.
So
that's
not
helpful.
A
The
we
try
to
care
I
think
you
know
he
said
I've
been
pushing
on
as
the
multiple
signatures
is
one
that
we
have
captured
and
we
need
to
make
sure
we
can
support
that.
How
is
why
I
was
asking
the
questions
if
there's
gaps
in
the
threat
model
that
we
were
talking
about,
that
we
did
have
a
threat
model
working
group
that
you
and
some
others
that
were
on
I'm,
hoping
we
can
get
those
written
down
in
a
way
that
we
can.
You
know,
go
back
and
read
those
like
alright.
How
does
that
address?
G
I
think
is
just
a
gap
in
the
language.
I
think
I
think
what
we
need
to
do
is-
and
this
is
just
my
opinion-
here's
what
I
think
we
need
to
do.
We
need
to
have
a
solid
thread
model
meeting
where
we
all
sit
down
and
we
say:
look
what
are
the
security
problems
we're
trying
to
solve
right?
So,
for
example,
are
we
worried
about
people
just
having
one
signing
key
that
signs
for
everything?
G
A
G
Think
to
be
very
useful
if
they
have
like
a
brainstorm,
whiteboard
kind
of
session.
When
we
draw
pictures-
and
they
say
look,
what
do
we
worried
about
what
what
do
we
think
our
attackers
can
do
who's,
keeping
keys
we're
right?
This
sort
of
discussion
is
yeah.
I
think
this
is
what
Justin
is
trying
to
drive
at
well.
F
I
think
there's
two
differ
conversations
going
on
here
so
like
the
first
is
just
signatures,
just
getting
the
signatures
that
can
be
attached
to
content
and
just
having
some
way
to
verify
that
and
then
actually
doing
the
key
management
which
to
me
sounds
like
it's
more
of
the
hard
work,
because
that's
everything
that
that
toughest
is
helping
us
with
today,
and
without
that
you
know,
I
was
basically
saying
yeah
we
had
the
same
thing
as
schema,
1
and
schema.
One
was
was
worthless
basically
without
without
something
like
tough
but
I
guess.
F
The
question
is:
do
we
want
to
like,
with
notary
v1,
we
squeeze
the
two
together
and
I
think
we
we
see
that
that
wasn't
really
a
usable
solution
either.
So
we
want
to
separate
the
two,
but
what
I
really
want
to
know
is
first
off.
Are
we
okay
with
just
the
way
of
storing
signatures
in
the
registry
and
I
think
attaching
them
to
an
index
or
having
dedicated
api's?
Both
are
good
solutions.
They
both
kind
of
solve
the
same
problem,
which
is
just
linking
signatures
with
content.
But
then
also
are
we
discussing
doing
key
management?
G
A
Ahead,
I
just
say:
I
the
key
management
issue
and
I
I
think
this
is.
We
had
a
working
group
that
was
float
on.
This
they'll
be
good.
If
we
can
revive
some
of
this.
Unfortunately,
a
lot
of
the
same
people
are
in
both
these
working
groups
and
everybody's
got
their
day
job
so
try
to
figure
how
to
make
good
progress
here.
I,
you
know
now
we
have
Brian
from
you
know
and
Sam
remind
me
how
do
I
pronounce
his
name
again:
you're
you're
Brian.
D
A
A
Trying
to
go
back
to
alright,
anyway,
your
expert,
Oh,
Neos
I,
don't
know
if
Brian
or
exactly
comparable
but
they're,
certainly
in
depths
of
areas
that
seem
very
similar
and
why
I
want
both
involved.
The
point
is:
is
that
there's
some?
We
need
to
get
more
people
involved.
We
need
to
make
more
progress
on
it,
we're
trying
to
get
things
written
down
so
that
we
can
review
it.
I
mean
this
is
I
keep
on
asking
Justin
to.
A
Let
me
know
what
he's
thinking
to
keep
son
saying:
I
will
let
me
write
it
down
and
it's
the
best
way
for
this
thing
to
scale.
We
keep
on
referring
back
to
Sam's
doc,
that
you
know
that
he
wrote
up
a
while
ago
on
the
design
options.
So
that's
been
really
helpful
to
write
those
down
so
I
I
guess
I
would
really
encourage.
You
know
Trish,
shank
and
Capo's
here
to
help
us
with
this
threat
model
doc
that
we've
talked
about
that.
A
We
didn't
want
to
put
in
the
that
we
captured
the
scenarios
into
the
scenarios
doc,
but
we
agreed
there
was
another
section:
those
that
should
go
in
not
a
threat
model
of
code,
but
a
threat
model
of
the
kind
of
things
that
you're
referring
to,
because
honestly
you're
bringing
up
stuff
that
I
just
I
just
want
it
to
work.
I,
don't
know
I'm,
trusting
others
will
help
us
figure
it
out,
but
there's
a
detail.
A
E
I
think
there's
a
lot
of
interest
in
doing
that
from
our
side,
like
we'd
like
to
be
able
to
do
this.
I
think
that
part
of
the
problem
is:
is
that
there's
a
lot
of
things
that
are
like
baked
into
what's
in
the
scenarios
that's
hard
for
us
to
go
through
and
do
this
so
we're
really
looking
forward
to
getting
that
like
the
information
that
is
really
at
the
level
that
we
can
do
the
threat
model
work
and
things
like
that
with
and
also
any
description
about
things
that
are
absolutely
hard
requirements.
E
E
Is
this
something
that
I
don't
I,
don't
really
get
exactly
what's
going
on
here,
but
it
feels
like
that
could
be
something
like
a
targets
file
inside
of
something
like
tough
or
it
can
be
something
that
has
a
secure
hash
of
something
in
points
to
it
is
that
is
that
a
fair
reading
of
it,
and
if
so,
I
have
a
fair
amount
of
other
questions
about
related
things
with
the
document.
It's
something
that.
B
You
could
in
principle,
though,
I
mean
the
idea
with
this
I
think
I
mentioned
before
you
came,
was
that
what
I
was
to
do
with
this
is
build,
something
that
makes
sense
in
a
registry
that
you
can
and
as
a
example,
build
out
what
the
tough
metadata
would
look
like
on
top
of
there
s,
so
that
you
this
so
that
we
have
a
registry
native
way
of
storing
tough
assigned
tuff
metadata.
That
makes
sense
from
a
both
from
a
registry
point
of
view
and
from
a
tough
point
of
view.
Ok,.
E
E
When
you
have
scenarios
where
you
have
multiple
people,
possibly
disjoint
sets
of
people
that
want
to
refer
to
the
same
thing
or
you
you
know
like,
and
they
want
to
sign
and
do
things
with
it,
because
if
you
have
the
signature
embedded
and
then
you
have
multiple
people
trying
to
do
it,
then
of
course
it
changes
the
thing
as
you're
as
you're
going.
So
why
I
don't
really
understand
why
this
first
point
why
we
want
to
have
a
signature
embedded
in
the
thing?
D
Just
and
it
might
be
worth
reviewing
a
little
bit
of
the
OCI
image
spec
that
describes
the
relationship
between
the
different
components
that
we're
talking
about.
So
the
image
spec
has
the
definition
for
an
index
a
manifest
and
the
things
that
make
up
a
manifest
and
that's
the
components
for
an
OCI
image.
D
These
are
all
the
things
that
gets
stored
in
a
registry,
and
so
what
just
in
Cormack
stock
is
focused
on
and
what
the
doc
that
I
wrote
a
while
ago
is
focused
on
is:
are
we
able
to
reuse
the
same
concepts
that
are
defined
in
that
image
spec
to
describe
how
the
signatures
can
be
related
to
the
objects
that
are
there
stored
in
the
registry?
So
the
things
like
how
a
signature
relates
to
a
manifest
how
a
signature
could
potentially
relate
to
layers
things
like
that.
F
The
actual
identifiers
that's
used
for
the
image
I
mean
that
that
depends
like
there's
there's
a
hash
tree.
It
just
depends
where,
on
this
has
tree,
you
want
to
call
it
an
identifier,
for
example,
internally
the
runtimes
tend
to
use
the
config
digest,
which
is
much
lower
down
in
the
hash
tree,
because
that
actually
represents
the
file
system.
F
Apart
from
potential
changes
and
light
compression
and
stuff
like
that,
so
like
you
can
you
can
go
up
the
tree
more
and
then
you're
just
changing
you're,
changing
that
hash
of
say
the
index,
which
would
change
the
tag
but,
as
was
mentioned
earlier,
for
example,
if
you're
doing
stuff
like
etags
to
see
if
something
has
changed,
something
has
changed.
There's
a
new
signature
so
from
a
runtime
perspective,
calling
down
a
changed
or
a
new
version
of
that
manifest
is
probably
what's
wanted.
B
So,
just
in
second
effectively
we
we're
saying
that
the
embedded
signatures
is
more
natural
for
a
registry
than
detached
signatures.
That
was
the
other
conversation
we
had
before.
Why?
If
we
want
to
have
two
signatures,
we
have
to
make
a
whole
new
set
of
api's
for
handling
desert
signatures
and
registries,
but
I,
don't
fundamentally
think
it
effects
I
mean
I.
It
shouldn't
make
a
real
difference
to,
for
example,
implementing
tough
in
the
registry,
whether
or
not
we
do
one
or
the
other.
B
E
E
First,
before
I
before
I
point
out
what
I
think
is
a
problem
which
is
that,
are
you
also
envisioning
that
there
is
additionally
a
piece
of
target's
metadata,
or
are
you
envisioning
a
scenario
where
let's
say
that
a
user
Bob
wants
to
go
and
have
three
different
targets,
files
that
they
would
have?
Otherwise,
you
know
listed
as
is
valid
in
their
targets
file,
so
says,
Bob
now
go
and
individually
sign
those
three.
E
Sorry,
I
I'm,
not
sure
I'm
gonna
have
the
right
term
here,
but
the
is
it
the
image
manifest
that
he
signs
for
these
are
the
MA
indexes
or
whatever
he's
saying
for
these.
Does
he
individually
sign
those
and
then
upload
them
in
the
new
proposal,
or
does
he
still
create
a
single
targets
file
that
helps.
E
Okay,
so
in
the
end,
what
you're
gonna
end
up
with
is
you're
gonna
end
up
with
a
targets
file
that
refers
to
the
things
that
you
care
about
and
that
target's
file
is
a
single
file
that
has
a
single
version
that
was
signed
by
Bob,
yeah
and
other
metadata.
That's
that
points
to
it-
and
everything
pointed
to,
or
indirectly
pointed
to
is
all
still
has
secure,
hashes
yeah.
B
G
F
E
Also
saying
you
could
also
do
things
like
I
can
say
well,
tree
shrunk
is
the
one
who
knows
what
the
you
know:
data
dog
images
are
supposed
to
be
there
for
what?
If,
if
you're
asking
me
what's
correct,
then
if
it's
data
dog,
you
should
really
ask
tree
shrunk
and
trust
him.
She
could
do
delegations
and
all
sorts
of
other
things
like
I.
G
F
H
So
you
guys
I'm,
sorry
to
jump
in
here
late
Steve
invited
me
to
come
in
just
just
to
get
some
clarification
about
what
you
guys
are
discussing
so
there's
this
idea
that
we
would
have
the
signatures
contained
in
a
parallel
artifact
to
the
manifest
itself
and
then
placed
and
then
index
correct.
At
least
that
was
as
far
as
I
understand
coming
in
before
right.
H
Sorry,
could
you
repeat
that
yeah,
so
my
understanding
and
forgive
me,
I
haven't
been
in
here
for
a
couple
weeks
because
of
other
unrelated
stuff.
That's
been
going
on
on
our
team,
but
my
understand
is
the
is
that
the
plan
was
to
have
the
signatures
be
contained
as
a
parallel
artifact
within
an
index
you
have
an
index
pointed
to
by
a
tag,
and
then
you
have
the
signatures
and
then
the
manifest
was
that
still
what
we're
discussing?
Where
was
that
design
move
since
then,.
B
H
B
H
So
the
one
thing
I
wanted
to
mention-
and
this
is
just
something
I-
don't
know
if
anyone
here
has
been
tracking
the
discussion-
that's
been
going
on
around
diffs
like
adding
gifts
into
the
UCI
image,
stuff
image,
slash
containers,
if
not
I'll,
send
around
a
link,
but
basically
there's
a
team
of
Red
Hat.
That's
interested
in
adding
this
adding
support
for
layered
ifs
and
they
were
planning
on
doing
so,
like
adjacent
to
a
manifest
and
I
responded
and
proposed.
H
Well,
why
not
just
create
a
new
index
that
points
to
both
the
unmodified
manifest,
as
well
as
the
your
special
gifting
artifact
type,
and
they
had
a
number
of
reasons
they
didn't
want
to
do
that,
and
so
their
current
plan
is
to
basically
have
a
naming
convention
where,
if
you
have
a
tag,
foo
they're
going
to
have
like
Delta's,
foo
and
I'm
not
very
excited
about
this
idea.
But
it
occurs
to
me
that
there
seems
to
be
a
similar
open
question
here,
which
is
ideally
right.
H
A
B
H
B
I'm
not
I
mean
no
I,
those
various
points
that
we
just
come
up
they're.
Actually,
the
objects
that
are
the
old
signed
object
and
the
differently
signed
object
are
still
actually
valid
objects
that
you
might
want
to
refer
to
for
reasons
so
I
kind
of
think
that
the
signatures
modifying
my
trainings,
adding
a
new
signature
zone
modifying
the
thing
is
potentially
a
feature,
not
a
bug,
but
this
was
a
I
think.
That's
why
I
kind
of
wanted
to
prototype
it.
They
say
that
well,
I
mean
Derek,
pointed
out.
B
H
So
one
of
the
things
I'm
giving
some
thought
to
you
the
last
couple
days
after
hearing
about
this
gift
thing
and
now
thinking
about
it
from
the
stand
I
by
the
way.
What
I'm
about
to
say
is
not
a
proposal.
I
could
be
wildly
off
I'm,
simply
going
to
toss
an
idea
into
the
air
and,
and
then
everyone
can
rip
it
of
shreds
and
that'll
be
good.
In
that
way,
one
of
the
things
I've
been
thinking
about
is
there's
deathly.
H
Scenarios
where,
like
an
index,
is
referring
not
to
different
information,
I'm,
sorry,
not
to
different
versions
of
something,
but
rather
to
metadata
about
a
particular
manifest
right
like
so
for
an
image
metadata
can
consist
of
diffs
signatures.
Maybe
even
you
know
variants
of
that
of
that
particular
manifest
and
I'm
wondering
and
again
this.
A
Been
that
piece
that
I've
been
trying
to
poke
at
is
there's
always
this
cause
and
effect
like
which,
which
what
is
the
intent
versus
the
result
and
the
thing
as
much
as
we
try
to
promote
there's
a
best
practice.
We
believe
that
tags
are
the
way
to
you.
Do
things
and
you
do
unique
tagging
and
then
there's
features.
A
You
add
four
unique
tagging
and
blah
blah
blah
that
people
do
use
deployments
with
digests
and
the
idea
that
we
have
to
change
the
reference
of
the
digest
just
to
be
able
to
get
a
signature
is
the
part
that
I
struggle
with.
If
we
can
say
and
granted,
this
is
a
new
API,
but
we
already
have
a
new
API
is
just
to
support
notary,
so
registries
that
don't
currently
support
signing
in
this
notary
or
the
ones
that
do
we're
gonna
change.
Anyway.
A
It's
not
a
bad
thing
to
add
some
api's
the
if
I
can
keep
the
digest
of
the
thing
that
originally
came
from
a
bun
and
that
doesn't
ever
change,
but
I
could
add
signatures
to
that
and
then
I
could
at
any
time
you
use
this
granted
new
API
and
say
what
are
the
signatures?
What
are
the
things
and
the
signatures
could
have
content
I'm,
not
trying
to
exclude
any
of
the
tough
conversations
the
either?
A
What
are
the
things
that
reference
this,
but
I
still
can
always
reference
it
by
its
digest
and
original
tag,
and
if
that
means
I
can
now
get
you
know,
regardless
of
how
we
store
it
right
there
I
just
she's
got
a
really
powerful
way
of
storing
these
things
that
we
have
the
ability
to
digest
the
thing
from
a
bun
to
didn't
ever
change.
The
still
the
you
know.
A
B
A
I
think
in
a
rip
on
there,
because
I
think
that
if
we
like
with
places
that
get
me
nervous
about
things,
we
change
into
the
registry
or
like
the
storage
infrastructure
that
we've
all
had
spent
years.
Making
robust,
creating
and
in
some
registries
like
quai,
have
gone
much
further
on
doing
really
rich
indexing,
while
others
have
been
reluctant
to
do
database
e
things,
because
you
know
various
reasons
we're
getting
dragged
into
it.
A
We
are
adding
it,
but
the
adding
an
API
that
can
do
some
better
indexing
over
content
that
we
could
already
store
with
the
rich
informations
already
there.
That
feels
a
minimalistic
thing
that
we
could
do
and
really
provide
a
lot
of
value
there.
Just
maybe
it's
part
of
this
exercise
for
you
for
what
are
the
areas
we
do
not
want
to
touch
because
it's
hugely
impactful,
it's
scary,
it's
gnarly
whatever!
And
what
are
the
places
that
hey?
It's
easy
for
us
to
touch
in.
B
A
B
F
G
Guys,
unfortunately,
I
need
to
go.
It's
3:00
p.m.
but
I.
Think
I
think
we
need
to.
We
really
need
to
arrange
another
meeting
where
we
discuss
high-level
meta
questions
like
this
before
we
go
further
cuz,
otherwise
I'm
I'm
afraid
we
will
accidentally
spin
around
in
cycle
circles.
How
should
we
arrange
this
meeting?
What
do
you
think
Steve
well.
A
We've
been,
you
know,
we're
a
ting
here.
I
think.
The
piece
that
we've
been
discussing
is
there's
a
bunch
of
things
that
we're
obviously
trying
to
solve
from
a
court
registry
implementation
and
that's
why
I
sucked
in
Joey,
because
he's
probably
done
some
of
the
more
advanced
stuff
and
long
deep
thinking
of
how
to
index
and
do
stuffs
and
registries
there
is
this
persistence
model
is
how
do
we
learn
from
the
stuff
that
we
did
in
v1
and
went
to
v2
and
maybe
there's
some
stuff
from
v1?
That
was
still
good.
There's.
A
Another
aspect
that
you
guys
are
bringing
you
and
Kappas
and
I
hope
you
guys
don't
mind
me
using
your
last
name
as
referenced,
because
so
many
Justin's
now
at
least
two
that
there's
a
set
of
details
of
threat,
modeling
and
security
that
you
guys
are
making
sure
that
we
think
of
but
I
want
to
make
sure.
We
include
that,
but
I
think
there's
a
gap
in
understanding
how
the
problems
were
wrestling
around
from
the
registry,
so
I
think
it
was
Sam.
Somebody
put
it
in
a
link
to
some
of
the
specs.
A
If
you
they're,
not
that
big
they're,
you
know
you
can
take
a
look
at
this
I
think
that'll
help
understand
some
of
the
problems
we're
wrestling
with
that.
We
can.
You
know
kind
of
keep
these
conversations
going,
because
there's
a
center
of
these
conversations
I
think
we
still
need
to
solve
its
the
each
team
bringing
their
expertise
in
and
how
do
we
have
enough
information
about
that?
That
can
make
the
conversations
more
efficient
and
collaborative
and
if.
C
A
Could
help
so
as
Prabhas
read
up
on
those
they're,
not
that
big
and
if
you
could
help
scribble
down
some
of
the
the
threat
model,
things
that
you
were
doing,
some
of
which
I
captured
in
the
scenarios
that
Justin
gave
me
earlier.
There
was
some
that
we
said
should
be
in
this
other
doc.
If
you
can
help
us
with
that
expertise,
I
think
we'll
be
able
to
have
the
basis
to
continue
moving
forward.
Yeah.
G
Well,
I
think
I
think
that's
a
great
idea.
I
think
Justin,
Marina
and
I
should
take
a
look
at
this
documents
that
Carmack
and
and
others
have
produced
on
sam'l
and
and
think
about
it
from
our
trend
model,
point
of
view
and
add
to
it
right
and
run
it
by
you
guys
and
see
whether
we're
all
speaking
the
same
language.
What
do
you
guys
think
Kappas
and
marina.
A
Great
thanks
folks
I'll
were
already
past
and
people
have
to
go.
Let
me
figure
out
with
the
the
challenge
were
trying
to
do
is
figure
out
how
to
do
time.
Zone
management
with
you
know,
East
Coast
is
not
as
hard
but
compared
to
Justin
and
he's
got
a
lot
of
us
time.
Meetings
he's
trying
to
meet
at
the
same
time.
So
it's
we
have
a
narrow
window.
Sometimes
let
me
figure
out
the
next
time.
Can
we
do?
We
want
Justin
Cormac?
What
do
you
can
you
do
for
a
next
meeting?
Can.