📰 NewsMonitor

This week’s package management news, gathered from the package manager OPML feed collection, my posts and boosts on Mastodon, and anything people sent me. The collection now includes the vlt blog and vlt CLI releases. Releases uv 0.13.0 makes Python 3.15 the default download, prefers native ARM64 interpreters on Windows ARM64, and changes the cache format, so dependencies may be downloaded or rebuilt after upgrading. It now honours --require-hashes in constraints files included with -c and rejects editable requirements in them, so installs that previously passed can fail. Astral’s Python 3.15 post also covers a build-lazy-imports preview that runs build backends under -X lazy_imports=all. Astral measured wheel builds up to 18% faster with it. pnpm 12.11 installs and signature-checks the Rust toolchain named in rust-toolchain.toml, and links skills//SKILL.md files shipped by direct dependencies into directories such as .claude/skills once they are approved with pnpm approve. A new permissions setting records what each dependency may do, with its build capability taking precedence over allowBuilds. 12.10 added an experimental loaded node linker that loads compatible dependencies straight from the content-addressable store through a Node.js loader. RubyGems and Bundler 4.1.0.beta2 add gem build --content-addressable, drop setuid, setgid and sticky bits when extracting gems, let a Bundler override drop or replace a single dependency of a gem, and add a sparse_checkout option for git sources. Bun 1.4.3 skips downloading tarballs for packages that stay out of node_modules, such as bundled dependencies and packages for other platforms, when installing without a lockfile. Installing npm@10.9.2 went from 196 tarball downloads to 1. Registry and tarball URLs are also parsed more strictly before credentials are attached. mise 2026.10.1 to 2026.10.7 runs auto_update in the background from an activated shell, still honouring minimum_release_age, and stores finished downloads in a content-addressed cache that is hashed again before each reuse. java@21 and other vendorless Java versions now install Temurin builds. PIE 1.5 installs several PHP extensions in one command and adds pie upgrade, which upgrades each extension within the constraint it was installed with. --select== replaces --allow-non-interactive-project-install for unattended installs, and the Sigstore attestation library PIE uses to verify its own updates now accepts attestation sources other than GitHub. cargo-semver-checks 0.51.0 adds six lints for C-ABI variadic functions, which are new in Rust 1.99. This is the first language feature to get SemVer lints in the same release that added it. The project’s own dependency updates now use -Z min-publish-age with seven days and an allowlist of build scripts pinned by hash. Docker Engine 29.9.0 adds a lazy-pull daemon feature that skips layer content a remote snapshotter such as soci or stargz already provides, and fixes containerd-store pulls that left images runnable but incomplete for export or push. jj 0.46.0 can colocate secondary workspaces by creating Git worktrees, and jj git push can push to several remotes at once. Terraform 1.17.0-rc1 allows variables and locals in provider requirements. Also out: Homebrew 7.0.9 pipx 1.17.12 conda 26.9.2 opam 2.6.1 Elm 0.19.3 vlt 1.3.8 setup-uv 10.3.0 NuGet 8.1.0.2 Gradle 8.14.6 Stack 4.1.0.3 RC Harbor 2.15.4 snapd 2.78 Renovate 44.149.1 Dependabot Core 0.399.0 Security Gradle 9.8.1 fixes three high-severity advisories: Deserialization of untrusted Java objects on the unauthenticated worker-to-daemon channel Deserialization of untrusted Java objects before authentication in client-to-daemon communication Repositories staying enabled after their SSL connection fails, which can expose builds to malicious artifacts pnpm 12.10 stops a dependency version string with path traversal from writing files outside the global virtual store, and stops a lockfile overriding the integrity of a config dependency pinned with version+integrity. pnpm audit signatures now checks against the integrity recorded in the lockfile, and archive metadata over 64 MiB is rejected before being loaded into memory. 11.28.5 carries the fixes on the 11.x line. Go 1.27.2 and 1.26.9 include security fixes to the go command along with crypto/tls, html/template, net/http, net/textproto and os. SCORED The SCORED 2026 workshop ran on Tuesday as part of OpenSSF Community Day Europe in Prague, and most sessions have slides on the schedule. A few were preprints already linked here: Software Dark Matter, which won best paper, No Snake Oil, the trusting-trust attack through GNU strip, and the lemons review. Hurry Up and Wait: Malware Detection Timelines and Minimum Release Age for npm (Dominic Tassio et al., SCORED) matches 520 malicious package versions from 403 CWE-506 GitHub advisories against npm publish times. 69% of attack windows closed within eight days, and weighting by downloads raises that to 94.2%, and the authors recommend an eight-day minimum release age. Did You Forkget It? Detecting One-Day Vulnerabilities in Open-source Forks With Global History Analysis (Romain Lefeuvre et al., SCORED) propagates OSV introduced and fixed commits across the Software Heritage commit graph. Starting from 7,162 repositories referenced in OSV, it finds 2.2 million forks carrying a presumed vulnerable commit, 1.7 million of them with an unpatched head. When SBOMs Differ (Lukas Gehrke et al., SCORED) publishes over 467,000 SBOMs for 93,445 repositories from Syft, Trivy and the GitHub dependency graph. The three sources produce different dependency sets and encode dependency structure differently, and sbomqs scores their output differently against regulatory guidelines. Mind the Gap: How SBOM Specification Ambiguities Lead to Divergent Software Bills of Materials (Alan Prado et al., SCORED) compares three SBOM generators against lockfiles for over 3,000 JavaScript and Rust projects. Most of the differences are systematic and come from each generator handling dependency scope, naming, provenance and representation in its own way. Over the Shoulder: Improving SBOM Accuracy by Watching the Build (Sanchit Sahay et al., SCORED) evaluates SBOMit, which records filesystem and network activity during a build with eBPF as in-toto attestations and turns them into package identities. Across 98 CNCF projects the median runtime overhead was 12.4%. Librarian Catches Thief (Gale Fagan, SCORED) runs document similarity over ClawHub, where attackers uploaded hundreds of near-identical agent skills that led users to credential-stealing malware. The scan found the campaigns and linked poisoned copies to the skills they were cloned from. It ran in five minutes on one workstation. Canary in the Code Mine (Timothy Brennan, SCORED) tries to predict which of 2,053 Jenkins plugins will get the next security advisory. A ROC-AUC of 0.96 turned out to come from a label leak, and the out-of-time figure under a pre-registered protocol was 0.67. Repeating the protocol on PyPI reproduced the leak and reversed which features came out as predictive. SandScope (Zhuoran Tan et al., SCORED) audits MCP servers by running them under WASI or over stdio and tracing environment, file and tool-input data into LLM-visible output. It completed shallow dynamic scans for 38.5% of a 100-repository MCP corpus. When Models Meet Loaders: Deserialization Risk in Huggingface (Xiang Guo et al., SCORED) measures how common 41 model serialization formats are across 10,000-model snapshots of Hugging Face taken at 39 points in time, 56,533 models in total. Each format depends on its own deserialization library, which becomes part of the supply chain of any application loading the model. SoK: What Software Supply Chain Security Can Learn from Decades of Physical Supply Chain Risk Management (Linus Kühl and Michael Dircksen, SCORED) maps 17 physical supply chain instruments onto software counterparts, such as bills of materials to SBOMs and dual sourcing to tested substitute dependencies. Five transfer directly and ten need adaptation. Safety stock fails to transfer because software copies are not used up, and threat modelling transfers in the other direction. Ghost in the Codebase (Luca Galli, Open Systems, SCORED) describes how Open Systems moved to a Bazel monorepo with one version per dependency after tracking Log4Shell by hand, then added SCA and SAST gates in CI that emit SARIF. Coding agents now go through the same gates, with an agent skill that reads the SARIF report. Papers Skill Constellations: Tracing the Supply Chain of Agent Skills on GitHub (Fahd Seddik, arXiv) builds a dated copy network from the git history of every SKILL.md in GitSkills, covering 2.2 million skill adoptions. A few repositories are the source of almost all copies, and almost all copies stay at the version they were copied from. Reviewing the top 100 source repositories would prevent 14.9% of later adoptions of high-risk skills, against 0.5% for the 100 most-starred. Assessing the Cross-Version Applicability of Java Library Vulnerability Exploits (Zirui Chen et al., ASE) runs 259 exploits against 28,150 versions of 128 Maven libraries. Unmodified exploits identify affected versions with 83.0% recall and 99.3% precision, better than most vulnerability databases, and the work contributed 796 missing affected versions to the CPE dictionary. Articles How we made registry metadata 70% smaller (vlt) describes the trimmed packument vlt.io serves by default, which shrinks vite’s from 4.41 MB to 104 KB. It drops dist.signatures, dist.shasum and attestation documents, which are base64 and hex strings that compress poorly under gzip, but keeps time, license and libc so pnpm and Bun can run minimum release age checks from the trimmed document. A ?stable query filters prereleases, which are 58.6% of published versions across the top 1,000 packages. The Era of Software Quality, or the Era of Ostriches? (Michael Catanzaro) counts GNOME CVEs rising from 37 in 2024 to 97 in 2025 and 141 so far in 2026, and WebKitGTK reaching 305 this year, mostly from AI analysis of bundled Skia and ANGLE. The GNOME bug bounty paid €183,900 before ending in February because of AI-driven submissions. Catanzaro opposes Rust in GNOME because of the supply-chain risk of pulling in Cargo dependencies. Rewind VM: a flaky build you only catch once (Farid Zakaria) runs Nix builds in a single-vCPU KVM guest where clocks, interrupts and I/O completions are recorded, so each run is reproducible, and rewind check perturbs thread schedules to find failing interleavings. It found a SIGPIPE failure in a Nix test that had passed 20,000 runs on a laptop. The follow-up, Nix wrote half of my debugger, uses nixpkgs’ separateDebugInfo outputs and debuginfod to show symbols and source for every binary in the VM, kernel included. Mirko Swillus wrote up the Alpha-Omega roundtable at Open Source Summit Europe. Abandoned packages, the Bernies I wrote about in May, make up roughly 10 to 20% of the dependency trees behind critical infrastructure, and some package managers are starting to recommend replacements. Participants proposed ecosystem councils to prioritise abandoned packages by blast radius. Elsewhere The Deno team is joining Cloudflare, and JSR stays online with its infrastructure moving to Cloudflare. The Deno runtime gets monthly bug fix and security releases for one more year, after which Cloudflare stops developing it, and Deno Deploy shuts down in six months. Guix channel files can now be an alias for a remote file with downloaded-channels, which takes an HTTPS URL or a SWHID, so the channel commits everyone pulls can be set from a CI server or by one person on a team. R-Forge is being retired after 20 years because the FusionForge software it runs on is unmaintained. The site goes read-only in January 2027 and SVN in January 2028. git-pkgs I tagged proxy v0.9.1. Send links for next week to @andrewnez@mastodon.social.

