Update man pages and add missing man pages to containers-common.

containers-certs.d.5.md

@@ -0,0 +1,28 @@
+% containers-certs.d(5)
+
+# NAME
+containers-certs.d - Directory for storing custom container-registry TLS configurations
+
+# DESCRIPTION
+A custom TLS configuration for a container registry can be configured by creating a directory under `/etc/containers/certs.d`.
+The name of the directory must correspond to the `host:port` of the registry (e.g., `my-registry.com:5000`).
+
+## Directory Structure
+A certs directory can contain one or more files with the following extensions:
+
+* `*.crt`  files with this extensions will be interpreted as CA certificates
+* `*.cert` files with this extensions will be interpreted as client certificates
+* `*.key`  files with this extensions will be interpreted as client keys
+
+Note that the client certificate-key pair will be selected by the file name (e.g., `client.{cert,key}`).
+An examplary setup for a registry running at `my-registry.com:5000` may look as follows:
+```
+/etc/containers/certs.d/    <- Certificate directory
+└── my-registry.com:5000    <- Hostname:port
+   ├── client.cert          <- Client certificate
+   ├── client.key           <- Client key
+   └── ca.crt               <- Certificate authority that signed the registry certificate
+```
+
+# HISTORY
+Feb 2019, Originally compiled by Valentin Rothberg <rothberg@redhat.com>

containers-policy.json.5.md

@@ -1,9 +1,9 @@
-% POLICY.JSON(5) policy.json Man Page
+% CONTAINERS-POLICY.JSON(5) policy.json Man Page
 % Miloslav Trmač
 % September 2016
 
 # NAME
-policy.json - syntax for the signature verification policy file
+containers-policy.json - syntax for the signature verification policy file
 
 ## DESCRIPTION
 
@@ -278,4 +278,6 @@ selectively allow individual transports and scopes as desired.
   atomic(1)
 
 ## HISTORY
+August 2018, Rename to containers-policy.json(5) by Valentin Rothberg <vrothberg@suse.com>
+
 September 2016, Originally compiled by Miloslav Trmač <mitr@redhat.com>

containers-registries.conf.5.md

@@ -7,14 +7,68 @@ containers-registries.conf - Syntax of System Registry Configuration File
 
 # DESCRIPTION
 The CONTAINERS-REGISTRIES configuration file is a system-wide configuration
-file for container image registries. The file format is TOML. The valid
+file for container image registries. The file format is TOML.
-categories are: 'registries.search', 'registries.insecure', and
-'registries.block'.
 
 By default, the configuration file is located at `/etc/containers/registries.conf`.
 
-# FORMAT
+# FORMATS
-The TOML_format is used to build a simple list format for registries under three
+
+## VERSION 2
+VERSION 2 is the latest format of the `registries.conf` and is currently in
+beta. This means in general VERSION 1 should be used in production environments
+for now.
+
+Every registry can have its own mirrors configured.  The mirrors will be tested
+in order for the availability of the remote manifest.  This happens currently
+only during an image pull.  If the manifest is not reachable due to connectivity
+issues or the unavailability of the remote manifest, then the next mirror will
+be tested instead.  If no mirror is configured or contains the manifest to be
+pulled, then the initially provided reference will be used as fallback.  It is
+possible to set the `insecure` option per mirror, too.
+
+Furthermore it is possible to specify a `prefix` for a registry.  The `prefix`
+is used to find the relevant target registry from where the image has to be
+pulled.  During the test for the availability of the image, the prefixed
+location will be rewritten to the correct remote location.  This applies to
+mirrors as well as the fallback `location`.  If no prefix is specified, it
+defaults to the specified `location`.  For example, if
+`prefix = "example.com/foo"`, `location = "example.com"` and the image will be
+pulled from `example.com/foo/image`, then the resulting pull will be effectively
+point to `example.com/image`.
+
+By default container runtimes use TLS when retrieving images from a registry.
+If the registry is not setup with TLS, then the container runtime will fail to
+pull images from the registry. If you set `insecure = true` for a registry or a
+mirror you overwrite the `insecure` flag for that specific entry.  This means
+that the container runtime will attempt use unencrypted HTTP to pull the image.
+It also allows you to pull from a registry with self-signed certificates.
+
+If you set the `unqualified-search = true` for the registry, then it is possible
+to omit the registry hostname when pulling images.  This feature does not work
+together with a specified `prefix`.
+
+If `blocked = true` then it is not allowed to pull images from that registry.
+
+### EXAMPLE
+
+```
+[[registry]]
+location = "example.com"
+insecure = false
+prefix = "example.com/foo"
+unqualified-search = false
+blocked = false
+mirror = [
+    { location = "example-mirror-0.local", insecure = false },
+    { location = "example-mirror-1.local", insecure = true }
+]
+```
+
+## VERSION 1
+VERSION 1 can be used as alternative to the VERSION 2, but it is not capable in
+using registry mirrors or a prefix.
+
+The TOML_format is used to build a simple list for registries under three
 categories: `registries.search`, `registries.insecure`, and `registries.block`.
 You can list multiple registries using a comma separated list.
 
