►
From YouTube: CNCF Notary Project Meeting 2020-06-22
Description
CNCF Notary Project Meeting 2020-06-22
A
C
C
A
Guessing
that
we
have
a
small
group,
because
while
we
talked
about
going
from
ten
to
eleven
last
week
and
Amy
did
update
the
calendar,
that
people
are
forgetting
that
we
have
10
to
11
now
so
I'm
happy
to
start,
because
I
think
I
was
just
reading.
Marinas
tough
document,
which
there's
just
a
couple
of
PIFAN
ease
in
there.
That
I
think
help
with
I.
Think
some
of
the
confusion
we've
had
in
some
of
the
conversations.
B
Yeah
one
thing
I
do
want
to
mention
is
that,
even
though
tough
has
update
in
the
name,
that's
the
you
and
tough.
It
is
also
used
for
initial
software,
installation
lots
and
lots
of
times
in
places
as
well.
So
it's
you
know
like,
regardless
of
what
your,
what
you're
doing
with
it,
whether
you're
doing
an
actual
update
of
something
where
you've
already
established
like
have
an
earlier
version
or
whether
you
want
to
install
something
new
tuff
is
meant
to
handle
that
case
securely
and
well.
A
B
That
means
is
that
so
we're
not
going
to
prescribe
whether
you
do
some
way
of
trust
on
first
use
or
how
you
get
like
a
bundle
of
things
inside
your
client
in
in
practice.
What's
always
the
best,
if
you
know
what
repo
you're
going
to
communicate
with,
which
register
you're
gonna
communicate
with
which
maybe
you
do,
then
it's
always
the
best
to
just
ship
some
version,
even
an
old
version
of
at
least
the
route
metadata
for
that
which
is
much
smaller
than
you
know.
A
A
A
A
A
Justin
Marina:
do
you
want
to
do
the
metadata
overhead
conversation
first,
I
mean?
Is
that
less
important
to
have
people
here
for
I
it's
recorded,
and
we
at
least
have
some
people
here.
So
I
am
open
to
suggestions
on
just
I
know
that
you
know
this
is
the
only
person
for
the
the
key
stuff
that
I
know.
Others
are
also
like
participants
and,
where
I
see
you
guys
being
the
ones
that
driving
this
conversation.
So
at
least
it's
recorded
up
to
you
guys.
B
B
B
Basically,
the
spreadsheet
we
sent
out
shows
the
the
overheads
and
other
things
with
this,
and
the
comparison
page
is
really
the
only
page
you
need
to
look
at
if
you
want
to
get
the
actual
kind
of
bird's-eye
view
of
what's
going
on.
If
you
really
want
to
dig
into
exactly
how
everything
was
computed
than
the
other
sheets
make
some
amount
of
difference,
and
we
also
look
at
what
the
sizes
of
different
things
are
for
a.
B
I
think
there's
a
typo
here,
but
for
a
registry
with
a
single
image
and
registry,
with
200
million
images,
which
is
I,
think
the
size
of
docker
rockers
registry,
this
I
can
fit
and
in
either
case
the
the
actual
overhead
numbers
we
show
there.
We
color-coded
this
to
try
to
say
what
we
thought
like
would
make
sense,
but
of
course,
just
left
the
numbers
there.
If
you
have
a
large.
A
B
Well,
we're
trying
to
see
what
the
what
the
overhead
would
be
in
essence
for
going
in
and
actually
like,
producing
appropriately
stein
metadata
and
things
that
would
allow
you
to
verify
that
images
haven't
been
excuse
me
that
they
haven't
been.
The
metadata
hasn't
been
tampered
with.
You
don't
have
all
data
being
replayed
and
so
on.
B
So
in
the
end,
what
we
did
is
we
looked
at
we
need.
We
got
some
numbers
from
Dustin
Cormac
that
were
very
helpful.
We
also
went
and
look
at
sizes
of
things
where
we
tried
to
go
and
look
at
what
he
liked.
Existing
systems
would
have
are
used
in
different
sin
areas,
how
much
overhead
that
would
be,
and
then
we
took
the
proposal
that
that
we
I
guess
called
it
the
Lasker
proposal,
because
I
don't
know,
that's
perfectly
accurate,
but
it
I
think
the
solution
that
we've
seen
you
prevent
and
talk
about
the
most.
B
So
we
named
it
that,
because
I
think
that
just
made
it
easier
for
us
at
least
to
keep
track,
which
was
which
and
we'd
compare
the
overheads
of
all
of
these
in
all
the
different
scenarios,
to
see
kind
of
what
the
cost
would
be,
and
we
talk
in
more
detail
about
how
these
costs
were
derived.
But
basically,
the
way
we
propose
to
set
this
up
and
the
green
options
are
the
ones
we
think
are
good.
A
B
The
numbers
here-
ok,
so
there's
there's
two
things
that
we
looked
at
here,
but
the
main
thing
that
this
looks
at
is
it
looks
at
the
the
actual
size
overhead
of
doing
the
transmissions
of
data.
We
also
for
this
I
can't
highlight
this
well
for
the
fresh
client
option
for
tough
to
design
option
2
it's.
This
is
what
a
client
that
no
previous
state
is
gonna
get
which
is
okay,
but
it's
not
great.
B
So
the
reason
why
this
is
sort
of
yellow
from
you
know,
yellow
colored,
is
from
a
security
standpoint
you're
not
as
as
well
off
as
you
would
otherwise
be
II.
That's
also
why
this
column
here
is
is
red
because
of
the
security
concerns
that
we
talked
about
over
the
past.
Like
many
meetings
related
to
not
having
some
kind
of
snapshot
metadata,
and
then
we
did
comparisons
to
look
at
really.
B
B
We
think
the
overheads
are
small,
both
for
a
single
image
and
large
public
repo,
and
so
the
options
that
we
ended
up,
selecting
here,
because
we
few
these
overheads
as
negligible
we
chose,
we
would
recommend
the
option
that
has
the
best
security
for
for
the
users
as
a
good
option,
because
something
like
a
point:
zero,
zero,
two
percent
overhead
or
a
point,
zero.
Four
percent
overhead
is
feels
like
a
drop
in
the
bucket
to
pay
for
getting.
You
know,
improved
security.
D
A
couple
of
comments
here,
one
I,
think
the
clarification
definitely
helps.
It
was
a
little
bit
confusing
to
me
because,
when
I
was
looking
at
it
from
a
signature
overhead
perspective,
it's
not
clear
to
me
why
some
of
these
options
are
not
recommended.
I
think
I
would
make
that
a
call
out
in
the
dock.
D
That
says
these
options
are
not
recommended
for
exploit,
agree
arenas
and
maybe
in
the
dock
I'm
just
kind
of
looking
at
this
really
quickly,
but
that
best
tenants
is
definitely
does
help
that
there's
something
in
addition
to
the
men
data
overhead
that
we're
looking
at
the
other
question.
I
have-
and
this
is
something
where
I'm
not
familiar
enough
with
registries,
but
are
there
other
overheads
that
we
should
also
look
at
in
terms
of
like
the
time
to
pull
down
signatures
and
compute
them?
That
should
also
be
included
in
this
overhead.
B
Yeah,
we
can
certainly
add
things
like
that.
In
practice
we
haven't
found
that
to
be
problematic,
I
mean
even
a
like.
You
know
even
the
little
embedded
systems
that
people
use
in
automobiles,
that
you
know
the
signature
like
doing
a
couple
of
signature.
Verification
isn't
a
big
deal
for
an
ECU,
and
the
the
really
expensive
thing
here
is.
The
is
is
like
you
know,
would
be
something
like
private
key
signing,
which
you
know.
Even
then
you
do.
B
Tens
of
thousand
per
second
doing
verifications
will
substantially
faster
than
that
and,
if
you're
doing
something
like
which
I
don't
think
you're
doing
will
be
doing
anything
more
complicated.
But
but
you
know
the
actual
time
overhead
here
is,
you
know,
think
of
it,
like
you
know
like
like
TLS
or
something
like
that
it
just
it
really
gets
kind
of
lost
in
that
at
least
some
practice
has
has
always
been
sort
of
lost
in
the
in
you
know,
in
the
sea
of
other
things,.
D
Yes,
that
I
was
gonna
say
what
we've
usually
done
in
the
past
is
just
compare
that
to
the
time
it
would
take
to
deploy
an
artifact
without
a
signature
versus
time
to
deploy
with,
and
that,
like
you
know,
if
we
consider
other
options
down
the
road
I
think
the
distinction
here
would
help
call
out
why
cuff
might
be
a
better
solution
right
like
if
the
implementation
from
the
topside
just
adds
very
little
versus
sort
of,
like
some
other
signature
validation
as
significantly
more
validation.
Time
I
think
that's
a
data
point
to
have
as
well.
A
D
B
Don't
have
the
numbers
in
front
of
me,
but
you're
number
one
like
as
you
would
download
it.
You'd
usually
compute
that,
but
even
if
you,
if
you
don't
in
terms
of
actual
crypto
operations,
you
can
do
like
many
many
I
think
I
I'll
run
the
numbers
you
can
do
open.
Ssl
speed
on
this,
but
but
doing
like
secure
hashing
over
data
is
extraordinarily
fast
on
a
modern
computer.
So
it's
just
not
I
I,
don't
know
it's
not
something
that
that
we've
we've
had
really
a
concern
with
anybody.
B
Who's
deployed
or
tried
it
in
practice,
but
we
can.
We
can
get
some
number
it's
just
like
I
mean
you.
You
do
all
these
things
to
when
you
do
a
download
over
HTTP.
So
you
know
if
you're
going
to
see
something
like
that
slow
down,
which
is
is
imperceptible,
so
yeah
I,
don't
know
I
mean
we
can.
We
can
look
at
it
but
like
in
practice.
What
we've
seen
is
latency
and
bandwidth,
or
a
much
bigger
contributors
to
this.
B
A
I'm
still
trying
to
figure
out
what
exactly
you're,
comparing
here
I
mean
because
the
the
method-
it's
not
clear
to
me,
what
methodology
or
even
what
problem
you're
trying
to
solve
here,
because
you've
done
a
great
job
saying
yes,
this
one
is
red,
it
must
be
bad
and
this
one's
green.
It
must
be
good
and
there's
numbers,
but
there's
nothing
really
explaining
what
it
is
you're
trying
to
accomplish.
If
I'm,
taking
a
image
and
I'm
trying
to
get
its
signature
back,
then
I'm
not
sure
why?
B
Document
we
have
has
like
outline
some
of
the
security
problems
and
shortcomings
with
proposal
of
just
retrieving
a
signature.
This
notion
of
like
something
is
signed.
Therefore,
I
trusted
is
problematic,
and
so
what
we've
done
here
is
this
document
is
focused
on.
What's
the
overhead,
that
is,
you
know
that
you
would
have
if
you
actually
provide
protection,
that's
greater
than
just
having
something
that
has
a
signature
somewhere
that
may
or
may
not
be
out
of
date
and
no.
A
A
That
is,
you
know,
software
base
images
that
are
people
depend
on
and
they
are
intentionally
a
single
version,
a
tag
that
references
it
as
a
version,
and
we
do
want
to
get
updates
to
that
and
we've
built
stuff
in
a
jar
specifically
to
enable
getting
updates
to
that,
not
not
from
a
security
perspective,
just
a
notification
that
an
update
has
happened.
The
digest
has
changed
for
a
given
tag.
So
that's
an
important
problem
for
base
images.
A
You
know
like
operating
systems
like
Linux
and
Windows
and
various
permutations
of
each
and
so
forth,
and
the
runtimes
that
are
sitting
on
top
of
them,
but
when
customers
builds
something
from
that,
they
don't
want
an
update
to
that
thing,
because
that
an
update
to
that
thing
that
they're
building
is
a
specific
deployment.
They
want
to
secure
supply
chain,
that's
not
a
secure
supply,
they
want
a
supply
chain.
A
That
says
something
changed
might
be
the
source
itself
that
changed,
that
I've
made
an
update
and
I
want
to
push
that
or
the
thing
I
depend
on
changed
and
I
want
an
update
from
that.
So
I
think
we
have
to
tease
out
the
two,
because
the
the
apps
that
people
built
should
not
get
updated
tags
that
there
would
be
any
update
specific
to
that.
So
I
think
we're
just
watches
for
the
problem.
I.
B
I
think
the
people
that
want
to
have
what
the
updated
tag
points
to
you
should
get.
What
the
updated
take
points
and
people
that
want
to
have
a
version
should
get
a
version.
A
specific
version,
I
think
think.
We
agree
on
that
and
I
think.
We
also
agree
that
it
would
be
bad
if,
if
a
potentially
malicious
actor
could
give
somebody
that
said,
they
wanted
the
latest
version,
an
old
version
that
has
security,
vulnerabilities
or
other
things
like
that.
B
You
know
trying
to
show
that
the
added
security
you
get
from
doing
things
this
way
doesn't
come
at
the
cost
of
usability,
doesn't
come
at
the
cost
of
overhead
and
so
on,
and
so
you
know
we're
we're
trying
to
present
this
in
as
clean
of
a
way
as
we
can
so
that
others
can
can
look
at
this.
And
then
you
know
like
get
the
the
protection
that
they
should
have
for
their
users,
because
the
last
thing
that
that
we
want
is
for
there
to
be
a
security
incident
and
to
have
users
at
substantial
risk.
A
A
A
B
I
was
I
preface
what
I
was
saying
by
saying.
So
in
the
case
that
the
clients
have
state
okay,
then
then
there's
this
protection.
Okay.
So
in
the
case
that
the
clients
do
not
have
stayed,
then
there
are
a
few
means
to
deal
with
this,
so
presumably
they
have
they
have
the
route
metadata
or
something
else
from
that
registry
that
they're
going
to.
B
E
B
B
It's
a
Merkle
tree
of
what's
in
the
repo
okay
and
what
we
go
here
with
the
numbers,
and
things
is
that
you
know,
even
though
the
absolute
data
is
modestly
large.
It's
not
actually
that
large
in
in
registry
terms,
or
you
know
like
real
terms.
It's
it's,
you
know
it's
you
get
the
data
and
the
data
clients
download
is
small
because
you
only
need
to
download
their
path
to
the
Merkle
tree.
Are.
A
B
B
B
A
Do
because
there's
different
owners
of
each
one.
So
that's
why
I'm
struggling
because
the
one
of
the
options
that
we
keep
on
talking
about
is
putting
everything
together.
But
we
haven't
addressed
any
of
the
security
issues
where
those
are
fundamentally
different
owners
and
teams
that
there
and
we
have,
depending
on
the
registry
and
how.
B
We
talked
about
that
in
the
document
quite
a
bit.
If
there's,
if
there's
parts
that
are
in
there
that
aren't
clear
or
need
more
expert
exploded
position,
we
can
always
do
more,
but
this
this
is
something
you
know
like
the
way
to
think
about.
It
is,
if
you
imagine,
for
a
moment,
you
have
all
these
separate
repose,
which
is
fine
just
think
of
it.
That
way,
they're
all
totally
separate,
now
think
for
a
moment.
B
D
Just
really
quickly
before
we
move
to
that
I
think
what
we're
essentially
having
is
a
conversation
around
the
design
itself
right
I
think
the
metadata
doc
could
easily
circumvent
that
by
just
calling
out
what
makes
sense
for
metadata
perspectives,
because
I
think
the
the
conversation
we're
looking
more
at
is
this
design
actually
work
or
not
and
there's
a
lot
of
other
considerations
we're
taking
in
there.
But
this
talk
on
its
own
from
a
size
perspective
just
can
call
out
what
are
the
options
that
make
sense
or
not
right,
I.
D
Think
it's
saying
a
lot
more
about
options
without
really
covering
the
content
of
like
what
those
decisions
are
we
just
called
out
in
a
different
doc
and
I
think
you
know
just
separating
out
what
the
recommendation
here
is
based
on
size,
verses.
We
look
at
the
the
other,
doc
I
think
would
make
more
sense
just
for
keeping
context.
A
Thanks,
no
yeah
I
think
here's
the
thing
Justin
like
the
what
I?
What
you've
got
me
labeled
is
me,
you
know,
is
some
snapshot,
no
snapchat
proposal,
all
I'm
saying
there
is:
there
is
a
way
to
go,
find
content
using
this
reverse
lookup.
So
it's
not
excluding
any
metadata
conversation
so
I,
don't
so
that
label
one
bad
versus
the
other.
That's
what
I'm
just
trying
to
understand
what
it
is
you're
trying
to
say
that
the
concerns
we've
had
is
not
that
you
is
a
registry,
especially
docker
hub,
which
is
meant
for
the
world.
A
To
put
content
on
is
intentionally
segmented,
and
then
you
have
private
registry.
Is
that
even
though
they're
private
to
a
particular
customer,
they
still
have
multiple
teams
sharing
content
in
that.
So
how
do
we
account
for
a
set
of
dock,
a
set
of
content
that
needs
to
be
secured?
The
first
is
just
is
it
signed,
and
then
you
have
a
second
level
of
security
which
we're
not
pushing
back
on
that?
It's
not
valid,
it's
just
where
what
is
the
trade-off
of
it,
that
an
update
can
be
somehow
verified,
so
I
think
it's
just.
F
F
It's
just
sure
the
feasibility
of
adding,
in
addition
to
just
signatures,
if
you
add
this,
the
second
level
of
repository
security,
just
the
main
ideas
that
it
doesn't
add
so
much
extra
metadata
for
the
client
to
download.
But
it's
like
infeasible
for
them
to
do
it,
that's
kind
of
the
the
main
idea,
and
then
you
know
you
can
do
it
into
the
numbers
and
figure
out.
You
know
exactly
how
much
extra
is
it
and
what
does
it
mean,
but
I
think
that's
the
big
takeaway.
A
A
F
B
B
The
estimates
which
we
expected
me
right
within
a
factor
of
you
know
like
maybe
maybe
two
something
like
that
could
be
slightly
larger
or
could
be
slightly
smaller,
but
it's
not
going
to
be
substantially
off
and
the
growth
rate
is
is
about
right,
so
it's
I
may
be
giving
marina
not
enough.
Credit
I
think
her
numbers
are
a
lot
more
right
than
that,
but
as
as
like
new
interesting
cases
or
things
like
that,
like
a
merge,
if
there's
some
weird
trying
to
think
of
even
what
this
would
be.
B
But
if
somebody
is
scattering
massive
amounts
of
small
oti
metadata
or
something
like
that,
then
maybe
you
know
maybe
that
like
changes,
one
of
the
terms
in
the
spreadsheet
slightly,
but
in
general
we
did
I
think
a
pretty.
We
tried
to
be
very
thorough
about
this,
so
that
it
was
a
really
fair
comparison
and
it
was
really
factually
based
on
the
information
we
got.
A
Okay,
all
right
I
mean
one
of
the
things
we
can
look
at
I
mean
the
the
prototyping
that
we're
looking
at
doing
will
should
be
able
to
give
the
opportunity
to
be
able
to
put
this
information,
I
think
the
the
biggest
problem
or
the
biggest
concern,
and
if
you're
saying
that
this
doc
talks
about
it,
then
we
can.
We
can
certainly
address
it,
but
the
biggest
concern
is:
how
do
we,
as
registry
operator,
secure
any
content
across
different
repos,
because
by
definition
there
should
be
no
team?
A
B
Let
me
just
talk
about
that
real
quick,
because
that's
come
up
a
couple
of
times.
The
kind
of
TL
DR
is
already.
You
have
mechanisms
that
protect
like
the
different
repositories
on
the
same
system
from
this
like
on
the
same
registry,
so
you
already
have
all
kinds
of
access
control
for
this
okay,
you
can
view
this
snapshot
as
just
being
extra
like
metadata.
That
happens
to
be
the
same
for
every
repository,
but
nothing
else.
None
of
the
other
files
change,
okay
and
then
there's
one
other
property
of
this
metadata.
B
That
is
important,
which
is
that
I.
If
I
give
you
like
your
path
to
the
root
of
the
Merkel
tree,
you
have
no
idea
and
no
way
to
prove
that
anything
else
is
in
that
Merkel
tree
so
like.
Basically,
it's
not
that
you
can't
just
go
like
poking
around
and
looking
at
things,
because
of
the
way
that
the
we
do.
B
The
secure,
basically
you're,
given
the
secure
hash
of
things
and
you'd,
have
to
be
able
to
go
backwards
from
the
secure
hash
to
be
able
to
get
any
meaningful
information
about
what
anybody
this
is
doing
and
the
whole
reason
for
my
secure
hashes
are
secure
is
because
you
can't
go
backwards
from
the
hash
to
find.
The
original
thing
know.
A
Something
that
I'm
not
are
you
saying
that
the
if
I
had
if
Team
B
had
access
to
team
is
secured
hashes,
they
couldn't
recreate
the
actual
content.
I
think
that's!
What
is
that?
What
you're
saying
yeah,
but
the
question
is:
how
did
Team
B
even
get
access
to
team
a's
metadata
in
the
first
place,
and
why
okay.
B
B
It's
like
you're
doing
one
signature
on
the
registry
and
that
one
signature
has
a
whole
bunch
of
secure
hash
is
listed
under
it
and
it
doesn't
you
don't
know
who
those
hashes
are
for
what
those
hashes
mean
or
anything.
What
you're
told
is
that
if
your
hash
is
there,
then
then
the
thing
was
fine
by
the
registry
right,
and
so
it
doesn't
matter
what
those
other
things
are.
It's
they're
just
they're,
just
hashes
right,
that's
effectively
what
like
what
like
a
completely
flat,
Merkle
tree,
would
look
like,
which
would
be
really
inefficient.
B
There
wouldn't
be
a
reason
to
do
it,
but
you
can,
you
can
see
I
think
you
can
see
conceptually
why
the
security
property,
the
privacy
property,
you
have
you
get
it
there
and
in
fact,
the
inside
the
document
there's
there's
a
description
about
how
even
with
oh
sorry
did.
Somebody
else
want
to
say
something.
B
Okay,
even
if
you
like,
knew
the
person
you
were
next
to
somehow
in
the
tree
like
you
were
at
a
company
and
you
had
the
previous
metadata
and
you
went
and
knew
that
this
hash
course
bonded
somehow
did
this
party
when
you
generate
the
new
thing,
you
can
just
put
the
like
the
timestamp
of
the
thing
you're
doing
in
that
your
hash,
and
it
makes
it
so
that
everything
moves
randomly
in
the
tree
anyway,
because
you're
adding
an
extra
piece
of
information
into
every
to
the
secure
hash
as
you're
doing,
and
so
it
really
doesn't
it
it's
one
of
these
things
that
sounds
more
complicated
than
it
is
it's.
G
G
Sorry,
if
it
helps
Steve
I
was
also
pressing,
just
in
a
marina
for
a
bit
more
details
on
how
this
would
preserve
privacy.
So
so
let
me
try
to
see
if
I
can
use
different
words
to
try
to
assuage
your
concerns.
What
Justin
is
saying
is
correct.
The
Merkel
tree
is,
it's
got
a
whole
bunch
of
leaves
under
it.
Billions
of
leaves
whatever
it
is,
and
the
point
is,
unless
you
know
what
you're
looking
for
the
key
in
the
end
in
the
tree,
you're
not
even
gonna,
know
that
it
exists
right.
G
Yeah,
so
so
what
if
you
need
a
key?
What
if
you
could
guess,
for
example,
oh
I
know
that
Microsoft
is
working,
maybe
I
know
the
codename
for
this
project.
I'm
I'm
gonna,
try
to
query
this
key
and
see
if
it
exists
in
the
tree
right.
That's
the
larger
concern
here
and
I
ran
through
this
with
them,
and
so
the
way
the
thing
that
needs
to
be
hidden.
So
the
snapshot
has
got
all
this
leaves
in
there.
G
That's
for
sure,
and
if
he
knew
the
key,
you
could
try
to
guess
and
then
query
the
the
snapshot
for
it.
And
so
what
do
you
need
to
do
is
to
obfuscate?
You
need
to
hide
the
the
key
names.
That's
the
more
important
thing
and
the
way
you
would
do
this
is
by
using
existing
access
control
mechanisms.
You
really
have
a
private
images.
If
you
don't
know,
if
you
don't
have
permission
to
to
see
the
key
you
won't,
you
won't
be
able
to
query
it
in
the
first
place.
G
Now,
if
you
knew
the
key,
for
example,
if
you
could
somehow
guess
it
and
you
could
guess
you
could
guess
you
could
quarry
the
snapshot
for
the
way
to
solve
that
problem.
Is
by
obfuscating
your
your
true
things.
You
know
you
don't
want
to
give
the
way
you
don't
use
the
direct
code
name,
for
example,
maybe
use
something
else.
Does
that
make
sense?
Well.
A
B
A
B
A
I
gotta
put
ok,
so
that
is
the
propose.
So
now
what
I'm
asking
is
how
what
is
it?
You're
expecting
like
the
two
teams
using
the
shape
same
registry,
especially
if
they're
private
don't
have
what
you're
kind
of
making
your
argument
is
team
B,
even
if
I
got
team,
a's
secure
metadata
that
they
can't
reverse
engineer
anything,
so
it
doesn't
expose
anything.
The
fact
that
there
is
even
metadata
that
you
got
access
to
from
Team
A
is:
is
this
security
boundary
problem.
B
Because
if
you
want
to
link
everything
together
in
in
a
way
that
you
have
time
timely
information
like
what's
the
way
to
say
this,
if
you
want
to
have
actual,
you
know
the
ability
to
say
that
things
weren't
modified,
you
have
to
have
some
notion
of
like
a
snapshot
of
information
on
the
repository.
You
have
to
have
some
notion
of
like
time
moving
forward.
Otherwise
you're,
always
in
like,
like
this
perpetual
state
of
you
know
this,
like
this
baby
bird
imprint
on
what
or
random
thing
you
happen
to
be
given,
which
is
is
bad.
A
That
but
I'm
not
I'm
still
trying
to
follow
the
the
use
case.
So
if,
if
a
entity
is
trying
to
pull
content
from
both
team,
a
and
Team
B,
then
I
could
see
kind
of
like
there's
an
efficiency
here
that
I,
when
I
try
to
validate
both
a
and
B's
content
that
I
want
to
be
efficient
about.
That
is
that
is
that
the
argument,
not
necessarily
now
so
Team,
B
and
Team
B,
never
looks
a
team
a
what
is
the
benefit
to
this
disclosure
of
information
between
the
two
just
first,
the
security
aspect.
B
So
to
go
to
the
example
in
the
document
which
is
I,
think
you
have
this
up
now
so
figure
one
looks
at
what
happens
when
you
have
per
image
index
manifest
signatures
here.
Okay,
in
the
example
it's
giving
is.
This
is
an
example
where,
in
this
case,
there
happens
to
be
a
repository
that
contains
things
both
from
foo
and
bar
okay
and.
B
A
E
B
Right
so
here
you
go
and
you
have
per
image
index
manifest
signatures.
You
basically
have
no
snapshot
information
here.
So
what
happens
is
here
you
have
this.
This
repository
it
had
at
on
Tuesday
a
bad
version
of
food
was
pushed
it's
not
known
that
this
was
a
bad
version
at
the
time
of
course,
Wednesday.
This
was
maybe
discovered
that
hey
there's
some
security
issue
or
something
with
this,
and
so
now
foo
one
point
latest
on
Wednesday
points
to
foo
1.2
right,
okay,
Thursday.
B
B
Compromises
the
the
registry,
then
the
question
is:
is
that
what
damage
can
they
do
to
a
specific
client
like
what
metadata
can
they
give
to
the
client
to
make
them
think?
A
certain
version
is
like
is
the
latest
version.
This
is
for
our
client
is
trying
to
retrieve
through
one
point
latest
or
bar
one
point.
Late
is
so
because
the
registry
gets
to
pick
what
foo
or
bar
points
to
then.
If
they're
just
retrieving
the
per
image
information,
then
the
registry
gets
to
go
and
just
basically.
A
B
B
But
it
at
least
has
information.
It
has
no
information
about
any
registry,
it
might
cult
to
correct
it.
Does
it
well
today
because
it
has
to
know
at
least
like
I
might
want
to
go
like
here's
the
see
a
bundle
for
docker.
You
know,
then,
that
he's
gonna,
let
me
establish
trust
on
first
use
with
docker
hub
or
whatever
it.
What.
A
A
But
the
scenario
you
have
to
account
for
is
that
a
server
list
environment
right
there's
just
as
your
AWS
Google,
whatever
we've
got
VMs
that
are
sitting
around
and
compute
instances,
they
were
just
ready
to
give
out
to
any
one
customer
at
any
one
time.
The
majority
of
customers
don't
actually
pull
their
content,
that
they're
deploying
from
docker
hub.
They
pull
it
from
their
private
registry
and,
as
we
give
that
VM
to
you
know
any
one
of
the
hundreds
of
thousands
to
millions
of
customers
that
we
have.
B
H
That
is
a
muddling
process
that
happens
prior
to
the
environment
bootstrapping.
At
least.
We
need
to
do
that,
so
there
is
only
a
valid
set
of
hosts
that
you
will
be
able
to
pull
from
not
any
host
on
the
internet
unless
you
have
some
kind
of
bundling
or
or
exclusion
or
inclusion
parts
that
have
been
set
up
from
the
CA
as
well.
Yeah.
A
I
can
see
you
have
to
give
it
the
you
know.
The
the
current
thinking
is
that
you
would
obviously
give
it
the
client
keys.
You
know
the
public
keys
that
says
these
are
the
ones
that
I
trust
and
it
then
was
pull.
So
what
is
your
proposal?
It's
somehow
in
addition
to
the
client
keys,
it
gives
it
the
public
keys.
Rather,
it
gives
it
some
metadata
as
well.
A
B
G
D
A
B
B
If
it's
in
Figure
1,
then
the
malicious
registry
can
still
just
rehab
that
file
or
just
keep
it
around,
and
you
don't
have
any
way
to
actually
like
invalidate
it
in
a
good
way.
So
the
thing
with
the
word
2
is
that,
as
long
as
you've
seen
a
snapshot
from
after
the
change
was
made,
sorry
I
started
I,
you
know,
I
can
go
through
this
I.
Don't
have
to
go
through
this
now
and
I
do
realize
that
neo
is
like
you
had
something
you
wanted
to
mention
to
we've
kind
of
co-opted.
This
whole
meeting.
A
Yeah
I
think
that
the-
and
this
might
so,
let
me
I'll
say
this
and
let's
figure
out
what
we
want
to
do.
I
think
part
of
what
we're
doing
here
is
we're
saying,
there's
this
entity
that
there's
almost
like
these
two
parties,
it's
the
two
subkey
thing
that
both
have
to
be
done
at
the
same
time
to
agree
and
part
of
the
and
in
fact
the
original
notary
design
actually
had
a
separate
store
as
well.
Maybe
that's
why
this
was.
A
The
thought
is:
is
that
I
don't
know
the
details
yet
because
that's
what
I'm
looking
for
nas
and
the
other
key
folks
to
help
with
is
that
client
pulls
the
client
keys
from
some
other
entity,
not
from
the
registry,
some
secure
key
management
store
and
then
it
has
the
ability
to
pull
from
the
registry,
because
it
says
ok,
I
have
these
keys.
It
sounds
like
there's
unless
the
metadata
is
also
stored
in
a
separate
entity
that
is
separately
trusted,
then,
if
I,
if
that
client
then
pulls
from
the
registry.
A
At
that
point,
it's
not
clear
to
me
why
whatever
got
hacked
to
push
it
back
to
a
previous,
the
one
one
tag
instead
of
one
two,
that's
any
basically,
it's
gonna,
the
hacker
is
gonna
hack
that
as
well.
So
there's
almost
like
this
two
two
phase
commit
thing
that
we're
trying
to
achieve,
and
where
does
that?
Second
piece
of
information
come
from
yeah.
B
B
A
B
Conversation,
we
couldn't
walk
you
through
all
this.
It's
not
a
problem
we
can
mark
anybody
is
interested
through
this.
It's
totally
fine
yeah,
and
if
we
want
to
do
this
sometime
later
this
week,
that's
great
I
know.
Other
people
probably
have
stuff
coming
up
in
a
moment
to
is
there
stuff
that
we
and
I
actually
have
to
drop
in
a
moment.
I
just
realized.
They
do
actually
a
little
hard
to
stop,
but
yeah
I
apologize
I
feel
like
I've,
talked
an
awful
lot
during
this
meeting.
A
D
Yeah
I
can
address
those
class
so
I.
What
I
put
in
is
questions
that
I
expect
that
will
get
use
cases
to
kind
of
clarify
like
what
how
these
questions
should
be,
and
so
the
the
diner,
the
feedback
that
you
have
should
be
addressed
after
the
next
meeting
we
have
where
we
go
through
the
different
use
cases
and
see
what
we
need
to
answer
there.
I
do
want
to
affect
like
I'm,
not
sure
what
time
zones
everyone
is.
I
went
with
sort
of
like
an
early
morning.
Availability
I
had
cuz
I
figure.
D
E
D
A
A
The
doodle
link
was
in
the
agenda.
I
got
you
yeah
just
doing
both
what
helped
people
I
think
people
look
at
the
agenda
for
what's
currently
got
been.
The
conversation
thread
and
slack
would
be
helpful
for
everybody
all
right.
So
that's
we're
at
the
hour.
I
know
it's
there's
a
lot
of
stuff
there,
but
I
think
we
are
getting
a
little
at
least
I'm
trying
to
understand
a
little
bit
better
of
what
we're
trying
to
accomplish.
A
I
don't
know
if
the
new
environment
was
new
information
that
helped
understand
where
some
of
the
concerns
are
coming
from.
In
addition
to
the
cross
repo
thing
so
we'll
keep
on
iterating
I've
started,
putting
out
a
scope
for
I.
Put
it
out.
Really
it
in
breath
is
had
a
framework
for
doing
some
prototyping.
So
we
can
flush
out
some
of
these
things.
A
I
got
some
of
it
done
last
week,
I'll
be
working
on
it
this
week,
I'll
get
it
out
before
the
next
meeting,
so
people
can
take
a
look
at
it
and
that,
hopefully,
will
give
us
the
framework
to
start
experimenting
with
these
things
and
flushing
out
the
details.
So
with
that
encouraged
take
a
look
at
you
know.
I
was
scheduled
for
whatever
he's
doing
around
key
management.
That
I
know
we
need
and
I'll.