Ladies and gentlemen, we are in a glorious, splendiferous, outrageous era of crap! 

Some call it “high-yield,” some call it “speculative-grade,” but to those of us living in the real world, we know them as junk bonds, the formerly-sleepy world of below-

An actual post from the sitting president of the United States: The White House considers anyone that uses the term, “Artificial Intelligence,” as opposed to the highly accepted new and more accurate term, “Super Intelligence,” THE ENEMY! President DONALD J. TRUMP His screws are so loose you can hear them rattling around.  ★

David Smith, last week: Been really interesting to watch the iOS 27 adoption curve over the first two weeks. Clearly on a different path than previous years. Still steadily growing, at a similar rate to the ‘steady growth’ phase of most years, but without the big surge at the start. Given that this rate is largely controlled by Apple’s automatic update logic, I suspect it’s a deliberate choice. Likely because it lets them manage the Siri AI waiting list and avoid a big queue on day one. Smith’s numbers are from analytics from users of Widgetsmith and Pedometer++. If you look at his chart for Widgetsmith, there’s really no explanation other than that Apple pushing automatic updates to users more slowly than in any previous year, and I think it makes sense that this is to gate admissions to Siri AI. You can also see from his chart that has been slowing down initial .0 updates in recent years — the adoption rates were much faster for iOS 15 and 16 back in 2021 and 2022. Note too that every year Apple makes it more and more likely that users will opt into automatic software updates. The overwhelming majority of iOS users get OS updates when their devices update themselves. (It’s purely personal anecdata, but I feel like Siri AI has gotten worse since iOS 27.0 was officially released. It feels a bit slower and I seem to get worse answers, sometimes. I asked it for a word today, using it as an interactive thesaurus, and it simply told me it couldn’t. It never did that over the summer. I started using iOS 27 full-time on my iPhone the day after the WWDC keynote and I got into the Siri AI beta the next week. While it might be some sort of placebo effect, I feel like Siri AI was better — slightly faster and more useful — in July and August than it is now. I could be wrong, or maybe just unlucky of late. But I’m also quite certain that scaling up the Private Cloud Compute side of Siri AI is a massive challenge for a platform with over a billion Siri AI-eligible users.)  ★

