track: x/crypto is in go.mod only for the update signature check, so osv-scanner ignores GO-2026-5932 #621

New issue

Open

opened 2026-09-24 15:52:22 +00:00 by hexajon · 1 comment

hexajon commented

2026-09-24 15:52:22 +00:00

Owner

What

GO-2026-5932 says the golang.org/x/crypto/openpgp package is unsafe by design and unmaintained. No fixed version exists, and none will: the advisory covers the package itself.

madtea never builds that package. madtea update checks the release signature with github.com/ProtonMail/go-crypto/openpgp (internal/cmd/update/verify.go), the maintained fork the advisory recommends. That library pulls in other x/crypto packages (sha3, hkdf, argon2, blake2b, cast5, cryptobyte). Go records dependencies per module, so all of x/crypto sits in go.mod, and a module-level scan flags the advisory anyway.

I keep the ProtonMail library for now. The osv-scanner gate leg (#587) scans every module version, so it ignores this one advisory, and a test fails if madtea ever builds x/crypto/openpgp.

Why this issue stays open

An ignore entry is a standing exception. This issue tracks it until one of these makes it unnecessary:

The advisory or the x/crypto module changes so that madtea's version no longer matches.
The update signature check moves to a format that needs no third-party crypto, for example an Ed25519 signature checked with Go's standard crypto/ed25519. That would reverse ADR 0012, so it needs its own decision and a transition period, because installed binaries only check the .asc signature.
ProtonMail's library stops depending on x/crypto.

Related: ADR 0012 (release signing), #413 (sigstore for release artifacts), #587 (the osv-scanner leg).

Acceptance

The GO-2026-5932 ignore entry is removed, and the osv-scanner leg stays green without it.

## What GO-2026-5932 says the `golang.org/x/crypto/openpgp` package is unsafe by design and unmaintained. No fixed version exists, and none will: the advisory covers the package itself. madtea never builds that package. `madtea update` checks the release signature with `github.com/ProtonMail/go-crypto/openpgp` (`internal/cmd/update/verify.go`), the maintained fork the advisory recommends. That library pulls in other `x/crypto` packages (`sha3`, `hkdf`, `argon2`, `blake2b`, `cast5`, `cryptobyte`). Go records dependencies per module, so all of `x/crypto` sits in `go.mod`, and a module-level scan flags the advisory anyway. I keep the ProtonMail library for now. The osv-scanner gate leg (#587) scans every module version, so it ignores this one advisory, and a test fails if madtea ever builds `x/crypto/openpgp`. ## Why this issue stays open An ignore entry is a standing exception. This issue tracks it until one of these makes it unnecessary: - The advisory or the `x/crypto` module changes so that madtea's version no longer matches. - The update signature check moves to a format that needs no third-party crypto, for example an Ed25519 signature checked with Go's standard `crypto/ed25519`. That would reverse ADR 0012, so it needs its own decision and a transition period, because installed binaries only check the `.asc` signature. - ProtonMail's library stops depending on `x/crypto`. Related: ADR 0012 (release signing), #413 (sigstore for release artifacts), #587 (the osv-scanner leg). ## Acceptance - The GO-2026-5932 ignore entry is removed, and the osv-scanner leg stays green without it.

hexajon added the

security

label

2026-09-24 15:52:22 +00:00

hexajon referenced this issue

2026-09-24 16:03:52 +00:00

feat(gate): scan every lockfile with osv-scanner #622

hexajon commented

2026-09-24 16:23:47 +00:00

Author

Owner

I checked whether this setup follows the Go way. I keep PGP for now. The answer has two parts.

1. The signature library follows the Go way.

The deprecation notice on golang.org/x/crypto/openpgp (v0.57.0, openpgp/read.go) says:

New applications should consider a more focused, modern alternative to OpenPGP for their specific task. If you are required to interoperate with OpenPGP systems and need a maintained package, consider github.com/ProtonMail/go-crypto/openpgp, which is a maintained fork that aims to be a drop-in replacement for this package.

madtea does interoperate with OpenPGP. scripts/install.sh checks checksums.txt.asc with gpg --verify, SECURITY.md tells users to verify downloads by hand with gpg, and GoReleaser signs with gpg. That is the case where the Go authors point to the ProtonMail fork, and that is what madtea update uses. The "focused, modern alternative" (for example Ed25519) fits only if the installer, the manual steps, and the release signing all move off OpenPGP together.

2. The vulnerability scan does not follow the Go way.

govulncheck's own documentation (golang.org/x/vuln v1.8.0, cmd/govulncheck/doc.go) says it "uses static analysis of source code or a binary's symbol table to narrow down reports to only those that could affect the application", and that "There is no support for silencing vulnerability findings" (go.dev/issue/61211). The Go vulnerability page (go.dev/security/vuln) says govulncheck "only surfaces vulnerabilities that actually affect you, based on which functions in your code are transitively calling vulnerable functions."

So the Go way is to report by reachability, with no ignore list. Under it, GO-2026-5932 is not a finding for madtea: govulncheck reports nothing, because no madtea code imports x/crypto/openpgp.

The osv-scanner leg from #587 departs from that on purpose. It scans every module version, reached or not, and that found 6 real vulnerable versions govulncheck did not report. The cost is module-level false positives like this one, which need the ignore entry that Go's tool deliberately does not offer.

This issue stays open on that tension: the ignore entry exists only because the scan is stricter than the Go way.

I checked whether this setup follows the Go way. I keep PGP for now. The answer has two parts. **1. The signature library follows the Go way.** The deprecation notice on `golang.org/x/crypto/openpgp` (v0.57.0, `openpgp/read.go`) says: > New applications should consider a more focused, modern alternative to OpenPGP for their specific task. If you are required to interoperate with OpenPGP systems and need a maintained package, consider github.com/ProtonMail/go-crypto/openpgp, which is a maintained fork that aims to be a drop-in replacement for this package. madtea does interoperate with OpenPGP. `scripts/install.sh` checks `checksums.txt.asc` with `gpg --verify`, `SECURITY.md` tells users to verify downloads by hand with `gpg`, and GoReleaser signs with `gpg`. That is the case where the Go authors point to the ProtonMail fork, and that is what `madtea update` uses. The "focused, modern alternative" (for example Ed25519) fits only if the installer, the manual steps, and the release signing all move off OpenPGP together. **2. The vulnerability scan does not follow the Go way.** govulncheck's own documentation (`golang.org/x/vuln` v1.8.0, `cmd/govulncheck/doc.go`) says it "uses static analysis of source code or a binary's symbol table to narrow down reports to only those that could affect the application", and that "There is no support for silencing vulnerability findings" (go.dev/issue/61211). The Go vulnerability page (go.dev/security/vuln) says govulncheck "only surfaces vulnerabilities that actually affect you, based on which functions in your code are transitively calling vulnerable functions." So the Go way is to report by reachability, with no ignore list. Under it, GO-2026-5932 is not a finding for madtea: govulncheck reports nothing, because no madtea code imports `x/crypto/openpgp`. The osv-scanner leg from #587 departs from that on purpose. It scans every module version, reached or not, and that found 6 real vulnerable versions govulncheck did not report. The cost is module-level false positives like this one, which need the ignore entry that Go's tool deliberately does not offer. This issue stays open on that tension: the ignore entry exists only because the scan is stricter than the Go way.

hexajon referenced this issue

2026-10-13 22:23:04 +00:00

epic: code and supply-chain security hardening #759

hexajon added a new dependency

2026-10-13 22:23:14 +00:00

#759 epic: code and supply-chain security hardening