►
From YouTube: OCI Weekly Discussion - 2021-09-15
Description
Recording of the OCI weekly developer's call on 15 Sep 2021; agenda/notes here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg#September-15-2021
B
B
A
I
do
I
do
and
actually
like
my
biggest
thing
here,
is
being
able
to
actually
get
like
topics
or
an
agenda
together
for
oci
summit,
which
is
thursday
september
30th,
and
it's
over
in
the
hackmd.
Yes
and
we'd
like
to
be
able
to
actually
get
things
together
for
that,
and
I
would
love
to
be
able
to
have
an
agenda
that
I
could
tell
people
about.
B
A
This
is
a
carefully
designed
moment
of
panic
in
here
that
I
would
like
to
be
able
to
tell
everyone
that,
like
here,
is
what
we
are
going
to
talk
about,
because
in
large
part,
I'm
betting,
the
people
that
are
trying
to
be
able
to
sign
in
from
wherever
don't
actually
have
all
day
to
be
able
to
hang
out
in
the
zoo.
Just
saying.
A
B
Yeah,
I
think
that
was
the
question,
because
I
think
you
started
this
on
the
slack
conversation.
Did
we
want
to
agenda?
Was
it
ad
hoc?
When
does
the
ad
hoc
turn
into
an
actual
agenda,
and
I
think
having
some
structure,
especially
is
some
amount
of
people
will
be
virtual,
I'm
not
trying
to
put
any
weight
on
it.
Great.
D
Yeah
well,
I
think
that
that's
the
complicating
factor,
because
I
think,
when
it
felt
like
the
bulk
of
people,
would
be
in
person
it's
like
easier
to
do
a
unconference
style
like
hey
here's,
some
stickies,
everybody
write
a
topic,
put
it
on
the
board,
let's
organize
them,
and
now
that
it's
maybe
leaning
more
virtual
than
in
person.
I
think
I'll.
D
You
know
for
certain
topics
so
yeah,
maybe
that's
I
don't
know
how
specific
we
can
get,
but
we
can
at
least
probably
come
up
with
three
four
five.
You
know
big
blocks
that
make
sense
to
cover
and
lay
them
out
across
the
day,
so
that
people
who
are
virtual,
can
you
know
I
don't
know
how
many
people
really
want
to
spend
eight
hours
on
zoom.
D
E
E
Gonna
talk
about
the
image
spec
detail
x,
but
the
kind
of
thing
that
I'm
sort
of
curious
about-
and
I
think,
would
be
good
for
a
meeting
like
this-
that's
gonna,
probably
draw
in
more
community
members
than
like
just
usually
the
people
that
are
here,
would
be
sort
of
like
an
open
session
where
you
know
people
can
come
and
the
question
the
high
level
question
can
be
like
what
is
missing
for
you.
What
are
what
are
the
problems
that
you're
facing
when
you
use
these
specifications
and
it
could
be
everything
from
like?
E
Oh,
I
have
trouble
with
the
documentation
which
definitely
I've
heard
before
and
that's
why
we
did
the
the
jekyll
template
or
it
could
be
something
like
very
specific,
but
it's
really
to
just
bring
people
in
that.
You
know,
may
not
have
time
or
whatever
to
go
to
these
meetings
and
just
to
like
hear
them
out-
and
I
guess
like
the
issue
of
course,
is:
if
no
one
comes,
then
we
probably
want
to
have
something
else
to
talk
about
in
advance.
E
But
I,
for
I
don't
know
if
you'd
call
it
like
a
town
hall
or
something
I'm
thinking
of
gilmore
girls
when
they
used
to
have
town
halls
and
they'd
all
come
and
like
like
talk
about
their
stuff.
Like
that
sort
of
thing.
D
You
know
what
we
haven't
had
here
in
a
little
while
it
seems
like
we
had
a
string
of
it
like
maybe
earlier
this
year
is
people
you
know
saying:
hey
I've
been
doing
something
cool
and
it's
related,
maybe
isn't
like
a
spec
change
or
anything
like
that.
But
you
know
anything
that
people
have
as
kind
of
a
project
or
something
they're
playing
with.
You
know
we
should
probably
have
a
block
of
time
for
people
to
share.
A
All
right
phil,
I'm
marking
that
as
show
and
tell
to
be
able
to
make
sure
that
we
like
actually
have
time
for
that
as
well.
But,
like
you
know
what
other
pieces
are
coming
up,
that
folks
would
really
want
to
be
able
to
like
have
just
in-depth
conversations
about.
B
I'll
add,
obviously
the
artifact
spec
we've
released
a
draft
today
which
we'll
be
announcing
in
a
minute
so
that
you
know
that's
kind
of
that
working
group
problem
that
we've
been
trying
to
solve
for
a
bit.
So
we
we
have
been
making
progress
on
it.
We
have
a
draft
releasing
today.
Obviously
having
that
refresh
conversation
would
be
interesting.
D
Sargent
says
oci
2,
which
yeah
there
were
a
lot
of
like
sub
topics
around
that
that
you
know
had
hack
and
d
documents
and
that's
a
good
good
reminder
that
you
know
that
that
may
be
an
area
for
you
know
now
that
we
have
kind
of
a
working
group
process
codified.
If
anyone
wants
to
run
with
some
of
those
oci
2
ideas,
I
think
they
would
make
good
like
working
group
topics.
F
I
mean
I
somewhat
said
that
jokingly,
I
think,
in
the
oci
2
process.
What
I
found
was
that
there
was
a
lot
of
different
needs,
that
weren't
really
being
talked
about,
or,
like
I
didn't
even
know
about,
for
the
most
part
and
maybe
like
out
of
a
show
and
tell
like
hey
here,
are
problems.
We
can
maybe
come
up
with
some
common
ground
to
go
attack
because,
like
yeah,
the
oci
2
proposals
were
really
good.
B
We've
been
talking
about
wanting
to
merge
the
artifact
stuff
into
distribution.
Is
there
other
distribution
changes
we're
talking
about
there's
longer
things
we
were
trying
hoping
to
do
with
distribution
related
to
making
it
a?
You
know,
a
package
manager
for
other
types
as
well.
B
B
I'd
also
agree
on
the
confidential
computing,
because
even
in
this
topic,
I've
seen
a
couple
different
pieces
of
it,
and
is
it
just
the
persistence?
Is
it
the
execution
environment?
Is
it
both?
I
think,
having
a
broader
context
of
where
it
fits
in
will
help,
because
I
think,
there's
been
a
lot
of
different
interpretations
of
what
people
think
encryption
or
confidential
computing
could
be.
G
B
G
A
Yes,
yes,
that
is
actually
the
challenge
there
is
about,
like
the
getting
folks
to
register
requires
being
able
to
have
something
like
an
agenda
getting
an
agenda,
it
requires
who's
going
to
be
there
as
well.
I
can
work
with
this
right
now,
like
I,
I
think
that's
a
rough
good
outline
and
I
can
start
adding
like
times
to
it
and
that
sort
of
thing
it
feels
a
little
thin.
I
kind
of
want
like
two
or
three
more.
D
Yeah,
some
of
them
were
big.
The
other
thing
I
thought
about
tossing
in
there
is
yeah
not
it
goes
back
to
who's
who's
going
to
be
there,
but
any
kind
of
time
that
could
be
spent
on
some
issue
cleanup.
You
know
walking
through
the
spec
repos
issues
prs.
D
I
know
vbats
had
spent
a
few
calls
doing
some
of
that
grooming,
but
yeah
might
as
well
put
some
blocks
of
time
in
there.
For
that.
A
No,
that's
fair!
That
does
give
like
kind
of
some
good
breaks
between
like
discussions
and
like
times
when
people
like
that
are
virtual
might
not
be
around
for
so.
Okay.
D
A
E
E
I
think
I
this
this
probably
isn't
super
related
to
oci,
but
I
just
I
haven't,
really
tried
this
out
yet,
and
I
want
to
understand
like
how
it's
related
to
containers
and
oci
like
more
specifically
because
right
now,
it's
sort
of
presented
as
like
an
initiative
and
a
set
of
tools
and
all
these
big
companies
backing
it,
which
some
of
you
folks
on
here
are
from,
and
I
kind
of
think
it
would
be
interesting
to
better
understand
it.
H
Yeah,
I
think
the
specific
it's
like
it
has
a
bunch
of
broad
things.
I
think
the
thing
that's
specific
to
like
oci
would
be
the
cosine
project,
the
sub,
the
sub
project
cosine
mainly
around
like
provenance,
data
for
images
and
artifacts.
E
B
And
maybe
some
ideas
around,
because
there
are
a
couple
of
efforts
trying
to
solve
signing.
So
maybe
there's
you
know,
I
don't
know
whether
this
might
be
an
ordering
thing.
You
know
this
is
part
of
why
we've
done
the
the
artifact
stuff
to
try
to
support
multiples
without
being
project
specific,
and
then
there
are
project
specific
offerings
because
they're
kind
of
like
the
confidential
computing
is
there
and
they
put
a
comment.
I
put
some
notes
in
there.
B
B
Maybe
that's
another
way
to
put
it
it's
trying
to
avoid
hey
here's,
the
project,
kind
of
show
and
tell
marketing
opportunity
as
opposed
to
what
does
this
group
actually
need
to
do
to
enable
you
know
a
wide
ecosystem
of
capabilities.
H
A
B
D
Well,
I
I
went
to
a
bunch
of
meetings
last
year
when
the
confidential
computing
consortium
got
founded.
I
guess
that's
two
years
ago
last
year,
but
you
know
red
hat:
has
people
involved
luke?
Oh,
I
can't
think
of
his
last
name.
Yeah.
H
D
Was
working
on
enclave
technology,
secure
enclaves,
because
I
I
assume
confidential
confidential
computing
is
more
about
the
you
know,
various
hardware
and
software
enclave
ideas
which
does
have
crossover
to
containers
yeah,
there's,
definitely.
G
A
Sixth
stage,
with
the
with
kubernetes
project,
cncf
tags,.
G
So
they're
creating
a
confidential
computing
tag
work.
You
know
work
group
within
cncf
to
to
cover
some
of
the
efforts
that
the
catec
container
guys
have
been
working
on.
You
know
and
some
of
the
ibm
initiatives
that
have
been
going
on
as
well
and
and
others
there's
a
lot
a
lot
of
groups
but
partially
driven
by
canada
but
they're
they're,
and
we
would
probably
want
to
get
samio
in
you
know
so
yeah,
but.
G
G
I
think
we
need
to
work
with
them
a
little
bit,
but
yeah
they're,
definitely
on
the
signature
stuff
in
the
scanning
that
that's
all
related,
although,
yes,
you
can
do
it
in
hardware
only
if
you
wanted
to,
but
again
they
probably
are
going
to
come
all
the
way
around
and
say:
okay!
Well,
who
do
we
work
with?
G
A
Okay,
I
have
enough
to
be
able
to
kind
of
like
run
from
here,
so
I'll
start
pulling
things
together.
D
Yeah,
we
can
maybe
take
a
crack
at
it
if
you,
if
you
need
help
on
that,
maybe
and
then
sure,
probably
just.
D
H
I
think
the
main
purpose
of
this
was
kind
of
to
to
catch
back
up
on
this
see
where
we
are
and
then
decide
whether
how
we
can
go
forward,
but
I
think
we
had
this
vr
and
a
bunch
of
peers.
We
had
some
discussions
around
it,
but
then
we
kind
of
said
that
you
know,
let's
let
it
run
for
a
bit.
Let's
see
the
the
adoption
and
see
who's
using
it
and
then
we'll
come
back
to
it
with
the
use
cases.
H
So
I
guess
we're
having
that
composition
now
yeah.
So
I
kind
of
added
a
bunch
of
links
with
like
where
there's
now
you
know
it's
defaulting
containing
decrying,
with
keys
on
keys
and
file
system
support
registries,
mostly
supported
and
a
bunch
of
things
to
the
opr's.
H
I
think
the
his
what
happened
last
time
was.
We
were
opening
the
pr
against
the
image,
and
then
we
discussed
that,
instead
of
having
like
a
single
media,
type
or
mime
type
for
the
different
types
of
encrypted
artifacts
that
we
would
have
it
as
a
suffix
and
then
we
created
the
pr
against
the
artifacts
repo
to
add
the
encrypted
suffix.
H
I
think
that's
kind
of
where
we
left
off
and
also
I
put
in
a
bunch
of
use
cases
that
you
know
are
actively
using
this
so
like.
I
think
the
banana
is
a
cat
or
containers
one
but
like
in
ibm
cloud.
We
also
support
pulling
and
decrypting
images
and
openshift
and
so
on.
B
From
the
artifact
spec
perspective,
when
I
last
looked
at
this,
it
sounded
like
there
was
some
disagreement
on
the
thrashing
on
the
number
of
editions,
and
that
was
not
a
non-scalable
thing.
To
be
honest,
I
haven't
really
looked
much
back
at
it
since
I
am
curious
just
because
you
know
with
the
artifacts
work,
the
idea
is
that
those
media
types
would
be
opened,
so
there
wouldn't
be
enforcement
on
layer,
media
types.
So
is
there
something
that
you're
blocked
on
at
this
point
or
is
it
certain
registries
aren't
implementing
it
or
supporting.
H
I
think
the
hope
is
sorry
mike
mike.
Do
you
want
to
go.
H
Yeah,
I
think
the
hope
is
to
kind
of
like
say
that
if
you,
if
you
run
into,
I
think
someone
else
will
mention
this
last
call.
But
if
you
run
into
this
particular
video
type,
you
know-
or
maybe,
if
I
could-
you
mentioned
that,
like
how
do
you
handle
this
or
like
what
different,
runtimes
or
registry
to
support
the
use
of
this
particular
suffix.
B
From
a
registry
perspective,
I
think
that
what
we
said
is
it's
just
it.
We
basically
ignores
it
because
there's
nothing
about
the
blob
media
types
that
should
matter
the
manifest
media
types
matter
because
there's
processing
of
it,
but
the
blogs
are
just
stored
as
opaque,
blobs
and
they're
just
served
they're
stored
and
served
having
a
standard
on
how
people
and
for
you
know,
convey
that
is
certainly
interesting
and
having
that
probably
in
artifacts
would
be
a
good
thing
to
say.
Look
if
your!
B
If
your
layers
are
encrypted
here
is
the
convention
you
should
use.
I
don't
know
if
I'd
say
must,
because
the
whole
idea
is
that
the
premise
of
the
artifact
stuff
is
it's
really
up
to
the
owner
of
the
artifact
type,
and
the
registries
are
just
storage
buckets.
It
knows
how
to
push
discover,
pull
authenticate.
You
know
for
obvious
registers
that
authenticate
at
least
on
push
and
the
stuff
on
the
file,
it's
kind
of
like
the
file
extension
of
files
on
your
disk
on
your
computer.
B
B
I
E
I
Back
a
little
bit
on
blobs
being
untyped,
because
they're
they're
typed
in
the
manifests,
so
I
think
it's
it's.
It
would
be
easy
to.
I
don't
know,
think
up
an
implementation
that
decides
to
store
different
media
types
in
different,
like
backend
buckets,
for
example,.
I
Like
media
type,
the
actual
the
leaf
blobs.
B
Right,
but
what
I'm
actually
saying
is
the
registries?
Don't
care
like?
Yes,
the
manifest
does
have
it,
because
it's
the
way,
the
validation
and
it's
exposed
to
like
when
a
client,
whether
the
container
image,
tooling
or
the
helm,
tooling,
or
an
s-bond
tooling,
when
it
pulls
its
manifest.
It
helps
to
know
what
the
media
types
are,
so
it
can
determine
what
to
do
with
it
from
a
registry.
B
J
J
K
Cases
where
client
versus
registry
wasn't
really
called
out
in
the
spec,
where
the
spec
says
that
the
implementations
must
support
these
for
and
that
you
know,
should
support
other
stuff,
but
doesn't
guarantee
someone
hadn't
made
a
registry
that
would
validate
the
manifest
and
say
hey
those
aren't
valid
media
types
to
me.
In
fact
this,
when
you
look.
B
At
because
the
brand
sorry
zhao
did
a
list
of
all
registries
that
support
artifacts
today
and
the
majority
of
them
do
there's
literally
docker
hub,
which
is
finishing
up
the
work
in
quay
and
the
two
end
pro
the
reasons
that
they
don't
is
because
they
were
overly
restricting
which
media
types
are
supported.
So
to
your
point,
john,
they
must
implement.
B
They
must
support,
at
least
these,
so
they
know
about,
for
instance,
foreign
layers
or
non-distributed
layers,
rather,
but
they're
not
supposed
to
be
limited
to
what
those
types
are
and
to
your
point,
brandon.
It's
other
brendan
mitchell,
you're
right
there
is.
This
is
another
place
where
we
we
didn't
say
like.
Obviously,
the
container
image
format
should
not
care
about
the
helm,
chart
media
types
and
it
shouldn't
ignore
our
mission
just
like
so
no
not
mine.
J
So
if
we
want
non-distributability
to
apply
to
new
kinds
of
media
types,
we
either
need
to
create
a
cross-product
list
of
all
possible
media
types
that
include
the
non-distributability
in
it
or
have
some
guidance
about
like
how
non-distributability
works
or
create
some
new
field
that
expresses
it
because,
right
now,
it's
embedded
in
the
media
type,
and
so,
if
we
want
to
have
encrypted
layers,
do
we
multiply
everything
by
two
now
or
do
we?
Can
we
fix
this
somehow?
Because
it's
going
to
explode.
J
I
Sorry
in
quay
at
least,
we
want
to
be
able
to
do
things
intelligently
with
the
media
type
so
like
right
now.
The
reason
the
artifacts
aren't
fully
implemented
is
because
we
essentially
pushed
whitelisting
too
far
down
into
checking
the
manifest,
but
we
very
much
want
to
be
able
to
offer
the
ability
in
in
the
registry
to
deny
list
or
allow
lists.
B
B
B
So
we
are
trying
to
undo
that
I
have
to
go
back
and
double
click
on
where
the
status
of
that
is,
but
if,
for
the
same
reasons,
we're
trying
to
undo
that
I'm
hesitant
to
try
to
promote
that
on
new
things
because
it
was
problematic.
Do
we
need
to
continue
problematic
patterns.
J
I
would,
I
would
say,
maybe
open
a
proposal
on
the
image
spec
to
remove
it.
We
we
don't
want
to
merge
that
immediately,
but
at
least
we
could
have
the
conversation
there,
and
if
someone
has
a
problem
with
removing
this,
then
we
could
look
into
other
solutions
beyond
just
removing
it
because,
like
yeah,
maybe
microsoft
is
the
only
one
who
cares,
but
it's
quite
possible
that
other
companies
are
using.
This
feature.
B
I
wonder
if
it
falls.
Maybe
this
isn't
the
right
thread
to
pull
on,
because
we're
trying
to
go
back
to
the
encryption
thing,
but
if
this
is
what
helps
unravel
and
enable
that
conversation,
it
might
be
something
we
put
it
into
reserve
right
like
it
was
used,
it
needs
to
be
there
for
a
while.
Obviously,
people
are
still
pulling
images
that
way,
we're
not
going
to
yank
all
them
down,
hopefully
we'll
be
able
to
not
do
that
at
some
point
going
forward.
B
J
Yeah
sure
just
yeah,
let's
start
the
conversation
about
that
and
figure
out
what
our
options
are.
B
But
does
that
help
or
hurt
like
if,
if
we
say
we
won't
be
doing
that
pattern
going
forward?
I
think,
regardless
of
whether
we
yank
it
out
or
switch
like,
I
think
my
suggestion
would
be.
We
should
not
be
recommending
people
use
this
anymore.
It
is
very
problematic.
It
was
done
for
a
reason
that
was
an
older
licensing.
Technology
didn't
match
a
container
model
right.
Sometimes
things
don't
align
in
times
how
technology
and
lawyers
and
legal
licensing
get
solved.
I
think
we're
consolidating
on
a
viable
solution
there.
B
J
Yeah
I
mean
this
removes
an
objection
for
me
is
that
it
doesn't
compose
well
with
so
like.
If
we
can
figure
out
do
microsoft,
loggers
require
encrypted
layers
be
also
non-distributable,
then
that
helps-
and
we
can
say,
okay,
we'll
punt
on
this-
you
can
only
have
non-distributable
legacy,
media
types
or
whatever,
but
just
figuring
out
like
what
we
want
to
do
is
where
I'm
at,
because
I
I
don't
want
to
just
keep
piling
on
to
this
cross
product.
H
Brandon,
what
do
you
think
yeah?
I
think
I
think,
for
the
with
the
registry
side
based
on
discussion,
it
seems
seems
good.
I
think.
H
I
feel
like
there
isn't
necessarily
a
special
need
to
handle
the
encrypted
flops,
especially
I
think
they
can
just
be
treated
like
regular
bulbs.
They
can
be
distributed
because
you
know
they
wouldn't
be
able
to
be
decrypted
anyway.
Yeah.
H
Yeah
so,
and
and
that
we
got,
I
think
I
think
all
is
good,
but
I
don't
think
it's
a
fact
that
much.
I
think
the
only
question
is
then
do
we
have
to
add
some
reference
into.
If
you
see
something
like
that,
how
do
you
like
handle
it
or
some
kind
of
ideas
like
pointing
to
other
projects
and
things
like
that.
H
Kind
of
like
for
like
usage
right,
let's
say
because
this
this
is
gonna
start
getting
b,
start
being
used
a
bit
more
given
the
use
cases
from
cat
and
things
like
that
like
should.
We
also
have
a
part
of
the
artifacts
repo
that
says
you
know
here
are
some
common
media
types
that
you
may
see
and
here's
how
they
can
be
handled
and
implementations
that
use
them.
B
Yeah
I
mean
in
the
artifacts
fact
we
do
talk
about
the
the
media
types
and
some
conversation
around
ordinal
and
non-ordinal
or
compressed
or
otherwise,
so
it
it
does
make
sense
to
put
there
for
no
other
reason,
then
we
obviously
want
to
enable
this
on
all
types
right.
You
know
whether
it
be
wasm
or
you
know.
I
don't
know
if
helm
is
the
best
example,
because
there's
more
of
a
script,
a
template
script,
but
there's
certainly
a
lot
of
other
types
that
are
trying
to
store
stuff
and
I'm
sure
they'd
want
to
be
encrypted.
B
So
john,
I
think
you
had
the
most
feedback
pushing
back
on
it
there
and
that
was
tangled
up
in
this.
You
know
the
non-distributable,
so
we
can
go
back
and
look
at
that
wording
and
see
if
we
can
untangle
that
does
that
make
sense,
yeah.
G
Speak
to
mine,
so
we
talked
about
a
number
of
different
ways:
oh
one
with
a
suffix
one
with
an
annotation
one
with
the
config
element.
You
know,
there's
there's
many
different
ways.
We
can
do
this,
but
we
you
know
we
need.
We
need
to
get
something
here.
J
Yeah
I
I
I
do
think
that
the
suffix
approach
is
correct,
because
it's
something
it
composes
with
any
media
type
right.
You
could
encrypt
anything
yeah.
My
only
reservation
is
like
as
a
standards
body
to
just
like,
approve
this
as
a
pattern
when,
if
we're,
if
we're
going
by
the
book
per
rfc
6838,
it
would
be
great
to
get
this
actually
landed
in
iana
as
a
structured
syntax
in
the
registry.
J
B
J
B
B
So
there
was
a
thing
there
and
the
idea
is
that
the
dozen
or
two
registry
products
and
services
out
there
could
pull
in
that
json
file.
That
has
all
of
that.
So
there'd
be
this
magic
way
that
all
of
a
sudden
you
get
icons
and
localized
strings
the
problem.
Is
we
as
a
standards
body
that
want
to
own
that
list,
or
you
know,
then
who's
to
say
that
those
media
types
are
actually
owned
by
the
entity?
So
now
we're
back
to
the
problem
of
okay,
helm,
wasm
need
to
go
register
those
with
diana.
B
They
would
register
their
manifest
media
types,
that's
how
they
get
the
ownership
of
that
space.
I
think
the
question
comes
back
to
how
many
layer
media
types
do
we
need
so
we
do
have
tar.
We
do
have
oh
there's
a
couple
there,
because
one
of
the
things
that
I
went
through
with
registering
animated
types
is:
there
was
no
concept
of
a
namespace.
B
J
So
this
is
different
than
that.
This
is
a
separate
process
for
registering
a
suffix
which
is
slightly
different
from
registering
a
media
type
itself.
I
and
it
might
be
harder
because,
with
a
with
a
media
type,
they
kind
of
don't
care
as
much
with
the
vendor
prefix
or
the
vendor
tree.
I
I
did
so.
I
pushed
on
this
because
of
the
z
standard
thing
and
I
actually
did
get
facebook
to
register
plus
z
std
as
a
structured
suffix,
and
it
didn't
seem
to
take
that
long,
but
there's
precedent
here.
J
I
do
think
you'll
have
to
solve
this
hard
problem
of
like
well.
How
do
we
express
that
something
is
just
generically
encrypted?
What
does
that
actually
mean,
and
maybe
that's.
C
C
H
Yeah,
so
that
was
one
of
the
design
points
where
we
we
went
back
and
forth,
which
was
like
for
us
to
make
the
layer
reusable
in
a
way
that
we
can
keep
authorizing
more
people
to
use
the
layer.
For
example,
like
we
had
to
keep
certain
encryption
data
in
other
parts
of
the
registry
or
like
in
the
manifest.
H
H
Yeah,
that's
pretty
involved
and
it's
like
yeah.
The
other
alternative
was
like.
We
had
this
like
the
encrypted
zip
files
right
and
then
you
put
it
in,
but
the
issue
we
entered
the
zip
files
is
then
you
know
you
still
have
to
manage
the
key
and
then,
if
you're
on
the
app
recipients,
multiple
recipients,
then
you
have
to
use
multiple
public
keys
and
so
on.
K
The
reason
I
pulled
up
the
share,
I'm
just
trying
to
wonder
if
I'm
answering
john's
question,
not
if
we
did
say
in
this
I
was
like
I
was
just
reading
30
seconds
ago
that
we've
got
annotations
defined
on
I'm
assuming
that
later
and
so
you'll
have
an
annotation
stored
under
this
or
group
and
containers
prefix
there,
and
that
includes
what
kinds
of
ciphers
and
whatnot
they're
using.
So
that
would
make
this
somewhat
extendable,
I
believe,
is
that.
J
Slightly
different
so,
like
I
don't
have
a
problem
with
this
within
the
context
of
oci
like
this
makes
sense
to
me.
It's
that
we're
leaning
on
like
media
type
semantics,
and
so
if
we
want
to
use
media
type
semantics
to
express
like
this
is
a
thing
that
is
encrypted.
Then
we
need
to,
in
the
other
context
of
iana
register
this
suffix,
that's
like
yeah,
any
media
type
could
be
encrypted
and
I'm
I'm
suspecting
they
would
push
back
on
something
so
like
generic.
You
know,
without
without
the
context
of
what's
in
oci.
J
K
H
The
reason
why
we
didn't
do
that
was
because,
if
you
wanted
to
now
add
the
give
someone
access
to
this
image,
you
would
have
to
modify
the
blob
and
then
you
don't
get
the
deduplication
and
all
that
again
yeah.
J
H
H
Yeah,
so
so
that's
where
that's
where,
like
all
this,
all
this
trouble
came
into
right,
where
it's
just
like
now,
I
have
to
like.
I
need
this
information
and
that's
why
we
couldn't
do
like
a
generic.
H
We
wanted
to
do
this
for
the
manifest
in
the
config
files
as
well,
but
like
every
implementation,
did
it
their
own
way
where
they
did
a
bunch
of
random
stuff.
They
they
handled
a
different
way.
So
I
don't
know
whether
we
started
off
as
its
own
media
type,
and
then
we
were
like.
Oh,
let's
make
it
a
suffix
just
because
it
seems
like
naturally
like
we
want
to
incremental
stuff
as
well,
but
from
a
standards
perspective.
H
If
we
really
want
to,
I,
I
think
the
other
idea
that
we
threw
around
was
we
had
the
ina
registry
for
suffixes,
but
then
we
have
also
oci
registry
that
we
also
we
also
respect
within
the
oci
spec.
On
top
of
that,.
G
G
You
know
encrypted
like
not
a
that,
would
only
be
able
to
be
processed
if
you
already
had
this
config
in
this
setup
and
could
execute
a
certain
process.
So
I
don't
know.
H
I
mean
I'm
not
sure
whether
it's
like
we
can
have
an
addition
to
the
like
addition
to
the
registry
having
lci's
on
suffix
registry,
or
maybe
we
just
do
yeah
different
types.
J
G
J
Maybe
maybe
eci
is
an
encrypted
container
image.
I
I
think
they'll
like
if
we're
being
adults
and
doing
the
right
thing,
I
think
you
should
probably
reach
out
to
the
internet
engineering
steering
group.
Of
course,
if
you
don't
want
to
do
that,
you
can
tell
me
well
whatever
you
want,
but
that
that's
probably
where
I
would
go
if,
like
we
really
want
to
do
this
right.
G
And
I
I'd
be,
I'm
still
I'm,
I
think
it's
more
fuzzy
to
to
to
do
a
suffix
than
to
change
the
prefix
of
you
know
from
oci
to
eci.
I
don't
know
that
sounds
just
as
hard.
H
G
J
H
Yeah,
so
I
don't
know
whether
it's
going
to
be
like
if
we're
removing.
Well,
if
the
non-issue
for
the
bullet
is
it's
weird,
because
if
you're
an
anchor
by
jesus,
you
can't
like
there's
no
way
to
express
that
right.
H
K
I
H
Yeah,
but
I
think
the
thought
is
that
if
we
had
a
single
media
type
for
encrypted
layers,
for
example,
you
could
then
compress
and
then
encrypt
it.
You
would
just
encrypt
it
and
compress
it,
which
doesn't
really
quite
make
too
much
sense.
So
you
would
have
to
create
a
new
media
type,
which
was
like
dot
g,
zip,
dot,
encrypted
dot
that
yeah
or
something
like
that.
Easy
well,
yeah.
J
J
F
F
I
mean
like
the
stuff
that
we
have
in
the
like
the
cipher
type
and
the
hmac,
and
so
on.
They
put
into
the
encoding
header
so
not
suggesting
that,
like
it's
necessarily
better,
I'm
just
saying
that
if
they
already
have
a
thing.
H
H
H
H
J
I
I'm
reading
through
this.
I
see
that
they're
changing
the
media
type
to
application,
octet
stream
to
avoid
exposing
information
about
the
content
right
so
like
is,
is
the
media
type,
something
that
should
be
encrypted
or
not
be
exposed?
If
we're?
If
we
don't
want
to
leak,
the
content
is
the
content
type
included
in
that.
H
Right
now
we
say
that
oh,
it's
a
layer
just
for
ease
of
like
handling
for
for
the
runtime.
J
Yeah,
I
guess
I
would
say,
maybe
just
set
it
to
application,
octet
stream
and
you
don't
get
to
know
the
content
type
of
the
layer,
but
maybe
that's
a
terrible
idea.
H
All
the
layers
kind
of
go
through
this
like
encoding
session
coding
and
then
use
use
directly
right.
But
if,
in
this
case,
you
wanted
to
use
the
media
type
questions
like
byte
stream,
then
your
your
layer
could
have
another
field
in
the
manifest.
That's
it
whether
it's
encrypted
and
you
have
the
music.
What
is
that
right?
So
good.
J
This
is
a
terrible
idea,
so
please
tell
me
why
it
is
what,
if
we
would
could
you
put
just
like
a
descriptor
of
the
unencrypted
bit
as
like
just
the
first
set
of
bytes
and
so
like
if
you're
processing,
this
you
just
read
a
json
object
and
then
everything
after
that
is
the
encrypted
payload
so
or
everything
after
that
is
the
like
the
payload
of
the
unencrypted
thing.
J
H
H
H
The
the
issue
I
think
is
like
the
most
of
the
runtimes
use
the
media
type
as
an
indication
of
how
do
I
handle
this
and
having
like
them,
try
and
show
introspect
the
blob
and
figure
that
out.
I
feel
like
it's
a
of
your
kind
of
forms.
G
If
we
presumed
john
back
to
your
idea
that
the
that
it's
always
encrypted-
and
we
always
attempt
to
decrypt
it
right,
then
then
then
we
could
use
that
same
algorithm
to
check,
and
then
we
could
use
some
header
portion
of
the
layer
to
not
actually
be
a
layer,
but
actually
to
be
a
text
file
or
something
in
the
layer
right
it
would.
They
would
have
the
additional
piece
of
information
that
we're
looking
for
that.
Yes,
you're
right.
This
wasn't
this
was
encrypted.
So
but
I
don't
know
I'm
reaching
I'm
reaching
john
as
well.
Here.
H
G
G
I
H
K
H
I
I
think
I
think
that
will
work.
It
would
just
be
like
a
huge
pain
for
most
of
the
implementations
because
they
they're
like
layer
equals
predictor.
This
put
it
to
the
system
and
then
they
just
add
a
decoder
right.
So
in
this
case
it
will,
it
will
complicate
the
the
handling
a
lot
more.
I
I
think
we
had
this
discussion
with
entertainment,
media
types
issue
where,
like
now,
we
we
have
like
five
different
ways
to
handle
and
other
video
types.
K
Time
here
do
we
want
to
continue
this
on
into
another
meeting
or
follow
up
in
the.
F
B
B
Excuse
me,
even
if
we
did
you
know
one
we're
gonna
we're
talking
about,
can
we
deprecate
the
non-distributed
layers,
but
from
removing
it
from
the
pivot
of
encrypted?
B
What
taylor's
saying
is,
by
definition,
they're
public
there's
no
value
in
encrypting
them
at
least
the
way
we're
thinking
about
it.
So
at
least
we
remove
that
pivot.
So
I
think
we
can
separate
the
conversation
of
whether
it
should
be
a
suffix
all
the
places
it
goes
and
whether
it
needs
to
apply
to
cryptid.
But
can
we
also
maybe
start
messaging
non-distributed
is
not
a
good
thing
that
you
should
not
consider
using.
B
K
B
J
G
Thanks
everybody,
cool
cool,
so
brandon
are
you
gonna
you're
gonna
work
with
steve
a
little
bit
and
try
to
figure
out
if
what
we
can
do
with
the
ayanna
groups.