It’s almost like you can predict the timing of such things, if you pay attention to Apple’s consistent patterns.  ★

In 1960, a team at the University of Illinois released the first version of their PLATO “computerized instruction system,” a network of what would eventually be thousands of computer terminals connected to large mainframe computers.

Monte Carlo simulations (or methods) is the technique of applying randomness and the Law of large numbers to the solution of various scientific and engineering problems. One of its first documented uses was by Stanislaw Ulam and John von Neumann for nuclear weapon simulations after WWII [1]. In this post I want to provide examples of some simple uses of Monte Carlo simulations. We'll start with the classical example of calculating the value of \pi by throwing darts. Estimating pi Suppose we take a square board and inscribe a quarter of a circle into it. We then proceed to throw darts at the board and record whether each dart hits inside or outside the quarter circle. Having thrown many such darts, we calculate the ratio of the darts inside the circle to the total number thrown. Assuming our darts are distributed uniformly over the square, by the Law of large numbers this ratio should approach the ratio of areas of the quarter circle A_{circ} to the full square A_{square}. With a square side length of 1, we have: [\frac{A_{circ}}{A_{square}}=\frac{\pi/4}{1}=\frac{\pi}{4}] Therefore: [\pi\approx 4\frac{ ext{hits inside}}{ ext{total throws}}] Here's a visualization: 200

