Merge branch 'opencontainers:main' into main

Author: jdolitsky

CODEOWNERS

@@ -1 +1 @@
-* @brendandburns @jonjohnsonjr @jstarks @jonboulle @stevvooe @vbatts @cyphar
+* @jonjohnsonjr @jonboulle @stevvooe @vbatts @cyphar

EMERITUS.md

@@ -1,7 +1,9 @@
 We would like to acknowledge previous OCI image spec maintainers and their huge contributions to our collective success:
 
 * Brandon Philips (@philips)
+* Brendan Burns (@brendandburns)
 * Jason Bouzane (@jbouzane)
+* John Starks (@jstarks)
 * Keyang Xie (@xiekeyang)
 
 We thank these members for their service to the OCI community.

HACKING.md

@@ -96,7 +96,7 @@ $ make clean
 This target generates PNG image files from DOT source files in the `img` directory.
 
 Prerequisites:
-* [graphviz](http://www.graphviz.org/)
+* [graphviz](https://www.graphviz.org/)
 
 Invocation:
 ```

MAINTAINERS

@@ -1,6 +1,4 @@
-Brendan Burns <[email protected]> (@brendandburns)
 Jon Johnson <[email protected]> (@jonjohnsonjr)
-John Starks <[email protected]> (@jstarks)
 Jonathan Boulle <[email protected]> (@jonboulle)
 Stephen Day <[email protected]> (@stevvooe)
 Vincent Batts <[email protected]> (@vbatts)

Makefile

@@ -108,7 +108,7 @@ endif
 install.tools: $(TOOLS:%=.install.%)
 
 .install.lint:
-	go get github.com/golangci/golangci-lint/cmd/golangci-lint@latest
+	go get github.com/golangci/golangci-lint/cmd/golangci-lint@v1.45.2
 
 .install.gitvalidation:
 	go get -u github.com/vbatts/git-validation

README.md

@@ -97,7 +97,7 @@ For example, this paragraph will span three lines in the Markdown source.
 ### Sign your work
 
 The sign-off is a simple line at the end of the explanation for the patch, which certifies that you wrote it or otherwise have the right to pass it on as an open-source patch.
-The rules are pretty simple: if you can certify the below (from [developercertificate.org](http://developercertificate.org/)):
+The rules are pretty simple: if you can certify the below (from [developercertificate.org](https://developercertificate.org/)):
 
 ```
 Developer Certificate of Origin
@@ -149,7 +149,7 @@ You can add the sign off when creating the git commit via `git commit -s`.
 ### Commit Style
 
 Simple house-keeping for clean git history.
-Read more on [How to Write a Git Commit Message](http://chris.beams.io/posts/git-commit/) or the Discussion section of [`git-commit(1)`](http://git-scm.com/docs/git-commit).
+Read more on [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/) or the Discussion section of [`git-commit(1)`](https://git-scm.com/docs/git-commit).
 
 1. Separate the subject from body with a blank line
 2. Limit the subject line to 50 characters

annotations.md

@@ -24,7 +24,7 @@ This specification defines the following annotation keys, intended for but not l
 * **org.opencontainers.image.source** URL to get source code for building the image (string)
 * **org.opencontainers.image.version** version of the packaged software
   * The version MAY match a label or tag in the source code repository
-  * version MAY be [Semantic versioning-compatible](http://semver.org/)
+  * version MAY be [Semantic versioning-compatible](https://semver.org/)
 * **org.opencontainers.image.revision** Source control revision identifier for the packaged software.
 * **org.opencontainers.image.vendor** Name of the distributing entity, organization or individual.
 * **org.opencontainers.image.licenses** License(s) under which contained software is distributed as an [SPDX License Expression][spdx-license-expression].

considerations.md

@@ -20,10 +20,10 @@ Implementations:
 
 * [Go][]: [github.com/docker/go][], which claims to implement [canonical JSON][canonical-json] except for Unicode normalization.
 
-[canonical-json]: http://wiki.laptop.org/go/Canonical_JSON
+[canonical-json]: https://wiki.laptop.org/go/Canonical_JSON
 [github.com/docker/go]: https://github.com/docker/go/
 [Go]: https://golang.org/
-[JSON]: http://json.org/
+[JSON]: https://json.org/
 
 # EBNF
 

descriptor.md

@@ -59,7 +59,7 @@ Extended _Descriptor_ field additions proposed in other OCI specifications SHOUL
 
 ## Digests
 
-The _digest_ property of a Descriptor acts as a content identifier, enabling [content addressability](http://en.wikipedia.org/wiki/Content-addressable_storage).
+The _digest_ property of a Descriptor acts as a content identifier, enabling [content addressability](https://en.wikipedia.org/wiki/Content-addressable_storage).
 It uniquely identifies content by taking a [collision-resistant hash](https://en.wikipedia.org/wiki/Cryptographic_hash_function) of the bytes.
 If the _digest_ can be communicated in a secure manner, one can verify content from an insecure source by recalculating the digest independently, ensuring the content has not been modified.
 

layer.md

@@ -63,7 +63,7 @@ Where supported, MUST include file attributes for Additions and Modifications in
 
 #### Hardlinks
 
-* Hardlinks are a [POSIX concept](http://pubs.opengroup.org/onlinepubs/9699919799/functions/link.html) for having one or more directory entries for the same file on the same device.
+* Hardlinks are a [POSIX concept](https://pubs.opengroup.org/onlinepubs/9699919799/functions/link.html) for having one or more directory entries for the same file on the same device.
 * Not all filesystems support hardlinks (e.g. [FAT](https://en.wikipedia.org/wiki/File_Allocation_Table)).
 * Hardlinks are possible with all [file types](#file-types) except `directories`.
 * Non-directory files are considered "hardlinked" when their link count is greater than 1.
@@ -147,9 +147,9 @@ Entries for the following files:
 
 Create a new directory and initialize it with a copy or snapshot of the prior root filesystem.
 Example commands that can preserve [file attributes](#file-attributes) to make this copy are:
-* [cp(1)](http://linux.die.net/man/1/cp): `cp -a rootfs-c9d-v1/ rootfs-c9d-v1.s1/`
-* [rsync(1)](http://linux.die.net/man/1/rsync):  `rsync -aHAX rootfs-c9d-v1/ rootfs-c9d-v1.s1/`
-* [tar(1)](http://linux.die.net/man/1/tar): `mkdir rootfs-c9d-v1.s1 && tar --acls --xattrs -C rootfs-c9d-v1/ -c . | tar -C rootfs-c9d-v1.s1/ --acls --xattrs -x` (including `--selinux` where supported)
+* [cp(1)](https://linux.die.net/man/1/cp): `cp -a rootfs-c9d-v1/ rootfs-c9d-v1.s1/`
+* [rsync(1)](https://linux.die.net/man/1/rsync):  `rsync -aHAX rootfs-c9d-v1/ rootfs-c9d-v1.s1/`
+* [tar(1)](https://linux.die.net/man/1/tar): `mkdir rootfs-c9d-v1.s1 && tar --acls --xattrs -C rootfs-c9d-v1/ -c . | tar -C rootfs-c9d-v1.s1/ --acls --xattrs -x` (including `--selinux` where supported)
 
 Any [changes](#change-types) to the snapshot MUST NOT change or affect the directory it was copied from.
 
@@ -235,7 +235,7 @@ This section specifies applying an entry from a layer changeset if the target pa
 
 If the entry and the existing path are both directories, then the existing path's attributes MUST be replaced by those of the entry in the changeset.
 In all other cases, the implementation MUST do the semantic equivalent of the following:
-- removing the file path (e.g. [`unlink(2)`](http://linux.die.net/man/2/unlink) on Linux systems)
+- removing the file path (e.g. [`unlink(2)`](https://linux.die.net/man/2/unlink) on Linux systems)
 - recreating the file path, based on the contents and attributes of the changeset entry
 
 ## Whiteouts
@@ -333,7 +333,7 @@ Implementations SHOULD NOT upload layers tagged with this media type; however, s
 [Descriptors](descriptor.md) referencing non-distributable layers MAY include `urls` for downloading these layers directly; however, the presence of the `urls` field SHOULD NOT be used to determine whether or not a layer is non-distributable.
 
 [libarchive-tar]: https://github.com/libarchive/libarchive/wiki/ManPageTar5#POSIX_ustar_Archives
-[gnu-tar-standard]: http://www.gnu.org/software/tar/manual/html_node/Standard.html
+[gnu-tar-standard]: https://www.gnu.org/software/tar/manual/html_node/Standard.html
 [rfc1952_2]: https://tools.ietf.org/html/rfc1952
 [tar-archive]: https://en.wikipedia.org/wiki/Tar_(computing)
 [rfc8478]: https://tools.ietf.org/html/rfc8478

schema/config-schema.json

@@ -1,6 +1,6 @@
 {
   "description": "OpenContainer Config Specification",
-  "$schema": "http://json-schema.org/draft-04/schema#",
+  "$schema": "https://json-schema.org/draft-04/schema#",
   "id": "https://opencontainers.org/schema/image/config",
   "type": "object",
   "properties": {

schema/content-descriptor.json

@@ -1,6 +1,6 @@
 {
   "description": "OpenContainer Content Descriptor Specification",
-  "$schema": "http://json-schema.org/draft-04/schema#",
+  "$schema": "https://json-schema.org/draft-04/schema#",
   "id": "https://opencontainers.org/schema/descriptor",
   "type": "object",
   "properties": {

schema/image-index-schema.json

@@ -1,6 +1,6 @@
 {
   "description": "OpenContainer Image Index Specification",
-  "$schema": "http://json-schema.org/draft-04/schema#",
+  "$schema": "https://json-schema.org/draft-04/schema#",
   "id": "https://opencontainers.org/schema/image/index",
   "type": "object",
   "properties": {

schema/image-layout-schema.json

@@ -1,6 +1,6 @@
 {
   "description": "OpenContainer Image Layout Schema",
-  "$schema": "http://json-schema.org/draft-04/schema#",
+  "$schema": "https://json-schema.org/draft-04/schema#",
   "id": "https://opencontainers.org/schema/image/layout",
   "type": "object",
   "properties": {

schema/image-manifest-schema.json

@@ -1,6 +1,6 @@
 {
   "description": "OpenContainer Image Manifest Specification",
-  "$schema": "http://json-schema.org/draft-04/schema#",
+  "$schema": "https://json-schema.org/draft-04/schema#",
   "id": "https://opencontainers.org/schema/image/manifest",
   "type": "object",
   "properties": {

spec.md

@@ -25,7 +25,7 @@ The goal of this specification is to enable the creation of interoperable tools
 
 ## Notational Conventions
 
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC 2119](http://tools.ietf.org/html/rfc2119) (Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997).
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119) (Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997).
 
 The key words "unspecified", "undefined", and "implementation-defined" are to be interpreted as described in the [rationale for the C99 standard][c99-unspecified].
 
@@ -64,5 +64,5 @@ Future versions of this specification may include the following OPTIONAL feature
 * Signatures that are based on signing image content address
 * Naming that is federated based on DNS and can be delegated
 
-[c99-unspecified]: http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf#page=18
+[c99-unspecified]: https://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf#page=18
 [runtime-spec]: https://github.com/opencontainers/runtime-spec