import containers-common-1-49.el9

.containers-common.metadata

@@ -0,0 +1 @@
+a72daf8585b41529269cdffcca3a0b3d4e2f21cd SOURCES/RPM-GPG-KEY-redhat-beta

.gitignore

@@ -0,0 +1 @@
+SOURCES/RPM-GPG-KEY-redhat-beta

SOURCES/002-rhel-shortnames-overrides.conf

@@ -0,0 +1,10 @@
+[aliases]
+"skopeo"  = "registry.access.redhat.com/ubi8/skopeo"
+"ubi8/skopeo" = "registry.access.redhat.com/ubi8/skopeo"
+"rhel9/skopeo" = "registry.redhat.io/rhel9/skopeo"
+"buildah" = "registry.access.redhat.com/ubi8/buildah"
+"ubi8/buildah" = "registry.access.redhat.com/ubi8/buildah"
+"rhel9/buildah" = "registry.redhat.io/rhel9/buildah"
+"podman" = "registry.access.redhat.com/ubi8/podman"
+"ubi8/podman" = "registry.access.redhat.com/ubi8/podman"
+"rhel9/podman" = "registry.redhat.io/rhel9/podman"

SOURCES/Containerfile.5.md

@@ -0,0 +1,578 @@
+% "CONTAINERFILE" "5" "Aug 2021" "" "Container User Manuals"
+
+# NAME
+
+Containerfile(Dockerfile) - automate the steps of creating a container image
+
+# INTRODUCTION
+
+The **Containerfile** is a configuration file that automates the steps of creating a container image. It is similar to a Makefile. Container engines (Podman, Buildah, Docker) read instructions from the **Containerfile** to automate the steps otherwise performed manually to create an image. To build an image, create a file called **Containerfile**.
+
+The **Containerfile** describes the steps taken to assemble the image. When the
+**Containerfile** has been created, call the `buildah bud`, `podman build`, `docker build` command,
+using the path of context directory that contains **Containerfile** as the argument. Podman and Buildah default to **Containerfile** and will fall back to **Dockerfile**. Docker only will search for **Dockerfile** in the context directory.
+
+
+**Dockerfile** is an alternate name for the same object.  **Containerfile** and **Dockerfile** support the same syntax.
+
+# SYNOPSIS
+
+INSTRUCTION arguments
+
+For example:
+
+  FROM image
+
+# DESCRIPTION
+
+A Containerfile is a file that automates the steps of creating a container image.
+A Containerfile is similar to a Makefile.
+
+# USAGE
+
+  ```
+  buildah bud .
+  podman build .
+  ```
+
+  -- Runs the steps and commits them, building a final image.
+  The path to the source repository defines where to find the context of the
+  build.
+
+  ```
+  buildah bud -t repository/tag .
+  podman build -t repository/tag .
+  ```
+
+  -- specifies a repository and tag at which to save the new image if the build
+  succeeds. The container engine runs the steps one-by-one, committing the result
+  to a new image if necessary, before finally outputting the ID of the new
+  image.
+
+  Container engines re-use intermediate images whenever possible. This significantly
+  accelerates the *build* process.
+
+# FORMAT
+
+  `FROM image`
+
+  `FROM image:tag`
+
+  `FROM image@digest`
+
+  -- The **FROM** instruction sets the base image for subsequent instructions. A
+  valid Containerfile must have either **ARG** or *FROM** as its first instruction.
+  If **FROM** is not the first instruction in the file, it may only be preceded by
+  one or more ARG instructions, which declare arguments that are used in the next FROM line in the Containerfile.
+  The image can be any valid image. It is easy to start by pulling an image from the public
+  repositories.
+
+  -- **FROM** must appear at least once in the Containerfile.
+
+  -- **FROM** The first **FROM** command must come before all other instructions in
+  the Containerfile except **ARG**
+
+  -- **FROM** may appear multiple times within a single Containerfile in order to create
+  multiple images. Make a note of the last image ID output by the commit before
+  each new **FROM** command.
+
+  -- If no tag is given to the **FROM** instruction, container engines apply the
+  `latest` tag. If the used tag does not exist, an error is returned.
+
+  -- If no digest is given to the **FROM** instruction, container engines apply the
+  `latest` tag. If the used tag does not exist, an error is returned.
+
+**MAINTAINER**
+  -- **MAINTAINER** sets the Author field for the generated images.
+  Useful for providing users with an email or url for support.
+
+**RUN**
+  -- **RUN** has two forms:
+
+  ```
+  # the command is run in a shell - /bin/sh -c
+  RUN <command>
+
+  # Executable form
+  RUN ["executable", "param1", "param2"]
+  ```
+**RUN mounts**
+
+**--mount**=*type=TYPE,TYPE-SPECIFIC-OPTION[,...]*
+
+Attach a filesystem mount to the container
+
+Current supported mount TYPES are bind, cache, secret and tmpfs.
+
+       e.g.
+
+       mount=type=bind,source=/path/on/host,destination=/path/in/container
+
+       mount=type=tmpfs,tmpfs-size=512M,destination=/path/in/container
+
+       mount=type=secret,id=mysecret cat /run/secrets/mysecret
+
+       Common Options:
+
+              · src, source: mount source spec for bind and volume. Mandatory for bind. If `from` is specified, `src` is the subpath in the `from` field.
+
+              · dst, destination, target: mount destination spec.
+
+              · ro, read-only: true (default) or false.
+
+       Options specific to bind:
+
+              · bind-propagation: shared, slave, private, rshared, rslave, or rprivate(default). See also mount(2).
+
+              . bind-nonrecursive: do not setup a recursive bind mount.  By default it is recursive.
+
+              · from: stage or image name for the root of the source. Defaults to the build context.
+
+              · rw, read-write: allows writes on the mount.
+
+       Options specific to tmpfs:
+
+              · tmpfs-size: Size of the tmpfs mount in bytes. Unlimited by default in Linux.
+
+              · tmpfs-mode: File mode of the tmpfs in octal. (e.g. 700 or 0700.) Defaults to 1777 in Linux.
+
+              · tmpcopyup: Path that is shadowed by the tmpfs mount is recursively copied up to the tmpfs itself.
+
+	Options specific to cache:
+
+              · id: Create a separate cache directory for a particular id.
+
+              · mode: File mode for new cache directory in octal. Default 0755.
+
+              · ro, readonly: read only cache if set.
+
+              · uid: uid for cache directory.
+
+              · gid: gid for cache directory.
+
+              · from: stage name for the root of the source. Defaults to host cache directory.
+
+              · rw, read-write: allows writes on the mount.
+
+
+**RUN Secrets**
+
+The RUN command has a feature to allow the passing of secret information into the image build. These secrets files can be used during the RUN command but are not committed to the final image. The `RUN` command supports the `--mount` option to identify the secret file. A secret file from the host is mounted into the container while the image is being built.
+
+Container engines pass secret the secret file into the build using the `--secret` flag.
+
+**--mount**=*type=secret,TYPE-SPECIFIC-OPTION[,...]*
+
+- `id` is the identifier for the secret passed into the `buildah bud --secret` or `podman build --secret`. This identifier is associated with the RUN --mount identifier to use in the Containerfile.
+
+- `dst`|`target`|`destination` rename the secret file to a specific file in the Containerfile RUN command to use.
+
+- `type=secret` tells the --mount command that it is mounting in a secret file
+
+```
+# shows secret from default secret location:
+RUN --mount=type=secret,id=mysecret cat /run/secrets/mysecret
+```
+```
+# shows secret from custom secret location:
+RUN --mount=type=secret,id=mysecret,dst=/foobar cat /foobar
+```
+The secret needs to be passed to the build using the --secret flag. The final image built does not container the secret file:
+
+```
+ buildah bud --no-cache --secret id=mysecret,src=mysecret.txt .
+```
+
+  -- The **RUN** instruction executes any commands in a new layer on top of the current
+  image and commits the results. The committed image is used for the next step in
+  Containerfile.
+
+  -- Layering **RUN** instructions and generating commits conforms to the core
+  concepts of container engines where commits are cheap and containers can be created from
+  any point in the history of an image. This is similar to source control.  The
+  exec form makes it possible to avoid shell string munging. The exec form makes
+  it possible to **RUN** commands using a base image that does not contain `/bin/sh`.
+
+  Note that the exec form is parsed as a JSON array, which means that you must
+  use double-quotes (") around words, not single-quotes (').
+
+**CMD**
+  -- **CMD** has three forms:
+
+  ```
+  # Executable form
+  CMD ["executable", "param1", "param2"]`
+
+  # Provide default arguments to ENTRYPOINT
+  CMD ["param1", "param2"]`
+
+  # the command is run in a shell - /bin/sh -c
+  CMD command param1 param2
+  ```
+
+  -- There should be only one **CMD** in a Containerfile. If more than one **CMD** is listed, only
+  the last **CMD** takes effect.
+  The main purpose of a **CMD** is to provide defaults for an executing container.
+  These defaults may include an executable, or they can omit the executable. If
+  they omit the executable, an **ENTRYPOINT** must be specified.
+  When used in the shell or exec formats, the **CMD** instruction sets the command to
+  be executed when running the image.
+  If you use the shell form of the **CMD**, the `<command>` executes in `/bin/sh -c`:
+
+  Note that the exec form is parsed as a JSON array, which means that you must
+  use double-quotes (") around words, not single-quotes (').
+
+  ```
+  FROM ubuntu
+  CMD echo "This is a test." | wc -
+  ```
+
+  -- If you run **command** without a shell, then you must express the command as a
+  JSON array and give the full path to the executable. This array form is the
+  preferred form of **CMD**. All additional parameters must be individually expressed
+  as strings in the array:
+
+  ```
+  FROM ubuntu
+  CMD ["/usr/bin/wc","--help"]
+  ```
+
+  -- To make the container run the same executable every time, use **ENTRYPOINT** in
+  combination with **CMD**.
+  If the user specifies arguments to `podman run` or `docker run`, the specified commands
+  override the default in **CMD**.
+  Do not confuse **RUN** with **CMD**. **RUN** runs a command and commits the result.
+  **CMD** executes nothing at build time, but specifies the intended command for
+  the image.
+
+**LABEL**
+  -- `LABEL <key>=<value> [<key>=<value> ...]`or
+  ```
+  LABEL <key>[ <value>]
+  LABEL <key>[ <value>]
+  ...
+  ```
+  The **LABEL** instruction adds metadata to an image. A **LABEL** is a
+  key-value pair. To specify a **LABEL** without a value, simply use an empty
+  string. To include spaces within a **LABEL** value, use quotes and
+  backslashes as you would in command-line parsing.
+
+  ```
+  LABEL com.example.vendor="ACME Incorporated"
+  LABEL com.example.vendor "ACME Incorporated"
+  LABEL com.example.vendor.is-beta ""
+  LABEL com.example.vendor.is-beta=
+  LABEL com.example.vendor.is-beta=""
+  ```
+
+  An image can have more than one label. To specify multiple labels, separate
+  each key-value pair by a space.
+
+  Labels are additive including `LABEL`s in `FROM` images. As the system
+  encounters and then applies a new label, new `key`s override any previous
+  labels with identical keys.
+
+  To display an image's labels, use the `buildah inspect` command.
+
+**EXPOSE**
+  -- `EXPOSE <port> [<port>...]`
+  The **EXPOSE** instruction informs the container engine that the container listens on the
+  specified network ports at runtime. The container engine uses this information to
+  interconnect containers using links and to set up port redirection on the host
+  system.
+
+**ENV**
+  -- `ENV <key> <value>`
+  The **ENV** instruction sets the environment variable <key> to
+  the value `<value>`. This value is passed to all future
+  **RUN**, **ENTRYPOINT**, and **CMD** instructions. This is
+  functionally equivalent to prefixing the command with `<key>=<value>`.  The
+  environment variables that are set with **ENV** persist when a container is run
+  from the resulting image. Use `podman inspect` to inspect these values, and
+  change them using `podman run --env <key>=<value>`.
+
+  Note that setting "`ENV DEBIAN_FRONTEND=noninteractive`" may cause
+  unintended consequences, because it will persist when the container is run
+  interactively, as with the following command: `podman run -t -i image bash`
+
+**ADD**
+  -- **ADD** has two forms:
+
+  ```
+  ADD <src> <dest>
+
+  # Required for paths with whitespace
+  ADD ["<src>",... "<dest>"]
+  ```
+
+  The **ADD** instruction copies new files, directories
+  or remote file URLs to the filesystem of the container at path `<dest>`.
+  Multiple `<src>` resources may be specified but if they are files or directories
+  then they must be relative to the source directory that is being built
+  (the context of the build). The `<dest>` is the absolute path, or path relative
+  to **WORKDIR**, into which the source is copied inside the target container.
+  If the `<src>` argument is a local file in a recognized compression format
+  (tar, gzip, bzip2, etc) then it is unpacked at the specified `<dest>` in the
+  container's filesystem.  Note that only local compressed files will be unpacked,
+  i.e., the URL download and archive unpacking features cannot be used together.
+  All new directories are created with mode 0755 and with the uid and gid of **0**.
+
+**COPY**
+  -- **COPY** has two forms:
+
+  ```
+  COPY <src> <dest>
+
+  # Required for paths with whitespace
+  COPY ["<src>",... "<dest>"]
+  ```
+
+  The **COPY** instruction copies new files from `<src>` and
+  adds them to the filesystem of the container at path <dest>. The `<src>` must be
+  the path to a file or directory relative to the source directory that is
+  being built (the context of the build) or a remote file URL. The `<dest>` is an
+  absolute path, or a path relative to **WORKDIR**, into which the source will
+  be copied inside the target container. If you **COPY** an archive file it will
+  land in the container exactly as it appears in the build context without any
+  attempt to unpack it.  All new files and directories are created with mode **0755**
+  and with the uid and gid of **0**.
+
+**ENTRYPOINT**
+  -- **ENTRYPOINT** has two forms:
+
+  ```
+  # executable form
+  ENTRYPOINT ["executable", "param1", "param2"]`
+
+  # run command in a shell - /bin/sh -c
+  ENTRYPOINT command param1 param2
+  ```
+
+  -- An **ENTRYPOINT** helps you configure a
+  container that can be run as an executable. When you specify an **ENTRYPOINT**,
+  the whole container runs as if it was only that executable.  The **ENTRYPOINT**
+  instruction adds an entry command that is not overwritten when arguments are
+  passed to `podman run`. This is different from the behavior of **CMD**. This allows
+  arguments to be passed to the entrypoint, for instance `podman run <image> -d`
+  passes the -d argument to the **ENTRYPOINT**.  Specify parameters either in the
+  **ENTRYPOINT** JSON array (as in the preferred exec form above), or by using a **CMD**
+  statement.  Parameters in the **ENTRYPOINT** are not overwritten by the `podman run` arguments.  Parameters specified via **CMD** are overwritten by `podman run` arguments.  Specify a plain string for the **ENTRYPOINT**, and it will execute in
+  `/bin/sh -c`, like a **CMD** instruction:
+
+  ```
+  FROM ubuntu
+  ENTRYPOINT wc -l -
+  ```
+
+  This means that the Containerfile's image always takes stdin as input (that's
+  what "-" means), and prints the number of lines (that's what "-l" means). To
+  make this optional but default, use a **CMD**:
+
+  ```
+  FROM ubuntu
+  CMD ["-l", "-"]
+  ENTRYPOINT ["/usr/bin/wc"]
+  ```
+
+**VOLUME**
+  -- `VOLUME ["/data"]`
+  The **VOLUME** instruction creates a mount point with the specified name and marks
+  it as holding externally-mounted volumes from the native host or from other
+  containers.
+
+**USER**
+  -- `USER daemon`
+  Sets the username or UID used for running subsequent commands.
+
+  The **USER** instruction can optionally be used to set the group or GID. The
+  following examples are all valid:
+  USER [user | user:group | uid | uid:gid | user:gid | uid:group ]
+
+  Until the **USER** instruction is set, instructions will be run as root. The USER
+  instruction can be used any number of times in a Containerfile, and will only affect
+  subsequent commands.
+
+**WORKDIR**
+  -- `WORKDIR /path/to/workdir`
+  The **WORKDIR** instruction sets the working directory for the **RUN**, **CMD**,
+  **ENTRYPOINT**, **COPY** and **ADD** Containerfile commands that follow it. It can
+  be used multiple times in a single Containerfile. Relative paths are defined
+  relative to the path of the previous **WORKDIR** instruction. For example:
+
+  ```
+  WORKDIR /a
+  WORKDIR b
+  WORKDIR c
+  RUN pwd
+  ```
+
+  In the above example, the output of the **pwd** command is **a/b/c**.
+
+**ARG**
+   -- ARG <name>[=<default value>]
+
+  The `ARG` instruction defines a variable that users can pass at build-time to
+  the builder with the `podman build` and `buildah build` commands using the
+  `--build-arg <varname>=<value>` flag. If a user specifies a build argument that
+  was not defined in the Containerfile, the build outputs a warning.
+
+  Note that a second FROM in a Containerfile sets the values associated with an
+  Arg variable to nil and they must be reset if they are to be used later in
+  the Containerfile
+
+```
+  [Warning] One or more build-args [foo] were not consumed
+  ```
+
+  The Containerfile author can define a single variable by specifying `ARG` once or many
+  variables by specifying `ARG` more than once. For example, a valid Containerfile:
+
+  ```
+  FROM busybox
+  ARG user1
+  ARG buildno
+  ...
+  ```
+
+  A Containerfile author may optionally specify a default value for an `ARG` instruction:
+
+  ```
+  FROM busybox
+  ARG user1=someuser
+  ARG buildno=1
+  ...
+  ```
+
+  If an `ARG` value has a default and if there is no value passed at build-time, the
+  builder uses the default.
+
+  An `ARG` variable definition comes into effect from the line on which it is
+  defined in the `Containerfile` not from the argument's use on the command-line or
+  elsewhere.  For example, consider this Containerfile:
+
+  ```
+  1 FROM busybox
+  2 USER ${user:-some_user}
+  3 ARG user
+  4 USER $user
+  ...
+  ```
+  A user builds this file by calling:
+
+  ```
+  $ podman build --build-arg user=what_user Containerfile
+  ```
+
+  The `USER` at line 2 evaluates to `some_user` as the `user` variable is defined on the
+  subsequent line 3. The `USER` at line 4 evaluates to `what_user` as `user` is
+  defined and the `what_user` value was passed on the command line. Prior to its definition by an
+  `ARG` instruction, any use of a variable results in an empty string.
+
+  > **Warning:** It is not recommended to use build-time variables for
+  >  passing secrets like github keys, user credentials etc. Build-time variable
+  >  values are visible to any user of the image with the `podman history` command.
+
+  You can use an `ARG` or an `ENV` instruction to specify variables that are
+  available to the `RUN` instruction. Environment variables defined using the
+  `ENV` instruction always override an `ARG` instruction of the same name. Consider
+  this Containerfile with an `ENV` and `ARG` instruction.
+
+  ```
+  1 FROM ubuntu
+  2 ARG CONT_IMG_VER
+  3 ENV CONT_IMG_VER=v1.0.0
+  4 RUN echo $CONT_IMG_VER
+  ```
+  Then, assume this image is built with this command:
+
+  ```
+  $ podman build --build-arg CONT_IMG_VER=v2.0.1 Containerfile
+  ```
+
+  In this case, the `RUN` instruction uses `v1.0.0` instead of the `ARG` setting
+  passed by the user:`v2.0.1` This behavior is similar to a shell
+  script where a locally scoped variable overrides the variables passed as
+  arguments or inherited from environment, from its point of definition.
+
+  Using the example above but a different `ENV` specification you can create more
+  useful interactions between `ARG` and `ENV` instructions:
+
+  ```
+  1 FROM ubuntu
+  2 ARG CONT_IMG_VER
+  3 ENV CONT_IMG_VER=${CONT_IMG_VER:-v1.0.0}
+  4 RUN echo $CONT_IMG_VER
+  ```
+
+  Unlike an `ARG` instruction, `ENV` values are always persisted in the built
+  image. Consider a `podman build` without the --build-arg flag:
+
+  ```
+  $ podman build Containerfile
+  ```
+
+  Using this Containerfile example, `CONT_IMG_VER` is still persisted in the image but
+  its value would be `v1.0.0` as it is the default set in line 3 by the `ENV` instruction.
+
+  The variable expansion technique in this example allows you to pass arguments
+  from the command line and persist them in the final image by leveraging the
+  `ENV` instruction. Variable expansion is only supported for [a limited set of
+  Containerfile instructions.](#environment-replacement)
+
+  Container engines have a set of predefined `ARG` variables that you can use without a
+  corresponding `ARG` instruction in the Containerfile.
+
+  * `HTTP_PROXY`
+  * `http_proxy`
+  * `HTTPS_PROXY`
+  * `https_proxy`
+  * `FTP_PROXY`
+  * `ftp_proxy`
+  * `NO_PROXY`
+  * `no_proxy`
+  * `ALL_PROXY`
+  * `all_proxy`
+
+  To use these, pass them on the command line using `--build-arg` flag, for
+  example:
+
+  ```
+  $ podman build --build-arg HTTPS_PROXY=https://my-proxy.example.com .
+  ```
+
+**ONBUILD**
+  -- `ONBUILD [INSTRUCTION]`
+  The **ONBUILD** instruction adds a trigger instruction to an image. The
+  trigger is executed at a later time, when the image is used as the base for
+  another build. Container engines execute the trigger in the context of the downstream
+  build, as if the trigger existed immediately after the **FROM** instruction in
+  the downstream Containerfile.
+
+  You can register any build instruction as a trigger. A trigger is useful if
+  you are defining an image to use as a base for building other images. For
+  example, if you are defining an application build environment or a daemon that
+  is customized with a user-specific configuration.
+
+  Consider an image intended as a reusable python application builder. It must
+  add application source code to a particular directory, and might need a build
+  script called after that. You can't just call **ADD** and **RUN** now, because
+  you don't yet have access to the application source code, and it is different
+  for each application build.
+
+  -- Providing application developers with a boilerplate Containerfile to copy-paste
+  into their application is inefficient, error-prone, and
+  difficult to update because it mixes with application-specific code.
+  The solution is to use **ONBUILD** to register instructions in advance, to
+  run later, during the next build stage.
+
+## SEE ALSO
+buildah(1), podman(1), docker(1)
+
+# HISTORY
+```
+May 2014, Compiled by Zac Dover (zdover at redhat dot com) based on docker.com Dockerfile documentation.
+Feb 2015, updated by Brian Goff (cpuguy83@gmail.com) for readability
+Sept 2015, updated by Sally O'Malley (somalley@redhat.com)
+Oct 2016, updated by Addam Hardy (addam.hardy@gmail.com)
+Aug 2021, converted Dockerfile man page to Containerfile by Dan Walsh (dwalsh@redhat.com)
+```

SOURCES/RPM-GPG-KEY-redhat-release

@@ -0,0 +1,34 @@
+pub   4096R/FD431D51 2009-10-22
+      Key fingerprint = 567E 347A D004 4ADE 55BA  8A5F 199E 2F91 FD43 1D51
+uid                  Red Hat, Inc. (release key 2) <security@redhat.com>
+
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Version: GnuPG v1.4.5 (GNU/Linux)
+
+mQINBErgSTsBEACh2A4b0O9t+vzC9VrVtL1AKvUWi9OPCjkvR7Xd8DtJxeeMZ5eF
+0HtzIG58qDRybwUe89FZprB1ffuUKzdE+HcL3FbNWSSOXVjZIersdXyH3NvnLLLF
+0DNRB2ix3bXG9Rh/RXpFsNxDp2CEMdUvbYCzE79K1EnUTVh1L0Of023FtPSZXX0c
+u7Pb5DI5lX5YeoXO6RoodrIGYJsVBQWnrWw4xNTconUfNPk0EGZtEnzvH2zyPoJh
+XGF+Ncu9XwbalnYde10OCvSWAZ5zTCpoLMTvQjWpbCdWXJzCm6G+/hx9upke546H
+5IjtYm4dTIVTnc3wvDiODgBKRzOl9rEOCIgOuGtDxRxcQkjrC+xvg5Vkqn7vBUyW
+9pHedOU+PoF3DGOM+dqv+eNKBvh9YF9ugFAQBkcG7viZgvGEMGGUpzNgN7XnS1gj
+/DPo9mZESOYnKceve2tIC87p2hqjrxOHuI7fkZYeNIcAoa83rBltFXaBDYhWAKS1
+PcXS1/7JzP0ky7d0L6Xbu/If5kqWQpKwUInXtySRkuraVfuK3Bpa+X1XecWi24JY
+HVtlNX025xx1ewVzGNCTlWn1skQN2OOoQTV4C8/qFpTW6DTWYurd4+fE0OJFJZQF
+buhfXYwmRlVOgN5i77NTIJZJQfYFj38c/Iv5vZBPokO6mffrOTv3MHWVgQARAQAB
+tDNSZWQgSGF0LCBJbmMuIChyZWxlYXNlIGtleSAyKSA8c2VjdXJpdHlAcmVkaGF0
+LmNvbT6JAjYEEwECACAFAkrgSTsCGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAK
+CRAZni+R/UMdUWzpD/9s5SFR/ZF3yjY5VLUFLMXIKUztNN3oc45fyLdTI3+UClKC
+2tEruzYjqNHhqAEXa2sN1fMrsuKec61Ll2NfvJjkLKDvgVIh7kM7aslNYVOP6BTf
+C/JJ7/ufz3UZmyViH/WDl+AYdgk3JqCIO5w5ryrC9IyBzYv2m0HqYbWfphY3uHw5
+un3ndLJcu8+BGP5F+ONQEGl+DRH58Il9Jp3HwbRa7dvkPgEhfFR+1hI+Btta2C7E
+0/2NKzCxZw7Lx3PBRcU92YKyaEihfy/aQKZCAuyfKiMvsmzs+4poIX7I9NQCJpyE
+IGfINoZ7VxqHwRn/d5mw2MZTJjbzSf+Um9YJyA0iEEyD6qjriWQRbuxpQXmlAJbh
+8okZ4gbVFv1F8MzK+4R8VvWJ0XxgtikSo72fHjwha7MAjqFnOq6eo6fEC/75g3NL
+Ght5VdpGuHk0vbdENHMC8wS99e5qXGNDued3hlTavDMlEAHl34q2H9nakTGRF5Ki
+JUfNh3DVRGhg8cMIti21njiRh7gyFI2OccATY7bBSr79JhuNwelHuxLrCFpY7V25
+OFktl15jZJaMxuQBqYdBgSay2G0U6D1+7VsWufpzd/Abx1/c3oi9ZaJvW22kAggq
+dzdA27UUYjWvx42w9menJwh/0jeQcTecIUd0d0rFcw/c1pvgMMl/Q73yzKgKYw==
+=zbHE
+-----END PGP PUBLIC KEY BLOCK-----
+

SOURCES/containerignore.5.md

@@ -0,0 +1,87 @@
+% ".containerignore" "28" "Sep 2021" "" "Container User Manuals"
+
+# NAME
+
+.containerignore(.dockerignore) - files to ignore buildah or podman build context directory
+
+# INTRODUCTION
+
+Before container engines build an image, they look for a file named .containerignore or .dockerignore in the root
+context directory. If one of these file exists, the CLI modifies the context to exclude files and
+directories that match patterns specified in the file. This avoids adding them to images using the ADD or COPY
+instruction.
+
+The CLI interprets the .containerignore or .dockerignore file as a newline-separated list of patterns similar to
+the file globs of Unix shells. For the purposes of matching, the root of the context is considered to be both the
+working and the root directory. For example, the patterns /foo/bar and foo/bar both exclude a file or directory
+named bar in the foo subdirectory of PATH or in the root of the git repository located at URL. Neither excludes
+anything else.
+
+If a line in .containerignore or .dockerignore file starts with # in column 1, then this line is considered as a
+comment and is ignored before interpreted by the CLI.
+
+# EXAMPLES
+
+Here is an example .containerignore file:
+
+```
+# comment
+*/temp*
+*/*/temp*
+temp?
+```
+
+This file causes the following build behavior:
+Rule 	Behavior
+```
+# comment 	Ignored.
+*/temp* 	Exclude files and directories whose names start with temp in any immediate subdirectory of the root.
+For example, the plain file /somedir/temporary.txt is excluded, as is the directory /somedir/temp.
+*/*/temp* 	Exclude files and directories starting with temp from any subdirectory that is two levels below the
+root. For example, /somedir/subdir/temporary.txt is excluded.
+temp? 	Exclude files and directories in the root directory whose names are a one-character extension of temp. For example, /tempa and /tempb are excluded.
+```
+Matching is done using Go’s filepath.Match rules. A preprocessing step removes leading and trailing whitespace and
+eliminates . and .. elements using Go’s filepath.Clean. Lines that are blank after preprocessing are ignored.
+
+Beyond Go’s filepath.Match rules, Docker also supports a special wildcard string ** that matches any number of
+directories (including zero). For example, **/*.go will exclude all files that end with .go that are found in all
+directories, including the root of the build context.
+
+Lines starting with ! (exclamation mark) can be used to make exceptions to exclusions. The following is an example .containerignore file that uses this mechanism:
+```
+*.md
+!README.md
+```
+All markdown files except README.md are excluded from the context.
+
+The placement of ! exception rules influences the behavior: the last line of the .containerignore that matches a
+particular file determines whether it is included or excluded. Consider the following example:
+```
+*.md
+!README*.md
+README-secret.md
+```
+No markdown files are included in the context except README files other than README-secret.md.
+
+Now consider this example:
+```
+*.md
+README-secret.md
+!README*.md
+```
+All of the README files are included. The middle line has no effect because !README*.md matches README-secret.md and
+comes last.
+
+You can even use the .containerignore file to exclude the Containerfile or Dockerfile and .containerignore files.
+These files are still sent to the daemon because it needs them to do its job. But the ADD and COPY instructions do
+not copy them to the image.
+
+Finally, you may want to specify which files to include in the context, rather than which to exclude. To achieve
+this, specify * as the first pattern, followed by one or more ! exception patterns.
+
+## SEE ALSO
+buildah-build(1), podman-build(1), docker-build(1)
+
+# HISTORY
+*Sep 2021, Compiled by Dan Walsh (dwalsh at redhat dot com) based on docker.com .dockerignore documentation.

SOURCES/containers-auth.json.5.md

@@ -0,0 +1,104 @@
+% containers-auth.json 5
+
+# NAME
+containers-auth.json - syntax for the registry authentication file
+
+# DESCRIPTION
+
+A credentials file in JSON format used to authenticate against container image registries.
+The primary (read/write) file is stored at `${XDG_RUNTIME_DIR}/containers/auth.json` on Linux;
+on Windows and macOS, at `$HOME/.config/containers/auth.json`.
+
+When searching for the credential for a registry, the following files will be read in sequence until the valid credential is found:
+first reading the primary (read/write) file, or the explicit override using an option of the calling application.
+If credentials are not present, search in `${XDG_CONFIG_HOME}/containers/auth.json` (usually `~/.config/containers/auth.json`), `$HOME/.docker/config.json`, `$HOME/.dockercfg`.
+
+Except the primary (read/write) file, other files are read-only, unless the user use an option of the calling application explicitly points at it as an override.
+
+
+## FORMAT
+
+The auth.json file stores encrypted authentication information for the
+user to container image registries.  The file can have zero to many entries and
+is created by a `login` command from a container tool such as `podman login`,
+`buildah login` or `skopeo login`. Each entry either contains a single
+hostname (e.g. `docker.io`) or a namespace (e.g. `quay.io/user/image`) as a key
+and an auth token in the form of a base64 encoded string as value of `auth`. The
+token is built from the concatenation of the username, a colon, and the
+password. The registry name can additionally contain a repository name (an image
+name without tag or digest) and namespaces. The path (or namespace) is matched
+in its hierarchical order when checking for available authentications. For
+example, an image pull for `my-registry.local/namespace/user/image:latest` will
+result in a lookup in `auth.json` in the following order:
+
+- `my-registry.local/namespace/user/image`
+- `my-registry.local/namespace/user`
+- `my-registry.local/namespace`
+- `my-registry.local`
+
+This way it is possible to setup multiple credentials for a single registry
+which can be distinguished by their path.
+
+The following example shows the values found in auth.json after the user logged in to
+their accounts on quay.io and docker.io:
+
+```
+{
+	"auths": {
+		"docker.io": {
+			"auth": "erfi7sYi89234xJUqaqxgmzcnQ2rRFWM5aJX0EC="
+		},
+		"quay.io": {
+			"auth": "juQAqGmz5eR1ipzx8Evn6KGdw8fEa1w5MWczmgY="
+		}
+	}
+}
+```
+
+This example demonstrates how to use multiple paths for a single registry, while
+preserving a fallback for `my-registry.local`:
+
+```
+{
+	"auths": {
+		"my-registry.local/foo/bar/image": {
+			"auth": "…"
+		},
+		"my-registry.local/foo": {
+			"auth": "…"
+		},
+		"my-registry.local": {
+			"auth": "…"
+		},
+	}
+}
+```
+
+An entry can be removed by using a `logout` command from a container
+tool such as `podman logout` or `buildah logout`.
+
+In addition, credential helpers can be configured for specific registries and the credentials-helper
+software can be used to manage the credentials in a more secure way than depending on the base64 encoded authentication
+provided by `login`.  If the credential helpers are configured for specific registries, the base64 encoded authentication will not be used
+for operations concerning credentials of the specified registries.
+
+When the credential helper is in use on a Linux platform, the auth.json file would contain keys that specify the registry domain, and values that specify the suffix of the program to use (i.e. everything after docker-credential-).  For example:
+
+```
+{
+    "auths": {
+        "localhost:5001": {}
+    },
+    "credHelpers": {
+		"registry.example.com": "secretservice"
+	}
+}
+```
+
+For more information on credential helpers, please reference the [GitHub docker-credential-helpers project](https://github.com/docker/docker-credential-helpers/releases).
+
+# SEE ALSO
+    buildah-login(1), buildah-logout(1), podman-login(1), podman-logout(1), skopeo-login(1), skopeo-logout(1)
+
+# HISTORY
+Feb 2020, Originally compiled by Tom Sweeney <tsweeney@redhat.com>

SOURCES/containers-certs.d.5.md

@@ -0,0 +1,28 @@
+% containers-certs.d 5 Directory for storing custom container-registry TLS configurations
+
+# 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 `$HOME/.config/containers/certs.d` or `/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 exemplary 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>

SOURCES/containers-mounts.conf.5.md

@@ -0,0 +1,16 @@
+% containers-mounts.conf(5)
+
+## NAME
+containers-mounts.conf - configuration file for default mounts in containers
+
+## DESCRIPTION
+The mounts.conf file specifies volume mount directories that are automatically mounted inside containers. Container processes can then use this content. Usually these directories are used for passing secrets or credentials required by the package software to access remote package repositories. Note that for security reasons, tools adhering to the mounts.conf are expected to copy the contents instead of bind mounting the paths from the host.
+
+## FORMAT
+The format of the mounts.conf is the volume format `/SRC:/DEST`, one mount per line. For example, a mounts.conf with the line `/usr/share/secrets:/run/secrets` would cause the contents of the `/usr/share/secrets` directory on the host to be mounted on the `/run/secrets` directory inside the container. Setting mountpoints allows containers to use the files of the host, for instance, to use the host's subscription to some enterprise Linux distribution.
+
+## FILES
+Some distributions may provide a `/usr/share/containers/mounts.conf` file to provide default mounts, but users can create a `/etc/containers/mounts.conf`, to specify their own special volumes to mount in the container. When Podman runs in rootless mode, the file `$HOME/.config/containers/mounts.conf` will override the default if it exists.
+
+## HISTORY
+Aug 2018, Originally compiled by Valentin Rothberg <vrothberg@suse.com>

SOURCES/containers-policy.json.5.md

@@ -0,0 +1,421 @@
+% CONTAINERS-POLICY.JSON 5 policy.json Man Page
+% Miloslav Trmač
+% September 2016
+
+# NAME
+containers-policy.json - syntax for the signature verification policy file
+
+## DESCRIPTION
+
+Signature verification policy files are used to specify policy, e.g. trusted keys,
+applicable when deciding whether to accept an image, or individual signatures of that image, as valid.
+
+By default, the policy is read from `$HOME/.config/containers/policy.json`, if it exists, otherwise from `/etc/containers/policy.json`;  applications performing verification may allow using a different policy instead.
+
+## FORMAT
+
+The signature verification policy file, usually called `policy.json`,
+uses a JSON format.  Unlike some other JSON files, its parsing is fairly strict:
+unrecognized, duplicated or otherwise invalid fields cause the entire file,
+and usually the entire operation, to be rejected.
+
+The purpose of the policy file is to define a set of *policy requirements* for a container image,
+usually depending on its location (where it is being pulled from) or otherwise defined identity.
+
+Policy requirements can be defined for:
+
+- An individual *scope* in a *transport*.
+  The *transport* values are the same as the transport prefixes when pushing/pulling images (e.g. `docker:`, `atomic:`),
+  and *scope* values are defined by each transport; see below for more details.
+
+  Usually, a scope can be defined to match a single image, and various prefixes of
+  such a most specific scope define namespaces of matching images.
+
+- A default policy for a single transport, expressed using an empty string as a scope
+
+- A global default policy.
+
+If multiple policy requirements match a given image, only the requirements from the most specific match apply,
+the more general policy requirements definitions are ignored.
+
+This is expressed in JSON using the top-level syntax
+```js
+{
+    "default": [/* policy requirements: global default */]
+    "transports": {
+        transport_name: {
+            "": [/* policy requirements: default for transport $transport_name */],
+            scope_1: [/* policy requirements: default for $scope_1 in $transport_name */],
+            scope_2: [/*…*/]
+            /*…*/
+        },
+        transport_name_2: {/*…*/}
+        /*…*/
+    }
+}
+```
+
+The global `default` set of policy requirements is mandatory; all of the other fields
+(`transports` itself, any specific transport, the transport-specific default, etc.) are optional.
+
+<!-- NOTE: Keep this in sync with transports/transports.go! -->
+## Supported transports and their scopes
+
+### `atomic:`
+
+The `atomic:` transport refers to images in an Atomic Registry.
+
+Supported scopes use the form _hostname_[`:`_port_][`/`_namespace_[`/`_imagestream_ [`:`_tag_]]],
+i.e. either specifying a complete name of a tagged image, or prefix denoting
+a host/namespace/image stream or a wildcarded expression for matching all
+subdomains. For wildcarded subdomain matching, `*.example.com` is a valid case, but `example*.*.com` is not.
+
+*Note:* The _hostname_ and _port_ refer to the container registry host and port (the one used
+e.g. for `docker pull`), _not_ to the OpenShift API host and port.
+
+### `dir:`
+
+The `dir:` transport refers to images stored in local directories.
+
+Supported scopes are paths of directories (either containing a single image or
+subdirectories possibly containing images).
+
+*Note:* The paths must be absolute and contain no symlinks. Paths violating these requirements may be silently ignored.
+
+The top-level scope `"/"` is forbidden; use the transport default scope `""`,
+for consistency with other transports.
+
+### `docker:`
+
+The `docker:` transport refers to images in a registry implementing the "Docker Registry HTTP API V2".
+
+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 (by only specifying the host name)
+or a wildcarded expression for matching all subdomains. For wildcarded subdomain
+matching, `*.example.com` is a valid case, but `example*.*.com` is not.
+
+### `oci:`
+
+The `oci:` transport refers to images in directories compliant with "Open Container Image Layout Specification".
+
+Supported scopes use the form _directory_`:`_tag_, and _directory_ referring to
+a directory containing one or more tags, or any of the parent directories.
+
+*Note:* See `dir:` above for semantics and restrictions on the directory paths, they apply to `oci:` equivalently.
+
+### `tarball:`
+
+The `tarball:` transport refers to tarred up container root filesystems.
+
+Scopes are ignored.
+
+## Policy Requirements
+
+Using the mechanisms above, a set of policy requirements is looked up.  The policy requirements
+are represented as a JSON array of individual requirement objects.  For an image to be accepted,
+*all* of the requirements must be satisfied simultaneously.
+
+The policy requirements can also be used to decide whether an individual signature is accepted (= is signed by a recognized key of a known author);
+in that case some requirements may apply only to some signatures, but each signature must be accepted by *at least one* requirement object.
+
+The following requirement objects are supported:
+
+### `insecureAcceptAnything`
+
+A simple requirement with the following syntax
+
+```json
+{"type":"insecureAcceptAnything"}
+```
+
+This requirement accepts any image (but note that other requirements in the array still apply).
+
+When deciding to accept an individual signature, this requirement does not have any effect; it does *not* cause the signature to be accepted, though.
+
+This is useful primarily for policy scopes where no signature verification is required;
+because the array of policy requirements must not be empty, this requirement is used
+to represent the lack of requirements explicitly.
+
+### `reject`
+
+A simple requirement with the following syntax:
+
+```json
+{"type":"reject"}
+```
+
+This requirement rejects every image, and every signature.
+
+### `signedBy`
+
+This requirement requires an image to be signed using “simple signing” with an expected identity, or accepts a signature if it is using an expected identity and key.
+
+```js
+{
+    "type":    "signedBy",
+    "keyType": "GPGKeys", /* The only currently supported value */
+    "keyPath": "/path/to/local/keyring/file",
+    "keyPaths": ["/path/to/local/keyring/file1","/path/to/local/keyring/file2"…],
+    "keyData": "base64-encoded-keyring-data",
+    "signedIdentity": identity_requirement
+}
+```
+<!-- Later: other keyType values -->
+
+Exactly one of `keyPath`, `keyPaths` and `keyData` must be present, containing a GPG keyring of one or more public keys.  Only signatures made by these keys are accepted.
+
+The `signedIdentity` field, a JSON object, specifies what image identity the signature claims about the image.
+One of the following alternatives are supported:
+
+- The identity in the signature must exactly match the image identity.  Note that with this, referencing an image by digest (with a signature claiming a _repository_`:`_tag_ identity) will fail.
+
+  ```json
+  {"type":"matchExact"}
+  ```
+- If the image identity carries a tag, the identity in the signature must exactly match;
+  if the image identity uses a digest reference, the identity in the signature must be in the same repository as the image identity (using any tag).
+
+  (Note that with images identified using digest references, the digest from the reference is validated even before signature verification starts.)
+
+  ```json
+  {"type":"matchRepoDigestOrExact"}
+  ```
+- The identity in the signature must be in the same repository as the image identity.  This is useful e.g. to pull an image using the `:latest` tag when the image is signed with a tag specifying an exact image version.
+
+  ```json
+  {"type":"matchRepository"}
+  ```
+- The identity in the signature must exactly match a specified identity.
+  This is useful e.g. when locally mirroring images signed using their public identity.
+
+  ```js
+  {
+      "type": "exactReference",
+      "dockerReference": docker_reference_value
+  }
+  ```
+- The identity in the signature must be in the same repository as a specified identity.
+  This combines the properties of `matchRepository` and `exactReference`.
+
+  ```js
+  {
+      "type": "exactRepository",
+      "dockerRepository": docker_repository_value
+  }
+  ```
+- Prefix remapping:
+
+  If the image identity matches the specified prefix, that prefix is replaced by the specified “signed prefix”
+  (otherwise it is used as unchanged and no remapping takes place);
+  matching then follows the `matchRepoDigestOrExact` semantics documented above
+  (i.e. if the image identity carries a tag, the identity in the signature must exactly match,
+  if it uses a digest reference, the repository must match).
+
+  The `prefix` and `signedPrefix` values can be either host[:port] values
+  (matching exactly the same host[:port], string),
+  repository namespaces, or repositories (i.e. they must not contain tags/digests),
+  and match as prefixes *of the fully expanded form*.
+  For example, `docker.io/library/busybox` (*not* `busybox`) to specify that single repository,
+  or `docker.io/library` (not an empty string) to specify the parent namespace of `docker.io/library/busybox`==`busybox`).
+
+  The `prefix` value is usually the same as the scope containing the parent `signedBy` requirement.
+
+  ```js
+  {
+      "type": "remapIdentity",
+      "prefix": prefix,
+      "signedPrefix": prefix,
+  }
+  ```
+
+If the `signedIdentity` field is missing, it is treated as `matchRepoDigestOrExact`.
+
+*Note*: `matchExact`, `matchRepoDigestOrExact` and `matchRepository` can be only used if a Docker-like image identity is
+provided by the transport.  In particular, the `dir:` and `oci:` transports can be only
+used with `exactReference` or `exactRepository`.
+
+<!-- ### `signedBaseLayer` -->
+
+
+### `sigstoreSigned`
+
+This requirement requires an image to be signed using a sigstore signature with an expected identity and key.
+
+```js
+{
+    "type":    "sigstoreSigned",
+    "keyPath": "/path/to/local/public/key/file",
+    "keyData": "base64-encoded-public-key-data",
+    "fulcio": {
+        "caPath": "/path/to/local/CA/file",
+        "caData": "base64-encoded-CA-data",
+        "oidcIssuer": "https://expected.OIDC.issuer/",
+        "subjectEmail", "expected-signing-user@example.com",
+    },
+    "rekorPublicKeyPath": "/path/to/local/public/key/file",
+    "rekorPublicKeyData": "base64-encoded-public-key-data",
+    "signedIdentity": identity_requirement
+}
+```
+Exactly one of `keyPath`, `keyData` and `fulcio` must be present.
+
+If `keyPath` or `keyData` is present, it contains a sigstore public key.
+Only signatures made by this key are accepted.
+
+If `fulcio` is present, the signature must be based on a Fulcio-issued certificate.
+One of `caPath` and `caData` must be specified, containing the public key of the Fulcio instance.
+Both `oidcIssuer` and `subjectEmail` are mandatory,
+exactly specifying the expected identity provider,
+and the identity of the user obtaining the Fulcio certificate.
+
+At most one of `rekorPublicKeyPath` and `rekorPublicKeyData` can be present;
+it is mandatory if `fulcio` is specified.
+If a Rekor public key is specified,
+the signature must have been uploaded to a Rekor server
+and the signature must contain an (offline-verifiable) “signed entry timestamp”
+proving the existence of the Rekor log record,
+signed by the provided public key.
+
+The `signedIdentity` field has the same semantics as in the `signedBy` requirement described above.
+Note that `cosign`-created signatures only contain a repository, so only `matchRepository` and `exactRepository` can be used to accept them (and that does not protect against substitution of a signed image with an unexpected tag).
+
+To use this with images hosted on image registries, the relevant registry or repository must have the `use-sigstore-attachments` option enabled in containers-registries.d(5).
+
+## Examples
+
+It is *strongly* recommended to set the `default` policy to `reject`, and then
+selectively allow individual transports and scopes as desired.
+
+### A reasonably locked-down system
+
+(Note that the `/*`…`*/` comments are not valid in JSON, and must not be used in real policies.)
+
+```js
+{
+    "default": [{"type": "reject"}], /* Reject anything not explicitly allowed */
+    "transports": {
+        "docker": {
+            /* Allow installing images from a specific repository namespace, without cryptographic verification.
+               This namespace includes images like openshift/hello-openshift and openshift/origin. */
+            "docker.io/openshift": [{"type": "insecureAcceptAnything"}],
+            /* Similarly, allow installing the “official” busybox images.  Note how the fully expanded
+               form, with the explicit /library/, must be used. */
+            "docker.io/library/busybox": [{"type": "insecureAcceptAnything"}],
+            /* Allow installing images from all subdomains */
+            "*.temporary-project.example.com": [{"type": "insecureAcceptAnything"}],
+            /* A sigstore-signed repository */
+            "hostname:5000/myns/sigstore-signed-with-full-references": [
+                {
+                    "type": "sigstoreSigned",
+                    "keyPath": "/path/to/sigstore-pubkey.pub"
+                }
+            ],
+            /* A sigstore-signed repository using the community Fulcio+Rekor servers.
+
+               The community servers’ public keys can be obtained from
+               https://github.com/sigstore/sigstore/tree/main/pkg/tuf/repository/targets .  */
+            "hostname:5000/myns/sigstore-signed-fulcio-rekor": [
+                {
+                    "type": "sigstoreSigned",
+                    "fulcio": {
+                        "caPath": "/path/to/fulcio_v1.crt.pem",
+                        "oidcIssuer": "https://github.com/login/oauth",
+                        "subjectEmail": "test-user@example.com"
+                    },
+                    "rekorPublicKeyPath": "/path/to/rekor.pub",
+                }
+            ],
+            /* A sigstore-signed repository, accepts signatures by /usr/bin/cosign */
+            "hostname:5000/myns/sigstore-signed-allows-malicious-tag-substitution": [
+                {
+                    "type": "sigstoreSigned",
+                    "keyPath": "/path/to/sigstore-pubkey.pub",
+                    "signedIdentity": {"type": "matchRepository"}
+                }
+            ],
+            /* A sigstore-signed repository using the community Fulcio+Rekor servers,
+               accepts signatures by /usr/bin/cosign.
+
+               The community servers’ public keys can be obtained from
+               https://github.com/sigstore/sigstore/tree/main/pkg/tuf/repository/targets .  */
+            "hostname:5000/myns/sigstore-signed-fulcio-rekor- allows-malicious-tag-substitution": [
+                {
+                    "type": "sigstoreSigned",
+                    "fulcio": {
+                        "caPath": "/path/to/fulcio_v1.crt.pem",
+                        "oidcIssuer": "https://github.com/login/oauth",
+                        "subjectEmail": "test-user@example.com"
+                    },
+                    "rekorPublicKeyPath": "/path/to/rekor.pub",
+                    "signedIdentity": { "type": "matchRepository" }
+                }
+            ]
+              /* Other docker: images use the global default policy and are rejected */
+        },
+        "dir": {
+            "": [{"type": "insecureAcceptAnything"}] /* Allow any images originating in local directories */
+        },
+        "atomic": {
+            /* The common case: using a known key for a repository or set of repositories */
+            "hostname:5000/myns/official": [
+                {
+                    "type": "signedBy",
+                    "keyType": "GPGKeys",
+                    "keyPath": "/path/to/official-pubkey.gpg"
+                }
+            ],
+            /* A more complex example, for a repository which contains a mirror of a third-party product,
+               which must be signed-off by local IT */
+            "hostname:5000/vendor/product": [
+                { /* Require the image to be signed by the original vendor, using the vendor's repository location. */
+                    "type": "signedBy",
+                    "keyType": "GPGKeys",
+                    "keyPath": "/path/to/vendor-pubkey.gpg",
+                    "signedIdentity": {
+                        "type": "exactRepository",
+                        "dockerRepository": "vendor-hostname/product/repository"
+                    }
+                },
+                { /* Require the image to _also_ be signed by a local reviewer. */
+                    "type": "signedBy",
+                    "keyType": "GPGKeys",
+                    "keyPath": "/path/to/reviewer-pubkey.gpg"
+                }
+            ],
+            /* A way to mirror many repositories from a single vendor */
+            "private-mirror:5000/vendor-mirror": [
+                { /* Require the image to be signed by the original vendor, using the vendor's repository location.
+                     For example, private-mirror:5000/vendor-mirror/productA/image1:latest needs to be signed as
+                     vendor.example/productA/image1:latest . */
+                    "type": "signedBy",
+                    "keyType": "GPGKeys",
+                    "keyPath": "/path/to/vendor-pubkey.gpg",
+                    "signedIdentity": {
+                        "type": "remapIdentity",
+                        "prefix": "private-mirror:5000/vendor-mirror",
+                        "signedPrefix": "vendor.example.com"
+                    }
+                }
+            ]
+        }
+    }
+}
+```
+
+### Completely disable security, allow all images, do not trust any signatures
+
+```json
+{
+    "default": [{"type": "insecureAcceptAnything"}]
+}
+```
+## SEE ALSO
+  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>

SOURCES/containers-registries.conf.5.md

@@ -0,0 +1,322 @@
+% CONTAINERS-REGISTRIES.CONF 5 System-wide registry configuration file
+% Brent Baude
+% Aug 2017
+
+# NAME
+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.
+
+Container engines will use the `$HOME/.config/containers/registries.conf` if it exists, otherwise they will use `/etc/containers/registries.conf`
+
+### GLOBAL SETTINGS
+
+`unqualified-search-registries`
+: An array of _host_[`:`_port_] registries to try when pulling an unqualified image, in order.
+
+`credential-helpers`
+: An array of default credential helpers used as external credential stores.  Note that "containers-auth.json" is a reserved value to use auth files as specified in containers-auth.json(5).  The credential helpers are set to `["containers-auth.json"]` if none are specified.
+
+### NAMESPACED `[[registry]]` SETTINGS
+
+The bulk of the configuration is represented as an array of `[[registry]]`
+TOML tables; the settings may therefore differ among different registries
+as well as among different namespaces/repositories within a registry.
+
+#### Choosing a `[[registry]]` TOML table
+
+Given an image name, a single `[[registry]]` TOML table is chosen based on its `prefix` field.
+
+`prefix`: A prefix of the user-specified image name, i.e. using one of the following formats:
+  - _host_[`:`_port_]
+  - _host_[`:`_port_]`/`_namespace_[`/`_namespace_…]
+  - _host_[`:`_port_]`/`_namespace_[`/`_namespace_…]`/`_repo_
+  - _host_[`:`_port_]`/`_namespace_[`/`_namespace_…]`/`_repo_(`:`_tag|`@`_digest_)
+  - [`*.`]_host_
+
+The user-specified image name must start with the specified `prefix` (and continue
+with the appropriate separator) for a particular `[[registry]]` TOML table to be
+considered; (only) the TOML table with the longest match is used. It can
+also include wildcarded subdomains in the format `*.example.com`.
+The wildcard should only be present at the beginning as shown in the formats
+above. Other cases will not work. For example, `*.example.com` is valid but
+`example.*.com`, `*.example.com/foo` and `*.example.com:5000/foo/bar:baz` are not.
+Note that `*` matches an arbitrary number of subdomains. `*.example.com` will hence
+match `bar.example.com`, `foo.bar.example.com` and so on.
+
+As a special case, the `prefix` field can be missing; if so, it defaults to the value
+of the `location` field (described below).
+
+#### Per-namespace settings
+
+`insecure`
+: `true` or `false`.
+By default, container runtimes require TLS when retrieving images from a registry.
+If `insecure` is set to `true`, unencrypted HTTP as well as TLS connections with untrusted
+certificates are allowed.
+
+`blocked`
+: `true` or `false`.
+If `true`, pulling images with matching names is forbidden.
+
+#### Remapping and mirroring registries
+
+The user-specified image reference is, primarily, a "logical" image name, always used for naming
+the image.  By default, the image reference also directly specifies the registry and repository
+to use, but the following options can be used to redirect the underlying accesses
+to different registry servers or locations (e.g. to support configurations with no access to the
+internet without having to change `Dockerfile`s, or to add redundancy).
+
+`location`
+: Accepts the same format as the `prefix` field, and specifies the physical location
+of the `prefix`-rooted namespace.
+
+By default, this equal to `prefix` (in which case `prefix` can be omitted and the
+`[[registry]]` TOML table can only specify `location`).
+
+Example: Given
+```
+prefix = "example.com/foo"
+location = "internal-registry-for-example.net/bar"
+```
+requests for the image `example.com/foo/myimage:latest` will actually work with the
+`internal-registry-for-example.net/bar/myimage:latest` image.
+
+With a `prefix` containing a wildcard in the format: "*.example.com" for subdomain matching,
+the location can be empty. In such a case,
+prefix matching will occur, but no reference rewrite will occur. The
+original requested image string will be used as-is. But other settings like
+`insecure` / `blocked` / `mirrors` will be applied to matching images.
+
+Example: Given
+```
+prefix = "*.example.com"
+```
+requests for the image `blah.example.com/foo/myimage:latest` will be used
+as-is. But other settings like insecure/blocked/mirrors will be applied to matching images
+
+`mirror`
+: An array of TOML tables specifying (possibly-partial) mirrors for the
+`prefix`-rooted namespace (i.e., the current `[[registry]]` TOML table).
+
+The mirrors are attempted in the specified order; the first one that can be
+contacted and contains the image will be used (and if none of the mirrors contains the image,
+the primary location specified by the `registry.location` field, or using the unmodified
+user-specified reference, is tried last).
+
+Each TOML table in the `mirror` array can contain the following fields:
+- `location`： same semantics
+as specified in the `[[registry]]` TOML table
+- `insecure`： same semantics
+as specified in the `[[registry]]` TOML table
+- `pull-from-mirror`: `all`, `digest-only` or `tag-only`.  If "digest-only"， mirrors will only be used for digest pulls. Pulling images by tag can potentially yield different images, depending on which endpoint we pull from.  Restricting mirrors to pulls by digest avoids that issue.  If "tag-only", mirrors will only be used for tag pulls.  For a more up-to-date and expensive mirror that it is less likely to be out of sync if tags move, it should not be unnecessarily used for digest references.  Default is "all" (or left empty), mirrors will be used for both digest pulls and tag pulls unless the mirror-by-digest-only is set for the primary registry.
+Note that this per-mirror setting is allowed only when `mirror-by-digest-only` is not configured for the primary registry.
+
+`mirror-by-digest-only`
+: `true` or `false`.
+If `true`, mirrors will only be used during pulling if the image reference includes a digest.
+Note that if all mirrors are configured to be digest-only, images referenced by a tag will only use the primary
+registry.
+If all mirrors are configured to be tag-only, images referenced by a digest will only use the primary
+registry.
+
+Referencing an image by digest ensures that the same is always used
+(whereas referencing an image by a tag may cause different registries to return
+different images if the tag mapping is out of sync).
+
+
+*Note*: Redirection and mirrors are currently processed only when reading images, not when pushing
+to a registry; that may change in the future.
+
+#### Short-Name Aliasing
+The use of unqualified-search registries entails an ambiguity as it is
+unclear from which registry a given image, referenced by a short name,
+may be pulled from.
+
+As mentioned in the note at the end of this man page, using short names is
+subject to the risk of hitting squatted registry namespaces.  If the
+unqualified-search registries are set to `["registry1.com", "registry2.com"]`
+an attacker may take over a namespace of registry1.com such that an image may
+be pulled from registry1.com instead of the intended source registry2.com.
+
+While it is highly recommended to always use fully-qualified image references,
+existing deployments using short names may not be easily changed.  To
+circumvent the aforementioned ambiguity, so called short-name aliases can be
+configured that point to a fully-qualified image
+reference.
+
+Short-name aliases can be configured in the `[aliases]` table in the form of
+`"name"="value"` with the left-hand `name` being the short name (e.g., "image")
+and the right-hand `value` being the fully-qualified image reference (e.g.,
+"registry.com/namespace/image").  Note that neither "name" nor "value" can
+include a tag or digest.  Moreover, "name" must be a short name and hence
+cannot include a registry domain or refer to localhost.
+
+When pulling a short name, the configured aliases table will be used for
+resolving the short name.  If a matching alias is found, it will be used
+without further consulting the unqualified-search registries list.  If no
+matching alias is found, the behavior can be controlled via the
+`short-name-mode` option as described below.
+
+Note that tags and digests are stripped off a user-specified short name for
+alias resolution.  Hence, "image", "image:tag" and "image@digest" all resolve
+to the same alias (i.e., "image").  Stripped off tags and digests are later
+appended to the resolved alias.
+
+Further note that drop-in configuration files (see containers-registries.conf.d(5))
+can override aliases in the specific loading order of the files.  If the "value" of
+an alias is empty (i.e., ""), the alias will be erased.  However, a given
+"name" may only be specified once in a single config file.
+
+
+#### Short-Name Aliasing: Modes
+
+The `short-name-mode` option supports three modes to control the behaviour of
+short-name resolution.
+
+* `enforcing`: If only one unqualified-search registry is set, use it as there
+  is no ambiguity.  If there is more than one registry and the user program is
+  running in a terminal (i.e., stdout & stdin are a TTY), prompt the user to
+  select one of the specified search registries.  If the program is not running
+  in a terminal, the ambiguity cannot be resolved which will lead to an error.
+
+* `permissive`: Behaves as enforcing but does not lead to an error if the
+  program is not running in a terminal.  Instead, fallback to using all
+  unqualified-search registries.
+
+* `disabled`: Use all unqualified-search registries without prompting.
+
+If `short-name-mode` is not specified at all or left empty, default to the
+`permissive` mode.  If the user-specified short name was not aliased already,
+the `enforcing` and `permissive` mode if prompted, will record a new alias
+after a successful pull.  Note that the recorded alias will be written to
+`/var/cache/containers/short-name-aliases.conf` for root to have a clear
+separation between possibly human-edited registries.conf files and the
+machine-generated `short-name-aliases-conf`.  Note that `$HOME/.cache` is used
+for rootless users.  If an alias is specified in a
+`registries.conf` file and also the machine-generated
+`short-name-aliases.conf`, the `short-name-aliases.conf` file has precedence.
+
+#### Normalization of docker.io references
+
+The Docker Hub `docker.io` is handled in a special way: every push and pull
+operation gets internally normalized with `/library` if no other specific
+namespace is defined (for example on `docker.io/namespace/image`).
+
+(Note that the above-described normalization happens to match the behavior of
+Docker.)
+
+This means that a pull of `docker.io/alpine` will be internally translated to
+`docker.io/library/alpine`. A pull of `docker.io/user/alpine` will not be
+rewritten because this is already the correct remote path.
+
+Therefore, to remap or mirror the `docker.io` images in the (implied) `/library`
+namespace (or that whole namespace), the prefix and location fields in this
+configuration file must explicitly include that `/library` namespace. For
+example `prefix = "docker.io/library/alpine"` and not `prefix =
+"docker.io/alpine"`. The latter would match the `docker.io/alpine/*`
+repositories but not the `docker.io/[library/]alpine` image).
+
+### EXAMPLE
+
+```
+unqualified-search-registries = ["example.com"]
+
+[[registry]]
+prefix = "example.com/foo"
+insecure = false
+blocked = false
+location = "internal-registry-for-example.com/bar"
+
+[[registry.mirror]]
+location = "example-mirror-0.local/mirror-for-foo"
+
+[[registry.mirror]]
+location = "example-mirror-1.local/mirrors/foo"
+insecure = true
+
+[[registry]]
+location = "registry.com"
+
+[[registry.mirror]]
+location = "mirror.registry.com"
+```
+Given the above, a pull of `example.com/foo/image:latest` will try:
+
+1. `example-mirror-0.local/mirror-for-foo/image:latest`
+2. `example-mirror-1.local/mirrors/foo/image:latest`
+3. `internal-registry-for-example.net/bar/image:latest`
+
+in order, and use the first one that exists.
+
+Note that a mirror is associated only with the current `[[registry]]` TOML table. If using the example above, pulling the image `registry.com/image:latest` will hence only reach out to `mirror.registry.com`, and the mirrors associated with `example.com/foo` will not be considered.
+
+## VERSION 1 FORMAT - DEPRECATED
+VERSION 1 format is still supported but it does not support
+using registry mirrors, longest-prefix matches, or location rewriting.
+
+The TOML format is used to build a simple list of registries under three
+categories: `registries.search`, `registries.insecure`, and `registries.block`.
+You can list multiple registries using a comma separated list.
+
+Search registries are used when the caller of a container runtime does not fully specify the
+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.
+
+Note that insecure registries can be used for any registry, not just the registries listed
+under search.
+
+The `registries.insecure` and `registries.block` lists have the same meaning as the
+`insecure` and `blocked` fields in the current version.
+
+### EXAMPLE
+The following example configuration defines two searchable registries, one
+insecure registry, and two blocked registries.
+
+```
+[registries.search]
+registries = ['registry1.com', 'registry2.com']
+
+[registries.insecure]
+registries = ['registry3.com']
+
+[registries.block]
+registries = ['registry.untrusted.com', 'registry.unsafe.com']
+```
+
+# NOTE: RISK OF USING UNQUALIFIED IMAGE NAMES
+We recommend always using fully qualified image names including the registry
+server (full dns name), namespace, image name, and tag
+(e.g., registry.redhat.io/ubi8/ubi:latest). When using short names, there is
+always an inherent risk that the image being pulled could be spoofed. For
+example, a user wants to pull an image named `foobar` from a registry and
+expects it to come from myregistry.com. If myregistry.com is not first in the
+search list, an attacker could place a different `foobar` image at a registry
+earlier in the search list. The user would accidentally pull and run the
+attacker's image and code rather than the intended content. We recommend only
+adding registries which are completely trusted, i.e. registries which don't
+allow unknown or anonymous users to create accounts with arbitrary names. This
+will prevent an image from being spoofed, squatted or otherwise made insecure.
+If it is necessary to use one of these registries, it should be added at the
+end of the list.
+
+It is recommended to use fully-qualified images for pulling as
+the destination registry is unambiguous. Pulling by digest
+(i.e., quay.io/repository/name@digest) further eliminates the ambiguity of
+tags.
+
+# SEE ALSO
+ containers-auth.json(5) containers-certs.d(5)
+
+# HISTORY
+Dec 2019, Warning added for unqualified image names by Tom Sweeney <tsweeney@redhat.com>
+
+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>
+
+Aug 2017, Originally compiled by Brent Baude <bbaude@redhat.com>

SOURCES/containers-registries.conf.d.5.md

@@ -0,0 +1,37 @@
+% CONTAINERS-REGISTRIES.CONF.D 5
+% Valentin Rothberg
+% Mar 2020
+
+# NAME
+containers-registries.conf.d - directory for drop-in registries.conf files
+
+# DESCRIPTION
+CONTAINERS-REGISTRIES.CONF.D is a system-wide directory for drop-in
+configuration files in the `containers-registries.conf(5)` format.
+
+By default, the directory is located at `/etc/containers/registries.conf.d`.
+
+# CONFIGURATION PRECEDENCE
+
+Once the main configuration at `/etc/containers/registries.conf` is loaded, the
+files in `/etc/containers/registries.conf.d` are loaded in alpha-numerical
+order. Then the conf files in `$HOME/.config/containers/registries.conf.d` are loaded in alpha-numerical order, if they exist. If the `$HOME/.config/containers/registries.conf` is loaded, only the conf files under `$HOME/.config/containers/registries.conf.d` are loaded in alpha-numerical order.
+Specified fields in a conf file will overwrite any previous setting.  Note
+that only files with the `.conf` suffix are loaded, other files and
+sub-directories are ignored.
+
+For instance, setting the `unqualified-search-registries` in
+`/etc/containers/registries.conf.d/myregistries.conf` will overwrite previous
+settings in `/etc/containers/registries.conf`.  The `[[registry]]` tables merged
+by overwriting existing items if the prefixes are identical while new ones are
+added.
+
+All drop-in configuration files must be specified in the version 2 of the
+`containers-registries.conf(5)` format.
+
+# SEE ALSO
+`containers-registries.conf(5)`
+
+# HISTORY
+
+Mar 2020, Originally compiled by Valentin Rothberg <rothberg@redhat.com>

SOURCES/containers-registries.d.5.md

@@ -0,0 +1,140 @@
+% 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, the registries configuration directory is `$HOME/.config/containers/registries.d` if it exists, otherwise `/etc/containers/registries.d` (unless overridden at compile-time);
+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 `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`).
+
+### Built-in Defaults
+
+If no `docker` section can be found for the container image, and no `default-docker` section is configured:
+
+- The default directory, `/var/lib/containers/sigstore` for root and `$HOME/.local/share/containers/sigstore` for unprivileged user,  will be used for reading and writing signatures.
+- Sigstore attachments will not be read/written.
+
+## 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` and `sigstore-staging` are deprecated and intentionally not documented here. -->
+
+- `lookaside-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, `lookaside` below is used.
+
+- `lookaside` defines an URL of the signature storage.
+   This URL is used for reading existing signatures,
+   and if `lookaside-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 `lookaside-staging` is defined).
+
+- `use-sigstore-attachments` specifies whether sigstore image attachments (signatures, attestations and the like) are going to be read/written along with the image.
+   If disabled, the images are treated as if no attachments exist; attempts to write attachments fail.
+
+## 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:
+        lookaside: https://lookaside.database-supplier.com
+    distribution.great-middleware.org:
+        lookaside: https://security-team.great-middleware.org/lookaside
+    docker.io/web-framework:
+        lookaside: https://lookaside.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 signature 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:
+        lookaside: https://registry-lookaside.example.com
+    registry.example.com/mydepartment:
+        lookaside: https://lookaside.mydepartment.example.com
+        lookaside-staging: file:///mnt/mydepartment/lookaside-staging
+    registry.example.com/mydepartment/myproject:mybranch:
+        lookaside: http://localhost:4242/lookaside
+        lookaside-staging: file:///home/useraccount/webroot/lookaside
+```
+
+### 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:
+    lookaside-staging: file:///mnt/company/common-lookaside-staging
+```
+
+# AUTHORS
+
+Miloslav Trmač <mitr@redhat.com>