101000 Run

π ≈ —

Change the number of samples (dart throws) and click "Run" to regenerate. The code is very simple - here's a slightly sanitized version: const total = Number(samples.value); let inside = 0; for (let i = 0; i < total; i++) { const x = Math.random(); const y = Math.random(); const inCircle = x * x + y * y <= 1; if (inCircle) inside++; } estimateValue = 4 * inside / total;

You'll notice that the estimate is relatively poor - even with 1000 samples - if you click "Run" several times, some numbers will be way off mark. While this method does estimate \pi, it's not a particularly good estimate. I find that running ~10 billion samples is necessary to estimate it to 4 digits after the decimal with reasonable reliability. In general, for independent trials like these, the typical sampling error decreases in proportion to 1/\sqrt{N}, where N is the number of trials. This means that halving the error requires four times as many samples. While the \pi estimation may seem whimsical, it's an example of an important class of problems to which Monte Carlo simulation is applied: numerical integration. Our simulation estimates the area under the quarter-circle curve, which is a definite integral. Many integrals are very difficult to solve analytically, and much research has been done in the area of numerical analysis to develop methods to calculate integrals. Monte Carlo methods are particularly useful for high-dimensional integrals, where other numerical methods can become prohibitively expensive. Combinatorial simulation - the game of SET A common use of Monte Carlo methods is estimating complex combinatorial calculations. These often don't have analytical solutions, and enumerating all options is intractable due to the scale of the numbers involved. As an example, let's consider the game of SET. Each SET card has four attributes: Number of shapes (1, 2 or 3) Color (Red, Green or Purple) Shape type (Oval, Diamond or Squiggle) Shading (Empty, Striped or Solid) And the goal is to find a "set" - three cards that are either all different or all the same for each attribute separately. As an example, here's a hand with a single set; see if you can find it [2]: SET hand with a single set And the next hand doesn't have any sets: SET hand with no hands Here's a question: given a freshly shuffled SET deck, what are the odds that the first 12 cards drawn will have no sets among them? This question is difficult to answer without using a computer. It's easy to calculate the number of ways to deal a 12-card hand from a deck of 81: [\binom{81}{12}=70,724,320,184,700] But how many of these hands have no sets? Enumerating 70 trillion SET hands and checking each one can take quite a while, and there is no straightforward counting formula to answer this question. Some clever methods can be employed to leverage symmetries and other mathematical properties of SET to cut down this search space considerably. Donald Knuth himself worked on this problem and came up with a neat program (setset-all on his programs page) that found 2,284,535,476,080 such hands. Therefore, the answer to our question is: [\frac{2,284,535,476,080}{70,724,320,184,700}\approx 0.0323] There's a 3.23% chance that a randomly drawn hand of 12 cards from a full deck of SET will have no set in it. Let's see how we can use a Monte Carlo simulation to answer this question with relatively small effort, without deep knowledge of the mathematical properties of SET that enable cutting down the search space Knuth-style. We can use the following pseudo-code: C = 0 run N times: draw a random 12-card hand from a fresh deck count sets in the hand if no sets: C += 1

Estimated probability = C / N

