►
From YouTube: OCI Weekly Discussion - 2023-03-09
B
B
B
B
So
James
the
reason
I
do
that
done
a
few
times
before
we've
got
a
few
people
from
the
runtime
spec
here,
but
I
think
a
lot
of
what
happens
on
their
side.
They
they
do
a
lot
more
over
on
the
GitHub,
getting
issues
and
pull
requests,
I'm
kind
of
surprised.
How
long
has
that
been
open?
C
Yeah
yeah
just
opened
it
yesterday
and
someone
from
my
team
said:
there's
a
meeting
today,
so
I
thought
bring.
B
It
up
yeah
that
doesn't
hurt
to
chime
in
we.
We
appreciate
everybody
who
wants
to
stop
by
and
visit
I
suspect
I,
don't
want
to
put
words
into
the
runtime
spec
maintainer's
Mouse,
so
they
they
should
go
ahead
and
chime
in
now.
But
my
guess
is
that
opening
up
a
pull
request
over,
there
will
probably
be
a
good
good
Way
Forward
on
that
one.
D
B
B
Runtime
spec
issue,
1185
James,
has
on
our
agenda
to
talk
about
an
issue
with
the
layout
folder
when
it's
on
Windows.
C
If
you
create
a
new
object,
it
serializes
this
at
all
and
then,
when
it
re-serializes
it
comes
back
and
so,
but
when
I
was
doing
it
in
Rust
it
it
caught
it
because
the
rust
oci
spec
has
a
check
to
make
sure
that
there's
at
least
a
list
there
and
not
null.
B
B
Get
a
little
bit
more
yeah
that
that
would
probably
be
the
next
piece
on
this,
but
like
I
say,
since
you
only
opened
it
yesterday,
they
tend
to
be
pretty
active
over
on
their
GitHub
repo.
That
was
their
way
of
going
back
and
forth.
So
that's
why
I
like
to
pull
these
requests
early
just
to
get
them
before
before
you
sit
through
an
hour
of
us
going
back
and
forth
on
the
same
thing
we
go
back
and
forth
on
every
week.
I
was
like:
let's,
let's
get
you
an
answer
to
this.
F
B
All
right
next
up
on
here,
trying
to
figure
out
from
this
things
have
been
moving
around
on
the
list.
Here
is
the
containerdy
security
issue,
something
under
errands,
or
is
that
something
different?
This.
G
This
was
just
a
small
thing:
I
wanted
to
bring
up
before
we
got
into
the
main
event,
which
was
like
container
D.
Had
this
issue
where
very
large
config
blobs
could
cause
a
denial
of
service,
and
that
seemed
like
the
kind
of
thing
that
oci
could
specify
is
not
expected,
or
maybe
we
can't
say
that
they
should
never
be
over
a
certain
size,
but
we
can
say
clients,
May,
reject
them.
Registries
May
reject
them.
Etc.
We've
we've
done
this
in
the
past
with
manifests,
it
doesn't
have
to
be
a
big
topic.
G
B
G
Configs,
so
containerdy
will
also
pull
the
config
and
you
know
because
it
needs
to
and
explode
when
it's
you
know
a
thousand
gigabytes
or
something
so.
B
E
G
Let
me
before
before
it
gets
too
funny.
The
specific
change
I
would
request
is
if
the
artifact
type,
if
the
config
media
type,
is
oci
config,
which
specifies
that
this
is
an
image
and
not
a
random
artifact,
then
the
config
blob
must
should
we
can
argue
about.
It
should
be
less
than
some
size.
G
We
can
argue
about
that
too.
This
does
not
affect
artifacts
uppercase
or
lowercase
artifacts.
If
you
Define
your
own
artifact
type
of
cat
pictures,
you
are
welcome
to
stuff
terabytes
of
cat
pictures
into
your
config
or
into
the
layers
or
anywhere
you
want.
E
E
You
mentioned
Brandon
you're
concerned
about
air
gapped
and
regulated
environments
where
updates
occur
very
slowly.
Well,
if
we
go
forward,
go
ahead
with
this,
using
a
approach
of
injecting
artifacts
into
image
manifests
you're,
going
to
have
Legacy
container
D
clients
that
do
not
support.
Do
not
know
to
do
this
special
casing
Logic,
for
if
the
config
media
type
is
this,
then
the
size
to
be
this
or
that
that's
just
not
going
to
exist
in
your
air
gapped
environment.
E
H
G
For
the
record,
that's
more
or
less
the
language
we
have
for
manifest
image
sizes,
which
is
you
know,
write
a
registry
can
accept
whatever
a
registry
expects
or
accepts
and
a
client
can
produce
whatever
it
produces,
but
we
wanted
to
have
some
general
guideline
for
what
is
a
reasonable
thing
to
be
expected
to
be
portable
right,
I'm,
fine,
also
not
specifying
for
the
record.
I
really
didn't
think
this
would
be
this
much
of
a
topic.
G
I'm
fine,
just
saying,
like
you
know,
container
day
fix
container
D.
Future
runtimes
will
fix
future
runtimes
issues.
If
this
is
an
issue,
you
know
that's
on
you,
I'm
also
fine,
totally
just
leaving
it
as
a
thing.
I
just
thought
it
was
interesting,
given
our
previous
discussions
about
manifest
size
limits.
B
I
think
it
helps
portability
for
images
if
the
image
producer
knows
that
they
shouldn't
put
5000
labels
on
an
image
and
try
to
ship
that
off
and
load
that
onto
a
container
D
that
will
eventually
refuse
it
and
so
having
it
in
the
spec
that
says,
here's
a
limit
that
run
times
are
probably
going
to
enforce
on
you.
If
you
try
to
do
it,
that's
helpful
to
me
and.
H
G
In
any
case,
my
general
idea
was
containerdy
has
set
this
set
of
limits
on
their
own.
Potentially
we
should
give
a
suggestion
it
may
it
can.
It
would
be
super
nice
if
you
could
to
have
everybody
align
on
this,
but
if
that's
controversial
at
all
I
will
retract.
G
A
G
Want
to
detract
more
from
the
main
event
I'm
going
to
go
off
and
do
write
a
PR
for
this,
and
we
can
argue
there
about
that
and
then
I
will
we'll
argue
about
it
for
a
few
weeks
and
then
I'll
close
it.
Let's
get
back
to
the
good
stuff,
yeah.
G
A
H
A
That
limit
is
a
containerdy
or
client-side
limit.
I
think
having
input
from
the
continuity
maintainers
would
be
the
best
way
to
get
this
ironed
out
right,
and
it's
only
for
the
config
Json.
It
doesn't
matter
about
the
blob
or
anything
like
that,
and
it's
clearly
a
client-side
implementation.
More
than
anything
else
right.
G
Yeah
I
guess,
unlike
manifest
it's
more
like
the
config,
is
totally
opaque.
The
registry
doesn't
care
about.
What's
in
the
config,
unlike
manifests
where
the
registry
does
need
to
like
have
a
agreement
about
the
general
size,
I
think,
the
more
and
more
we
talk
about
this,
the
less
I'm
convinced
we
needed
a
change
at
all
and
which
is
great,
which
is
the
exactly
the
the
direction
things
should
go
thanks.
Everyone.
E
I,
looked
at
the
history
of
cdes,
filed
against
container
runtimes,
Registries
and
clients,
and
even
in
the
relatively
short
time
frame
that
oci
1.0
has
been
standardized.
There's
been
a
few
type
confusion
vulnerabilities,
one
which
resulted
in
an
rce
one
resulted
in
a
crash,
and
the
doctor,
client
and
I
think
that,
while
it
is,
it
is
possible
to
standardize
the
sort
of
fallback
for
artifacts
I.
Just
think
that
we
are
we're
going
down
a
path
that
will
result
in
CDs
being
discovered
in
client-side,
tooling.
E
That
will
be
found
for
years
after
this
is.
There
are
a
large
number
of
clients
that
Zoom
image
manifests,
contain
image,
configs
and
image
layers,
and
it
is
a.
It
is
definitely
a
fair
point
that
those
assumptions
should
not
be.
You
know,
clients
should
validate
before
they
parsed
and
they
should
not.
E
They
should
not
use
memory
unsafe,
parsers,
and
things
like
this
like
this-
is
you
know,
sort
of
Standard
Security
practice,
but
standardizing
using
image
manifest
for
artifacts
just
blows
the
the
doors
wide
open
in
terms
of
the
varieties
of
new
arbitrary
content
that
clients
that
were
written
prior
to
this
standardization
will
have
to
handle
and
to
the
points
that
Brandon
has
raised
and
others
is.
We
have
clients
that
might
not
be
updated
for
years
we
might
have
regulated
environments,
air
gapped
environments
and
so
off
so
on.
E
So
that
is
my
concern.
It's
the
last
sort
of
objection
that
I'm
going
to
raise
to
this.
This
approach
and
I'll
leave
it
to
the
floor
and
the
the
voting
maintainers.
A
A
It's
indirectly,
like
a
kind
of
a
covered
Brandon
said,
which
is
it's
it's
hurting
others
and
how
we
can
make
progress.
A
lot
of
people
are
depending
on
some
aspects
and
to
me
we
had
an
implementation
in
Docker
Hub
that
worked
and
then
now
they
even
yanked
out
the
capability
to
push
in
subjects.
So
it's
it's
a
step
back,
I
think
that's
what
I'm
more
concerned
about.
So
how
can
we
get
out
of
this
and
agree
on
something?
A
But
we
can
do
this
when
people
who
actually
had
the
most
comments
on
the
issue
are
not
here.
Last
week
we
couldn't
kind
of
get
an
insight
into
999.
Winston
made
a
few
comments
as
well,
and
this
week.
Also,
we
can't
so
is,
is
what
how
do
we
want
to
proceed?
Is
John
or
Vincent
able
to
join
the
call
Jason.
G
I'd
love
to
hear
from
other
image
back
maintainers
that
have
not
had
any
input
at
all
right
there.
There
are
a
number
of
image
deck
maintainers.
This
is
the
constant
issue
in
oci.
Is
that
you
know
we
we
three
or
four
of
us
always
argue
about
a
tiny
thing,
and
then
we
need
you
know
the
adults
to
come
step
in
and
actually
vote
on,
which
of
us
has
made
the
better
argument.
I'd
like
to
I'd
like
to
just
try
to
do
that
now.
G
If
we
could
get
I,
don't
know
how
to
get
their
attention.
I,
don't
know
what
what
to
do
to
get
them
to
care
about
image
spec
that
they're
a
maintainer
for,
but
it
would
be
excellent
to
have
their
their
feedback
and
input,
otherwise
we're
going
to
keep
arguing
and
then
we're
going
to
come
up
with
our
like
we,
you
know
the
the
five
of
us
agree
and
then
image,
spec
maintainers
are
going
to
show
up
and
say:
oh,
but
we
disagree
and
now
we're
back
to
like
square
one.
Sorry
go
ahead,
Mike.
H
Yeah
so
two
two
things
here
right:
one:
we
ran
into
this
problem
years
back
for
this
call
that
we
would
try
to
make
decisions
here,
right
and
and
that
didn't
work
very
well,
because
as
you're
saying
right,
we
we
couldn't
get
the
right
people
on
this
call
every
week,
so
I
I
think.
From
that
perspective,
the
the
idea
of
the
work
group
came
along
for
a
very
good
reason
right.
H
G
I
think
I
think
the
the
I
think
reopening
the
work
group
I'm
making
airports,
but
you
can't
see
them
reopening
the
the
work
group
is
sort
of
a
formality.
The
the
contents
of
the
work
group
are
the
four
or
five
or
six
of
us
that
are
already
here,
arguing
about
it.
So
if
image
spec
maintainers
need
the
work
group
to
be
officially
unsealed
and
resumed,
then
that
would
be
a
step
we
should
take,
but
I'd
rather
avoid
it.
I
can
is.
Does
somebody
especially.
G
H
G
Oci
precedent
for
getting
that
call
like
do
we
have
a
bet
signal.
Do
we
have
an
oci
signal
for
coming,
come
and
approve
a
PR?
Please
image,
spec
maintainers
I'll.
G
H
Separate
the
call
out
into
two
parts
right
with
the
second
half
being
a
focus
discussion
and
then
make
sure
we
get
the
invites
in
email,
and
you
know
slack
slack
it
out
make
sure
they
come
right.
If
they
don't,
we
got
to
go
talk
to
them
right
to
make
sure
we
get
all
the
right
input.
The
things
that
Aaron
is
mentioning
are
are
correct.
H
Right,
I'd
like
to
point
out
to
them,
though,
that
we're
already
using
it
for
those
other
purposes,
so
we're
already
actually
seeing
some
of
those
kinds
of
security
issues
coming
up,
for
example
the
cve
that
was
pointed
at
the
top
right.
So
we
we
do
need
to
think
about
it.
Consider
the
the
security
issues,
maybe
slow
down
just
a
little
bit
just
to
beat
on
it
right
and
review
it
from
the
deep
view
of
would
changing
the
work
group's
output
right.
C
G
There's
nothing
left
to
discuss
like
like
you
know
what
what
are
we
here
for?
What
do
we
all
come
here
to
talk
about
if
it's
just
the
same
thing
and
then
image
spec
maintainers,
don't
do
anything,
maybe
maybe
you're
totally
right,
I
hear
what
you're
saying
we
should
go
bug
them
to
actually
take
a
look
and
see.
H
Yeah
I'm
not
saying
we
shouldn't
discuss
things
I'm,
just
saying,
don't
expect
the
vote
to
happen
here,
because
if
it
does
it's
an
isolated
boat
with
a
limited
scope
of
people
right
that
that
was
the
only
part
that
we
tried
to
stay
away
from.
It's
perfectly
fine
to
discuss
issues
and
try
to
you
know,
drill
down
on
some
of
the
PRS
pull
them
down
and
to
expose
others
right
on
a
weekly
basis
to
what's
going
on
I'm.
Not
saying
don't
do
that
just.
G
The
work
group
has
the
same
problem
right.
The
work
group
met
for
months
and
came
to
a
conclusion
that
we
edited
that
we
modified,
but
then
even
if
we
had
all
agreed
on
that
day
to
that
thing,
we
would
have
had
to
spend
weeks
months,
who
knows
wrangling,
image,
spec,
maintainers,
yeah,
so
I'll,
I'm,
gonna.
B
H
E
I
think,
unfortunately,
we're
right
to
propose
sort
of
an
answer
to
this
type.
Confusion
issue,
the
the
nature
of
that
answer.
The
nature
of
that
proposal
would
be
to
restrict
the
artifacts
to
a
a
well-defined
set
and
I
think
that's
yeah
I
think
that
goes
against
the
charter
of
the
the
the
the
organization
right
is
not
to
act
as
a
gatekeeper.
I
think
is
the
language
I
saw
elsewhere.
H
Yeah,
we
don't
want
to
restrict
the
the
set,
but
we
we
did
have
the
the
concept.
The
thought
right
that
we
would
at
least
look
at
the
ones
that
are
being
proposed
and
used
review
them.
Make
sure
that
they're
not
that
they've
got
these
kinds
of
limits
right
that
they're,
not
just
exposing
some
random
format.
That
can
be.
You
know,
taken
advantage
of
by
the
client,
see
or
or
on
the
registry.
D
Worries
Mike
no
worries
Mike
have
we
can
we
say
right
now
that
we've
had
a
concerted
effort
to
solicit
the
image,
spec
maintainers
and
actually
bring
them
to
the
floor,
because
they'll
be
willing
to
go.
Do
that
I?
Think
just
it.
You
know
in
previous
experiences,
especially
with
the
image
spec.
It
was
a
very
directed,
concerted
effort
where
we
had
to
reach
out
and
and
and
actually
go
and
get
each
of
the
maintainers
and
say.
Okay,
we
feel
like
we've
had
a
bunch
of
conversation.
Can
you
come
and
help
us
make
this
decision?
D
I
know
there
was
something
that
Josh
put
on
the
mailing
list,
but
I've
also
seen
them
kind
of
just
it.
In
my
experience
with
image,
spec
maintainers,
specifically,
it
was
a
very
directed
set
of
questions
that
either
we'd
have
to
call
a
meeting
or
say
we
need
you
to
look
at
this
right
now.
I,
just
I,
I
can't
say
right
now
that
I
feel
like
we've,
had
a
directed
effort
and
I'd
be
willing
to
go.
Do
that
I
don't
know
again,
it
came
back
to
how
Jason
said.
G
I
three
weeks
ago
on
issue
999
I
added
image,
spec
maintainers,
which
I
believe
it
emails
them
or
GitHub,
notifies
them
in
some
way
and
we've
gotten
nothing.
No
new,
no
new
feedback
from
them
in
three
weeks,
I
think
yeah
to
your
point
about
making
it
as
clear
and
direct
a
question
as
possible.
If
I
was
if
I
was
a
LAX
image,
spec
maintainer
from
six
years
ago,
and
someone
told
me
to
read
issue
999
with
no
context,
I
would
rightfully
not
do
that.
G
I
would
I
would
ask
for
you
know
what
is
the
question?
Yes,
no,
what?
What
is
the?
What
is
the
question
I
can
answer
as
easily
as
possible
to
that
effect?
Can
we
merge
999
and
whatever
other
ancillary
related
changes
we
have
with
the
image
effect
maintainers,
we
have
on
board
and
then
the
question
we
have
for
image
deck
maintainers
is:
do
you
approve
of
the
release
as
currently
at
head?
Like
we,
you
know.
G
Now
we
have
a
spec
at
head
that
you
can
read
and
diff
since
1.0,
and
that
change
is
a
little
bit
easier
to
to
ingest
than
all
the
discussion
on
all
of
the
issues
that
link
to
20
other
issues.
That
way
it's
here
is
the
thing
we
are
asking
you
to
approve.
You
approve
or
don't
I
think
that
process
will
still
take
a
month,
but
at
least
it's
only
a
month
and
it's
a
clear
up
and
down
question
as
opposed
to
weigh
in
on
our
arguments.
H
No
because
well
I
would
ask,
did
Stephen
day
take
a
look
at
the
or
Alexa.
It's
all
right.
G
B
Or
maybe
before
we
start
pulling
in
other
maintainers
for
a
vote
on
this
and
and
engaging
them
to
read
through
a
100
comment
thread
I
think
it's
safe
to
say
that
there's
enough
dissension
in
there
that
we
wouldn't
be
able
to
get
another
release
candidate
out
the
door
or
a
release
out
the
door
with
artifact
in
there
and
so
I
I
thought
we
had
agreed
last
week
that
909
would
eventually
go
once
we
finished
up
some
of
the
other
changes
we
were
looking
at
in
image,
spec
and
so
I've
got
those
listed
on
this
next
bullet
point
in
the
discussion
here.
E
And
then,
as
a
way
to
unblock,
we
address
those
ancillary
issues
and
look
into
what
we
need
to
do
to
make
sure
artifact
is
a
viable
Baseline
lowercase,
a
artifact
merged
999.
It
does
have
approval,
I,
think
in
order
to
merge
or
maybe
I,
don't
know
what
what
the
rules
are
with
the
GitHub
pull
request
but
merge
999
and
if
it
works
better
for
the
maintainers
I
am
fine
writing
a
pull
request,
essentially
reverting
999
and
making
this
case
and
just
having
the
maintainers
review.
E
You
know,
I
think
it's
likely
the
case
that
the
consensus
is
against
artifact
manifest,
but
I
also
think
that
moving
forward
with
1.1,
with
no
definition
for
artifacts
at
all
of
any
sort
will
will
hurt
end
users,
so
I
want
to
make
sure
that
we
do
that.
B
What
I've
seen
is
there
is
consensus
amongst
a
fair
number
maintainers
that
we
can
work
on
artifact
manifest
it's
just
going
to
be
something
that's
done
with
more
than
what's
in
there
right
now.
They
they
don't
want
to
see
it
just
limited
to
what
it
currently
is,
so
it
would
be
a
change
to
what's
there
and
that
there
is
an
acceptance
that
effect
could
happen
inside
of
a
branch,
so
I've
seen
that
so
far
and
I
think
we've
got
enough
consensus
there
to
move
forward
with
that
doesn't
mean
it's
going
to
merge
in
tomorrow.
B
B
B
Only
my
changes
in
a
1023
and
I
was
fine.
Either
way.
I
haven't
seen
anything
from
vbat
and
a
little
bit
on
this
one
so
and
I
went
ahead
and
took
mine
out
of
draft
state.
So
if
anybody
wants
to
look
at
that
and
give
that
a
thumbs
up,
they're
welcome
too,
if
they
want
to
give
the
thumbs
up
to
the
bachelor,
welcome
to
do
as
well
and
10
30
is
that
I
believe
is
errands
and
I.
B
B
But
I
want
to
put
up
there.
I,
don't
think
it's
something
we
can
do
on
the
call
today.
I
think
people
are
going
to
need
to
sit
down,
spend
some
time
actually
reading
through
these,
but
I
think
that'll,
be
a
good
path
forward
is
to
look
through
each
each
one
of
those
and
sort
out
which
way
they
want
to
go
on
that
one
and
what
they
want
to
approve.
B
If
nobody
has
anything
on
that,
one
I
can
throw
out
something
might
be
a
little
more
rejectionable.
Let's
see,
there
was
a
request
on
the
oci
mailing
list
to
get
rid
of
conformance
tests
for
blob,
delete.
B
B
E
I
guess
I
would
wonder
what
the
intent
of
the
blob
delete.
Api
was.
Was
it
like
like
a
security
thing
or.
F
H
B
H
H
You
know
maybe
I
need
to
delete
that
that
data
and
I
need
to
make
sure
it
was
dual.
So
like
you're,
you're
right,
it
requires
additional
client.
You
know
to
I'm
just
I'm,
remembering
why
it
was
put
in
there.
And
yes,
as
TNN
said
it
was,
it
was
done
for
completeness.
B
Make
it
be
had
a
flag,
and
so
does
that
make
sense
to
adjust
the
performance
test
to
just
at
least
put
a
flag
in
there
that
you
could
option
that
off
and
would
someone
still
be
oci
conformant
without
that
in
there
at
least
as
conforming
as
we
do
in
our
conformance
test,
because
you
can
be
conformed
without
a
tag
listing
API.
As
long
as
you
say,
Don't
run
that
test.
B
I
don't
know
if
I
had
the
least
confrontational
things
or
a
very
way.
It's
just
and
I'm
chilling
everybody
out
with
the
monotone
voice
there.
B
Let's
see
I'll
keep
moving
forward,
but
that
one
was
on
our
email.
So
it's
a
good
one
to
look
at
and
yeah
Aaron
for
your
comment.
There
10
29,
10,
30,
10
23
at
I,
think
they're
each
we're
all
hitting
the
same
area
of
the
code
base.
B
Let's
see
here,
Json
schema,
that's
a
quick
one.
Folks
want
to
look
at
that.
I
changed
everything
https,
but
if
you
look
at
Json
schema
that
actual
schema
term,
there
is
not
just
a
URL,
it's
also
a
thick
string
that
matches
something
Upstream
in
the
spec,
and
so
it
needs
to
stay
HTTP.
So
my
change
there
was
not
great
and
needs
to
be
reverted,
and
this
is
set
out
there
for
long
enough.
So
hopefully
someone
has
the
time
to
go
through
and
look
at
that
and
say
thumbs
up
to
that.
A
B
Yeah
I
had
paying
feedbacks
and
said:
hey
I'm,
just
going
to
throw
my
as
a
draft,
because
I
got
too
much
content.
There
try
to
figure
out
and
put
it
up
there
and
then
I
didn't
see
anything
else
from
V
pass
when
he
saw
that
okay
I
think
it
just
means
he
hasn't
had
time
makes.
A
B
E
I
think
that
the
while
these
PRS
have
it's
a
little
merge
conflicts
I
think
that
most
of
them
look
like
they're,
pretty
easily
resolved
I.
Just
looked
at
diffing
the
three
or
trying
to
do
a
merge
on
all
three
of
them.
E
I
think
we
could
probably
just
go
in
sort
of
a
sequence:
I
think
10
23
just
defines
a
well
10
23
and
1029,
both
sort
of
Define
scratch
and
I
think
that
just
needs
to
be
resolved,
but
1029
adds
guidelines
for
artifacts
and
10.
30
changes
ignore
language
so
that
it's
clearer
that
implementations
have
different
required
Behavior
when
encountering
unknown
media
types.
B
B
B
That
either
that
or
if
it,
if
it's
possible
to
split
because
you
originally
had
a
separate
PR
for
10
30
of
saying
a
lot
of
the
language
around,
do
not
fail
or
do
not
air.
It
might
make
sense
to
look
at
those
two
separate
things.
E
Yeah
I
think
that
if
we
merge
your
two
PRS
I
think
I'll
need
to
rebase
and
actually
I
would
just
end
up
removing
some
of
the
language
that's
in
mind.
But
I
think
it
just
makes
sense
to
merge
those
first
and
before
I
attempt
to
create
a
hypothetical
PR
which
might
still
have
a
git
diff.
B
The
only
other
thing
I'm
going
to
pull
in
there
was
distribution,
spec
head
issue,
374
or
yeah.
That
was
issue
they're
running
into
issues
on
their
conformance
test
because
they
have
a
minimum
size
for
a
chunked
upload.
B
B
E
I
think
you
are
and
yes
is
there
a
there's,
an
issue
here.
Is
there
a
pull
request
s.
B
It's
been
sitting
out
for
a
long
while,
but
it
was
just
the
issue
saying
hey.
Please
please
fix
this
because
the
conformance
tests
are
breaking.
H
F
B
It's
something
with
the
S3
API
I'd
have
to
go
digging
into
the
AWS
documentation
for
that
one,
but
they
don't
want
you
to
pushing
up
things
in,
like
you
know,
two
kilobyte
chunk
at
a
time
kind
of
deal.
E
A
B
H
B
They're
originally
asking
for
an
environment
variable
but
I
said
that's
not
good
enough
for
me
because
me,
as
a
client
doesn't
know
what
the
environment
variable
is
on
your
conformance
test,
and
so
the
the
thing
we
came
back
to
was
what,
if
we
have
a
header
that
comes
back
on
that
put
that
initiates
the
chunked
upload
and
when
the
client
sees
that
header.
The
client
can
parse
that
header
and
responding
kind.
H
B
Was
looking
to
see
if
they've
got
something
and
apparently
they
don't?
But
it's
you
know
this
is
our
API
back
to
the
client
right.
B
F
B
B
F
F
A
Yeah
I
would
lean
towards
having
that,
because,
technically
speaking,
even
if
the
backend
driver
for
distribution
or
something
else
implements
smaller
or
larger
chunk
sizes,
we
chunking
can
happen
and
the
uploads
can
actually
happen
too.
There's
no
reason
for
registry
to
actually
honor
a
minimum
or
a
maximum,
because
each
of
those
drivers
independently
implement
the
chant
upload.
So
what
I'm
trying
to
understand
is
is
the
client
failing,
because
the
underlying
implementation
doesn't
handle
these
cases
or
is
it
because.
B
Was
the
common
I
see
at
the
very
first
or
very
top
of
the
issue,
is
a
five
megabyte,
except
for
the
last
chunk,
whatever
that
last
chunk
is
right,
and
so
if
we
start
pushing
two
chunks
and
they're
both
less
than
the
five
megabyte
limit,
then
it's
going
to
fail
this
upload
and
that's
because
they
weren't
doing
it
in
the
registry
server.
They
just
passed
directly
off
to
the
three
back
end
and
the
S3
was
throwing
that
error.
A
B
B
H
Yeah,
that's
that's
sort
of
the
thing
right,
they're
trying
to
get
run
the
conformance
against
their
registry
and
is
failing
in
this
case,
so
they're
they're,
asking
for
a
switch
to
make
it
pass
for
their
which
we've
done
for
prior
other
registries.
Allow
them
to
configure
what
they
needed
to
get
it
to
run
correctly
right.
So
long
as
the
specification
did
not
have
a
restriction
against
that
configuration.
B
B
B
B
So,
if
we
put
guidance,
I
would
adjust,
manages
for
all
our
guidance
and
that
would
that
would
work.
But
the
the
nice
thing
about
throwing
a
header
in
there
is
that
the
header
just
gives
back
that
feedback
so
that
we
don't
have
to
put
in
the
spec
at
all.
It's
just
passed
back
to
the
client
of
hey.
This
is
what
you
need
to
be
above.
A
Was
just
following
presidential
manifest
we
did
not
publish
the
max
manifest
size
as
a
header.
Why
would
we
do
that
for
chunk
size
specifically.
B
The
the
one
thing
we
got
in
the
chunk,
API
that
we
don't
have
with
the
Manifest,
is
when
you
upload
a
manifest,
you
just
send
it.
The
registry
has
no
option
at
that
point,
to
tell
you
anything
before
you
send
it
you're
just
uploading
at
that
point
with
the
chunked
upload
there
is
that
initial
post
request
that
says
give
me
the
URL
I
need
to
start
doing
my
chunked
uploads
too,
and
so
you
do
have
a
response
back
from
the
server
at
that
point
that
they
can
pass
additional
data
in.
A
Yes,
you
do
end
up
sending
the
first
chunk,
though,
to
get
this
right
or
is.
A
B
C
A
B
B
The
the
374
we're
looking
at
a
chunked
upload
and
if
you
push
a
chunk,
that's
too
small,
the
back
end,
S3
API
comes
back
and
says
that
your
trunk
is
too
small.
So
you
can't
push
that
you
know
worrying
about
various
attack
scenarios
against
an
S3
API
and
so
we're
looking
at
in
the
initial
post
that
you
request
that
says.
Hey
I
want
to
do
a
chunked
upload
to
allow
the
registry
server
to
say
yeah,
you
can
do
the
upload
to
the
URL
enter
by
the
way.
I
I
Same
limits
that
other
implementations
get
I
I
would
have
to
think
about
it.
I
definitely
think
you
I
mean
I,
think
it
would
be
something
we
shouldn't
just
say
every
you
know,
a
header
makes
sense
here,
probably
or
some
way
further
writer
should
discussify
what
what
their
minimum
is.
That's.
I
Yeah
I
mean
we
could
add
that
Jamie's
been
looking
at
stuff
like
this
as
well.
Recently,
I,
don't
know
if
he
has
any
thoughts.
B
B
I'll
get
working
on
a
PR
on
that
one
and
effects
plus
minus
either
way
feel
free
to
intercept
me
before
I
get
that
submitted,
and
we
can
always
change
it.
Otherwise,
I'll
get
something
for
us
to
look
at
for
the
next
time.
A
F
I
can't
so
it
has
a
runtime
spec
maintainer.
It
makes
me
feel
better
about
runtime
spec
changes
when
the
runtime
authors
are
thumbs,
upping
it
when
there's
a
thumbs
up
saying
yes,
I
do
agree
with
this
spec
change
and
I
do
plan
to
implement
it.
In
my
runtime,
knowing
that
registry
authors
are
on
board
with
the
change
is
probably
helpful
for
distribution,
spec,
maintainers.