Releases

pnpm 12.1 adds the workspace task scheduler to the Rust CLI, dispatching each package as soon as its dependencies finish where the previous scheduler waited for a whole topological batch, and moves login credentials into structured global config. 12.3 makes the global command shims native executables on every platform and extends the trust-policy flags to pnpm remove and pnpm update. On the 11.x line, 11.25 backports the task scheduler and adds --resume-from for recursive runs.

rustup 1.29.1 checks for toolchain updates in parallel during rustup update and installs multiple components concurrently in rustup component add.

Conan 2.32.0 adds LoongArch64 host detection, Xcode 26.6 and gcc 16.2 support, and lets XcodeToolchain accept arbitrary xcconfig build settings.

PDM 2.29.0 exports editable local dependencies with relative paths in requirements files, and restricts locked packages to the platform they were resolved for when appending targets with pdm lock --platform.

zizmor 1.30, the GitHub Actions workflow auditor, adds a self-repository audit and expands pre-commit support.

Renovate 44.59.0 adds a manager for Microsoft’s Agent Package Manager, and 44.60.0 lets security-update PRs be rate-limited and stops the Go proxy datasource caching transient errors, a long-standing cause of flapping Go update PRs.

The Maven 3.8.x branch has reached end of life; the final state is archived under a tag and the branch removed.

Also out:

• Homebrew 6.0.22
• snapd 2.77.1
• RubyGems and Bundler 4.0.20
• Bun 1.4.2
• Verdaccio 6.10.2
• Go 1.27.1 and 1.26.8
• Rust 1.98.1
• uv 0.12.10
• pipx 1.17.2
• conda 26.7.2
• Pixi 0.79.0
• mise 2026.9.1
• Dependabot Core 0.394.0
• Docker Engine 29.8.0
• Terraform 1.16.1
• Helm 4.3.0-rc.1 and 3.22.0-rc.1
• opam 2.6.0-beta2
• CPAN-Meta 2.150015

Security

Podman 6.1.1 fixes CVE-2026-17106, a path traversal where a crafted tar archive could write outside the extraction directory via malicious links.

Poetry 2.4.2 fixes three issues: installing an artifact absent from the lockfile when the source omits its hash, a path traversal when downloading from a compromised URL, and a path traversal in sdist extraction on Python 3.10.0-3.10.12 and 3.11.0-3.11.4.

Coder disclosed that an attacker gained access to its Cloudflare account and added their own IPs to the module registry pool, serving credential-stealing modules for about fourteen hours on 31 August. Fixed in 2.37.0 with backports to 2.36.4, 2.35.7 and 2.34.9. This is what artifact signing is for: the tampered modules came from the real domain over valid TLS, so only a signature check against a key held outside the Cloudflare account would have flagged them.

Articles

Boring Python: dependency management (James Bennett) is a revised edition of the 2022 post: it now recommends PEP 751 lock files over pinned requirements files, allows uv or PDM for local development while keeping pip-with-hashes for production installs, and adds a section on three-day dependency cooldowns.

The Holy Grail of Nixpkgs Version Ranges (Farid Zakaria) adds version-range constraints to nixpkgs by pairing a 309,000-version index of historical nixpkgs revisions with the clingo Answer Set Programming solver, so a query like python@>=3.10 resolves to a concrete set of revisions. Mixing revisions can produce glibc symbol mismatches, which the solver constrains against using binary compatibility metadata.

Security scanning my own code with Scrutineer and local coding models (Anil Madhavapeddy): notes on running Scrutineer, the code-scanning workflow tool that I wrote, against his own repos with a local GLM 5.3 model in place of a hosted one. He argues the triage decisions maintainers make on findings should themselves be tracked and fed into later scans across an organisation.

Papers

The Software Supply Chain as a Market for Lemons: A Multivocal Review of Trust Signal Collapse (Paramitha et al., arXiv) reviews 252 web sources and 870 Reddit threads on how practitioners pick dependencies: the cheap signals they rely on (stars, download counts, contributor activity) are now cheaper to fake than to earn, and the authors recommend costly signals such as cryptographic attestation as mandatory defaults.

A Multi-Month Study of Git Commit Signing (Shittu et al., arXiv): 22 CS students configured commit signing independently, used it across four coursework projects and a second device, then examined a repository seeded with anomalous commits; nearly all signed every commit but over a quarter missed the anomalies.

AgOSS: A Dataset and Multi-Layer Characterization of Open-Source Agricultural Software (Dudhaiya et al., arXiv) applies OpenSSF Scorecard, governance metrics, SBOM dependency analysis and KEV matching to 66 agricultural OSS repositories and non-agricultural controls; the agricultural projects score lower on raw Scorecard results but the gap disappears once project size and maturity are accounted for.

Elsewhere

NYU Tandon has launched the NYU Software Supply Chain Security Operations Center, led by Justin Cappos, embedding master’s students in open source projects for year-long security placements; the first cohort of 8-10 starts January 2027 with support from Google and DTCC.

Sovereign Tech Agency with Erik Möller (Josh Bressers, Open Source Security): an interview with the STA’s Director of Programs on the Sovereign Tech Fund, its maintainer fellowships, funding for standards-body participation, and the Sovereign Tech Resilience programme for security audits and post-quantum work.

Introducing vulnbrocards.com (William Woodruff): the vulnerability-triage brocards from earlier posts now each have a stable URL.

Determining Value and Viability Using CHAOSS Practitioner Guides (Dawn Foster) is part three of the series, covering the Demonstrating Organizational Value and Assessing Viability guides for justifying open source contribution work to leadership and evaluating dependency risk.

Tracking Trends in Open Source AI Policy (Emma Irwin) applies the CHAOSS AI Alignment working group’s use-policy-specificity metric to 39 open source project AI policies: 25 address code contributions, none address environmental impact, infrastructure strain or notetaker bots.

GitHub added a star history REST endpoint that returns timestamped aggregate star counts for a repository without listing the accounts that starred it.

The Cargo team put out a call for testing for -Zchecksum-freshness, which detects the need to rebuild from file content checksums, replacing the mtime check. The plan is to stabilise it as build.fingerprint = "content" in .cargo/config.toml.

CERN is migrating its 2,200 accelerator-control machines from RHEL to Debian 13 by the end of 2026. The announcement calls the -march=x86-64-v2 compiler default forced obsolescence for older hardware and lists gaps in Debian’s standard tooling for automated package building and publishing.

The recording of Is the InnerSource Commons Good for Open Source?, the FOSS Backstage 2026 talk Ben Nickolls and I gave analysing 800 InnerSource Commons member companies, is now up.

FOSDEM 2027 will be held on 30-31 January.

git-pkgs

I tagged 23 repos this week:

• git-pkgs v0.20.0
• archives v0.7.0
• artifacts v0.2.1
• brief v0.13.0
• capcheck v0.1.4
• changelog v0.2.1
• clone v0.7.3
• dependents v0.2.0
• distill v0.1.2
• enrichment v0.7.1
• forge v0.10.0
• licenses v0.7.0
• magic v0.3.1
• manifests v0.12.0
• outline v0.2.2
• pin v0.2.1
• provides v0.2.1
• proxy v0.8.1
• purl v0.1.20
• registries v0.9.1
• sigstore v0.2.1
• vers v0.7.0
• vulns v0.2.3

Send links for next week to @andrewnez@mastodon.social.

Every second, open source contribution quietly shapes the software we rely on, and yet our view of this open ecosystem is surprisingly opaque. Open source development is performed in public spaces — we can see the commits, issues and comments, the APIs and endpoints are free to use — the logs are just sitting there, so why can’t we just collect all of the data?

…Said every researcher, everywhere. However in most cases of open source related data, we are only looking at part of the whole. Why am I writing this post? Because many of us (including many business decision-makers) are too comfortable with unsubstantiated data. We’ve gotten used to it. Our models assume that it’s smelly and we adjust the logic and weights to compromise. When it comes to open source, our confidence is even lower, even though our resulting decisions can directly impact individuals whom we collectively depend on.

Let’s consider one of my favorite datasets: GHarchive. Started as a hobby project in 2011, this crawler has amassed more than 15 years of event data from GitHub. While this source provides a historical record of open source development on GitHub, as a real-time or comprehensive source of metrics, it’s unreliable and should not be a source for volume-based metrics.

In 2025, GHarchive captured 14% fewer events than in 2024, despite steady growth in platform adoption. Since 2025, we estimate that data retention in GHarchive has fallen to ~50% and in 2026 it may be as low as 20% for some event types (see figure below). Prior to 2025, you could make the general assumption that the majority of events would be represented in this pipeline. Since 2025, we must now assume we may be missing at least half of events and possibly more — not to mention all of the additional activity that’s left out of the event API (see GitHub’s GraphQL API.)

