TileHashReader's ReadHashes operates in five stages:

1. it collects the tiles needed to compute the tree hash (stx);
2. it collects the tiles needed to compute the requested indexes;
3. if fetches all the tiles from the TileReader;
4. it authenticates the stx tiles against the tree hash;
5. it authenticates the remaining tiles against their parents.

At the collection stage, it deduplicates. So for example if h = 2,
N = 15, and indexes = [(0, 01)]

                s3
          ┌───────┴───────┐
          ∘               ∘              s2        <- 1/000.p/3
      ┌───┴───┐       ┌───┴───┐       ┌───┴───┐
      ∘       ∘       ∘       ∘       ∘       ∘      s1     s0
    ┌─┴─┐   ┌─┴─┐   ┌─┴─┐   ┌─┴─┐   ┌─┴─┐   ┌─┴─┐   ┌─┴─┐    |
    00  01  02  03  04  05  06  07  08  09  10  11  12  13  14

    └── 0/000 ───┘  └── 0/001 ───┘  └── 0/002 ───┘ └ 0/003.p/3 ┘

then there are four hashes needed to compute the tree hash
(s3, s2, s1, s0) which sit in two tiles (1/000.p/3 and 0/003.p/3).

Step 4 authenticates those two tiles against the tree hash. Then step 5
should have authenticated tiles[2:] (the remaining tiles) against their
parents. Instead, it was authenticating tiles[len(stx):], so tiles[4:].

That means that tiles[2:4] were never authenticated, but were still
(correctly) used to find hashes for indexes. Those hashes were returned
completely attacker-controlled. The tiles were also passed
attacker-controlled to SaveTiles, breaking its security contract.

Ooof.

Add a comprehensive test that iterates over all tree sizes in [1, 100]
and tries to tamper with every index.

Fixes CVE-2026-56865
Fixes #80744

Change-Id: I4948dfe06e5c8ba068f7f7edfc215c086a6a6964
Reviewed-on: https://go-review.googlesource.com/c/mod/+/814960
Auto-Submit: Gopher Robot <gobot@golang.org>
Reviewed-by: Neal Patel <nealpatel@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

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
Fixes 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>

Update golang.org/x dependencies to their latest tagged versions.

Change-Id: Ib25f5b0dfa47e4446cdef2b615a71fd558e32e4c
Reviewed-on: https://go-review.googlesource.com/c/mod/+/814842
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Gopher Robot <gobot@golang.org>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Neal Patel <nealpatel@google.com>

By now Go 1.27.0 has been released, and Go 1.25 is no longer supported
per the Go Release Policy (see https://go.dev/doc/devel/release#policy).

See https://go.dev/doc/godebug#go-126 for GODEBUG setting changes
relevant to Go 1.26.

For golang/go#69095.

[git-generate]
(cd . && go get go@1.26.0 && go mod tidy)

Change-Id: Id697a3439977f9848fe334b3ff6b5c76c41a5fd9
Reviewed-on: https://go-review.googlesource.com/c/mod/+/817900
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Gopher Robot <gobot@golang.org>

WorkFile.Cleanup currently links to the nonexistent
WorkFile.DropRequire method. Link to WorkFile.DropUse instead, which
uses the deferred cleanup behavior described by Cleanup.

Also fix File.DropTool's doc comment to name DropTool instead of
RemoveTool.

Change-Id: If5ee772f69dab2a38acbbc8a24cc1104334be365
Reviewed-on: https://go-review.googlesource.com/c/mod/+/819820
Reviewed-by: Sean Liao <sean@liao.dev>
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
Auto-Submit: Sean Liao <sean@liao.dev>