After running 10 million simulated draws, I got an answer of 0.0323, which matches the real answer very closely. The Monte Carlo approach lets us solve rather complicated problems in a very simple way. Suppose we want to answer the same question for a hand of 15 cards; this would blow up the search space considerably - there are about 100x more ways to select 15-card hands than there are to select 12-card hands. But for a Monte Carlo simulation, we adjust one small parameter and get a very reliable [3] answer (about 0.00037, in case you were wondering). Retirement projection One domain where Monte Carlo simulations are ubiquitous is projections for retirement portfolios. Suppose someone prepares to retire with a total sum of 1 million dollars in their portfolio; they'd like to be able to draw $30,000 a year from the portfolio for their living expenses. Would that work? There's a large number of factors to take into account when analyzing this question, but for simplicity let's focus on just two: portfolio return and inflation. We can run a naive estimate, assuming average values: suppose an average yearly portfolio return of 4%, and average yearly inflation of 2% [4] Let's denote our portfolio return as r=0.04, and inflation as q=0.02. Then the real return each year is: [r^{\mathrm{real}}=\frac{1+r}{1+q}-1\approx0.0196] Starting with $1,000,000, at the end of the year we'll have $1,019,600 and then draw $30,000 for living expenses [5], ending with $989,600. If we continue this way, the money runs out after ~55 years, which means that a person retiring at the age of 65 should be reasonably safe, right? But this is very simplistic; assuming just average returns is risky, because they do a poor job of representing reality, and many factors have uncertainty. For example, the sequence of returns matters a lot; a bad year (-10%) followed by a great year (+18%) would still count as "4% on average" but produces significantly less money than two consecutive +4% years. Inflation is also unpredictable, and sometimes correlated with portfolio returns; there could be bad years of high inflation and low / volatile returns that can wreak havoc on a portfolio. As we add factors (variance in yearly draws, mixed portfolios of stocks, bonds, real estate, life expectancy, unexpected events, changing tax laws etc.), relying on a single average estimate becomes increasingly more fraught. This is why Monte Carlo simulations are very popular in this domain: by drawing from reasonable distributions based on historical data, a Monte Carlo simulation can easily run a million different scenarios and provide estimates: for example, what are the odds of money running out before death. Here's a useful chart from a simulation I ran: In the top chart: The dashed line shows the constant assumptions mentioned before: what happens when yearly return is always 4% and inflation is always 2%. The shaded blue areas demonstrate the outcomes of 1,000,000 simulations where inflation and return numbers are drawn from reasonable normal distributions based on historical data. We see that in 25% of the cases, all money ran out by roughly 22 years. In the bottom chart: It's even easier to see how long the funds last; if we're interested in knowing, say, what are the odds that this plan will have enough money for 30 years - the chart shows it's about 60% (since in 40% of the simulations the funds were depleted at this point). Looking a this simulation, under the current assumptions the plan sounds much riskier than the average assumption makes it appear. Assuming that a 65-y.o. person would plan for 25 years of retirement until death, the ~30% odds of not having sufficient funds for this duration of time are sobering. Perhaps a change in plans is needed (such as a more frugal lifestyle or securing additional funds in some way). Retirement projection is only one of may ways in which Monte Carlo simulations are used for financial and economical applications; given the high uncertainty of these domains, it's very difficult to plan using analytical calculations. Company sales projections, growth projections, stock offering prices and much more uses Monte Carlo simulations to arrive at estimates with reasonable error bars. Code All the code for the explorations in this post is available on GitHub.

[1]While these techniques were conceptually understood much earlier, it's not surprising that their first real applications coincided with the development of the first digital computers. As we'll see later in the post, Monte Carlo simulations benefit from running large numbers of trials to get reasonable accuracy.

[2]The answer is: three empty red diamonds, three solid purple ovals, three striped green squiggles. Note that for each of the 4 SET attributes, these three cards are either all the same or all different.

[3]For the same number of trials, this estimate has greater relative uncertainty than the 12-card estimate, because we encounter far fewer hands without a set.

[4]For the examples in this post, we'll be using real dollars, or today's value of the money. We'll assume that the $30,000 yearly draw doesn't change and will instead apply inflation to the portfolio itself.

[5]More sophisticated simulations would let us control these parameters; for example, are the expense funds drawn at the beginning or end of each year, or distributed on a monthly basis?

This is a cool car. It doesn’t look like anything else and it looks like it’s been pulled a few years from the future. I don’t know about this whole trend where cars don’t have rear windows though. I get it that you just use the camera but my old habits says I want to see out the back sometimes. But the only reason I wouldn’t buy this thing is that turd of a new logo Jaguar went with. I could not abide driving around in something with this typographic calamity.  ★