The crawler logic behind this dataset is simple: give me all the events from the GitHub Event stream (e.g. opening pull requests, commenting on issues etc). However, the GitHub API has limitations on the number of calls per hour as well as the number of events listed, so for days with a lot of spiky activity, the crawler will miss some. Although we never assumed that this dataset was collecting 100% of events, the current architecture is showing signs of strain. We suspect that this is due, in part, to the rate of repository growth and adoption of automated tooling on GitHub. In 2011, GitHub announced it reached 2 million public repositories, and by 2026, that figure surpassed 400 million.

I want to acknowledge that building and sharing comprehensive open datasets at scale is hard. Have you ever built a pipeline only to discover that the variables changed mid year, the payload for one output is getting truncated, all your joins broke because one side of the dataset is case sensitive … I could go on. And these examples are just ordinary data issues. Building a dataset at the scale of GitHub where “Every second, more than one new developer on average joined GitHub—over 36 million in the past year“—you start running into a new set of challenges.

My own journey with open source related data began when I repeatedly found myself questioning how much we could trust our own metrics. To expand my understanding of the nuances and the limitations of open source related datasets, I reached out to Andrew Nesbitt, who has spent years digging in data trenches for the benefit of the community. Together we converged on the following issues that we wanted to highlight for the broader community.

Assembling: Assume there will be problems

When I asked Andrew ‘can you summarize the challenges you have faced assembling comprehensive datasets?’ — “I just assume I’m going to have a terrible time anyway, so I start with my best effort and fill in the gaps”. While disappointing, this aligned with most data aggregation methods I’ve reviewed—tools such as Grimoire labs and OSS insights also require multiple processes for collection, combination and reconciliation. Even with these approaches, many sources have missing, incomplete, or inconsistent information.

One source is probably not enough. If you are considering the use of an open source project, you may want to know how many maintainers work on this project, what versions are available, what their dependencies are and any active vulnerabilities or known issues. Each of these queries requires a distinct source—the development history, the dependency graph, the CVE database, etc. Ecosyste.ms strives to pull this information together into one place, but combining data from 1000+ datasets has its own unique set of challenges.

For example, my index is probably not your index. One perennial issue is inconsistent naming conventions across sources. Beyond variable type and format, repository names, versions, packages, tags, licenses, urls, etc. tend to be unique across platforms. Some are case sensitive, there are often duplicates, and anyone can change a name at any time… I’ve been keenly following the adoption of purl and SWHID, but so far I have not found one name to rule them all.

Now we have to keep this up to date: At the moment, there is no consistent way of sharing updates across platforms. Changes to names, APIs, deletions, etc. are more often discovered by errors and breakage than by scouring release notes. To keep Ecosyste.ms up to date, Andrew has written multiple syncing processes that identify or infer updates that need to be accounted for. I asked Andrew ‘If you could ask a platform/data source to change one thing, what would it be?’, “Can I crawl an endpoint that’s just NEW stuff?’

Consuming: Design your pipeline for your use case

Because of LLMs, “it’s now easier for anyone to try to access and build reports”. But those building quick reports are likely not going to go through the pain of being comprehensive. This is where aggregated sources like GHarchive and Ecosyste.ms thrive. As data providers, we’d love if data consumers knew that:

How you collect data matters. If everyone wanted the same dataset, in the same format, at the same time, it would be simple. Depending on how the data is stored—centralized vs distributed and cached, relational vs graph, etc. —queries could be more efficient (in cost and computation) than exports or bulk requests faster than individual requests. This all depends on the topology of the infrastructure and the dataset. In a perfect world, data producers would design their architecture for their top user journeys. However open source related datasets serve a wide variety of user personas from corporations to non-profits, researchers to individual users, maintainers, funders, and many more, with a variety of demands from historical deep dives to realtime feedback. Data producers can’t design for all of these cases, so my challenge to them is to be more open about the best way to access this information.

At the end of the day, we have to respect the human infrastructure: Open source-related datasets are riddled with personally identifiable information (PII). Some individuals may be comfortable sharing their information with fellow contributors, but seeing it aggregated across platforms can be uncomfortable. Any source with PII should be handled with care: anonymize when you can and ensure you are in alignment with policies and regulations. Open source communities are real people so please, consume their data responsibly.

Interpreting: Never stop asking questions

While many have moved on from ‘data-driven’ to ‘AI-enabled’, the fact remains that ALL AI SYSTEMS DEPEND ON DATA. Our data about open source will continue to be incomplete and imperfect, but by asking questions about our sources, acknowledging the gaps, and considering both the technical and human processes behind open source development, we can refine and improve on how we interpret our insights and models even if they don’t completely reflect reality.

GitHub’s git 2.5 announcement introduced git worktree in July 2015 with a one-line caveat: “It’s not recommended to use git worktree with a repository that contains submodules.” Eleven years later git still requires --force to remove a worktree that has submodules and refuses to move one. In between, worktree add had to be patched to ignore submodule.recurse because honouring it made the internal reset --hard recurse into submodule paths that were still empty in the fresh worktree.

This got me thinking about submodules as a package manager. Most of the pieces are there and the behaviour roughly matches, but they don’t quite line up and the experience of using them is worse at almost every step. Enough projects have adopted them and then backed out that “why are git submodules so bad” is a recurring thread.

The gitlink in the superproject’s tree, a commit SHA recorded at a path with mode 160000, is the lockfile entry, and the .gitmodules file mapping paths to fetch URLs is the manifest. git submodule update reads both and populates the working tree, which is the install step. The pin itself is as precise as any package manager’s: an exact commit identified by object ID.

Resolution

The gitlink records only which commit to check out, so .gitmodules carries a url per submodule and update clones from there, which is the only resolution mechanism. If the upstream repository is renamed, transferred to a different host, or taken private, every downstream pin breaks, even though the SHA is unchanged and the objects still exist in every clone that already has them. The manifest hard-codes a host because git has no lookup from a commit ID to servers that hold it.

Git also copies each URL into the superproject’s .git/config the first time git submodule init runs, under submodule.<name>.url, and later commands read it from there, ignoring .gitmodules. Editing the committed .gitmodules to point at a mirror or a fork leaves an already-initialised clone unchanged until git submodule sync copies the new value across.

The usual workaround in CI is git’s global url.<base>.insteadOf config, which rewrites any URL with a matching prefix before fetching, submodule URLs included. The common cases are rewriting https://github.com/ to git@github.com: so an SSH deploy key applies, or redirecting an internal hostname to a mirror.

Installation

A plain git clone writes the gitlink into the index so the submodule directory exists, and leaves it empty until git submodule update --init runs or the clone was made with --recurse-submodules. The submodule.recurse config setting makes checkout, fetch, pull, grep and several other commands recurse automatically, and it defaults to off.

By default update checks out the gitlink commit, detached, and two independent flags modify that:

• --init: copy any missing .gitmodules entries into .git/config first, required on first run and a no-op after
• --remote: check out the tip of the submodule’s configured remote-tracking branch instead of the gitlink commit (the remote’s HEAD if submodule.<name>.branch is unset)

The command reference documents both, though the name update conflates “install what’s pinned” with “update to latest”. Switching branches in the superproject changes the gitlink in the index and leaves the submodule’s working tree wherever it already was, so git status immediately shows the submodule as modified. Passing --recurse-submodules to checkout, or setting submodule.recurse, brings the submodule working tree along with the branch switch. The Rust project’s account of moving compiler subprojects off submodules lists this cluster from experience: checkouts left empty or on the wrong commit after clone, unrelated submodule bumps landing in pull requests because a branch switch left the submodule dirty, and custom logic in the bootstrap build tool to check each submodule out to the right commit before building.

Storage

A submodule’s git directory is stored under the superproject’s $GIT_DIR/modules/<name>/, with a .git file in the submodule’s working tree containing a gitdir: pointer back to it and a core.worktree setting pointing the other way. git submodule absorbgitdirs migrates older clones that still have a nested .git/ directory. Each entry under modules/ is a git directory with its own refs, HEAD, index, config, hooks, and by default its own object store. Removing a submodule is correspondingly spread across three places: git rm <path> drops the gitlink and the .gitmodules entry, git submodule deinit <path> clears the working tree and the .git/config entry, and the absorbed $GIT_DIR/modules/<name> directory that both leave behind is documented as a manual rm -rf.

Worktrees and submodules collide over this layout because a linked worktree shares the superproject’s $GIT_DIR but has its own working tree, HEAD, and index under $GIT_DIR/worktrees/<id>/. Put two worktrees on different superproject branches and they reference the same submodule at two different commits. Each needs its own submodule checkout and index, tied to storage that’s partly per-worktree and partly shared. worktree remove requires the override rather than checking whether that state is disposable, and worktree move refuses because the pointer-file rewrite it would need is unimplemented.

