Source: gitsign Version: 0.13.0-2 Severity: important Tags: security upstream X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
Hi, The following vulnerabilities were published for gitsign. CVE-2026-44309[0]: | Gitsign is a keyless Sigstore to signing tool for Git commits with | your a GitHub / OIDC identity. Prior to 0.16.0, 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. This vulnerability is | fixed in 0.16.0. CVE-2026-44310[1]: | Gitsign is a keyless Sigstore to signing tool for Git commits with | your a GitHub / OIDC identity. From 0.4.0 to before 0.15.0, | 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. This vulnerability is | fixed in 0.15.0. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-44309 https://www.cve.org/CVERecord?id=CVE-2026-44309 https://github.com/sigstore/gitsign/security/advisories/GHSA-7rmh-48mx-2vwc [1] https://security-tracker.debian.org/tracker/CVE-2026-44310 https://www.cve.org/CVERecord?id=CVE-2026-44310 https://github.com/sigstore/gitsign/security/advisories/GHSA-7c37-gx6w-8vc5 Regards, Salvatore