The incomparable Mark Gurman, reporting for Bloomberg: Apple Inc.’s upcoming push into smart home devices will include a doorbell, thermostat and other accessories developed through an unusual partnership with LG Electronics Inc. The products will be part of an ecosystem of devices that work with Apple’s new smart home hub, as well as an upgraded HomePod mini and fresh TV set-top box, according to people with knowledge of the matter. The new Apple devices are set to be introduced on Oct. 13. The products developed with South Korea’s LG will also include a smart deadbolt lock, indoor security camera, outdoor security camera and floodlight camera, said the people, who asked not to be identified because the undertaking is private. Though the two companies worked together to develop the accessories, the products will carry the LG brand. The South Korean firm is handling manufacturing and product support. Gurman has more than “people familiar with the matter” (or Matter, for that matter) — he cites FCC filings from LG that have product names and illustrations As Gurman himself notes, this is somewhat unusual for Apple, but it’s not altogether new territory either. In Venn diagram terms, the circle for “peripherals Apple very much wants on the market” is a superset of “peripherals Apple wants to make itself and put the Apple brand on”. For some of these products that Apple doesn’t want to make under its own brand, Apple makes them through Beats. But for others they partner with other companies. They’ve long partnered with Logitech for keyboards, keyboard iPad cases, and even the Logitech Crayon, the only third-party alternative to Apple’s own official iPad Pencils. Unlike Apple’s Pencils, the Crayon works without pairing to a specific iPad — surely a godsend in classrooms. There’s also the Logitech Muse — a sky-pencil/magic-wand peripheral for Vision Pro. (Vision Pro is a $4000 mixed reality headset that weighs 2 pounds, which Apple released in early 2024.) Apple does this with Belkin too — that’s another trusted partner for Apple. And, in addition to serving as a longtime display component supplier for Apple, back when Apple had temporarily and foolishly exited the market for Apple-branded external displays, they worked with LG to make the LG 5K Ultrafine display, which for a while was simultaneously the best external Mac display on the market yet also an unreliable flaky product. Even at its best it had an unstable sub-par stand. The thing that makes this partnership awkward for Apple is that these products — doorbells, cameras, deadbolt locks — are products that require the utmost of trust. What products could possibly require more trust than a camera with footage of what’s going on in or at your home, or a lock that controls who can get in? I think that’s why Apple wants to get into this market with products that they can put their stamp of approval on. But LG, of all companies, was just exposed in a scandal for shipping “smart” TVs that literally listen to the ambient audio in the room — even in standby! — and invade your privacy by tracking what content appears on screen. (I own a 2019 LG TV but I haven’t allowed it Wi-Fi access since, literally, 2019.)  ★