Xavier Morel asked on the git list this March whether a submodule checkout could itself be a worktree of an existing shared clone, having found bare repositories plus worktrees worked well for a set of related projects but that adding submodules on top always cloned fresh. An RFC and a three-patch series proposing --recurse-submodules for git worktree add followed in April, giving each linked worktree its own submodule git directory under $GIT_COMMON_DIR/worktrees/<id>/modules/ and sharing the object storage between them by hardlink.

The same multiplication happens in a single-worktree clone when two submodules both depend on a third repository. Each path in the superproject gets its own modules/ entry, its own object store unless alternates are configured by hand, and its own gitlink. The two pins can point at different commits of the same repository, and git treats them as unrelated checkouts. Package managers with a shared cache (cargo’s registry cache, pnpm’s content-addressable store, the Go module cache) store the bytes once and check them out per location.

Updating

The gitlink holds one commit SHA, so moving a submodule forward means entering it, fetching, checking out the new commit, leaving, and git add <path> in the superproject to record the new gitlink. git submodule update --remote fetches the configured branch’s tip and checks that out instead of the recorded gitlink, and committing the result in the superproject is what moves the pin. .gitmodules can name a branch per submodule for --remote and the update bots to follow. A plain update ignores that field and checks out the gitlink SHA regardless. There is no syntax for a version range, a tag pattern, or a minimum commit, so the manifest’s only floating reference is a branch name and the gitlink is the only pin.

Dependabot and Renovate can both open pull requests bumping a gitlink. Dependabot’s gitsubmodule ecosystem proposes a new gitlink SHA when the submodule’s configured branch moves, and Renovate’s git-submodules manager does the same, shipping disabled by default; both follow branch tips because a branch name is the only reference the manifest exposes.

Security

.gitmodules is committed to the repository, so a hostile upstream controls its contents, and git parses it during clone --recurse-submodules before the user has seen any of the fetched files, a combination that has produced remote code execution repeatedly. CVE-2018-11235 used ../ in a submodule’s name so its git directory, hooks included, was written outside $GIT_DIR/modules/ and a post-checkout hook ran during clone. In CVE-2018-17456 the submodule URL began with -, so the child git clone parsed it as an option, the class of bug git’s --end-of-options delimiter defends against. CVE-2022-39253 was a disclosure bug: a symlink in a submodule’s object directory made a local-transport clone copy arbitrary files from the victim’s disk. The fix changed the protocol.file.allow default to user, so local-path submodules now need an explicit opt-in. CVE-2024-32002 combined a symlink with a case-insensitive filesystem to write a hook into .git/ during recursive clone. I covered the broader pattern of package-manager checkout paths as an attack surface in the CWE field guide.

Abstraction

Submodules expose git’s internals directly: object IDs as the pin, detached HEADs after update, the $GIT_DIR/modules/ layout, transport URLs in the manifest. A package manager wraps the equivalents behind a manifest format, a resolver, and a local cache; submodules surface them raw.

Most of the gaps map to things package managers already solved: a shared object cache, recursing into dependencies by default on clone and checkout, a single lifecycle for adding and removing a dependency, range constraints in the manifest. The April patch series adding --recurse-submodules to git worktree add tackles one instance of the storage problem, giving each worktree its own submodule checkout over hardlinked shared storage. Resolution is the harder one: a commit SHA is a host-independent identity for the object, and the URL in .gitmodules is git’s only mapping from that identity to a server that holds it.

pnpm 12

pnpm 12.0 is the stable release of the Rust rewrite. The commands, flags, settings and lockfile format from pnpm 11 carry over unchanged; a companion what’s different post lists the seven behavioural changes.

Git dependencies on GitHub, GitLab and Bitbucket now resolve through the host’s canonical HTTPS URL regardless of how they were specified, so lockfiles record only the canonical HTTPS URL for those hosts. Dependency cycles are broken canonically during peer resolution, so the lockfile is a pure function of the dependency graph. Cycle-heavy workspaces resolve peers 2-3x faster with roughly 25% less memory.

Globally installed tools resolve to the version pinned in the current project, and pnpm can provision npm, Yarn and Bun as managed tools with a pnx command for one-off runs. Unrecognised keys in pnpm-workspace.yaml are now errors.

On the 11.x branch, 11.23 reworks the registries setting so an Artifactory or GitLab registry can keep its tarball URLs out of pnpm-lock.yaml, and 11.24 restores pnpm approve-builds --global and groups recursive publishes by registry so a credential mismatch is caught before anything is uploaded.

Releases

Stack 4.1.0.1 RC adds cross-package Backpack support: when a package uses signatures and mixins to depend on an abstract interface from another package, Stack now generates the extra instantiation build steps Cabal needs. Private Backpack, with signatures and implementations in the same package, was already supported.

winget 1.29.290 adds an experimental sourcePriority feature: sources can be given a numeric priority via source add or source edit, and higher-priority sources sort first in search results when other ranking factors are equal.

Maven 3.10.0-rc-1 is the first release candidate for the 3.10 line, which aligns 3.x behaviour with Maven 4: classpath ordering, version-range resolution filtering and the Resolver 2.0.19 changes are backported, and the super POM drops the deprecated release-profile and default plugin management.

Renovate 44.42.0 sets CI=true for every child process it spawns, and 44.49.0 fetches changelog entries newest-first and stops once the target platform’s PR body length limit is reached, instead of fetching hundreds of releases.

Also out:

• Homebrew 6.0.20
• npm 11.19.1
• Verdaccio 6.10.1
• Deno 2.9.6
• uv 0.12.7
• pipx 1.17.0
• pixi 0.78.0
• mise 2026.8.14
• MacPorts 2.12.6
• Flatpak 1.18.2
• Dependabot Core 0.393.0
• Gradle 9.8.0-M2
• sbt 2.0.8

Security

The Renovate project disclosed ten advisories affecting the CLI, nine High and one Moderate: four command injection vectors, four credential exfiltration paths via malicious Link headers, TLS private key exposure in logs, and a minimumReleaseAge bypass. All are fixed in 44.14.7, released 7 August.

Composer 2.10.3 and 2.2.30 fix four issues: CVE-2026-59944 (path traversal via symlinked bin entries), command injection via a malicious Perforce URL, URL-embedded credentials leaking into more places than intended, and GitLab URL matching that could send credentials to the wrong domain.

ORAS 1.3.4 fixes three credential-scoping issues: mTLS client certificates supplied via --cert-file were presented to any HTTPS peer including cross-origin redirect and bearer-realm targets, custom --header values were forwarded to hosts other than the configured registry, and --debug traces logged pre-signed URL parameters, cookies, proxy authorisation and token response bodies.

Articles

Rumour is the exploit (Anil Madhavapeddy): after opening a public PR fixing a path traversal in OCaml’s cohttp, Anil’s server logs showed probes for the exact pattern within minutes, and an agent given only a rough description of the bug produced a working exploit in under a minute. He argues that once the existence of a fix is public an agent can rediscover the bug independently, so the coordinated-disclosure window that embargoes are meant to protect has closed for open source maintainers.

What’s new in Private Packagist, August 2026 (Packagist blog): MFA enforcement now covers Composer authentication tokens, regenerated tokens invalidate the old one immediately (previously cached for 14 days), and security monitoring reads Composer 2.10’s config.policy section to determine which advisories to suppress.

Papers

Evaluating Inference-Time Defenses Against Package Hallucination in LLM-Generated Code (arXiv) shows that prior measurements overstate hallucinated-package rates by counting standard-library modules as hallucinations (by 9.4 percentage points for Python) and evaluates seven decoding-time strategies for reducing them.

The Rising Cost of Trust: Practitioners’ Trust Signals, Controls, and Responses in the Software Supply Chain (arXiv) is a semi-structured interview study of 38 industry and open source practitioners on which signals they use when deciding to depend on a package and what controls they apply.

AROMA+: A Study of Factors Affecting Reproducible Builds in the Maven Ecosystem (arXiv) automatically recovers the build environment for Maven Central releases and attempts to reproduce them: 32% of packages are feasible for automatic reproduction, of which 12% reproduce fully, and the recovered build specs match Reproducible Central’s manually curated ones field-for-field 99.8% of the time.

Elsewhere

The Rust project announced its first Maintainers in Residence, funding five contributors (including rustup maintainer rami3l) full-time and two more via grants for at least twelve months from a Rust Foundation maintainers fund backed by Google, AWS and OpenAI.

Fettle and the CVE problem (Josh Bressers, Open Source Security): an interview with Paul Asadoorian on Fettle, a tool for checking a Linux system’s outdated packages, pending firmware updates and binary hardening flags, and on his InfraTrust Pulse report which tracks vendor advisories rather than raw CVE counts.

