--certificate-identity or --certificate-identity-regexp is required for verification in keyless mode

cosign también exige `--certificate-oidc-issuer` (o `--certificate-oidc-issuer-regexp`); la opción de identidad se comprueba primero. cosign 1.x aceptaba la verificación keyless sin estas opciones.

Sigstore cosign 2.x/3.x — verify / verify-blob / verify-attestation without --key

Qué significa

Sin `--key`, cosign verifica firmas «keyless» (sin clave): un certificado de corta duración emitido por Fulcio vincula la firma a una identidad OIDC (un flujo de trabajo de CI, un correo electrónico). Una firma keyless válida solo demuestra que *alguien* con *alguna* identidad firmó, así que cosign 2.0 y posteriores exigen que indiques de quién aceptas la firma. El comando se detiene antes de leer el bundle hasta que indiques la identidad y el emisor esperados.

Por qué ocurre

• Comandos de la documentación de cosign 1.x

  frecuente

  `COSIGN_EXPERIMENTAL=1 cosign verify image` funcionaba en 1.x y verificaba cualquier identidad. Copiado en un pipeline de 2.x/3.x, falla aquí.

• Aún no conoces la identidad del firmante

  frecuente

  La identidad es el SAN del certificado: en GitHub Actions, la URL del flujo de trabajo con su ref; en la firma interactiva, una dirección de correo electrónico. Los proyectos la documentan junto a sus instrucciones de verificación.

• Un artefacto firmado con clave verificado sin --key

  ocasional

  Si el artefacto se firmó con un par de claves, pasa `--key cosign.pub`; así no hacen falta las opciones de identidad.

Cómo solucionarlo

1. 1.

   Fijar la identidad del flujo de trabajo y el emisor

   En GitHub Actions, el emisor es `https://token.actions.githubusercontent.com` y la identidad es el archivo del flujo de trabajo en una ref.

   # Artifacts signed in GitHub Actions: identity = workflow file at a ref, issuer = GitHub's OIDC issuer
   cosign verify-blob \
     --bundle app.sigstore.json \
     --certificate-identity "https://github.com/acme/app/.github/workflows/release.yml@refs/tags/v1.4.2" \
     --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
     app.tar.gz

2. 2.

   Usar una expresión regular anclada para rangos de identidades

   `--certificate-identity-regexp` permite aceptar todas las etiquetas de un mismo flujo de trabajo. Ánclala; si no, puede coincidir el flujo de trabajo de un fork.

   # Any release tag of that workflow - anchor the expression
   cosign verify ghcr.io/acme/app:1.4.2 \
     --certificate-identity-regexp '^https://github\.com/acme/app/\.github/workflows/release\.yml@refs/tags/v[0-9]+\.[0-9]+\.[0-9]+$' \
     --certificate-oidc-issuer https://token.actions.githubusercontent.com

3. 3.

   Leer la identidad del certificado

   El nombre alternativo del sujeto del certificado del bundle es el valor que debes fijar, una vez que decidas que esa es la identidad en la que confías.

   # Read the identity recorded in the signing certificate of a bundle
   jq -r '.verificationMaterial.certificate.rawBytes' app.sigstore.json | base64 -d \
     | openssl x509 -inform DER -noout -ext subjectAltName

← Explorar toda la base de datos de errores de firma