►
From YouTube: OCI Weekly Discussion - 2021-09-29
Description
Recording of the OCI weekly developer's call from 29 Sep 2021; agenda/notes here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg#September-29-2021
A
C
B
Yeah,
so
I
mean
the
the
result
of
the
oc.
Artifacts
stuff
is
just
not
applicable
to
all
things
that
are
referenceable
in
a
registry
like
it
is
a
specific
guidance
for
basically
setting
a
string
inside
an
oci
image
to
mean
something
and
that
doesn't
broadly
work
because
of
how
an
oci
image
index
works
right.
B
D
C
So
I'm
sorry
I
I
walked
out
of
the
car
in
the
rain
to
the
house,
so
I
missed
part
of
this.
So
hopefully
you
guys
can
hear
me
now.
I
think
we're
getting
caught
up
in
all
right.
I
don't
know
how
to
do
this
in
a
way
that
we
don't
wind
up
making
this
the
artifact
conversation,
and
it's
almost
like
that's
we're
gonna,
try
to
deal
with
tomorrow,
but
we're
getting
caught
up.
C
I
think,
in
my
opinion
of
how
we
had
to
implement
a
generic
way
to
reference
everything
in
a
registry
today
versus
what
we're
trying
to
accomplish,
in
other
words,
the
mechanics
of
how
we
accomplish.
This
are
one
thing,
as
opposed
to
the
concept
of
what
we've
been
working
to
enable
the
mechanics
of
using
the
media
type
was.
How
do
we
represent
this
without
making
changes.
C
E
D
Docker
is
going
to
be
pointing
to
that
95
of
things
people
pulling
today,
they're
container
images
and
so
we're
trying
to
make
this
a
little
bit
more
generic,
but
at
the
same
time
we
need
to
be
careful
that
I
don't
think
we're
making
it
more
generic
we're
making
it
specific
to
that
other
five
percent,
and
we
need
to
find
that
way.
We
create
a
solution
that
is
generic
to
everything.
C
Of
going
into
that
one
still
this,
no,
I
get
you,
but
the
concept
is
there
is
distribution,
supports
multiple
manifests.
Just
so
happens,
some
of
them
are
described
in
the
image.
Spec
there's
a
concept
of
artifacts.
We
refer
to
the
artifact
type
as
a
logical
thing
by
using
the
config
media
type
today,
how
that
gets
represented
in
manifest
new,
manifest
that
we're
proposing
or
new
manifests
that
don't
yet
exist
is
still.
Those
are
implementations
of
the
concept
that
I
can
store
different
artifacts
in
a
registry.
E
I
think
brandon
is
actually
suggesting
a
path
forward
to
unify
oci
artifacts
or
as
artifacts.
Whatever
container
images
as
like
one
thing-
and
this
is
this-
is
the
path
forward
is
just
calling
all
of
it
oci
generically,
because
in
pearl
there
is
something
called
docker
already
and
docker
is
at
least
in
the
pearl
context.
It
is
very,
very
specific,
it
is,
you
know
you
use
docker
and
docker
hub,
and
that's
all
you
use,
you
don't
use
anything
else.
D
Yeah
and
in
terms
of
that
path
forward,
because
I
know
steve's
concern-
is
I'm
working
on
those
horror
stuff.
I
want
to
make
sure
that
there
is
something
there
and
I'm
not
saying
we
don't
do
that.
You
know
keep
working
on
it,
keep
keep
making
progress
on
that
side
of
it
make
sure
there
is
a
point
that
we
can
get
to
when
that
finally
gets
pulled
into
us
yeah
assuming
it
does
where
we
can
say
okay.
D
This
is
how
this
would
be
represented
in
pearl
in
the
future,
but
as
we
define
the
pearl
today,
we
define
it
with
whatever
ci
is
today,
and
we
just
say:
okay,
here's
how
we
can
potentially
expand
this
in
the
future,
but
right
now
we're
defining
this
we're
defining
an
oci
artifact,
we're
defining
an
oci
image,
an
index,
and
we
just
work
with.
What's
in
our
ci
day
and
just
knowing
there
are
other
things
that
might
come
in
the
future,
I
I
think
again.
C
C
E
One
thing
I
will
point
out
steve
real
quick
is
that
pearl
does
not
understand
any
of
this
stuff,
so
pearl
that
right
now,
the
way
that
we've
submitted
the
proposal
is
there
is
no
indication
of
what
kind
of
thing
it
is
all
it's
saying
is
that
it's
an
artifact
and
it
has
a
digest.
That's
that's
it.
In
fact.
Currently
the
discussion
is
circling
around
well,
if
it.
E
E
C
I
guess
I'm
still
trying
to
figure
out
what
it
is
we're
disagreeing
on,
so
the
the
mechanics
of
what
we're
trying
to
achieve
is,
and
maybe
we're
just
gonna
go
back
to
this.
This
is
part
of
the
the
goal
we
have
you're.
Building
the
debian
image
you're
going
to
host
the
debian
image
on
multiple
registries.
C
C
That's
part
of
the
goal
right,
so
I
build
an
s-bomb
and
then
I
sign
them
all.
I'm
not
getting
intake
deals
which
technology
signing
with
it
doesn't
matter.
The
point
is:
is
that
you're
going
to
build
these
things,
and
we
need
an
identifier
that
says
this
s-bomb
points
to
this
debian
image,
this
very,
very
specific
one
with
the
digest.
C
We
want
to
be
able
to
say
that
this
s-bomb,
when
they
crack
it
open
and
they
see
what
is
this
s
bomb,
pointing
at
that
there's
a
piece
of
information
in
there.
That
can
absolutely
positively
no
question
about
it
say
this:
they
don't
have
to
find
the
debian
image
per
se,
because
the
assumption
is
they've
already
found
the
debian
image.
The
question
is:
when
they
do
a
double
check
to
say:
does
this
s-bomb
actually
point
to
this
debian
image?
C
There
is
debian
and
a
digest
that
can
link
and
as
long
as
those
match,
we're
in
great
shape
at
the
end
of
the
day.
That's
really
all
that
has
to
be
in
that
pearl
like
full.
Stop
the
other
information
we're
talking
about
is
the
ability
to
have
hints
some
kind
of
information.
That's
helpful
because
you
can
argue
even
the
debian
name
doesn't
help
doesn't
matter,
but
we
do
want
to
have
some
information
that
says
all
right.
C
C
First
of
all,
we've
been
arguing
whether
there
should
actually
be
a
registry
in
there,
but
that's
it.
I
want
to
be
careful
before
I
go
on
that
conversation
too
far
and
it's
it
seems
like
it
would
be
helpful
to
say
this
is
a
container
image
versus
a
helm
chart
versus
a
wasm
if
we,
because
it
just
it
seems
helpful
to
for
troubleshooting
that
I'm
looking
at
this
pearl
computer's
not
going
to
do
anything
with
the
pearl
and,
quite
frankly,
the
computer,
the
computer
code
doesn't
care
whether
it's
an
index
or
even
an
image.
C
In
fact,
I'd
argue
that
an
s-bomb
shouldn't
actually
point
to
an
index
because
it
indexes
as
deflection
to
different
architectures,
and
you
don't.
I
can't
imagine,
having
an
s
bomb
for
a
multi-architecture
platform.
It
would
eventually
point
to.
This
is
the
s-bomb
for
linux.
This
is
the
s-bomb
for
arm
and
whatever
I
think,
if
we
boil
it
down
to
those
pieces,
then
we're
we're
talking
a
little
bit
more
narrowly.
What
we're
trying
to
achieve.
D
C
Experience,
let
me
rephrase
the
curl.
Crews
are
only
interested
in
the
digest
and
the
the
repo
name,
the
other
stuff
we've
been
talking
about,
isn't
used
to
resolve
like
there.
The
fact
that
it
says
it's
a
container
image
versus
a
helm
chart
versus
a
wasm
is
irrelevant
for
the
linkage.
It's
really
a
troubleshooting
piece
of
data.
D
Yeah,
because
my
biggest
concern
and
the
thing
that
I'd
put
up
in
the
kiddish
github
issue
was
I'm
trying
to
understand
how
a
computer
could
generate
those
fields
and
parse
those
fields
if
they've
been
generated,
so
that's
kind
of
what
I
wanted
to
work
out
and
understand
with
what
we're
doing
here
before
we
said.
Okay,
let's
do
it.
I
want
to
understand
what
we're
actually
doing
so
if
it's
never
gonna
be
parsed
back
here.
Okay,
I
guess
that's
not
a
big
issue
anymore.
I.
D
A
computer
yeah,
and
so
assuming
it
is
I'm
that's
kind
of
the
biggest
thing
I
want
to
try
to
get
out
of
this
was:
how
can
I
generate
these
fields?
Is
it
just
the
string
helm?
Is
it
a
type
field
in
there
is
it?
Where
is
it
coming
from?
How
is
that
field
being
generated?
Specifically
I'm
trying
to
get
to
some
of
those
details,
and
that's
why
I
was
trying.
C
To
get
the
very
specifics
of
the
at
the
end
of
the
day,
the
way
you
definitively
know
these
things
are
linked
is
the
digest,
and
probably
the
repo
would
be
needed.
The
registry
is
a
runtime
configuration
that
gets
passed
in
that
says.
Look.
This
is
where
all
this
content
is
now
that's
great.
But
if,
when
someone
when
a
piece
of
code
is
validating,
is
this
s-bomb
really
for
this
container
image?
It's
the
manifest
digest?
That's
we're
saying
that
that's
the
definitive
linking
everything
beyond
that
is
not
code,
not
stuff.
C
You
would
use
in
code
to
do
anything
with
it's
really
a
matter
of
like
if
the
fact
that
we
want
to
say
it's
a
helm,
chart
versus
a
container
image
versus
a
wasm
is
really
just
helpful
information
to
human.
I
don't
see
how
code
would
do
anything
with
it
and
then
it's
just
a
matter
of
well.
If
we're
going
to
say
it's
a
helmet
or
wasm
or
something
else,
then
do
we
have
to
reinvent
a
short
name
for
those
or
do
we
use
the
the
I
was
where
I
referred
to
it
as
artifact
types.
D
A
A
E
Can
I
back
up
a
little
here
and
just
describe
like
what
we
are
looking
for
as
far
as
the
s-bomb
side
is
concerned,
s-bombs
want
accurate
artifact
locations
and
we
really
cannot
provide
accurate
artifact
locations
for
anything
that
is
stored
in
a
content,
addressable
storage
that
gets
pointed
to
by
a
digest
or
a
tag,
and
so
the
reason
why
we
were
looking
at
pearl
is
to
figure
out
some
pattern.
That
would
tell
us
this.
E
E
E
F
E
A
E
C
What
I'm
trying
to
distill
down
to
is
what
is
actually
needed
for
this
use
case
and
what
I'm
getting
at
is,
while
the
manifest
media
type,
whether
it's
an
oci
image
manifest
or
an
oci
image
index
or
a
docker
manifest
or
a
docker,
I
forgot
the
other.
The
docker
types
that
represent
index
are,
if
you
have
all
of
those,
actually
aren't
help.
Those
don't
add
any
value
to
what
we're
doing
here,
because
at
the
end
of
the
day,
that's
part
of
the
container
ecosystem.
The
container
ecosystem
knows
how
to
resolve
manifests.
C
At
the
end
of
the
day,
all
we're
trying
to
find
is
the
unique
identifier
which,
where
the
more
we
dig
into
this
with
the
pearl
community,
this
is
what's
nice
about
the
distribution
is
it
does
have
a
unique
identifier
that
does
have.
I
think
somebody
did
some
confidence.
They
couldn't
find
any
hits
on
any
of
the
digest
collisions.
C
So
it
by
design
has
a
unique
identifier
if
we
can't
agree
on
anything
else
and
if
we
don't
agree
on
artifact
type,
if
we
don't
agree
on
what
the
the
url
location
is
it
doesn't
we
still
get
a
win
at
the
end
of
the
day.
As
long
as
the
pearl
says,
this
thing
oci
star,
I'm
going
to
leave
that
out
for
a
second
and
debian
at
you
know,
shot
256
for
today
shot
5
12
tomorrow,
colon
you
know
long
digit,
not
human,
expected
to
remember.
C
E
A
E
Is
it
it
is,
but
I
mean
the
reason
that
we're
making
an
oci
ish
star
pearl
or
whatever
is
the
assumption
that
pearl
will
allow
for
something
as
genetic
as
oci.
If
pearl
does
not
allow
something
as
genetic
as
oci,
then
you
know
I
I
think
it.
I
think
we
still
have
the
opportunity
to
find
another
scheme
to
identify
these
things.
C
C
That's
problematic,
but
that's
really
for
the
spdx
and
cyclone
dx
community
to
decide
we're
just
saying:
look
if
somebody's
going
to
use
perl,
which
we
kind
of
liked
the
idea
that
here's,
how
you
could
uniquely
identify
things
that
are
in
registries
by
the
way
things
are
in
registries,
are
uniquely
identifiable
like
this
is
the
thing
that
we've
been
watching
in
the
pro
conversation
is
they're
somewhat
justifying
location,
because
the
only
way
they
can
get
a
unique
value
for
the
thing
and
that's
broken
like
they
need
to
solve
that.
But
that's
not
really.
Our
charter.
E
E
But
pearl
assumes
that
when
you
have
something
you
have
like
a
fool,
what
they
assume
is
that
full
points
to
some
unique
closed,
specific
ecosystem.
So
it's
almost
like.
So
it's
almost
like.
If
you
know
you
were
to
distribute
wasm
packages
using
oci
using
the
oci
stuff
and
registries,
and
all
that
as
implementations,
then
wasm
can
be
a
line.
C
C
You
don't
have
to
build
yet
another
storage
service
for
your
thing
and
you
don't
need
to
create
yet
another
wasm
for
your
sorry,
you
had
another
pearl
for
your
thing
if
you've
defined
a
wasm
and
if
you
define
an
artifact
type,
which
is
defined
in
the
usa,
images
implement
implemented
as
a
config
manifest
manifest
config
media
type
just
use
that
same
string
like
you,
don't
even
need
to
rethink
it.
All.
That's
really.
C
What
I'm
trying
to
find
a
path
here
is
saying:
look
if
we're
really
going
to
argue
an
argument,
debate
to
the
point
where
it's
just
not
constructive,
on
the
artifact
type.
Being
a
property
in
it,
it's
actually
not
needed.
I
think
it's
unfortunate
that
we
don't
put
it
in
there,
but
you
don't
need
it.
It's
literally,
if
you
want
a
unique
identifier,
the
awesome
thing
about
registries
is
the
manifest
digest.
Is
that
thing.
D
D
C
B
I
disagree,
I
mean,
like
the
tob,
approved,
the
proposal
for
oca
artifacts
but
like
as
as
implemented
and
as
I
know
it's
an
implementation
detail,
but
I
think
first,
if
you're
going
to
use
this
in
a
spec
like
perl.
I
think
it's
important
to
get
the
details
correct.
The
current
iteration
of
oc
artifacts
cannot
satisfy
the
charter.
It
is
just
impossible
and
I
like
I,
don't
think
that
the
t.o.b
has
signed
off
on.
Like
yes,
artifacts
achieved
its
goals.
I
I
disagree
with
that
impression.
C
Your
point
is
noted:
it's
been
consistent,
but
that
is
there.
There
is
there
more
to
be
done
sure,
but
I
actually
don't
understand
the
point
of
this
this
campaign
to
to
not
call
anything
artifacts
when
it's
a
project
that
is
approved,
we're
continuing.
You
know
we're
looking
to
make
more
progress
on
it.
I
don't
know
why
we
continue
to
have
this
debate
of.
Why
should
we
not
use
a
term
that
we
did
to
find
it
didn't
get
merged?
It
did
get
approved.
C
C
C
E
Okay,
so
now
it's
it's
going
beyond.
You
know
the
what
we
started
talking
about,
which
was:
how
do
we
identify
these
things
so,
like
I
said,
at
least
at
the
poor
level,
they
expect
a
mature
ecosystem
and
oci
in
general
does
not
whatever
it
is.
Artifacts
or
anything
does
not
represent
a
mature
ecosystem
or
a
mature
implementation.
E
Yeah
no
you're,
just
talking
about
registry
you're,
not
talking
about
some.
You
know
implementation
like,
for
example,
docker
that
has
all
of
the
infrastructure
ready
to
circulate
a
certain
kind
of
package
that
folks
are
using
right
now.
So
docker
has
all
of
that.
There's
a
cli
that
understands
a
certain
type
of
package.
E
C
And
there's
a
health
cli
there's
a
wasm
cli,
there's
a
singularity
in
the
line.
They
all
store
things
in
container
registries
using
those
ci
artifacts
to
be
able
to
define
what
those
types
are
yep
every
registry
supports
it.
Docker
hub
has
some
work,
that's
still
up
finishing
up,
but
there's
a
long
list
of
every
other
registry
that
does
yes.
E
E
E
C
I
think
we
really
missed
the
whole
point
by
doing
that,
the
whole
point
is
somebody
doesn't
have
to
go
into
the
pearl
spec
and
create
their
own.
The
whole
idea
is
what
we've
seen
in
those
pro
conversations
is
many
of
these
other
package
types.
Don't
have
the
infrastructure
that
we
have
with
distribution
so
by
creating
and
standardizing
on
a
common
way
of
doing
it.
I
don't
really
care
whether
it
says
oci
dash,
artifact
or
not.
C
C
If
they
want
to
use
helm
for
a
chart
museum,
they
could
use
the
separate
helm
entry.
If
they
want
to
leverage.
What's
the
registry
implementations,
then
they
can
say
oci
I'd
like
to
have
a
helm
in
there
somewhere.
If
we
can't
agree
on
that
because
for
some
reason
we
don't
want
to
agree
on
the
word
artifact,
then
that's
not
really
the
most
important
thing.
E
C
No,
that's
fair.
There
was
another
example.
I
came
a
camera
who
was
npm
or
debian
rose.
I
don't
know
if
you
remember,
there
was
another
one
that
had
a
similar
model
where
you
can
store
different
types
in
the
same
service,
but
the
reality
is
s3
is
not
robust
enough
to
be
one
of
these
type
of
servers.
It's
a
it's
a
very
important,
critical
underpinning,
but
that's
why
we
have
registries
and
package
managers
that
are
sit.
Atop,
storage,
storage,
apis.
C
G
So
I
wanted
to
kind
of
like
be
back
on
what
canon
was
saying:
docker
manifests
or
docker
images
are,
are
referenced
as
backward
compatibility
in
oci
or
as
a
subset
in
some
way
do
are
you
planning
to
collapse
this?
Because,
if
you
say
it's,
oci
docker
images
are
at
least
the
doctor.
Manifest
is
not
supposed
to
be
an
oci
now
how?
How
do
you
think
about
it
from
the
pulp
side?
Where
do
you
want
it
to
be.
E
D
I
think
what
sanjay
is
getting
at
is:
we've
got
the
docker
manifest
type
for
the
schema,
2
version,
potentially
other
ones.
We've
got
the
oci
manifest
type
both
of
those
can
refer
to
images
that
docker
can
run
or
any
other
container
runtime
can
run
they're
very
interrelated.
Do
we
keep
them
separate,
or
do
we
try
to
push
everybody
over
to
the
oci
image,
even
though
they
are
probably
talking
about
a
docker
image.
E
A
D
E
C
I
don't
know
if
they
really
care,
as
opposed
to
there
is
an
entry
there.
I
think
it's
a
matter
of
what
what
direct
people
forward,
because
the
docker
one
is
problematic,
because
the
location
location
as
well.
So
I
think
the
idea
is
that
we
can
give
a
better
answer
so
that
customers
start
to
get
location
independence
for
our
identity.
A
E
Want
to
say
that
there's
another,
maybe
some
way
that
you
can
tweak
this
explanation
rather
than
call
it
a
package
type
think
about
it
as
a
transport
type,
and
it
doesn't
it
it
doesn't
matter
if,
in
all
of
these
cases,
docker
included,
it
doesn't
matter
what
the
package
type
is.
The
transport
type
seems
to
always
adhere
to
oci's
specification,
and
that
might
be
another
way
of
thinking
about.
A
This
okay,
so
this
I
feel,
like
the
proposals,
kind
of
took
a
turn.
So
are
we
thinking
now
that
we
want
to
have
oci
dash
image
as
a
separate
entry
from
oci,
wasm
oci
dash,
I
mean
and
and
if
that
is
the
proposal
then
like
what
do
we
do
about
things
like
signatures
because
there's
not
oci-signature
like
what
is
that
type
of
I
mean
what
do
we
do
for
these
things
that
are
distributed,
that
can
be
stored
in
registries,
but
don't
have
like
a
specific
ecosystem
or
a
cli
tool
or
package
manager.
C
I
actually
don't
think
it
needs
a
problem.
I
think,
if
you
look
at
what
perl
is
trying
to
to
do
is
like
well,
I
think
it's
not
so
much
what
pearl's
trying
to
do,
but
how
we're
trying
to
use
it
in
the
s-bomb
case.
So
I
wouldn't
have
an
s-bomb
on
a
on
a
signature.
I
wouldn't
have
an
s-bomb
on,
probably
wouldn't.
Couldn't
you
put
a
signature
in
an
s-bomb?
C
I
would
put
a
signature
on
an
s-bomb.
Yes,
so
that's
how
I
know
that
somebody
didn't
tamper
with
the
s-bomb,
but
the
the
point.
If
we're
taking
it
from
the
point
of
the
s-bomb,
the
s-bombs
don't
know,
they're
signed
the
s-bombs
know
they're
pointing
at
things
the
s-bombs
point
to
container
images.
They
point
at
helm,
charts
they
point
at
wasms.
C
They
could
theory
point
to
another
s-bomb,
because
s-bombs
could
hang
off
other
s-bombs,
but
things
that
hang
off
those
signatures.
Skin
results
are
like.
Actually,
I
would
say
a
scan
result
is
another
way
to
use
a
pearl
too,
because
a
skin
result
should
say
well.
What
does
this
scan
if
I'm
putting
a
scan
result
in
a
registry
which
is
one
of
the
scenarios,
then
what
is
the
unique
identifier
inside
of
it?
So
it'd
be
nice
if
pearl
can
separate
location
from
identity
that
we
could
use
pearl
for
that
as
well.
C
F
So
I've
been
re-reading
through
that
other
thread
on
pearl
of
reasons
for
github
bitbucket
generic
types
and
it
so
I
think,
focusing
on
wasm
is
interesting,
but
maybe
less
useful
today
than
focusing
on
something
that
already
exists
in
pearl
like,
for
example,
debian
packages.
Inevitably,
someone
is
going
to
store
debian
packages
in
an
oci
repository.
In
fact,
akihiro
already
has-
and
that's
really
clever
and
interesting,
and
I
would
love
to
see
more
of
that.
F
I
think
the
pearl
community
would
prefer
to
see
that
underneath
the
deb
package
type
somehow
with
some
way
to
specify
that
it
comes
from
an
oci
repository,
because
the
oci
repository
is
not
the
package
type.
It's
the
storage
location,
it's
where
it
where
it's
at.
It's
that's
why
I
was
trying
to
make
the
corollary
earlier
to
s3,
because
s3
web
dav
http
are
all
transport
mechanisms,
not
package
types
and
oci
is
more
similar
to
those
than
it
is
to
a
debian
package.
C
No,
it
makes
perfect
sense,
and
you
know
we're
also
converging
debian
on
the
ocs
stuff
as
well.
The
I
think
the
what
you're
making
is
a
good
point.
What's
interesting,
though,
is
the
way
it
where
the
location
conversation
comes
in.
So
while
you
could
say
that
yeah
I
should
just
go
under
the
deb.
The
idea
is
the
way
you
find
things
when
you
would
put
in
a
location
to
debian.
C
C
What
I
would
think
is
those
are
like
the
darker
ones,
overloaded,
because
we
are
talking
about
supersetting
that
the
deb
one
would
be
if
you're
looking
at
deb
in
a
typical
debian
package
manager,
then
use
the
dev
if
you're
using
for
debian
that
now
you
can
benefit
from
you
know.
The
the
oci
protocol
then
use
this
perl
to
reference
it.
Maybe
that's
not
the
best
way
to
do
it,
because
what
we're
trying
to
say
is
look,
you
got
a
debian
package.
It
doesn't
really
matter
whether
you've
got
a
debian
package
manager
or
via
oci.
C
D
So
what
I'm
trying
to
understand
on
the
location
is,
do
you
need
to
know
where
you
can
go,
get
it
and
pull
it
yourself,
or
are
you
just
trying
to
uniquely
identify
it?
So
you
can
disambiguate
it
from
other
installs,
and
you
know
know
that
it
has
been
installed
there,
because
if
you
don't
need
to
know
where
you
can
go,
get
it
that
kind
of
removes
a
lot
of
the
concerns
on
locations
and
specifying
that
location
is
an
oci
versus
the
debian
repo
or
something
like
that.
C
E
D
So
is
it
a
problem
if
the
locations
are
different
so,
like
two
different
organizations
will
say
I
got
this
from
my
loan
internal
repo
and
the
other
organization
says
I
got
it
from
docker
hub.
Are
we
deduping
on
that
field,
or
are
we
going
to
keep
the
d2
being
strictly
on
that
digest,
and
does
it
really
matter.
A
A
E
A
So
we
are
the
top
of
the
hour,
so
I
will
say
I
am
slightly
more
confused
about
where
we
want
to
go
with
this
than
I
was
when
the
call
started
so
are
do.
Are
we
thinking
that
we
want
to
like
scrap
this
and
propose
oci
image
or,
and
let
other
people
enter
their
stuff
or
are
we
thinking
that
we
can
get
to
an
agreement
around
oci,
because
I
I
do
see
the
I
mean?
A
I
don't
think
that
is
necessarily
something
that
will
be
implemented,
especially
if
they're
not
involved
in
these
s-bomb
communities
like
spx
or
cyclone
dx,
where
they're
using
pearl
to
reference
it
they're
gonna
like
if
they're
working
with
the
tool,
they're
gonna,
say:
okay,
I
wanna
reference
this
helm
chart
and
there's
no
way
to
do
it
with
pearls.
So
I
guess
I
just
won't
create
a
pearl
if
you
are
a
uri
for
it.
That
is
how
I
see
it
happening.
We.
D
A
D
A
C
Unique
identifier
for
it-
and
I
don't
know
how
you
would
do
that
in
some
of
the
places
they're
storing
it
today
so,
but
I
do
struggle
with
this.
The
intent
here
was
never
to
replace
what
already
exists.
The
intent
was
hey
you're,
benefiting
from
the
the
artifacts
approaching
registry,
so
you
don't
have
to
do
all
this
infrastructure.
C
You
don't.
The
only
thing
you
have
to
do
is
go
register
your
unique
guy
on
a
media
type,
but
once
you've
done
that
party
on
everything
else
is
done
for
you.
This
was
one
of
those
examples.
I
was
hoping
that
they
didn't
have
to
go
chase
down
and
register
a
pearl
for
it
as
well.
They
could
just
take
the
oci
entry
put
their
repo
and
digest.
C
I
was
hoping
that
you'd
have
artifact
type
equals
exactly
what
they
said
for
the
iana
registration
in
there.
So
again
it's
super
simple:
they
don't
need
a
register,
they
just
stick
it
in
any
actually
whoever's
generating
an
s-bomb.
The
guidance
would
be
hey
if
you're
generating
an
s-bomb
for
this
artifact
type.
Then
here's
the
iana
registered
media
type
that
you
should
use
party
on.
No,
nobody
has
to
do
any
other
spec
prs
communications
like
all
the
baseline
was
done
for
them.
D
I
think
rose
to
quickly
answer
your
question.
I
think
the
common
thing
that
most
of
us
agree
on
is
oci
image
right
now,
and
maybe
we
can
iterate
on
that
later
on
to
add
more
stuff,
but
that
would
at
least
give
us
the
thing
that
a
lot
of
us
are
all
in
agreement.
That's
the
bare
minimum
that
we
all
like
is
oci
image.
Only
representing
a
container
computer.