Additional Sustainability Topics from the CHAOSS Practitioner Guides (Dawn Foster) covers the Security, Diverse Leadership and Sunsetting guides; the Security guide recommends Libyears and release frequency as dependency-currency metrics.

The Sovereign Tech Agency is investing €508,640 in Flatpak over two years, funding a contractor team organised by Modal Collective and Para-Real to build new portals for PipeWire audio, network isolation, VPN and spell-checking, plus an entitlements system for app permissions.

Rust Metadata Carver (Decoder Loop) is a Binary Ninja plugin that extracts panic metadata from Rust binaries, recovering which crates and Rust version a stripped binary was built with.

renovate-pretty-log-tui 0.6.0 (Jamie Tanna) adds a summary view and HTML export to the terminal UI for reading Renovate debug logs, and surfaces errors more clearly.

git-pkgs

I tagged 9 repos this week:

• gcs v0.1.0 (new), a Go library for Google Cloud Storage object operations via the JSON API with minimal dependencies
• archives v0.6.0
• artifacts v0.2.0
• brief v0.12.1
• clone v0.7.1
• manifests v0.10.1
• purl v0.1.19
• registries v0.9.0
• sbom v0.1.6

Send links for next week to @andrewnez@mastodon.social.

We’re looking for a passionate, self-directed engineer to take full ownership of one of the most widely deployed libraries in the ecosystem. This is a rare opportunity to make a real impact on software that millions of developers depend on every single day. If you thrive on autonomy, love working in the open, and want to wear many hats in a fast-paced environment, we’d love to hear from you.

About the role

As Senior Open Source Maintainer you will be the primary technical owner and public face of the project. You’ll drive the roadmap, ship releases, support a global user base, and champion the project across the wider industry. This is a highly visible individual contributor role with enormous scope. No two days are the same, and you’ll have full autonomy to decide how you spend your time.

What you’ll do

• Own the technical roadmap and long-term architectural direction
• Review and merge contributions from a diverse, global community of open source developers
• Triage and prioritise the issue tracker and feature request backlog
• Maintain comprehensive documentation, examples, migration guides, and API references
• Ensure project websites and documentation meet current accessibility standards
• Cut releases across all supported major version lines and write the release notes
• Own the CI pipeline, release automation, and package publishing infrastructure
• Keep dependencies current and promptly action automated update pull requests
• Support users on GitHub, Discord, Slack, Stack Overflow, Mastodon, Bluesky, and email
• Ensure compatibility across all current runtimes, operating systems, and architectures
• Preserve backwards compatibility, including widely relied-upon undocumented behaviour
• Coordinate release timing with downstream distributions, registries, and redistributors

You’ll also

• Participate in the on-call rotation for incidents at downstream production deployments
• Support enterprise consumers where project issues block business-critical systems
• Define and communicate support, deprecation, and end-of-life policies for all release lines
• Provide migration guidance to adopters upgrading from end-of-life releases
• Coordinate advisories, CVE records, disclosure timelines, and researcher credits
• Ship embargoed CVE patches across all supported version lines within the disclosure window
• Produce SBOMs, VEX statements, and signed provenance attestations for every release
• Maintain reproducible builds and independently verifiable release artifacts
• Complete supplier security assessments and questionnaires for enterprise consumers
• Remediate findings from OpenSSF Scorecard, dependency scanners, and compliance platforms

As well as

• Review high volumes of contributions from AI coding agents and automated refactoring tools
• Triage vulnerability reports generated by commercial AI security scanners
• Champion the project at international conferences, on podcasts, and across social media
• Moderate all community spaces and enforce the Code of Conduct
• Engage constructively with feedback shared on social media and public forums
• Represent the project in working groups, standards bodies, and regulatory consultations
• Prepare grant applications and quarterly reports for current and prospective funders
• Administer domains, trademarks, signing keys, cloud accounts, and social media
• Advise enterprise legal teams on licensing, patent, warranty, and export control matters
• Own the succession plan: identify, recruit, and onboard your replacement

How we’ll measure success

• GitHub stars
• Time to first response on issues and pull requests
• Release cadence and mean time to patch for disclosed vulnerabilities
• Open issue and stale pull request backlog
• Dependency freshness
• OpenSSF Scorecard result and other automated project scoring
• Community sentiment across public channels
• Downstream adoption
• Bus factor

What we’re looking for

• 8+ years of professional software engineering experience
• Deep expertise in one systems language and professional proficiency in at least four others
• Written communication pitched to audiences from first-time contributors to Fortune 500 CISOs
• Consistent release cadence with minimal dependency churn and no breaking changes
• Comfortable across engineering, support, security, community, marketing, finance, and legal
• Balances contributors, enterprises, security researchers, regulators, and automated systems
• Comfortable receiving direct public feedback and turning it into improvements
• Availability overlapping core business hours in AMER, EMEA, and APAC
• Able to respond to time-sensitive security matters outside normal working hours
• Provides own hardware, reliable internet, and test environments for all supported platforms

Nice to have

• Prior experience in technical writing, developer relations, or community management
• Experience migrating existing codebases to memory-safe languages
• Working knowledge of licence compatibility and international trademark registration
• Grant writing and nonprofit financial reporting experience
• Media training
• An established personal audience on at least one major social platform
• Conversational proficiency in a second and third language
• A second job

What we offer

• 100% remote, work from anywhere in the world
• Complete flexibility over your working hours
• High-impact work depended on by startups and Fortune 500 companies alike
• Exceptional visibility and personal brand building opportunities
• Regular speaking slots at leading industry events
• The opportunity to develop close working relationships with several national CERTs
• A passionate, highly engaged global user community
• GitHub Sponsors enabled on the repository

How to apply

Please submit a CV, a link to your GitHub profile, and a short cover letter telling us what ownership means to you. Our interview process consists of a recruiter screen, a technical interview, a system design round, a take-home exercise, and a final community panel.

If you don’t meet every requirement listed above, we’d still encourage you to apply.

We are committed to building a diverse and inclusive community and welcome applicants from all backgrounds. This position will remain open until filled. Due to the volume of applications received, we are unable to respond to every candidate individually.

This role is not eligible for relocation assistance or visa sponsorship.

The root cause is that the “latest release” query filters out anything the semantic gem fails to parse. That code predates the vers library and I’ve yet to swap it over, so it’s still applying one strict SemVer parser to every ecosystem. SemVer requires exactly three numeric segments before the hyphen. 36.0 has two, 0.7.1.bcr.1 has five, and bcr contains letters, so every protobuf release since 3.19.6 fails the parse and gets treated as unstable. The same filter reports glog’s latest as 0.7.1 when the registry has 0.7.1.bcr.1.

Bazel is a build tool first, and its module system (bzlmod, the default since Bazel 7) is mostly used to pull in existing C++, Java and Go projects that already have their own release histories. Rather than force those projects to renumber, Bazel documents its version format as a deliberate loosening of SemVer: any SemVer string is valid and sorts the same way, and beyond that the release part can have any number of segments and each segment can contain letters. Abseil’s date-based 20210324.2 and protobuf’s two-segment 36.0 are both accepted as-is. The grammar in Version.java is RELEASE[-PRERELEASE][+BUILD], where RELEASE is dot-separated identifiers of ASCII letters and digits only. Comparison applies SemVer’s prerelease identifier rules to the release segments as well:

• numeric identifiers sort numerically, so 36.0 > 4.0.0
• any identifier containing a letter sorts above every purely numeric one, then as an ASCII string
• a version with more release segments sorts above one that shares its prefix, so 0.7.1.bcr.1 > 0.7.1
• a prerelease sorts below the same release part on its own, so 36.0-rc2 < 36.0

The .bcr.N suffix is a registry convention rather than part of the format. Registry entries are immutable once published, and the registry often carries small patches on top of the upstream tarball to make a project build cleanly under Bazel. When one of those patches needs updating and the upstream source stays as-is, the fixed entry is published under a new version with .bcr.1 tacked onto the release part. That’s why 36.0.bcr.1 exists: 36.0 was yanked for a macOS toolchain integrity mismatch, and the fix went in as extra release segments rather than a +build tag so that it sorts strictly above 36.0. That ordering matters because Bazel resolves dependencies with Minimal Version Selection, the same algorithm as Go modules, which always picks the highest version any dependent asked for; a suffix that sorted equal or lower would leave everyone pinned to the broken build.

Version.java also handles build metadata differently from SemVer §10: rather than being ignored for comparison and kept, the +BUILD part is stripped at parse time before anything is stored or sent to a registry, so 1.2.3+abc and 1.2.3 are equal and interchangeable rather than equal-but-distinct. The empty string is a valid version and sorts higher than everything else; it marks a module that’s been overridden to point at a local directory or git commit instead of a registry release, and sorting it top means a local override always wins MVS. Since the release segments have no fixed meaning, breaking changes were originally signalled by a separate compatibility_level integer in the module file, roughly equivalent to a SemVer major version. Both active release lines made that field a no-op in February 2026 (9.1.0, backported to 8.6.0) after it caused resolution failures only the module authors could resolve, leaving breaking changes to be reported by the module’s own build-time errors instead.