Package registries, manifest formats, lockfiles, version ranges and identifiers all have written specifications of some kind, spread across six kinds of venue. Specifications show up in package management mostly as an invisible layer of the dependency tree, where an HTTP library is built against RFC 9110 and a JSON parser against ECMA-404, and the documents covering package management itself are spread just as thinly. I went looking for the IETF’s share, since wire protocols between independently written implementations are what the RFC series exists for, and found nine documents, most of them concerned with firmware updates on IoT devices. The rest is distributed among Ecma, ISO, CNCF and OASIS, the enhancement proposal processes individual ecosystems run for themselves, and for a couple of registries a service’s own API reference. Which venue a document is published in determines whether a second client, a mirror or an archival reconstruction can rely on it, since each of those requires specified behaviour rather than whatever a given server returns this week. Venues Package management specifications are published in six kinds of venue: the IETF, the industry standards bodies, the software foundations, a single ecosystem’s enhancement proposal process, a service operator’s own API documentation, and a third party’s description of observed behaviour. The IETF handles protocols that independently written implementations have to interoperate under, while Ecma, ISO/IEC and OASIS cover formats consumed across industries, which is also what gets them cited in procurement rules and regulation. CNCF, the OCI and the Linux Foundation publish the same kinds of format with a lighter process and faster revisions, while the ecosystem processes, PEPs and Rust RFCs and conda CEPs and Gentoo GLEPs among them, produce documents binding on a single language community. The last two slots are weaker: API documentation describes one running service rather than a contract others can implement against, and a third-party description is written by whoever needed the behaviour recorded when the operator had published none. IETF A title search for “package” across the whole RFC series returns 42 documents, 41 of them about something else entirely: SIP event packages, MGCP media gateway packages, and CMS symmetric and asymmetric key packages. The one exception, RFC 4108 from 2005 on using CMS to protect firmware packages, is the first of the nine. Searching for “software” returns mostly ARPANET-era host notes and SDN terminology. The series covers inventory and attestation instead, nearly all of it produced by the IoT firmware update effort. Concise Software Identification Tags, the CBOR encoding of SWID, is RFC 9393, with RFC 8412 covering Software Inventory Message and Attributes for reporting installed software over PA-TNC. There is a YANG data model for reporting SBOMs and vulnerability information in RFC 9472. The SUIT working group accounts for two more, RFC 9019 giving a firmware update architecture for IoT devices and RFC 9124 the manifest information model that goes with it. SCITT’s architecture for trustworthy and transparent digital supply chains became RFC 9943 in June 2026, the newest of the set and the closest to current SBOM and attestation deployments. The last two are RFC 8240, a report from the 2016 IoT Software Update workshop, and RFC 1805 from 1995, describing a Location-Independent Data/Software Integrity Protocol. The document that would actually specify a package format is draft-ietf-suit-manifest, the CBOR serialization of the manifest described abstractly in RFC 9124. Revision 00 went up in October 2019, the individual draft it was derived from in October 2017, and revision 37 arrived in June 2026 with the usual six month expiry on it. Nearly nine years in, it is the IETF’s one software update wire format, scoped to firmware on constrained devices rather than to registry clients. The series supplies more than that count suggests: every registry protocol here runs over HTTP, and Python’s core metadata began as PEP 241 in 2001, defining PKG-INFO as a single set of RFC 822 headers parseable by the rfc822.py module. The current specification still describes the format as based on email headers, and notes that in the absence of a precise definition the practical standard is whatever email.parser accepts under its compat32 policy. Debian’s deb822 field folding is documented as similar to RFC 5322, enough that control files of a single stanza parse with RFC 5322 parsers. Maven Central requires OpenPGP signatures, the .asc files that appear in its published layout, and OpenPGP is now RFC 9580 from July 2024, which obsoleted RFC 4880 along with the Camellia and ECC extensions. apt verifies Release files against the same format, inline as InRelease or detached as Release.gpg. RubyGems signs with X.509 certificates instead, which its own security guide calls rarely used for want of an established chain of trust. Standards bodies The cross-ecosystem pieces, the ones several language communities and most compliance tooling have to share, are nearly all published at Ecma, whose TC54 was established with OWASP in September 2023. Package URL became ECMA-427 with its first edition published on 10 December 2025, and TC54’s second task group is putting a second edition to the December 2026 General Assembly. CycloneDX was ratified earlier, version 1.6 as ECMA-424 1st edition in June 2024 and 1.7 arriving as the 2nd edition in December 2025. Common Lifecycle Enumeration, which records releases, end of support dates and component transitions, is ECMA-428 as of December 2025. SPDX went to ISO instead and is ISO/IEC 5962:2021, whose text describes SPDX 2.2.1 while the project itself is on 3.x, so a contract or a procurement rule citing ISO/IEC 5962:2021 is naming 2.2.1 regardless of what whoever wrote it had in mind. CycloneDX has shipped a second edition through Ecma over the same period, so Ecma’s published text tracks the implementation more closely than ISO’s does for SPDX. Outside Ecma and ISO, CSAF is an OASIS standard for machine-readable security advisories, and the attestation layer is at CNCF, as TUF, in-toto and Sigstore. The OCI distribution spec is this group’s one registry protocol, implemented by Docker Hub, GHCR, ECR, Harbor, Quay, Zot and Artifactory, and since adopted by Homebrew for bottles and Helm for charts. Ecosystem specs Published registry protocols come out of a single ecosystem’s own process, each in its own client’s vocabulary, which is what sent me looking for a reference model above them in January. Python has the longest paper trail, with the simple repository API now a living specification the PyPA maintains, consolidating nine PEPs: 503 for the original HTML format in 2015, 592 for yanking, 629 for API versioning, 691 for the JSON format, 700 for project versions and file sizes and upload times, 714 for renaming the metadata field, 740 for provenance, 792 for project status markers, and 833, from June 2026, which freezes the HTML representation. PEP 503 established, and every later document preserved, that a directory of files on a static web server is a valid index, so devpi, Artifactory, Nexus, CodeArtifact and an S3 bucket all serve pip. NuGet covers more of the protocol than any of them, documented by Microsoft as a service index listing named resources, four of them required: PackageBaseAddress for package content, RegistrationsBaseUrl for metadata, PackagePublish for pushes and SearchQueryService for search. A separate implementation guide in the same documentation is addressed to anyone building a NuGet repository. Composer documents its repository format the same way, with packages.json, the metadata-url template and the HTTP caching requirements written out, and Satis generates static repositories from it. RubyGems documents its compact index as three endpoints, /versions, /info/ and /names, served as append-only text with ETags and HTTP Range support so a client fetches only what changed since its last request. The format came out of the 2012 RubyGems.org capacity crisis and took four years to ship. Cargo’s sparse index cites it as prior art, quoting Bundler’s path from a full index to a centralized query API to an incrementally downloaded flat file. Cargo’s sparse index came through RFC 2789 in the Rust process, with the motivation stated in the document: a git clone of the full index reported 215MiB against 10MiB for the same content under xz -6, and CI was downloading all of it to use a fraction. Its design constraint was static files behind a CDN using HTTP/2 alone, the same constraint Python’s format has, and the Cargo book documents a registry web API on top of the index format, covering publish, yank, owners and search for alternate registries. Go specified the GOPROXY protocol in the module reference with endpoints written out, /@v/list and /@v/$version.info among them, and ships one client that implements it. Debian’s repository format is documented on the wiki, outside the policy manual, and the page is labelled a work in progress covering the structure of the official repository and the format clients accept, with the goal of becoming a sub-policy eventually. dak, reprepro and aptly produce that format and apt reads it, so the wiki page is treated as normative whatever the label says. Registries npm and Maven Central both publish documentation that omits the part a client installs from. npm’s registry API documentation ships an OpenAPI file for publishing, search, tokens, organisations, access control and trusted publishers, leaving out GET /{package} and tarball downloads, which together are the read path every install runs through. Older endpoint documentation is in npm/registry as an archived collection and in npm/api-documentation, and the fullest public account of the read path is a third-party OpenAPI file assembled from observed behaviour. npm-registry-couchapp was the last publicly readable server and GitHub archived it on 11 August 2021, with a deprecation notice that names the internal micro-services now serving the API. Verdaccio and cnpm implement a compatible API by matching observed behaviour, a weakness in an ecosystem with five clients in npm, yarn, pnpm, bun and Deno. Maven publishes the repository layout and the POM reference, with maven-metadata.xml defined by the Repository Metadata Model, so the storage format is specified. What stays de facto is the resolver’s conflict and ordering behaviour, defined by what ComparableVersion and the resolver in maven-artifact compute. The Gradle team derived those semantics from observed behaviour and then shipped Gradle Module Metadata alongside the POM as its own specification. Sonatype has operated Maven Central since 2008, GitHub operates npm, and each publishes what it chooses to document. ecosyste.ms maintains OpenAPI schemas for more than 25 registry APIs. Two of those registries publish an official schema themselves, crates.io and open-vsx.org, and the rest are generated from the mapping code in packages.ecosyste.ms. Versioning Every ecosystem has its own versioning rules, and version comparison is the least settled part of the whole business. Semantic Versioning 2.0.0 is a self-published document on semver.org by Tom Preston-Werner under CC BY 3.0, and its one IETF reference is RFC 2119, cited for MUST and SHOULD. It specifies version syntax and precedence only, so range syntax comes from each client: node-semver’s README is the operative document for npm, Cargo’s caret default is in the Cargo book, Ruby’s ~> is in the RubyGems documentation, and Python’s are in PEP 440 and PEP 508. Ordering rules split the same way: Debian Policy section 5.6.12 gives the comparison algorithm for epoch, upstream_version and debian_revision in the policy text itself, PEP 440 does the same for Python, and Go’s pseudo-versions and +incompatible suffix are described in the module reference. RPM’s ordering is rpmvercmp inside librpm and Maven’s is ComparableVersion in maven-artifact, with the implementation as the reference in both cases. univers exists because of that spread: one library that reimplements every ecosystem’s comparison rules behind a single interface. The cross-ecosystem attempt is vers, from the purl project, which defines a URI syntax for version ranges together with the semantics for interpreting each notation, so an npm caret range comes out as vers:npm/>=1.0.2|<2.0.0. It was developed alongside purl and is due to be proposed to Ecma later in 2026, which would put ranges in the same venue as identifiers and lifecycle events. Ecma would then hold the identifier, the bill of materials, the lifecycle record and the version range, four of the pieces that have to mean the same thing in every ecosystem, within three years of TC54’s founding, while the protocol layer remains inside the ecosystems and with the registry operators.