Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
sigstore-go fails to check signature timestamps against a signing key's validity period for self-managed long-lived keys without certificates. Impact To verify a bundle with a self-managed long-lived key, the key needs to be wrapped in an ExpiringKey type that implies expiration semantics: Despite the API contract, the validator does not check the bundle signing time against the validity window. Attackers that obtain expired key materials may be able to sign bundles with those materials that are accepted despite a configured expiry date. This issue only impacts the long-lived signing key workflow, and not standard deployments involving a certificate authority. Reproduction steps Start from a sigstore-go checkout: Apply the [patch] containing the test case and associated materials: Run the test: On vulnerable code, the test fails because verification succeeds even though the trusted ExpiringKey is not valid at the signed timestamp: [patch]:…
Recommended action: Upgrade to 1.2.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact What kind of vulnerability is it? Who is impacted? A verifier configured with WithTransparencyLog(N1) or WithSignedCertificateTimestamps(N1) expected defense-in-depth against the compromise of a single log instance. However, threshold counting counted verified witnesses per-entry or per-validation-path rather than per-log-authority. As a result, a single compromised transparency log could forge multiple entries with different indices, and a single compromised CT log could verify multiple times (either across multiple certificate chains or via multiple embedded SCTs), fully satisfying the multi-log threshold requirements and defeating the multi-log policy. Note that this does not affect Cosign, as Cosign sets a threshold of 1. Patches Has the problem been patched? What versions should users upgrade to? Upgrade to v1.1.5. Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? There is no workaround, beyond relying on trusted logs.
Recommended action: Upgrade to 1.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact sigstore-go is susceptible to a denial of service attack when a verifier is provided a maliciously crafted Sigstore Bundle containing large amounts of verifiable data, in the form of signed transparency log entries, RFC 3161 timestamps, and attestation subjects. The verification of these data structures is computationally expensive. This can be used to consume excessive CPU resources, leading to a denial of service attack. TUF's security model labels this type of vulnerability an "Endless data attack," and can lead to verification failing to complete and disrupting services that rely on sigstore-go for verification. The vulnerable loops are in the verification functions in the package github.com/sigstore/sigstore-go/pkg/verify. The first is the DSSE envelope verification loop in verifyEnvelopeWithArtifact, which decodes all the digests in an attestation can be found here:…
Recommended action: Upgrade to 0.6.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.