pnpm 11.13 adds pnpm change, a native changesets-compatible release planner that handles version bumping, dependent propagation, fixed groups and per-package release lanes. It also adds pnpm team for registry organisation and team membership, and a versioning.epics config that ties a group of packages to a lead package so their versions stay within a band derived from the lead’s major. 11.12 preceded it, letting a pnpmfile fetcher return { delegate: <resolution> } so custom fetchers can hand off to the built-in ones portably across pnpm and pacquet.
Deno 2.9.3 adds deno add --no-save and --save-optional, and --min-dep-age as a shorter alias for the minimum-release-age check.
pixi 0.73.0 lets { workspace = true } work in environment [dependencies] tables, so a version shared across features or targets is declared once in [workspace.dependencies] without needing the pixi-build preview.
uv 0.11.29 adds JSON output to uv tree and prefers local artifacts over URLs when installing from pylock.toml.
Verdaccio 6.8.0 fires the notification webhook on unpublish and single-version removal as well as publish. Templates get a variable, and the object exposes only name, groups and real_groups so the auth token can never reach the notification endpoint.
zizmor 1.27 adds experimental support for auditing GitHub’s new parallel steps pattern.
Rust 1.97.1 is a point release backporting an LLVM fix and disabling the IR change in 1.97.0 that made the miscompilation more likely to trigger.
Homebrew 6.0.11 merges brew vulns, so CVE scanning of installed formulae is now built in; I wrote up the work behind it.
Also out: npm 12.0.1, Athens 0.18.1, vcpkg 2026-07-13, sbt 2.0.2, Nix 2.35.1, mise 2026.7.10, pipx 1.16.0, Gradle 9.7.0-RC1, Renovate 43.268.4, Dependabot Core 0.387.0.
Docker Engine 29.6.2 fixes three CVEs: CVE-2026-15793, where a git source checkout from a bundle file could lead to command injection; CVE-2026-15792, where incorrect parameters from a BuildKit frontend could cause a panic; and CVE-2026-15791, where an LLB file operation could be tricked into removing the contents of /tmp.
sbt 1.12.14 backports the fix for CVE-2026-26032 in the bundled Apache Ivy PackagerResolver.
crates.io: development update (Tobias Bieniek, Rust Blog) covers six months of work: crate pages now have a Code tab that shows the exact files cargo downloads, which can differ from the linked repository; crates.io accounts are being untangled from GitHub logins; and the Svelte frontend migration is complete.
Composer and Packagist Under Supply-Chain Stress (Sebastian Bergmann) reviews how the PHP ecosystem held up through 2025 and 2026, what it can borrow from other registries, and who owns the infrastructure.
My First Month as AI Security Engineer in Residence (Jacob Finkelman, Rust Foundation) covers building a prioritised database of crates to scan, running early passes with Scrutineer, and working out when a bug found this way should be embargoed rather than reported openly.
Software Supply Chains are Dead: Use-Case-Oriented Regeneration (arXiv) argues that supply-chain attacks have raised the cost of external dependencies while generative AI has lowered the cost of local implementation, and evaluates an agent workflow that synthesises only the slice of a dependency an application actually calls.
Setup Complete, Now You Are Compromised: Weaponizing Setup Instructions Against AI Coding Agents (Bagmar et al., arXiv) evaluates package-install-time supply-chain attacks delivered through project setup docs against production coding-agent harnesses: editing only a README, requirements file or Makefile redirects the agent to an untrusted registry, a known-vulnerable version, or a wrong-but-plausible package name.
The Distributed Open-Source Vulnerability Ecosystem (Mandl et al., arXiv) models vulnerability management as a distributed process and traces where scanners diverge on identical software inventories to specific stages of the ecosystem rather than any one tool or data source.
Forgejo 16.0 adds per-repository watch options, an Authorized Integrations mechanism for secret-less API access, and review comments that span multiple lines.
Ruby 4.0.6 is a routine bugfix release.
Open Source Security: Project Lightwell (Josh Bressers) is a podcast conversation with Máirín Duffy on Red Hat’s programme for routing AI-discovered vulnerabilities to upstream projects rather than carrying downstream patches.
Send links for next week to @andrewnez@mastodon.social.
]]>brew info --json=v2, derived a source repository URL and version tag for each installed formula, and queried osv.dev for anything known against that repo at that version. As of Homebrew 6.0.11 that command is built in and the gem is deprecated. Getting useful answers out of brew vulns in between meant changing what data Homebrew publishes about its own packages, registering Homebrew with the specs that vulnerability tooling is built on, standing up an advisory database, and porting Homebrew’s version comparison to Python so osv.dev can order our releases.
$ brew vulns
Checking 142 packages for vulnerabilities...
(18 packages skipped - no supported source URL)
openssl@3 (3.4.1)
CVE-2024-13176 (medium) - Timing side-channel in ECDSA signature...
Fixed in: 3.4.2
Found 1 vulnerability in 1 package
10 resolved by formula patches (not counted; pass --no-ignore-patches to include):
glibc: CVE-2024-2961, CVE-2024-33599, CVE-2024-33600, CVE-2025-0395, ...
About a month after the first release Mike McQuaid invited me to transfer the repo into the Homebrew org, and from then on it was being run against all of homebrew-core rather than just my laptop. That’s roughly 8,400 formulae, enough real data to find edge cases fixtures never do. OSV records with malformed affected ranges were passing versions through silently, so range evaluation became fail-closed. Vulnerability summaries occasionally contain terminal escape sequences and needed sanitising before printing. One pathological query could pull unbounded pages from the OSV API, so both pagination and the thread pool that fetches vulnerability detail got hard caps, and CI users needed a distinct exit code for “the scan errored” as opposed to “the scan found something”.
Hundreds of formulae in homebrew-core ship with at least one patch applied on top of the upstream tarball, and some of those patches fix CVEs, so the bottle a user installs is not affected even when the upstream version number falls inside an advisory’s range. A query keyed on repo and version reports those as open regardless. There was also no programmatic way to find out which formulae carried patches at all: brew info --json didn’t serialise the patch list, formulae.brew.sh didn’t show it, and formulae loaded from the API had an empty one, leaving a grep over a full homebrew-core checkout as the only option.
I opened a discussion proposing two changes to Homebrew itself: add patches to the JSON output, and let a patch declare which CVEs it resolves. Mike said yes to both more or less immediately. Patches went into Formula#to_hash the same day, which surfaced 1,191 of them across 809 formulae, 972 with an external URL and 219 embedded in the formula file as __END__ data. The patch do DSL then gained resolves and type:
patch do
url "https://deb.debian.org/.../libquicktime_1.2.4-12.debian.tar.xz"
sha256 "..."
type :backport
resolves "CVE-2016-2399", "CVE-2017-9122"
apply "patches/CVE-2016-2399.patch", "patches/CVE-2017-9122_et_al.patch"
end
The vocabulary matches CycloneDX’s pedigree.patches so SBOM tooling can read it without translation, and CVE ids are auto-inferred from the patch URL and apply filenames, which meant glibc, unzip, zip and libquicktime populated without any formula edits.
That change sat in review for close to a month and shipped in Homebrew 6.0.4, at which point brew-vulns could consume it: any OSV result whose id or alias matches a resolves entry is reported as patched, excluded from the exit code, and marked analysis.state: resolved in CycloneDX output. Bo Anderson later mapped resolves through the API layer so it survives the JSON round-trip when formulae are loaded without a local homebrew-core checkout.
With the DSL merged, the next job was populating it across those 1,191 existing patches. Of the 972 external ones, 497 point at GitHub commit URLs (in principle queryable in OSV by commit hash), 272 point at raw files hosted in homebrew-core itself, 42 come from Debian, and the rest scatter across MacPorts, FreeBSD ports, Fedora, Gentoo and gists. Patrick Linnane sampled 59 of the GitHub-commit patches and found zero that referenced a CVE; homebrew-core’s patches are almost entirely build and portability fixes, and a heuristic that greps formula source for CVE strings risks marking things patched that aren’t, since several of the CVE mentions in core are comments about unfixed issues.
So the approach flipped from annotating every patch by URL heuristic to running the scanner over every patched formula and only annotating where a real finding gets suppressed. That pass covered the 484 patched formulae with a resolvable source repo and turned up nine with open OSV findings; in every case the shipped patch was a build fix unrelated to the CVE, so zero new annotations came out of it.
A wider sweep querying OSV by commit hash for the GitHub-commit patches, reading DEP-3 headers on the Debian tarballs, and grepping local patch bodies found exactly one more: nvi carries a Debian regex patch that fixes CVE-2015-2305. Along the way, extending the scanner’s homepage fallback to cover formulae hosted outside GitHub, GitLab and Codeberg also turned up an unrelated data bug where libart’s homepage field pointed at a completely different project.
The glibc formula’s Debian patch tarball resolves ten CVEs, and querying OSV by the sourceware.org repo URL returns exactly one of them. The other nine exist in OSV only as records auto-converted from NVD, and those conversions carry no affected[].package data: you can GET /v1/vulns/CVE-2024-2961 and read the record, but no query by package, purl or repository will ever return it. All of libquicktime’s patched CVEs were in the same state. So even a scanner with perfect repo-URL derivation has a recall ceiling set by how much of NVD has been enriched with package data upstream, and for the C libraries Homebrew ships a lot of, the answer is not much.
By this point Homebrew had structured resolves data, version history and patch metadata for every formula, which together are enough to act as an OSV data source. I added an --osv-export flag to the tap that walks every formula’s resolves list and emits one OSV-schema JSON record per CVE, under a Homebrew ecosystem with pkg:brew/<name> package URLs, BREW-<formula>-<CVE> ids, and the resolving patch details carried in ecosystem_specific. A demo repository held the initial 26 records with schema validation running in CI, and any OSV-aware tool reading that feed could answer whether a given Homebrew package version was affected by a given CVE without going near the upstream repo.
For anyone else’s tooling to read those records, two specs needed a Homebrew entry and osv.dev needed code to handle it. The package-url spec defines the pkg: identifier format that OSV, CycloneDX, SPDX and most SBOM tooling use to name packages, and it maintains a registry of allowed types. A pkg:brew type had been proposed in 2023 by William Woodruff and again by others afterwards, and it finally landed via Rui Chen earlier this year. One wrinkle specific to Homebrew is that formula names can contain @ for version-pinned variants like openssl@3 and python@3.12, and @ is also purl’s version separator, so pkg:brew/openssl@3 is ambiguous and the @ in the name has to be percent-encoded as pkg:brew/openssl%403.
The OSV schema keeps its own registry of ecosystem names and id prefixes, and records that use an unregistered one fail validation. Registering Homebrew and the BREW- prefix was straightforward, as was documenting the database URL and how Homebrew versions sort, which any tool evaluating an affected range needs to implement.
Getting osv.dev itself to ingest the feed is the piece still in progress. Two additions are needed per ecosystem in the osv.dev importer: a purl-to-package mapping, which for pkg:brew is a couple of lines, and a version comparator so that range queries like “is 6.0_7 inside introduced: 0, fixed: 6.0_8” can be evaluated server-side. Homebrew versions are the upstream version string with an optional _N revision suffix that increments when a formula changes without an upstream release, and the upstream strings are whatever each project uses, semver or otherwise. The comparator is therefore a Python port of Homebrew’s Ruby Version#<=> logic, which runs to a couple of hundred lines of edge cases. The draft PR is open; until it merges and ingestion is enabled, brew vulns can’t query {ecosystem: "Homebrew"} over the API and has to fetch the advisory database’s static JSON directly instead.
I transferred the demo repository into the Homebrew org once the schema registration merged, initially as Homebrew/homebrew-advisory-database. That name lasted about a day: the homebrew- prefix is how the setup-homebrew CI action identifies taps, and CI runs started failing on an attempt to tap a directory full of JSON files, so it became Homebrew/advisory-database and every reference to the old name across brew and the repo’s own workflows had to follow.
The repo holds one JSON file per advisory, currently 33 across six formulae (glibc, libquicktime, lrzsz, nvi, unzip, zip), all generated from resolves annotations. A daily GitHub Actions workflow regenerates them, and because the org’s branch ruleset requires pull requests on main the workflow opens a PR instead of pushing. Regeneration originally ran gem install brew-vulns followed by brew vulns --osv-export, which meant the tap couldn’t be archived until brew had a native replacement; that arrived as brew generate-vulns-advisories, a hidden dev command, and the workflow switched over.
The fixed boundary in each record needed more care than “whatever version ships today”. If unzip’s formula gained a CVE-2014-8139 patch at revision 6.0_6 and the current revision is 6.0_8, a record saying fixed: 6.0_8 wrongly flags 6.0_6 and 6.0_7 as vulnerable. The generator now walks homebrew-core’s git history via FormulaVersions to find the first revision where the resolving patch appeared, and merges into existing records rather than overwriting them so a hand-corrected boundary or a curated record survives the next nightly run. The contributing guide covers the curated path for cases the generator can’t express, using a BREW-0000-0000 placeholder id that a maintainer replaces on merge.
Around this point I was added as a Homebrew maintainer, which made the next stretch a lot smoother since it involved landing a run of interdependent changes across brew, homebrew-core and the advisory database in quick succession. The scanner moved into Library/Homebrew/cmd/vulns.rb with a supporting vulns/ module directory, following the same pattern as brew livecheck, and the tracking issue has the full design doc listing everything that changed on the way in.
User-facing commands in brew’s cmd/ directory can’t lazy-load gem groups (a RuboCop cop enforces it), which was the biggest constraint on the port: anything the command needs has to be in the vendored bundle already or reimplemented, and adding five gems to every Homebrew install for one subcommand wasn’t going to fly. The tap depended on purl, vers, cvss-suite, sbom and sarif-ruby, and all five went.
The sbom and sarif-ruby gems were only used for --cyclonedx and --sarif output, so those flags are dropped for now and will return as direct JSON emission validated against the published schemas. The purl gem was used exactly once, to extract the ecosystem token from an OSV record’s affected.package.purl field, and since the merged code only evaluates SEMVER ranges locally that lookup is never reached.
The vers gem became a small Homebrew::Vulns::Semver module implementing strict SemVer 2.0 comparison. Homebrew’s own Version class isn’t a drop-in here: it sorts 1.0.0-alpha.1 above 1.0.0-alpha.beta where the SemVer spec says numeric prerelease identifiers sort below alphanumeric ones, and it compares +build metadata where SemVer says build metadata is ignored for ordering. Getting either wrong turns a range boundary into a false positive or negative.
The cvss-suite gem became Homebrew::Vulns::CVSS, which implements the CVSS v3.0/v3.1 base-score formula and buckets the result. CVSS v4.0 scoring requires a roughly 270-entry MacroVector lookup table plus interpolation between entries, so v4 vectors currently fall through to the next severity entry on the record; almost every record with a v4 vector also carries a v3 one, so in practice little is lost.
The tap’s --all flag was going to become --eval-all to match other brew commands, until --eval-all was replaced across brew with a tap-trust mechanism while the PR was in review, so with no arguments brew vulns now scans every formula from a trusted tap and falls back to installed formulae otherwise. The tap also always read the current formula definition for the source URL and version, so an old installed keg would be checked against whatever version the formula had since been bumped to. The built-in command reads the installed keg’s SPDX SBOM instead, and if an outdated keg predates SBOM generation the scan warns and exits nonzero rather than reporting a version it never checked.
All of that shipped together in Homebrew 6.0.11, and the tap is now a deprecation stub pointing at the built-in command.
The command as shipped queries OSV’s GIT ecosystem by repo URL, which covers about 73% of homebrew-core (6,210 of 8,492 formulae); the other 2,282 have no derivable GitHub, GitLab or Codeberg URL and are skipped, with a count reported at the end of the run. Closing that gap means finding other keys that join a formula to an advisory, and doing the joining once at authoring time in the advisory database rather than on every user’s machine. That way brew vulns stays at a single batched API call however many matching strategies feed the database behind it.
Of the skipped formulae, 322 have a stable.url pointing at a language package registry (145 PyPI, 144 npm, plus Maven, Hackage, CPAN, crates and a few others), and a URL like files.pythonhosted.org/.../foo-1.2.tar.gz encodes enough to build a pkg:pypi/foo@1.2 purl and query OSV’s PyPI ecosystem directly. The same applies to the 12,283 resource blocks across homebrew-core, which are vendored dependencies inside formulae; about 91% of those are registry URLs (over 10,000 PyPI alone) and none are scanned today.
That leaves roughly 1,960 formulae hosted on SourceForge, GNU mirrors, gnome.org download servers, Debian archives and the like, with no direct package identifier at all. For those the join goes through Repology, which already indexes Homebrew alongside every major Linux distro: look up the formula name, get back the Debian, Alpine and openSUSE source-package names for the same upstream, query OSV’s distro ecosystems for those, and collect the CVE aliases.
Repology’s bulk dumps turned out to be 10GB+ PostgreSQL restores rather than anything directly loadable, so the index builder paginates the API instead, about 43 pages at one request per second, and writes a distilled formula -> {distro -> srcname} map into the advisory repo. Name matching needs normalisation (postgresql@16 maps to Repology’s postgresql, libmatio maps to matio, and Repology sometimes lists a Debian binary package where the OSV feed keys on the source package), and corrections to Repology’s project grouping go upstream to repology-rules instead of into a local override layer.
OSV has no CPAN, CTAN or LuaRocks ecosystem, and 61 formulae vendor at least one CPAN module, so that path reads the cpan-security-advisory database directly. Between the registry URLs, the Repology mapping and the CPAN feed, roughly 96% of homebrew-core ends up with at least one automated join key, with a few hundred formulae left over that will need a hand-curated mapping file in the advisory repo.
The scan output can surface in more of Homebrew than a dedicated subcommand. Running the scanner once inside brew generate-formula-api and attaching a vulnerabilities field to each formula’s JSON would put open findings on formulae.brew.sh formula pages and in brew info without a live query, since both already read that JSON. From there brew install could warn when the version being installed has an open advisory, and brew upgrade could list which CVEs each pending bump resolves alongside the version change, so the security case for an upgrade is visible when you’re deciding whether to run it.
Every installed keg already carries an SPDX SBOM listing its dependencies with versions, and the built-in command reads that SBOM for the top-level source URL now, so the inventory for scanning a formula’s whole dependency tree is already on disk and the remaining work is the same matching problem as everything above. Casks are harder because a large share of them package closed-source applications, with no upstream repo to query and no visible dependency list to walk. The EU Cyber Resilience Act will change that from outside Homebrew: vendors selling into Europe will have to produce SBOMs for their products, and as those start to appear for the apps that casks install, scanning a cask’s dependency tree becomes the same job as scanning a keg’s.
On the maintainer side, a homebrew-core PR that bumps a formula is the natural place to report which CVEs the bump closes, which are still open at the new version, and which affect any vendored resource blocks. Running the full matcher against the one changed formula is cheap enough to sit inside brew test-bot alongside the existing audit checks. Anything it finds that isn’t already a BREW-* record is a candidate for the advisory database, giving it a second feed driven by formula changes as well as the nightly advisory sweep. Restoring --sarif and --cyclonedx output brings back the code-scanning and SBOM integrations for downstream projects that want to scan their own Brewfiles in CI.
Underneath all of that, osv.dev ingestion is still the gate for querying {ecosystem: "Homebrew"} directly rather than fetching the advisory JSON, and CVSS v4 scoring still needs its lookup table before v4-only records get a severity label.
Thanks to Mike McQuaid and Patrick for all the help getting this over the line so far, and to the rest of the Homebrew maintainers for reviews across an unreasonable number of pull requests. If you’re on Homebrew 6.0.11 or later brew vulns is already there; the advisory database and the discussion thread that most of this fell out of are good places to follow along.
npm 12.0.0 is out. allow-git and allow-remote now default to none, so installing git dependencies or user-supplied tarball URLs needs explicit opt-in. npm shrinkwrap is removed and npm-shrinkwrap.json is no longer honoured at the project root or inside dependency tarballs. Unknown .npmrc keys, unknown CLI flags and abbreviated flags now error instead of warn, root preinstall runs before dependencies are installed, and npm adduser, star and unstar are gone.
pnpm 11.10 adds an _auth setting that takes registry credentials as a single URL-keyed structure, so CI can pass them via pnpm_config__auth without the shell-quoting problems that broke the per-registry env vars. It also adds pnpm prefix and pnpm issues, and pnpm self-update can now install v12, the Rust port. 11.11 followed with a pnpm access command for managing registry visibility, MFA requirements and team access, and lets allowBuilds entries for git-hosted packages match by repository URL without pinning a commit hash.
uv 0.11.28 hardens ZIP handling against parser differentials via an updated astral-async-zip, so uv may now reject malformed wheels it previously accepted, matching last week’s tar work. 0.11.27 preceded it with resolver performance work: SIMD TOML parsing, interned requires-python specifiers and cached lock markers.
Go 1.26.5 is a security release fixing issues in crypto/tls and os, alongside bug fixes to the compiler, runtime and go command.
Rust 1.97.0 stabilises resolver.lockfile-path in Cargo config for pointing at a lockfile outside a read-only source directory, and build.warnings for turning warnings into errors without -Dwarnings invalidating the build cache. cargo clean now refuses a --target-dir that doesn’t look like a Cargo target directory.
winget 1.29 adds an experimental source priority feature: sources get a numeric priority via winget source add or source edit, and higher-priority sources sort first when a search matches packages in more than one.
Spack 1.2.1 fixes a hang in the new installer when running under forkserver and restores solver performance on macOS.
CocoaPods 1.17.0 adds --no-lint to pod repo push to skip the lint phase when publishing, and updates ruby-macho so mergeable libraries are detected.
Hex 2.5.1 adds ignore_advisories and ignore_retirements to the mix.exs :hex block and as environment variables, so acknowledged CVEs and retirements can be listed once and mix hex.audit reports them separately without failing. Advisories can be ignored by any aliased identifier.
mise 2026.7.4 graduates mise bootstrap and mise dotfiles out of experimental mode, so system packages, repos, user services and shell activation now work without MISE_EXPERIMENTAL. 2026.7.5 followed, sharing config trust across git worktrees so trusting a repo once covers every git worktree add checkout, and fixing npm-backed tools on npm 12.
Also out: Homebrew 6.0.9, RubyGems 4.0.16, Bundler 4.0.16, Cargo 0.98.0, asdf 0.20.0, Hatch 1.17.1, Hatchling 1.31.0, pixi 0.72.2, Yarn 4.17.1, Deno 2.9.2, Helm 4.2.3, Helm 3.21.3, Podman 6.0.1, Nix 2.34.8, Gradle 9.7.0-M3, Maven 3.10.0-rc-1, Renovate 43.258.0, Dependabot Core 0.385.0, Go 1.27rc2.
opam 2.5.2 fixes CVE-2026-57825: a package could install files anywhere on the system by including a symlink to an external directory, bypassing the user prompt that direct external paths trigger.
pnpm 11.11.0 and 10.34.5 fix two path traversals: a crafted pnpm-lock.yaml dependency key could write package content outside the virtual store, and a dependency whose manifest name was a scoped traversal like @x/../../../<path> could be written outside node_modules during install even with --ignore-scripts.
ORAS 1.3.3 picks up oras-go 2.6.2 to fix CVE-2026-50163: a crafted OCI artifact with a relative hardlink target could get oras pull to link into a file in the invoker’s working directory rather than the extract directory.
Immutable Versions on Packagist (Packagist Blog) is the next post in the Composer supply chain series: once a stable version is published its git reference is now fixed, retag attempts are blocked with an email to the maintainer, and deletions become soft with a public transparency log.
You shouldn’t trust Trusted Publishing (William Woodruff) argues Trusted Publishing is an authentication mechanism between CI and a registry, not a signal that a package is safe, and that PyPI keeps it out of the badge UI for exactly that reason.
Trail of Bits published a proposal for PyPI transparency logs: an append-only log of every distribution file the index serves, with inclusion proofs exposed through the Simple API, so a compromised index serving different artifacts to different users becomes detectable. There is a draft PEP, a test log, and source.
The EuroPython 2026 Packaging Summit schedule is up for 13 July in Kraków, with public notes and late topic proposals still open.
Open Source Security: Rust Foundation Maintainers Fund (Josh Bressers) is a podcast conversation with Lori Lorusso and Niko Matsakis on how the fund is structured and where the money goes.
The Nix Foundation is fundraising for a documentation team via Open Collective, with itemised monthly and one-off funding targets for paid contributors working on onboarding and reference material.
Git 2.55 adds git history fixup <commit> for amending an earlier commit and replaying its descendants in one step, incremental multi-pack index repacking, a built-in inotify filesystem monitor on Linux, and a hook.<name>.parallel config for running hooks concurrently.
Beyond Compliance: A Large Scale Study on the Completeness and Consistency of the GitHub SBOMs (Bhuiyan et al., arXiv) measures GitHub’s auto-generated SBOMs across ecosystems and finds version and licence coverage varies enough by language that reliability depends on which ecosystem you’re in.
I tagged six repos this week:
Send links for next week to @andrewnez@mastodon.social.
]]>Monorepo, single version policy: every package in the tree must agree on one version of each dependency; upgrading anything means upgrading everyone at once. The org chart has been forbidden from appearing in the code. It works when there’s a standing migration workforce whose job is dragging every consumer along.
Monorepo with workspaces: one repository, but each package keeps its own manifest and can pin its own versions. One strong platform team, and leadership that believes coordination was solved at the 2019 offsite.
Git submodules: a dependency is referenced by exact commit SHA in a separate repository, and updating it is a manual two-step that never gets automated. Two teams agreed to collaborate and recorded, to the commit hash, exactly how little they meant it.
Bazel: every dependency edge between targets is declared explicitly in a BUILD file; nothing is ambient or inferred. Adopted when the org grew past the point where anyone knew who depended on whom by asking, so the build system was made to enforce what the humans had lost track of. Typically legible to one person, who came from Google.
Nix / Guix: builds are pure functions of their declared inputs; anything not listed in the derivation doesn’t exist at build time. “Works on my machine” has been made a structurally impossible sentence, at the cost of most of the hiring pipeline.
Maven nearest-wins mediation: when two paths through the tree want different versions of the same artifact, Maven picks whichever is fewer hops from the root, regardless of which is newer or satisfies more constraints. Conflict resolution by proximity to the top, which is also how the org settles most disagreements.
Artifactory in front of the public registries, private namespace full of forks: every install goes through a proxy the org controls, and packages that needed patching were forked in rather than contributed back. Trust is granted by a system rather than a person, and the forks date from an argument Legal won that hasn’t been reopened since.
deb/rpm packages for the in-house application: the app is built into an OS package and installed by the system package manager, and releasing goes through the same gate as a kernel update. Ops won, and has governed since. Releases are events with a runbook and at least one person whose job title contains the word “release”.
Docker: the application ships with its own copy of the operating system, so the deployment environment is whatever the developer decided at build time. Dev seceded from Ops and took the OS with them, and Ops can no longer reject an artifact that contains everything Ops used to control. The company finds out how many copies of Debian it’s running when the next xz happens.
Terraform modules from a private registry: infrastructure is packaged as versioned modules that application teams consume like any other dependency. The infra team built an interface so application teams would stop paging them, and now gets paged about the interface.
Module federation: separately built and deployed JavaScript bundles negotiate shared dependency versions with each other at runtime, in the browser. Teams report to different VPs who won’t share a meeting, so version resolution was deferred to the last possible moment, on the user’s machine, because nowhere earlier in the pipeline could agreement be reached.
peerDependencies: the package declares a version constraint on a dependency its host must provide, without shipping anything to satisfy it. A framework team issuing policy to application teams: you will be on React 18, we will check, satisfying the constraint is your problem.
Vendored dependencies: the source of each dependency is copied into the repository and committed; upstream can change or vanish without effect. An org that was hurt by an upstream once and now takes hostages; the cost is a manual merge that lives permanently in next sprint.
No lockfile, latest everywhere: each install resolves fresh against the registry, and the dependency set is whatever’s newest at that moment. The founder still commits to main, had a bad experience with npm-shrinkwrap.json years ago, and won’t touch a lockfile.
semantic-release on every merge: the version number is computed from Conventional Commits prefixes and a release is cut automatically whenever main changes. Publishing became a side effect of the commit prefix, because being the person who cut the release had become a liability.
Go MVS: resolves each dependency to the highest version anything in the graph explicitly requires, and no higher; nothing upgrades just because a newer version exists. Designed by someone who looked at SAT-solver resolution and concluded the problem was self-inflicted, and it encodes an org where change only happens when someone puts the requirement in writing.
Brewfile: the development environment is declared as a list of Homebrew packages that brew bundle installs in order. Onboarding as ritual: the file fails on line 14, and the actual mechanism for getting a working machine is a Slack thread called #dev-setup-help.
Most dependency strategies are attempts to avoid interpersonal negotiation. The tooling doesn’t remove the disagreement, it just picks who loses by default.
]]>Zig’s package manager has been built into the zig binary since 0.11 in August 2023, with no separate tool and no central registry. A build.zig.zon file lists dependencies as URLs with content hashes, and zig build fetches and compiles everything together. The language and the tool are both run by the Zig Software Foundation, a 501(c)(3).
A Zig project has a build.zig program at its root, describing targets, compile flags, and which dependencies to link where, alongside a build.zig.zon data file listing metadata and dependencies. Despite the similar names, build.zig.zon is inert data that can be parsed without running anything, while build.zig is arbitrary Zig code that gets compiled and executed. Which of the two an operation touches is where most of the security properties come from.
.{
.name = .example,
.version = "0.3.1",
.fingerprint = 0x6a8091f57c7f07ff,
.minimum_zig_version = "0.16.0",
.dependencies = .{
.known_folders = .{
.url = "https://github.com/ziglibs/known-folders/archive/refs/tags/1.1.0.tar.gz",
.hash = "known_folders-1.1.0-Fy-PJtnVAAC1Qq48Hf6_4er0Ku98mFvx99UUwo9-mrJd",
},
.tracy = .{
.url = "git+https://github.com/wolfpld/tracy#v0.11.1",
.hash = "N-V-__8AAKw3UgOhKDsrn8hRlOoGmVBl5x91fMi0WQwVaokf",
.lazy = true,
},
},
.paths = .{
"build.zig",
"build.zig.zon",
"src",
"LICENSE",
},
}
The .zon extension is Zig Object Notation, a subset of Zig’s syntax restricted to literals and anonymous structs with no expressions, imports, or function calls. The fingerprint is a 64-bit integer combining a random 32-bit id with a checksum of the name, generated once when the package is created. It stays the same through renames and repo moves, so it’s the package’s identity independent of whichever URL currently serves it.
Each dependency is either a .url and .hash pair or a local .path. The hash is computed over the extracted files after applying the .paths inclusion list from the dependency’s own manifest, so a package author decides which files count towards its identity. The documentation is explicit that the hash is the identity and the URL is just one place to get it: “packages do not come from a url; they come from a hash. url is just one of many possible mirrors.”
The hash string is $name-$version- followed by URL-safe base64 packing the fingerprint id, decompressed size, and 200 bits of truncated SHA-256, so a zig-pkg/ directory listing stays readable without a lookup table. A dependency with no build.zig.zon of its own, like tracy above, is a “naked” package and gets the placeholders N-V- and a sentinel id instead. .lazy = true defers fetching until the dependency is referenced from build.zig.
Dependencies are fetched by downloading the URL, verifying it against the pinned hash, unpacking into a project-local zig-pkg/ directory named by the hash, and recursing into that dependency’s own .zon. A canonical recompressed tarball is kept in the global cache so a second project using the same hash doesn’t redownload. zig fetch <url> on its own downloads one URL and prints the computed hash for pasting into a manifest, without recursing. Supported schemes are http(s):// for tarballs and git bundles, git+http(s):// for the git smart protocol with a ref in the fragment, file://, and bare paths.
zig build compiles build.zig together with every dependency’s build.zig into a single executable and runs it, so a transitive dependency’s build code is linked into the same program as yours rather than invoked as a separate process per package. Calling into a dependency from your build script runs that dependency’s build script, which can do the same for its own dependencies.
Every .zon in the tree pins its direct dependencies by content hash, so there’s no version resolution step and the full tree is determined once the root’s hashes are fixed. Two dependencies that pin different hashes of the same upstream both get fetched and both exist, with deduplication by hash only. Version selection using the fingerprint field is planned and expected to look like Go’s minimal version selection, but as of 0.16 the only cross-tree check is that the same fingerprint and version can’t appear with two different hashes.
0.14 introduced the current hash format and the fingerprint field. 0.16 moved extracted packages from the global cache into a project-local zig-pkg/ directory and added --fork for overriding a package across the whole tree. On 30 June the fetching logic, HTTP client, TLS, and git protocol were moved out of the compiler binary into the build-system process, shipped as source.
Resolution algorithm. None: each manifest pins exact content hashes with no version ranges. Closest to the explicit-dependencies bucket alongside Nix and Guix, though without a content-addressed store underneath, and with minimal version selection planned.
Lockfile. Manifest is the lock: build.zig.zon pins content hashes for every direct dependency and each dependency does the same for its own, with no separate file. Doesn’t fit any of the existing buckets cleanly: reproducible without a lockfile like Go, but by pinning hashes in the manifest rather than by deterministic resolution.
Build hooks. Allowed: build.zig is a Zig program compiled and run at build time with every dependency’s build.zig compiled into the same process, comparable to Cargo’s build.rs, Gradle, or Swift’s Package.swift.
Tuesday test. Fails, i.e. the install can observe inputs the manifest doesn’t declare: build.zig is Turing-complete and runs for every dependency, though .zon on its own is pure data and would pass alone.
Manifest format. Custom for metadata (.zon), host language for build logic (build.zig), where most tools in the categorisation put both in one file. Being a bespoke format rather than JSON or TOML, .zon needs its own parser in every cross-ecosystem tool that reads manifests, ecosyste.ms and git-pkgs included.
Architecture. Source host as registry, alongside Go modules, Deno, and Carthage, with no central index and packages served as tarballs or git refs at whatever URL the author chose.
Review model. None: whoever controls the URL controls what’s served at it.
Namespacing. URL-based for location, but identity is the name plus a self-generated 64-bit fingerprint, which doesn’t match any bucket in the namespacing categorisation.
Distribution model. Source only, compiled on the client.
Ecosystem scope. Language-specific, though Zig’s C interop and bundled zig cc mean C and C++ libraries are commonly packaged as Zig dependencies too.
Version retention. Delegated to the source host, so a GitHub release stays available until the repo owner deletes it or the account goes away, and there’s no yank mechanism.
Size. Without a central index there’s no canonical count, though Zigistry scrapes GitHub for repos with a build.zig.zon and indexes what it finds.
Mirroring. Trivial in principle since the client accepts any URL and verifies by hash, though each .zon names one URL per dependency, so if that URL goes dead the depender has to edit their manifest.
The Zig Software Foundation governs the language and the tool, funded by donations, but package hosting and name authority are outside its remit since there’s no registry for it to operate.
Name ownership rests on the fingerprint, and the manifest documentation says a fork of a maintained project should regenerate it, calling a fork that keeps the upstream’s value “hostile, attempting to take control over the original project’s identity”. Nothing enforces that and there’s no arbiter to appeal to. Availability, account recovery, DMCA takedowns and abuse handling all fall to whichever source host the URL points at, which in practice is overwhelmingly GitHub. Removal of a malicious version is something only the repo owner or the source host can do, and neither has any way to signal downstream .zon files that already pin its hash. Changes to the package manager itself go through the Zig issue tracker.
Loris Cro of the ZSF wrote in 2022 that “we don’t plan to create an official package index”, so the absence of a governance provider is a design choice rather than a gap.
The closest existing designs are Go modules and pre-JSR Deno (when it imported dependencies directly by URL): URL-addressed source, no publish step, no central registry, integrity by content hash. Go’s go.sum and checksum database are the nearest equivalent to .zon hashes, though Go verifies against a public log rather than only what the depending project committed. Swift Package Manager is close on the client side, with a host-language build manifest and git-URL dependencies, but resolves version ranges against tags rather than pinning a single hash. Bazel’s http_archive takes a URL list plus a sha256 with the hash as the identity and the URLs as interchangeable mirrors, then evaluates a hermetic Starlark BUILD file rather than a Turing-complete build program.
The fingerprint is what none of those have: a package identity that survives a URL change, whereas in Go the identity is the module path and moving a repo creates a new module. The --fork flag uses it to substitute a local checkout for every occurrence of a package across the whole dependency tree, regardless of which URLs the intermediate .zon files pinned. It is a CLI argument only, not a manifest field, and the release notes call that “appropriately ephemeral”.
There is no build.zig.zon field equivalent to Cargo’s [patch], Go’s replace, npm’s overrides or pub’s dependency_overrides, and no update subcommand for direct dependencies either.
With exact-hash pins at every level and no ranges to re-resolve, a fix in a low-level dependency reaches a project only when every intermediate .zon on the path has been re-released with the new hash. Until then the root’s options are forking the intermediates, vendoring a patched zig-pkg/ into source control, or passing --fork on every build. The flag isn’t recorded anywhere, so the same commit builds a different tree depending on whether it was passed, in a design where the committed manifest is otherwise a complete lock. Once minimal version selection lands, listing the fixed version in the root .zon would be enough, as it is in go.mod.
The .paths filter is close to the files array in package.json or include in Cargo.toml, except that the hash is computed after the filter is applied rather than over a tarball the author uploaded, so the inclusion list is part of the identity rather than a packaging convenience.
Code execution at install time. zig build --fetch runs nothing from the package: it downloads each URL, verifies the hash, extracts and parses each dependency’s .zon as data, and recurses without compiling build.zig. zig build compiles your build.zig and every dependency’s build.zig into one executable and runs it, so a dependency’s build script executes with your privileges the first time you build. There’s no flag to disable that, since the build script is how a dependency exposes its artifacts. A .lazy = true dependency isn’t fetched, and its build.zig isn’t compiled in, until b.lazyDependency is called for it.
Code execution before install time. Since .zon is data, parsing a manifest and running zig fetch on an untrusted URL are safe modulo the extractor, but zig build on an untrusted checkout compiles and runs build.zig, and so do zig build -h and --list-steps, since the step list comes from executing the configure phase.
Lockfile guarantees by design. The manifest pins 200 bits of SHA-256 for every direct dependency, and each of those pins its own, so the whole tree is fixed by content and every install is a locked install. The guarantee is per-project and starts at first fetch: the hash protects a project from the URL’s contents changing later, but there’s no independent record of what the URL served at the moment the hash was first written down. Go’s checksum database is the counterexample, a public log that records what each module path served so a substituted first fetch would disagree with everyone else’s. Without an equivalent, two Zig projects adding the same URL a week apart can pin different hashes with nothing to flag the discrepancy. Plain http:// URLs are accepted without a warning, and an already-unpacked zig-pkg/<hash>/ directory is not re-hashed before reuse.
Package name identity. name is a bare Zig identifier, at most 32 bytes, case-sensitive, ASCII only, so the usual normalisation gaps don’t apply. Deduplication and --fork match on name plus fingerprint, so two packages sharing a name with different fingerprints coexist in the same tree.
Resolution across multiple sources. Each dependency entry names exactly one URL, so there’s no source ordering to get wrong and the dependency-confusion pattern doesn’t apply. The related failure mode is a stale URL: the .zon records where the author fetched from, and if that host disappears there’s no automatic fallback even though any mirror serving the same bytes would satisfy the hash.
Namespace allocation. Fingerprints are self-asserted rather than allocated, so a fork can write the upstream’s value into its own manifest verbatim and be matched as the same package. Typosquatting on the URL is the source host’s problem.
Maintainer lifecycle. Maintainership is control of the source repo, so adding a maintainer means adding a GitHub collaborator, and nothing signals that to anyone with the package in their tree. Account recovery is whatever the source host provides, and a lapsed custom domain in a .url is a straightforward takeover, mitigated only by the hash pin in existing dependers’ manifests.
Immutability of published versions. The hash in a depender’s .zon guarantees they get the bytes they locked but not their continued availability, and the tag or release the URL points at can be replaced with something else that new dependers will then pin. Git tags can be force-pushed, GitHub release assets can be replaced, and there’s no transparency log recording what a URL served when.
Provenance from source to artifact. The artifact is the source, so there’s no build step to attest. The hash proves you got what the depender pinned but not who wrote it or whether the URL’s repo matches the tarball, and trusted publishing would need somewhere to publish to.
The minimum viable publish credential. This is whatever the source host issues: for GitHub, a token or SSH key with push access to the repo, with scoping, expiry and 2FA on GitHub’s side and no separate publish surface for a Zig-specific credential to protect.
Blast radius and detection. Anomaly detection on publish, malicious-version markers that clients check, and central audit logging are all registry functions that nothing here stands in for. A compromised release spreads only as fast as dependers update their .hash fields, which is slower than a registry ecosystem with floating ranges but also means there’s no single place to pull it from once it’s out, and detection falls to whoever’s reading diffs on the source host.
The Zig compiler’s own build.zig.zon declares zero external dependencies, with the only entries being .path references into the source tree. The toolchain components it needs are vendored into the release tarballs rather than fetched. Since the 30 June change the HTTP client, TLS stack, git protocol and decompressors ship as Zig source rather than compiled into the zig binary, which the devlog notes runs in ReleaseSafe so safety checks stay on for the networking code.
Closest relatives are Go modules and pre-JSR Deno on the registry side, Swift Package Manager on the client side, and Bazel’s http_archive on the fetch model. Treating the content hash as the identity, with the URL just one place to fetch it, is the right way round, and .zon being pure data means the dependency graph can be read without executing anything. The compiler declaring zero external dependencies of its own is a supply chain position I’d like to see more of, and moving the networking stack out into ReleaseSafe source that can be patched without rebuilding the compiler is a good recent change.
.zon being a bespoke format rather than JSON or TOML means I’ve had to write a parser for it in both ecosyste.ms and git-pkgs, and so will everyone else building cross-ecosystem tooling. The tool ends up on the wrong side of the Tuesday test because build.zig is a full Zig program, when the pure-data .zon had it most of the way to passing. The governance functions a registry would provide fall to GitHub instead, which is now the arbiter of availability, account recovery and abuse handling for Zig packages without either party having chosen that.
Nothing in the manifest can override a transitive dependency, so if a low-level package ships a security fix and an intermediate hasn’t re-released, the options are forking the intermediate or passing --fork on every build, and the flag leaves nothing in the repo to record that it was passed. Cargo, Go, npm, pub, Mix and Bazel all have a manifest field for this, and exact-hash pinning makes its absence matter more here than it would with version ranges.
I keep running into content addressing in package management, usually solving one problem at one layer, and I’ve been collecting the places it appears. A package manager content-addressed end to end would have its registry index, its package metadata, every released artifact, and the files inside them all named by hash, so any of it could be fetched from any source and verified locally. That idea has been floating around for as long as I’ve been paying attention, and several of the systems below get a long way towards it without any one of them yet covering the whole stack. This is a survey of the pieces as they exist today: what gets hashed, and what each hash is used for.
Individual files within a package. pnpm keeps a shared on-disk store, normally one per filesystem, where every file from every installed package lives once, named by its content hash, and each project’s node_modules is built from hard links into it, so ten projects depending on the same version of React share one physical copy of every file. OCI registries store each image layer as a blob keyed by its sha256 digest and reference layers from manifests by digest, so pushing an image whose base layers already exist on the registry transfers only the new ones. The same blob store and manifest format now carries Helm charts, WebAssembly modules, and arbitrary files via ORAS, which makes an OCI registry a general-purpose content-addressed package store as much as a container host.
The remote execution API used by Bazel and Buck stores build inputs and outputs in a content-addressable store of individual file blobs, and ostree does the same for whole operating system trees underneath Flatpak and rpm-ostree. nix store optimise walks an existing Nix store and replaces duplicate files across unrelated packages with hard links to a single copy.
A single distributed artifact. One tarball, gem, wheel, jar, or crate, one hash, recorded in almost every lockfile format: npm and Yarn’s integrity field in SRI notation, Cargo.lock’s checksum, go.sum, composer.lock, mix.lock, poetry.lock, uv.lock, pubspec.lock, and Bundler’s CHECKSUMS block in Gemfile.lock. Registries publish the same hash alongside the artifact so a client with no prior state has a reference to check against: PyPI’s #sha256= URL fragments and PEP 691 hashes objects, Maven’s .sha1 and .sha256 sidecar files, the crates.io index cksum, npm’s dist.integrity, Hex’s inner and outer checksums, conda’s per-package sha256 in each channel’s repodata.json.
The same level also covers Homebrew’s per-bottle sha256, the hash listed for each .deb in a Debian Packages file, Subresource Integrity attributes on <script> tags, and the expected hash passed to Nix’s fetchurl and other fixed-output derivations. The digest of an OCI image manifest sits here too, with the difference that it is routinely used as the fetch key, as in alpine@sha256:…, as well as a check after fetching by tag.
A resolved dependency graph. A lockfile taken as a whole records one selected dependency resolution across many packages: the exact set of artifacts one project resolved to at one moment. Nix’s flake.lock is the most explicit form, recording a content hash for every flake input transitively. A Cargo.lock, Gemfile.lock, or package-lock.json does the same in its own format, and committing one to a git repository makes the resolution itself content-addressed by way of the containing commit, which npm ci, bundle install --frozen, and cargo build --locked then treat as authoritative.
Every version of one package. A hash over the complete list of releases for a single package name at a point in time snapshots that package’s publishing history. A TUF repository can express this as a delegated targets file scoped to one package, listing each release with its artifact hash, with the file’s own hash recorded in the snapshot metadata above it. gittuf records every state a git reference has held as a signed, hash-chained reference state log, which for a repository that tags its releases is a verifiable history of every version it has published.
Hackage’s append-only 01-index.tar accumulates per-package entries that build the same record over time. The crates.io git index keeps one file per crate listing all published versions, so the git blob hash of that file is also such a snapshot, though that is a side effect of the index living in a git repository; since the sparse protocol became Cargo’s default in 1.70 most clients fetch per-crate JSON over HTTP and never see the git form.
Every package in a registry. A hash over the full index of a registry at a point in time pins the complete set of packages and versions available from it. Debian’s Release file contains hashes of the Packages files for each component and architecture, which in turn list a hash for every .deb, giving a three-level chain from one signed file down to every byte in the archive; Alpine’s APKINDEX and RPM’s repomd.xml follow the same pattern.
Registries that keep their index in git get this property from git itself: the HEAD commit of the crates.io index, a Homebrew tap, nixpkgs, or a Guix channel is a content-addressed snapshot of every package definition it holds. TUF expresses the same thing as snapshot.json and timestamp.json metadata, and Hackage layers the hackage-security TUF implementation over its index tarball.
Metadata about artifacts. Signatures, attestations, and provenance documents are themselves data with their own hashes, and usually contain hashes of the things they describe. The simplest form is a signature authenticating one object: Maven .asc files are detached signatures over individual artifacts, Debian’s Release.gpg and inline InRelease sign the repository metadata, and RPM carries signatures and digests inside the package header.
Metadata documents can also reference each other by hash to form their own chain, as TUF’s timestamp metadata authenticates the current snapshot metadata, which pins the version and optionally the hash of each targets metadata file, which in turn records hashes of the target artifacts, with root metadata separately distributing the trusted keys for each role; an OCI image manifest references its config JSON by digest alongside the layer digests, and go.sum records a hash of each module’s go.mod file separately from the module zip. Sigstore bundles, npm provenance, and PyPI PEP 740 attestations sit in both halves at once, being signatures over an artifact digest that are then themselves logged by hash in the Rekor transparency log.
The inputs to a build. A hash can be taken over a build recipe and everything it depends on before any output exists, so the identifier names the description of the work and is known ahead of the result. Nix input-addressed derivations compute the store path from a hash of the .drv file and the store paths of every input, and Guix works the same way.
Bazel and Buck compute an action digest from the command line, the environment, and the content hashes of every input file, and use it as the lookup key into a remote execution cache; Docker BuildKit keys its layer cache on each instruction plus the hashes of the files it can see; and ccache and sccache hash the compiler binary, flags, and preprocessed source to decide whether a translation unit needs recompiling. Nix’s experimental content-addressed derivations flip the relationship and derive the store path from a hash of the build output, which puts the hash itself back at the single-artifact level while keeping the input-keyed workflow around it.
Software Heritage applies content addressing across most of these levels at once for archived source code: a SWHID can name an individual file (swh:1:cnt:), a directory tree (swh:1:dir:), a revision (swh:1:rev:), a release (swh:1:rel:), or a snapshot of every reference in a repository (swh:1:snp:), each computed as a hash over the level below. The scheme is git-compatible by construction, so a git commit SHA-1 and the corresponding swh:1:rev: identifier encode the same digest.
Hashing an archive as one opaque blob is simple but makes the result sensitive to bytes that have no effect on the code inside: gzip compression level and OS flag, tar member ordering, embedded mtimes, even the timezone of the machine that built it, so two archives with identical extracted contents can hash differently. A change to git archive’s gzip output in early 2023 broke every tool that had pinned a hash of a GitHub source tarball, including Bazel rules, Homebrew formulae, and Nix fixed-output fetchers, while consumers hashing the extracted tree were unaffected; GitHub reverted the change within days.
One answer is to skip the container and hash the file tree directly: Go’s dirhash computes SHA-256 of each file’s contents, sorts the resulting hash path lines, and records the hash of that listing as the h1: value in go.sum, so the zip’s encoding, compression, and per-file metadata never enter into it. A second h1: over just go.mod lets dependency resolution be verified without fetching the rest of the module. Zig’s .hash is computed over the extracted tree filtered to the package’s own .paths inclusion list, so the archive encoding never enters into it and the author decides which files count.
The other answer is to define a canonical archive format and hash that: Nix’s NAR serialisation strips timestamps, normalises permissions, and sorts entries deterministically, so the same tree always produces the same archive bytes. Debian’s reproducible builds effort and the work on Python wheel reproducibility approach the same problem from the build side, making toolchains produce byte-identical output for identical source. Output-addressed schemes such as Nix’s CA derivations benefit most from getting this right, since identical inputs producing different output bytes means different store paths and no cache reuse across independent builds.
Which hash function is used, and whether the identifier records that choice, determines how hard it is to migrate later. Most of the schemes above encode the algorithm or a hash-scheme version in the identifier: SRI strings carry a sha384- or sha512- prefix, OCI digests are written sha256:…, go.sum lines begin with h1:, and IPFS CIDs embed a multihash code that self-describes both the function and the digest length. SWHIDs record a scheme version and object type in the prefix but currently fix the digest itself to git-compatible SHA-1.
Git originally hard-coded SHA-1 with no algorithm marker anywhere in the object format, and the transition to SHA-256, proposed in 2017, has taken nearly a decade of design and interop work; SHA-256 repositories can now be created, but SHA-1 remains the default and interoperability between the two object formats is still incomplete. npm’s older dist.shasum field is bare hex SHA-1 with the same limitation, which is why packuments now carry both it and an SRI-format dist.integrity field.
Verification. Comparing fetched bytes against a hash recorded earlier, either in a lockfile written at resolution time or in metadata served by the registry, so a tampered or corrupted download is rejected before it is unpacked. This is the most widespread use and the only one most lockfile formats implement, and because the check sits after the fetch it can be, and in several clients is, made optional or advisory.
Addressing. Using the hash as the key the client fetches by, so the request names the expected content and a wrong response is detectable on arrival without consulting anything else. Pulling an OCI image by digest and resolving an IPFS CID are both this. Unlike verification, addressing is hard to make optional, since a client that asked for a hash and accepted non-matching bytes would not have the object it requested.
Deduplication. Using the hash as a storage or transfer key so identical content is held or sent once. pnpm’s file store and OCI’s blob layer both share content across packages this way, the first within one machine and the second across every client of a registry.
Build caching. Treating a hash over the inputs to a computation as a cache key, so a build step whose inputs match a previous run can take that run’s output instead of repeating the work. Nix derivations and Bazel actions are the two implementations most package-adjacent tooling borrows from.
Tamper evidence. Placing hashes as nodes in a Merkle structure so that a small trusted root, such as a signed tree head or a TUF timestamp file, is enough to authenticate everything it transitively references. Go’s checksum database and Debian’s Release chain both let untrusted mirrors serve the full archive on the strength of one signature at the top.
One consequence of addressing and tamper evidence taken together is that the question of where bytes come from can be separated from the question of whether to trust them: once a name has been bound to a hash by whatever authority you accept for that, the bytes can arrive from anywhere and be checked locally. Go’s module system is designed around this split, with GOPROXY free to point at any proxy or chain of proxies, public or private, while the checksum database at sum.golang.org independently confirms that what arrived matches what everyone else has seen for that module version.
Nix can pull from any binary cache added as a substituter, with each substituted path verified against a signature from a cache key the user has trusted, and fixed-output or content-addressed paths additionally checked against the content hash encoded in the path itself. Debian and its derivatives have run on third-party mirrors for over two decades on the strength of one signed Release file per suite chaining down to every .deb in the archive. An OCI pull pinned to a digest can be served by any registry mirror or pull-through cache, since the manifest and every layer are checked against their digests regardless of which host the bytes came from. Zig’s manifest documentation states the same principle directly, calling the .url “just one of many possible mirrors” for the content the .hash identifies.
All of which assumes the binding from name to hash has already been established somewhere trusted, because content addressing does not decide which hash a name should point to in the first place. Which account is permitted to publish rails 8.0.0, and which artifact that version resolves to, is a governance question answered by the registry’s account system and the maintainers who hold the credentials, and a hash can only confirm that you received what they published.
Attacks on package supply chains tend to target that binding rather than the bytes themselves: account takeover and malicious maintainer handover publish hostile artifacts under an existing trusted name, typosquatting registers a name close enough to be mistaken for one, and dependency confusion arranges for a different registry to win resolution for the same name; in each case the hostile artifact’s hash is then recorded and propagated as faithfully as any other. In Zooko’s terms, a hash is secure and globally consistent and means nothing to a person, while a name is the part a person can actually use and is only as trustworthy as whoever controls it; binding one to the other is the job that registries, maintainer accounts, signatures, and transparency logs are there to do.
]]>Hex 2.5.0 adds organisation-defined dependency policies: an organisation publishes a named policy through its repository, a project opts in via HEX_POLICY or the :hex block in mix.exs, and resolution then filters out versions that carry an advisory above a given severity, are retired for listed reasons, or are newer than a release-age threshold.
Conan 2.30.0 adds SPDX expression support to its SBOM generation, a conf=~ unset operator, and IntelCC support in the Meson, Autotools and Premake toolchains.
uv 0.11.25 hardens tar handling against parser differentials via an updated astral-tokio-tar, so uv may now reject malformed source distributions it previously accepted, and writes a full lockfile into tool receipts. 0.11.26 followed with resolver performance work reusing state across PubGrub iterations.
pixi 0.72.0 adds inline package manifests, so a git dependency without a Pixi Build manifest of its own can have build backend metadata set directly in the consuming project’s dependencies table.
mise 2026.7.0 adds mise install --monorepo with a tri-state [monorepo].lockfile setting for a single root lockfile across config roots, a per-tool github_attestations option to disable GitHub Artifact Attestation verification for one tool, and enables shell expansion in env by default.
Rust 1.96.1 is a point release fixing missing retries and timeouts in Cargo’s HTTP client and patching three libssh2 CVEs in the copy compiled into Cargo.
npm 12.0.0-pre.2 graduates the linked install strategy from experimental to stable and moves install-script approval under a dedicated npm install-scripts namespace.
brew-vulns 0.4.0, which I maintain, uses the resolves field on formula patches added in Homebrew 6.0.4 to suppress false positives where the formula already carries a patch for the CVE, and records those as analysis.state = resolved in CycloneDX output.
Also out: Homebrew 6.0.6, sbt 2.0.1, Cargo 0.97.2, Deno 2.9.1, Podman 5.8.4, Harbor 2.15.2, Dependabot Core 0.384.0, diffoscope 323.
Composer 2.10.2 and LTS 2.2.29 fix path traversal via package bin entries (GHSA-gjfg-22fp-rrxx), credential leakage in verbose output (GHSA-g6xq-892h-64w3), missing package name validation (GHSA-499r-g7pc-vmp9), and three further hardening changes around HTTP redirects, phar metadata and JSON error output.
Guix substitute and pull vulnerabilities fixes four issues in the daemon and client: substitute extraction ran before hash verification so a malicious substitute could write arbitrary files as the daemon user, a substitute for one store item could be accepted in place of another, file:// substitute URIs could leak daemon-readable files via error backtraces, and a malicious channel could overwrite user files via guix pull or time-machine. CVEs pending.
Mitigated: API bypass for download metadata on python.org reports an authentication bypass in the python.org API where mixed handling of guest and API-key authentication could grant administrative privileges over download metadata; the fix separates the two modes and adds URL validation. Guix has a tracking issue on the implications for its importer.
Hijacked npm and Go packages use VS Code tasks to deploy infostealer covers a campaign in which sixteen hijacked Go modules and a set of npm packages shipped fake font files and VS Code task definitions that fetched a Python infostealer.
GuixPkgs: every Guix package as a Nix flake (Farid Zakaria) imports the full Guix package set into Nix by building a primitive that exposes each Guix derivation through a flake.
The Vulnerability Identity Crisis (Jay Jacobs and Art Manion, Empirical Security) argues a vulnerability should be defined as a disposition, a structural property comprising a fault, conditions for exploitation, and a resulting security failure, rather than by surface characteristics.
Do excellent vulnerability reports (Daniel Stenberg) is a guide for reporters on what an open source project needs from a vulnerability report to act on it.
All Package Management Functionality Moved from Compiler to Build System (Andrew Kelley, Zig devlog) shifts package fetching, the HTTP client, TLS, the Git protocol and archive handling out of the zig binary into the build-side maker process, shipped as source. Networking now runs in ReleaseSafe with safety checks on and can be patched without rebuilding the compiler.
Mutating the “Immutable”: A Large-Scale Study of Git Tag Alterations (Rapaport et al., arXiv) analyses 328.4 million repositories from Software Heritage and finds 10.2 million tags that were deleted or force-pushed after creation, undermining the assumption that a tag is a stable reference for reproducible builds.
Uncovering Similar but Different Packages in PyPI and Potential Security Threats (Park et al., arXiv) measures package replication on PyPI, where a package duplicates most of an existing codebase, and traces how replicated packages propagate known vulnerabilities and provide cover for malicious variants.
Cloak and Detonate: Scanner Evasion and Dynamic Detection of Agent Skill Malware (Ji et al., arXiv) builds payload transforms that evade all eight tested agent-skill scanners at over 90% via self-extracting packing, and proposes SkillDetonate, a sandboxed runtime auditor that catches 97% by observing behaviour at OS boundaries instead of inspecting at install time.
File-Level Copying Is an Implicit Dependency in Open Source (He et al., arXiv) mines 690,500 copy events from World of Code and frames copied files as dependencies that lack the four signals a package manager provides: provenance, maintenance, security and compliance.
The PSF has announced the inaugural Python Packaging Council election, establishing a technical decision-making body for Python packaging specs that coordinates across tools and teams.
The Open Source Pledge has a redesigned site marking $7 million paid to maintainers by member companies so far.
Once a Maintainer: Mike Dalessio is an interview with the Nokogiri maintainer on the security work that comes with maintaining a widely depended-on gem.
I tagged fifteen repos this week:
Send links for next week to @andrewnez@mastodon.social.
]]>It is also not about open source. Where open source appears in the text, it appears as an exemption, a component risk, a compliance contact, or a paperwork trail.
The CRA is a product-safety law in the CE-mark family, the same regime that already covers toys, radio equipment and machinery: rules a manufacturer must meet before selling a product in the EU, with a conformity mark at the end. The CRA extends that to anything with software in it. In the previous post I described this class of regulation as requiring haulage firms to certify which bridges their lorries crossed while employing no bridge inspectors, and the CRA is the regulation most often held up as the counterexample.
The things the CRA defines are products, the companies that make or sell them, and components. There is nothing in it corresponding to a project, a package, a registry, or a maintainer. Open source is visible in the regulation only as a property a component of a regulated product can have, so in the CRA’s terms there is no OpenSSL, only products that incorporate OpenSSL.
Non-commercial open source is carved out of scope, which took a lot of lobbying and has been treated since as a win for the community. But exclusion from a product regulation is not the same as benefiting from it. A project outside the CRA’s scope is in the same position as one the drafters had never heard of.
The regulation establishes no fund and no inspection or maintenance body, and nothing in it requires a manufacturer to contribute upstream. The exemption is the edge of what product law can reach: software nobody is selling offers nothing for a market regulation to attach to.
The phrase “supply chain” appears in the text in its product-law sense, meaning the chain of companies who put a good on the market and can each be held responsible for it. That is a different thing from the transitive dependency graph the same phrase means in open source, and reading the regulation as if it governs the second because the vocabulary overlaps is a category error.
The clause that bears most directly on open source dependencies requires a manufacturer to exercise due diligence when pulling in third-party components, open source included. A manufacturer discharging that duty has a menu of options:
None of those routes money to the upstream author, because the rational response to liability for a component is to reduce exposure to it rather than to invest in it. A haulage firm told it is answerable for the state of every bridge on its route will plan routes with fewer bridges on them before it considers starting a bridge-repair division. When open source licence terms became a perceived corporate risk, the tooling that appeared was licence scanners and component-replacement policies, and security liability is the same shape of problem.
The closest the text gets to upstream is a clause requiring a manufacturer who finds a vulnerability in a component to report it to the maintainer. That duty assumes a maintainer is still there to receive it, which is what a maintenance regime would ensure and a product regulation cannot.
The steward category covers organisations that support open source intended for commercial use without themselves selling a product. A steward’s obligations are lighter than a manufacturer’s: have a security policy, cooperate with regulators on request, and handle vulnerability reports for the projects it looks after.
Those are the duties of an organisation that would otherwise be a gap in a manufacturer’s paperwork, which in bridge terms means requiring an existing maintenance crew to post a contact number so that a haulier filling in forms has someone to name. Nothing in the steward provisions hires that crew or appoints an inspector, and the lighter obligations are still organised around the manufacturer’s product.
For the steward category to route money to open source, manufacturers would need to prefer steward-backed components enough to pay for them. The regulation gives a manufacturer no reason to: its due diligence can be discharged by any of the routes in the previous section with no steward involved. Anyone who does want to buy component assurance can already get it from commercial redistributors. Red Hat has been selling supported open source for over two decades, and Chainguard sells hardened images with the SBOM and vulnerability handling needed for a CRA technical file. The nearest thing to a saleable steward output is Article 25’s voluntary security attestation, left to a future delegated act. Becoming a steward today adds obligations to a foundation without creating anything a manufacturer is obliged to buy from it.
The SBOM requirement asks for top-level dependencies “at the very least,” which makes the transitive graph optional, and the SBOM goes into the manufacturer’s technical file alongside the rest of the compliance paperwork. That file is held by the manufacturer and handed to a regulator on request, with no right of access for consumers, researchers, or maintainers. This is how CE-mark technical files have always worked: a private record between the manufacturer and whoever might one day audit it.
The SBOM that results is a liability artifact rather than a transparency instrument:
The CRA will not, to take a concrete case, put a public SBOM for Windows anywhere a member of the public can read it. The National Bridge Inventory from the previous post is open to anyone, and because the bridge regime attaches to the function a structure performs, the privately held Ambassador Bridge is federally inspected regardless of title. A library inside thousands of CE-marked products gets no equivalent record, because the CRA’s trigger is commercial activity and its technical file is a sealed dossier for apportioning fault after an incident.
The machinery the CRA sets running is all on the product side: the Commission will sort products into risk classes, ENISA will run a reporting platform for manufacturers to notify exploited vulnerabilities in their own products, member states will appoint enforcement bodies, and CEN, CENELEC and ETSI are writing the standards manufacturers will be assessed against. None of that touches anything upstream of the manufacturer, because the regulation defines nothing there.
The second-order effects that do reach open source are modest: SBOM tooling will mature because more manufacturers need to produce SBOMs, though Executive Order 14028 had already pushed that along. Exploited-vulnerability reporting will be quicker in the specific case of a manufacturer notifying ENISA about its own product. Neither of those is particular to open source or acts on the upstream project where a vulnerability originates.
When Log4Shell prompted a European policy response, the instrument that came back was product law, which is structurally incapable of acting on the infrastructure that prompted it. The CRA does open source little direct harm, and the exemptions the community fought for are about as good as exemptions get.
The cost is that “we passed the CRA” is now available as the answer when open source maintenance comes up: a regulation with no maintenance regime in it occupies the slot where one would go. The open source community made the CRA an open source story through its own lobbying, and two years on is still reading itself into a text whose subject is manufacturers and consumers.
]]>Roads and Bridges was pitched at the audience that was listening in 2016, technology companies and philanthropic foundations, neither of which maintains bridges: they drive over them for free, pay for them through tax, and leave the upkeep to the state. Spelling out the National Bridge Inspection Standards and the Highway Trust Fund to that room would have meant describing a government programme to a non-government audience, so the report stopped at the analogy and asked the people present to help.
The decade since produced GitHub Sponsors, Open Collective, corporate OSPO budgets, and foundation grants: voluntary contributions from users of the infrastructure. The civil-engineering equivalent is Adopt-a-Highway, where a local business pays to pick litter from a stretch of road and gets its name on a sign. Adopt-a-Highway is a real programme that does some good, and no state relies on it to keep a bridge from falling into a river.
In the United States, every public-road bridge with a span longer than twenty feet is maintained under a federal regime that has been running since 1971, set up after the Silver Bridge collapse killed 46 people in 1967. The National Bridge Inspection Standards are codified at 23 CFR 650 Subpart C and they specify, among other things:
Recognising a structure as a public bridge switches all of that on automatically: the inventory entry, the inspection cycle, the condition ratings, the funding line, the closure authority. For an open source project, the same recognition currently switches on a speech.
The government action that has followed regulates the consumers of open source rather than the infrastructure. The EU Cyber Resilience Act, US Executive Order 14028, and the various SBOM mandates put obligations on companies that ship products containing open source, which in bridge terms is requiring haulage firms to certify which bridges their trucks crossed while not employing any bridge inspectors.
Critical open source projects generally have identifiable owners (named maintainers, a foundation, a company), and the single-maintainer statistic is alarming because the number is one rather than because it is unknown. What they lack is a state owner of record, but the bridge regime does not require one. The Ambassador Bridge between Detroit and Windsor carries around a quarter of road-borne US–Canada merchandise trade, is owned by a private company, and is still subject to federal inspection because the regime attaches to the function the structure performs, not to who holds the title. We know exactly who owns it, and we have left them to it.
The part of NBIS with the least open source equivalent is the most boring: an inspection that finds nothing wrong is filed with exactly the same formality as one that finds a crack in a girder. The inspector records a 9 for the deck and a 9 for the superstructure, dates and signs it, and it goes into the National Bridge Inventory next to all the others, with date of last inspection a queryable field in its own right.
In open source, a review that finds nothing wrong is almost never published, because the only outputs with anywhere to go are findings: issues, pull requests, CVEs. The absence of a CVE against a project cannot distinguish “someone competent checked this and it was fine” from “nobody has looked.” Bug bounties, CVE credit, advisory acknowledgements, and conference talks all pay out on findings, and time spent confirming that a library is sound earns nothing and leaves no trace, which makes a clean review economically irrational to perform. A bridge inspector is paid the same for a 9 as for a 3, and that flat rate is what makes routine inspection a job rather than a hobby.
A certified inspector’s “found sound” is a legal record because the state has defined who counts as an inspector and what an inspection consists of, whereas a drive-by GitHub comment saying “I looked at this and it seems fine” is correctly discounted to zero because there is no way to know who looked, how hard, or at what. Without a definition of what an inspection is and who is qualified to perform one, a clean report has no weight, so nobody bothers to write one.
Germany’s Sovereign Tech Agency is the clearest example I know of a government treating open source as infrastructure it has some responsibility for, and the telling detail is the legal form. It was set up in 2022 as the Sovereign Tech Fund and renamed in 2024 to the Sovereign Tech Agency, a shift from a thing that disburses money to a thing that does work, and it pays maintainers under service contracts rather than grants, because German public-spending law makes it difficult for the government to give money away without defined consideration in return.
That constraint is usually described as a bureaucratic obstacle, but it is doing the same job here that it does in civil engineering, where state departments of transportation procure inspection and repair from contractors under agreements specifying scope, deliverables, schedule, and acceptance criteria. A contract casts the maintainer as a professional the state is buying from because it needs the work done, which is a more accurate and more dignified relationship than the grantee-and-benefactor one that most open source funding has settled into.
The procuring agency writes its own scope of work (which project, which components, what methodology, what gets published and by when), so a review delivered against that scope to a public agency carries weight because of who commissioned it and what they specified, not because of any certification the reviewer holds. Engineering standards have generally propagated this way, from large public buyers writing down what they will pay for and contractors converging on whatever wins the work, which also avoids the argument about who has the authority to set norms for open source: a scope of work claims no authority over the ecosystem, only over the purchase order.
A maintenance contract for an open source project has an obvious scope, and most of it is work maintainers already do unpaid:
Every item on that list produces an artifact whether or not it turns up a problem, since coverage is a percentage regardless, a compatibility matrix has a value in every cell, and a security review conducted on a given date against a stated methodology is a record even when the finding count is zero. Those artifacts map onto component condition ratings, a dated profile across several dimensions instead of a single health score, each of which can be re-measured on a cycle. A profile can also carry the equivalent of a load posting, where the report records that the project is sound within stated limits (“maintained for LTS platforms only,” “not hardened against untrusted input”) without having to choose between a clean bill and a warning label, which is a state open source currently has no way to express. Aggregate the reports across enough contracts and the result is an inventory with a structure number, an owner of record, a date of last inspection, and a condition by component.
Documentation goes stale, dependencies become outdated, and CI matrices stop matching the platforms people use, on a shorter cycle than concrete weathers because the environment a library runs in is other software that is also changing. The right instrument is a maintenance contract on a term, not a one-off grant or a bounty, and “we funded that project in 2024” should sound as odd as “we inspected that bridge in 2024.” The boundary of that contract is condition assessment and upkeep rather than feature development, so the state is buying “keep it standing and report its condition,” which answers in advance the worry that government money would put government hands on a project’s roadmap.
The institution the Roads and Bridges metaphor pointed at already exists, with fifty years of regulation, case law, and procurement practice behind it, and none of it was built by asking trucking companies to sponsor their favourite overpass.
]]>composition, a tiny Haskell package whose whole gimmick is that it depends on nothing, not even base. The upcoming GHC 10.2 breaks it: built-in names resolve through a real module, GHC.Essentials, which is in base, so from 10.2 every package picks up an implicit base dependency whether the cabal file declares one or not. The PR added a flag to opt out of that. Dan closed it and shipped a 2.0 that depends on base like everything else, on the grounds that the zero-dependency claim had always been a polite fiction about where the compiler’s wired-in identifiers came from.
The zero-dependency claim was always a question of where the line falls between the compiler and its standard library, and in GHC 10.2 that line moved by one module. That sent me off cataloguing the same boundary in other ecosystems, but the part I didn’t expect was how much the answer changes what a vulnerability advisory looks like.
The clearest case I found is Ruby Bug #20516: Ruby 3.3.2 shipped weeks after the fix for CVE-2024-35176 still bundling the vulnerable rexml 3.2.6, because the fix had gone out as a gem release and the copy in the Ruby tarball hadn’t been bumped to match. The advisory for that CVE is filed against the gem rexml, but the vulnerable copy on a 3.3.2 install is there because the Ruby distribution put it there rather than because any project resolved it, and an SBOM generated from a Gemfile.lock won’t list it at all; the gap exists because rexml is on both sides of that line at once.
Seven years earlier, before Ruby’s gemification had reached WEBrick, CVE-2017-10784 was filed against three Ruby version ranges and fixed by three coordinated point releases, with advisory text reading “all users running an affected release should upgrade immediately.” The 2024 REXML CVEs (CVE-2024-35176 and five more through the year) were each filed against pkg:gem/rexml with a gem version range, each fixed by a gem release that users could apply without waiting for a Ruby point release, though the bundled copy still had to be bumped on each maintained Ruby branch.
CVE-2023-24329 in Python’s urllib.parse lists five separate CPython version ranges across 3.7 through 3.11 and the fix was five point releases; CVE-2022-35256 in Node’s http parser is three Node release lines and three point releases. Go’s vulnerability database has a pseudo-module literally called stdlib so that toolchain CVEs can be expressed in the OSV schema at all, with govulncheck matching those entries against the Go version that built the binary rather than anything in go.sum.
In most ecosystems the standard library is underneath the package manager: bundled into the compiler or runtime, with no registry page, no independent version number, and no lockfile entry. Python’s stdlib ships in the CPython tarball and urllib has no canonical PyPI package; Rust’s std and core are sysroot crates whose names 404 on crates.io; the Go module spec treats any import path without a dot in the first segment as standard library and never resolves it from the network; dart:core is a URI scheme rather than a pub package; java.base is in the JDK image and fs and http are compiled into the Node binary.
A smaller group put the standard library inside the package manager, with a registry page and a version that appears in the dependency graph. Haskell’s base is on Hackage, kotlin-stdlib and scala-library are Maven Central artifacts that turn up in Gradle lockfiles, FSharp.Core is an implicit <PackageReference> on NuGet, elm/core is a required line in every elm.json, and Deno’s @std/* is on JSR with nothing equivalent baked into the binary.
A third group run both at once, with the same module available from the runtime distribution and from the registry under the same name. Perl’s dual-life modules ship in the perl tarball and on CPAN, Ruby has three tiers of non-gemified libraries, default gems, and bundled gems, R splits base packages from CRAN-updatable recommended packages, and Julia bundles its stdlibs as packages with fixed UUIDs that the resolver can satisfy from the General registry instead.
Modules have been moving through Ruby’s tiers from stdlib to default gem to bundled gem for a decade, with the pace picking up in 3.4 (csv, base64, bigdecimal, drb and nine others to bundled) and 4.0 (ostruct, logger, irb, rdoc). PEP 594 removed nineteen modules from CPython in 3.13, and JEP 320 removed the Java EE and CORBA modules from the JDK in 11 with replacements on Maven Central.
The dart:html family is deprecated in favour of package:web on pub, and a subset of Julia’s bundled stdlibs became upgradable from the registry in 1.9. In GHC 9.10 base was split over a new ghc-internal package as the first step toward a base that can be reinstalled independently of the compiler version, which is the work Dan’s composition PR was responding to. Racket decomposed its whole distribution in a single 2014 release into roughly two hundred catalog packages over a minimal core.
ASP.NET Core, one layer up from .NET’s base class library, is the one case I found that moved from registry packages back into the runtime: 1.0 shipped as ordinary NuGet packages that every web project restored individually; by 2.1 it had been reconstituted as a shared framework installed alongside the runtime, and from 3.0 the package references were replaced by a single implicit <FrameworkReference>. The package model had produced large restore graphs, slow installs, and diamond conflicts between package versions that application authors had no way to untangle, because the whole framework had gone into the resolver at once rather than one module at a time.
The reason given most often in the migration documents is decoupling release cadence: a fix in one stdlib module shouldn’t have to wait for the next language version, and a language version shouldn’t be forced because one module needs a patch. The Julia 1.9 post is direct about stdlibs having been stuck at whatever version shipped with the binary, with DelimitedFiles made the first upgradable stdlib so a fix could ship from the registry while the library stayed in the distribution. The Dart migration to package:web exists because the old dart:html bindings were hand-maintained and chronically behind the browser APIs, while the package is generated from Web IDL and can be released whenever the IDL changes. Reinstallable base is meant to fix the long-standing Haskell annoyance that an upper bound on base is really a constraint on which GHC you can use.
The cpan/ and dist/ directories in the perl source tree exist so a dual-life module can be released on CPAN ahead of the next perl. Ruby’s default gems are the same idea under a different name, and a fix to json or psych reaches users as a gem update rather than three coordinated point releases.
The second stated reason is getting code out of the core distribution so the core team is no longer responsible for it. PEP 594’s title is “Removing dead batteries” and the rationale is about modules with no maintainer, obsolete protocols and design decisions from the 1990s; the standard-* packages on PyPI that resurrect telnetlib and cgi are a third-party project, not a CPython deliverable. JEP 320’s rationale is that the Java EE and CORBA APIs were never really part of SE and standalone Maven artifacts had existed for years, and Nim has a graveyard org for modules removed from its stdlib.
Ruby’s default-to-bundled promotion is driven by maintenance handoff rather than release cadence: a default gem still has ruby-core as the maintainer of record while a bundled gem is an ordinary gem that happens to be in the install, and if nobody maintains a bundled gem after promotion that’s no longer ruby-core’s problem.
The migration documents give cadence and maintenance burden as reasons and don’t mention advisory format, probably because the benefit goes to scanner authors and SBOM consumers rather than the language teams doing the work. A CVE moving from prose against a runtime version to a purl with a version range is what matters for the SBOM and CRA questions I keep coming back to, and the transitional state where a module ships in both the runtime and the registry is where it breaks.
The rexml gap was a release-process slip, but dual-shipping produces the same problem by design. CVE-2024-30105 in .NET’s System.Text.Json has a Microsoft advisory listing the NuGet package range (>= 7.0.0, <= 8.0.3) and the runtime range (“.NET 8.0.6 or earlier”) side by side, because the library is both an out-of-band NuGet package and part of the shared framework, and the remediation is effectively “upgrade whichever one you’re getting it from.”
Go’s GO-2023-1571 lists both the stdlib pseudo-module and golang.org/x/net because the same HPACK code is in both. JavaFX was removed from the JDK in 11 and now ships as pkg:maven/org.openjfx/* on Maven Central, so CVE-2024-20925 is fixed for Java 11+ users by bumping a Maven dependency while Java 8 users, where it’s still bundled, get a JDK update for the same bug, and both paths appear in the one advisory. Any tool consuming these needs a per-ecosystem, per-module record of whether the runtime copy or the registry copy wins at load time, and that mapping isn’t part of any common advisory format.
Perl has been dual-shipping long enough to have tooling for it: Module::CoreList records which version of every dual-life module shipped in every perl release back to 5.000, the %upstream hash records whether blead or CPAN holds the canonical copy of each, and the corelist command queries both from the shell. That’s a machine-readable record of which version shipped with a given perl and where fixes land first; which copy actually loads is still a runtime introspection question, but the release-to-bundled-version mapping is the part other ecosystems leave implicit. Ruby has stdgems.org, which publishes the equivalent mapping as JSON, though it’s a third-party project rather than part of the toolchain, and for Python, Java, Julia and Dart I can’t find anything comparable.
The record that would make the transitional state safe for a scanner has roughly the same fields everywhere: for each runtime release and each module, the bundled version, the registry coordinate it corresponds to, which side is canonical upstream, whether the registry copy can replace the bundled one in place, and which copy the toolchain resolves to when both are installed. Module::CoreList and stdgems.org each cover roughly the first three; nothing I’ve found covers all five, and the identity layer underneath has the same gap, since purl has no syntax for “rexml as bundled in ruby 3.3.2” as distinct from pkg:gem/rexml@3.2.6, which is what the Go stdlib pseudo-module works around for one ecosystem. The migration is happening across a dozen ecosystems and the bookkeeping exists, partially, in two of them.