In a Go module, how do you force a transitive dependency up to a fixed version nothing else requires?

## The situation An advisory names `example.com/lib`, fixed in `v1.4.2`. You do not import it. It is in your build because a library you *do* import requires it, and that library still requires `v1.4.0`. Nothing in the graph asks for the fix, so nothing gives it to you, and there is a date on the ticket. ## Why a single command is enough Module version selection resolves each module to the **highest version anyone in the graph names as a minimum**. Your own `go.mod` is part of that graph — in fact it is the root of it. So a `require example.com/lib v1.4.2` in the main module raises the selected version to at least `v1.4.2` regardless of what any dependency requires, and no dependency can pull it back down. You are not overriding anything or fighting the resolver; you are adding one more requirement, and the maximum moves. The command that writes it: ``` go get example.com/[email protected] ``` Run from the main module. It resolves the version, writes or updates the require line, adds the hashes to `go.sum`, and — because no package of yours imports that module — annotates the line `// indirect`. That comment is correct and should stay: it is a statement about imports, not about strength. An indirect requirement participates in selection exactly like a direct one. Note what this is *not*. `go get -u ./...` would probably also pick the fix up, but it would move every other module in the build list at the same time; on a deadline that is the wrong diff to ask anyone to review. `go get -u=patch ./...` moves less but still touches everything, and it cannot help at all if the fix landed in a new minor. Naming the module and version is the surgical change: one line moves. ## Verify, do not assume Three commands, each answering a different question: - `go list -m example.com/lib` prints the version **actually selected** for the build. This is the one that proves the fix is in. `go list -m all` shows the whole resolved build list if you want the fuller picture. - `go mod why -m example.com/lib` prints the shortest chain of **imports** from a package of yours down to a package in that module — it answers "why is this in my program at all", and a reply of "module ... is not needed" tells you the requirement is only there because you wrote it. - `go mod graph` prints the **requirement** edges, one `from to` pair per line. Tracing from your main module down to the pinned dependency shows you who was asking for the old version, which is what you will paste into the ticket and what tells you which upstream to file an issue against. Then run the tests. You have changed code your dependencies call and you do not — a patched module can still change behaviour, and yours is the build that has to survive it. ## Living with the pin `go mod tidy` will keep the higher version: it adds missing requirements and drops unused ones, but it does not downgrade a requirement that is still needed. What it *will* remove is a requirement whose module no longer provides any imported package — if the library that dragged `example.com/lib` in gets dropped later, the pin goes with it, correctly. The pin is also self-healing in the good direction. Once the intervening library releases a version that requires `v1.4.2` or newer on its own, your explicit line becomes redundant, and the next `go mod tidy` after that upgrade lets the graph's own requirement carry it. Nothing breaks if you leave it either — a floor at a version everyone already exceeds does nothing. What you should not do is treat this as free. You have raised a module ahead of what its consumer was tested against. That is usually fine for a patch release and less obviously fine across a minor. Say so in the PR description, note the advisory that forced it, and prefer the smallest version that carries the fix rather than the newest available — the smaller the step, the smaller the chance that fixing a security problem introduces a behavioural one.