From 556dc2220d36b079b83a50c3f6f2df454005bc99 Mon Sep 17 00:00:00 2001
From: Jindrich Novy <jnovy@redhat.com>
Date: Tue, 27 Aug 2024 10:52:42 +0200
Subject: [PATCH] containers-common-1-92.el9

- update vendored components
- Related: RHEL-27608

Signed-off-by: Jindrich Novy <jnovy@redhat.com>
---
 containers-common.spec      | 10 +++++++---
 containers-policy.json.5.md | 13 ++++++++++---
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/containers-common.spec b/containers-common.spec
index 1f04266..641a1dd 100644
--- a/containers-common.spec
+++ b/containers-common.spec
@@ -4,15 +4,15 @@
 # pick the oldest version on c/image, c/common, c/storage vendored in
 # podman/skopeo/podman.
 %global skopeo_branch main
-%global image_branch v5.32.0
-%global common_branch v0.60.0
+%global image_branch v5.32.2
+%global common_branch v0.60.2
 %global storage_branch v1.55.0
 %global shortnames_branch main
 
 Epoch: 2
 Name: containers-common
 Version: 1
-Release: 91%{?dist}
+Release: 92%{?dist}
 Summary: Common configuration and documentation for containers
 License: ASL 2.0
 ExclusiveArch: %{go_arches}
@@ -173,6 +173,10 @@ EOF
 %{_datadir}/rhel/secrets/*
 
 %changelog
+* Tue Aug 27 2024 Jindrich Novy <jnovy@redhat.com> - 2:1-92
+- update vendored components
+- Related: RHEL-27608
+
 * Wed Aug 07 2024 Jindrich Novy <jnovy@redhat.com> - 2:1-91
 - Update shortnames and vendored components
 - Related: RHEL-27608
diff --git a/containers-policy.json.5.md b/containers-policy.json.5.md
index 909d04a..ad3a1f5 100644
--- a/containers-policy.json.5.md
+++ b/containers-policy.json.5.md
@@ -320,7 +320,9 @@ This requirement requires an image to be signed using a sigstore signature with
 {
     "type":    "sigstoreSigned",
     "keyPath": "/path/to/local/public/key/file",
+    "keyPaths": ["/path/to/first/public/key/one", "/path/to/first/public/key/two"],
     "keyData": "base64-encoded-public-key-data",
+    "keyDatas": ["base64-encoded-public-key-one-data", "base64-encoded-public-key-two-data"]
     "fulcio": {
         "caPath": "/path/to/local/CA/file",
         "caData": "base64-encoded-CA-data",
@@ -328,28 +330,33 @@ This requirement requires an image to be signed using a sigstore signature with
         "subjectEmail", "expected-signing-user@example.com",
     },
     "rekorPublicKeyPath": "/path/to/local/public/key/file",
+    "rekorPublicKeyPaths": ["/path/to/local/public/key/one","/path/to/local/public/key/two"],
     "rekorPublicKeyData": "base64-encoded-public-key-data",
+    "rekorPublicKeyDatas": ["base64-encoded-public-key-one-data","base64-encoded-public-key-two-data"],
     "signedIdentity": identity_requirement
 }
 ```
-Exactly one of `keyPath`, `keyData` and `fulcio` must be present.
+Exactly one of `keyPath`, `keyPaths`, `keyData`, `keyDatas` 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 `keyPaths` or `keyDatas` is present, it contains sigstore public keys.
+Only signatures made by any key in the list 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;
+At most one of `rekorPublicKeyPath`, `rekorPublicKeyPaths`, `rekorPublicKeyData` and `rekorPublicKeyDatas` 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.
+signed by one of the provided public keys.
 
 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).