`OCIRepository`/cosign verification: support TSA-only trusted roots (no transparency log) for private Sigstore instances like GitHub Artifact Attestations
Maintainers usually reply within 1 day
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 68/100
- Issue type
- Feature
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- go
- Domain
- backend-api-design, security
Research direction
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.
Written by the indexing model from the issue text.
Description
(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
- 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 ontimestampAuthorities). - Configure an
OCIRepositorywithverify.provider: cosign,verify.trustedRootSecretRefpointing at that trusted root, noverify.secretRef. - 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
OCIRepositoryspec 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.
- Dominant language
- Go
- Stars
- 285
- Forks
- 259
- Avg merge
- 2d 14h
- Merged PRs (30d)
- 16
Getting set up
- Ships a Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from fluxcd/source-controller
-
OCIRepository: pick the Helm chart layer automatically when the first layer is a provenance filePossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
fluxcd/source-controller#2198 ·
Maintainers usually reply within 1 day
-
Improve documentation on debugging the controller locallyMay be free again @Bryandero98 claimed this 37 days ago, and no pull request is open. Openarea/docs good first issue help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
fluxcd/source-controller#666 · 2 comments ·
Maintainers usually reply within 1 day
-
area/oci enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
fluxcd/source-controller#2180 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
fluxcd/source-controller#2150 ·
Maintainers usually reply within 1 day
-
GitRepository `.spec.ref.commit` + `.spec.ref.branch` does not shallow clone, contrary to the docsOpen
Difficulty 5/5 Over a week Newbie friendliness 42/100
fluxcd/source-controller#2146 · 2 comments ·
Maintainers usually reply within 1 day
All issues in fluxcd/source-controller
Similar issues
-
compress: block buffers get re-zeroed on every call, and the zeroing is immediately overwrittenOpen
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
ClickHouse/ch-go#1218 ·
Maintainers usually reply within 13 days
-
effort:s impact:low raised-by:reviewer risk:low
Difficulty 1/5 Under an hour Newbie friendliness 84/100
medici-finance/assay#4251 · 1 comment ·
Maintainers usually reply within 1 day
-
automation models
Difficulty 1/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
golang-migrate/migrate#1457 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
Maintainers usually reply within 1 day