External parsers get .bcr.N wrong one of two ways:

• strict SemVer (the semantic gem): rejects 0.7.1.bcr.1 because the release part must be exactly three integers, so it drops from the stable set
• permissive generic (the vers fallback): accepts the extra segments, applies prerelease semantics to the alphabetic bcr, and sorts it below 0.7.1

The vers spec, the package-url project’s cross-ecosystem notation for version ranges, enumerates comparison schemes for fifteen ecosystems and has yet to cover Bazel, though pkg:bazel is a registered purl type so there is already a slot for a vers:bazel scheme. Both vers libraries I maintain hit the second case. The fix in Ruby and Go is a port of the Version.java sort as an implementation-defined bazel scheme ahead of the spec. The corresponding ecosyste.ms change keeps .bcr.N releases eligible as stable, lets the yanked flag exclude 36.0, and moves both protobuf and glog to the correct latest version.

Names and channels

GNU rm goes back and re-reads argv after option parsing has finished. getopt_long accepts any unambiguous prefix of a long option, which would make --no-p a valid spelling of --no-preserve-root, so rm checks the literal string and rejects anything shorter with “you may not abbreviate the –no-preserve-root option”. --preserve-root has been the default since 2006, and the override requires the full flag every time, on top of whatever the argument parser does. It’s easy to miss when reimplementing: uutils, the Rust coreutils rewrite, accepted --n until March 2026.

A long name with no short form is the most common hardening on an override flag, and the one most package managers reach for. apt has --allow-remove-essential, --allow-downgrades, --allow-change-held-packages and --allow-unauthenticated, all long-only, split out from a blanket --force-yes in apt 1.1. pnpm 10 disables install scripts by default and calls the global re-enable dangerouslyAllowAllBuilds. hdparm gates its drive-destroying operations behind --yes-i-know-what-i-am-doing, and the worst of them behind --please-destroy-my-drive as well. The name is the warning, and someone reviewing a script or a diff will read past -f but stop on --allow-remove-essential.

apt also used a typed confirmation phrase for essential-package removal until 2021: print the warning, require Yes, do as I say! character-for-character before proceeding. Typing the translated phrase in Chinese locales required an input method that was unavailable at a bare console, so apt 0.5.23 stopped translating it for zh_*. The check ran regardless of TTY, so echo 'Yes, do as I say!' | apt-get ... worked. In November 2021 a Pop!_OS packaging conflict made apt install steam propose removing the desktop environment, the prompt appeared in a Linus Tech Tips video, and the phrase got typed anyway. apt 2.3.12 replaced the prompt with a hard error two weeks later; the NEWS entry credits Linus Tech Tips and System76 by name.

PEP 668 says the escape hatch for externally-managed environments “should not be something as simple as a --force flag”, and pip’s --break-system-packages, added in 23.0.1, is long-only with an error message that takes half a screen to steer users away. But pip maps every long option to both an environment variable and a config-file key automatically, with no per-option opt-out. PIP_BREAK_SYSTEM_PACKAGES=1 in .bashrc or break-system-packages = true in pip.conf sets it permanently, and the pip test suite itself has to clear the env var to test the un-overridden path.

Node.js tags each option individually in src/node_options.cc as either kAllowedInEnvvar or kDisallowedInEnvvar, and exits with an error if a disallowed one arrives through NODE_OPTIONS. --eval, --print, --interactive and anything that names a script to run are on the disallowed list, and the PR that introduced the mechanism put --tls-cipher-list there too with the one-line rationale “Disallowed because of security concerns”. cargo’s config reference marks registry [source] replacement and [patch] tables the same way, “Environment: not supported”, so pointing a build at a different crate source takes a file on disk rather than an exported variable. npm 12 restricts a different channel: passing --allow-scripts on the command line in a project-scoped install throws EALLOWSCRIPTS, forcing the policy into package.json where it’s checked in and reviewed.

Daniel Stenberg made the case against relying on names alone in 2017, when a curl user proposed deprecating -k and keeping only --insecure, on the grounds that a two-character flag is hard to spot in a script and easy to insert. Stenberg declined: the misuse comes from copy-paste, users transplant -k from a Stack Overflow answer without reading it, and they’d transplant --insecure just as readily. Adding a warning would produce fatigue rather than caution. curl 8.x still accepts -k, though the equivalent CURL_INSECURE environment variable is absent; every entry in the man page’s ENVIRONMENT section leaves verification on.

Preconditions and scope

git push --force-with-lease attaches a precondition rather than relying on spelling: override only if the remote ref matches what I last fetched, so a force-push fails if someone else pushed in the meantime. That check turned out to have a hole: editors with background auto-fetch update the tracking ref without the user seeing the new commits, so the lease matches even though the user’s mental model is stale. git 2.30 added --force-if-includes, which additionally requires the remote tip to appear in the local branch’s reflog, so a fetched-but-unread commit still blocks the push.

go get -insecure applied to everything the command touched, and Go 1.17 removed it in favour of GOINSECURE, which takes a comma-separated list of module path globs so unverified fetches only apply to matching paths. pacman made the same move: the boolean --force that overrode file-conflict checks was removed in 5.1 and replaced with --overwrite <glob>, which has to name what it’s clobbering. Nix’s permittedInsecurePackages requires the versioned package name, openssl-1.1.1w rather than openssl, so when the version changes the exception stops matching and the build fails again until someone re-approves it. Composer 2.2’s allow-plugins is a per-plugin map in composer.json rather than a global switch. cargo’s [patch] table is per-crate.

systemctl reboot --force skips the orderly shutdown of units, and passing --force twice skips systemd itself, issuing the reboot(2) syscall directly from the systemctl process so it works even when PID 1 has hung.

Ceph’s pool-deletion command stacks three mechanisms: ceph osd pool delete NAME NAME --yes-i-really-really-mean-it, with the pool name given twice, and the monitor on the server side still refuses unless mon_allow_pool_delete is set to true in its configuration.

Out of band

Docker keeps insecure-registries in the daemon config only, so pulling from an unverified registry means reconfiguring the daemon. A git server with receive.denyNonFastForwards or receive.denyDeletes set rejects a force-push regardless of what flags the client sent. Homebrew’s HOMEBREW_FORBIDDEN_FORMULAE and siblings let an admin block installs, and HOMEBREW_FORBIDDEN_OWNER names who set the policy so the error message tells the user who to ask rather than what to type. Set in /etc/homebrew/brew.env alongside HOMEBREW_SYSTEM_ENV_TAKES_PRIORITY, the system file is applied after the user’s shell environment and overrides it, so a value exported in the shell is discarded.

csrutil disable has always required booting to Recovery. spctl --master-disable used to turn off Gatekeeper from a normal terminal, but on macOS 15 it prints “This operation is no longer supported” and directs the user to System Settings; a persistent global disable now needs an MDM configuration profile or an interactive System Settings change rather than a scriptable command.

sudo’s credential cache expires instead of requiring a separate channel: five minutes by default per terminal. Set-ExecutionPolicy -Scope Process in PowerShell lasts for the shell session, and GitHub’s sudo mode for sensitive account settings re-prompts after a couple of hours. Ceph’s injectargs, which is how you set mon_allow_pool_delete without a monitor restart, is cleared when the monitor restarts. Putting the examples against the same six properties:

Threat models

A long unabbreviatable flag catches a fat-fingered -f and stands out to a reviewer skimming a diff. A TTY check blocks yes | tool, server-side config ignores whatever flags the client sent, and a typed phrase, on apt’s evidence, stops very little. Refusing an env-var route stops a poisoned parent process, and for package managers specifically that parent is often something the tool itself just installed.

