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
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
gitsign verify and gitsign verify-tag re-encode commit/tag objects through go-git's EncodeWithoutSignature before checking the signature, instead of verifying against the raw git object bytes. For malformed objects with duplicate tree headers, git-core and go-git parse different trees: git-core uses the first, go-git uses the second. A signature crafted over the go-git-normalized form (second tree) passes gitsign verify while git-core resolves the commit to a completely different tree. This breaks the invariant that a verified signature, the commit semantics git-core presents to users, and the object hash logged in Rekor all refer to the same content. Severity Medium (CVSS 3.1: 5.7) CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N - Attack Vector: Network — a malformed commit can be distributed via any accessible git remote - Attack Complexity: High — exploitation requires crafting malformed objects that also bypass git server fsck checks (not universally enabled) - Privileges…
Recommended action: Upgrade to 0.16.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
CertVerifier.Verify() in pkg/git/verifier.go unconditionally dereferences certs[0] after sd.GetCertificates() without checking the slice length. A CMS/PKCS7 signed message with an empty certificate set is a structurally valid DER payload; GetCertificates() returns an empty slice with no error, causing an immediate index-out-of-range panic. On the gitsign --verify code path (the GPG-compatible mode invoked by git verify-commit), the panic is silently recovered by internal/io/streams.go's Wrap() function, which returns nil instead of an error. main.go then exits with code 0, causing exit-code-only verification callers to interpret the failed verification as success. Severity Medium (CVSS 3.1: 5.8) CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L - Attack Vector: Network — attacker pushes a commit carrying a crafted signature to any accessible repository, or delivers the signature file out-of-band - Attack Complexity: Low — stripping certificates from a PKCS7 object requires only…
Recommended action: Upgrade to 0.15.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
gitsign may select the wrong Rekor entry to use during online verification when multiple entries are returned by the log. Details gitsign uses Rekor's search API to fetch entries that apply to a signature being verified. The parameters used for the search are the public key and the payload. The search API returns entries that match either condition rather than both. When gitsign's credential cache is used, there can be multiple entries that use the same ephemeral keypair / signing certificate. As gitsign assumes both conditions are matched by Rekor, there is no additional validation that the entry's hash matches the payload being verified, meaning that the wrong entry can be used to successfully pass verification. PoC Enable the credential cache and create commit signatures using the cached signing certificate. gitsign verify or git log --show-signature will demonstrate the use of the wrong entry index for the corresponding commit. Note that this depends on the order of…
Recommended action: Upgrade to 0.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In certain versions of gitsign, Rekor public keys were fetched via the Rekor API, instead of through the local TUF client. If the upstream Rekor server happened to be compromised, gitsign clients could potentially be tricked into trusting incorrect signatures. There is no known compromise the default public good instance (rekor.sigstore.dev) - anyone using this instance is unlikely to be affected. Patches This was fixed in v0.8.0 via https://github.com/sigstore/gitsign/pull/399 Workarounds n/a References Are there any links users can visit to find out more? https://docs.sigstore.dev/about/threat-model/#sigstore-threat-model
Recommended action: Upgrade to 0.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.