SOURCES/containers-signature.5.md

@@ -0,0 +1,244 @@
+% container-signature 5 Container signature format
+% Miloslav Trmač
+% March 2017
+
+# NAME
+container-signature - Container signature format
+
+# DESCRIPTION
+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](containers-policy.json.5.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](containers-policy.json.5.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`](containers-policy.json.5.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
+(identifying the low-level software implementation; not the top-level caller).
+
+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 accommodate 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).

SOURCES/containers-storage.conf.5.md

@@ -0,0 +1,351 @@
+% containers-storage.conf(5) Container Storage Configuration File
+% Dan Walsh
+% May 2017
+
+# NAME
+storage.conf - Syntax of Container Storage configuration file
+
+## DESCRIPTION
+The STORAGE configuration file specifies all of the available container storage options for tools using shared container storage, but in a TOML format that can be more easily modified and versioned.
+
+## FORMAT
+The [TOML format][toml] is used as the encoding of the configuration file.
+Every option and subtable listed here is nested under a global "storage" table.
+No bare options are used. The format of TOML can be simplified to:
+
+    [table]
+    option = value
+
+    [table.subtable1]
+    option = value
+
+    [table.subtable2]
+    option = value
+
+## STORAGE TABLE
+
+The `storage` table supports the following options:
+
+**driver**=""
+  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.
+This field is required to guarantee proper operation.
+Valid rootless drivers are "btrfs", "overlay", and "vfs".
+Rootless users default to the driver defined in the system configuration when possible.
+When the system configuration uses an unsupported rootless driver, rootless users default to "overlay" if available, otherwise "vfs".
+
+**graphroot**=""
+  container storage graph dir (default: "/var/lib/containers/storage")
+Default directory to store all writable content created by container storage programs.
+The rootless graphroot path supports environment variable substitutions (ie. `$HOME/containers/storage`).
+When changing the graphroot location on an SELINUX system, ensure the labeling matches the default locations labels with the following commands:
+
+```
+# semanage fcontext -a -e /var/lib/containers/storage /NEWSTORAGEPATH
+# restorecon -R -v /NEWSTORAGEPATH
+```
+
+In rootless mode you would set
+
+```
+# semanage fcontext -a -e $HOME/.local/share/containers NEWSTORAGEPATH
+$ restorecon -R -v /NEWSTORAGEPATH
+```
+**rootless_storage_path**="$HOME/.local/share/containers/storage"
+  Storage path for rootless users. By default the graphroot for rootless users is set to `$XDG_DATA_HOME/containers/storage`, if XDG_DATA_HOME is set. Otherwise `$HOME/.local/share/containers/storage` is used. This field can be used if administrators need to change the storage location for all users. The rootless storage path supports environment variable substitutions (ie. `$HOME/containers/storage`)
+
+A common use case for this field is to provide a local storage directory when user home directories are NFS-mounted (podman does not support container storage over NFS).
+
+**runroot**=""
+  container storage run dir (default: "/run/containers/storage")
+Default directory to store all temporary writable content created by container storage programs. The rootless runroot path supports environment variable substitutions (ie. `$HOME/containers/storage`)
+
+**driver_priority**=[]
+  Priority list for the storage drivers that will be tested one after the other to pick the storage driver if it is not defined. The first storage driver in this list that can be used, will be picked as the new one and all subsequent ones will not be tried. If all drivers in this list are not viable, then **all** known drivers will be tried and the first working one will be picked.
+By default, the storage driver is set via the `driver` option. If it is not defined, then the best driver will be picked according to the current platform. This option allows you to override this internal priority list with a custom one to prefer certain drivers.
+Setting this option only has an effect if the local storage has not been initialized yet and the driver name is not set.
+
+### STORAGE OPTIONS TABLE
+
+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.
+
+**pull_options** = {enable_partial_images = "false", use_hard_links = "false", ostree_repos=""}
+
+Allows specification of how storage is populated when pulling images. This
+option can speed the pulling process of images compressed with format zstd:chunked. Containers/storage looks
+for files within images that are being pulled from a container registry that
+were previously pulled to the host.  It can copy or create
+a hard link to the existing file when it finds them, eliminating the need to pull them from the
+container registry. These options can deduplicate pulling of content, disk
+storage of content and can allow the kernel to use less memory when running
+containers.
+
+containers/storage supports four keys
+  * enable_partial_images="true" | "false"
+    Tells containers/storage to look for files previously pulled in storage
+    rather then always pulling them from the container registry.
+  * use_hard_links = "false" | "true"
+    Tells containers/storage to use hard links rather then create new files in
+    the image, if an identical file already existed in storage.
+  * ostree_repos = ""
+    Tells containers/storage where an ostree repository exists that might have
+    previously pulled content which can be used when attempting to avoid
+    pulling content from the container registry
+
+**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.
+
+  Example
+     remap-user = "containers"
+     remap-group = "containers"
+
+**root-auto-userns-user**=""
+  Root-auto-userns-user is a user name which can be used to look up one or more UID/GID ranges in the /etc/subuid and /etc/subgid file.  These ranges will be partitioned to containers configured to create automatically a user namespace.  Containers configured to automatically create a user namespace can still overlap with containers having an explicit mapping set.  This setting is ignored when running as rootless.
+
+**auto-userns-min-size**=1024
+  Auto-userns-min-size is the minimum size for a user namespace created automatically.
+
+**auto-userns-max-size**=65536
+  Auto-userns-max-size is the maximum size for a user namespace created automatically.
+
+**disable-volatile**=true
+  If disable-volatile is set, then the "volatile" mount optimization is disabled for all the containers.
+
+### STORAGE OPTIONS FOR AUFS TABLE
+
+The `storage.options.aufs` table supports the following options:
+
+**mountopt**=""
+  Comma separated list of default options to be used to mount container images.  Suggested value "nodev". Mount options are documented in the mount(8) man page.
+
+### STORAGE OPTIONS FOR BTRFS TABLE
+
+The `storage.options.btrfs` table supports the following options:
+
+**min_space**=""
+  Specifies the min space in a btrfs volume.
+
+**size**=""
+  Maximum size of a container image.   This flag can be used to set quota on the size of container images. (format: <number>[<unit>], where unit = b (bytes), k (kilobytes), m (megabytes), or g (gigabytes))
+
+### STORAGE OPTIONS FOR THINPOOL (devicemapper) TABLE
+
+The `storage.options.thinpool` table supports the following options for the `devicemapper` driver:
+
+**autoextend_percent**=""
+  Tells the thinpool driver the amount by which the thinpool needs to be grown. This is specified in terms of % of pool size. So a value of 20 means that when threshold is hit, pool will be grown by 20% of existing pool size. (default: 20%)
+
+**autoextend_threshold**=""
+  Tells the driver the thinpool extension threshold in terms of percentage of pool size. For example, if threshold is 60, that means when pool is 60% full, threshold has been hit. (default: 80%)
+
+**basesize**=""
+  Specifies the size to use when creating the base device, which limits the size of images and containers. (default: 10g)
+
+**blocksize**=""
+  Specifies a custom blocksize to use for the thin pool. (default: 64k)
+
+**directlvm_device**=""
+  Specifies a custom block storage device to use for the thin pool. Required for using graphdriver `devicemapper`.
+
+**directlvm_device_force**=""
+  Tells driver to wipe device (directlvm_device) even if device already has a filesystem.  (default: false)
+
+**fs**="xfs"
+  Specifies the filesystem type to use for the base device. (default: xfs)
+
+**log_level**=""
+  Sets the log level of devicemapper.
+
+    0: LogLevelSuppress 0 (default)
+    2: LogLevelFatal
+    3: LogLevelErr
+    4: LogLevelWarn
+    5: LogLevelNotice
+    6: LogLevelInfo
+    7: LogLevelDebug
+
+**metadata_size**=""
+  metadata_size is used to set the `pvcreate --metadatasize` options when creating thin devices. (Default 128k)
+
+**min_free_space**=""
+  Specifies the min free space percent in a thin pool required for new device creation to succeed. Valid values are from 0% - 99%. Value 0% disables. (default: 10%)
+
+**mkfsarg**=""
+  Specifies extra mkfs arguments to be used when creating the base device.
+
+**mountopt**=""
+  Comma separated list of default options to be used to mount container images.  Suggested value "nodev". Mount options are documented in the mount(8) man page.
+
+**size**=""
+  Maximum size of a container image.  This flag can be used to set quota on the size of container images. (format: <number>[<unit>], where unit = b (bytes), k (kilobytes), m (megabytes), or g (gigabytes))
+
+**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.)
+
+### STORAGE OPTIONS FOR OVERLAY TABLE
+
+The `storage.options.overlay` table supports the following options:
+
+**ignore_chown_errors** = "false"
+  ignore_chown_errors can be set to allow a non privileged user running with a  single UID within a user namespace to run containers. The user can pull and use any image even those with multiple uids.  Note multiple UIDs will be squashed down to the default uid in the container.  These images will have no separation between the users in the container. (default: false)
+
+**inodes**=""
+  Maximum inodes in a read/write layer.   This flag can be used to set a quota on the inodes allocated for a read/write layer of a container.
+
+**force_mask** = "0000|shared|private"
+  ForceMask specifies the permissions mask that is used for new files and
+directories. The values "shared" and "private" are accepted.  (default: ""). Octal permission
+masks are also accepted.
+
+- ``: Not set
+  All files/directories, get set with the permissions identified within the
+image.
+
+- `private`: it is equivalent to 0700.
+  All files/directories get set with 0700 permissions.  The owner has rwx
+access to the files. No other users on the system can access the files.
+This setting could be used with networked based home directories.
+
+- `shared`: it is equivalent to 0755.
+  The owner has rwx access to the files and everyone else can read, access
+and execute them. This setting is useful for sharing containers storage
+with other users.  For instance, a storage owned by root could be shared
+to rootless users as an additional store.
+NOTE:  All files within the image are made readable and executable by any
+user on the system. Even /etc/shadow within your image is now readable by
+any user.
+
+  `OCTAL`: Users can experiment with other OCTAL Permissions.
+
+Note: The force_mask Flag is an experimental feature, it could change in the
+future.  When "force_mask" is set the original permission mask is stored in the
+"user.containers.override_stat" xattr and the "mount_program" option must be
+specified. Mount programs like "/usr/bin/fuse-overlayfs" present the extended
+attribute permissions to processes within containers rather than the
+"force_mask"  permissions.
+
+**mount_program**=""
+  Specifies the path to a custom program to use instead of using kernel defaults
+for mounting the file system. In rootless mode, without the CAP_SYS_ADMIN
+capability, many kernels prevent mounting of overlay file systems, requiring
+you to specify a mount_program. The mount_program option is also required on
+systems where the underlying storage is btrfs, aufs, zfs, overlay, or ecryptfs
+based file systems.
+  mount_program = "/usr/bin/fuse-overlayfs"
+
+**mountopt**=""
+  Comma separated list of default options to be used to mount container images.  Suggested value "nodev". Mount options are documented in the mount(8) man page.
+
+**skip_mount_home=""**
+  Tell storage drivers to not create a PRIVATE bind mount on their home directory.
+
+**size**=""
+  Maximum size of a read/write layer.   This flag can be used to set quota on the size of a read/write layer of a container. (format: <number>[<unit>], where unit = b (bytes), k (kilobytes), m (megabytes), or g (gigabytes))
+
+### STORAGE OPTIONS FOR VFS TABLE
+
+The `storage.options.vfs` table supports the following options:
+
+**ignore_chown_errors** = "false"
+  ignore_chown_errors can be set to allow a non privileged user running with a  single UID within a user namespace to run containers. The user can pull and use any image even those with multiple uids.  Note multiple UIDs will be squashed down to the default uid in the container.  These images will have no separation between the users in the container. (default: false)
+
+### STORAGE OPTIONS FOR ZFS TABLE
+
+The `storage.options.zfs` table supports the following options:
+
+**fsname**=""
+  File System name for the zfs driver
+
+**mountopt**=""
+  Comma separated list of default options to be used to mount container images.  Suggested value "nodev". Mount options are documented in the mount(8) man page.
+
+**size**=""
+  Maximum size of a container image.   This flag can be used to set quota on the size of container images. (format: <number>[<unit>], where unit = b (bytes), k (kilobytes), m (megabytes), or g (gigabytes))
+
+## SELINUX LABELING
+
+When running on an SELinux system, if you move the containers storage graphroot directory, you must make sure the labeling is correct.
+
+Tell SELinux about the new containers storage by setting up an equivalence record. This tells SELinux to label content under the new path, as if it was stored under `/var/lib/containers/storage`.
+
+```
+semanage fcontext -a -e /var/lib/containers NEWSTORAGEPATH
+restorecon -R -v NEWSTORAGEPATH
+```
+
+In rootless mode, you would set
+
+```
+semanage fcontext -a -e $HOME/.local/share/containers NEWSTORAGEPATH
+restorecon -R -v NEWSTORAGEPATH
+```
+
+The semanage command above tells SELinux to setup the default labeling of `NEWSTORAGEPATH` to match `/var/lib/containers`.  The `restorecon` command tells SELinux to apply the labels to the actual content.
+
+Now all new content created in these directories will automatically be created with the correct label.
+
+## QUOTAS
+
+Container storage implements `XFS project quota controls` for overlay storage
+containers and volumes. The directory used to store the containers must be an
+`XFS` file system and be mounted with the `pquota` option.
+
+Example /etc/fstab entry:
+```
+/dev/podman/podman-var /var xfs defaults,x-systemd.device-timeout=0,pquota 1 2
+```
+
+Container storage generates project ids for each container and builtin volume, but these project ids need to be unique for the XFS file system.
+
+The xfs_quota tool can be used to assign a project id to the storage driver directory, e.g.:
+
+```
+echo 100000:/var/lib/containers/storage/overlay >> /etc/projects
+echo 200000:/var/lib/containers/storage/volumes >> /etc/projects
+echo storage:100000 >> /etc/projid
+echo volumes:200000 >> /etc/projid
+xfs_quota -x -c 'project -s storage volumes' /<xfs mount point>
+```
+
+In the example above, the storage directory project id will be used as a "start offset"
+and all containers will be assigned larger project ids (e.g. >= 100000).
+Then the volumes directory project id will be used as a "start offset"
+and all volumes will be assigned larger project ids (e.g. >= 200000).
+This is a way to prevent xfs_quota management from conflicting with containers/storage.
+
+## FILES
+
+Distributions often provide a `/usr/share/containers/storage.conf` file to define default storage configuration. Administrators can override this file by creating `/etc/containers/storage.conf` to specify their own configuration. Likewise rootless users can create a storage.conf file to override the system storage.conf files. Files should be stored in the `$XDG_CONFIG_HOME/containers/storage.conf` file.  If `$XDG_CONFIG_HOME` is not set then the file `$HOME/.config/containers/storage.conf` is used.
+
+Note: The storage.conf file overrides all other storage.conf files. Container
+engines run by users with a storage.conf file in their home directory do not
+use options in the system storage.conf files.
+
+/etc/projects - XFS persistent project root definition
+/etc/projid -  XFS project name mapping file
+
+## SEE ALSO
+`semanage(8)`, `restorecon(8)`, `mount(8)`, `fuse-overlayfs(1)`, `xfs_quota(8)`, `projects(5)`, `projid(5)`
+
+## HISTORY
+May 2017, Originally compiled by Dan Walsh <dwalsh@redhat.com>
+Format copied from crio.conf man page created by Aleksa Sarai <asarai@suse.de>

SOURCES/containers-transports.5.md

@@ -0,0 +1,118 @@
+% 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.
+
+The semantics of the image names ultimately depend on the environment where
+they are evaluated. For example: if evaluated on a remote server, image names
+might refer to paths on that server; relative paths are relative to the current
+directory of the image consumer.
+
+### **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|@source-index}]_
+
+An image is stored in the docker-save(1) formatted file.
+_docker-reference_ must not contain a digest.
+Alternatively, for reading archives, @_source-index_ is a zero-based index in archive manifest
+(to access untagged images).
+If neither _docker-reference_ nor @_source_index is specified when reading an archive, the archive must contain exactly one image.
+
+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[:reference]_
+
+An image compliant with the "Open Container Image Layout Specification" at _path_.
+Using a _reference_ is optional and allows for storing multiple images at the same _path_.
+
+### **oci-archive:**_path[:reference]_
+
+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>

SOURCES/containers.conf

@@ -0,0 +1,721 @@
+# The containers configuration file specifies all of the available configuration
+# command-line options/flags for container engine tools like Podman & Buildah,
+# but in a TOML format that can be easily modified and versioned.
+
+# Please refer to containers.conf(5) for details of all configuration options.
+# Not all container engines implement all of the options.
+# All of the options have hard coded defaults and these options will override
+# the built in defaults. Users can then override these options via the command
+# line. Container engines will read containers.conf files in up to three
+# locations in the following order:
+#  1. /usr/share/containers/containers.conf
+#  2. /etc/containers/containers.conf
+#  3. $HOME/.config/containers/containers.conf (Rootless containers ONLY)
+#  Items specified in the latter containers.conf, if they exist, override the
+# previous containers.conf settings, or the default settings.
+
+[containers]
+
+# List of annotation. Specified as
+# "key = value"
+# If it is empty or commented out, no annotations will be added
+#
+#annotations = []
+
+# Used to change the name of the default AppArmor profile of container engine.
+#
+#apparmor_profile = "container-default"
+
+# The hosts entries from the base hosts file are added to the containers hosts
+# file. This must be either an absolute path or as special values "image" which
+# uses the hosts file from the container image or "none" which means
+# no base hosts file is used. The default is "" which will use /etc/hosts.
+#
+#base_hosts_file = ""
+
+# Default way to to create a cgroup namespace for the container
+# Options are:
+# `private` Create private Cgroup Namespace for the container.
+# `host`    Share host Cgroup Namespace with the container.
+#
+#cgroupns = "private"
+
+# Control container cgroup configuration
+# Determines  whether  the  container will create CGroups.
+# Options are:
+# `enabled`   Enable cgroup support within container
+# `disabled`  Disable cgroup support, will inherit cgroups from parent
+# `no-conmon` Do not create a cgroup dedicated to conmon.
+#
+#cgroups = "enabled"
+
+# List of default capabilities for containers. If it is empty or commented out,
+# the default capabilities defined in the container engine will be added.
+#
+#default_capabilities = [
+#  "CHOWN",
+#  "DAC_OVERRIDE",
+#  "FOWNER",
+#  "FSETID",
+#  "KILL",
+#  "NET_BIND_SERVICE",
+#  "SETFCAP",
+#  "SETGID",
+#  "SETPCAP",
+#  "SETUID",
+#]
+
+# A list of sysctls to be set in containers by default,
+# specified as "name=value",
+# for example:"net.ipv4.ping_group_range=0 0".
+#
+default_sysctls = [
+  "net.ipv4.ping_group_range=0 0",
+]
+
+# A list of ulimits to be set in containers by default, specified as
+# "<ulimit name>=<soft limit>:<hard limit>", for example:
+# "nofile=1024:2048"
+# See setrlimit(2) for a list of resource names.
+# Any limit not specified here will be inherited from the process launching the
+# container engine.
+# Ulimits has limits for non privileged container engines.
+#
+#default_ulimits = [
+#  "nofile=1280:2560",
+#]
+
+# List of devices. Specified as
+# "<device-on-host>:<device-on-container>:<permissions>", for example:
+# "/dev/sdc:/dev/xvdc:rwm".
+# If it is empty or commented out, only the default devices will be used
+#
+#devices = []
+
+# List of default DNS options to be added to /etc/resolv.conf inside of the container.
+#
+#dns_options = []
+
+# List of default DNS search domains to be added to /etc/resolv.conf inside of the container.
+#
+#dns_searches = []
+
+# Set default DNS servers.
+# This option can be used to override the DNS configuration passed to the
+# container. The special value "none" can be specified to disable creation of
+# /etc/resolv.conf in the container.
+# The /etc/resolv.conf file in the image will be used without changes.
+#
+#dns_servers = []
+
+# Environment variable list for the conmon process; used for passing necessary
+# environment variables to conmon or the runtime.
+#
+#env = [
+#  "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
+#  "TERM=xterm",
+#]
+
+# Pass all host environment variables into the container.
+#
+#env_host = false
+
+# Set the ip for the host.containers.internal entry in the containers /etc/hosts
+# file. This can be set to "none" to disable adding this entry. By default it
+# will automatically choose the host ip.
+#
+# NOTE: When using podman machine this entry will never be added to the containers
+# hosts file instead the gvproxy dns resolver will resolve this hostname. Therefore
+# it is not possible to disable the entry in this case.
+#
+#host_containers_internal_ip = ""
+
+# Default proxy environment variables passed into the container.
+# The environment variables passed in include:
+# http_proxy, https_proxy, ftp_proxy, no_proxy, and the upper case versions of
+# these. This option is needed when host system uses a proxy but container
+# should not use proxy. Proxy environment variables specified for the container
+# in any other way will override the values passed from the host.
+#
+#http_proxy = true
+
+# Run an init inside the container that forwards signals and reaps processes.
+#
+#init = false
+
+# Container init binary, if init=true, this is the init binary to be used for containers.
+#
+#init_path = "/usr/libexec/podman/catatonit"
+
+# Default way to to create an IPC namespace (POSIX SysV IPC) for the container
+# Options are:
+#  "host"     Share host IPC Namespace with the container.
+#  "none"     Create shareable IPC Namespace for the container without a private /dev/shm.
+#  "private"  Create private IPC Namespace for the container, other containers are not allowed to share it.
+#  "shareable" Create shareable IPC Namespace for the container.
+#
+#ipcns = "shareable"
+
+# keyring tells the container engine whether to create
+# a kernel keyring for use within the container.
+#
+#keyring = true
+
+# label tells the container engine whether to use container separation using
+# MAC(SELinux) labeling or not.
+# The label flag is ignored on label disabled systems.
+#
+#label = true
+
+# Logging driver for the container. Available options: k8s-file and journald.
+#
+#log_driver = "k8s-file"
+
+# Maximum size allowed for the container log file. Negative numbers indicate
+# that no size limit is imposed. If positive, it must be >= 8192 to match or
+# exceed conmon's read buffer. The file is truncated and re-opened so the
+# limit is never exceeded.
+#
+#log_size_max = -1
+
+# Specifies default format tag for container log messages.
+# This is useful for creating a specific tag for container log messages.
+# Containers logs default to truncated container ID as a tag.
+#
+#log_tag = ""
+
+# Default way to to create a Network namespace for the container
+# Options are:
+# `private` Create private Network Namespace for the container.
+# `host`    Share host Network Namespace with the container.
+# `none`    Containers do not use the network
+#
+#netns = "private"
+
+# Create /etc/hosts for the container.  By default, container engine manage
+# /etc/hosts, automatically adding  the container's  own  IP  address.
+#
+#no_hosts = false
+
+# Default way to to create a PID namespace for the container
+# Options are:
+# `private` Create private PID Namespace for the container.
+# `host`    Share host PID Namespace with the container.
+#
+#pidns = "private"
+
+# Maximum number of processes allowed in a container.
+#
+#pids_limit = 2048
+
+# Copy the content from the underlying image into the newly created volume
+# when the container is created instead of when it is started. If false,
+# the container engine will not copy the content until the container is started.
+# Setting it to true may have negative performance implications.
+#
+#prepare_volume_on_create = false
+
+# Run all containers with root file system mounted read-only
+#
+# read_only = false
+
+# Path to the seccomp.json profile which is used as the default seccomp profile
+# for the runtime.
+#
+#seccomp_profile = "/usr/share/containers/seccomp.json"
+
+# Size of /dev/shm. Specified as <number><unit>.
+# Unit is optional, values:
+# b (bytes), k (kilobytes), m (megabytes), or g (gigabytes).
+# If the unit is omitted, the system uses bytes.
+#
+#shm_size = "65536k"
+
+# Set timezone in container. Takes IANA timezones as well as "local",
+# which sets the timezone in the container to match the host machine.
+#
+#tz = ""
+
+# Set umask inside the container
+#
+#umask = "0022"
+
+# Default way to to create a User namespace for the container
+# Options are:
+# `auto`        Create unique User Namespace for the container.
+# `host`    Share host User Namespace with the container.
+#
+#userns = "host"
+
+# Default way to to create a UTS namespace for the container
+# Options are:
+# `private`        Create private UTS Namespace for the container.
+# `host`    Share host UTS Namespace with the container.
+#
+#utsns = "private"
+
+# List of volumes. Specified as
+# "<directory-on-host>:<directory-in-container>:<options>", for example:
+# "/db:/var/lib/db:ro".
+# If it is empty or commented out, no volumes will be added
+#
+#volumes = []
+#
+#[engine.platform_to_oci_runtime]
+#"wasi/wasm" = ["crun-wasm"]
+#"wasi/wasm32" = ["crun-wasm"]
+#"wasi/wasm64" = ["crun-wasm"]
+
+[secrets]
+#driver = "file"
+
+[secrets.opts]
+#root = "/example/directory"
+
+[network]
+
+# Network backend determines what network driver will be used to set up and tear down container networks.
+# Valid values are "cni" and "netavark".
+# The default value is empty which means that it will automatically choose CNI or netavark. If there are
+# already containers/images or CNI networks preset it will choose CNI.
+#
+# Before changing this value all containers must be stopped otherwise it is likely that
+# iptables rules and network interfaces might leak on the host. A reboot will fix this.
+#
+#network_backend = ""
+
+# Path to directory where CNI plugin binaries are located.
+#
+#cni_plugin_dirs = [
+#  "/usr/local/libexec/cni",
+#  "/usr/libexec/cni",
+#  "/usr/local/lib/cni",
+#  "/usr/lib/cni",
+#  "/opt/cni/bin",
+#]
+
+# The network name of the default network to attach pods to.
+#
+#default_network = "podman"
+
+# The default subnet for the default network given in default_network.
+# If a network with that name does not exist, a new network using that name and
+# this subnet will be created.
+# Must be a valid IPv4 CIDR prefix.
+#
+#default_subnet = "10.88.0.0/16"
+
+# DefaultSubnetPools is a list of subnets and size which are used to
+# allocate subnets automatically for podman network create.
+# It will iterate through the list and will pick the first free subnet
+# with the given size. This is only used for ipv4 subnets, ipv6 subnets
+# are always assigned randomly.
+#
+#default_subnet_pools = [
+#  {"base" = "10.89.0.0/16", "size" = 24},
+#  {"base" = "10.90.0.0/15", "size" = 24},
+#  {"base" = "10.92.0.0/14", "size" = 24},
+#  {"base" = "10.96.0.0/11", "size" = 24},
+#  {"base" = "10.128.0.0/9", "size" = 24},
+#]
+
+# Path to the directory where network configuration files are located.
+# For the CNI backend the default is "/etc/cni/net.d" as root
+# and "$HOME/.config/cni/net.d" as rootless.
+# For the netavark backend "/etc/containers/networks" is used as root
+# and "$graphroot/networks" as rootless.
+#
+#network_config_dir = "/etc/cni/net.d/"
+
+# Port to use for dns forwarding daemon with netavark in rootful bridge
+# mode and dns enabled.
+# Using an alternate port might be useful if other dns services should
+# run on the machine.
+#
+#dns_bind_port = 53
+
+[engine]
+# Index to the active service
+#
+#active_service = production
+
+# The compression format to use when pushing an image.
+# Valid options are: `gzip`, `zstd` and `zstd:chunked`.
+#
+#compression_format = "gzip"
+
+
+# Cgroup management implementation used for the runtime.
+# Valid options "systemd" or "cgroupfs"
+#
+#cgroup_manager = "systemd"
+
+# Environment variables to pass into conmon
+#
+#conmon_env_vars = [
+#  "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
+#]
+
+# Paths to look for the conmon container manager binary
+#
+#conmon_path = [
+#  "/usr/libexec/podman/conmon",
+#  "/usr/local/libexec/podman/conmon",
+#  "/usr/local/lib/podman/conmon",
+#  "/usr/bin/conmon",
+#  "/usr/sbin/conmon",
+#  "/usr/local/bin/conmon",
+#  "/usr/local/sbin/conmon"
+#]
+
+# Enforces using docker.io for completing short names in Podman's compatibility
+# REST API. Note that this will ignore unqualified-search-registries and
+# short-name aliases defined in containers-registries.conf(5).
+#compat_api_enforce_docker_hub = true
+
+# Specify the keys sequence used to detach a container.
+# Format is a single character [a-Z] or a comma separated sequence of
+# `ctrl-<value>`, where `<value>` is one of:
+# `a-z`, `@`, `^`, `[`, `\`, `]`, `^` or `_`
+#
+#detach_keys = "ctrl-p,ctrl-q"
+
+# Determines whether engine will reserve ports on the host when they are
+# forwarded to containers. When enabled, when ports are forwarded to containers,
+# ports are held open by as long as the container is running, ensuring that
+# they cannot be reused by other programs on the host. However, this can cause
+# significant memory usage if a container has many ports forwarded to it.
+# Disabling this can save memory.
+#
+#enable_port_reservation = true
+
+# Environment variables to be used when running the container engine (e.g., Podman, Buildah).
+# For example "http_proxy=internal.proxy.company.com".
+# Note these environment variables will not be used within the container.
+# Set the env section under [containers] table, if you want to set environment variables for the container.
+#
+#env = []
+
+# Define where event logs will be stored, when events_logger is "file".
+#events_logfile_path=""
+
+# Sets the maximum size for events_logfile_path.
+# The size can be b (bytes), k (kilobytes), m (megabytes), or g (gigabytes).
+# The format for the size is `<number><unit>`, e.g., `1b` or `3g`.
+# If no unit is included then the size will be read in bytes.
+# When the limit is exceeded, the logfile will be rotated and the old one will be deleted.
+# If the maximum size is set to 0, then no limit will be applied,
+# and the logfile will not be rotated.
+#events_logfile_max_size = "1m"
+
+# Selects which logging mechanism to use for container engine events.
+# Valid values are `journald`, `file` and `none`.
+#
+#events_logger = "journald"
+
+# Creates a more verbose container-create event which includes a JSON payload
+# with detailed information about the container.
+#events_container_create_inspect_data = false
+
+# A is a list of directories which are used to search for helper binaries.
+#
+#helper_binaries_dir = [
+#  "/usr/local/libexec/podman",
+#  "/usr/local/lib/podman",
+#  "/usr/libexec/podman",
+#  "/usr/lib/podman",
+#]
+
+# Path to OCI hooks directories for automatically executed hooks.
+#
+#hooks_dir = [
+#  "/usr/share/containers/oci/hooks.d",
+#]
+
+# Manifest Type (oci, v2s2, or v2s1) to use when pulling, pushing, building
+# container images. By default image pulled and pushed match the format of the
+# source image. Building/committing defaults to OCI.
+#
+#image_default_format = ""
+
+# Default transport method for pulling and pushing for images
+#
+#image_default_transport = "docker://"
+
+# Maximum number of image layers to be copied (pulled/pushed) simultaneously.
+# Not setting this field, or setting it to zero, will fall back to containers/image defaults.
+#
+#image_parallel_copies = 0
+
+# Tells container engines how to handle the builtin image volumes.
+#   * bind: An anonymous named volume will be created and mounted
+#     into the container.
+#   * tmpfs: The volume is mounted onto the container as a tmpfs,
+#     which allows users to create content that disappears when
+#     the container is stopped.
+#   * ignore: All volumes are just ignored and no action is taken.
+#
+#image_volume_mode = ""
+
+# Default command to run the infra container
+#
+#infra_command = "/pause"
+
+# Infra (pause) container image name for pod infra containers.  When running a
+# pod, we start a `pause` process in a container to hold open the namespaces
+# associated with the  pod.  This container does nothing other then sleep,
+# reserving the pods resources for the lifetime of the pod. By default container
+# engines run a builtin container using the pause executable. If you want override
+# specify an image to pull.
+#
+#infra_image = ""
+
+# Specify the locking mechanism to use; valid values are "shm" and "file".
+# Change the default only if you are sure of what you are doing, in general
+# "file" is useful only on platforms where cgo is not available for using the
+# faster "shm" lock type. You may need to run "podman system renumber" after
+# you change the lock type.
+#
+#lock_type** = "shm"
+
+# MultiImageArchive - if true, the container engine allows for storing archives
+# (e.g., of the docker-archive transport) with multiple images.  By default,
+# Podman creates single-image archives.
+#
+#multi_image_archive = "false"
+
+# Default engine namespace
+# If engine is joined to a namespace, it will see only containers and pods
+# that were created in the same namespace, and will create new containers and
+# pods in that namespace.
+# The default namespace is "", which corresponds to no namespace. When no
+# namespace is set, all containers and pods are visible.
+#
+#namespace = ""
+
+# Path to the slirp4netns binary
+#
+#network_cmd_path = ""
+
+# Default options to pass to the slirp4netns binary.
+# Valid options values are:
+#
+# - allow_host_loopback=true|false: Allow the slirp4netns to reach the host loopback IP (`10.0.2.2`).
+#   Default is false.
+# - mtu=MTU: Specify the MTU to use for this network. (Default is `65520`).
+# - cidr=CIDR: Specify ip range to use for this network. (Default is `10.0.2.0/24`).
+# - enable_ipv6=true|false: Enable IPv6. Default is true. (Required for `outbound_addr6`).
+# - outbound_addr=INTERFACE: Specify the outbound interface slirp should bind to (ipv4 traffic only).
+# - outbound_addr=IPv4: Specify the outbound ipv4 address slirp should bind to.
+# - outbound_addr6=INTERFACE: Specify the outbound interface slirp should bind to (ipv6 traffic only).
+# - outbound_addr6=IPv6: Specify the outbound ipv6 address slirp should bind to.
+# - port_handler=rootlesskit: Use rootlesskit for port forwarding. Default.
+#   Note: Rootlesskit changes the source IP address of incoming packets to a IP address in the container
+#   network namespace, usually `10.0.2.100`. If your application requires the real source IP address,
+#   e.g. web server logs, use the slirp4netns port handler. The rootlesskit port handler is also used for
+#   rootless containers when connected to user-defined networks.
+# - port_handler=slirp4netns: Use the slirp4netns port forwarding, it is slower than rootlesskit but
+#   preserves the correct source IP address. This port handler cannot be used for user-defined networks.
+#
+#network_cmd_options = []
+
+# Whether to use chroot instead of pivot_root in the runtime
+#
+#no_pivot_root = false
+
+# Number of locks available for containers and pods.
+# If this is changed, a lock renumber must be performed (e.g. with the
+# 'podman system renumber' command).
+#
+#num_locks = 2048
+
+# Set the exit policy of the pod when the last container exits.
+#pod_exit_policy = "continue"
+
+# Whether to pull new image before running a container
+#
+#pull_policy = "missing"
+
+# Indicates whether the application should be running in remote mode. This flag modifies the
+# --remote option on container engines. Setting the flag to true will default
+# `podman --remote=true` for access to the remote Podman service.
+#
+#remote = false
+
+# Default OCI runtime
+#
+#runtime = "crun"
+runtime = "crun"
+
+# List of the OCI runtimes that support --format=json. When json is supported
+# engine will use it for reporting nicer errors.
+#
+#runtime_supports_json = ["crun", "runc", "kata", "runsc", "youki", "krun"]
+
+# List of the OCI runtimes that supports running containers with KVM Separation.
+#
+#runtime_supports_kvm = ["kata", "krun"]
+
+# List of the OCI runtimes that supports running containers without cgroups.
+#
+#runtime_supports_nocgroups = ["crun", "krun"]
+
+# Default location for storing temporary container image content. Can be overridden with the TMPDIR environment
+# variable. If you specify "storage", then the location of the
+# container/storage tmp directory will be used.
+# image_copy_tmp_dir="/var/tmp"
+
+# Number of seconds to wait without a connection
+# before the `podman system service` times out and exits
+#
+#service_timeout = 5
+
+# Directory for persistent engine files (database, etc)
+# By default, this will be configured relative to where the containers/storage
+# stores containers
+# Uncomment to change location from this default
+#
+#static_dir = "/var/lib/containers/storage/libpod"
+
+# Number of seconds to wait for container to exit before sending kill signal.
+#
+#stop_timeout = 10
+
+# Number of seconds to wait before exit command in API process is given to.
+# This mimics Docker's exec cleanup behaviour, where the default is 5 minutes (value is in seconds).
+#
+#exit_command_delay = 300
+
+# map of service destinations
+#
+# [service_destinations]
+#  [service_destinations.production]
+#     URI to access the Podman service
+#     Examples:
+#       rootless "unix://run/user/$UID/podman/podman.sock" (Default)
+#       rootful "unix://run/podman/podman.sock (Default)
+#       remote rootless ssh://engineering.lab.company.com/run/user/1000/podman/podman.sock
+#       remote rootful ssh://root@10.10.1.136:22/run/podman/podman.sock
+#
+#    uri = "ssh://user@production.example.com/run/user/1001/podman/podman.sock"
+#    Path to file containing ssh identity key
+#    identity = "~/.ssh/id_rsa"
+
+# Directory for temporary files. Must be tmpfs (wiped after reboot)
+#
+#tmp_dir = "/run/libpod"
+
+# Directory for libpod named volumes.
+# By default, this will be configured relative to where containers/storage
+# stores containers.
+# Uncomment to change location from this default.
+#
+#volume_path = "/var/lib/containers/storage/volumes"
+
+# Default timeout (in seconds) for volume plugin operations.
+# Plugins are external programs accessed via a REST API; this sets a timeout
+# for requests to that API.
+# A value of 0 is treated as no timeout.
+#volume_plugin_timeout = 5
+
+# Paths to look for a valid OCI runtime (crun, runc, kata, runsc, krun, etc)
+[engine.runtimes]
+#crun = [
+#  "/usr/bin/crun",
+#  "/usr/sbin/crun",
+#  "/usr/local/bin/crun",
+#  "/usr/local/sbin/crun",
+#  "/sbin/crun",
+#  "/bin/crun",
+#  "/run/current-system/sw/bin/crun",
+#]
+
+#kata = [
+#  "/usr/bin/kata-runtime",
+#  "/usr/sbin/kata-runtime",
+#  "/usr/local/bin/kata-runtime",
+#  "/usr/local/sbin/kata-runtime",
+#  "/sbin/kata-runtime",
+#  "/bin/kata-runtime",
+#  "/usr/bin/kata-qemu",
+#  "/usr/bin/kata-fc",
+#]
+
+#runc = [
+#  "/usr/bin/runc",
+#  "/usr/sbin/runc",
+#  "/usr/local/bin/runc",
+#  "/usr/local/sbin/runc",
+#  "/sbin/runc",
+#  "/bin/runc",
+#  "/usr/lib/cri-o-runc/sbin/runc",
+#]
+
+#runsc = [
+#  "/usr/bin/runsc",
+#  "/usr/sbin/runsc",
+#  "/usr/local/bin/runsc",
+#  "/usr/local/sbin/runsc",
+#  "/bin/runsc",
+#  "/sbin/runsc",
+#  "/run/current-system/sw/bin/runsc",
+#]
+
+#youki = [
+#  "/usr/local/bin/youki",
+#  "/usr/bin/youki",
+#  "/bin/youki",
+#  "/run/current-system/sw/bin/youki",
+#]
+
+#krun = [
+#  "/usr/bin/krun",
+#  "/usr/local/bin/krun",
+#]
+
+[engine.volume_plugins]
+#testplugin = "/run/podman/plugins/test.sock"
+
+[machine]
+# Number of CPU's a machine is created with.
+#
+#cpus=1
+
+# The size of the disk in GB created when init-ing a podman-machine VM.
+#
+#disk_size=10
+
+# Default image URI when creating a new VM using `podman machine init`.
+# Options: On Linux/Mac, `testing`, `stable`, `next`. On Windows, the major
+# version of the OS (e.g `36`) for Fedora 36. For all platforms you can
+# alternatively specify a custom download URL to an image. Container engines
+# translate URIs $OS and $ARCH to the native OS and ARCH. URI
+# "https://example.com/$OS/$ARCH/foobar.ami" becomes
+# "https://example.com/linux/amd64/foobar.ami" on a Linux AMD machine.
+# The default value is `testing`.
+#
+# image = "testing"
+
+# Memory in MB a machine is created with.
+#
+#memory=2048
+
+# The username to use and create on the podman machine OS for rootless
+# container access.
+#
+#user = "core"
+
+# Host directories to be mounted as volumes into the VM by default.
+# Environment variables like $HOME as well as complete paths are supported for
+# the source and destination. An optional third field `:ro` can be used to
+# tell the container engines to mount the volume readonly.
+#
+# volumes = [
+#  "$HOME:$HOME",
+#]
+
+# The [machine] table MUST be the last entry in this file.
+# (Unless another table is added)
+# TOML does not provide a way to end a table other than a further table being
+# defined, so every key hereafter will be part of [machine] and not the
+# main config.

SOURCES/containers.conf.5.md

@@ -0,0 +1,779 @@
+% containers.conf 5 Container engine configuration file
+
+# NAME
+containers.conf - The container engine configuration file specifies default
+configuration options and command-line flags for container engines.
+
+# DESCRIPTION
+Container engines like Podman & Buildah read containers.conf file, if it exists
+and modify the defaults for running containers on the host. containers.conf uses
+a TOML format that can be easily modified and versioned.
+
+Container engines read the /usr/share/containers/containers.conf and
+/etc/containers/containers.conf, and /etc/containers/containers.conf.d/*.conf files
+if they exist. When running in rootless mode, they also read
+$HOME/.config/containers/containers.conf and
+$HOME/.config/containers/containers.conf.d/*.conf files.
+
+Fields specified in containers conf override the default options, as well as
+options in previously read containers.conf files.
+
+Config files in the `.d` directories, are added in alpha numeric sorted order and must end in `.conf`.
+
+Not all options are supported in all container engines.
+
+Note container engines also use other configuration files for configuring the environment.
+
+* `storage.conf` for configuration of container and images storage.
+* `registries.conf` for definition of container registires to search while pulling.
+container images.
+* `policy.conf` for controlling which images can be pulled to the system.
+
+# FORMAT
+The [TOML format][toml] is used as the encoding of the configuration file.
+Every option is nested under its table. No bare options are used. The format of
+TOML can be simplified to:
+
+    [table1]
+    option = value
+
+    [table2]
+    option = value
+
+    [table3]
+    option = value
+
+    [table3.subtable1]
+    option = value
+
+## CONTAINERS TABLE
+The containers table contains settings to configure and manage the OCI runtime.
+
+**annotations** = []
+List of annotations. Specified as "key=value" pairs to be added to all containers.
+
+Example: "run.oci.keep_original_groups=1"
+
+**apparmor_profile**="container-default"
+
+Used to change the name of the default AppArmor profile of container engines.
+The default profile name is "container-default".
+
+**base_hosts_file**=""
+
+The hosts entries from the base hosts file are added to the containers hosts
+file. This must be either an absolute path or as special values "image" which
+uses the hosts file from the container image or "none" which means
+no base hosts file is used. The default is "" which will use /etc/hosts.
+
+**cgroups**="enabled"
+
+Determines  whether  the  container will create CGroups.
+Options are:
+  `enabled`   Enable cgroup support within container
+  `disabled`  Disable cgroup support, will inherit cgroups from parent
+  `no-conmon` Do not create a cgroup dedicated to conmon.
+
+**cgroupns**="private"
+
+Default way to to create a cgroup namespace for the container.
+Options are:
+`private` Create private Cgroup Namespace for the container.
+`host`    Share host Cgroup Namespace with the container.
+
+**default_capabilities**=[]
+
+List of default capabilities for containers.
+
+The default list is:
+```
+default_capabilities = [
+      "CHOWN",
+      "DAC_OVERRIDE",
+      "FOWNER",
+      "FSETID",
+      "KILL",
+      "NET_BIND_SERVICE",
+      "SETFCAP",
+      "SETGID",
+      "SETPCAP",
+      "SETUID",
+]
+```
+
+Note, by default container engines using containers.conf, run with less
+capabilities than Docker. Docker runs additionally with "AUDIT_WRITE", "MKNOD",
+"NET_RAW", "CHROOT". If you need to add one of these capabilities for a
+particular container, you can use the --cap-add option or edit your system's containers.conf.
+
+**default_sysctls**=[]
+
+A list of sysctls to be set in containers by default,
+specified as "name=value".
+
+Example:"net.ipv4.ping_group_range=0 1000".
+
+**default_ulimits**=[]
+
+A list of ulimits to be set in containers by default,
+specified as "name=soft-limit:hard-limit".
+
+Example: "nofile=1024:2048".
+
+**devices**=[]
+
+List of devices.
+Specified as 'device-on-host:device-on-container:permissions'.
+
+Example: "/dev/sdc:/dev/xvdc:rwm".
+
+**dns_options**=[]
+
+List of default DNS options to be added to /etc/resolv.conf inside of the
+container.
+
+**dns_searches**=[]
+
+List of default DNS search domains to be added to /etc/resolv.conf inside of
+the container.
+
+**dns_servers**=[]
+
+A list of dns servers to override the DNS configuration passed to the
+container. The special value “none” can be specified to disable creation of
+/etc/resolv.conf in the container.
+
+**env**=["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "TERM=xterm"]
+
+Environment variable list for the container process, used for passing
+environment variables to the container.
+
+**env_host**=false
+
+Pass all host environment variables into the container.
+
+**host_containers_internal_ip**=""
+
+Set the ip for the host.containers.internal entry in the containers /etc/hosts
+file. This can be set to "none" to disable adding this entry. By default it
+will automatically choose the host ip.
+
+NOTE: When using podman machine this entry will never be added to the containers
+hosts file instead the gvproxy dns resolver will resolve this hostname. Therefore
+it is not possible to disable the entry in this case.
+
+**http_proxy**=true
+
+Default proxy environment variables will be passed into the container.
+The environment variables passed in include:
+`http_proxy`, `https_proxy`, `ftp_proxy`, `no_proxy`, and the upper case
+versions of these. The `no_proxy` option is needed when host system uses a proxy
+but container should not use proxy. Proxy environment variables specified for
+the container in any other way will override the values passed from the host.
+
+**init**=false
+
+Run an init inside the container that forwards signals and reaps processes.
+
+**init_path**="/usr/libexec/podman/catatonit"
+
+Path to the container-init binary, which forwards signals and reaps processes
+within containers. Note that the container-init binary will only be used when
+the `--init` for podman-create and podman-run is set.
+
+**ipcns**="shareable"
+
+Default way to to create a IPC namespace for the container.
+Options are:
+  `host`     Share host IPC Namespace with the container.
+  `none`     Create shareable IPC Namespace for the container without a private /dev/shm.
+  `private`  Create private IPC Namespace for the container, other containers are not allowed to share it.
+  `shareable` Create shareable IPC Namespace for the container.
+
+**keyring**=true
+
+Indicates whether the container engines create a kernel keyring for use within
+the container.
+
+**label**=true
+
+Indicates whether the container engine uses MAC(SELinux) container separation via labeling. This option is ignored on disabled systems.
+
+**log_driver**=""
+
+Logging driver for the container. Currently available options are k8s-file, journald, none and passthrough, with json-file aliased to k8s-file for scripting compatibility.  The journald driver is used by default if the systemd journal is readable and writable.  Otherwise, the k8s-file driver is used.
+
+**log_size_max**=-1
+
+Maximum size allowed for the container's log file. Negative numbers indicate
+that no size limit is imposed. If it is positive, it must be >= 8192 to
+match/exceed conmon's read buffer. The file is truncated and re-opened so the
+limit is never exceeded.
+
+**log_tag**=""
+
+Default format tag for container log messages. This is useful for creating a specific tag for container log messages. Container log messages default to using the truncated container ID as a tag.
+
+**netns**="private"
+
+Default way to to create a NET namespace for the container.
+Options are:
+  `private` Create private NET Namespace for the container.
+  `host`    Share host NET Namespace with the container.
+  `none`    Containers do not use the network.
+
+**no_hosts**=false
+
+Create /etc/hosts for the container. By default, container engines manage
+/etc/hosts, automatically adding  the container's  own  IP  address.
+
+**pidns**="private"
+
+Default way to to create a PID namespace for the container.
+Options are:
+  `private` Create private PID Namespace for the container.
+  `host`    Share host PID Namespace with the container.
+
+**pids_limit**=1024
+
+Maximum number of processes allowed in a container. 0 indicates that no limit
+is imposed.
+
+**prepare_volume_on_create**=false
+
+Copy the content from the underlying image into the newly created volume when the container is created instead of when it is started. If `false`, the container engine will not copy the content until the container is started. Setting it to `true` may have negative performance implications.
+
+**read_only**=true|false
+
+Run all containers with root file system mounted read-only. Set to false by default.
+
+**seccomp_profile**="/usr/share/containers/seccomp.json"
+
+Path to the seccomp.json profile which is used as the default seccomp profile
+for the runtime.
+
+**shm_size**="65536k"
+
+Size of `/dev/shm`. The format is `<number><unit>`. `number` must be greater
+than `0`.
+Unit is optional and can be:
+`b` (bytes), `k` (kilobytes), `m`(megabytes), or `g` (gigabytes).
+If you omit the unit, the system uses bytes. If you omit the size entirely,
+the system uses `65536k`.
+
+**tz=**""
+
+Set timezone in container. Takes IANA timezones as well as `local`, which sets the timezone in the container to match the host machine.
+If not set, then containers will run with the time zone specified in the image.
+
+Examples:
+  `tz="local"`
+  `tz="America/New_York"`
+
+**umask**="0022"
+
+Sets umask inside the container.
+
+**userns**="host"
+
+Default way to to create a USER namespace for the container.
+Options are:
+  `private` Create private USER Namespace for the container.
+  `host`    Share host USER Namespace with the container.
+
+**utsns**="private"
+
+Default way to to create a UTS namespace for the container.
+Options are:
+  `private` Create private UTS Namespace for the container.
+  `host`    Share host UTS Namespace with the container.
+
+**volumes**=[]
+
+List of volumes.
+Specified as "directory-on-host:directory-in-container:options".
+
+Example:  "/db:/var/lib/db:ro".
+
+## NETWORK TABLE
+The `network` table contains settings pertaining to the management of CNI
+plugins.
+
+**network_backend**=""
+
+Network backend determines what network driver will be used to set up and tear down container networks.
+Valid values are "cni" and "netavark".
+The default value is empty which means that it will automatically choose CNI or netavark. If there are
+already containers/images or CNI networks preset it will choose CNI.
+
+Before changing this value all containers must be stopped otherwise it is likely that
+iptables rules and network interfaces might leak on the host. A reboot will fix this.
+
+**cni_plugin_dirs**=[]
+
+List of paths to directories where CNI plugin binaries are located.
+
+The default list is:
+```
+cni_plugin_dirs = [
+  "/usr/local/libexec/cni",
+  "/usr/libexec/cni",
+  "/usr/local/lib/cni",
+  "/usr/lib/cni",
+  "/opt/cni/bin",
+]
+```
+
+**default_network**="podman"
+
+The network name of the default network to attach pods to.
+
+**default_subnet**="10.88.0.0/16"
+
+The subnet to use for the default network (named above in **default_network**).
+If the default network does not exist, it will be automatically created the first time a tool is run using this subnet.
+
+**default_subnet_pools**=[]
+
+DefaultSubnetPools is a list of subnets and size which are used to
+allocate subnets automatically for podman network create.
+It will iterate through the list and will pick the first free subnet
+with the given size. This is only used for ipv4 subnets, ipv6 subnets
+are always assigned randomly.
+
+The default list is (10.89.0.0-10.255.255.0/24):
+```
+default_subnet_pools = [
+  {"base" = "10.89.0.0/16", "size" = 24},
+  {"base" = "10.90.0.0/15", "size" = 24},
+  {"base" = "10.92.0.0/14", "size" = 24},
+  {"base" = "10.96.0.0/11", "size" = 24},
+  {"base" = "10.128.0.0/9", "size" = 24},
+]
+```
+
+**network_config_dir**="/etc/cni/net.d/"
+
+Path to the directory where network configuration files are located.
+For the CNI backend the default is "/etc/cni/net.d" as root
+and "$HOME/.config/cni/net.d" as rootless.
+For the netavark backend "/etc/containers/networks" is used as root
+and "$graphroot/networks" as rootless.
+
+**dns_bind_port**=53
+
+Port to use for dns forwarding daemon with netavark in rootful bridge
+mode and dns enabled.
+Using an alternate port might be useful if other dns services should
+run on the machine.
+
+## ENGINE TABLE
+The `engine` table contains configuration options used to set up container engines such as Podman and Buildah.
+
+**active_service**=""
+
+Name of destination for accessing the Podman service. See SERVICE DESTINATION TABLE below.
+
+**cgroup_manager**="systemd"
+
+The cgroup management implementation used for the runtime. Supports `cgroupfs`
+and `systemd`.
+
+**conmon_env_vars**=[]
+
+Environment variables to pass into Conmon.
+
+**conmon_path**=[]
+
+Paths to search for the conmon container manager binary. If the paths are
+empty or no valid path was found, then the `$PATH` environment variable will be
+used as the fallback.
+
+The default list is:
+```
+conmon_path=[
+    "/usr/libexec/podman/conmon",
+    "/usr/local/libexec/podman/conmon",
+    "/usr/local/lib/podman/conmon",
+    "/usr/bin/conmon",
+    "/usr/sbin/conmon",
+    "/usr/local/bin/conmon",
+    "/usr/local/sbin/conmon",
+    "/run/current-system/sw/bin/conmon",
+]
+```
+
+**detach_keys**="ctrl-p,ctrl-q"
+
+Keys sequence used for detaching a container.
+Specify the keys sequence used to detach a container.
+Format is a single character `[a-Z]` or a comma separated sequence of
+`ctrl-<value>`, where `<value>` is one of:
+`a-z`, `@`, `^`, `[`, `\`, `]`, `^` or `_`
+
+**enable_port_reservation**=true
+
+Determines whether the engine will reserve ports on the host when they are
+forwarded to containers. When enabled, when ports are forwarded to containers,
+they are held open by conmon as long as the container is running, ensuring that
+they cannot be reused by other programs on the host. However, this can cause
+significant memory usage if a container has many ports forwarded to it.
+Disabling this can save memory.
+
+**env**=[]
+
+Environment variables to be used when running the container engine (e.g., Podman, Buildah). For example "http_proxy=internal.proxy.company.com".
+Note these environment variables will not be used within the container. Set the env section under [containers] table,
+if you want to set environment variables for the container.
+
+**events_logfile_path**=""
+
+Define where event logs will be stored, when events_logger is "file".
+
+**events_logfile_max_size**="1m"
+
+Sets the maximum size for events_logfile_path.
+The unit can be b (bytes), k (kilobytes), m (megabytes) or g (gigabytes).
+The format for the size is `<number><unit>`, e.g., `1b` or `3g`.
+If no unit is included then the size will be in bytes.
+When the limit is exceeded, the logfile will be rotated and the old one will be deleted.
+If the maximumn size is set to 0, then no limit will be applied,
+and the logfile will not be rotated.
+
+**events_logger**="journald"
+
+The default method to use when logging events.
+
+The default method is different based on the platform that
+Podman is being run upon.  To determine the current value,
+use this command:
+
+`podman info --format {{.Host.EventLogger}`
+
+Valid values are: `file`, `journald`, and `none`.
+
+**events_container_create_inspect_data**=true|false
+
+Creates a more verbose container-create event which includes a JSON payload
+with detailed information about the container.  Set to false by default.
+
+**helper_binaries_dir**=["/usr/libexec/podman", ...]
+
+A is a list of directories which are used to search for helper binaries.
+
+The default paths on Linux are:
+- `/usr/local/libexec/podman`
+- `/usr/local/lib/podman`
+- `/usr/libexec/podman`
+- `/usr/lib/podman`
+
+The default paths on macOS are:
+- `/usr/local/opt/podman/libexec`
+-	`/opt/homebrew/bin`
+-	`/opt/homebrew/opt/podman/libexec`
+- `/usr/local/bin`
+-	`/usr/local/libexec/podman`
+-	`/usr/local/lib/podman`
+-	`/usr/libexec/podman`
+-	`/usr/lib/podman`
+
+The default path on Windows is:
+- `C:\Program Files\RedHat\Podman`
+
+**hooks_dir**=["/etc/containers/oci/hooks.d", ...]
+
+Path to the OCI hooks directories for automatically executed hooks.
+
+**image_default_format**="oci"|"v2s2"|"v2s1"
+
+Manifest Type (oci, v2s2, or v2s1) to use when pulling, pushing, building
+container images. By default images pulled and pushed match the format of the
+source image. Building/committing defaults to OCI.
+Note: **image_build_format** is deprecated.
+
+**image_default_transport**="docker://"
+
+Default transport method for pulling and pushing images.
+
+**image_parallel_copies**=0
+
+Maximum number of image layers to be copied (pulled/pushed) simultaneously.
+Not setting this field will fall back to containers/image defaults. (6)
+
+**image_volume_mode**="bind"
+
+Tells container engines how to handle the builtin image volumes.
+
+* bind: An anonymous named volume will be  created  and  mounted into the container.
+* tmpfs: The volume is mounted onto the container as a tmpfs, which allows the users to create content that disappears when the container is stopped.
+* ignore: All volumes are just ignored and no action is taken.
+
+**infra_command**="/pause"
+
+Infra (pause) container image command for pod infra containers. When running a
+pod, we start a `/pause` process in a container to hold open the namespaces
+associated with the pod. This container does nothing other then sleep,
+reserving the pods resources for the lifetime of the pod.
+
+**infra_image**=""
+
+Infra (pause) container image for pod infra containers. When running a
+pod, we start a `pause` process in a container to hold open the namespaces
+associated with the pod. This container does nothing other then sleep,
+reserving the pods resources for the lifetime of the pod. By default container
+engines run a builtin container using the pause executable. If you want override
+specify an image to pull.
+
+**lock_type**="shm"
+
+Specify the locking mechanism to use; valid values are "shm" and "file".
+Change the default only if you are sure of what you are doing, in general
+"file" is useful only on platforms where cgo is not available for using the
+faster "shm" lock type. You may need to run "podman system renumber" after you
+change the lock type.
+
+**multi_image_archive**=false
+
+Allows for creating archives (e.g., tarballs) with more than one image. Some container engines, such as Podman, interpret additional arguments as tags for one image and hence do not store more than one image. The default behavior can be altered with this option.
+
+**namespace**=""
+
+Default engine namespace. If the engine is joined to a namespace, it will see
+only containers and pods that were created in the same namespace, and will
+create new containers and pods in that namespace. The default namespace is "",
+which corresponds to no namespace. When no namespace is set, all containers
+and pods are visible.
+
+**network_cmd_path**=""
+
+Path to the slirp4netns binary.
+
+**network_cmd_options**=[]
+
+Default options to pass to the slirp4netns binary.
+
+Valid options values are:
+
+  - **allow_host_loopback=true|false**: Allow the slirp4netns to reach the host loopback IP (`10.0.2.2`). Default is false.
+  - **mtu=MTU**: Specify the MTU to use for this network. (Default is `65520`).
+  - **cidr=CIDR**: Specify ip range to use for this network. (Default is `10.0.2.0/24`).
+  - **enable_ipv6=true|false**: Enable IPv6. Default is true. (Required for `outbound_addr6`).
+  - **outbound_addr=INTERFACE**: Specify the outbound interface slirp should bind to (ipv4 traffic only).
+  - **outbound_addr=IPv4**: Specify the outbound ipv4 address slirp should bind to.
+  - **outbound_addr6=INTERFACE**: Specify the outbound interface slirp should bind to (ipv6 traffic only).
+  - **outbound_addr6=IPv6**: Specify the outbound ipv6 address slirp should bind to.
+  - **port_handler=rootlesskit**: Use rootlesskit for port forwarding. Default.
+  Note: Rootlesskit changes the source IP address of incoming packets to a IP address in the container network namespace, usually `10.0.2.100`. If your application requires the real source IP address, e.g. web server logs, use the slirp4netns port handler. The rootlesskit port handler is also used for rootless containers when connected to user-defined networks.
+  - **port_handler=slirp4netns**: Use the slirp4netns port forwarding, it is slower than rootlesskit but preserves the correct source IP address. This port handler cannot be used for user-defined networks.
+
+**no_pivot_root**=false
+
+Whether to use chroot instead of pivot_root in the runtime.
+
+**num_locks**=2048
+
+Number of locks available for containers and pods. Each created container or
+pod consumes one lock. The default number available is 2048. If this is
+changed, a lock renumbering must be performed, using the
+`podman system renumber` command.
+
+**pod_exit_policy**="continue"
+
+Set the exit policy of the pod when the last container exits.  Supported policies are:
+
+| Exit Policy        | Description                                                                 |
+| ------------------ | --------------------------------------------------------------------------- |
+| *continue*         | The pod continues running when the last container exits. Used by default.   |
+| *stop*             | The pod is stopped when the last container exits. Used in `play kube`.      |
+
+**pull_policy**="always"|"missing"|"never"
+
+Pull image before running or creating a container. The default is **missing**.
+
+- **missing**: attempt to pull the latest image from the registries listed in registries.conf if a local image does not exist. Raise an error if the image is not in any listed registry and is not present locally.
+- **always**: pull the image from the first registry it is found in as listed in registries.conf. Raise an error if not found in the registries, even if the image is present locally.
+- **never**: do not pull the image from the registry, use only the local version. Raise an error if the image is not present locally.
+
+**remote** = false
+Indicates whether the application should be running in remote mode. This flag modifies the
+--remote option on container engines. Setting the flag to true will default `podman --remote=true` for access to the remote Podman service.
+
+**runtime**=""
+
+Default OCI specific runtime in runtimes that will be used by default. Must
+refer to a member of the runtimes table. Default runtime will be searched for
+on the system using the priority: "crun", "runc", "kata".
+
+**runtime_supports_json**=["crun", "runc", "kata", "runsc", "youki", "krun"]
+
+The list of the OCI runtimes that support `--format=json`.
+
+**runtime_supports_kvm**=["kata", "krun"]
+
+The list of OCI runtimes that support running containers with KVM separation.
+
+**runtime_supports_nocgroups**=["crun", "krun"]
+
+The list of OCI runtimes that support running containers without CGroups.
+
+**image_copy_tmp_dir**="/var/tmp"
+
+Default location for storing temporary container image content. Can be
+overridden with the TMPDIR environment variable. If you specify "storage", then
+the location of the container/storage tmp directory will be used. If set then it
+is the users responsibility to cleanup storage. Configure tmpfiles.d(5) to
+cleanup storage.
+
+**service_timeout**=**5**
+
+Number of seconds to wait without a connection  before the
+`podman system service` times out and exits
+
+**static_dir**="/var/lib/containers/storage/libpod"
+
+Directory for persistent libpod files (database, etc).
+By default this will be configured relative to where containers/storage
+stores containers.
+
+**stop_timeout**=10
+
+Number of seconds to wait for container to exit before sending kill signal.
+
+**exit_command_delay**=300
+
+Number of seconds to wait for the API process for the exec call before sending exit command mimicking the Docker behavior of 5 minutes (in seconds).
+
+**tmp_dir**="/run/libpod"
+
+The path to a temporary directory to store per-boot container.
+Must be a tmpfs (wiped after reboot).
+
+**volume_path**="/var/lib/containers/storage/volumes"
+
+Directory where named volumes will be created in using the default volume
+driver.
+By default this will be configured relative to where containers/storage store
+containers. This convention is followed by the default volume driver, but may
+not be by other drivers.
+
+**chown_copied_files**=true
+
+Determines whether file copied into a container will have changed ownership to
+the primary uid/gid of the container.
+
+**compression_format**=""
+
+Specifies the compression format to use when pushing an image. Supported values are: `gzip`, `zstd` and `zstd:chunked`.
+
+## SERVICE DESTINATION TABLE
+The `service_destinations` table contains configuration options used to set up remote connections to the podman service for the podman API.
+
+**[service_destinations.{name}]**
+URI to access the Podman service
+**uri="ssh://user@production.example.com/run/user/1001/podman/podman.sock"**
+
+  Example URIs:
+
+- **rootless local**  - unix://run/user/1000/podman/podman.sock
+- **rootless remote** - ssh://user@engineering.lab.company.com/run/user/1000/podman/podman.sock
+- **rootful local**  - unix://run/podman/podman.sock
+- **rootful remote** - ssh://root@10.10.1.136:22/run/podman/podman.sock
+
+**identity="~/.ssh/id_rsa**
+
+Path to file containing ssh identity key
+
+**[engine.volume_plugins]**
+
+A table of all the enabled volume plugins on the system. Volume plugins can be
+used as the backend for Podman named volumes. Individual plugins are specified
+below, as a map of the plugin name (what the plugin will be called) to its path
+(filepath of the plugin's unix socket).
+
+**[engine.platform_to_oci_runtime]**
+
+Allows end users to switch the OCI runtime on the bases of container image's platform string.
+Following config field contains a map of `platform/string = oci_runtime`.
+
+## SECRET TABLE
+The `secret` table contains settings for the configuration of the secret subsystem.
+
+**driver**=file
+
+Name of the secret driver to be used.
+Currently valid values are:
+  * file
+  * pass
+
+**[secrets.opts]**
+
+The driver specific options object.
+
+## MACHINE TABLE
+The `machine` table contains configurations for podman machine VMs
+
+**cpus**=1
+Number of CPU's a machine is created with.
+
+**disk_size**=10
+
+The size of the disk in GB created when init-ing a podman-machine VM
+
+**image**=""
+
+Default image URI when creating a new VM using `podman machine init`.
+Options: On Linux/Mac, `testing`, `stable`, `next`. On Windows, the major
+version of the OS (e.g `36`) for Fedora 36. For all platforms you can
+alternatively specify a custom download URL to an image. Container engines
+translate URIs $OS and $ARCH to the native OS and ARCH. URI "https://example.com/$OS/$ARCH/foobar.ami" would become "https://example.com/linux/amd64/foobar.ami" on a Linux AMD machine.
+The default value
+is `testing` on Linux/Mac, and on Windows.
+
+**memory**=2048
+
+Memory in MB a machine is created with.
+
+**user**=""
+
+Username to use and create on the podman machine OS for rootless container
+access. The default value is `user`. On Linux/Mac the default is`core`.
+
+**volumes**=["$HOME:$HOME"]
+
+Host directories to be mounted as volumes into the VM by default.
+Environment variables like $HOME as well as complete paths are supported for
+the source and destination. An optional third field `:ro` can be used to
+tell the container engines to mount the volume readonly.
+
+On Mac, the default volumes are: `"/Users:/Users", "/private:/private", "/var/folders:/var/folders"`
+
+# FILES
+
+**containers.conf**
+
+Distributions often provide a `/usr/share/containers/containers.conf` file to
+define default container configuration. Administrators can override fields in
+this file by creating `/etc/containers/containers.conf` to specify their own
+configuration. Rootless users can further override fields in the config by
+creating a config file stored in the `$HOME/.config/containers/containers.conf` file.
+
+If the `CONTAINERS_CONF` path environment variable is set, just
+this path will be used. This is primarily used for testing.
+
+Fields specified in the containers.conf file override the default options, as
+well as options in previously read containers.conf files.
+
+**storage.conf**
+
+The `/etc/containers/storage.conf` file is the default storage configuration file.
+Rootless users can override fields in the storage config by creating
+`$HOME/.config/containers/storage.conf`.
+
+If the `CONTAINERS_STORAGE_CONF` path environment variable is set, this path
+is used for the storage.conf file rather than the default.
+This is primarily used for testing.
+
+# SEE ALSO
+containers-storage.conf(5), containers-policy.json(5), containers-registries.conf(5), tmpfiles.d(5)
+
+[toml]: https://github.com/toml-lang/toml

SOURCES/default-policy.json

@@ -0,0 +1,32 @@
+{
+    "default": [
+        {
+            "type": "insecureAcceptAnything"
+        }
+    ],
+    "transports": {
+        "docker": {
+	    "registry.access.redhat.com": [
+		{
+		    "type": "signedBy",
+		    "keyType": "GPGKeys",
+		    "keyPaths": ["/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release", "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-beta"]
+		}
+	    ],
+	    "registry.redhat.io": [
+		{
+		    "type": "signedBy",
+		    "keyType": "GPGKeys",
+		    "keyPaths": ["/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release", "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-beta"]
+		}
+	    ]
+	},
+        "docker-daemon": {
+	    "": [
+		{
+		    "type": "insecureAcceptAnything"
+		}
+	    ]
+	}
+    }
+}

SOURCES/default.yaml

@@ -0,0 +1,28 @@
+# This is a default registries.d configuration file.  You may
+# add to this file or create additional files in registries.d/.
+#
+# lookaside: for reading/writing simple signing signatures
+# lookaside-staging: for writing simple signing signatures, preferred over lookaside
+#
+# lookaside and lookaside-staging take a value of the following:
+#   lookaside:  {schema}://location
+#
+# For reading signatures, schema may be http, https, or file.
+# For writing signatures, schema may only be file.
+
+# The default locations are built-in, for both reading and writing:
+# /var/lib/containers/sigstore for root, or
+# ~/.local/share/containers/sigstore for non-root users.
+default-docker:
+#  lookaside: https://…
+#  lookaside-staging: file:///…
+
+# The 'docker' indicator here is the start of the configuration
+# for docker registries.
+#
+# docker:
+#
+#   privateregistry.com:
+#    lookaside: https://privateregistry.com/sigstore/
+#    lookaside-staging: /mnt/nfs/privateregistry/sigstore
+

SOURCES/mounts.conf

@@ -0,0 +1 @@
+/usr/share/rhel/secrets:/run/secrets

SOURCES/pyxis.sh

@@ -0,0 +1,78 @@
+#!/bin/bash
+#set -e
+rm -f /tmp/pyxis*.json
+TOTAL=`curl -s --negotiate -u: -H 'Content-Type: application/json' -H 'Accept: application/json' -X GET "https://pyxis.engineering.redhat.com/v1/repositories?page_size=1" | jq .total`
+if [ "$TOTAL" == "null" ]; then
+  echo "Error comunicating with Pyxis API."
+  exit 1
+fi
+PAGES=$(($TOTAL/250))
+for P in `seq 0 $PAGES`; do
+  curl -s --negotiate -u: -H 'Content-Type: application/json' -H 'Accept: application/json' -X GET "https://pyxis.engineering.redhat.com/v1/repositories?page_size=500&page=$P" > /tmp/pyxis$P.json
+done
+cat /tmp/pyxis*.json > /tmp/pyx.json
+rm -f /tmp/rhel-shortnames.conf
+while read -r LINE; do
+  if [[ "$LINE" == *\"_id\":* ]] || [[ "$LINE" == *\"total\":* ]]; then
+    if [ -z $REGISTRY ] ||
+       [ -z $PUBLISHED ] ||
+       [ -z $REPOSITORY ] ||
+       [  $REPOSITORY == \"\" ] ||
+       [ "$AVAILABLE" != "Generally Available" ] ||
+       [[ $REPOSITORY == *[@:]* ]] ||
+       [[ $REPOSITORY == *[* ]] ||
+       [[ "$REGISTRY" == *non_registry* ]] ||
+       [[ $REGISTRY != *.* ]]
+     then
+      continue
+    fi
+    if [[ $REGISTRY == *quay.io* ]] ||
+       [[ $REGISTRY == *redhat.com* ]]; then
+      if [ "$REQUIRES_TERMS" == "1" ]; then
+        REGISTRY=registry.redhat.io
+      fi
+      echo "\"$REPOSITORY\" = \"$REGISTRY/$REPOSITORY\""
+      echo "\"$REPOSITORY\" = \"$REGISTRY/$REPOSITORY\"" >> /tmp/rhel-shortnames.conf
+    fi
+    REGISTRY=""
+    PUBLISHED=""
+    AVAILABLE=""
+    REPOSITORY=""
+    REQUIRES_TERMS=""
+    continue
+  fi
+  if [[ "$LINE" == *\"published\":\ true,* ]]; then
+    PUBLISHED=1
+  fi
+  if [[ "$LINE" == *\"requires_terms\":\ true,* ]]; then
+    REQUIRES_TERMS=1
+  fi
+  if [[ "$LINE" == *\"repository\":\ * ]]; then
+    REPOSITORY=`echo $LINE | sed 's,^.* ",,' | sed 's;",$;;'`
+  fi
+  if [[ "$LINE" == *\"registry\":\ * ]]; then
+    REGISTRY=`echo $LINE | sed -e 's,^.*:\ ",,' -e 's,".*,,'`
+  fi
+  if [[ "$LINE" == *\"release_categories\":\ * ]]; then
+    read -r LINE
+    AVAILABLE=`echo $LINE | sed 's,",,g'`
+  fi
+done < /tmp/pyx.json
+
+cp /tmp/rhel-shortnames.conf /tmp/r.conf
+for D in `cut -d\  -f1 /tmp/r.conf | sort | uniq -d`; do
+  echo $D
+  M=`grep ^$D /tmp/r.conf | grep 'redhat.com' | tail -n1`
+  [ -z "$M" ] && M=`grep ^$D /tmp/r.conf | tail -n1`
+  echo $M
+  if [ ! -z "$M" ]; then
+    echo "replacing $D with $M"
+    grep -v "^$D.*" /tmp/r.conf > /tmp/r2.conf
+    echo "$M" >> /tmp/r2.conf
+    mv /tmp/r2.conf /tmp/r.conf
+  fi
+done
+
+sed -i '/.*rhel.*-els\/.*$/d' /tmp/r.conf
+echo "[aliases]" > 001-rhel-shortnames-pyxis.conf
+sort /tmp/r.conf >> 001-rhel-shortnames-pyxis.conf

SOURCES/registries.conf

@@ -0,0 +1,79 @@
+# For more information on this configuration file, see containers-registries.conf(5).
+#
+# NOTE: RISK OF USING UNQUALIFIED IMAGE NAMES
+# We recommend always using fully qualified image names including the registry
+# server (full dns name), namespace, image name, and tag
+# (e.g., registry.redhat.io/ubi8/ubi:latest). Pulling by digest (i.e.,
+# quay.io/repository/name@digest) further eliminates the ambiguity of tags.
+# When using short names, there is always an inherent risk that the image being
+# pulled could be spoofed. For example, a user wants to pull an image named
+# `foobar` from a registry and expects it to come from myregistry.com. If
+# myregistry.com is not first in the search list, an attacker could place a
+# different `foobar` image at a registry earlier in the search list. The user
+# would accidentally pull and run the attacker's image and code rather than the
+# intended content. We recommend only adding registries which are completely
+# trusted (i.e., registries which don't allow unknown or anonymous users to
+# create accounts with arbitrary names). This will prevent an image from being
+# spoofed, squatted or otherwise made insecure.  If it is necessary to use one
+# of these registries, it should be added at the end of the list.
+#
+# # An array of host[:port] registries to try when pulling an unqualified image, in order.
+
+unqualified-search-registries = ["registry.access.redhat.com", "registry.redhat.io", "docker.io"]
+
+# [[registry]]
+# # The "prefix" field is used to choose the relevant [[registry]] TOML table;
+# # (only) the TOML table with the longest match for the input image name
+# # (taking into account namespace/repo/tag/digest separators) is used.
+# # 
+# # The prefix can also be of the form: *.example.com for wildcard subdomain
+# # matching.
+# #
+# # If the prefix field is missing, it defaults to be the same as the "location" field.
+# prefix = "example.com/foo"
+#
+# # If true, unencrypted HTTP as well as TLS connections with untrusted
+# # certificates are allowed.
+# insecure = false
+#
+# # If true, pulling images with matching names is forbidden.
+# blocked = false
+#
+# # The physical location of the "prefix"-rooted namespace.
+# #
+# # By default, this is equal to "prefix" (in which case "prefix" can be omitted
+# # and the [[registry]] TOML table can only specify "location").
+# #
+# # Example: Given
+# #   prefix = "example.com/foo"
+# #   location = "internal-registry-for-example.net/bar"
+# # requests for the image example.com/foo/myimage:latest will actually work with the
+# # internal-registry-for-example.net/bar/myimage:latest image.
+#
+# # The location can be empty iff prefix is in a
+# # wildcarded format: "*.example.com". In this case, the input reference will
+# # be used as-is without any rewrite.
+# location = internal-registry-for-example.com/bar"
+#
+# # (Possibly-partial) mirrors for the "prefix"-rooted namespace.
+# #
+# # The mirrors are attempted in the specified order; the first one that can be
+# # contacted and contains the image will be used (and if none of the mirrors contains the image,
+# # the primary location specified by the "registry.location" field, or using the unmodified
+# # user-specified reference, is tried last).
+# #
+# # Each TOML table in the "mirror" array can contain the following fields, with the same semantics
+# # as if specified in the [[registry]] TOML table directly:
+# # - location
+# # - insecure
+# [[registry.mirror]]
+# location = "example-mirror-0.local/mirror-for-foo"
+# [[registry.mirror]]
+# location = "example-mirror-1.local/mirrors/foo"
+# insecure = true
+# # Given the above, a pull of example.com/foo/image:latest will try:
+# # 1. example-mirror-0.local/mirror-for-foo/image:latest
+# # 2. example-mirror-1.local/mirrors/foo/image:latest
+# # 3. internal-registry-for-example.net/bar/image:latest
+# # in order, and use the first one that exists.
+short-name-mode = "enforcing"

SOURCES/registry.access.redhat.com.yaml

@@ -0,0 +1,3 @@
+docker:
+     registry.access.redhat.com:
+         sigstore: https://access.redhat.com/webassets/docker/content/sigstore

SOURCES/registry.redhat.io.yaml

@@ -0,0 +1,3 @@
+docker:
+     registry.redhat.io:
+         sigstore: https://registry.redhat.io/containers/sigstore

SOURCES/shortnames.conf

@@ -0,0 +1,121 @@
+[aliases]
+  # almalinux
+  "almalinux" = "docker.io/library/almalinux"
+  "almalinux-minimal" = "docker.io/library/almalinux-minimal"
+  # Arch Linux
+  "archlinux" = "docker.io/library/archlinux"
+  # centos
+  "centos" = "quay.io/centos/centos"
+  # containers
+  "skopeo" = "quay.io/skopeo/stable"
+  "buildah" = "quay.io/buildah/stable"
+  "podman" = "quay.io/podman/stable"
+  "hello" = "quay.io/podman/hello"
+  "hello-world" = "quay.io/podman/hello"
+  # docker
+  "alpine" = "docker.io/library/alpine"
+  "docker" = "docker.io/library/docker"
+  "registry" = "docker.io/library/registry"
+  "swarm" = "docker.io/library/swarm"
+  # Fedora
+  "fedora-minimal" = "registry.fedoraproject.org/fedora-minimal"
+  "fedora" = "registry.fedoraproject.org/fedora"
+  # openSUSE
+  "opensuse/tumbleweed" = "registry.opensuse.org/opensuse/tumbleweed"
+  "opensuse/tumbleweed-dnf" = "registry.opensuse.org/opensuse/tumbleweed-dnf"
+  "opensuse/tumbleweed-microdnf" = "registry.opensuse.org/opensuse/tumbleweed-microdnf"
+  "opensuse/leap" = "registry.opensuse.org/opensuse/leap"
+  "opensuse/busybox" = "registry.opensuse.org/opensuse/busybox"
+  "tumbleweed" = "registry.opensuse.org/opensuse/tumbleweed"
+  "tumbleweed-dnf" = "registry.opensuse.org/opensuse/tumbleweed-dnf"
+  "tumbleweed-microdnf" = "registry.opensuse.org/opensuse/tumbleweed-microdnf"
+  "leap" = "registry.opensuse.org/opensuse/leap"
+  "leap-dnf" = "registry.opensuse.org/opensuse/leap-dnf"
+  "leap-microdnf" = "registry.opensuse.org/opensuse/leap-microdnf"
+  "tw-busybox" = "registry.opensuse.org/opensuse/busybox"
+  # SUSE
+  "suse/sle15" = "registry.suse.com/suse/sle15"
+  "suse/sles12sp5" = "registry.suse.com/suse/sles12sp5"
+  "suse/sles12sp4" = "registry.suse.com/suse/sles12sp4"
+  "suse/sles12sp3" = "registry.suse.com/suse/sles12sp3"
+  "sle15" = "registry.suse.com/suse/sle15"
+  "sles12sp5" = "registry.suse.com/suse/sles12sp5"
+  "sles12sp4" = "registry.suse.com/suse/sles12sp4"
+  "sles12sp3" = "registry.suse.com/suse/sles12sp3"
+  "bci/bci-base" = "registry.suse.com/bci/bci-base"
+  "bci/bci-micro" = "registry.suse.com/bci/bci-micro"
+  "bci/bci-minimal" = "registry.suse.com/bci/bci-minimal"
+  "bci/bci-busybox" = "registry.suse.com/bci/bci-busybox"
+  # Red Hat Enterprise Linux
+  "rhel" = "registry.access.redhat.com/rhel"
+  "rhel6" = "registry.access.redhat.com/rhel6"
+  "rhel7" = "registry.access.redhat.com/rhel7"
+  "rhel7.9" = "registry.access.redhat.com/rhel7.9"
+  "rhel-atomic" = "registry.access.redhat.com/rhel-atomic"
+  "rhel-minimal" = "registry.access.redhat.com/rhel-minimum"
+  "rhel-init" = "registry.access.redhat.com/rhel-init"
+  "rhel7-atomic" = "registry.access.redhat.com/rhel7-atomic"
+  "rhel7-minimal" = "registry.access.redhat.com/rhel7-minimum"
+  "rhel7-init" = "registry.access.redhat.com/rhel7-init"
+  "rhel7/rhel" = "registry.access.redhat.com/rhel7/rhel"
+  "rhel7/rhel-atomic" = "registry.access.redhat.com/rhel7/rhel7/rhel-atomic"
+  "ubi7/ubi" = "registry.access.redhat.com/ubi7/ubi"
+  "ubi7/ubi-minimal" = "registry.access.redhat.com/ubi7-minimal"
+  "ubi7/ubi-init" = "registry.access.redhat.com/ubi7-init"
+  "ubi7" = "registry.access.redhat.com/ubi7"
+  "ubi7-init" = "registry.access.redhat.com/ubi7-init"
+  "ubi7-minimal" = "registry.access.redhat.com/ubi7-minimal"
+  "rhel8" = "registry.access.redhat.com/ubi8"
+  "rhel8-init" = "registry.access.redhat.com/ubi8-init"
+  "rhel8-minimal" = "registry.access.redhat.com/ubi8-minimal"
+  "rhel8-micro" = "registry.access.redhat.com/ubi8-micro"
+  "ubi8" = "registry.access.redhat.com/ubi8"
+  "ubi8-minimal" = "registry.access.redhat.com/ubi8-minimal"
+  "ubi8-init" = "registry.access.redhat.com/ubi8-init"
+  "ubi8-micro" = "registry.access.redhat.com/ubi8-micro"
+  "ubi8/ubi" = "registry.access.redhat.com/ubi8/ubi"
+  "ubi8/ubi-minimal" = "registry.access.redhat.com/ubi8-minimal"
+  "ubi8/ubi-init" = "registry.access.redhat.com/ubi8-init"
+  "ubi8/ubi-micro" = "registry.access.redhat.com/ubi8-micro"
+  "ubi8/podman" = "registry.access.redhat.com/ubi8/podman"
+  "ubi8/buildah" = "registry.access.redhat.com/ubi8/buildah"
+  "ubi8/skopeo" = "registry.access.redhat.com/ubi8/skopeo"
+  "rhel9" = "registry.access.redhat.com/ubi9"
+  "rhel9-init" = "registry.access.redhat.com/ubi9-init"
+  "rhel9-minimal" = "registry.access.redhat.com/ubi9-minimal"
+  "rhel9-micro" = "registry.access.redhat.com/ubi9-micro"
+  "ubi9" = "registry.access.redhat.com/ubi9"
+  "ubi9-minimal" = "registry.access.redhat.com/ubi9-minimal"
+  "ubi9-init" = "registry.access.redhat.com/ubi9-init"
+  "ubi9-micro" = "registry.access.redhat.com/ubi9-micro"
+  "ubi9/ubi" = "registry.access.redhat.com/ubi9/ubi"
+  "ubi9/ubi-minimal" = "registry.access.redhat.com/ubi9-minimal"
+  "ubi9/ubi-init" = "registry.access.redhat.com/ubi9-init"
+  "ubi9/ubi-micro" = "registry.access.redhat.com/ubi9-micro"
+  "ubi9/podman" = "registry.access.redhat.com/ubi9/podman"
+  "ubi9/buildah" = "registry.access.redhat.com/ubi9/buildah"
+  "ubi9/skopeo" = "registry.access.redhat.com/ubi9/skopeo"
+  # Rocky Linux
+  "rockylinux" = "docker.io/library/rockylinux"
+  # Debian
+  "debian" = "docker.io/library/debian"
+  # Kali Linux
+  "kali-bleeding-edge" = "docker.io/kalilinux/kali-bleeding-edge"
+  "kali-dev" = "docker.io/kalilinux/kali-dev"
+  "kali-experimental" = "docker.io/kalilinux/kali-experimental"
+  "kali-last-release" = "docker.io/kalilinux/kali-last-release"
+  "kali-rolling" = "docker.io/kalilinux/kali-rolling"
+  # Ubuntu
+  "ubuntu" = "docker.io/library/ubuntu"
+  # Oracle Linux
+  "oraclelinux" = "container-registry.oracle.com/os/oraclelinux"
+  # busybox
+  "busybox" = "docker.io/library/busybox"
+  # php
+  "php" = "docker.io/library/php"
+  # python
+  "python" = "docker.io/library/python"
+  # rust
+  "rust" = "docker.io/library/rust"
+  # node
+  "node" = "docker.io/library/node"

SOURCES/storage.conf

@@ -0,0 +1,236 @@
+# This file is the configuration file for all tools
+# that use the containers/storage library. The storage.conf file
+# overrides all other storage.conf files. Container engines using the
+# container/storage library do not inherit fields from other storage.conf
+# files.
+#
+#  Note: The storage.conf file overrides other storage.conf files based on this precedence:
+#      /usr/containers/storage.conf
+#      /etc/containers/storage.conf
+#      $HOME/.config/containers/storage.conf
+#      $XDG_CONFIG_HOME/containers/storage.conf (If XDG_CONFIG_HOME is set)
+# See man 5 containers-storage.conf for more information
+# The "container storage" table contains all of the server options.
+[storage]
+
+# Default Storage Driver, Must be set for proper operation.
+driver = "overlay"
+
+# Temporary storage location
+runroot = "/run/containers/storage"
+
+# Primary Read/Write location of container storage
+# When changing the graphroot location on an SELINUX system, you must
+# ensure  the labeling matches the default locations labels with the
+# following commands:
+# semanage fcontext -a -e /var/lib/containers/storage /NEWSTORAGEPATH
+# restorecon -R -v /NEWSTORAGEPATH
+graphroot = "/var/lib/containers/storage"
+
+
+# Storage path for rootless users
+#
+# rootless_storage_path = "$HOME/.local/share/containers/storage"
+
+# Transient store mode makes all container metadata be saved in temporary storage
+# (i.e. runroot above). This is faster, but doesn't persist across reboots.
+# transient_store = true
+
+[storage.options]
+# Storage options to be passed to underlying storage drivers
+
+# AdditionalImageStores is used to pass paths to additional Read/Only image stores
+# Must be comma separated list.
+additionalimagestores = [
+]
+
+# Allows specification of how storage is populated when pulling images. This
+# option can speed the pulling process of images compressed with format
+# zstd:chunked. Containers/storage looks for files within images that are being
+# pulled from a container registry that were previously pulled to the host.  It
+# can copy or create a hard link to the existing file when it finds them,
+# eliminating the need to pull them from the container registry. These options
+# can deduplicate pulling of content, disk storage of content and can allow the
+# kernel to use less memory when running containers.
+
+# containers/storage supports four keys
+#   * enable_partial_images="true" | "false"
+#     Tells containers/storage to look for files previously pulled in storage
+#     rather then always pulling them from the container registry.
+#   * use_hard_links = "false" | "true"
+#     Tells containers/storage to use hard links rather then create new files in
+#     the image, if an identical file already existed in storage.
+#   * ostree_repos = ""
+#     Tells containers/storage where an ostree repository exists that might have
+#     previously pulled content which can be used when attempting to avoid
+#     pulling content from the container registry
+pull_options = {enable_partial_images = "false", use_hard_links = "false", ostree_repos=""}
+
+# Remap-UIDs/GIDs is the mapping from UIDs/GIDs as they should appear inside of
+# a container, to the UIDs/GIDs as they should appear 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.
+#
+# remap-uids = 0:1668442479:65536
+# remap-gids = 0:1668442479:65536
+
+# 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 = "containers"
+# remap-group = "containers"
+
+# Root-auto-userns-user is a user name which can be used to look up one or more UID/GID
+# ranges in the /etc/subuid and /etc/subgid file.  These ranges will be partitioned
+# to containers configured to create automatically a user namespace.  Containers
+# configured to automatically create a user namespace can still overlap with containers
+# having an explicit mapping set.
+# This setting is ignored when running as rootless.
+# root-auto-userns-user = "storage"
+#
+# Auto-userns-min-size is the minimum size for a user namespace created automatically.
+# auto-userns-min-size=1024
+#
+# Auto-userns-max-size is the minimum size for a user namespace created automatically.
+# auto-userns-max-size=65536
+
+[storage.options.overlay]
+# ignore_chown_errors can be set to allow a non privileged user running with
+# a single UID within a user namespace to run containers. The user can pull
+# and use any image even those with multiple uids.  Note multiple UIDs will be
+# squashed down to the default uid in the container.  These images will have no
+# separation between the users in the container. Only supported for the overlay
+# and vfs drivers.
+#ignore_chown_errors = "false"
+
+# Inodes is used to set a maximum inodes of the container image.
+# inodes = ""
+
+# Path to an helper program to use for mounting the file system instead of mounting it
+# directly.
+#mount_program = "/usr/bin/fuse-overlayfs"
+
+# mountopt specifies comma separated list of extra mount options
+mountopt = "nodev,metacopy=on"
+
+# Set to skip a PRIVATE bind mount on the storage home directory.
+# skip_mount_home = "false"
+
+# Size is used to set a maximum size of the container image.
+# size = ""
+
+# ForceMask specifies the permissions mask that is used for new files and
+# directories.
+#
+# The values "shared" and "private" are accepted.
+# Octal permission masks are also accepted.
+#
+#  "": No value specified.
+#     All files/directories, get set with the permissions identified within the
+#     image.
+#  "private": it is equivalent to 0700.
+#     All files/directories get set with 0700 permissions.  The owner has rwx
+#     access to the files. No other users on the system can access the files.
+#     This setting could be used with networked based homedirs.
+#  "shared": it is equivalent to 0755.
+#     The owner has rwx access to the files and everyone else can read, access
+#     and execute them. This setting is useful for sharing containers storage
+#     with other users.  For instance have a storage owned by root but shared
+#     to rootless users as an additional store.
+#     NOTE:  All files within the image are made readable and executable by any
+#     user on the system. Even /etc/shadow within your image is now readable by
+#     any user.
+#
+#   OCTAL: Users can experiment with other OCTAL Permissions.
+#
+#  Note: The force_mask Flag is an experimental feature, it could change in the
+#  future.  When "force_mask" is set the original permission mask is stored in
+#  the "user.containers.override_stat" xattr and the "mount_program" option must
+#  be specified. Mount programs like "/usr/bin/fuse-overlayfs" present the
+#  extended attribute permissions to processes within containers rather than the
+#  "force_mask"  permissions.
+#
+# force_mask = ""
+
+[storage.options.thinpool]
+# Storage Options for thinpool
+
+# autoextend_percent determines the amount by which pool needs to be
+# grown. This is specified in terms of % of pool size. So a value of 20 means
+# that when threshold is hit, pool will be grown by 20% of existing
+# pool size.
+# autoextend_percent = "20"
+
+# autoextend_threshold determines the pool extension threshold in terms
+# of percentage of pool size. For example, if threshold is 60, that means when
+# pool is 60% full, threshold has been hit.
+# autoextend_threshold = "80"
+
+# basesize specifies the size to use when creating the base device, which
+# limits the size of images and containers.
+# basesize = "10G"
+
+# blocksize specifies a custom blocksize to use for the thin pool.
+# blocksize="64k"
+
+# directlvm_device specifies a custom block storage device to use for the
+# thin pool. Required if you setup devicemapper.
+# directlvm_device = ""
+
+# directlvm_device_force wipes device even if device already has a filesystem.
+# directlvm_device_force = "True"
+
+# fs specifies the filesystem type to use for the base device.
+# fs="xfs"
+
+# log_level sets the log level of devicemapper.
+# 0: LogLevelSuppress 0 (Default)
+# 2: LogLevelFatal
+# 3: LogLevelErr
+# 4: LogLevelWarn
+# 5: LogLevelNotice
+# 6: LogLevelInfo
+# 7: LogLevelDebug
+# log_level = "7"
+
+# min_free_space specifies the min free space percent in a thin pool require for
+# new device creation to succeed. Valid values are from 0% - 99%.
+# Value 0% disables
+# min_free_space = "10%"
+
+# mkfsarg specifies extra mkfs arguments to be used when creating the base
+# device.
+# mkfsarg = ""
+
+# metadata_size is used to set the `pvcreate --metadatasize` options when
+# creating thin devices. Default is 128k
+# metadata_size = ""
+
+# Size is used to set a maximum size of the container image.
+# size = ""
+
+# use_deferred_removal marks devicemapper block device for deferred removal.
+# If the thinpool is in use when the driver attempts to remove it, the driver
+# tells the kernel to remove it as soon as possible. Note this does not free
+# up the disk space, use deferred deletion to fully remove the thinpool.
+# use_deferred_removal = "True"
+
+# use_deferred_deletion marks thinpool device for deferred deletion.
+# If the device is busy when the driver attempts to delete it, the driver
+# will attempt to delete device every 30 seconds until successful.
+# If the program using the driver exits, the driver will continue attempting
+# to cleanup the next time the driver is used. Deferred deletion permanently
+# deletes the device and all data stored in device will be lost.
+# use_deferred_deletion = "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.
+# xfs_nospace_max_retries = "0"

SOURCES/update-vendored.sh

@@ -0,0 +1,36 @@
+#!/bin/bash
+# This script assures we always deliver the current documentation/configs
+# for the c/storage, c/image and c/common vendored in podman, skopeo, buildah
+# For questions reach to Jindrich Novy <jnovy@redhat.com>
+rm -f /tmp/ver_image /tmp/ver_common /tmp/ver_storage
+CENTOS=""
+pwd | grep /tmp/centos > /dev/null
+if [ $? == 0 ]; then
+  CENTOS=1
+fi
+set -e
+for P in podman skopeo buildah; do
+  BRN=`pwd | sed 's,^.*/,,'`
+  rm -rf $P
+  pkg clone $P
+  cd $P
+  [ -z "$CENTOS" ] && pkg switch-branch $BRN
+  if [ $BRN != stream-container-tools-rhel8 ]; then
+    pkg prep
+  else
+    pkg --release rhel-8 prep
+  fi
+  DIR=`ls -d -- */ | grep -v ^tests | head -n1`
+  grep github.com/containers/image $DIR/go.mod | cut -d\  -f2 | sed 's,-.*,,'>> /tmp/ver_image
+  grep github.com/containers/common $DIR/go.mod | cut -d\  -f2 | sed 's,-.*,,' >> /tmp/ver_common
+  grep github.com/containers/storage $DIR/go.mod | cut -d\  -f2 | sed 's,-.*,,' >> /tmp/ver_storage
+  cd -
+done
+IMAGE_VER=`sort -n /tmp/ver_image | head -n1`
+COMMON_VER=`sort -n /tmp/ver_common | head -n1`
+STORAGE_VER=`sort -n /tmp/ver_storage | head -n1`
+sed -i "s,^%global.*image_branch.*,%global image_branch $IMAGE_VER," containers-common.spec
+sed -i "s,^%global.*common_branch.*,%global common_branch $COMMON_VER," containers-common.spec
+sed -i "s,^%global.*storage_branch.*,%global storage_branch $STORAGE_VER," containers-common.spec
+rm -f /tmp/ver_image /tmp/ver_common /tmp/ver_storage
+rm -rf podman skopeo buildah

SOURCES/update.sh

@@ -0,0 +1,55 @@
+#!/bin/bash
+# This script delivers current documentation/configs and assures it has the intended
+# settings for a particular branch/release.
+# For questions reach to Jindrich Novy <jnovy@redhat.com>
+
+ensure() {
+  if grep ^$2[[:blank:]].*= $1 > /dev/null
+  then
+    sed -i "s;^$2[[:blank:]]=.*;$2 = $3;" $1
+  else
+    if grep ^\#.*$2[[:blank:]].*= $1 > /dev/null
+    then
+      sed -i "/^#.*$2[[:blank:]].*=/a \
+$2 = $3" $1
+    else
+      echo "$2 = $3" >> $1
+    fi
+  fi
+}
+
+#./pyxis.sh
+#./update-vendored.sh
+spectool -f -g containers-common.spec
+for FILE in *; do
+  [ -s "$FILE" ]
+  if [ $? == 1 ] && [ "$FILE" != "sources" ]; then
+    echo "empty file: $FILE"
+    exit 1
+  fi
+done
+ensure storage.conf    driver                        \"overlay\"
+ensure storage.conf    mountopt                      \"nodev,metacopy=on\"
+if pwd | grep rhel-8 > /dev/null
+then
+awk -i inplace '/#default_capabilities/,/#\]/{gsub("#","",$0)}1' containers.conf
+ensure registries.conf unqualified-search-registries [\"registry.access.redhat.com\",\ \"registry.redhat.io\",\ \"docker.io\"]
+ensure registries.conf short-name-mode               \"permissive\"
+ensure containers.conf runtime                       \"runc\"
+ensure containers.conf events_logger                 \"file\"
+ensure containers.conf log_driver                    \"k8s-file\"
+ensure containers.conf network_backend               \"cni\"
+if ! grep \"NET_RAW\" containers.conf > /dev/null
+then
+  sed -i '/^default_capabilities/a \
+  "NET_RAW",' containers.conf
+fi
+else
+ensure registries.conf unqualified-search-registries [\"registry.access.redhat.com\",\ \"registry.redhat.io\",\ \"docker.io\"]
+ensure registries.conf short-name-mode               \"enforcing\"
+ensure containers.conf runtime                       \"crun\"
+fi
+[ `grep \"keyctl\", seccomp.json | wc -l` == 0 ] && sed -i '/\"kill\",/i \
+				"keyctl",' seccomp.json
+[ `grep \"socket\", seccomp.json | wc -l` == 0 ] && sed -i '/\"socketcall\",/i \
+				"socket",' seccomp.json

SPECS/containers-common.spec

@@ -0,0 +1,380 @@
+# Bellow definitions are used to deliver config files from a particular branch
+# of c/image, c/common, c/storage vendored in all podman, skopeo, buildah.
+# These vendored components must have the same version. If it is not the case,
+# pick the oldest version on c/image, c/common, c/storage vendored in
+# podman/skopeo/podman.
+%global skopeo_branch main
+%global image_branch v5.24.0
+%global common_branch v0.51.0
+%global storage_branch v1.45.3
+%global shortnames_branch main
+
+Epoch: 2
+Name: containers-common
+Version: 1
+Release: 49%{?dist}
+Summary: Common configuration and documentation for containers
+License: ASL 2.0
+ExclusiveArch: %{go_arches}
+BuildRequires: /usr/bin/go-md2man
+Provides: skopeo-containers = %{epoch}:%{version}-%{release}
+Conflicts: %{name} <= 2:1-22
+Obsoletes: %{name} <= 2:1-22
+Requires: (container-selinux >= 2:2.162.1 if selinux-policy)
+Requires: oci-runtime
+%if 0%{?rhel} >= 9 || 0%{?fedora}
+Requires: crun >= 0.19
+%else
+Requires: runc
+%endif
+Requires: system-release
+Suggests: subscription-manager
+Recommends: fuse-overlayfs
+Recommends: slirp4netns
+Source1: https://raw.githubusercontent.com/containers/storage/%{storage_branch}/storage.conf
+Source2: https://raw.githubusercontent.com/containers/storage/%{storage_branch}/docs/containers-storage.conf.5.md
+Source3: mounts.conf
+Source4: https://raw.githubusercontent.com/containers/image/%{image_branch}/docs/containers-registries.conf.5.md
+#Source5: https://raw.githubusercontent.com/containers/image/%%{image_branch}/registries.conf
+Source5: registries.conf
+Source6: https://raw.githubusercontent.com/containers/image/%{image_branch}/docs/containers-policy.json.5.md
+Source7: https://raw.githubusercontent.com/containers/common/%{common_branch}/pkg/seccomp/seccomp.json
+Source8: https://raw.githubusercontent.com/containers/common/%{common_branch}/docs/containers-mounts.conf.5.md
+Source9: https://raw.githubusercontent.com/containers/image/%{image_branch}/docs/containers-signature.5.md
+Source10: https://raw.githubusercontent.com/containers/image/%{image_branch}/docs/containers-transports.5.md
+Source11: https://raw.githubusercontent.com/containers/image/%{image_branch}/docs/containers-certs.d.5.md
+Source12: https://raw.githubusercontent.com/containers/image/%{image_branch}/docs/containers-registries.d.5.md
+Source13: https://raw.githubusercontent.com/containers/common/%{common_branch}/pkg/config/containers.conf
+Source14: https://raw.githubusercontent.com/containers/common/%{common_branch}/docs/containers.conf.5.md
+Source15: https://raw.githubusercontent.com/containers/image/%{image_branch}/docs/containers-auth.json.5.md
+Source16: https://raw.githubusercontent.com/containers/image/%{image_branch}/docs/containers-registries.conf.d.5.md
+Source17: https://raw.githubusercontent.com/containers/shortnames/%{shortnames_branch}/shortnames.conf
+Source19: 001-rhel-shortnames-pyxis.conf
+Source20: 002-rhel-shortnames-overrides.conf
+Source21: RPM-GPG-KEY-redhat-release
+Source22: registry.access.redhat.com.yaml
+Source23: registry.redhat.io.yaml
+#Source24: https://raw.githubusercontent.com/containers/skopeo/%%{skopeo_branch}/default-policy.json
+Source24: default-policy.json
+Source25: https://raw.githubusercontent.com/containers/skopeo/%{skopeo_branch}/default.yaml
+# FIXME: fix the branch once these are available via regular c/common branch
+Source26: https://raw.githubusercontent.com/containers/common/main/docs/Containerfile.5.md
+Source27: https://raw.githubusercontent.com/containers/common/main/docs/containerignore.5.md
+Source28: RPM-GPG-KEY-redhat-beta
+
+# scripts used for synchronization with upstream and shortname generation
+Source100: update.sh
+Source101: update-vendored.sh
+Source102: pyxis.sh
+
+%description
+This package contains common configuration files and documentation for container
+tools ecosystem, such as Podman, Buildah and Skopeo.
+
+It is required because the most of configuration files and docs come from projects
+which are vendored into Podman, Buildah, Skopeo, etc. but they are not packaged
+separately.
+
+%prep
+
+%build
+
+%install
+install -dp %{buildroot}%{_sysconfdir}/containers/{certs.d,oci/hooks.d,systemd,registries.d,registries.conf.d}
+install -dp %{buildroot}%{_datadir}/containers/systemd
+install -m0644 %{SOURCE1} %{buildroot}%{_sysconfdir}/containers/storage.conf
+install -m0644 %{SOURCE5} %{buildroot}%{_sysconfdir}/containers/registries.conf
+install -m0644 %{SOURCE17} %{buildroot}%{_sysconfdir}/containers/registries.conf.d/000-shortnames.conf
+install -m0644 %{SOURCE19} %{buildroot}%{_sysconfdir}/containers/registries.conf.d/001-rhel-shortnames.conf
+install -m0644 %{SOURCE20} %{buildroot}%{_sysconfdir}/containers/registries.conf.d/002-rhel-shortnames-overrides.conf
+
+# for signature verification
+%if !0%{?rhel} || 0%{?centos}
+install -dp %{buildroot}%{_sysconfdir}/pki/rpm-gpg
+install -m0644 %{SOURCE21} %{buildroot}%{_sysconfdir}/pki/rpm-gpg
+install -m0644 %{SOURCE28} %{buildroot}%{_sysconfdir}/pki/rpm-gpg
+%endif
+install -dp %{buildroot}%{_sysconfdir}/containers/registries.d
+install -m0644 %{SOURCE22} %{buildroot}%{_sysconfdir}/containers/registries.d
+install -m0644 %{SOURCE23} %{buildroot}%{_sysconfdir}/containers/registries.d
+install -m0644 %{SOURCE24} %{buildroot}%{_sysconfdir}/containers/policy.json
+install -dp %{buildroot}%{_sharedstatedir}/containers/sigstore
+install -m0644 %{SOURCE25} %{buildroot}%{_sysconfdir}/containers/registries.d/default.yaml
+
+# for containers-common
+install -dp %{buildroot}%{_mandir}/man5
+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/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
+go-md2man -in %{SOURCE14} -out %{buildroot}%{_mandir}/man5/containers.conf.5
+go-md2man -in %{SOURCE15} -out %{buildroot}%{_mandir}/man5/containers-auth.json.5
+go-md2man -in %{SOURCE16} -out %{buildroot}%{_mandir}/man5/containers-registries.conf.d.5
+go-md2man -in %{SOURCE26} -out %{buildroot}%{_mandir}/man5/Containerfile.5
+go-md2man -in %{SOURCE27} -out %{buildroot}%{_mandir}/man5/containerignore.5
+
+install -dp %{buildroot}%{_datadir}/containers
+install -m0644 %{SOURCE3} %{buildroot}%{_datadir}/containers/mounts.conf
+install -m0644 %{SOURCE7} %{buildroot}%{_datadir}/containers/seccomp.json
+install -m0644 %{SOURCE13} %{buildroot}%{_datadir}/containers/containers.conf
+
+# install secrets patch directory
+install -d -p -m 755 %{buildroot}/%{_datadir}/rhel/secrets
+# rhbz#1110876 - update symlinks for subscription management
+ln -s %{_sysconfdir}/pki/entitlement %{buildroot}%{_datadir}/rhel/secrets/etc-pki-entitlement
+ln -s %{_sysconfdir}/rhsm %{buildroot}%{_datadir}/rhel/secrets/rhsm
+ln -s %{_sysconfdir}/yum.repos.d/redhat.repo %{buildroot}%{_datadir}/rhel/secrets/redhat.repo
+
+# ship preconfigured /etc/containers/registries.d/ files with containers-common - #1903813
+cat <<EOF > %{buildroot}%{_sysconfdir}/containers/registries.d/registry.access.redhat.com.yaml
+docker:
+     registry.access.redhat.com:
+         sigstore: https://access.redhat.com/webassets/docker/content/sigstore
+EOF
+
+cat <<EOF > %{buildroot}%{_sysconfdir}/containers/registries.d/registry.redhat.io.yaml
+docker:
+     registry.redhat.io:
+         sigstore: https://registry.redhat.io/containers/sigstore
+EOF
+
+%files
+%dir %{_sysconfdir}/containers
+%dir %{_sysconfdir}/containers/certs.d
+%dir %{_sysconfdir}/containers/registries.d
+%dir %{_sysconfdir}/containers/oci
+%dir %{_sysconfdir}/containers/oci/hooks.d
+%dir %{_sysconfdir}/containers/registries.conf.d
+%dir %{_sysconfdir}/containers/systemd
+%dir %{_datadir}/containers/systemd
+%if !0%{?rhel} || 0%{?centos}
+%{_sysconfdir}/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
+%{_sysconfdir}/pki/rpm-gpg/RPM-GPG-KEY-redhat-beta
+%endif
+%config(noreplace) %{_sysconfdir}/containers/policy.json
+%config(noreplace) %{_sysconfdir}/containers/storage.conf
+%config(noreplace) %{_sysconfdir}/containers/registries.conf
+%config(noreplace) %{_sysconfdir}/containers/registries.conf.d/*.conf
+%config(noreplace) %{_sysconfdir}/containers/registries.d/default.yaml
+%config(noreplace) %{_sysconfdir}/containers/registries.d/registry.redhat.io.yaml
+%config(noreplace) %{_sysconfdir}/containers/registries.d/registry.access.redhat.com.yaml
+%ghost %{_sysconfdir}/containers/containers.conf
+%dir %{_sharedstatedir}/containers/sigstore
+%{_mandir}/man5/*
+%dir %{_datadir}/containers
+%{_datadir}/containers/mounts.conf
+%{_datadir}/containers/seccomp.json
+%{_datadir}/containers/containers.conf
+%dir %{_datadir}/rhel/secrets
+%{_datadir}/rhel/secrets/*
+
+%changelog
+* Tue Jan 31 2023 Jindrich Novy <jnovy@redhat.com> - 2:1-49
+- add missing systemd directories
+- Related: #2124478
+
+* Mon Jan 30 2023 Jindrich Novy <jnovy@redhat.com> - 2:1-48
+- update vendored components and configuration files
+- Related: #2124478
+
+* Thu Jan 05 2023 Jindrich Novy <jnovy@redhat.com> - 2:1-47
+- update vendored components, regenerate pyxis
+- Related: #2124478
+
+* Thu Nov 10 2022 Jindrich Novy <jnovy@redhat.com> - 2:1-46
+- The NET_RAW capability was required in RHEL8 but no longer required in RHEL9
+- Resolves: #2141531
+
+* Fri Oct 21 2022 Jindrich Novy <jnovy@redhat.com> - 2:1-45
+- add beta GPG key
+- Related: #2124478
+
+* Tue Aug 23 2022 Jindrich Novy <jnovy@redhat.com> - 2:1-44
+- exclude non-go arches because of go-md2man
+- Related: #2061316
+
+* Tue Aug 23 2022 Jindrich Novy <jnovy@redhat.com> - 2:1-43
+- add beta keys to default-policy.json
+- Related: #2061316
+
+* Mon Aug 08 2022 Jindrich Novy <jnovy@redhat.com> - 2:1-42
+- update shortnames
+- Related: #2061316
+
+* Wed Aug 03 2022 Jindrich Novy <jnovy@redhat.com> - 2:1-41
+- drop aardvark-dns and netavark - packaged separately
+- update vendored components
+- Related: #2061316
+
+* Mon Jun 27 2022 Jindrich Novy <jnovy@redhat.com> - 2:1-40
+- remove rhel-els and update shortnames
+- Related: #2061316
+
+* Tue Jun 14 2022 Jindrich Novy <jnovy@redhat.com> - 2:1-39
+- update shortnames
+- Related: #2061316
+
+* Thu Jun 09 2022 Jindrich Novy <jnovy@redhat.com> - 2:1-38
+- fix unqualified registries in registries.conf generation code
+- Related: #2088139
+
+* Mon May 23 2022 Jindrich Novy <jnovy@redhat.com> - 2:1-37
+- update unqualified registries list
+- Related: #2088139
+
+* Mon May 09 2022 Jindrich Novy <jnovy@redhat.com> - 2:1-36
+- update aardvark-dns and netavark to 1.0.3
+- update vendored components
+- Related: #2061316
+
+* Wed Apr 20 2022 Jindrich Novy <jnovy@redhat.com> - 2:1-35
+- add missing man pages from Fedora
+- Related: #2061316
+
+* Wed Apr 06 2022 Jindrich Novy <jnovy@redhat.com> - 2:1-34
+- update to netavark and aardvark-dns 1.0.2
+- update vendored components
+- Related: #2061316
+
+* Mon Mar 21 2022 Jindrich Novy <jnovy@redhat.com> - 2:1-33
+- allow consuming aardvark-dns and netavark from upstream branches
+- Related: #2061316
+
+* Mon Feb 28 2022 Jindrich Novy <jnovy@redhat.com> - 2:1-32
+- build rust packages with RUSTFLAGS set to make ExecShield happy (Lokesh Mandvekar)
+- Related: #2000051
+
+* Mon Feb 28 2022 Jindrich Novy <jnovy@redhat.com> - 2:1-31
+- update to netavark and aardvark-dns 1.0.1
+- Related: #2000051
+
+* Wed Feb 23 2022 Lokesh Mandvekar <lsm5@redhat.com> - 2:1-30
+- archful package should conflict with older noarch package
+- Related: #2000051
+
+* Tue Feb 22 2022 Lokesh Mandvekar <lsm5@redhat.com> - 2:1-29
+- consistent release tags for all packages
+- Related: #2000051
+
+* Tue Feb 22 2022 Lokesh Mandvekar <lsm5@redhat.com> - 2:1-28
+- main package should obsolete noarch versions upto 2:1-22
+- Related: #2000051
+
+* Mon Feb 21 2022 Lokesh Mandvekar <lsm5@redhat.com> - 2:1-27
+- do not specify infra_image in containers.conf
+- needed to resolve gating test failures
+- Related: #2000051
+
+* Sat Feb 19 2022 Lokesh Mandvekar <lsm5@redhat.com> - 2:1-26
+- aardvark-dns built for same arches as netavark
+- Related: #2000051
+
+* Sat Feb 19 2022 Lokesh Mandvekar <lsm5@redhat.com> - 2:1-25
+- build netavark only for podman's arches
+- i686 can't find go-md2man which causes the build to fail otherwise
+- Related: #2000051
+
+* Fri Feb 18 2022 Jindrich Novy <jnovy@redhat.com> - 2:1-24
+- update to netavark-1.0.0 and aardvark-dns-1.0.0
+- Related: #2000051
+
+* Thu Feb 17 2022 Jindrich Novy <jnovy@redhat.com> - 2:1-23
+- package aarvark-dns and netavark as part of the containers-common
+- Related: #2000051
+
+* Thu Feb 17 2022 Jindrich Novy <jnovy@redhat.com> - 2:1-22
+- update shortnames and vendored components
+- Related: #2000051
+
+* Wed Feb 16 2022 Jindrich Novy <jnovy@redhat.com> - 2:1-21
+- containers.conf should contain network_backend = "cni" in RHEL8.6
+- Related: #2000051
+
+* Wed Feb 09 2022 Jindrich Novy <jnovy@redhat.com> - 2:1-20
+- update shortname aliases from upstream
+- Related: #2000051
+
+* Fri Feb 04 2022 Jindrich Novy <jnovy@redhat.com> - 2:1-19
+- sync vendored components
+- Related: #2000051
+
+* Fri Feb 04 2022 Jindrich Novy <jnovy@redhat.com> - 2:1-18
+- sync vendored components
+- Related: #2000051
+
+* Mon Jan 17 2022 Jindrich Novy <jnovy@redhat.com> - 2:1-17
+- sync shortname aliases via Pyxis
+- Related: #2000051
+
+* Fri Dec 10 2021 Jindrich Novy <jnovy@redhat.com> - 2:1-16
+- do not hardcode log_driver = "journald" and events_logger = "journald"
+  for RHEL9 and leave the rootful/rootless behaviour change based on
+  internal logic
+- Related: #2000051
+
+* Thu Dec 09 2021 Jindrich Novy <jnovy@redhat.com> - 2:1-15
+- do not allow broken content from Pyxis to land in shortnames.conf
+- Related: #2000051
+
+* Wed Dec 08 2021 Jindrich Novy <jnovy@redhat.com> - 2:1-14
+- update vendored component versions
+- sync shortname aliases via Pyxis
+- Related: #2000051
+
+* Tue Nov 30 2021 Jindrich Novy <jnovy@redhat.com> - 2:1-13
+- use log_driver = "journald" and events_logger = "journald" for RHEL9
+- Related: #2000051
+
+* Tue Nov 16 2021 Jindrich Novy <jnovy@redhat.com> - 2:1-12
+- consume seccomp.json from the oldest vendored version of c/common,
+  not main branch
+- Related: #2000051
+
+* Fri Nov 12 2021 Jindrich Novy <jnovy@redhat.com> - 2:1-11
+- use ubi8/pause as ubi9/pause is not available yet
+- Related: #2000051
+
+* Wed Nov 10 2021 Jindrich Novy <jnovy@redhat.com> - 2:1-10
+- update vendored components
+- Related: #2000051
+
+* Tue Nov 02 2021 Jindrich Novy <jnovy@redhat.com> - 2:1-9
+- make log_driver = "k8s-file" default in containers.conf
+- Related: #2000051
+
+* Fri Oct 01 2021 Jindrich Novy <jnovy@redhat.com> - 2:1-8
+- perform only sanity/installability tests for now
+- Related: #2000051
+
+* Wed Sep 29 2021 Jindrich Novy <jnovy@redhat.com> - 2:1-7
+- update to the new vendored components
+- Related: #2000051
+
+* Wed Sep 29 2021 Jindrich Novy <jnovy@redhat.com> - 2:1-6
+- add gating.yaml
+- Related: #2000051
+
+* Fri Sep 24 2021 Jindrich Novy <jnovy@redhat.com> - 2:1-5
+- update to the new vendored components
+- Related: #2000051
+
+* Fri Sep 10 2021 Jindrich Novy <jnovy@redhat.com> - 2:1-4
+- fix updating scripts
+- Related: #2000051
+
+* Thu Sep 09 2021 Jindrich Novy <jnovy@redhat.com> - 2:1-3
+- update to the new vendored components
+- Related: #2000051
+
+* Fri Aug 20 2021 Lokesh Mandvekar <lsm5@fedoraproject.org> - 2:1-2
+- bump configs to latest versions
+- replace ubi9 references with ubi8
+- Related: #1970747
+
+* Wed Aug 11 2021 Jindrich Novy <jnovy@redhat.com> - 2:1-1
+- initial import
+- Related: #1970747