Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#2,167 4 bình luận 1 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
68/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go
Lĩnh vực
backend-api-design, security

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Go
Star
283
Fork
252
Merge trung bình
1 giờ 6 phút
Pull request đã merge (30 ngày)
12

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của fluxcd/source-controller

Tất cả issue của fluxcd/source-controller

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.