I am looking at aligning the types defined in this repository with the
OCI image specification, and potentially exchanging local types with
those from the specification.
This patch is a stepping-stone towards that effort, but as this changes
the format of the serialized JSON, I wanted to put this up first before
proceeding with the other work in case there are concerns.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Docker Image manifest v2, schema version 1 is deprecated since 2015, when
manifest v2, schema version 2 was introduced (2e3f4934a7).
Users should no longer use this specification other than for backward
compatibility.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
We found some examples of manifests with URLs specififed that did
not provide a digest or size. This breaks the security model by allowing
the content to change, as it no longer provides a Merkle tree. This
was not intended, so explicitly disallow by tightening wording.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
The correct `vairant` string for ARM v6 is "v6", not "armv6l".
There is no known implementation that actually uses "armv6l".
See the discussion in opencontainers/image-spec PR 817
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Go 1.13 and up enforce import paths to be versioned if a project
contains a go.mod and has released v2 or up.
The current v2.x branches (and releases) do not yet have a go.mod,
and therefore are still allowed to be imported with a non-versioned
import path (go modules add a `+incompatible` annotation in that case).
However, now that this project has a `go.mod` file, incompatible
import paths will not be accepted by go modules, and attempting
to use code from this repository will fail.
This patch uses `v3` for the import-paths (not `v2`), because changing
import paths itself is a breaking change, which means that the
next release should increment the "major" version to comply with
SemVer (as go modules dictate).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This fixes registry endpoints to return the proper `application/json`
content-type for JSON content, also updating spec examples for that.
As per IETF specification and IANA registry [0], the `application/json`
type is a binary media, so the content-type label does not need any
text-charset selector. Additionally, the media type definition
explicitly states that it has no required nor optional parameters,
which makes the current registry headers non-compliant.
[0]: https://www.iana.org/assignments/media-types/application/json
Signed-off-by: Luca Bruno <lucab@debian.org>
Update grammar to support a resource class. Add
example for plugin repository class.
Signed-off-by: Derek McGowan <derek@mcgstyle.net> (github: dmcgowan)
Some frontmatter such as the weights, menu stuff, etc is no longer used
'draft=true' becomes 'published: false'
Signed-off-by: Misty Stanley-Jones <misty@docker.com>
Reading the oauth2 token documentation is misleading as it makes
no mention of it being a newer feature which may not be supported
by the token server. Add a note mentioning if it is not supported
to refer to the token documentation for getting a token.
Signed-off-by: Derek McGowan <derek@mcgstyle.net> (github: dmcgowan)
Previously, the specificiation incorrectly bound the fates of `urls` and
foreign layers. These are complementary but unrelated features, in that
the `urls` field may be populated for layers that aren't foreign. The
type of the layer only dictates the push behavior of the layer, rather
than involving where it came from.
For example, one may pull a foreign layer from a registry, but they may
not push it back to another registry. Conversely, a layer that has no
restrictions on push/pull behavior may be fetched via `urls` entries.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
