►
From YouTube: [OCI-WG] Reference Types - 2022-05-24
A
Yeah,
so
do
do
we
want
to
talk
about
that
first.
B
I'm
happy
to
go
through
some
of
those.
I
just
do
things
that
I'd
put
on
the
list
just
to
make
sure
we
didn't
miss
them.
Let's
see
I
kind
of
want
to
knock
out
a
quick
demo
of
what
we're
doing.
First,
on
e.
A
B
A
D
B
B
A
Yeah,
no,
I
guess
last
week
was
the
exception.
Maybe
I
don't
know
y'all
y'all
can
y'all
can
level
up
on
your
note-taking.
I'm
sure.
B
B
Let
me
throw
a
couple
of
quick
examples
here.
If
I
do
a
quick
artifact
list
command,
I
have
artifacts
and
this
if
I
check
this
repo
right
now,
this
is
on
the
newer
registry
code
out
there.
B
B
I
don't
have
any
other
tags,
it's
just
the
one
tag.
I
can
take
that
latest
thing
either.
If
that's
confusing
anybody,
I
ignored
normally
my
code,
no
other
tags,
not
repo,
so
this
is
looking
up
through
the
api.
Nothing
nothing
else
happening
there
and
if
I
go
check
one
of
these,
let
me
actually
go
yeah.
This
is
a
good
example
here.
B
And
I
missed
to
see
my
copy
there.
I've
got
a
manifest,
it's
got
some
annotations
on
it
and,
if
I
say
get
the
artifact
on
it,
I
can
pull
back
the
actual
artifact
content.
B
And
then,
let's
see
I'll
change,
I'm
going
to
keep
doing
this
as
it's
like
a
miscellaneous
thing.
It's
just
like
a
hello.
B
B
Who
knows
demo
failed
right
now
doing
all
this
good
stuff.
So
I'm
not
sure
where
that
demo
failed
I'll
go
through
some
do
some
debugging
there,
but
trust
me.
It
did
actually
work
before
this
demo
failed,
so
yeah
that
stuff,
actually
quasi
works
as
long
as
I'm
not
doing
that.
D
Those
those
example
annotations
is
that
you're
just
showing
that
you
can
do
that.
B
B
A
I
have
a
question:
how
many
changes
did
you
have
to
make
on
top
of
the
distribution
fork
in
order
to
make
this
happen?.
B
So
reg
client
itself
had
some
code
in
there
for
pushing
artifacts
before
but
they're
all
tagged
artifacts.
They
didn't
have
the
reference
type
code,
so
I
had
to
put
some
extra
code
in
there
to
check
adding
new
media
type
that
took
a
fair
bit
of
work,
because
I've
got
a
lot
of
wrappers
around
all
that
every
time
I
add
a
media
type
in
there,
but
adding
the
actual
push
by
reference.
It
was
just
a
quick
check
to
the
registry.
B
B
E
Yeah,
so
we
had
the
chance
to
support
only
the
new
manifest
first
and
over
the
last
week
we,
our
cars
from
my
team,
actually
helped
kind
of
support
the
image
manifest
as
well.
E
It
is
significant
in
the
sense
that
it
will
take
time
to
get
this
right
because
it's
actually
going
through
every
manifest
and
hoisting
annotations
and
building
the
the
responses
accordingly.
So
changes,
I
wouldn't
say,
are
trivial,
but
it's
doable.
But
then
again
the
whole
idea
of
the
working
group
is
so
that
we
can
see
these
experiences
and
and
see
whether
they
fit
the
use
cases
that
we
want
right.
B
F
We
can
jump
into
that.
I
know
thomas.
Was
there
tonight
serious
too,
so
we
started
having
a
conversation
on
the.
Let
me
pull
it
up.
F
This
is
the
the
issue
and
let
me
see
if
I
can
get
it
from
well.
Here's
the
full
issue
there's
a
whole
conversation
on
there.
I
think
some
of
that
is
just
explaining
where
we
think
there
could
be
issues
with
this
approach
or
where
things
will
be.
F
F
I'm
not
sure
what
the
best
way
to
tell
us.
What
do
you
think
the
best
way
to
handle
this
is
sweet
if
people
read
from
here-ish,
but
that's
really
not
good
to
do
in
a
synchronous
meeting.
F
Key
concerns,
I
think,
there's
a
couple,
so
the
first
one
is
that
in
my
so
in
the
meta
in
my
head,
I
think
anything
that
requires
changes
to
structs
or
apis
requires
that
registries
adopt
them
and
that,
like,
if
you
provide
a
full
back,
the
fullback
risks
just
becoming
the
de
facto
standard.
I
think-
and
that's
not
what
anybody
really
wants
right.
F
So,
as
I
think
everybody
here
is
aware
that,
like
we
want
to
try
and
avoid
that,
that's
the
meta
concern
the
second
one
is
like
in
terms
of
how
registries
are
structured
and
how
they
store
and
link
data
together.
Changing
that
for
big
registries
is
a
non
minor
thing,
so
adding
different
ways,
things
can
reference
each
other
or
what
but
does
add
complexity,
and
even
things
like
adding
tons
and
tons
of
tags
is
problematic
just
in
terms
of
list
tag
apis
and
things
like
that.
F
We're
not
designed
to
be
queried
a
lot.
I
guess
the
discussion
here
went
more
towards
the
so
proposal.
D
was
the
idea
that
you
have
a
manifestos
or
an
oci
index
that
you
add
things
too,
so,
essentially
the
digest
of
the
object
changes
as
you
sign
it
and
the
discussion.
F
I
guess
the
key
point
there
is,
should
digest
change
or
not
when
signatures
are
added
and
they're
probably
use
cases
for
both,
but
are
there
existing
structures
like
oci
indexes
we
can
use
instead
to
reference
things
and
tags
as
a
mutable
thing
to
appending
signatures
onto
the
same
object
or
something
else
yeah,
I
don't
know,
maybe
tennis
you
can
explain
better
otherwise,.
B
F
Digest
what
I
mean
yeah,
that's
a
good
point
like
what
are
you
signing
you
can
sign?
You
can
sign
anything.
You
just
have
to
define
exactly
what
you
want
to
sign,
so
you
could
sign
a
a
a
json
object
containing
references
to
other
things.
You
could
sign
a
single
digest.
You
know
as
as
one
thing,
but
I
itanis
is
pretty
better
explaining
the
the
other.
The
other
issues.
G
Yeah,
I
guess
like
where
this
discussion
went
was
against
this
fundamental
question
of
like
basically,
what
is
the
definition
of
the
image?
So
is
the
definition
of
the
image,
the
the
image
container
bits
and
the
signature
or,
like,
I
think
in
your
definition,
it's
more
like
that.
The
image
is
only
the
container
bits
and
then,
like
the
signatures,
are
all
external,
and
that
was
kind
of
like
the
reason.
G
As
far
as
I
understand
why
you
moved
on
from
proposal
d
was
because,
like
this,
this
dice
has
changed,
didn't
really
fit
without
your
use
cases
that
much
while,
if
you
look
at
like
the
some
of
the
doctor,
use
cases
like
that
they're
much
more
aligned
to
having
this
image,
that's
that
we
can
already
like.
Basically
like
the
thing
you
see
in
docker
images,
it's
already
signed,
it
has
at
the
stations
and
and
so
on.
It's
not
just
like
that.
G
I
guess,
like
the
only
practical
way
to
do
it
with
like
without
the
introducing
any
new
object
in
the
registry
is
to
sign
the
descriptor
in
the
in
the
image
index.
Like
I,
I
don't
see
any
other
like
practical,
practical
ways
there
and
like
in
this
issue.
We
I
I
think
we
had
like
some
kind
of
a
kind
of
like
clean
way
to
do
this,
with,
like
nesting
imaging
index,
turns
out
that,
like
the
runtime
support
for
this
is
like
kind
of
flaky
like
some
some
some
turn
on
time
support
some
stuff.
G
C
Right,
no,
not
only
like
words
in
a
spec,
but
also
conformance
tests,
and
that
way
we
can
guard
against
future
behavior.
Like,
for
instance,
I
mean
I'm
surprised
to
learn
that
it
says
anything
about
nested
indexes
who,
who
is
the
smart
person
that
thought
of
that?
Even
that's
nice,
but
even
like
discovering
an
image
in
a
deeply
nested
index
is
that
breadth
first
is
that
depth
first,
is
it's
like
I?
I
don't
even
know
how
I
assume
two
container
runtimes
come
up
with
a
completely
different
answer
for
that,
and
therefore
everything
explodes.
C
So
that's
that's.
I
think
a
big
reason
why
we
have
shied
away
from
that,
but
if
there
are
folks
at
docker
and
folks
in
the
run
time
space
that
are
interested
in
resolving
that
and
and
having
that
be
more
uniform,
then
that
reopens
that
possibility.
I
think
I
think,
there's
still
sort
of
a
conceptual.
C
I
think
we
have
all
we
had
all
prior
to
this
discussion.
Sort
of
tacitly
agreed
that,
like
alpine
is
one
thing
like
well,
it's
an
it's
an
image
index
of
n
things,
but
at
least
like
the
container
bits
are
the
thing
we
want
to
sign,
or
at
least
talk
about
and
so
like.
When
I
sign
it,
it
doesn't
modify
the
thing.
Sanjay
can
sign
my
sign,
the
same
thing
that
I
signed
and
they
are
not
the
order
of
those
signings
doesn't
matter
it's
not
that
sanjay
is
signing.
C
My
signature
of
the
thing
or
my
wrapper
of
the
thing,
with
containing
my
signature,
et
cetera,
et
cetera,
that
it's
sort
of
like
the
the
layer,
bits
and
config
bits
sit
there
and
quote
unquote,
are
the
image
and
then
we
I
say
that
image
is
good
or
that
image
contains
this
or
that
image
is
you
know
whatever?
So
it's
definitely
like
a
conceptual.
You
know,
sort
of
expanse
to
say
now
we're
gonna,
say
maybe,
or
at
least
consider
like
the
image,
might
actually
mean
the
image
plus
my
signature
or
the
image
plus.
C
B
Yeah
the
comment
I
was
going
to
add
to
this
was,
I
think,
what
you're
looking
at
is
saying.
We
should
just
have
it
all
as
one
index
here
and
the
discussion
on
d
when
it
got
to
that
part
really
did
focus
on
that
makes
sense
when
you're
the
image
originator,
but
it
doesn't
make
sense
when
you're
extending
this
down
the
road
just
because
of
our
concerns
with
changing
the
digest
everywhere
and
how
much
we
see,
workflows
that
are
really
dependent
on
that
digest,
not
changing.
B
When
you
look
at
science
solutions,
the
signature
is
based
off
that
digest
not
changing
on
the
image
when
we
look
at
people
that
are
making
these
deployments
in
a
production,
environment,
they're
grabbing
that
digest
and
comparing
across
to
make
sure
nothing
changed,
because
they
want
to
make
sure
they're
deploying
the
same
image
that
was
built
somewhere
else
and
nobody
modified
it
in
the
middle
of
that.
B
G
This
is
like
a
little
bit
written
on
the
issue
as
well
like
that
yeah
like
like.
Sometimes
you
have
many
of
these
laws
where
you
you
kind
of
want
the
dodgers
to
change,
but
there
could
be
like
like
different
clothes
as
well,
where
it's
actually
like
like
go
when,
when
you
have
different
components
that
need
to
understand
like
when
the
image
changes,
for
example
like
at
the
moment
like
they
can
react
to
the
cases
where
your
container
bits
change.
G
For
example,
like
somebody
pushes
or
changes
file
like
a
component,
can
react
to
it,
but
on
the
same
time
like
with
this
model,
they
can't
react
to
it
like
another
station's
changes
or
something
like
that,
while,
like
I,
I
think
you
can
come
up
with
flows
where,
where
like
like,
that
would
be
useful
as
well
and
and
in
those
flows
like
it's.
Actually,
it's
important
for
the
type
just
to
change
or
like
if
the
piece
is
important
for
like
a
component
to
understand
that
this
image
has
been
updated.
C
You
know
in
either
of
the
forms,
either
the
tag,
the
tag
fallback
form
or
the
referrers
form
the
same
system.
That
would
be,
you
know,
sort
of
pulling
what
the
latest
tag
points
to
to
see
if
it's
digest
changes
that
same
system
could
also
be
querying
tags
to
look
for
new
attestations
or
look
or
query
referrers
to
look
for
internet
stations
et
cetera.
C
So
maybe
I'm
missing
something
about
that
point,
but.
G
I
mean
currently
there's
also
like.
What's
missing?
Is
that
you
can't
really
like
understand
like
what?
What
at
the
stations
where
a
part
of
the
like
a
specific
image,
build,
or
something
like
that
like
like,
for
example,
like
we,
have
those
those
digital
stimulus
out
there?
They
have
lots
of
signatures,
like
which
one
of
the
signatures
is
the
correct
one
now
like
and
like.
G
If
I
would
imagine
that
at
the
moment
they
don't
have
at
the
stations,
but
at
some
point
they
will
have
at
the
stations
and
they
will
have
like
34
or
different
at
the
stations
and
like
like,
what's
like
like.
What's
the
connection
with
like
because
like
actually
only
one
of
them
is
the
valid
one?
Well,
I
think
I.
C
Think
that
that's
sort
of
a
conceptual
difference
too,
where,
because
it's
so
reproducible
there
might
be
50
different
workflows
that
produce
the
same
digest
image
right.
That's
that's
like
a
feature
of
distralis
that
that
is
possible.
So
I
get
what
you're
saying
about
like
now.
Do
I
have
to
scan
all
those
attestations
to
see
if
any
of
them
were
produced
using
a
vulnerable
dependency
or
something
that
definitely
is
complicating,
but
I
don't
think
that
that's
necessarily
a
misfeature
of
a
reproducible
yeah.
I
I
I.
G
Don't
think
it's
like
too
specific
to
this
image
like
how
would
they
expire
but
like
even
like,
with
like
the
current,
like
simple
release
pipelines
like
if
you're
like,
for
example,
I'm
doing
a
releases
from
my
repository,
I'm
also
doing
magnetic
builds
and
like
master
branch
builds
like
often
like
master
branch
builds
and
nightly
builds
will
not
have
binary
exchange
so,
but
but
then
like.
G
When
I'm
looking
at
my
release
or
something
like
this,
I
don't
want
to
see
that,
like
okay,
like
this,
this
image,
like
it,
has
some
kind
of
like
at
the
stations
for
the
master,
builds
and
like
nitrogens
as
well
like,
like.
That's,
that's
like
that's,
not
relevant
to
me
at
all,
like
if
I'm
just
looking
at
like.
What's
the
version
one
or
some
of
this
is.
A
So
I
mean
this
is
this
is
addressed
in
one
of
the
use
cases
where
we
want
to
know
what
was
the
latest
thing
that
was
appended
to
a
container
image.
So
what
was
the
latest
signature?
We
don't
want
to?
We
want.
We
don't
want
the
whole
list
of
attestations.
We
just
want
the
latest
one.
F
A
If
someone
wants
to
indicate
that
you
know,
if
you
want
to
just
get
the
the
latest
thing
then
get
the
latest
then
get
the
first
element
or
the
last
element
of
the
list.
G
Going
a
bit
back,
I
don't
necessarily
think
that
that
this,
the
last
signature
is
important.
This
is
like
necessarily
the
correct
one
because,
like
there
are
valid
cases
where
you
want
two
signatures
right,
because
you.
G
Signatures
from
two
different
roles,
but
you
don't
want
like,
like
some
some
other
like
person
in
their
random
role,
signing
a
different
image
that
happened
to
have
the
same
container,
because
you
don't
want
this
signature
to
to
to
also
become
like
part
of
the
images,
at
least
in
our
use.
Cases
like
like
there's
different
ways
to
look
at
it.
Of
course,.
A
Right
so
so
the
specific
use
case
that
I'm
thinking
about
is
chain
of
custody.
This
is
one
of
those
things
that,
like
very
regulated
environments,
would
like
to
have
so
in
those
situations
you
want
to.
A
C
I
think
it's
a
valid
use
case.
I
think
I
think
you
wouldn't
necessarily
need
to
do
that.
I
don't
think
in
a
chain
of
custody,
you
don't
only
care
about
the
latest
link
you
care
about
each
link,
so
even
in
that
case
it's
not,
you
could
do
that
with
either
a
signature
or
an
attestation.
That
says
I'm
jason
and
I
held
this
image
from
x
to
y
time,
and
then
I
handed
it
off
to
brandon
and
he
held
it
from
y
to
whatever.
A
Right
but
you,
how
do
you
track
that
besides,
I
mean
that's
the
way
that
you
track
it
is
you
say,
like
okay,
here's
jason's
stamp!
Now
he
occurred
at
this
time
stamp.
Now
it's
brandon's
damn
and
it
occurred
at
this
time,
and
if
you
want
to
verify
that
you
say
okay,
let
me
verify
whether
you
know
this
matches
brandon's
id
okay,
that
matches
brandon's
id
now.
Let
me
check
if
it
matches
jason's
id
and
so
on
and
so
forth,
so
it
it's
the
verification,
when
you
hand
over
something
that's
important.
G
Yeah,
I
think
it's
like
the
model
that
we
had
in
mind
would
would
have
been
that
once
you
hand
it
over,
they
will
add
a
new
signature
on
it
and
it
will
like
conceptually,
become
a
new
image
that
replaces
the
old
image
with
the
new
signature.
So
that's
that's
a
difference.
Yeah.
A
It's
a
it's
a
different
thing
it,
but
it
doesn't
really
match
it.
It
doesn't
really
match
what
you
know,
at
least
from
from
what
I
am
seeing,
what
oracle's
customers
are
asking
for?
That's
not
what
they
want.
They
want
to
verify
each
one
of
it.
They
don't
want
to
just
trust.
You.
G
No,
I
I
mean
that's
what
I
meant
that,
like
the
image
is
already
assigned,
someone
will
come
in
and
they
will
add
their
signature
in
a
different
role.
Now
the
new
image
replaces
stable
damage.
The
new
image
will
now
have
two
signatures.
So
now
now,
when
I'm
like
pulling
this
new
machine,
I
can
verify
that
that
this
image
has
been
signed
by
two
rows
and
like
yeah
and
oh.
G
The
boys,
the
difference,
is
that
like
like,
when,
in
our
model,
when
you
add
the
second
signature,
then
you're,
basically
like
modifying
an
image
you're
making
like
a
shallow
copy
of
it.
That's
like
that's
like,
like
99
percent
of
it
is
the
same,
but
the
digest
has
changed
while
in
the
current
one,
like
basically
you're
saying
that
the
image
was
is
just
like
the
digest
of
the
container
bits
and
like
whoever
adds
like
rows
to
images.
G
That
use
happened
to
use
the
same
container
bits
they
all
put
together
in
the
same
group
and
then
like
you
can
just
see
like
like,
like
you,
don't
know
how
many
bills
were
made,
but
those
builds
share.
The
container
bits-
and
this
is
like
a
collection
of
all
the
signatures
that
are
made
to
this
collection
of
images.
A
Yeah,
so
what
you're
saying
is
that
the
indication
that
something
new
was
added
to
that
chain
of
custody
is
the
different
digest
of
that
index.
Correct.
B
Yeah,
so
I
I
think
earlier,
one
of
the
comments
that
you
had
tonics
was
that
you
were
worried
about
having
a
lot
of
these
other
things
that
were
just
pushed
by.
Whoever
had
that
digest
was
pushing
content
and
one
quick
point
I
wanted
to
make
that
one.
My
main
point
was
that
these
people
still
need
right
access
to
your
repository
you're,
not
getting
around
that,
and
so
it's
going
to
be
someone
that's
got.
You
know
the
ability
to
push
this
data
up
to
your
repository.
B
All
that
stuff
might
stay
the
same,
but
you
can
still
have
a
new
manifest
with
a
new
digest
that
new
content
pushes
to
so
those
were
a
couple
of
small
side
points
to
think
about,
but
the
bigger
one
that
I
really
wanted
to
push
for
was
that
I
think
you've
got
a
vision
for
what
you
want
to
see
done,
and
I
think
it
might
be
easier
to
discuss
that
if
we
just
went
ahead
and
put
a
proposal
f
out
there
and
create
the
proposal
and
say
here's
our
vision
for
what
we
want
to
do,
because
what
you're
proposing
isn't
just
proposal
d,
because
d
actually
said
okay.
B
This
is
only
when
we
do
this
for
the
originator
and
we're
still
pushing
digest
tags,
and
we
still
have
this
other
path
in
there
to
do
things
that
weren't
digest
and
it
explicitly
wasn't
going
into
them
mutating
the
same
index
over
and
over
again.
It
was
trying
to
avoid
that,
and
so
I
think
you've
got
something
far
enough
along
in
terms
of
your
vision,
for
what
it
looks
like.
G
We
can
do
this
and-
and
you
can
give
me
more
points
of
like
what
the
differences
are,
so
that
I
don't
miss
anything
but-
and
it's
also
like,
I
think
why
we
haven't
done
this-
is
that
because,
like
there's,
there's
yeah
there's
all
these
moving
parts
like
that
like?
Is
there
like
an
extra
attack
that,
like
would
point
to
that
sign
manifest?
So
because,
like
there's
some
use
case
for
it,
then
it's
like
what
do
you
put
in
an
annotation
like?
G
Do
you
do
your
bootleg
and
do
like
inline
the
signature
there
like
what
we
might
be
also
interested
in
but,
like
all
of
those
parts,
are
kind
of
like
flexible?
So
I
I
don't
think
we
would
have
wanted
to
just
like
put
all
our
stuff
in
there
saying
that,
like
no,
we
don't
like
the
extra
attacks
and
the
signatures
need
to
be
in
line
and
stuff
like
that,
because,
like
like,
like
these,
are
all
like.
Just
like
up
for
discussion
and
like
it's,
I
think
that's.
C
Parts
we've
had
that
in
other
proposals
too,
where
people
say
like
you
know
this.
This
sort
of,
like
is
the
bones
of
the
of
the
proposal,
and
this
is
like
a
thing
that
if
it
happens
great
and
if
it
doesn't
happen,
it's
not
like
the
end
of
the
world,
we
would
prefer
to
have
signatures
in
line,
but
if
people
find
a
reason
not
to
it's
not
like,
we
have
to
make
a
proposal.
G,
that's
everything
except
that
part.
B
C
Yeah
I
wanted
to
I
brandon
for
the
record.
I
totally
agree,
that's,
I
think,
a
good
idea.
I
wanted
to
bring
up
a
case
that
I
think
is
illustrative
of
the
issue.
I
think
I
have
with
considering
a
signature
plus
an
image
as
a
new
image
with
a
new
digest,
and
it's
that
let's
say
that
there
is
a
really
bad
vulnerability
in
alpine
digest
abc
like
or
you
know,
alpine316.1
has
a
bug
and
right
now
3161
is
abc.
C
There
is,
as
far
as
I
know,
there
is
no
way
to
get
that
information
and
figure
out
whether
my
signed
wrapper
around
that
points
to
that
same
image.
Unless
you
use
the
nested
manifests
nested
manifest
would
solve
this,
but
then
you
have
a
bunch
of
runtime
problems.
Maybe
we
can
solve
that,
but
I
think
that's
the
issue
with
with
proposal
d,
fundamentally
with
the
adding
new
manifest
digest
manifest
descriptors
to
the
index,
is
that
I
can.
G
C
C
F
That's
for
the
multi-platform
it's
like
there
are
multi-platform
vulnerabilities,
but
it's
quite
possible.
You'll
actually
have
an
arm
only
one
so
that
it's
probably
better
to
compare
or
like,
for
example,
windows
and
linux.
Images
can
be
shipped
together
right,
so
there's
a
chance
that
the
windows
will
be
vulnerable,
but
the
other
one's
not
so,
it's
probably
better
to
check
the
actual
digest
for
the
the
image
manifest
not
for
the
index.
C
So
instead,
so
I
still
have
to
discover,
I
have
to
crawl
that
index,
manifest
to
find
all
the
vulnerable
images,
potentially
there's.
Probably
one
vulnerable
image.
You're
like
you're
right,
there's,
probably
not
a
lot
of
multi-arch
vulnerabilities.
F
But
you
have
to
call
the
registry
anyway
right
because
you're
trying
to
work
out
which
tags
or
which
things
contain
that
elements.
So,
for
example,
if
I
have
my
image
built
on
top
of
the
alpine
image
or
something
like
that,
there'll
also
be
some
crawling.
That
needs
to
be
done.
F
A
C
C
I
think
the
the
general
I
mean
the
the
reason
that
chris
and
I
think
we're
chuckling
about
it-
is
that
it's
a
sort
of
a
boil
the
ocean
type
of
problem
right,
like
sure,
wouldn't
it
be
nice
if
there
was
a
graph-based
ocib2
that
trivially
handled
all
of
these
issues,
but
you
know
now
you
have
the
rollout
problem.
I
think
that
was
roughly
the
feedback
on
proposal
c
was
like.
A
A
C
A
F
There
was
the
inside
the
notes
from
20
29
in
march,
a
discussion
on
like
it
sees.
Actually,
if
you
squint
kind
of
an
index.
B
Yeah
c
very
much
was
saying
and
I'm
putting
words
in
your
mouth
and
each
only
because
you're
too
busy
taking
great
notes
that
it
was
saying.
Okay,
we've
got
this
index,
but
we
want
to
do
enough
changes
that
we
should
also
version
the
spec,
and
so
it
was
looking
at
what
decision
points?
Do
you
make
in
terms
of
when
you
version
the
spec,
so
that
was
where
we
kind
of
came
out
that
difference.
B
F
I
mean
that
my
my
my
standpoint.
As
I
said,
the
beginning
is
like
if
either
like.
Ideally
we
change
nothing
just
because
then
it
just
works
or-
and
I
think
in
parallel,
we
should
look
at
building
out
a
v2
from
learnings
we've
got
and
thinking
about
how
we
can
how
we
can
get
people
towards
that.
But
that's
yeah!
That's
like
a
five
year
project.
F
That's
not
something
we're
gonna
solve
now
anything
in
between
kind
of
feels
like
a
we're
gonna
get
stuck
in
the
in
the
the
current
fallbacks
or
things
like
that.
B
C
yeah,
I
mean
yeah.
I
totally.
I
totally
agree
with
the
point
about.
If
there
is
a
fallback
mechanism
just
because
of
inertia,
the
fallback
mechanism
tends
to
become
the
mechanism.
I
think
that's
a
bit.
We've
had
that
discussion
in
a
few
different
ways.
I
think
that's
why
so
like
proposal
e
is
pretty
good.
I
think
because
it
addresses
the
fallback
problem
you
don't
have
to,
like.
C
You,
don't
have
to
update
your
registry
to
get
these
nice
benefits,
but
over
time
as
registries
pick
up,
support
assuming
registries
pick
up
support.
Maybe
they
never
do
and
we
get
a
you
know
a
pretty
good
fallback.
As
registries
pick
up
support,
then
nice
things
get
to
be
a
little
easier.
B
C
B
F
G
G
B
Yeah,
that
is
one
of
the
downsides
of
the
implementation
I
put
out
there
is.
I
actually
made
the
query
for
the
manifest
in
the
fallback
scenario,
an
option,
so
I
don't
pull
back
all
the
annotations
and
the
initial
query
unless
I
spent
unless
I
pass
an
extra
option,
it
says
actually
go
out
there
and
fetch
all
those
manifests
to
pull
those
up.
B
B
B
Cool,
I
had
a
few
other
things,
I'm
just
being
conscious
of
time.
I
want
to
make
sure
we
actually
save
some
of
the
stuff
there
for
them
there.
So
I
had
a
few
other
that
were
quick.
Oci
changes.
Do
we
need
any
layout
changes
needed
that
came
from
when
I
was
looking
through
some
of
the
zot
stuff?
When
I
was
going
through
some
of
the
code
there,
I
saw
a
comment
that
was
like
you
know:
hey.
B
Maybe
we
should
talk
to
the
working
group
about
what
this
looks
like,
and
I
was
thinking
the
same
thing
when
I
was
doing
pushing
this
stuff
into
an
rci
layout.
Originally,
when
I
was
looking
proposedly,
I
was
thinking
just
push
the
tag
into
the
into
the
layout.
The
same
way
I'll
push
any
other
tag
in
there,
and
then
I
can
just
do
the
tag,
queries
back
and
forth.
B
Perhaps
we
want
to
think
about.
Does
it
make
sense
to
add
some
other
fields
into
that
layout
spec,
and
then
we
can
just
query
those.
Instead,
it
makes
it
a
little
nicer
something
to
think
about.
I'm
guessing.
That
might
just
be
something
that
josh
and
I
are
interested
in.
I'm
not
sure
other
people
are.
D
B
So
something
to
think
about.
So
I'm
just
raising
that
up
as
a
little
conversation
point
for
thinking
going
down
the
future
another
one
I
had
in
there
was
show
the
query
response
that
we're
talking
about
in
those
and
and
the
refers
api
should
that
be
index
or
do
we
need
a
new
media
type
for
that
one
and
that
kind
of
came
from
a
comment
that
justin
had
on
the
pr
a
while
back
that
I
don't
think
many
people
saw
just
because
it
was
already
on
emerge
pr.
B
But
the
question
came
up.
You
know
we're
we're
pushing
back
this
response,
but
it's
on
a
query:
it's
not
an
actual
index,
there's
a
generated
index
so
that
you
can't
really
trust
the
digest
of
that,
and
so
I'm
not
too
picky
on
either
way
of
that
one.
But
I
kind
of
want
to
make
sure
the
question
was
visible
to
people
to
know
that
there
were
concerns
as
whether
or
not
that
should
be
an
oci
index
versus
making
a
new
media
type
for
the
response.
B
So
those
two
are
getting
some
wheels,
turning
feel
free
to
chime
in
ping
me
afterwards.
That
kind
of
stuff
like
I
said
these
were
kind
of
quick
things,
because
I
do
want
to
save
time
for
stuff.
At
the
end,
the
last
one
there
is
an
open
issue
out
there
for
renaming
everything
we
have
everything
we
are
calling
with
a
reference
to
call
it
like
refers
refer.
Something
like
that,
the
idea
being
that
we've
got
a
reference
already
out
there.
B
Distribution
distribution
uses
that
whenever
you're
converting
like
this
whole,
you
know
alpine
latest
into
whatever
you're
querying.
That
is
a
reference
right
now
and
so
we're
already
using
the
term
reference
everywhere
else
to
mean
that
thing
that
is
like
an
image
name
translated
kind
of,
and
so
I
wanted
to
disambiguate
make
sure
we
weren't
reusing
the
same
terms
for
our
stuff,
because
that
would
just
get
even
more
confusing.
So
I
propose
refers
refers
if
people
want
to
propose
another
term
feel
free,
throw
that
over
the
issue.
B
Otherwise,
if
you
don't
speak,
we'll
probably
just
keep
renaming
stuff
and
it
gets
hard
and
hard
to
undo
later
on,
and
that
was
my
quick
rapid
fire.
So
I
mentioned
I
was
trying
to
get
through,
so
we
could
get
to
the
more
interesting
discussions
there.
So
josh
you
had
the
proposal
e
upgrade
scenarios.
I
think
that's
where
you
want
to
spend
the
most
time
on
this.
D
You
see
my
browser,
we
can
okay,
so
one
of
the
things
about
proposal
e.
So
we
have
started
going
down
the
path
of
like
starting
to
validate
it
because
it
seemed
up
until
recently
that
it
was
where
we
were
headed
so,
but
I
opened
up
this
pr
yesterday,
number
49
with
adding
some
content
to
the
upgrade
dock
and
basically-
and
this
is
a
little
silly-
and
if
this
is
not
helpful-
I'm
not,
I
won't
be
offended,
it
won't
be
offended,
but
I'm
trying
to
think
about.
D
I
was
talking
to
brandon
about
what
are
like
the
different
components
here,
and
you
have
producers,
registries
and
consumers
that
are
not
going
to
upgrade
to
these
to
these
new
things
at
all,
and
so
I
just
wanted
to
put
like
a
some
sort
of
like
evolution,
kind
of
showing
the
evolution
of
these
types
of
clients.
So
the
tree
is
like
a
client
that
can
do
all
the
things
on
the
producer
side
and
the
beaver.
I
I
couldn't
find
like
really
good
emojis
for
this,
but
basically
like
these
are
all
now.
D
We
have
like
a
table
of
all
the
different
combinations
of
between
registries
and
clients
on
each
side
of
the
equation,
and
what
I
wanted
to
do
is
with
the
forks
that
we
have-
and
this
is
this
page
see
if
we
could
play
through
these
scenarios
and
see
that
they
actually
work
in
the
way
that
we
expect
them
to
so
right
now
I
have
brandon's
red
client
as
both
the
beaver
and
the
tree,
the
crane
fork
as
the
squirrel
and
the
branch
and
then
the
distribution
fork
as
the
motorcycle
and
then
distribution
on
main
is
the
bicycle.
D
That's
pretty
much
it
this
is.
This
is
up
on
the
pr
and
kind
of
like
what
needs
help
reviewing
is
do
these
descriptions
make
sense
to
people
as
far
as
what's
going
to
work
and
how
it's
going
to
work.
B
Find
the
mouse,
so
I
can
find
a
new
button
here.
The
other
big
thing
is
the
bold
was
this
cases
that
we
really
want
to
consider
supported,
and
there
are
some
things
down
there
where
we
didn't
bold,
because
we're
going
to
say
those
are
cases
that
we
just
don't
think
should
be
supported
anywhere.
B
We
we
expect
the
registry
is
going
to
throw
that
back
and
say
I
don't
understand
this
manifesto,
so
I
don't
know
how
to
load
this
into
the
registry
you're
getting
rejected,
and
similarly
that
one
other
case
down
there,
where
you
might
have
a
client.
That
only
knows
the
one
scenario
there
where
it
knows
the
back
version,
so
the
squirrel
version
instead
of
b
reversion.
B
So
if
your
consumer
only
knows
image
spec
and
your
producer
is
trying
to
push
the
new
artifact
media
type,
then
the
consumer
won't
know
how
to
read
that,
and
so
I
think,
that's
kind
of
an
obvious
case
where
there's
going
to
be
a
challenge.
But
it's
just
something
to
keep
in
mind,
as
that
might
be
another
one
of
those
issues.
Upgrading
everything
else
should
work
in
these
scenarios
or
have
nice
fallback
situations.
B
Correct
it
wouldn't
know
the
new
manifest,
so
I
wouldn't
know
how
to
pull
down
and
parse
apart
that
manifest,
hopefully
they're
not
going
to
be
clients
that
go
in
that
path.
Hopefully,
clients
are
going
to
go
from
not
knowing
anything
to
knowing
everything,
but
it's
possible.
Someone
would
only
configure
their
client
to
know
the
image
spec,
and
then
that
is
a
scenario
that
I
wanted
to
keep
in
mind.
D
D
Or,
if,
like
for
the
dot
for
the
docker
folks,
like
you
know,
is
there
any
other?
Like
general
concerns
with
the
with
the
working
group
or,
like
you
know,
I
want
to
make
sure
that
the.
F
F
G
Yeah,
I
think
that's
the
the
definition
of
the
root
object
that
that's,
I
think,
is
the
most
fundamental
thing
from
like
the
just
like
looking
at
the
proposal
e
as
well
like
like
yeah,
like
definitely
like.
We
don't.
If,
if
there
is
this
new
api
like
like
random,
show
like
that,
does
this
fancy
lookups
like
this?
G
Will
I
don't
know
if
this
fits
our
requirements
from
like
from
the
from
the
backboard
compatible
side
and
like
if
you
look
at
like
the
like
there's
some
tagging
scheme
there,
as
well
like
from
the
background
compatible
and
stuff
right
like
but
they're
supposed
to
do
like
the
list
of
tags
like
on
every
pool
or
like
every
verification.
G
So
I
think
from
that
side
one
of
the
issues
is
purely
like
performance
for
us
because,
like
we
want,
if
we
want
this
to
be
not
like
an
option
thing,
that's
like
only
used
rarely
but
like
really
like
integrated
into
like
docker
flows.
Then
it
needs
to
be
like
very
snappy
and
like
and
almost
like,
like
moving
from
like
on-site
images
to
signed
images
shouldn't
like
make
user
experience
worse
so
like.
G
I
would
see
that
if
I
need
to
do
a
pull-
and
I
need
to
like,
do
it
like
a
tax
list
in
there
as
part
of
my
commands,
I
think
this
is
just
like
too
slow
in
lots
of
cases
and
it's
it
could
be
like
breaking
from
from
that
side
already
and,
and
all
of
course
like.
That
brings
back
to
that
that
as
well,
that,
like
we
don't
want
like
arbitrary
signatures
to
be
there,
that
will
also
slow
things
down,
and
so
so
like
there
is
a
performance
side,
but
we're
also
like
concerned.
C
C
If
there
is,
I
mean
that
that
leads
me
to
believe
that
in
all
these
prototypes
and
stuff
we
build,
we
should
also
keep
an
eye
on
performance
right
like
so
so
we
can
reg
client
list
the
artifacts,
but
can
we
do
it
quickly
and
what's
the
load
on
the
server?
At
the
same
time,
you
did
mention
one
thing
I
wanted
to
also
talk
about,
which
was
so
like.
There
are
34
38
signatures
on
the
distroless
image.
C
Docker
pull
shouldn't
have
to
verify
all
of
them
in
order
to
pull
that
image
right
it
should.
There
should
be
some
policy.
Maybe
the
default
policy
is
tucson
is
to
verify
them
all,
or
the
default
policy
is
to
verify
none
of
them,
and
then
you
have
to
like
incrementally
add
things
you
start
to
care
about.
C
I
don't
know
that's
that
turns
into
a
sort
of
product
type
of
discussion,
but
I
don't
think
you
should
verify
every
signature
by
default
as
a
first
cut
because,
like
you
said
it's
a
lot
of
extra
work,
both
on
the
client
side
and
the
registry
side
to
serve
all
of
those
manifests,
and
it
doesn't
really
tell
you
anything
else
like
I
don't
I
don't
care.
C
If
josh
signed
my
image,
no
offense
josh,
I
don't
care
if
josh
signed
it
he's
not
one
of
the
people
that
I
consider
authoritative
about
this
image
or
when
I'm
going
to
pull
it
into
staging.
I
don't
care
that
it's
not
signed
by
like
the
prod
rollout
gatekeeper,
because
I
it's
not
time
for
that.
Yet
so
I
think
there's
a
lot
of
cases
where
you
don't
both
pro
both
for
performance
and
because
it
doesn't
tell
you
anything,
you
don't
have
to
verify
every
signature,
yeah.
G
I
I
think
that
makes
sense
in
like
if
you,
if
you
think
about
this
in
the
case
of
like
I,
have
like
my
deployment
policy
or
like
what,
whatever
like
the
voice
it
for
for,
like
an
exchange,
an
exchange,
that's
happening
in
the
supply
chain
but
like
if
we
just
want
to
make
it
like
as
part
of
like
talker
flows,
then
I
I
think
yeah
we.
I
think
we
need
to
verify
and
pull
and
like
then
the
question
is
like:
what
do
we?
G
What
do
we
show
there
to
the
user
like
we
want
to
show
there
that,
like
like
this
image,
was
signed?
It
was
like,
for
example,
like
signed
by
my
email
address,
like
my
email
address
was
verified
by
like
the
six
store
or
whoever
and
like
I
want
to
print
this
out,
but,
like
let's
say
like
now
that
we
have
30
signatures
like
how
do
I
pick
like
which
one
of
those
is
correct
like
like
I
I
imagine
or
like
like
I
like
I.
G
I
agree
that,
like
showing
the
sturdy
signatures
to
user
is
pointless
as
well
like
like
like
they
have
nothing
to
do
with
this,
but
like
how
do
I
know
which
one
is
the
correct
one
which
one
do
I,
which
one
do?
I
show
it
and
the
same
thing
with
like
if
the
image
is
signed,
probably
like
in
docker
image
ls,
you
want
to
see
that
this
image
is
signed
like
this
is
like
more
trusted
image.
This
is
what
you
should
use.
G
If
I
do
to
inspect
it,
it
should
show
me
like
probably
something
like
like
like
cosine.
Three
does
like
it
shows
me
like,
like
these
are
the
signatures.
These
are
the
stations
and
but
they're
probably,
I
need
to
show
all
the
signatures
because
again
like
how
do
I
verify
which
ones
are
important
and
which
ones
are
not,
and
I
think
don't
think
this
cosine
three
does
this
at
the
moment,
but
I
think
like
when
we
show
that
this
is
signed
by
like
those
two
certificates.
G
G
On
like
lots
of
lots
of
the
clothes
as
well
like,
like,
I
understand
that
there
are
flows
where,
where
you're
like
very
you,
have
very
secret
weapons
like
I
require
one
one
signature
from
this
role,
then
then
the
workload
is
okay,
but
there's
also
like
flows
where
we
just
need
to
understand
like
what's
going
on.
We
should
need
to
show
like,
what's
the
like
the
like
properties
of
this
object
and
stuff,
like
that,
where,
where
this
optimization
can't
be
done
so
easily.
C
Yeah,
if
the
so
in
general,
we're
trying
to
collapse
a
non-binary
state
of,
is
this
signed
or
not
down
to
a
binary
state
of?
Is
it
signed
like
meaningfully
like
there
are
38
signatures
that
mean
individually?
C
You
know
many
many
things
and
you
just
want
to
show
a
checkbox
in
there
like
docker
images,
ls
that
says
yes
signed
right,
you
could
you
could
have
a
policy,
you
could
say
your
policy
is.
It
must
be
signed
by
someone
that
I'm
like
someone.
C
That
means
something
someone
you
know
whatever
means
something
means
you
could
also
just
say,
as
the
default
like
fallback
policy
of
is,
did
anyone
sign
this
is
anybody
is
any
name
attached
to
this
as
a
person
who
knows
about
this
image,
then
you
don't
need
in
that
case
also,
you
don't
need
to
verify
everyone.
You
you
go
until
you
find
one
that's
verified,
and
then
you
stop.
B
Yeah,
I'm
sure
sanjay,
and
I
are
thinking
back
to
all
the
discussions
we've
had
on
the
notary
side
about
how
do
you
define
a
policy
and
how
do
you
define
this
is
what
we
want
to
check
to
see
if
we
are
verifying
this
thing
and
they're
going
to
be
different
scenarios,
each
user's
going
to
have
a
different
scenario
they
have,
and
hopefully
the
common
scenario
is
just
that.
I
see
a
signature
from
a
person
that
I
trust.
If
I
see
it,
we're
done,
and
hopefully
that's
the
first
century
check.
B
I
think
that
is
that
case
over
there,
where
it's
the
same
signers
just
doing
it
every
time
it
runs
on
a
different
environment
or
something
like
that.
It
just
gets
to
reproducible,
build
that
thing.
You're
you're,
seeing
the
same
thing
come
back
over
and
over
again
from
the
same
signers
that
you
trust.
C
Yeah
tianan,
your
question
of
signatures
are
also
scoped
to
the
namespace
and
repo.
Yes,
they
are
so
again.
You'd
only
have
signatures
for
people
that
can
push
to
that
repo.
C
I
think
in
dystrolis
case
distrolus's
case
is
pathological,
but
something
we
should
support
well
anyway,
which
is
that
the
way
that
bazel
builds
them.
It
has
like
build
these
dependencies
and
tag
it
as
debian
11
and
then
build
these
dependencies
and
tag
it
as
debian.
You
know
11.1
or
whatever
the
scheme
is,
and
it
just
so
happens
that
those
are
all
reproducible
so
that
it
ends
up
building
and
tagging
and
signing
for
each
of
those
tags,
which
is
a
little
silly
but
bazel's
a
little
silly.
B
In
addition
to
adding
all
those
signatures
on
there,
so
the
nice
thing
is
the
ability
to
delete
things
that
you
see
that
you
no
longer
need,
and
that's
a
lot
easier
to
do.
If
they're,
isolated,
independent
things
you
can
see.
Okay,
I
already
pushed
a
newer
version
of
this
out
there,
so
I
can
delete
that
old
signature.
C
Yeah
brandon
your
bro,
your
example
of
a
reproducible,
build
that
isn't
silly
like
bazel,
but
saying
like
I
built
this
yesterday
and
got
these
bytes.
I
built
it
today
and
got
these
bytes
I'll,
build
it
tomorrow
and
got
the
same
bytes
that's
useful
signal
because
you're
getting
like
it
is
reproducible.
Look
I
got
from
from
the
same
source
at
three
different
times:
bazel's.
B
The
the
more
valuable
one
to
me
is
if
we
get
two
completely
different,
desperate
builders
that
both
came
up
and
said,
we
both
built
the
same
builder,
a
and
builder
b
in
a
completely
separate
secure
zone,
and
they
both
did
that.
And
so
that's
where
I'm
thinking
there
are
policies
out
there.
People
are
going
to
want
to
see,
make
sure
builder,
a
and
builder
b,
both
sign
the
same
digest.
C
Unless
that
is
the
case,
but
yeah,
I
think
there's
a
lot
of
interesting
questions
around
what
the
default
policy
should
be
or
what
the
default
when
you
pull
a
random
image
from
docker
hub.