►
From YouTube: CNCF Notary Project Meeting 2020-06-29
Description
CNCF Notary Project Meeting 2020-06-29
B
B
B
B
B
B
First,
the
main
thing
that
I
think
we
were
struggling
with
is:
what
is
the
high
level
scenario
and
an
approach
that
we
could
go
about
it,
because
what
we're
seeing
is
we
have
a
bunch
of
subject
matter
experts
that
really
know
their
area
really
well
and
because
this
problem
is
so
deep
in
so
many
areas
that
it's
really
hard
for
everybody
to
be
an
expert
in
everybody
else's
area.
So
it's
trying
to
figure
out.
B
I
can't
say,
look
I,
don't
know
well
this
other
stuff
by
nowhere.
I
got
a
plug
in.
Let
me
focus
on
this
and
they're
gonna
surface
up
a
set
of
questions
and
issues
and
requirements
that
we
have
to
then
adapt
on
another
part,
and
likewise
back
and
forth,
so
I
was
trying
to
figure
out
how
to
frame
this.
We've
been
referring
to
a
sketch.
B
In
this
case,
it
was
a
model
he
started
with
sketches
and
then
built
this
model
which,
if
you
haven't
seen
it,
it's
really
amazing
the
way
they
use
sand
bags
filled
with
birdshot
that
created
this
natural
curve
and
he
was
able
to
prototype
some
things
and
figure
out
how
it
worked,
which
of
course,
then
goes
great.
I
got
the
structure,
but
where
does
all
the
stairwells
and
the
plumbing
and
the
lighting?
B
And
there
wasn't
really
that
much
lighting
back
then,
but
where
does
all
of
the
infrastructure
and
the
other
pieces
of
a
in
this
case
a
church
fit
into
it?
So
it
that
sketch
and
very
many
models
I
was
trying
to
find
some
that
were
open
license.
So
I
can
put
it
here,
but
just
do
some
sketches
of
the
physical
models
that
they've
made
to
prototype
designs
and
it's
through
that
that
they
were
able
to
come
up
with
better
approaches
to
facilitate
communications.
B
A
D
Yeah
I
think
I
mean
this
is
fairly
similar
to
the
models
we've
had
before.
I
guess.
One
thing,
that's
been
a
little
harder
in
this
community
is
usually
we've
when
we
work
with
other
folks
in
lying,
for
instance,
the
automotive
space
like
I
I,
I
guarantee
you
that
I
know
a
hundred
times
more
about
cloud
deployment
scenarios
that
I
knew
about
automotive
when
I
first
started
there,
and
we
agree
that
we
need
to
kind
of
be
working
together
and
working
together
more
closely
and
I.
D
Think
you
know
have
more
of
like
a
common
goal
about
what
we're
trying
to
achieve,
and
then
we
working
more
closely
together
to
get
there
and
meet
everyone's
needs,
because
our
goal
here
I
feel
like
there's
tension
where
it's
almost
like.
There's
groups
building
trying
to
build
different
models
and
that
arguing,
if
that
is
not
like
God
II,
didn't
go
and
then
get
a
bunch
of
people
to
design
different
things
and
then
like
in
the
end,
try
to
glom
it
together
or
try
to
try
to
do
whatever
I
think
we
need
to.
B
Okay,
so
part
of
it
I
think
is.
This
is
why
we
were
trying
to
get
the
scenarios
down
up
front
down
down
up
front
was
that
we
could
have
that
as
the
basis
on
what
we're
working
on
one
of
the
things
that
I've
kind
of
see
us
get.
You
know
very
focused
on,
and
this
is
because
that's
probably
your
expertise
in
this
area
as
Justin
is
the
the
update
scenario,
and
you
know
the
more.
Obviously,
the
update
framework
has
a
lot
to
do
with
that,
and
one
of
more
I
was
reading.
B
The
more
I
was
kind
of
seeing
that's
the
pattern.
That's
consistent
with
what
you've
been
representing
one
of
I
think
what
you're
seeing
is
the
that's
a
build.
There
is
a
build
scenario
where
that
is
important,
and
we
still
you
know.
So
it's
not
like
it's
not
important.
We
do
need
to
think
about
it,
but
when
we
think
about
doing
deployments
in
the
container
space
we
talk
about
them
in
very
immutable.
B
They
have
like
a
corporate
set
of
artifacts
that
they
reference
that
all
teams
would
reference,
even
smaller
teams,
so
I
think
it's
a
combination
of
those
two
high-level
bits
that
would
help
to
figure
out
where
they
fit
in,
because
there's
then
we
get
into
details
of
repos
and
from
real
clients
and
other
stuff.
That
I
think
will
flow
out
of
that
that
we
can
figure
out
how
to
address
some
of
those
but
they're
going.
D
The
second
point
is
the
easier
one
to
talk
about
first,
which
is
that
like,
if
there's
tough
metadata
on
the
public
repo
tough
targets
metadata,
you
can
copy
that
tough
targets
metadata
to
your
private
repo
and
just
use
it
there.
It's
it's
not
like
it's
not
somehow
associated
with
the
repo.
Your
private
repo
will
have
its
own
snapshot
file
and
we'll
list
that
target
this
metadata
on
it.
But
there's
no
like
there's
nothing.
Stopping
you
from
taking
targets
metadata,
which
is
you
know
just
for
everyone.
Furgus
metadata
is
the
thing.
B
Think
the
thing
that
I
struggle
with
is
we
keep
on.
We
talk
about
it
as
if
this
is
an
assumed
fact
and
we
and
it's
easier
to
use
as
opposed
to
I'm
still
struggling
a
little
bit
of.
Is
it
really
the
we
start
with
the
end
result,
and
we
could
use
it
here,
but
the
question
is:
should
we
and
where
does,
and
how
does
it
apply
when
I
see
things
like
the
client
initialization
is
out
of
scope
that
you
like
that
concerns
me
the
complexity
of
trying
to
pull
these
things
together.
You
know.
D
D
B
D
All
right,
I
mean
we're.
Gonna
have
kind
of
deja
vu
in
this
meeting
all
over
again
we're
we're,
welcome
to
go
back
through
the
scenarios
and
talk
about
the
the
problems
to
talk
about.
Why,
when
you
have
tag
matching
you
the
repository
telling
you
what
your
tag
latest
matches
is
problematic,
that
you
need
sign
metadata
from
the
user
to
do
that
like
fundamentally,
if
you
want,
we
don't
want
the
repository
to
be
able
to
control
what
a
tag
points
to
here
so
and
that
to
me
is
an
important
but
like
use
case
or
attack
case.
D
Even
if
it's
common
that
people
use
tags
differently,
it's
not
always
the
case
that
they
use
latest.
Sometimes
they
do.
But
in
those
cases
that's
it's
important
that
and
about
you
know
that
I,
don't
know
half
a
dozen
other
reasons
that
we
brought
up
related
to
all
the
problems
with
snapshot
and
everything
else
that
we
talked
about.
There's
like
a
whole
bunch
of
small,
but
in
you
know
seemingly
important
little
reasons
that
there,
but
the
the
case
of
copying
metadata
over
I
mean
you
brought
up.
Two
cases
use
a
copy
metadata
over.
D
You
can
literally
just
take
and
copy
targets
metadata
over
and
stick
it
on
the
other
repository
on
the
private
repository
and
that
works
just
fine
right.
So
that's
there's
you
know
and
I.
If
you
want
me
to
talk
in
more
detail
about
why
that
works
or
what
happens
I
can,
but
that's
that's
sort
of
like
that's
a
non-issue.
D
D
So,
once
again,
I
feel
like
we've,
we've
kind
of
gone
backwards,
like
I
felt
we'd
get
you
laid
out
two
things
that
were
quite
constructive,
that
we
could
talk
about
and
now
it's
kind
of
like
well
but
yeah.
Those
two
things
maybe
are
solved,
but
let
me
move
the
goalposts
and
talk
about
the
things
that
I
think
are
a
problem
like
tough,
doesn't
mandate
a
way
to
deal
with
how
you
do
trust
them
first
used.
Well,
we
don't
mandate
it,
but
we
support
like
the
way
in
notary
v1
does.
D
It
is
not
the
way
that
we
recommended
it
be
done
and-
and
you
know,
isn't
the
way
that
I'm
aware
that
any
other
group
does
does
trust
or
for
this
it's
still
supported.
We
could
do
it,
a
notary,
v2
and
some
people
might
in
certain
environments.
But
this
isn't
like
you
know
this,
isn't
like
the
fact
that
tough
allows
you
to
pick
a
couple
of
options
here,
isn't
necessarily
mean
that
tough
can't
do
this
problem.
It
just
means
that
there's
there's
multiple
paths
that
different
people
have
chosen,
so
I
don't
know
like
I.
E
E
C
Oh
thanks
I
think
it
could
just
be
a
mismatch
of
honestly
just
language
and
expectations
really
like
I,
think
the
way
we
designed
tough
now
and
we
made
like
a
radical
change
to
it.
Right
like
like,
with
design
option
2
with
the
the
Merkel
tree
snapshot
metadata.
We
were
fairly
confident.
It
will
work
with
all
of
the
deployment
scenarios.
C
Think
I
think
we
just
need
a
meeting
to
sit
down
and
figure
out
this
problem
once
and
for
all
right
like
if
we,
if
the
thinking
is
that
tough
is
not
gonna
solve
the
problems
at
all.
But
we
need
to
know
why
and
we
we
were
fairly
confident.
We
can
fix
the
problems
and
we're
also
not
trying
to,
at
the
same
time,
trying
to
forcefully
shoehorn
thought
here
and
say.
B
Like
all
the
clouds
have
actually
supported
this
option
in
various
forms
that
you
can
lock
a
tag
from
being
updated.
Maybe
that's
something
we
should
put
into
the
spec.
That
says
there
is
a
standard
way
that
a
tag
cannot
be
changed
for
one
set
of
you
know
for
the
deployment
scenarios,
so
I
think
that's
the
part
that
it
it
gets
gets
me
uncomfortable
is
when
we
keep
on
talking
about.
That
is
the
primary
scenario
and
that's
not
the
primary
problem.
Oh.
C
I
think
I
see
what
you're
saying
yes,
that
that
what
that
also
wasn't
clear
to
me
until
recently
either.
But
yes,
I've,
come
to
understand
that
the
latest
thinking
in
the
industry
is
that
yeah
tax
tags
should
be.
In
fact
you
don't
even
want
to
pull
things
necessarily
by
tags
anymore.
You
want
to
pull
things
directly
by
digest,
at
least
in
the
scene
at
will.
That
is
the
thinking
yeah.
B
And
I,
that's
I'd
actually
suggest
that
the
reason
people
go
to
digest
is
because
tags
don't
have
a
way
to
be
locked
if
we
had.
Oh
because
there's
problems
with
digest
as
well
being
very
long,
not
very
you
know,
friendly
being
able
to
see
in
logs
or
in
dashboards
and
there's
no
break
glass
scenario.
D
D
B
A
F
B
A
couple
I
mean
hacking.
A
registry
is
certainly
a
problem
and
there's
some
pieces.
That's
that
I
really
like,
but
like
part
of
the
immutable
tag,
is
view
lock
attack.
It
can't
be
deleted
anyway,
either.
So
there's
a
couple
of
things
around
that
that
there's
some
pieces
in
place
that
can
at
least
address
that
problem
and
then
I
think
it's
made.
It
was
just
referring
to
like
if
you,
if
somehow
it
was
deleted
and
replaced,
then
the
idea
is
that
the
replacement
wasn't
signed.
B
C
There
are
ways
you
can
cryptographically
do
this
so,
for
example,
with
an
append-only
lock,
you
can
do
this.
The
thing
is:
we
need
to
figure
out
what
the
problem
is,
such
as
this
locking
tags
like,
if
that's
a
requirement
that
we
need
to
build
into
our
design.
I,
just
I
knew
you
were
saying
something.
D
Yeah
I
was
actually
saying
that
the
way
you
would
do
this
in
tough
is
you
wouldn't
end
up
trusting
the
repository
or
registry
in
order
to
do
this
action
because
you
would
upload
the
sign
metadata
in
you
would
effectively
not
update
that
tag
anymore,
not
have
the
user.
That's
that
is
the
one
that's
responsible
that
has
the
key.
Have
them.
You
know,
go
and
be
this
walking
and
so
like
using
it
in
this
way.
D
Just
just
for
this
one
like
specific
problem,
it
helps
to
remove
the
fact
that
you're
you're,
relying
on
the
registry
for
enforcement
of
this
property
in
other
scenarios.
So
even
if
an
attacker
breaks
into
a
registry,
at
least
for
any
client
that
has
some
prior
metadata,
which
you
know
doesn't
have
to
be
a
pure
update
case,
but
can
being
your
trust
on
first
use
means
that
you
have
at
some
point
pre-loaded,
and
then
you
know
when
you
do
your
local
deployment
you're,
including
some
of
that
metadata,
as
we
discuss
as
you
would
like.
B
So
one
of
the
things-
and
this
is
part
of
what
I'm
hoping
this
sketch
will
come
out
and
you
know
in
trying
to
write
up
some
the
end
end
scenarios
to
flush
through
this
is
is
that
new
ephemeral,
client
and
one
of
the
things
that
I'm
hearing
is
you
know.
Obviously,
we
trusting
just
one
entity
is
bad,
whether
it
be
the
registry
or
a
single
user,
with
a
key
and
so
forth
and
key
in
this
case.
Let's
talk
about
the
nuclear
submarine
thing
right.
B
To
a
minimum
of
two
that
have
to
agree
so
if
they,
if
we
can't
trust
the
client,
because
the
clot
that
we
can't
trust,
think
they're
trying
could
have
got
hacked
as
well.
But
the
fact
is,
the
client
is
a
new
client
being
doled
out
for
use
and
there's
nothing
there
yet
specific
to
that
environment.
That
I
need
to
be
able
get
that
information
and
I'm
and
I
apologize
for
posting.
This,
just
like
a
half
an
hour
before
the
meeting,
I
didn't
get
a
chance
to
read
the
replies,
but
what
I
liked
about
that?
B
What
you're
trying
to
do
there
is
the
original
design
from
what
I
was
reading.
Is
that
a
client
has
some
piece
of
information
and
I
have
to
correlate
the
the
registry,
in
this
case
the
repository
and
my
client
to
see
if
they
got
out
of
sync
and
something
got
hacked
if
I,
don't?
How
do
you
have
any
information
on
the
client
then
and
I
can't
solely
trust?
The
registry,
then,
is
there
some
other
entity
that
would
also
have
to
get
hacked
as
well,
and
what
would
that
look
like?
What
is
that
other
entity.
D
So
as
I
understand
it
from
what
we
were
talking
about
before
when
we
were
talking
about
deployment
scenarios,
you're
using
stock
receipts
or
something
else
like
this
to
load
in
information
about
like
go
to
this
registry
and
use
these
keys
and
so
on,
and
so,
if
you're
loading
in
that
initial
metadata
in
and
that
metadata
includes
just
like
you
know,
an
initial
copy
of
like
the
top
metadata,
which
isn't
much
larger
than
just
the
list
of
keys.
Depending
on
what
you
know
how
you
set
things
up.
D
B
B
D
A
client
and
I
have
to
initialize
it.
Where
do
we
get
it
from
I'm,
saying
something
slightly
different,
so
as
a
new
client
forget
about
whether
using
tough
or
anything
else,
right,
you're,
gonna
get
keys
and
things
loaded
in
to
you
via
dr.
secrets
or
some
other
mechanism,
like
that,
so
app
secrets
into
your
container
spiffy
spy
or
whatever,
somehow
you're
gonna
end
up
getting
like
like
the
like
the
sort
of
like
secrets
and
configuration
and
whatever
else
you
need.
So
that's
great
configuration
information.
B
Yeah,
that's
it
you're.
Actually
saying
that
part,
that's
that's
the
part
we
don't
have.
Yet.
If
we,
the
client
has
creds
of
some
sort
that
says
it
can
pull
from
a
registry.
It
has
some
policy
that
says
what
it
can
do,
but
where
does
it
get
that
that
metadata?
That
you're,
referring
to
to
then
have
the
comparison?
The.
B
A
B
F
Configuration
system
and
long-lived
perfectly
well
be
year
old.
If
this
recent,
if
recuperation
a
circular
enforcement,
requires
them
to
be
regularly
updated
at
so
any
mechanism.
I'm
not
saying
it's
nimble,
it's
not
impossible,
but
it's
definitely
new.
It's
not
terribly
derived
from
just
obtaining
the
person.
Well,.
C
F
F
C
B
So
I
think
that
the
root
of
what
we're
talking
with
a
tale
about
what
data
and
how
long
and
so
forth,
is
there's
this
other
process.
That
is,
has
a
different
way
of
getting
different,
a
path
of
getting
information
from
the
registry
to
get
some
snapshot.
Some
metadata
around
a
particular
each
repo
and
it's
stored
in
a
secondary
entity,
so
that
a
femoral
client
that
comes
in
that
wants
to
initialize
there's
a
set
of
information.
It
has
to
get.
B
Obviously,
if
it's
getting
keys,
there's
a
certain
amount
of
trust
that
allows
you
to
get
the
key
so
doesn't
get
the
wrong
keys
or
the
wrong
configuration.
It
says,
instead
of
go
to
my
trusted
registry,
go
to
bad
trusted
registry
and
download
this
code
that
will
send
out
all
credit
card
information,
there's
a
certain
set
of
boundaries
that
are
put
in
place,
and
it's
not
that
any
one
entity
is
trusted
in
more
than
the
others
is
there's
this
correlation
of.
B
So
as
long
as
there's
a
process
by
which
that
takes
this
metadata
out
of
the
registry
puts
it
in
some
other
location
and
that
process
has
to
be
almost
a
third
trusted
trust
boundary.
Then,
as
a
client
I
come
in,
hey
I
woke
up
from
the
world.
Why
is
everybody
wearing
masks?
Okay,
let
me
just
get
to
work
right.
B
C
Yeah,
you
would
get
that
I
mean
so
so,
if
you
have
a
version
of
root
metadata
from
year
ago-
and
let's
say
you've
made
to
two
recent
key
rotations
since
then,
this
this
rotation
will
be
handled
automatically
for
you
now.
One
thing
that
will
happen
is
that
for
as
long
as
you
don't
update
the
secondary
store
with
the
latest
route,
your
new
clients
will
end
up
pulling
like
the
latest
route
over
and
over
and
over
again
and
it'll
be
inefficient.
C
B
C
B
Because
the
way
I
think
about
structuring
this
is
like
a
deployment.
If
it's
a
unique
tag-
and
we
have
this
way
to
lock
tags,
so
they
can
never
be
updated,
then
the
deployments
don't
need
to
do
this
kind
of
deeper
checking.
There's
something
there
that
I
don't
know
exactly
the
details.
Are
we
have
to
figure
that
out,
but
certainly
in
the
build
environment
where
it's
not
critically
timed
compared
to
a
production
deployment?
It's
it
it'll.
B
It
is
a
dangerous
time
because
you
have
new
code
being
pulled
in
and
so
forth
that
it
can
do
these
deeper
checks
and
says:
hey
I
am
in
a
build
environment.
Do
you
support
base
image,
update
tags
like
the
version
of
the
things
it's
updated
for
security
fixes
it
could
break
because
the
security
fix
breaks,
functionality,
compatibility
so
there's
always
extra
work
going
on
then
anyway,
and
then
we
can
do
this
tag.
Update
scenario
where
we're
trying
to
make
sure
other
rich
metadata
is
done
that
what
I?
What
feels
good
about
that
is
I'm?
B
Doing
the
more
complex
thing
at
the
more
scary
thing,
when
it's
not
a
critically
timed
and
the
more
critical
deployment
thing
where
I'm
trying
to
literally
start
a
function
in
less
than
a
second
and
I,
want
to
be
able
to
get
some
content
to
be
able
to
do
that.
I
can
still
get
the
right
level
of
security
because
I
never
support
an
updated.
C
Yeah
the
way,
the
way
the
design
option
2
is
structured
right
is
exactly
to
address
your
concern,
which
is
that
performance
is
key
here,
you're
doing
one
security,
but
you
don't
want
to
block
on
it.
So
it's
deliberately
designed
to
get
you
started
as
quickly
as
possible
and
if
you
want
to
do
deeper
checks,
you
can.
G
Gonna
say
kind
of
agree
with
revisiting
the
scenario
stuck
because
I
think
that
we've
come
across
several
scenarios
like
this,
where
the
because
the
end-to-end
workflows
aren't
well
documented
whenever
we're
debating
these
scenarios,
whenever
we
end
up
looking
at
some
implementation-
and
it's
been
difficult,
I
think
to
kind
of
understand
like
what
we're
working
towards
and
what
problems
things
just
solving
I
agree
with
that.
I.
G
Don't
think
this
is
necessarily
moving
the
goalposts
as
as
much
as
it
is
realizing
that
we've
never
really
had
the
scenarios
will
define
so
I
think
it
actually
makes
sense
to
kind
of
go
through
and
add
more
meat
to
that
duck.
It's
something
I've
brought
up
with
Omar
as
well
on
our
site.
On
the
ALW
side,
he
plans
on
participating,
more
and
I
think
that
will
at
least
help
us
understand
what
tough
is
addressing
some
of
these
problems
and
what
the
gaps
are,
that
we
need
to
close.
B
B
B
A
Don't
know
I
think
that
there
are
definitely
I
mean
I,
think
there
are
some
people
who
definitely
want
to
work
like
that.
There
are
other
people
who
don't
and
so
I,
don't
think
it's
a
solution.
That's
gonna
work
for
everyone,
I,
don't
think
we
can
impose
lock
tags
because
I
think
there
are
people
who
are
I.
You
know
people
who
are
using
latest
and
will
continue
to
use
latest
and
is
difficult
to
change
their
behavior.
So
I
think
we
can.
A
We
can't
make
that
the
only
behavior
we
I
don't
know
if
we
could
I
mean
if
we
could
make
better
security
guarantees.
If
you
only
use
tags
in
an
immutable
way,
then
we
might
persuade
more
people
to
use
immutable
tags.
If
that
were
the
case,
if
it
was,
if
that
helped
us
and
it'd
make
the
design
better,
I
think
I
think
that
might
be
okay,
and
so
you
might
get
you
might
get
better
guarantee.
Well,
it
depends
on
exactly
what
they
guarantee.
What
that
really
meant,
but
I
could
say
a
situation.
B
B
Initially,
you
went
the
other
way.
I
was
thinking
when
you
started
saying
people
following
a
certain
pattern.
Is
there's
people
locking
to
digest
because
those
are
immutable,
but
not
very
friendly
from
length
and
readability,
there's
a
locked
tag
which
we
don't
really
support
and
then
there's
the
latest
tag.
I
always
err
quote
because
latest
should
anyway
a
stable
tag,
but
it's
what
we
could
do
based
on
what
we
just
you
know
said
prior
to
this,
with
what
trick
Trish
Schenk
was
saying
with
design
option
two
I
think
is.
B
You
could
still
get
security
on
latest
because
we're
going
to
need
that
on
build.
It's
that
it's
a
more
heavyweight
performance
performance,
implication
thing.
So,
as
we
all
see
here
with
people
learning
containers,
they
will
learn
one
way
and
it'll
work
and
for
performance
reasons
they
want
to
do
in
a
slightly
different
way.
It's
just
it's
becomes
a
tweak.
So
in
this
case
it's
not
that
it's
an
insecure
way.
It
would
still
be
secure
because
we
did
it
for
builds.
It
would
just
be
less
performant
and
yeah.
A
B
H
Mean
for
me,
I,
don't
think
there'd
be
much
changes
the
spec
to
support
something
like
tag
walkie
and
I
mean
we
could
define
an
air
case
or
maybe
a
condition
where,
when
you
upload,
you
can
set
a
flag
that
says
like
mark.
This
is
locked,
but
the
registry
may
or
may
not
ignore
that,
and
you
know
in
that
case,
for
me,
what
I'd
like
to
see
happen
more
is
moving
tags
and
digests
as
not
one
or
the
other,
but
kind
of
two
dimensions
so
like,
for
example,
on
container
D.
H
We
keep
track
of
the
the
timestamps
associated
with
that,
so
I
think
one
of
the
things
we're
missing,
not
just
the
locking
but
the
actual
like
tag
history
and
making
sure
that,
especially
for
like
provenance
reasons
inside
of
notary
that
we
have,
we
know
when
everything
was
signed,
because
we
know
that
just
because
a
tag
got
updated
doesn't
mean
that
nothing
is
relying
on.
The
previous
tagged
version
for
deployment
is.
B
H
We
do
that
yeah
I
mean
there's
like
a
kind
of
like
an
e-tag
check.
Just
to
see
like
whether
or
not
this
is
the
same.
I
mean
that's
not
specific
what
we
do
in
container
D,
because
we
we
pointed
at
the
specific,
manifest
the
check,
but
that's
how
we
that's,
how
we
actually
keep
track
of
everything,
because
in
container
D
the
image
name
is
actually
the
top-level
reference.
B
The
tag
history
has
always
been
a
challenges.
I,
don't
know
if
I've
seen
me
that
does
it
really
well,
we
certainly
something
we
wanted
to
do
is
like
if
I
do
have
an
update
and
it's
broken.
How
do
I
get
to
the
previous
one
like
there's,
no
good
historical
index
thing
so
it'd
be
nice
to
have
that
formalized
as
well.
That's
a
that's!
A
good
fallback
and
usability
I.
Think
the
the
locking
that
feels
like
a
good
trade-off.
I
guess
is
what
I'm
kind
of
getting
at
us.
You
can
go
all
the
way
to
digest.
B
You
can
go
to
tags
with
a
lock
and
have
some
confidence
of
performance,
and
then
you
can,
for
what
we
would
say
is
the
best
practice
for
deploy
anyway
and
then
for
build
scenarios.
What
we
do
want
to
support
the
updating
of
a
tag
we
can
do
the
deeper
checks
and
we
do
it
in
a
way
that
the
client
isn't
assumed
to
be
in
a
previously
known
state.
We
have
to
do
this
separate
entity,
verification
process.
H
Yeah
one
thing
to
keep
in
mind
is
some
implementations
of
the
registry.
The
actual
storage
are
fairly
eventually
consistent,
so,
like
you
could
you
could
push
up
the
same
tag
to
two
different?
It's
kind
of
the
latest
wins
which
isn't
great,
and
that's
really
why
you
need
something
like
notary
or
something
if
you
really
want
to
enforce
for
said,
behavior
I.
C
Should
note
that
having
something
like
the
snapshot
metadata
actually
gives
you
audit
ability
for
free
in
this
sense,
if
you
keep
adding
every
use
natural
metadata
to
something
like
a
transparent
log
right,
which
is
an
append-only
log,
you,
you
could
actually
audit
whether
or
not
people
have
mutated
tax.
So
that's
that's
an
interesting
property
to
have.
B
Yeah
being
able
to
there's
no
standard
for
a
tag,
update
scenario
for
good
or
bad
reasons,
it's
something
we
you
can
put
in
your
diagnostics
and
logs.
You
know
history,
but
there's
no
standard
API
that
anybody
could
run
for
some
security
scanners.
Hey
here's
the
way
here,
BLS
Stacey
are
a
sure
and
Google.
Do
it
in
docker,
hub
and
blah
blah
blah
cool
all.
A
Right
thought:
I
wanted
to
talk
about
upon
the
agenda
that
I
want
to
talk
about
that
ephemeral
grants
thing
say:
yeah
in
particular,
I'm
gonna
think
there
were
two
things
about
option:
one
and
the
signature
design
doc
that
I
think
a
problematic
one
of
which
was
the
discussion
we
were
having
about
actually
the
feasibility
of
constructing
independent
sets
of
images,
which
is
pretty
unclear
that
I
can
work
at
all.
But
the
second
thing.
A
It's
not
it's
not
clear
how
you
could
actually
even
partition
their
registries
and
assess
sets
of
images
with
different
permissions
in
any
useful
way,
because
you
don't
know
what
that
you
don't
really
know
what
a
client's
permissions
are
until
you
actually
try
and
do
an
authorization
check
on
it.
So
you
don't
you
if
you
have
something
that
can
just
just
tells
you.
If
something
has
access
to
something
you
don't
you
can
actually
create,
sets
from
it
I'm
a
little
read
the
console.
That's
actually
not
the
bit.
A
I
want
to
talk
about
okay,
but
the
other
bit
I
was
about
was
the
fact
that
I
think
we
need
to
actually
have
a
position
on
ephemeral
grants,
because
the
other
problem
with
this
is
that
clients
have
different
security
guarantees,
depending
on
which
images
they've
downloaded
metadata.
For
so
effectively,
we
got
very
path-dependent
security
and
I
think
we
need
to
make.
We
need
to
have
a
position
that
ephemeral,
clans
are
an
extremely
important
case
and
therefore
that's
the
secures.
That's
the
security
given
that
in
the
in
this
option
one
this
is
that's
the
work.
A
A
Last
week's
call,
but
like
no
role
you
guys
to
get
much
worse
role
buy
protection
if
you
haven't
pulled
things
before
you
ephemeral,
and
we
should
treat
this
as
being
the
normal
case
and
optimize
for
that
case
rather
than
assume,
rather
than
in
that,
rather
than
assume
their
clients,
I've
actually
pulled
metadata
before
so
I
think
both
those
things
effectively
a
ruling
against
option,
one
as
being
feasible,
so
they're,
both
kinda,
both
of
those
kind
of
mitigate
towards
up
something
more
like
option.
Two.
A
And
and
like
maybe,
a
transparency
log
is
what
we
raise
more,
what
we
want
in
order
to
provide
those
kinds
of
guarantees,
because
it
doesn't,
rather
than
assuming,
that
clients
constantly
pulling
pulling
metadata
from
registry,
whereas
in
fact
we
know
that
a
lot
of
transfer,
ephemeral
and
that's
kind
of
that's
more
like
what
option
two
is
starting
to
look
like
to
me
as
it
comes
together.
Yeah.
D
I
think
what
you're
saying
makes
a
lot
of
sense,
I
mean
I.
Think
we
had
a
little
bit
of
hesitation
because
we
felt
like
a
transparency.
Log
was
adding
a
lot
more
complexity,
but
I
think
the
the
what
I
understood
a
little
more
is
the
difficulty
of
getting
people
to
provide
a
more
current
piece
of
metadata
themselves
is
in
many
ways
higher
than
an
entity
of
running
something
like
a
trans
certificate,
transparency
log
to
store
the
like.
A
A
D
D
D
D
D
A
Know
actually
I
mean
I
think
that
I
mean
I
have
a
kind
of
other
question
about
what
the
I
mean.
I
think
that
you've
been
working
under
the
assumption
that
the
registry
is
the
right
organizational
unit,
size
I'm,
not
sure
that
I'm
convinced
that
that
is
the
right
size
and
there
I
guess
there
are
so.
There
are
two
options:
there's
bigger
than
that:
ie
its
global
or
there's
smaller
than
that
ie.
A
D
The
place
where
we
kind
of
landed
on
that
is
that
instead,
so
in
tough,
currently
the
the
targets,
the
root
of
your
targets,
metadata
is
comes
from
the
root
file,
so
the
targets
metadata
that
you
care
about
comes
from
there,
but
well
that
we've
sort
of
proposed
in
this
is
that
the
targets
file
like
root
is
effectively
your
credentials
that
you
put
in
like
it
comes
in
your
system
ahead
of
time.
So
you
control
that
directly.
D
So
the
root
file
can
be
uniform
and
can
be
uniform
across
the
entire
registry,
because
all
it
controls
is
snapshot
in
time
stamp.
So
it's
no
longer
actually
a
very
security,
sensitive
role
in
the
system.
It's
gone
from
being
super
important
because
it
controlled
targets.
To
being
you
know
the
thing
that
lets
you
deal
with
compromised
of
snapshot
or
timestamp
I.
D
C
A
We
think
we've
thrown
out
two
options
now
so,
which
is
I,
think
good
progress,
so
so
actually,
like
I,
think
it's
yeah.
It's
definitely
Clara.
If
there's
is,
if
there's
one
option
that
we're
kind
of
its
racing
all
the
time
and
then
finally,
rather
than
because
it's
actually,
if
it's,
then
you
can
just
explain
that
one
option
rather
than
having
to
say
there's
two
alternatives.
A
D
Yeah
a
little
more
about
what
to
do
in
the
private
repo
case
with
if
our
option
we're
really
moving
to
this,
only
certificate,
transparency,
long
style
thing
whether
they
have
to
set
up
a
private
instance
just
to
do
that
which
doesn't
make
sense,
I
mean
I'm,
not
saying
it
doesn't
make
sense
they.
That
would
be
a
very
logical
thing
for
them
to
do
in
that
case,
but
we
would
just
have
to
mention
that,
as
this
is
the
way
to
do
it.
B
We
should
really
be
careful
about.
Some
of
these
I
mean
we're
seeing
more
and
more
and
more
these
air-gapped
environments
becoming
the
norm
and
for
anybody
that's
been
following
the
MCR
thread:
we've
had
a
changed
data.
Endpoints
like
there
is
customers
do
not
like
their
clients
having
access
to
things
that
they
don't
own.
B
So
we
need
to
not
make
it
only
for
the
big
companies
to
implement,
because
it's
really
tough
difficult.
You
know
it
needs
to
be
something.
The
average
company
can
do
very
easily
to
be
able
to
have
their
environment,
be
completely
trusted
and
isolated,
because
it's
not
I
wrote
it
in
one
of
these
things.
This
is
not
just
you
know,
submarines
and
these
large
esoteric
scenarios.
B
These
are
the
average
company,
wants
everything
locked
down
from
anything
public
as
a
standard
security
measure,
and
they
only
move
content
into
that
environment
in
a
trusted
way
and
then
the
way
they
move
content
into
it.
That's
the
part
that
gets
more
secure,
but
it's
the
fact
that
they
have
a
an
isolated
environment
is
the
standard.
D
Yeah
I
think
having
them
set
up
container
of
whatever
that
runs
through
their
repository
or
their
registry
having
them
set
up
under
moments
like
the
certificate
transparency,
log
sort
of
thing
feels
like
it,
it
might
be,
the
right
might
be
usable
enough.
I,
don't
know
if
what
others
think
about
that,
but.
A
A
Obviously,
with
all
of
you
I'm
curious
about
whether
we
I
mean
how
much
we
could
I
guess,
the
question
is:
what
secure
what
properties
are
different
from
the
regiment,
whether
we
could
bundle
it
into
the
registry,
whether
we
could
include
the
transparency
log
as
part
of
the
registry,
whether
or
whether
it
oh,
how
that's
gonna
work.
Oh
super
have
to
think
of.
D
A
I
mean
that
the
log
model
was
yeah,
I
mean
the
the
yes
and
you
need
other
people
potentially
to
replicate
it.
For
you,
I
mean
the
public
transparency.
Log
model
has
actually
been
working
fairly
reasonably
well,
and
this
in
the
sense
that,
like
people,
have
lost
their
keys
and
things
and
it's,
but
not,
everyone
has
simultaneously.
A
D
Okay
well
well,
thanks,
then
we'll
mention
our
thoughts
in
the
notary,
B
to
slack
Channel,
we'll
try
to
revise
I'll,
try
to
go
through
with
marina
and
anybody
else,
who's
interested
and
go
through
and
try
to
revise.
This
are
things
so
that
they
make
design
option
to
be
the
design
option
and
we'll
talk
about
using
this
sort
of
transparency.
D
Log
way
of
this
to
get
this
metadata,
as
as,
though
it
is
the
the
one
true
way,
because
I
totally
agree
like
with
something
Justin
permex
said,
which
is
that
you
know
looking
at
one
option
and
walking
down
that
path
is
easier.
Is
the
right
way
to
go
rather
than
trying
to
pull
in
different
directions
and
talk
about
all
that,
so
we'll
fix
our
mistakes
in
that
area.
Yeah.