pinscan

Overview ¶

pinscan answers "which of our modules are pinned to an UNTAGGED commit of another of our modules that has since been released?"

pinscan <checkout-dir>...        # the roots to walk
pinscan -v ~/src                 # and name every pair

It exits 1 when it finds something, 2 on a usage error, 0 otherwise, and always says what it read — a scan that walked nothing passes everything.

Why it exists ¶

go-downloader pinned github.com/go-macos/appbundle at v0.0.0-20260829193321, an untagged commit from 29 August. appbundle's Sign landed in v0.5.0 and the proxy serves v0.6.0, so the bundle it produced went on signing itself `Identifier=a.out` — the name the Go linker gives every binary — for seven weeks. The code was written, documented, tested and published, and the consumer could not reach it.

The compiler is what found it, on an attempt to call Sign. Nothing in the fleet asked the question, and gorequires asks the other one: who requires module X, named in advance.

The distinction that makes it a measurement rather than a count ¶

⛔ A PSEUDO-VERSION IS NOT A DEFECT. A module that was never tagged can only be referenced that way, and most of this fleet is in that state: measured 2026-10-18 over 669 local go.mod files, 262 fleet modules were pinned by pseudo-version and 234 of them had never been released. The defect is the intersection — pinned to a commit AND the module has a tag — which is 27 modules, and 120 consumer-to-module pairs.

⛔ AND "BEHIND" IS NOT "DIFFERENT". A sibling tool in this repository once reported 52 stale pins by testing inequality, and 35 of them were NEWER than the tag: raising those would have been a downgrade. So the pin's own timestamp is compared against the tag's publication time, and a pin that is ahead is reported separately rather than counted as a problem.