Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

`OCIRepository`/cosign verification: support TSA-only trusted roots (no transparency log) for private Sigstore instances like GitHub Artifact Attestations

Abierto
  • ¿Algo no está bien?
#2,167 4 comentarios 1 reacción 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
68/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
go
Área
backend-api-design, security

Línea de trabajo

Start with internal/oci/cosign/cosign.go and NewCosignVerifier, then locate OCIRepositoryVerification and its trusted-root handling. Verify the proposed explicit TSA-only option accepts roots with no tlogs while preserving certificate identity checks, and run or extend the repository’s existing verification coverage to confirm both successful and rejected identities.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

area/oci area/security enhancement

(generated with claude sonnet 5)

Summary

OCIRepository.spec.verify.trustedRootSecretRef currently requires the supplied trusted_root.json to contain at least one transparency-log (Rekor) entry, and the underlying verification also requires at least one Certificate Transparency SCT on the signing certificate. Both requirements are hard-coded with no way to opt out via the CRD, even though the sigstore/cosign library that Flux already depends on fully supports skipping both checks in favor of RFC 3161 timestamp-only verification (CheckOpts.IgnoreTlog + CheckOpts.UseSignedTimestamps + CheckOpts.IgnoreSCT, exposed on the cosign CLI as --insecure-ignore-tlog --use-signed-timestamps --insecure-ignore-sct).

This makes it impossible to verify artifacts signed by private/enterprise Sigstore instances that don't operate a public transparency log or CT log by design — for example, GitHub's private Sigstore instance used for Artifact Attestations on private/internal repositories. GitHub explicitly does not log these to any transparency log (that's the entire point of the private instance — avoiding leaking private repo/workflow metadata into a public, permanent record), and substitutes an embedded RFC 3161 timestamp instead.

Current behavior

internal/oci/cosign/cosign.go, NewCosignVerifier:

rekorURL, err := rekorURLFromTrustedRoot(customRoot)
if err != nil {
    return nil, fmt.Errorf("unable to extract Rekor URL from trusted root: %w", err)
}

If the supplied trusted root has zero tlogs entries, verifier construction fails outright before any signature/attestation checking is attempted.

Separately, even once past that, verification of a bundle with no CT-logged certificate fails with:

failed to verify signed certificate timestamp: only able to verify 0 SCT entries; unable to meet threshold of 1

Reproduction

  1. Sign/attest an OCI artifact using a private Sigstore instance whose trusted root has no transparency log (e.g. gh attestation trusted-root's private-instance entry has "tlogs": [] and relies solely on timestampAuthorities).
  2. Configure an OCIRepository with verify.provider: cosign, verify.trustedRootSecretRef pointing at that trusted root, no verify.secretRef.
  3. Reconciliation fails at verifier construction (unable to extract Rekor URL from trusted root: no transparency log entries found in trusted root), before any signature is even checked.

Proposed solution

Add an explicit opt-in to OCIRepositoryVerification (naming to match cosign's own CLI convention), e.g.:

verify:
  provider: cosign
  trustedRootSecretRef:
    name: private-sigstore-trusted-root
  trustedInfrastructure: true   # new field

When set, NewCosignVerifier skips rekorURLFromTrustedRoot/newRekorClient entirely and instead sets:

checkOpts.IgnoreTlog = true
checkOpts.UseSignedTimestamps = true
checkOpts.IgnoreSCT = true

This mirrors cosign's own --private-infrastructure / --insecure-ignore-tlog --use-signed-timestamps --insecure-ignore-sct combination almost exactly, and requires no changes elsewhere — the RFC 3161 timestamp and TSA cert chain needed for verification already flow through the same checkOpts.TrustedMaterial built from the supplied trusted root.

Evidence this works

I prototyped this exact change against a local fluxcd/source-controller checkout (pinned sigstore/cosign/v3 v3.0.6) and verified it end-to-end against a real OCI artifact carrying a real actions/attest@v4-produced Sigstore v3 bundle attestation (discovered via cosign.GetBundles/cosign.VerifyImageAttestations, so this also confirms Flux's existing bundle-discovery path already picks up actions/attest-produced attestations with no other changes needed):

  • Correct matchOIDCIdentity → verification succeeds.
  • Deliberately wrong identity → verification fails closed with a clear certificate-identity-mismatch error, confirming this doesn't weaken identity-based access control, only the transparency-log/CT-log requirement.

Alternatives considered

  • Inferring "TSA-only mode" automatically whenever the supplied trusted root has zero tlogs, rather than an explicit field. I'd lean against this for a real PR — it could silently downgrade security if a trusted root ends up empty due to misconfiguration rather than intentional design, whereas an explicit opt-in makes the tradeoff visible in the OCIRepository spec itself.

Offer

Happy to open a PR for this if the approach (explicit opt-in field, mirroring cosign's own --private-infrastructure naming) sounds reasonable to maintainers.

Lenguaje dominante
Go
Estrellas
283
Forks
252
Merge medio
1 h 4 min
PR fusionados (30 d)
11

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de fluxcd/source-controller

Todos los issues de fluxcd/source-controller

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.