An npm postinstall script, a setup.py, a build.rs, a Homebrew formula’s install block: all of these run with the package manager’s environment and all of them can invoke the package manager again, or export variables that the next invocation will read. When 140 @mastra/* npm packages were compromised in June 2026 the injected payload set NODE_TLS_REJECT_UNAUTHORIZED=0 in its own process before phoning home, because Node reads that from the environment unconditionally. In CVE-2024-48990 needrestart, running as root, inherited PYTHONPATH from the unprivileged processes it was inspecting and executed attacker code with it. Homebrew’s bin/brew re-executes itself through env -i with a fixed allowlist before any formula code runs, and separately strips anything matching token, key, password, cookie or auth from the environment before evaluating tap Ruby. Node’s kDisallowedInEnvvar list, cargo’s env-unsupported [source] table, and npm’s EALLOWSCRIPTS all guard against the case where the package manager’s caller is itself a package.

A global NIXPKGS_ALLOW_INSECURE=1 or GOINSECURE=* applies to every dependency resolved from that point on, including transitive ones pulled in by other packages. Nix’s version-pinned entries mean an exception granted for openssl-1.1.1w stops applying when a dependency bumps to a newer vulnerable build, and an entry in Composer’s allow-plugins map for phpstan/extension-installer applies to that plugin alone. A boolean override reaches everything downstream of it; a named one reaches what it names.

pip’s PEP 668 error message ends with “You can override this, at the risk of breaking your Python installation or OS, by passing –break-system-packages.” apt’s error, when -y is passed, reads “Essential packages were removed and -y was used without –allow-remove-essential”, while the interactive error a human at a terminal sees omits the flag, so of apt’s two code paths the automated one is the one told how to bypass. pip’s message and apt’s -y message both spell out the next command for anything that parses error output and retries: a CI wrapper, a build.rs shelling out to the system package manager, a provisioning script, or increasingly an agent that reads stderr as instructions.

Releases

Go 1.27 is out. On the module side, go mod tidy now consolidates duplicate require blocks into the canonical direct/indirect pair for modules declaring go 1.27 or later, go doc accepts package@version to fetch documentation for a specific module version, and the go command drops support for fetching modules from Bazaar repositories. A compress/flate encoder change also means archive/zip and compress/gzip produce different bytes than under Go 1.26, which is worth checking anywhere a Go-built tool’s archive output is hash-pinned downstream (forge tarball endpoints, module proxies, release pipelines).

Rust 1.98 ships Cargo with an unstable -Zmin-publish-age flag implementing RFC 3923: resolution filters out crate versions published more recently than a configured threshold. It also fixes a 1.96 Windows regression in cargo:token-from-stdout credential providers.

Bun 1.4 is the first release of the Rust rewrite, the bulk of which Jarred Sumner produced from the Zig codebase with Claude Code workflows. It fills out the package manager subcommands: bun pm diff shows un-minified source diffs between package versions and flags new install scripts, bun audit fix upgrades vulnerable dependencies, bun dedupe and bun prune clean up the lockfile and node_modules, GitHub and tarball dependencies now record SHA-512 hashes in the lockfile, and only packages from the npm registry are auto-trusted to run install scripts by default.

pnpm 11.22 shipped alongside a 11.21–11.22 recap: pnpm install now edits the lockfile in place for most everyday manifest changes without re-resolving the whole dependency graph, global installs switch over atomically, pnpm cache path prints the store location, and a project’s pnpm-workspace.yaml can no longer relocate machine-level state directories. pnpm 12 reached RC 8: the registries setting is now keyed by URL with scopes and tarball layout declared per entry, and packageImportMethod: auto tries hardlinks before reflinks on Linux, roughly halving the time to materialise node_modules from a warm store on btrfs.

Hex 2.5 surfaces security advisories during mix deps.get and mix deps.update, printing a summary of vulnerable packages at the end of the run. A cooldown setting withholds versions younger than a configured age from resolution, lifted automatically when the currently locked version is itself retired or has an advisory, and organisations can publish signed dependency policies that opted-in projects apply centrally.

Renovate 44.33.0–44.39.1 adds PEP 691 JSON simple index support to the PyPI datasource and passes POETRY_SOLVER_MIN_RELEASE_AGE through to Poetry when minimumReleaseAge is configured.

Also out:

• Gradle 9.7.1
• conda 26.7.1
• PDM 2.28.2
• Homebrew 6.0.18
• Chocolatey 2.7.4
• Verdaccio 6.9.3
• Dependabot Core 0.392.0
• mise 2026.8.10
• Harbor 2.15.2
• RPM 6.1.0
• RubyGems 4.0.19
• snapd 2.76.3
• DNF5 5.4.4.0
• opam 2.6.0-beta1
• diffoscope 329

Security

crates.io removed malicious versions of arrayref, internment, append-only-vec and several typosquat crates published from a compromised maintainer account. The malicious versions carried a build script that downloaded a remote payload and were live for under two hours before deletion; the post gives a command to check the local Cargo cache for the affected versions.

sbt 2.0.6 and 1.12.15 fix GHSA-m2pw-22cj-jq4v, a remote code execution via the sbt server when serverConnectionType is set to Tcp, and 2.0.7/1.13.0 fix the same class of bug in the BSP handler (GHSA-943m-f264-54p4). Builds using the default Unix domain socket connection type are unaffected.

Articles

What’s missing to have reproducible builds on PyPI (Brett Cannon) sets out three gaps: distributions don’t record the source location they were built from, sdists have no standard place to store build-environment SBOM data the way wheels do, and there’s no channel for independent verifiers to attest to PyPI that they reproduced a distribution.

Protecting the Rust standard library from breakage (Predrag Gruevski): rust-lang/rust CI now runs cargo-semver-checks against core, alloc and std, treating #[stable] and #[unstable] attributes as the public-API boundary. Getting there meant new stability fields in rustdoc’s JSON output and threading them through the linter’s query layer without rewriting existing lints.

Spinel dev log, July 2026: the Ruby tooling cooperative’s monthly update on rv (a Ruby version manager with its own precompiled Ruby builds), the Dyad shell helper, and brut-pack for bundling scripts.

How mature is this repository? (Alexandre Dulaunoy) introduces OSSTRL, which computes a 1–9 Technology Readiness Level for a GitHub repository from automatically gathered evidence across community, governance, development, support and security dimensions, with maturity gates so a single strong signal can’t inflate the overall level.

Papers

Implicit, Yet Impactful: Understanding Hidden Dependencies in Java Projects (Zhang et al., arXiv) measures transitive Maven dependencies whose classes are referenced directly by a project’s own code without being declared: across 972 GitHub modules, 34% contain at least one, 48% of those introduce breaking API changes, and 36 CVEs in the sample expose vulnerable methods that the root project calls directly.

SMTpip: Interpreter-Aware SMT-Based Dependency Conflict Resolution (Sakib et al., arXiv) encodes both package version constraints and Python interpreter compatibility as SMT formulas so a solver can decide up front whether a satisfying environment exists, reporting a 6.9× speedup over pip’s backtracking resolver on their benchmark.

Elsewhere

Commonhaus and HeroDevs launch OSSI (Josh Bressers, Open Source Security): an interview with Erin Schnabel and Rob Nalen on a partnership funding CVE remediation and extended support for end-of-life releases of Commonhaus-hosted projects, starting with Hibernate, Jackson and Quarkus.

How AWS powers PyPI and the PSF (PyPI blog): AWS’s open source credits programme covers PyPI’s infrastructure bill and its security sponsorship funds engineering time, but PyPI is currently maintained by roughly one and a half full-time engineers plus one on support. A line describing PyPI as a supply chain risk given that staffing was later reworded.

Inside Modern Software Engineering with Homebrew’s Mike McQuaid (Giant Robots podcast): an interview covering Homebrew’s history and open source maintainership.

Sustain #293 has Daniel Roe and Matias Capeletto on npmx, the community-built npm registry browser, covering how the project reached hundreds of contributors since January and its governance and funding.

git-pkgs

I tagged 16 repos this week:

• artifacts v0.1.1 (new), a Go library that describes a completed package file as a canonical package URL, an OCI-form content digest and a byte count, with optional filename and media type carried alongside
• integrity v0.1.1 (new), a Go library that parses Subresource Integrity metadata (SHA-256/384/512, standard or URL-safe base64) and verifies package byte streams against it as they are read
• brief v0.11.0
• clone v0.5.0
• cooldown v0.2.0
• enrichment v0.7.0
• forge v0.9.0
• licenses v0.6.0
• managers v0.11.0
• manifests v0.10.0
• pin v0.2.0
• pom v0.1.7
• purl v0.1.17
• registries v0.8.1
• sigstore v0.2.0
• vers v0.6.0

Send links for next week to @andrewnez@mastodon.social.

The projects sort by where they physically put the data, and each storage location brings its own answers to the same handful of questions: whether a plain git clone fetches it, what happens when two people edit the same issue offline and then both push, whether you can read it without the tool installed, whether it survives being pushed to a bare git host that has no support for the tool, and who counts as the author of an issue when there are no forge accounts. I wrote about git’s extension points last year and several of these tools use the custom-ref mechanism from that post, but here I’m looking at the data model rather than the plumbing.

Files in the working tree

The oldest approach is to make each issue a text file, or a directory of files, checked in next to the source. Bugs Everywhere did this in 2005 for Bazaar and later added git and Mercurial backends, and ditz stored issues as YAML from 2008. More recently GitRoot builds an entire self-hosted forge on the same idea, keeping issues as issues/<id>-<slug>.md with front-matter status fields, users and permissions as YAML under .gitroot/, and a small server that renders the lot as a web UI. Matthew Martin pointed at his own ticket directory that reuses keep-a-changelog fragments as lightweight work items with no tooling at all, which is about as minimal as this pattern gets.

In Diomidis Spinellis’s git-issue the .issues/ directory is itself a nested git repository with its own .git, sha-bucketed as issues/ef/1a04f.../description, .../tags, .../assignee and so on. That keeps the outer project’s history untouched, though the outer clone then doesn’t carry the issues at all.

Because the issues are ordinary tracked files, everything git already does works with no extra configuration: git clone fetches them, grep -r searches them, cat reads them, git bundle packs them, any dumb HTTP host or cgit instance serves them, and git log -p .issues/ shows who changed what and when. Concurrent edits to the same issue become a normal three-way text merge. That works cleanly when two people append separate comments to the bottom of a file, and produces a real conflict when they both change the title line, which you resolve the same way you’d resolve a conflict in code. The author of an issue is whoever git blame says created the file, backed by whatever commit signing the project already uses, so identity comes from git’s existing model rather than needing its own.

The drawback is that issue history and code history share one commit graph. On a busy project git log fills with “reword issue #34” interleaved with real changes, git bisect steps through issue-edit commits, and creating a feature branch forks the issue state along with the code, so an issue closed on the branch shows as open again the moment you switch back to main. Most of these tools work around the log noise by making each issue operation its own commit with a conventional prefix that’s easy to --invert-grep away, but the branching problem is unavoidable while mutable metadata is in the same tree as the code it describes.

Orphan branch

An orphan branch is a ref under refs/heads/ whose root commit has no parent, so it shares no history with main and its files never appear in a normal checkout. Scott Chacon’s ticgit from 2008 and the later ticgit-ng fork keep issues on a branch literally called ticgit, with each issue as a directory in that branch’s tree, and GitHub’s old gh-pages convention used the same mechanism for documentation. The very new haxy forge from the xit project puts an event log on refs/heads/haxy/events where each commit has an empty tree and the commit message is a JSON event describing an issue creation, comment, or status change; the server replays the log to build its state.

The tool reads and writes the branch through plumbing or a second worktree, so git log on main stays free of issue noise, merging concurrent edits works the same as for any files on a branch, and the issue author is whoever authored the commit on the orphan branch. Because the ref is under refs/heads/ a default git clone fetches it automatically, which is the one clear advantage this has over the notes and custom-ref approaches below.

$ git ls-tree ticgit
040000 tree 9b721cc...  1206206148_add-attachment-to-ticket_138
040000 tree 5d14214...  1206206166_download-attached-file_112

$ git ls-tree ticgit:1206206148_add-attachment-to-ticket_138
100644 blob cfdb466...  ASSIGNED_schacon@gmail.com
100644 blob 3074cf0...  COMMENT_1206206148_schacon@gmail.com
100644 blob f510327...  STATE_open
100644 blob 6d44874...  TAG_attach
100644 blob 9ebd07e...  TICKET_ID

Ticgit encodes almost everything in filenames (STATE_open, TAG_attach, ASSIGNED_<email>) so git ls-tree alone shows the state of an issue without reading any blobs. Haxy puts everything in the commit message instead, so git log haxy/events is the entire database, and in both cases the data is legible with stock git and no extra tool installed.

The trouble with an orphan branch is that it shows up in git branch -a looking like any other branch, so on a project with enough contributors someone will eventually delete the “stale” ticgit branch while tidying up. A git push --prune or git push --mirror from a clone made with --single-branch, or from a CI job that only fetched main, deletes it on the remote because the local side has no matching ref. Branch protection on most forges is pattern-based (main, release/*) and won’t cover a branch called ticgit unless someone remembers to add it.

Checking the orphan out in your only working tree swaps every file for the issue files, which is why the tools read it through git show ticgit:path rather than git checkout. The objects are safe from git gc for as long as the ref exists, but once the ref is deleted the entire disconnected graph becomes unreachable and the next gc --prune removes it, and on a stock bare host there is no server-side reflog to recover from.

git notes

Git ships with a notes facility that attaches arbitrary blobs to existing commits without rewriting them, stored under refs/notes/<namespace>. The notes ref points at an ordinary commit whose tree maps each annotated commit’s SHA to a blob, so adding a note is itself a commit and the full edit history is kept. Google’s now-archived git-appraise built distributed code review entirely on this: review requests are line-delimited JSON under refs/notes/devtools/reviews, threaded comments under refs/notes/devtools/discuss, and CI status under refs/notes/devtools/ci, all attached to the commit being reviewed.

$ git for-each-ref refs/notes/
e70fe480... commit  refs/notes/review

$ git cat-file -p refs/notes/review^{tree}
100644 blob 677b652c...  0a72c46f9a191c6097f708ccdabcd6af13eebede

$ git cat-file -p 677b652c
{"timestamp":"2026-08-18T00:00:00Z","reviewRef":"refs/heads/main",
 "targetRef":"refs/heads/master","description":"Demo review request",
 "requester":"andrew@example.com"}

Notes are not fetched by a default clone; you add fetch = +refs/notes/*:refs/notes/* to the remote config once and then they travel with every pull and push. Merging has first-class support in git itself via git notes merge, and the cat_sort_uniq strategy concatenates and dedupes conflicting notes line by line, which is why git-appraise stores one JSON object per line rather than a single pretty-printed document. Any git host accepts the ref, git log --notes='*' shows notes inline under each commit, and git bundle create backup.bundle --all packs them. Identity is the author of the notes commit, plus whatever the payload records; git-appraise puts the requester’s email in the JSON. The structural limitation is that a note has to hang off an existing commit, which suits code review and CI results very well and suits a bug report that isn’t about any particular commit rather less.

Custom ref namespaces

The approach most of the currently-active projects have settled on is to store data under a ref namespace outside refs/heads/, so nothing shows up in git branch, nothing touches the working tree, and the tool controls the object layout completely. git-bug is the most developed example: each bug is a chain of commits under refs/bugs/<id>, each commit’s tree holds an ops blob of JSON operations plus zero-byte marker files whose names encode Lamport clock values, and user identities are separate chains under refs/identities/<id>.

Gerrit’s NoteDb keeps every change’s review metadata as a commit graph at refs/changes/NN/NNNN/meta and has run Google’s own code review without a SQL database since Gerrit 3.0. Radicle stores issues and patches as collaborative objects under per-peer refs/namespaces/<nodeid>/refs/cobs/ and merges them over a gossip protocol rather than push. git-native-issue keeps each issue as a commit chain under refs/issues/<uuid> where the tree is empty and the metadata is carried in commit-message trailers (State: open, Labels: bug) rather than JSON, with a published format spec intended to be readable by any tool. Even the centralised forges use this layer for the code half of a pull request, exposing refs/pull/N/head on GitHub and refs/merge-requests/N/head on GitLab, though those are written by the forge and read-only to clients.

$ git fetch origin 'refs/bugs/*:refs/bugs/*' 'refs/identities/*:refs/identities/*'
$ git for-each-ref refs/bugs/ | head -1
aecc49e1... commit  refs/bugs/0066216d1e0cc97ad1c9eaa553459ca85a0d57e133e...

$ git cat-file -p aecc49e1^{tree}
100644 blob e69de29b...  create-clock-354
100644 blob e69de29b...  edit-clock-2314
100644 blob 588a2a80...  ops
100644 blob e69de29b...  version-4

$ git cat-file -p 588a2a80
{"author":{"id":"193531e4590156..."},
 "ops":[{"type":1,"timestamp":1722433238,
         "title":"Issue running the example_test.go",
         "message":"Hi y'all, I'm really excited...","files":null}]}

A default clone skips these refs entirely, so the first thing every tool does is add its refspec to .git/config. After that the data pushes to and pulls from any git host that accepts arbitrary ref names, which today is all of the major ones. Every clone that adds the refspec carries the full issue history, which is 454 refs for git-bug’s own repo but would be considerably more on a project with the issue volume of rails or kubernetes.

Because each edit is appended as a new commit rather than modifying an existing blob, two people editing the same bug offline produce two divergent tips that the tool merges by replaying both operation logs against the Lamport clocks, and there is never a text-level conflict to resolve by hand. That also means that when two people set the same field offline the replay picks a winner by clock order without surfacing a conflict. The raw objects are inspectable with git cat-file as above but not really readable without the tool. Identity is handled inside the data model: git-bug stores name, avatar and login in a versioned identity object, and Radicle derives it from the node’s Ed25519 key.

git-bug also ships bridges that import from and export to GitHub, GitLab and Jira, so an existing tracker can be mirrored into refs/bugs/ and kept usable through exactly the kind of outage that started this post. Forgejo has an open feature request for storing its own issues this way, and one proposal in that discussion is to treat refs/issues/* as the canonical store with the forge’s SQL tables rebuilt from it as a query index.

Built into the VCS

Fossil was designed from the start with tickets, wiki pages, forum threads and technotes as artifact types stored alongside check-ins in the same content-addressed store, all packed into a single SQLite database file per repository. A ticket exists as a set of immutable artifacts that each declare changes to named fields, and the current state of a ticket is computed by applying every artifact with a matching ticket id in timestamp order. SourceGear’s Veracity took a similar line around 2011 with a distributed bug database synced alongside the source DAG, though the project has since been discontinued.

$ fossil artifact 94cd0c6265
D 2026-08-18T06:37:37.865
J comment Something\sis\sbroken
J priority Medium
J status Open
J title Demo\sbug
J type Code_Defect
K 821e9e51da937dc2c37227ef8ed57c757e7530f0
U andrew
Z 1c440428fff5e32c7c5304e9f6cd5bec

The card format is one letter per line type: D is the timestamp, each J is a field assignment with spaces escaped as \s, K is the id of the ticket this artifact modifies, U is the user, and Z is an MD5 of the preceding lines. Syncing exchanges any artifacts the other side lacks, concurrent edits to the same ticket both survive as separate artifacts, and because each J card sets one field the effective merge policy is last-writer-wins per field with no conflict markers.

Everything travels with fossil sync or fossil clone because there is only one file. Identity is the U card backed by Fossil’s own login system, and the whole thing is readable with fossil ticket show or by opening the SQLite file directly. The obvious drawback is that none of this is git, so it composes with git-based tooling only through import and export.

git bundle

Aslak Raanes asked in the thread whether these approaches survive git bundle, which is the closest thing git has to Fossil’s single-file repository and the easiest way to get an offline backup onto a USB stick. I tried it: git bundle create backup.bundle --all on a clone of the git-bug repo with refs/bugs/* and refs/identities/* fetched packs all 454 bug refs and every identity into the bundle, and the same on a repo with refs/notes/review includes the notes ref. That works because --all to git rev-list means everything under refs/, and a bundle is just a packfile with a ref list on the front. So for every git-based approach here, files in tree, orphan branches, notes, and custom refs alike, one bundle file holds the code and the issue tracker together.

Registries with their own accounts

npm, PyPI, RubyGems, Packagist, Docker Hub, Hex.pm, Clojars, Hackage, and CPAN’s PAUSE each have a username-and-password identity system of their own, so 2FA on each has been implemented separately with its own enforcement policy. PyPI is the only one where enforcement is complete: 2FA has been mandatory for every account since 1 January 2024, with TOTP and WebAuthn both accepted, after a run-up that included distributing 4,000 hardware keys to maintainers of top projects in 2022. Publishing to npm requires either 2FA or a granular access token carrying a bypass flag. This month’s change closes the bypass for account-governance actions, and the September 2025 plan proposes removing it for local publishing as well, though that step has not yet landed. Mandatory enrolment on npm has run in cohorts since 2022: top 100 by dependents in February, top 500 in May, then high-impact packages at a million weekly downloads or 500 dependents.

RubyGems supports WebAuthn and TOTP and has required it since August 2022 for owners of any gem with more than 180 million total downloads, with a per-gem rubygems_mfa_required metadata flag for maintainers who want to opt the rest of their co-owners in. TOTP has been available on Packagist since 2019, and the Packagist team’s May 2026 post sets out mandatory MFA across packagist.org as the direction, with organisation-level enforcement and a requirement on maintainers of larger packages as the concrete first steps. Hex.pm supports TOTP and offers GitHub login alongside its native accounts. TOTP is already required when publishing over the OAuth device flow, which is the default in the mix and Gleam CLIs, and the July 2026 basic-auth deprecation sets 1 November 2026 as the date from which 2FA applies to every write operation on the API.¹

Docker Hub and Clojars each support TOTP as an account option with no mandate, WebAuthn is not available on either, and SMS is not a supported second factor anywhere in this group. Hackage has an open issue from November 2023 with a volunteer to implement it, and PAUSE authenticates uploads with a password and sends a notification email on every upload as the check on unexpected activity.

Registries that delegate identity to a platform

crates.io authenticates exclusively through GitHub OAuth, so a crates.io login carries whatever protections the GitHub account behind it has, and the same is true of pub.dev against Google accounts and the public Terraform Registry against GitHub. There has been discussion of having crates.io refuse logins from GitHub accounts without 2FA enabled, which the GitHub API exposes, but it has not been implemented. RFC 3946, accepted in May, introduces a crates.io-native username so that an account’s identity is no longer its GitHub username, and the July 2026 development update reports the implementation as started, which opens the way for other identity providers and would move crates.io towards the first group.

NuGet.org delegates authentication to Microsoft and Azure AD accounts and has required 2FA on the linked identity for new accounts since 8 March 2022, with existing accounts phased in over the following two months: sign-in to NuGet.org redirects to the Microsoft 2FA enrolment screen for any account without it, without changing that account’s global 2FA setting. That makes NuGet the earlier of the two registries in this survey with a universal requirement, and the requirement is NuGet.org’s own policy applied through an identity system it does not run.

Sonatype’s Central Publisher Portal for Maven Central, which replaced the old OSSRH JIRA-based signup, supports GitHub and Google social login alongside a portal-native username and password. There is no second factor on the portal’s own login, so a Central account has 2FA only to the extent that a linked GitHub or Google account does, and Sonatype’s 2FA support elsewhere in its product line does not extend to Central. Maven Central separately requires every published artifact to be PGP-signed, which is a control on the artifact rather than the account.

Registries that are a git repository

Homebrew, conda-forge, Spack, nixpkgs, Guix, and Julia’s General registry keep their package definitions in a git repository and accept new packages and version bumps as pull requests, so there is no separate registry publisher account and any second factor is on the forge account instead. GitHub Actions, where an action is any repository with an action.yml, works the same way with the marketplace listing on top. For the ones hosted on GitHub the effective policy is GitHub’s contributor 2FA programme, on which GitHub reported in April 2024 that 95% of the users targeted through 2023 had enrolled, with the requirement applied to groups selected by “the impact of their user privileges or specific actions they took” rather than to every account, so whether a homebrew-core or conda-forge committer is subject to mandatory 2FA is determined by GitHub’s targeting rather than by anything the registry sets. A committer to one of these repositories necessarily contributes code on GitHub and so falls within the programme’s selection criteria, unlike a crates.io or Terraform Registry publisher who only needs a GitHub login and may hold an account the programme has not reached. Guix has been hosted on Codeberg since May 2025, where TOTP and WebAuthn are available with no mandate.

Email-gated and account-free

CRAN accepts submissions through a web form and email confirmation with human review of every package, CocoaPods trunk authenticates with an emailed session token, and neither has an account database that a second factor would attach to. Trunk is scheduled to stop accepting new podspecs on 2 December 2026 after a read-only trial in the first week of November, which will make the question moot for that registry. The Go module proxy and the Swift Package Index have no publisher accounts at all: proxy.golang.org is a caching mirror of module versions fetched from their VCS hosts, and the Swift Package Index is a discovery layer over repositories it does not host.

Publishing from CI

A CI job cannot tap a security key, so publishing from CI on any registry that enforces 2FA at publish time requires a path other than an interactive login. Long-lived API tokens with the 2FA check waived have been that path historically, as with npm’s bypass flag and RubyGems’ automation-scoped keys, and the current round of changes on both registries is narrowing it. Trusted publishing replaces the stored token with a short-lived OIDC token that the registry verifies against a pre-registered CI workflow, so the credential is bound to the workflow that built the artifact and no maintainer credential is involved in the publish. PyPI added it in April 2023, followed by RubyGems in December 2023, npm and crates.io in 2025, and pub.dev for GitHub Actions and Google Cloud.

npm’s staged publishing, generally available since npm CLI 11.15.0 in May 2026, instead keeps the second factor with a human by splitting the operation in two: npm stage publish uploads the tarball to a holding area with any token and no 2FA prompt, and the version becomes installable only after a maintainer approves it through a separate 2FA challenge on the CLI or the website. The approval step applies regardless of which token staged the upload, including one issued over OIDC, so a human 2FA challenge sits between CI and the public index even when the pipeline authenticated with trusted publishing. Packagist’s planned FIDO2-confirmed release step applies the same design to git tags, and a pre-PEP discussion opened in June proposes splitting staged releases out of PEP 694 as a standalone feature for PyPI.

Summary

Package counts from ecosyste.ms, August 2026. Distribution repositories (Debian, Ubuntu, Alpine, and similar) are omitted since publication goes through distribution maintainers rather than upstream authors.