[internal-branch.go1.25-vendor] sumdb: ignore unrelated hashes in Lookup During Lookup, if the server returns a validly signed record for an unrelated module which contains in the signed tree head another hash for the module which was requested in the "extension" portion of the signed tree head (anything following the tree hash, but before the signatures), _only_ the unrelated hashes are validated by checking the relevant tiles, ignoring the portion in the tree head. Lookup would then look for hash lines which match the requested module path in the fully returned record, not just the validated portion, causing only the hash appended to the tree head portion to be returned. This would allow a malicious sumdb instance to return a validly signed response for a module from which Lookup would return a hash which is not actually present in the tree. This would allow a conspiring malicious sumdb and module proxy (or a module proxy which is proxying the sumdb _and has the sumdb key_) to serve malicious module content which is not recorded in the transparency log. The fix is quite simple, instead of caching the full record, we only cache the hash lines returned by tlog.ParseRecord, which are validated. Lookup will then only extract matching hashes from the validated portion, instead of the full record. Thanks to Mundur (https://github.com/M0nd0R) for reporting this issue. Fixes CVE-2026-56864 For golang/go#80745. Change-Id: I4a418620e8e4e8ab5f7ec41b0ed443a92e9be6e1 Reviewed-on: https://go-review.googlesource.com/c/mod/+/815000 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Gopher Robot <gobot@golang.org> Reviewed-by: Neal Patel <nealpatel@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit 57549bfb0d25b5ff7eb4763aa1f029d7e5383232) Reviewed-on: https://go-review.googlesource.com/c/mod/+/815120 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
This repository holds packages for writing tools that work directly with Go module mechanics. That is, it is for direct manipulation of Go modules themselves.
It is NOT about supporting general development tools that need to do things like load packages in module mode. That use case, where modules are incidental rather than the focus, should remain in x/tools, specifically x/tools/go/packages.
The specific case of loading packages should still be done by invoking the go command, which remains the single point of truth for package loading algorithms.