{“lastseen”:”2026-01-05T22:05:14″,”description”:”I need everyone to stop looking at `go.sum`, _especially_ to analyze dependency graphs. It is not a \u201clockfile,\u201d and it has zero semantic effects on version resolution. There is truly no use case for ever parsing it.\\n\\n`go.sum` is only a local cache for the Go Checksum Database. It\u2019s a map of module versions to their cryptographic hashes. Those versions may or may not be in use; it doesn\u2019t matter to package resolution.\\n\\n`go.sum` was not even enabled by default in the original modules design, precisely because it has no observable effect on builds!1 Its (important) purpose is exclusively tightening the security story: the Checksum Database ensures the whole ecosystem shares the same contents for a given module version, regardless of how it is downloaded, and `go.sum` makes that guarantee local and self-contained.\\n\\nInstead, just look at `go.mod`. It lists the precise version at which all dependencies are built. Since Go 1.17 (released August 2021), it includes all transitive dependencies needed to build the main module and its tests.2\\n\\nYou can either parse `go.mod` with golang.org\/x\/mod\/modfile, run `go mod edit -json` to get its JSON representation,3 or parse it according to its specification.\\n\\nThis is the end of the Public Service Announcement. Read on for some `go.mod` nerdery.\\n\\n## Manifests and lockfiles\\n\\nThe enduring confusion around `go.mod` and `go.sum` is due to the fact that most other languages also have two package-related files, but theirs _both_ matter to version resolution. These two files are usually called manifest and lockfile.\\n\\nThe manifest (e.g. `pyproject.toml`, `package.json`, `Cargo.toml`) usually lists _some_ dependencies along with potentially complex rules for which versions are supported. These rules usually apply transitively to dependents, making version resolution extremely hard and\/or slow in the general case, and sometimes unsolvable. The manifest is not always guaranteed to list all direct dependencies, and no automated mechanism ensures your code actually works with e.g. the minimum allowed manifest version of its dependencies.\\n\\nThe lockfile (e.g. `uv.lock`, `package-lock.json`, `Cargo.lock`) is a relatively recent innovation in some ecosystems, and it lists the actual versions used in the most recent build. It is not really human-readable, and usually doesn\u2019t apply recursively to dependents, allowing the rapid spread of supply-chain attacks.\\n\\nI honestly find the manifest version ranges essentially useless, and get endlessly confused trying to remember which commands modify the lockfile (and when\/why) and which ones respect it.\\n\\nIn Go, `go.mod` serves as both manifest and lockfile, and more: it lists all dependencies, direct and transitive, and their exact version to be used when the module is the main module. Semantic versioning is assumed, and those versions are also the minimum versions applied to dependents\u2019 module graphs. Different major versions of the same module are considered essentially separate modules.\\n\\nNotice how there is no way to accidentally use a feature introduced in a version that your dependents won\u2019t have. Also, when adding a dependency, you don\u2019t automatically get the latest\u2014potentially untested\/compromised\u2014version of all _its_ dependencies. Finally, there can\u2019t be diamond dependency conflicts.\\n\\nAll that with a single, human-readable file: `go.mod`.\\n\\nAll `go` commands take a `-mod` flag. If set to `mod`, missing dependencies can be added to `go.mod` automatically if necessary, and partial manual changes are reconciled. If set to `readonly`, those are errors. `go mod tidy` and (effectively) `go get` default to `mod`; all other commands default to `readonly`.\\n\\nGo modules truly don\u2019t get enough credit for how much simpler they are compared to the alternatives. In other ecosystems, package resolution time going down below 1s is celebrated (and is indeed an impressive technical achievement given the design\u2019s requirements!). In Go, no one ever noticed package resolution happening, so there is nothing to celebrate.\\n\\nFor more ecosystem feature appreciation posts, follow me on Bluesky at @filippo.abyssdomain.expert or on Mastodon at @filippo@abyssdomain.expert.\\n\\n## The picture\\n\\nI had a great time at 39c3 during the holidays. The Chaos Communication Congress is a magical place with a very strict photo policy, so it’s pretty hard to convey its atmosphere. This is the best I could do without recognizable humans in the frame. _In Fairy Dust we trust!_\\n\\n\\n\\nMy work is made possible by Geomys, an organization of professional Go maintainers, which is funded by Smallstep, Ava Labs, Teleport, Tailscale, and Sentry. Through our retainer contracts, they ensure the sustainability and reliability of our open source maintenance work and get a direct line to my expertise and that of the other Geomys maintainers. (Learn more in the Geomys announcement.) Here are a few words from some of them!\\n\\nTeleport \u2014 For the past five years, attacks and compromises have been shifting from traditional malware and security breaches to identifying and compromising valid user accounts and credentials with social engineering, credential theft, or phishing. Teleport Identity is designed to eliminate weak access patterns through access monitoring, minimize attack surface with access requests, and purge unused permissions via mandatory access reviews.\\n\\nAva Labs \u2014 We at Ava Labs, maintainer of AvalancheGo (the most widely used client for interacting with the Avalanche Network), believe the sustainable maintenance and development of open source cryptographic protocols is critical to the broad adoption of blockchain technology. We are proud to support this necessary and impactful work through our ongoing sponsorship of Filippo and his team.\\n\\n* * *\\n\\n 1. I still think it\u2019s important and it was the first thing I remember advocating for when I joined the Go team, because it makes the module cryptographically self-contained, and because the Go Checksum Database transparency story is not great in ephemeral environments like CI. These are security effects, though, not semantic ones. \u21a9\\n\\n 2. These are the only dependencies you care about, even for security. If the main module imports `example.com\/mod1\/pkg1` and a separate `example.com\/mod1\/pkg2` imports `example.com\/mod2`, there is no way for `example.com\/mod2` to affect the build or run code on the developer\u2019s machine, so you don\u2019t need to consider it a dependency. This is actually very powerful, allowing libraries to segregate dependencies (e.g. the AWS SDK) in optional packages, reducing the transitive trust tree of dependents that don\u2019t use that feature. \u21a9\u21a9\\n\\n 3. Why not `go list -m all`, you ask? Because that prints the whole module graph, which includes modules that don\u2019t contribute to the build2 and are not included in `go.mod`. A closer approximation would be `go list -f ‘{{.Module}}’ all`, but this command applies the local build constraints, like GOOS\/GOARCH. There is an open proposal for a flag to do `go.mod`-like resolution in `go list`. \u21a9”,”published”:”2026-01-05T20:06:30″,”modified”:”2026-01-05T20:06:30″,”type”:”filippoio”,”title”:”go.sum Is Not a Lockfile”,”source”:””,”references”:””,”id”:”FILIPPOIO:2184996B45FE9BE864E32BEC8C2ADC1F”,”bulletinFamily”:”blog”,”cwe”:null,”cvelist”:[],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:0,”severity”:”NONE”,”vector”:”NONE”,”version”:”NONE”},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/words.filippo.io\/gosum\/”,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2026-01-05T22:05:14″,”description”:”I need everyone to stop looking at `go.sum`, _especially_ to analyze dependency graphs. It is not a \u201clockfile,\u201d and it has zero semantic effects on…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[6,8,12,162,13,33,7,11,5],"class_list":["post-34072","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-cve","tag-cvss","tag-exploit","tag-filippoio","tag-news","tag-none","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n