@@ -22,18 +76,13 @@ Search registries are used when the caller of a container runtime does not fully
 container image that they want to execute.  These registries are prepended onto the front
 of the specified container image until the named image is found at a registry.
 
-Insecure Registries.  By default container runtimes use TLS when retrieving images
-from a registry.  If the registry is not setup with TLS, then the container runtime
-will fail to pull images from the registry. If you add the registry to the list of
-insecure registries then the container runtime will attempt use standard web protocols to
-pull the image.  It also allows you to pull from a registry with self-signed certificates.
 Note insecure registries can be used for any registry, not just the registries listed
 under search.
 
-Block Registries.  The registries in this category are are not pulled from when
+The fields `registries.insecure` and `registries.block` work as like as the
-retrieving images.
+`insecure` and `blocked` from VERSION 2.
 
-# EXAMPLE
+### EXAMPLE
 The following example configuration defines two searchable registries, one
 insecure registry, and two blocked registries.
 
@@ -49,6 +98,8 @@ registries = ['registry.untrusted.com', 'registry.unsafe.com']
 ```
 
 # HISTORY
+Mar 2019, Added additional configuration format by Sascha Grunert <sgrunert@suse.com>
+
 Aug 2018, Renamed to containers-registries.conf(5) by Valentin Rothberg <vrothberg@suse.com>
 
 Jun 2018, Updated by Tom Sweeney <tsweeney@redhat.com>

containers-registries.d.5.md

@@ -0,0 +1,128 @@
+% CONTAINERS-REGISTRIES.D(5) Registries.d Man Page
+% Miloslav Trmač
+% August 2016
+
+# NAME
+containers-registries.d - Directory for various registries configurations
+
+# DESCRIPTION
+
+The registries configuration directory contains configuration for various registries
+(servers storing remote container images), and for content stored in them,
+so that the configuration does not have to be provided in command-line options over and over for every command,
+and so that it can be shared by all users of containers/image.
+
+By default (unless overridden at compile-time), the registries configuration directory is `/etc/containers/registries.d`;
+applications may allow using a different directory instead.
+
+## Directory Structure
+
+The directory may contain any number of files with the extension `.yaml`,
+each using the YAML format.  Other than the mandatory extension, names of the files
+don’t matter.
+
+The contents of these files are merged together; to have a well-defined and easy to understand
+behavior, there can be only one configuration section describing a single namespace within a registry
+(in particular there can be at most one one `default-docker` section across all files,
+and there can be at most one instance of any key under the the `docker` section;
+these sections are documented later).
+
+Thus, it is forbidden to have two conflicting configurations for a single registry or scope,
+and it is also forbidden to split a configuration for a single registry or scope across
+more than one file (even if they are not semantically in conflict).
+
+## Registries, Scopes and Search Order
+
+Each YAML file must contain a “YAML mapping” (key-value pairs).  Two top-level keys are defined:
+
+- `default-docker` is the _configuration section_ (as documented below)
+   for registries implementing "Docker Registry HTTP API V2".
+
+   This key is optional.
+
+- `docker` is a mapping, using individual registries implementing "Docker Registry HTTP API V2",
+   or namespaces and individual images within these registries, as keys;
+   the value assigned to any such key is a _configuration section_.
+
+   This key is optional.
+
+   Scopes matching individual images are named Docker references *in the fully expanded form*, either
+   using a tag or digest. For example, `docker.io/library/busybox:latest` (*not* `busybox:latest`).
+
+   More general scopes are prefixes of individual-image scopes, and specify a repository (by omitting the tag or digest),
+   a repository namespace, or a registry host (and a port if it differs from the default).
+
+   Note that if a registry is accessed using a hostname+port configuration, the port-less hostname
+   is _not_ used as parent scope.
+
+When searching for a configuration to apply for an individual container image, only
+the configuration for the most-precisely matching scope is used; configuration using
+more general scopes is ignored.  For example, if _any_ configuration exists for
+`docker.io/library/busybox`, the configuration for `docker.io` is ignored
+(even if some element of the configuration is defined for `docker.io` and not for `docker.io/library/busybox`).
+
+## Individual Configuration Sections
+
+A single configuration section is selected for a container image using the process
+described above.  The configuration section is a YAML mapping, with the following keys:
+
+- `sigstore-staging` defines an URL of of the signature storage, used for editing it (adding or deleting signatures).
+
+   This key is optional; if it is missing, `sigstore` below is used.
+
+- `sigstore` defines an URL of the signature storage.
+   This URL is used for reading existing signatures,
+   and if `sigstore-staging` does not exist, also for adding or removing them.
+
+   This key is optional; if it is missing, no signature storage is defined (no signatures
+   are download along with images, adding new signatures is possible only if `sigstore-staging` is defined).
+
+## Examples
+
+### Using Containers from Various Origins
+
+The following demonstrates how to to consume and run images from various registries and namespaces:
+
+```yaml
+docker:
+    registry.database-supplier.com:
+        sigstore: https://sigstore.database-supplier.com
+    distribution.great-middleware.org:
+        sigstore: https://security-team.great-middleware.org/sigstore
+    docker.io/web-framework:
+        sigstore: https://sigstore.web-framework.io:8080
+```
+
+### Developing and Signing Containers, Staging Signatures
+
+For developers in `example.com`:
+
+- Consume most container images using the public servers also used by clients.
+- Use a separate sigure storage for an container images in a namespace corresponding to the developers' department, with a staging storage used before publishing signatures.
+- Craft an individual exception for a single branch a specific developer is working on locally.
+
+```yaml
+docker:
+    registry.example.com:
+        sigstore: https://registry-sigstore.example.com
+    registry.example.com/mydepartment:
+        sigstore: https://sigstore.mydepartment.example.com
+        sigstore-staging: file:///mnt/mydepartment/sigstore-staging
+    registry.example.com/mydepartment/myproject:mybranch:
+        sigstore: http://localhost:4242/sigstore
+        sigstore-staging: file:///home/useraccount/webroot/sigstore
+```
+
+### A Global Default
+
+If a company publishes its products using a different domain, and different registry hostname for each of them, it is still possible to use a single signature storage server
+without listing each domain individually. This is expected to rarely happen, usually only for staging new signatures.
+
+```yaml
+default-docker:
+    sigstore-staging: file:///mnt/company/common-sigstore-staging
+```
+
+# AUTHORS
+
+Miloslav Trmač <mitr@redhat.com>

containers-signature.5.md

@@ -0,0 +1,241 @@
+% container-signature(5) Container signature format
+% Miloslav Trmač
+% March 2017
+
+# Container signature format
+
+This document describes the format of container signatures,
+as implemented by the `github.com/containers/image/signature` package.
+
+Most users should be able to consume these signatures by using the `github.com/containers/image/signature` package
+(preferably through the higher-level `signature.PolicyContext` interface)
+without having to care about the details of the format described below.
+This documentation exists primarily for maintainers of the package
+and to allow independent reimplementations.
+
+## High-level overview
+
+The signature provides an end-to-end authenticated claim that a container image
+has been approved by a specific party (e.g. the creator of the image as their work,
+an automated build system as a result of an automated build,
+a company IT department approving the image for production) under a specified _identity_
+(e.g. an OS base image / specific application, with a specific version).
+
+A container signature consists of a cryptographic signature which identifies
+and authenticates who signed the image, and carries as a signed payload a JSON document.
+The JSON document identifies the image being signed, claims a specific identity of the
+image and if applicable, contains other information about the image.
+
+The signatures do not modify the container image (the layers, configuration, manifest, …);
+e.g. their presence does not change the manifest digest used to identify the image in
+docker/distribution servers; rather, the signatures are associated with an immutable image.
+An image can have any number of signatures so signature distribution systems SHOULD support
+associating more than one signature with an image.
+
+## The cryptographic signature
+
+As distributed, the container signature is a blob which contains a cryptographic signature
+in an industry-standard format, carrying a signed JSON payload (i.e. the blob contains both the
+JSON document and a signature of the JSON document; it is not a “detached signature” with
+independent blobs containing the JSON document and a cryptographic signature).
+
+Currently the only defined cryptographic signature format is an OpenPGP signature (RFC 4880),
+but others may be added in the future.  (The blob does not contain metadata identifying the
+cryptographic signature format. It is expected that most formats are sufficiently self-describing
+that this is not necessary and the configured expected public key provides another indication
+of the expected cryptographic signature format. Such metadata may be added in the future for
+newly added cryptographic signature formats, if necessary.)
+
+Consumers of container signatures SHOULD verify the cryptographic signature
+against one or more trusted public keys
+(e.g. defined in a [policy.json signature verification policy file](policy.json.md))
+before parsing or processing the JSON payload in _any_ way,
+in particular they SHOULD stop processing the container signature
+if the cryptographic signature verification fails, without even starting to process the JSON payload.
+
+(Consumers MAY extract identification of the signing key and other metadata from the cryptographic signature,
+and the JSON payload, without verifying the signature, if the purpose is to allow managing the signature blobs,
+e.g. to list the authors and image identities of signatures associated with a single container image;
+if so, they SHOULD design the output of such processing to minimize the risk of users considering the output trusted
+or in any way usable for making policy decisions about the image.)
+
+### OpenPGP signature verification
+
+When verifying a cryptographic signature in the OpenPGP format,
+the consumer MUST verify at least the following aspects of the signature
+(like the `github.com/containers/image/signature` package does):
+
+- The blob MUST be a “Signed Message” as defined RFC 4880 section 11.3.
+  (e.g. it MUST NOT be an unsigned “Literal Message”, or any other non-signature format).
+- The signature MUST have been made by an expected key trusted for the purpose (and the specific container image).
+- The signature MUST be correctly formed and pass the cryptographic validation.
+- The signature MUST correctly authenticate the included JSON payload
+  (in particular, the parsing of the JSON payload MUST NOT start before the complete payload has been cryptographically authenticated).
+- The signature MUST NOT be expired.
+
+The consumer SHOULD have tests for its verification code which verify that signatures failing any of the above are rejected.
+
+## JSON processing and forward compatibility
+
+The payload of the cryptographic signature is a JSON document (RFC 7159).
+Consumers SHOULD parse it very strictly,
+refusing any signature which violates the expected format (e.g. missing members, incorrect member types)
+or can be interpreted ambiguously (e.g. a duplicated member in a JSON object).
+
+Any violations of the JSON format or of other requirements in this document MAY be accepted if the JSON document can be recognized
+to have been created by a known-incorrect implementation (see [`optional.creator`](#optionalcreator) below)
+and if the semantics of the invalid document, as created by such an implementation, is clear.
+
+The top-level value of the JSON document MUST be a JSON object with exactly two members, `critical` and `optional`,
+each a JSON object.
+
+The `critical` object MUST contain a `type` member identifying the document as a container signature
+(as defined [below](#criticaltype))
+and signature consumers MUST reject signatures which do not have this member or in which this member does not have the expected value.
+
+To ensure forward compatibility (allowing older signature consumers to correctly
+accept or reject signatures created at a later date, with possible extensions to this format),
+consumers MUST reject the signature if the `critical` object, or _any_ of its subobjects,
+contain _any_ member or data value which is unrecognized, unsupported, invalid, or in any other way unexpected.
+At a minimum, this includes unrecognized members in a JSON object, or incorrect types of expected members.
+
+For the same reason, consumers SHOULD accept any members with unrecognized names in the `optional` object,
+and MAY accept signatures where the object member is recognized but unsupported, or the value of the member is unsupported.
+Consumers still SHOULD reject signatures where a member of an `optional` object is supported but the value is recognized as invalid.
+
+## JSON data format
+
+An example of the full format follows, with detailed description below.
+To reiterate, consumers of the signature SHOULD perform successful cryptographic verification,
+and MUST reject unexpected data in the `critical` object, or in the top-level object, as described above.
+
+```json
+{
+    "critical": {
+        "type": "atomic container signature",
+        "image": {
+            "docker-manifest-digest": "sha256:817a12c32a39bbe394944ba49de563e085f1d3c5266eb8e9723256bc4448680e"
+        },
+        "identity": {
+            "docker-reference": "docker.io/library/busybox:latest"
+        }
+    },
+    "optional": {
+        "creator": "some software package v1.0.1-35",
+        "timestamp": 1483228800,
+    }
+}
+```
+
+### `critical`
+
+This MUST be a JSON object which contains data critical to correctly evaluating the validity of a signature.
+
+Consumers MUST reject any signature where the `critical` object contains any unrecognized, unsupported, invalid or in any other way unexpected member or data.
+
+### `critical.type`
+
+This MUST be a string with a string value exactly equal to `atomic container signature` (three words, including the spaces).
+
+Signature consumers MUST reject signatures which do not have this member or this member does not have exactly the expected value.
+
+(The consumers MAY support signatures with a different value of the `type` member, if any is defined in the future;
+if so, the rest of the JSON document is interpreted according to rules defining that value of `critical.type`,
+not by this document.)
+
+### `critical.image`
+
+This MUST be a JSON object which identifies the container image this signature applies to.
+
+Consumers MUST reject any signature where the `critical.image` object contains any unrecognized, unsupported, invalid or in any other way unexpected member or data.
+
+(Currently only the `docker-manifest-digest` way of identifying a container image is defined;
+alternatives to this may be defined in the future,
+but existing consumers are required to reject signatures which use formats they do not support.)
+
+### `critical.image.docker-manifest-digest`
+
+This MUST be a JSON string, in the `github.com/opencontainers/go-digest.Digest` string format.
+
+The value of this member MUST match the manifest of the signed container image, as implemented in the docker/distribution manifest addressing system.
+
+The consumer of the signature SHOULD verify the manifest digest against a fully verified signature before processing the contents of the image manifest in any other way
+(e.g. parsing the manifest further or downloading layers of the image).
+
+Implementation notes:
+* A single container image manifest may have several valid manifest digest values, using different algorithms.
+* For “signed” [docker/distribution schema 1](https://github.com/docker/distribution/blob/master/docs/spec/manifest-v2-1.md) manifests,
+the manifest digest applies to the payload of the JSON web signature, not to the raw manifest blob.
+
+### `critical.identity`
+
+This MUST be a JSON object which identifies the claimed identity of the image (usually the purpose of the image, or the application, along with a version information),
+as asserted by the author of the signature.
+
+Consumers MUST reject any signature where the `critical.identity` object contains any unrecognized, unsupported, invalid or in any other way unexpected member or data.
+
+(Currently only the `docker-reference` way of claiming an image identity/purpose is defined;
+alternatives to this may be defined in the future,
+but existing consumers are required to reject signatures which use formats they do not support.)
+
+### `critical.identity.docker-reference`
+
+This MUST be a JSON string, in the `github.com/docker/distribution/reference` string format,
+and using the same normalization semantics (where e.g. `busybox:latest` is equivalent to `docker.io/library/busybox:latest`).
+If the normalization semantics allows multiple string representations of the claimed identity with equivalent meaning,
+the `critical.identity.docker-reference` member SHOULD use the fully explicit form (including the full host name and namespaces).
+
+The value of this member MUST match the image identity/purpose expected by the consumer of the image signature and the image
+(again, accounting for the `docker/distribution/reference` normalization semantics).
+
+In the most common case, this means that the `critical.identity.docker-reference` value must be equal to the docker/distribution reference used to refer to or download the image.
+However, depending on the specific application, users or system administrators may accept less specific matches
+(e.g. ignoring the tag value in the signature when pulling the `:latest` tag or when referencing an image by digest),
+or they may require `critical.identity.docker-reference` values with a completely different namespace to the reference used to refer to/download the image
+(e.g. requiring a `critical.identity.docker-reference` value which identifies the image as coming from a supplier when fetching it from a company-internal mirror of approved images).
+The software performing this verification SHOULD allow the users to define such a policy using the [policy.json signature verification policy file format](policy.json.md).
+
+The `critical.identity.docker-reference` value SHOULD contain either a tag or digest;
+in most cases, it SHOULD use a tag rather than a digest.  (See also the default [`matchRepoDigestOrExact` matching semantics in `policy.json`](policy.json.md#signedby).)
+
+### `optional`
+
+This MUST be a JSON object.
+
+Consumers SHOULD accept any members with unrecognized names in the `optional` object,
+and MAY accept a signature where the object member is recognized but unsupported, or the value of the member is valid but unsupported.
+Consumers still SHOULD reject any signature where a member of an `optional` object is supported but the value is recognized as invalid.
+
+### `optional.creator`
+
+If present, this MUST be a JSON string, identifying the name and version of the software which has created the signature.
+
+The contents of this string is not defined in detail; however each implementation creating container signatures:
+
+- SHOULD define the contents to unambiguously define the software in practice (e.g. it SHOULD contain the name of the software, not only the version number)
+- SHOULD use a build and versioning process which ensures that the contents of this string (e.g. an included version number)
+  changes whenever the format or semantics of the generated signature changes in any way;
+  it SHOULD not be possible for two implementations which use a different format or semantics to have the same `optional.creator` value
+- SHOULD use a format which is reasonably easy to parse in software (perhaps using a regexp),
+  and which makes it easy enough to recognize a range of versions of a specific implementation
+  (e.g. the version of the implementation SHOULD NOT be only a git hash, because they don’t have an easily defined ordering;
+  the string should contain a version number, or at least a date of the commit).
+
+Consumers of container signatures MAY recognize specific values or sets of values of `optional.creator`
+(perhaps augmented with `optional.timestamp`),
+and MAY change their processing of the signature based on these values
+(usually to acommodate violations of this specification in past versions of the signing software which cannot be fixed retroactively),
+as long as the semantics of the invalid document, as created by such an implementation, is clear.
+
+If consumers of signatures do change their behavior based on the `optional.creator` value,
+they SHOULD take care that the way they process the signatures is not inconsistent with
+strictly validating signature consumers.
+(I.e. it is acceptable for a consumer to accept a signature based on a specific `optional.creator` value
+if other implementations would completely reject the signature,
+but it would be very undesirable for the two kinds of implementations to accept the signature in different
+and inconsistent situations.)
+
+### `optional.timestamp`
+
+If present, this MUST be a JSON number, which is representable as a 64-bit integer, and identifies the time when the signature was created
+as the number of seconds since the UNIX epoch (Jan 1 1970 00:00 UTC).

containers-storage.conf.5.md

@@ -28,6 +28,12 @@ No bare options are used. The format of TOML can be simplified to:
 
 The `storage` table supports the following options:
 
+**driver**=""
+  container storage driver (default: "overlay")
+  Default Copy On Write (COW) container storage driver
+  Valid drivers are "overlay", "vfs", "devmapper", "aufs", "btrfs", and "zfs"
+  Some drivers (for example, "zfs", "btrfs", and "aufs") may not work if your kernel lacks support for the filesystem
+
 **graphroot**=""
   container storage graph dir (default: "/var/lib/containers/storage")
   Default directory to store all writable content created by container storage programs
@@ -36,12 +42,6 @@ The `storage` table supports the following options:
   container storage run dir (default: "/var/run/containers/storage")
   Default directory to store all temporary writable content created by container storage programs
 
-**driver**=""
-  container storage driver (default: "overlay")
-  Default Copy On Write (COW) container storage driver
-  Valid drivers are "overlay", "vfs", "devmapper", "aufs", "btrfs", and "zfs"
-  Some drivers (for example, "zfs", "btrfs", and "aufs") may not work if your kernel lacks support for the filesystem
-
 ### STORAGE OPTIONS TABLE
 
 The `storage.options` table supports the following options:
@@ -49,19 +49,58 @@ The `storage.options` table supports the following options:
 **additionalimagestores**=[]
   Paths to additional container image stores. Usually these are read/only and stored on remote network shares.
 
-**size**=""
-  Maximum size of a container image.   This flag can be used to set quota on the size of container images. (default: 10GB)
-
 **mount_program**=""
-  Specifies the path to a custom program to use instead for mounting the file system.
+  Specifies the path to a custom program to use instead of using kernel defaults for mounting the file system.
+
+      mount_program = "/usr/bin/fuse-overlayfs"
 
 **mountopt**=""
 
   Comma separated list of default options to be used to mount container images.  Suggested value "nodev".
 
-[storage.options.thinpool]
+**ostree_repo** = ""
+   If specified, use OSTree to deduplicate files with the overlay or vfs backends.
 
-Storage Options for thinpool
+**size**=""
+  Maximum size of a container image.   This flag can be used to set quota on the size of container images. (default: 10GB)
+
+**skip_mount_home** = "false"
+   Set to skip a PRIVATE bind mount on the storage home directory.
+Only supported by certain container storage drivers (overlay).
+
+**remap-uids=**""
+**remap-gids=**""
+
+  Remap-UIDs/GIDs is the mapping from UIDs/GIDs as they should appear inside of
+a container, to the UIDs/GIDs outside of the container, and the length of the
+range of UIDs/GIDs.  Additional mapped sets can be listed and will be heeded by
+libraries, but there are limits to the number of mappings which the kernel will
+allow when you later attempt to run a container.
+
+     Example
+     remap-uids = 0:1668442479:65536
+     remap-gids = 0:1668442479:65536
+
+     These mappings tell the container engines to map UID 0 inside of the
+     container to UID 1668442479 outside.  UID 1 will be mapped to 1668442480.
+     UID 2 will be mapped to 1668442481, etc, for the next 65533 UIDs in
+     Succession.
+
+**remap-user**=""
+**remap-group**=""
+
+  Remap-User/Group is a user name which can be used to look up one or more UID/GID
+ranges in the /etc/subuid or /etc/subgid file.  Mappings are set up starting
+with an in-container ID of 0 and then a host-level ID taken from the lowest
+range that matches the specified name, and using the length of that range.
+Additional ranges are then assigned, using the ranges which specify the
+lowest host-level IDs first, to the lowest not-yet-mapped in-container ID,
+until all of the entries have been used for maps.
+
+      remap-user = "storage"
+      remap-group = "storage"
+
+### STORAGE OPTIONS FOR THINPOOL TABLE
 
 The `storage.options.thinpool` table supports the following options:
 
@@ -113,25 +152,19 @@ Specifies the min free space percent in a thin pool required for new device crea
 
 Specifies extra mkfs arguments to be used when creating the base device.
 
-**use_deferred_removal**=""
-
-Marks devicemapper block device for deferred removal.  If the device is in use when its driver attempts to remove it, the driver tells the kernel to remove the device as soon as possible.  Note this does not free up the disk space, use deferred deletion to fully remove the thinpool.  (default: true).
-
 **use_deferred_deletion**=""
 
 Marks thinpool device for deferred deletion. If the thinpool is in use when the driver attempts to delete it, the driver will attempt to delete device every 30 seconds until successful, or when it restarts.  Deferred deletion permanently deletes the device and all data stored in the device will be lost. (default: true).
 
+**use_deferred_removal**=""
+
+Marks devicemapper block device for deferred removal.  If the device is in use when its driver attempts to remove it, the driver tells the kernel to remove the device as soon as possible.  Note this does not free up the disk space, use deferred deletion to fully remove the thinpool.  (default: true).
+
 **xfs_nospace_max_retries**=""
 
 Specifies the maximum number of retries XFS should attempt to complete IO when ENOSPC (no space) error is returned by underlying storage device. (default: 0, which means to try continuously.)
 
-**ostree_repo=""**
+## SELINUX LABELING
-  Tell storage drivers to use the specified OSTree repository.  Some storage drivers, such as overlay, might use
-
-**skip_mount_home=""**
-Tell storage drivers to not create a PRIVATE bind mount on their home directory.
-
-## SElinux labeling.
 
 When running on an SELinux system, if you move the containers storage graphroot directory, you must make sure the labeling is correct.
 

containers-transports.5.md

@@ -0,0 +1,109 @@
+% CONTAINERS-TRANSPORTS(5) Containers Transports Man Page
+% Valentin Rothberg
+% April 2019
+
+## NAME
+
+containers-transports - description of supported transports for copying and storing container images
+
+## DESCRIPTION
+
+Tools which use the containers/image library, including skopeo(1), buildah(1), podman(1), all share a common syntax for referring to container images in various locations.
+The general form of the syntax is _transport:details_, where details are dependent on the specified transport, which are documented below.
+
+### **containers-storage:** [storage-specifier]{image-id|docker-reference[@image-id]}
+
+An image located in a local containers storage.
+The format of _docker-reference_ is described in detail in the **docker** transport.
+
+The _storage-specifier_ allows for referencing storage locations on the file system and has the format `[[driver@]root[+run-root][:options]]` where the optional `driver` refers to the storage driver (e.g., overlay or btrfs) and where `root` is an absolute path to the storage's root directory.
+The optional `run-root` can be used to specify the run directory of the storage where all temporary writable content is stored.
+The optional `options` are a comma-separated list of driver-specific options.
+Please refer to containers-storage.conf(5) for further information on the drivers and supported options.
+
+### **dir:**_path_
+
+An existing local directory _path_ storing the manifest, layer tarballs and signatures as individual files.
+This is a non-standardized format, primarily useful for debugging or noninvasive container inspection.
+
+### **docker://**_docker-reference_
+
+An image in a registry implementing the "Docker Registry HTTP API V2".
+By default, uses the authorization state in `$XDG_RUNTIME_DIR/containers/auth.json`, which is set using podman-login(1).
+If the authorization state is not found there, `$HOME/.docker/config.json` is checked, which is set using docker-login(1).
+The containers-registries.conf(5) further allows for configuring various settings of a registry.
+
+Note that a _docker-reference_ has the following format: `name[:tag|@digest]`.
+While the docker transport does not support both a tag and a digest at the same time some formats like containers-storage do.
+Digests can also be used in an image destination as long as the manifest matches the provided digest.
+The digest of images can be explored with skopeo-inspect(1).
+If `name` does not contain a slash, it is treated as `docker.io/library/name`.
+Otherwise, the component before the first slash is checked if it is recognized as a `hostname[:port]` (i.e., it contains either a . or a :, or the component is exactly localhost).
+If the first component of name is not recognized as a `hostname[:port]`, `name` is treated as `docker.io/name`.
+
+### **docker-archive:**_path[:docker-reference]_
+
+An image is stored in the docker-save(1) formatted file.
+_docker-reference_ is only used when creating such a file, and it must not contain a digest.
+It is further possible to copy data to stdin by specifying `docker-archive:/dev/stdin` but note that the used file must be seekable.
+
+### **docker-daemon:**_docker-reference|algo:digest_
+
+An image stored in the docker daemon's internal storage.
+The image must be specified as a _docker-reference_ or in an alternative _algo:digest_ format when being used as an image source.
+The _algo:digest_ refers to the image ID reported by docker-inspect(1).
+
+### **oci:**_path[:tag]_
+
+An image compliant with the "Open Container Image Layout Specification" at _path_.
+Using a _tag_ is optional and allows for storing multiple images at the same _path_.
+
+### **oci-archive:**_path[:tag]_
+
+An image compliant with the "Open Container Image Layout Specification" stored as a tar(1) archive at _path_.
+
+### **ostree:**_docker-reference[@/absolute/repo/path]_
+
+An image in the local ostree(1) repository.
+_/absolute/repo/path_ defaults to _/ostree/repo_.
+
+## Examples
+
+The following examples demonstrate how some of the containers transports can be used.
+The examples use skopeo-copy(1) for copying container images.
+
+**Copying an image from one registry to another**:
+```
+$ skopeo copy docker://docker.io/library/alpine:latest docker://localhost:5000/alpine:latest
+```
+
+**Copying an image from a running Docker daemon to a directory in the OCI layout**:
+```
+$ mkdir alpine-oci
+$ skopeo copy docker-daemon:alpine:latest oci:alpine-oci
+$ tree alpine-oci
+test-oci/
+├── blobs
+│   └── sha256
+│       ├── 83ef92b73cf4595aa7fe214ec6747228283d585f373d8f6bc08d66bebab531b7
+│       ├── 9a6259e911dcd0a53535a25a9760ad8f2eded3528e0ad5604c4488624795cecc
+│       └── ff8df268d29ccbe81cdf0a173076dcfbbea4bb2b6df1dd26766a73cb7b4ae6f7
+├── index.json
+└── oci-layout
+
+2 directories, 5 files
+```
+
+**Copying an image from a registry to the local storage**:
+```
+$ skopeo copy docker://docker.io/library/alpine:latest containers-storage:alpine:latest
+```
+
+## SEE ALSO
+
+docker-login(1), docker-save(1), ostree(1), podman-login(1), skopeo-copy(1), skopeo-inspect(1), tar(1), container-registries.conf(5), containers-storage.conf(5)
+
+## AUTHORS
+
+Miloslav Trmač <mitr@redhat.com>
+Valentin Rothberg <rothberg@redhat.com>

skopeo.spec

@@ -39,7 +39,7 @@ Epoch: 1
 Epoch: 0
 %endif
 Version: 0.1.36
-Release: 17.dev.git%{shortcommit0}%{?dist}
+Release: 18.dev.git%{shortcommit0}%{?dist}
 Summary: Inspect Docker images and repositories on registries
 License: ASL 2.0
 URL: %{git0}
@@ -49,9 +49,13 @@ Source2: containers-storage.conf.5.md
 Source3: mounts.conf
 Source4: containers-registries.conf.5.md
 Source5: registries.conf
-Source6: policy.json.5.md
+Source6: containers-policy.json.5.md
 Source7: seccomp.json
 Source8: containers-mounts.conf.5.md
+Source9: containers-signature.5.md
+Source10: containers-transports.5.md
+Source11: containers-certs.d.5.md
+Source12: containers-registries.d.5.md
 
 %if 0%{?fedora}
 BuildRequires: go-srpm-macros
@@ -291,8 +295,12 @@ install -m0644 %{SOURCE1} %{buildroot}%{_sysconfdir}/containers/storage.conf
 install -p -m 644 %{SOURCE5} %{buildroot}%{_sysconfdir}/containers/
 go-md2man -in %{SOURCE2} -out %{buildroot}%{_mandir}/man5/containers-storage.conf.5
 go-md2man -in %{SOURCE4} -out %{buildroot}%{_mandir}/man5/containers-registries.conf.5
-go-md2man -in %{SOURCE6} -out %{buildroot}%{_mandir}/man5/policy.json.5
+go-md2man -in %{SOURCE6} -out %{buildroot}%{_mandir}/man5/containers-policy.json.5
 go-md2man -in %{SOURCE8} -out %{buildroot}%{_mandir}/man5/containers-mounts.conf.5
+go-md2man -in %{SOURCE9} -out %{buildroot}%{_mandir}/man5/containers-signature.5
+go-md2man -in %{SOURCE10} -out %{buildroot}%{_mandir}/man5/containers-transports.5
+go-md2man -in %{SOURCE11} -out %{buildroot}%{_mandir}/man5/containers-certs.d.5
+go-md2man -in %{SOURCE12} -out %{buildroot}%{_mandir}/man5/containers-registries.d.5
 
 mkdir -p %{buildroot}%{_datadir}/containers
 install -m0644 %{SOURCE3} %{buildroot}%{_datadir}/containers/mounts.conf
@@ -391,6 +399,9 @@ export GOPATH=%{buildroot}/%{gopath}:$(pwd)/vendor:%{gopath}
 %{_datadir}/bash-completion/completions/%{name}
 
 %changelog
+* Sun May 5 2019 Dan Walsh (Bot) <dwalsh+bot@fedoraproject.org> - 1:0.1.36-18.dev.git0fa335c
+- Update man pages and add missing man pages to containers-common.
+
 * Fri Apr 26 2019 Lokesh Manvdekar <lsm5@fedoraproject.org> - 1:0.1.36-17.dev.git0fa335c
 - Fixes @openshift/machine-config-operator#669
 - install /etc/containers/oci/hooks.d