sbt 2.0.0 moves build definitions and plugins to Scala 3, requires JDK 17, and replaces the caching layer with a Bazel-compatible local/remote cache that the rewritten compile and test tasks use. The project matrix plugin is now built in and a native-image client cuts startup time. sbt 1.12.12 shipped alongside it for the 1.x line.
pnpm 11.7 adds a frozenStore setting that opens the store’s SQLite index read-only so pnpm install can run against a Nix store, a read-only bind mount or an OCI layer without trying to write WAL sidecar files. The release also adds a --batch flag to publish a whole workspace in one request, per-scope auth tokens, and an option to delegate resolving installs to pacquet.
pnpm 10.34.4 on the v10 line fixes two path-traversal issues. A traversal-shaped configDependencies name or version in pnpm-workspace.yaml could write files outside node_modules/.pnpm-config and the store (GHSA-qrv3-253h-g69c), and a crafted lockfile alias under nodeLinker: hoisted could write outside the install root (GHSA-fr4h-3cph-29xv, also fixed in 11.7.0).
npm 12.0.0-pre.1 is the first pre-release with the v12 defaults switched on: dependency install scripts are blocked unless listed in allowScripts, allow-git and allow-remote default to none, and unknown configs and CLI flags error instead of warn. New in this build are an npm patch subcommand for native dependency patching and a packageExtensions field for repairing dependency manifests from the root.
Yarn 4.17.0 adds package map generation and lets npmMinimalAgeGate be set per npm scope rather than globally.
Dependabot Core 0.382.0 supports a scope property on npm_registry credentials and fixes a leak where npm registry credentials were sent to sibling paths on the same host.
mise 2026.6.11 adds Alpine apk as a bootstrap package manager alongside apt, dnf, pacman and brew, and stops the default Windows .exe shims from leaking into WSL sessions.
Stack 3.11.1 changes the default MSYS2 environment on 64-bit Windows from MINGW64 to CLANG64, following the MSYS2 project’s deprecation of the former.
conda 26.5.3 stops caching a not-found response for sharded repodata, which broke shards-only channels on subsequent runs.
Athens 0.18.0, the Go module proxy, adds Redis cluster-mode support for its singleflight stash.
Go 1.27rc1 drops Bazaar from the version control systems the go command can fetch modules from, and go mod tidy now consolidates duplicate require blocks into one direct and one indirect block for modules at go 1.27 or later.
pipx 1.14.1 restores a package after an interrupted reinstall and fixes inject --force reinstall behaviour.
uv 0.11.22 adds SARIF output to uv audit, a --script flag for uv check and uv metadata, and lets preview features be set in uv.toml and pyproject.toml. 0.11.23 followed a day later reverting two earlier fixes, one of which had broken pre-commit-uv.
Docker Engine 29.6.0 adds a GET /images/{name}/attestations endpoint that returns in-toto attestation statements such as SLSA provenance and SPDX SBOMs attached to an image, with platform selection and predicate-type filtering.
yay v13 shows how long it has been since each PKGBUILD was last modified, so a recently changed AUR package stands out for review, and adds Lua hooks in init.lua for scripting package checks and filtering.
Also out: Homebrew 6.0.2, Helm 4.2.2, Helm 3.21.2, Gradle 9.6.0, snapd 2.76, Harbor 2.15.2-rc1, Renovate 43.233.3.
rv: plan and progress (André Arko) reports a year in on the Rust-based Ruby toolchain. It now installs Rubies, builds with YJIT, manages gems with clean-install and rvx, and runs on Windows. The next step is full dependency resolution, evaluating a Gemfile and writing a lockfile at uv-like speed.
Package managers need global hooks (Nemo) argues every package manager should expose pre-clone and pre-build hooks so users can wire dependency cooldowns and threat-feed scanning into the install path locally, without a proxy registry or a shell wrapper.
Introducing pkgcli (Matthias Klumpp) is a new command-line front end for PackageKit to replace pkcon, with friendlier command names, coloured output and a JSON mode for scripting.
Why stdx is not on crates.io (Sylvain Kerkour) distributes his 64-crate Rust extended standard library by git only, citing the lack of namespaces and the attack surface a central registry adds: publish tokens, source that need not match the repository, typosquatting, dependency confusion. He argues Rust should follow Go’s model of pointing the package manager at the source repository and backing it with a checksum database and an optional caching proxy.
What is npm doing to protect the JavaScript ecosystem, and is it enough? (Mary Branscombe, The Stack) surveys the registry-side changes npm has shipped against supply-chain attacks and what that leaves for developers to do themselves.
curl summer of bliss (Daniel Stenberg) announces that the curl project will not accept or handle vulnerability reports during July 2026, giving the maintainers a month off the disclosure treadmill. libexpat is doing the same through 1 August.
The Vulnerability Report Is Dead. Long Live the Prompt! (Mikaël Barbero) argues an AI-assisted vulnerability report should lead with the prompt, model version, commit hash, tool access and verification status, and treat the generated write-up as supporting material.
Composer & Packagist Supply Chain Security in 2026 (Nils Adermann) are the slides from the PHPVerse talk covering the same series of changes the Packagist blog has been writing up over the last few weeks.
Homebrew tightens tap security, begins work on its interface (Help Net Security) interviews Mike McQuaid about the 6.0.0 release and the tap trust mechanism.
Thoughts on governance (Dawn Foster) gathers her recent talks on open source project governance and where it meets public-sector governance.
Open source is a gig (Cristovao Verstraeten, LinkedIn) compares maintaining open source to a touring musician’s life, mostly paid in exposure rather than money.
Software Dark Matter: Gazing at Uncharted Files to Navigate SBOM Integrations (Reddypalle et al., arXiv) names the gap between what an SBOM lists from package manager metadata and the security-relevant files that actually ship in an artifact but never appear in a manifest.
The ClickPy May 2026 report puts PyPI at 163.8 billion downloads for the month, up about 20% since March.
actions/checkout v7 now refuses by default to check out fork pull request code in pull_request_target workflows, blocking a common path to running untrusted code with write tokens in CI.
GitHub repositories can now cap the number of open pull requests a user without write access may have at once, aimed at drive-by contribution volume.
Weston Steimel has opened a discussion on improving the data quality of the PyPA advisory database and is asking for ideas.
gem-guardian is a RubyGems checksum verifier that has grown lockfile-checksum support, provenance reporting and publisher-provided checksum verification for private registries.
Following last week’s AUR takeover, Morten Linderud points out that anyone maintaining ten or more AUR packages they depend on should consider becoming an official Arch package maintainer instead.
Send links for next week to @andrewnez@mastodon.social.
]]>Then you run npm install and a few hundred of these impossible goods arrive in seconds, and the commercial software industry sits almost entirely on top of them. Open source breaks more or less the full set of market axioms at once.
The free rider problem. A public good is non-rival (my use doesn’t reduce yours) and non-excludable (you can’t keep me out), and standard theory holds that such goods will be underproduced because every rational actor waits for someone else to pay. The canonical case is the lighthouse, where everyone benefits and nobody volunteers, so government has to build it. An open source library meets the definition exactly, being perfectly non-rival and non-excludable by licence, so the theory predicts a small number of them, grudgingly produced and propped up by grants. npm alone hosts over five million, almost none grant-funded, with thousands more turning up every day.
You get what you pay for. Price is supposed to signal quality and scarcity, giving a market a way to sort good from bad. SQLite, by its own count the most widely deployed database engine in the world, costs the same as a week-old typosquat with a crypto miner in the postinstall hook. The most valuable libraries in existence and the most dangerous ones sit at the same number, and consumers route around the missing signal with reputation, download counts, and GitHub stars.
The tragedy of the commons. A shared resource gets depleted because each user’s rational move is to take without giving back, so the prediction for a software commons would be a small pool of overused, under-maintained code that decays as consumption outruns contribution. Some corners of the public registries do look like that, but the aggregate has grown every year since registries have existed.
Rational self-interest. Economic agents maximise their own utility, and utility can be defined broadly enough to cover enjoyment, status, and ideology as well as money. Even on the broad definition it is a stretch that so many people’s preferences include answering bug reports from strangers at eleven at night, after a full day at an unrelated job, prompted by an issue from a Fortune 500 company titled “URGENT!!”, for a project that pays them nothing. There are enough people whose preferences apparently work that way to keep most of the modern software stack running.
Supply and demand. Rising demand is supposed to raise the price and draw in new suppliers until the market clears, but when a library goes from a thousand downloads a week to ten million the price stays at zero and the maintainer count typically stays at one, because demand has no channel through which to act on supply. More users turn up, the issue tracker fills, security researchers start filing CVEs against it, and it stays one person’s job.
Division of labour. Critical infrastructure is supposed to be built by specialists, employed full-time, organised into firms that carry liability for failure. Across the public registries ecosyste.ms tracks, more than half of packages have a single maintainer, and that one person frequently has a day job in a different field, no employment relationship with any downstream user, and no contractual liability to anyone. The bus factor for long stretches of the dependency graph works out to a single hobbyist.
Firms guard competitive advantage. A company is not supposed to pay engineers to build something and then hand it to the people competing for its customers, yet Google, Meta, Microsoft, and Amazon all fund open source libraries the other three run in production. The standard explanation is commoditising your complement: give away the layer adjacent to where you make money so nobody can charge you rent there. That accounts for React and gRPC well enough and is the one entry here with a clean market explanation. The explanation does not extend to the much larger tier underneath, the libraries with one maintainer and no adjacent business model, which is most of what npm install pulls in.
Economists have noticed all this, and there is a small literature trying to account for it. Lerner and Tirole put it down to career signalling, contributing in public to build a reputation you cash in elsewhere. That holds when someone is watching, and not for the maintainer of an obscure dependency no hiring manager will ever look up. Benkler argued that the internet made coordination cheap enough to organise production without a firm. That explains how the work gets divided, not why anyone takes on the unglamorous half of it. Von Hippel framed it as user innovation, people building what they need and sharing it afterwards for next to nothing. It fits until the maintainer is still answering bug reports years after they stopped using the thing themselves. All three fit some maintainers some of the time, and none on its own accounts for the shape the system has taken or why it has held together this long.
Calling all of the above a list of market failures implies a working market underneath that would behave properly once the failures were corrected, and there isn’t one: open source has run for thirty years on a basis the textbook says cannot hold. It looks more like several arrangements overlaid on each other, part gift economy, part shared infrastructure, part public archive, part reputation system, with no single mechanism carrying it.
The practical fixes that keep being proposed treat it as a market anyway and bolt the missing pieces on, which is where bug bounties, sponsorship marketplaces, dependents-weighted funding formulas, criticality scores, and tokenised reward schemes all come from. Every one of them is an attempt to reconstruct a price for something that has never had one, and to do that they need a number to stand in for value.
The numbers available for that job are weak proxies, two or three steps removed from what anyone wants to know: who is keeping this running, how close they are to stopping, and whether a security report filed against it would reach anyone at all.
]]>Chosen successor. The maintainer picks a person and hands over the keys. This is the model everyone imagines when they say succession, and it has almost no supporting infrastructure: it’s a private conversation followed by some permission changes. The vetting is whatever the departing maintainer feels like doing, which is how event-stream happened: “he emailed me and said he wanted to maintain the module, so I gave it to him.” The xz takeover was the same mechanism worked patiently, with sock-puppet users manufacturing the pressure on an overworked maintainer to hand over.
CPAN is the one registry that gives this stage a name: a module whose permissions list the pseudo-user HANDOFF has a maintainer looking for someone to take over, recorded in the same machine-readable permissions file as every real owner.
The successor setting. GitHub has had account successors since 2020: you name a person in your account settings, and after presenting a death certificate and waiting seven days, or an obituary and waiting twenty-one, they can archive your public repositories or transfer them to an account they control. It is the only entry on this list built for the case where the maintainer dies. It covers the repos but not the registry accounts that publish from them, and no registry has an equivalent.
Open adoption. Instead of picking someone, the maintainer flags the project as available and waits. CPAN again has the oldest version: the ADOPTME pseudo-user as owner means the module is up for adoption, and NEEDHELP means the owner wants co-maintainers without leaving. RubyGems proposed an equivalent in October 2014, designed so that “the happiest of happy paths is to enable communication dev-to-dev, requiring no external involvement”, and shipped it as ownership calls and requests at the end of 2021. Debian’s RFA, Request For Adoption, does the same job for packages: the maintainer keeps working until a successor appears. Outside the registries the equivalent is a repostatus badge or a “looking for maintainers” line in the README, and no tooling reads either one.
Deliberate ending. The maintainer can also decline to be succeeded, and the registries support that decision better than any of the handovers above. Packagist’s abandoned field takes a replacement package name, and composer prints “Package X is abandoned, you should avoid using it. Use Y instead.” on every install. NuGet deprecation carries an alternate package, and a fully deprecated legacy package can apply to transfer its search ranking to a successor that shares its owners. Maven has the relocation element for coordinates that moved.
PyPI added project archival in 2025 and now serves status markers through its APIs. GitHub archiving makes the repo read-only with a banner. Pointing at a successor package moves the users to different code rather than moving the code to a different maintainer.
Registry adjudication. A third party hears a claim on an unmaintained name and rules on it. PyPI runs the most formal version: PEP 541 defines abandonment by three conjunctive criteria (unreachable owner, no release in twelve months, no owner activity). The claimant has to show failed contact attempts and improvements on their own fork, and explain why a renamed fork won’t do. It handled over 500 requests in 2025 and cleared what had been a nine-month backlog. PAUSE admins will grant co-maintainership on a CPAN module when the owner “has entirely disappeared”, with the condition that the adopter is “required to respect the work and design of the author”. Hackage admins add you to a package’s maintainer group after you’ve tried the maintainer and stated your intent publicly.
npm ran a four-week mediation process and suspended it in February 2021 after a mis-transfer; the current policy is “we do not transfer package, organization, or username ownership simply because another user wants the name”. crates.io removed its transfer mediation policy in 2024, on the grounds that requests grow with the registry and “aren’t even usually successful”, citing a PyPI team “not able to keep up with the requests”.
The orphan pool. The Linux distributions treat an unmaintained package as a vacancy to fill, and built state machines for filling it. Debian encodes the whole lifecycle as WNPP bugs: O for orphaned, RFA for adoption requested, RFH for help wanted, ITA for intent to adopt, and ITS for intent to salvage a package whose maintainer is present but inactive. Orphaning sets the package’s Maintainer field to the Debian QA Group, and an MIA team chases unresponsive maintainers through a staged escalation that ends in orphaning everything they hold.
Fedora reassigns orphaned packages to a literal orphan user that any packager can take over from with a button. After six weeks unclaimed the package is retired by committing a file named dead.package to its repo. The AUR grants orphan requests after two weeks of maintainer silence, automatically if the package has been flagged out-of-date for 180 days. CRAN marks the maintainer field itself ORPHANED and lets anyone take over without the previous maintainer’s consent. None of the language registries has anything like this: a distro package is communal property with a caretaker of record, while a registry name belongs to whoever published first.
In June 2026 an attacker adopted over four hundred orphaned AUR packages and added an npm install line to every PKGBUILD. The fetched npm package’s preinstall hook installed a credential stealer and eBPF rootkit. The first report was a user noticing npm install in a VR streaming tool’s PKGBUILD. Each time the payload package was taken down and the install line grepped for, the next batch of adoptions switched: npm install became bun add on a fresh package, then 'b''u''n' 'a'"d""d". Arch restricted account creation and package adoption while the incident ran.
The monorepo. Homebrew, nixpkgs, and conda-forge keep every package definition in one shared repository, so there are no keys to hand over and a succession is a pull request, which is as close as this list gets to anyone deciding with a reviewer in the loop. homebrew/core records no per-formula maintainer at all; maintainership amounts to whoever the tap accepts changes from. nixpkgs lists package maintainers as entries in one file, and adopting an orphaned package means adding your name to it, which is the distro’s caretaker-of-record model without the orphaning process.
Foundation custody. Projects can move into an organisation built to outlive any individual maintainer. Apache projects are run by PMCs rather than people, so succession is a membership change inside a structure that persists, and when a community dissolves the project moves to the Attic, a read-only terminal state with its own documented process. The OpenJS Foundation runs a progression and emeritus lifecycle for hosted projects. The foundation takes on the bus factor in exchange for governance overhead, and most packages on any registry are far too small to ever make that trade.
Corporate custody. When a company holds the project, succession is an org chart event: from inside it’s the chosen-successor mechanism with an employer attached, and from outside it isn’t visible at all. When antirez stepped down from Redis in 2020 he chose two successors and refused to design the governance that followed. He and both successors were Redis Labs employees, and the company held the trademark. The community’s succession came in 2024, when the relicense pushed Madelyn Olson and most of the external core team into forking Valkey under the Linux Foundation. That arrangement holds until the team is cut and the project becomes the corporate orphan from the previous post.
The fork. Every mechanism above falls back to this one: PEP 541 requires a working fork before PyPI will consider a transfer, and crates.io’s advice for an unreachable owner is to pick a new name. A fork copies the code, and the original keeps the registry name, which means it also keeps the install count and every manifest and lockfile that references it. The fork limbo and licence rug-pull cases from the death list both happened this way, with development moving to a new repo and the installs still resolving to the old one.
The forwarding-address problem has one solution, at the forge layer: GitHub repository transfers redirect the old URL to the new one indefinitely, although creating a new repository at the old name deletes the redirect permanently, an attack surface of its own. Go modules inherit both properties because a module path contains the repo that hosts it: there are no registry accounts to transfer, and a fork lives at a new path with a Deprecated comment in go.mod as the forwarding address. A transferred repo keeps resolving through the redirect, and Swift packages, declared as Git URLs in the manifest, behave the same way without an equivalent of the Deprecated comment to forward a fork.
The stranger. Avelino et al. studied 1,932 popular GitHub projects and found 16% had been abandoned by all of their core developers; 41% of those survived, and 86% of the survivors were rescued by a single new core developer. The most common motivation was “because I was using the project”, and the barriers the rescuers reported were not technical: lack of time, and not being able to get push access because the people who could grant it were gone.
The rescue the study describes is informal: someone who needs the package asks whoever still has access, and the handover is an email and some permission changes that nothing flags or records. That is also how event-stream changed hands, and the maintainer granting access has no way to tell the rescuer from the attacker. Where the orphan pool has already removed that maintainer, as with the four hundred AUR packages above, there is nobody in a position to tell.
]]>GitHub announced the breaking changes coming in npm v12, estimated for July. npm install will stop running dependency lifecycle scripts unless they’re allowed via the allowScripts field that 11.16.0 introduced in advisory mode, covered in the install-script allowlists post I wrote last week. Implicit node-gyp builds are blocked too, so a package with a binding.gyp and no install script needs approval like any other. Git dependencies and remote URL tarballs also stop resolving by default, each behind a new --allow-git / --allow-remote flag. Everything ships behind warnings in npm 11.16.0+ today.
uv audit is a new preview command that scans Python dependencies for known vulnerabilities and adverse project statuses like deprecation, a uv-native alternative to pip-audit. The same announcement covers an experimental malware check: uv add and uv sync can look up previously-resolved packages against OSV on every sync, behind UV_MALWARE_CHECK=1.
pnpm 11.5.3, backported to 10.34.2, hardens the packageManager bootstrap path. The registry and proxy settings used to download a requested pnpm version now come only from trusted config sources, not the repository’s own .npmrc, and the downloaded binary’s npm registry signature is verified before it runs, failing closed. Repository-controlled config can no longer expand environment variables into registry URLs or credential values, and Node.js downloads get their SHASUMS256.txt checked against the release team’s PGP keys instead of trusting the configured mirror to vouch for itself. A follow-up post walks through the malicious-repository scenario the env-variable change blocks.
Composer plugin allowlists are now available at the organization level for Private Packagist customers, the next post in Packagist’s supply-chain security series. Composer plugins run code during install and update, and the existing per-developer trust prompt is easy to clear without thinking, or to clear from a coding agent on autopilot.
The Arch User Repository package alvr was orphaned and immediately adopted by a threat actor who pushed an update carrying an infostealer payload. The aur-general thread tracks the takeover and the orphan-adoption mechanic that enabled it.
Podman 5.8.3 fixes CVE-2026-44517, where a Dockerfile ADD or COPY pulling from a malicious git repository or tar archive could write files outside the build context.
Ruby Central announced a Security Engineers in Residence programme, funded by an Alpha-Omega grant, to find and verify vulnerabilities in widely-used gems before reporting them to maintainers, following the model the Python, Rust and PHP foundations already run. I’m advising the team on package ecosystem security. The first engagement turned up a ReDoS in Nokogiri’s CSS query tokenizer, verified and fixed before disclosure.
RubyGems and Bundler 4.0.14 follow up on last week’s Cooldown feature: Bundler now preserves per-source cooldown settings when converging sources from the lockfile and stops excluding the locked version from cooldown during bundle update. On the RubyGems side, the gem installer validates executables and bindir, and C1 control characters are stripped from displayed gem text.
gem.coop namespaces moved from beta to general availability, so a Gemfile can point at a per-publisher source like https://gem.coop/@kaspth. Cooldown support was added to every namespace via a /cooldown suffix, though that part stays on the beta domain while bugs get fixed.
npm 11.17.0 adds a min-release-age-exclude config to exempt named packages from the release-age gate. The allowScripts policy now applies across prune, dedupe, uninstall, audit and link, and a prototype-pollution path in the config Queryable setter is closed.
Dependabot Core 0.381.0 adds Bundler 4 support and disables the npm minimal-age gate for Yarn Berry security updates, the same cooldown-bypass-for-security-fixes pattern it applied to pnpm last week. Go module updates now respect GONOPROXY and GONOSUMDB.
mise 2026.6.3 adds excludes to its minimum release age setting so a cooldown policy can carve out specific tools, plus an opt-in auto_env that activates platform-aware config and lockfiles by detected OS and architecture. 2026.6.5 closes trust-bypass paths where an untrusted project’s mise.toml or mise-tasks/ directory could run code before the user approved it, and makes credential_command global-only so a checked-out repo can’t run arbitrary shell through it.
Flatpak 1.18.0 exposes AMD’s compute interface (/dev/kfd) through the DRI device permission, prints failure causes in flatpak update output, and speeds up fish shell integration at startup.
Homebrew 6.0.0 adds a tap trust mechanism that requires explicit approval before a third-party tap’s Ruby runs on the machine. The release also ships a smaller default internal JSON API, sandboxing on Linux, and parallel formula installs from brew bundle. Three security advisories are addressed in the same release: an HTTPS-to-HTTP redirect bypass in the POST download strategy, root code execution via Git hooks in a macOS pkg postinstall, and the macOS installer trusting user-controlled plist files. brew bundle also adds npm, krew and winget support and now prompts before removing packages on cleanup. A PR I sent adds a patches key to brew info --json and the formulae.brew.sh API, so SBOM generators and vulnerability tools can see which patches each formula applies on top of upstream.
Deno 2.8.3 accepts --env-file in the dependency and registry subcommands, and suggests DENO_TLS_CA_STORE when a fetch hits an untrusted certificate.
Also out: pixi 0.70.2, Mamba 2.8.1, uv 0.11.21, Chocolatey 2.7.3, sbt 2.0.0-RC16, Gradle 9.6.0-RC2, Conan 2.29.1, Helm 4.2.1, Helm 3.21.1, pnpm 11.6.0, Homebrew 6.0.1, Windows Package Manager 1.29.250, Docker Engine 29.6.0-rc.1, Podman 6.0.0-RC1, Verdaccio 7.0.0-next-7.21, Renovate 43.220.0.
What We’re No Longer Seeing: AI and the Invisible Newcomer in Open Source (Mara Averick, stdlib blog) argues that the friction of a newcomer’s first clumsy issue or pull request is how communities spot and welcome new contributors, and that AI assistance now smooths that friction away before anyone sees it.
We have to change the rules of security (Josh Bressers) makes the case for deliberately choosing what security work to stop doing, rather than letting tasks fall through the cracks at random.
A Strategic Approach to Demonstrating the Value of OSS Efforts (Dawn Foster) collects a year of her writing and talks on showing leadership the value of open source work in one place.
The Guix Nix Abomination: Leveraging Guix derivations in Nix (Farid Zakaria) registers a Guix derivation in a Nix store and has Nix build it, showing the two tools share the same derivation machinery underneath the rivalry.
Nix flakes vs Guix works through why there’s no single Guix equivalent of a flake: flakes bundle several concerns into one feature, where Guix covers the same ground with separate composable tools. Update 15 June: the author has since taken this post down.
Are insecure code completions a vulnerability? (Seth Larson) catches PyCharm’s line completion suggesting CERT_NONE and warning-suppression boilerplate, and argues a CVE is the wrong mechanism for systematically insecure suggestions, though vendors should still fix them at the source.
Helm v3 end-of-life sets 9 September 2026 as the final feature release, limited to Kubernetes client library updates, and February 2027 as the cutoff for security patches. Existing Helm 3 releases can be managed by Helm 4 without chart rewrites.
Reuse Less Software (Simon Heath) argues for vendoring every dependency into your own repository as a supply-chain firebreak, on the principle that the auto-fetch step is what lets a poisoned release propagate at CI speed and that giving up transitive dedup is a price worth paying for the break.
When LLMs Invent Rust Crates: An Empirical Study of Hallucination Patterns and Mitigation (Zheng et al., arXiv) is the first large-scale study of crate hallucination in LLM-generated Rust code, building its dataset from Stack Overflow and GitHub tasks rather than the Python and JavaScript ecosystems earlier package-hallucination work measured.
Skilldex: A Package Manager and Registry for Agent Skill Packages with Hierarchical Scope-Based Distribution (Saha et al., arXiv) proposes a package manager and registry design for distributing agent skills with scoped namespaces.
Inside PyPI: Maria Ashna on Supporting Python’s Package Index is a Behind the Commit interview about the day-to-day work of running PyPI.
Fixing Fedora’s Packaging Pipeline is a Fedora Podcast episode with Jakub Kadlčík of the Copr build service on RPM packaging tooling.
The impact of AI on open source software development is a panel Mike McQuaid put together with five open source practitioners on what AI assistance changes for the communities and projects underneath the tooling.
Sustain episode 289 has Courtney Miller on software abandonment, maintainer burnout, and what AI tooling changes for project sustainability.
Two versioning schemes: PaceVer versions user-facing apps as MARKETING.NATIVE.OTA, bumping by which channel a release ships through, the slow store-reviewed binary or the fast over-the-air update. Kelvin versioning (Devine Lu Linvega) counts versions down in Kelvin towards absolute zero, where the software is frozen and no further releases are possible.
I tagged proxy v0.5.0.
Send links for next week to @andrewnez@mastodon.social.
]]>Contact: naming@vna.example
Subject: Vulnerability Naming Authority Announces Naming Process and Domain Allocation
Embargo: None
The Vulnerability Naming Authority (VNA), in coordination with the CVE Numbering Authority consortium and the National Telecommunications and Information Administration, has published a unified process for the assignment, registration, and disclosure of named vulnerabilities. The process introduces a controlled vocabulary, a centralised approvals registry, and a top-level domain, .vuln, allocated for use exclusively in disclosure communications.
The process applies to any vulnerability disclosed publicly by an entity operating within the United States. Vulnerabilities assigned only a CVE identifier remain out of scope.
A named vulnerability is defined as a vulnerability that the discoverer intends to refer to by name in disclosure materials, including but not limited to: the discoverer’s blog, the discoverer’s employer’s blog, the discoverer’s employer’s marketing department’s blog, a conference programme, a podcast episode title, and any subsequent press coverage.
Each named vulnerability is described by a structured record. The record contains a primary monosyllable, an optional Latinate suffix, a single SVG logo, a designated colour from a reserved palette, and a one-line description suitable for a slide.
Names are checked against a deconfliction database before assignment. The database is seeded with the prior canon: Heartbleed, Shellshock, Spectre, Meltdown, BlueKeep, POODLE, DROWN, KRACK, Dirty COW, Log4Shell, ProxyLogon, ProxyShell, PrintNightmare, ZeroLogon, Follina, Spring4Shell, Text4Shell, Looney Tunables, regreSSHion, LeakyVessels, Terrapin, LogoFAIL, PixieFAIL, NameDrop, TunnelVision, GoFetch, BootHole, SeriousSAM, HiveNightmare, Sinkclose, Retbleed, Zenbleed, Downfall, Reptar, Inception, and AmberWolf. New entries are imported nightly from the vulnerability.garden feed, which grows at approximately one entry per day.
A name that collides with an existing record receives a numeric suffix. A name that collides with a registered trademark receives a different name. A name that collides with a pharmaceutical product is referred for adjudication.
The .vuln top-level domain has been delegated to the Authority by IANA following a public comment period in which two comments were received, one of which was from the authors of the prior draft.
Under the relevant executive order, any entity headquartered in the United States disclosing a previously-unpublished CVE through a public blog post in the English language is required to register the corresponding .vuln domain within 72 hours of disclosure. The domain must resolve to a single-page site containing the CVE record, the CVSS vector, the approved logo, an FAQ, and downloadable press materials. The site must not contain advertising, with the exception of a single recruitment banner of no more than 200x100 pixels.
The disclosure_url field of the CVE record is validated against the registry. Records pointing outside .vuln are flagged in the public feed and marked non-conforming. Validation runs on a 72-hour SLA, which exceeds the SLA on the CVE record itself.
Civil penalties for non-conforming disclosure begin at five thousand dollars per day. The schedule includes exemptions for entities with annual gross revenue below a threshold to be determined, for federally funded research institutions, and for one named trade association added to the schedule during rulemaking at its own request.
Disputes over .vuln ownership are resolved under the Uniform Vulnerability Naming Dispute Resolution Policy (UVNDRP). Domains abandoned by the original discoverer enter a redemption period during which vendors, journalists, security consultancies, and conference organisers may submit competing claims.
Existing named vulnerabilities have been migrated. heartbleed.vuln redirects to the Codenomicon foundation site. log4shell.vuln is held by the Apache Software Foundation. shellshock.vuln is in the possession of a domain investor in Wyoming who has declined to respond to acquisition inquiries.
Applications are submitted through the VNA portal. Each application requires a draft name, a proposed logo in vector format, a colour preference, a CVSS vector, a brief technical description, and a non-refundable processing fee. The fee is waived for academic disclosures, federal agencies, and applicants who can demonstrate that their previous submission was rejected for tonal inconsistency.
The application progresses through five stages: pre-disclosure review, discoverer review, vendor review, brand review, and the Final Naming Committee. The Final Naming Committee meets once a fortnight in Reston, Virginia. Quorum is four members, of which the committee currently seats three.
Names are evaluated against the following criteria:
Where two or more discoverers submit applications for the same underlying CVE within a single review window, priority is determined by the order in which complete applications were received. Applications missing a logo or a colour preference are returned for revision; the discoverer may file a priority objection, heard at the next meeting of the Final Naming Committee that achieves quorum.
If two applications are subsequently merged into a single CVE, the senior name is retained and the junior discoverer is credited as a co-discoverer in the FAQ section of the disclosure site, in alphabetical order, in a font size of not less than 60% of the senior discoverer’s.
A vendor publishing a counter-name for a vulnerability already approved by the Authority must log it in the registry as an unofficial alias and may not register it as a .vuln subdomain. Conflicting registrations are referred to the Naming Disputes Subcommittee, whose decisions may be appealed to the Naming Disputes Appeals Subcommittee. The Appeals Subcommittee has not yet been constituted.
Where the scoop on a vulnerability is contested between the discoverer and a journalist present at an earlier conference talk, the journalist is not eligible to file.
Vulnerabilities affecting model serving infrastructure, retrieval pipelines, MCP servers, agent frameworks, and any component the discoverer can plausibly describe as “AI-adjacent” are filed under a separate carve-out. The carve-out was established in response to submission volume: AI-related disclosures currently arrive at a rate of approximately fourteen per business day, exceeding the Final Naming Committee’s review capacity by an order of magnitude. OpenClaw and the ClawHub package registry account for the majority of weekly submissions. Volume has continued to increase notwithstanding repeated requests from the Authority that the AI community consolidate disclosures.
Applications under the carve-out are routed to the AI Vulnerability Review Board, an instance of Anthropic’s Vulnaire model fine-tuned on the deconfliction database and the prior canon. Vulnaire scores each submission against the published criteria, drafts a recommended name, and either approves, defers, or returns it for revision. Decisions are published to the registry within four hours of submission. The auto-approval threshold was tuned downward after the first week of operation, during which Vulnaire approved every submission, including one that named itself, one that named the Authority, and one that named the Final Naming Committee. Subsequent retraining has reduced but not eliminated this behaviour.
Names approved by Vulnaire receive an “AI-reviewed” badge in the registry, in the same colour as the Authority’s wordmark. Several vendors have petitioned to have the badge removed; the Authority has declined. The Final Naming Committee reviews a five per cent sample of AI-approved names each fortnight. No sampled name has been overturned to date, though four have been marked for follow-up at the discretion of the reviewer. Follow-up is logged but not enforced.
The following names were approved at the May session, in order of disclosure: GoblinTap, EchoLeak2, GhostTunnel, VulpineShade, RustBleed, KarenRegex, ShadowFetch, TuesdayShell, YubiBait, UntitledFolder3, and ConcernedDog.
ConcernedDog2, filed twelve days later by a competing vendor against an unrelated CVE, has been deferred to the brand review subcommittee. Cassandra was filed twice in the same week; the second filing was approved as Cassandra2 following an objection from the first discoverer’s employer.
The first evergreen name, Heartbleed (2027), has been leased to a managed detection vendor for an undisclosed fee. Heartbleed (2014) is grandfathered. Subsequent year-suffixed instances will enter the rotation as their predecessors expire.
Two applications were rejected at brand review for tonal inconsistency with the severity vector, including AbundanceOfCaution, noted as insufficiently severe in either direction. One application was referred for pharmaceutical adjudication. The outcome is not public. GoatFarm was withdrawn at the discoverer’s request following a change of professional circumstances.
Planned namespaces include vendor, foundation, government (with a sub-namespace per attributing agency), and academic (in which submitted names must include at least one citation). A delegation protocol is being drafted to allow accredited research labs to operate subordinate naming authorities under, for example, project-zero.vuln.
A retrospective conformance pass is in preparation. Vulnerabilities disclosed before the establishment of the Authority will be required to refile under the present process. Grandfathered evergreen names will be unreserved and re-released to the auction pool. The Authority is consulting on a transitional grandfathering scheme for the existing grandfathering scheme.
A working group, chartered to define the conflict resolution process between the namespace layer and a planned trademark layer above it, meets concurrently with the Final Naming Committee and has not yet established a quorum. A second working group, on the historical etymology of vulnerability naming, will produce a report drawing on telecommunications, virology, and cryptozoology, due in eighteen months. Its terms of reference are under review by itself.
The Vulnerability Naming Authority is a 501(c)(6) trade association incorporated in Delaware. Its mission is to standardise the assignment, registration, and disclosure of named vulnerabilities. The Authority does not investigate vulnerabilities, assign CVE identifiers, coordinate disclosure, validate technical claims, or provide remediation guidance.
]]>Their own blog post from June 8th, titled The Work Continues, concedes “the right response is not to pretend the launch went the way we wanted. It did not.” I’ve been pulling the public data: GitHub commit history, on-chain trading records, and the long paper trail tea left across the package registries.
tea was founded by Max Howell, the creator of Homebrew, with Timothy Lewis. It came out of stealth in March 2022 with $8M led by Binance Labs, followed by an $8.9M seed round in December 2022. The pitch had two halves: a new package manager (the tea CLI), and a blockchain protocol that would reward the maintainers of open source packages with tokens. Howell wrote Homebrew and made nothing from it, and the pitch leaned on that history, famous Google interview rejection included.
The two halves split in October 2023, when the package manager was renamed pkgx and moved to its own GitHub org (the old teaxyz/cli repo still redirects there) while the teaxyz org kept the crypto protocol. pkgx is a decent piece of software, and it never had a token in it. But the separation was only organisational: the company and founders stayed the same, and pkgx remained part of tea’s pitch as the eventual “cryptographically aware package register” for the protocol.
The white paper describes a mechanism called Proof of Contribution. Every package gets a score called teaRank, computed over the dependency graph and explicitly modelled on Google’s PageRank. The more packages depend on yours, the higher your rank, and rewards scale with rank. To claim a package you add a tea.yaml file to its repository containing your wallet address.
The protocol paid out tokens in proportion to how many packages you controlled and how connected they were. Registering a thousand packages paid better than one, and declaring dependencies between them pushed their ranks higher still. Nothing in the design was costly to fake, since a package name costs nothing to register and a dependency is one line in a manifest. In February 2024 tea opened an incentivized testnet, a trial version of the protocol where points earned would convert to tokens at launch, and reported nearly 200,000 signups and 500 projects in the first week.
The farming started immediately, with pull requests on GitHub adding tea.yaml files to other people’s projects, trying to claim repos the submitter didn’t own. Howell called the PRs “disgusting and counter productive”. On the registries, Phylum documented new npm package publications climbing from mid-February 2024 to over seven times normal daily volume, with around 14,000 tea-registered packages across npm, PyPI, RubyGems, and crates.io. Sonatype counted roughly 15,000 on npm alone, with single accounts publishing hundreds of packages.
RubyGems published an incident report describing empty gems created to farm rewards, including one six-year-old gem with over 100,000 downloads whose owner retroactively added a tea.yaml to cash in on it. In response they tightened publishing limits and blocked the accounts responsible. By August 2024, DEVCLASS reported research estimating that of roughly 890,000 packages published to npm in the prior six months, around 70% were tea farming spam.
In November 2025, Endor Labs analysed the “IndonesianFoods” campaign: 43,000+ packages from at least 11 npm accounts over nearly two years, with auto-generated names from word lists. Amazon Inspector tied over 150,000 packages to the same token-farming campaign. Some coverage called it a worm, though Socket’s analysis found automation rather than self-propagation. The spam packages declared dependencies on each other to inflate teaRank, which meant installing any one of them pulled in the whole tree. An academic paper published in 2025 measures the abuse. The cleanup costs landed on npm, RubyGems, PyPI, and every mirror and security scanner downstream.
tea responded that November by halting rewards distribution for the affected period and promising redesigned anti-spam rules. Howell told The Register the protocol would slash farmers’ rewards.
In September 2025, eight months before the protocol went live, tea ran a public sale on CoinList, a site that runs token sales for crypto projects: 4 billion TEA at $0.0005 each, implying a $50M valuation for the full 100 billion token supply. The terms unlocked 100% of the tokens on day one. Token sales usually stagger when buyers can sell, releasing tokens over months or years so early buyers can’t all exit at once.
The launch plan, announced May 12th, put trading on Aerodrome, an exchange that runs as a program on Base, a blockchain built by Coinbase, rather than as a company matching orders. Prices on this kind of exchange come from a pool of paired tokens, TEA on one side and a dollar-pegged token on the other, and each trade moves the price along a curve. The smaller the pool, the more each trade moves it. tea seeded the pool with 2% of the token supply and scheduled the launch for 00:00 UTC on June 4th.
The pool received its tokens from 22:47 UTC on June 3rd, and the first trade executed at 23:54 UTC, six minutes before the official launch. tea’s June 8th post describes this as “onchain liquidity activity occurred ahead of the coordinated plan”: the pool was live and tradeable before the launch sequence finished. In those six minutes the price was bid up to $0.00065, above the CoinList sale price. In the first official hour, from 00:00 to 01:00 UTC, the price fell from $0.00046 to $0.00011 on $332,000 of volume, down 75% in 60 minutes.
The CoinList sale’s full unlock meant every September buyer was free to sell from the first minute, into a pool holding 2% of supply. The price has kept falling since and now sits around $0.00007, 86% below what CoinList buyers paid eight months ago, valuing the entire 100 billion token supply at roughly $7M against the $50M the sale implied.
The collapse didn’t need anyone to withdraw the tokens backing the pool, and the pool still holds around $280K. Per the project’s own pre-launch transparency filing, about 20% of supply was circulating at launch, ten times what the pool held.
Monthly commits across the teaxyz org and the pkgxdev org show how much of the company was still working by launch day:
Commits to the protocol org ramped through late 2024 as the team built chai, their open package dataset, and the token contracts, and even the December 2024 peak was only 100 commits. Activity declined through 2025: chai’s main developer stopped committing in August, the dataset repo’s last commit was in September, and the token contract repo’s last sustained work was in October and November. After November 2025, the month tea halted rewards over the farming campaign, the org had 2 commits in December, 1 in January, 2 in February, and none since.
The chart excludes forks, which hides the one place engineering continued: tea’s forks of go-ethereum and Optimism, the infrastructure for their blockchain, received steady commits from a single contributor through May 17th, 2026, two and a half weeks before launch.
Howell wrote 236 commits to pkgxdev repos in January 2025 and kept a steady pace through May, then made only scattered commits until stopping entirely in November 2025. His public GitHub activity in June 2026 is in automic-vault, a new org created in April with no connection to tea or pkgx, while he remained tea’s CEO in press coverage as recently as December.
pkgx itself is now mostly the work of one maintainer, Jacob Heider, who has carried the package-building pipeline more or less alone since mid-2025, lately assisted by Claude Code-generated pull requests that he reviews and merges. User-filed issues on the pkgx repo (then still teaxyz/cli) peaked at 78 a quarter in early 2023 and have arrived at a rate of 2 a quarter in 2026.
In tea’s Discord, the conversation since launch is upset token holders: testnet participants who completed identity verification say they’re not eligible for the airdrop, the free distribution of tokens they spent two years earning points toward, and a week after launch the official line in the channel is that nobody has said there won’t be one. “The current price is a complete joke for everyone who participated in the project,” as one user put it, while the moderation bot issues warnings for bad word usage. The member list shows two people with the Core Contributor role, and neither is a founder. The channels for the open source side of the project, the dev and package dataset discussion, have had no real activity since 2025.
tea’s post blames a bad week for crypto generally, and the wider market fell that week too. But the same post admits to “decisions, timing factors, and execution details that we are reviewing internally”, and the commit history shows few people left to conduct that review. Four years, roughly $17M in disclosed venture funding, and about $2M more from the public sale produced several hundred thousand spam packages and a cleanup bill paid by registries that never had any relationship with tea. The maintainers tea set out to pay, the ones with real packages and dependents, are left holding the same token as the farmers.
Data notes: commit counts are author-dated commits to non-fork repos in each GitHub org, collected via the GitHub API on June 11th 2026. Price data is GeckoTerminal hourly OHLCV for the Aerodrome TEA/USDC pool on Base. Issue counts exclude pull requests, bots, and tea team accounts. The raw data and chart scripts are in data/tea on GitHub.
]]>Malevolent dictator for life. The same arrangement after the benevolence has worn off, with the founder still in the chair and nobody around with the access or the energy to do much about it. From outside it shows up as long-time contributors going quiet and forks appearing in places that do not usually fork.
Steering council. What a BDFL project becomes after the dictator retires or is asked to. The usual shape is a small elected committee with rotating seats and no permanent membership, as in Python’s transition to a five-person Steering Council via PEP 13 and PEP 8016 after Guido stepped down. Most BDFL projects do not write a succession plan in advance and end up improvising one in whatever crisis prompted the handover.
Permanent core team. A long-lived group of recognised maintainers joined by invitation and serving without fixed term, sometimes inside a foundation and sometimes not. PostgreSQL’s core team is the canonical example, with new members nominated by existing ones and no formal voting or candidacy process. The model accumulates institutional memory better than rotating committees. The trade-off is that the criteria for joining are unwritten and amount to whatever the current members happen to agree on.
The Apache Way. A standardised ladder from contributor to committer to project management committee member, with a rotating chair and decisions taken on the dev mailing list by lazy consensus or vote. The structure is identical across every Apache project, which is the foundation’s actual product. It does not depend on any individual maintainer remaining interested next year, at the price of being slow.
Vendor-neutral foundation. A foundation owns the trademark and the legal entity, a technical oversight committee delegates to maintainers, and member companies pay dues that fund the staff. CNCF, Eclipse, OpenJS, and the Linux Foundation umbrella projects all run on variations of this shape. Neutrality means no single member captures the project, enforced by the membership agreement rather than anything structural in the code. The foundation itself is a participant in the arrangement rather than a neutral platform for it, with its own continuity and growth on the agenda alongside any one project’s.
Technical steering committee with subgroups. A TSC handles cross-cutting decisions, and special interest groups or working groups own particular areas of the codebase. Kubernetes is the maximalist version, with a documented governance file for every SIG, and Node.js runs a smaller version of the same shape. The model scales reasonably with the size of the project but less well with employer concentration, since once a majority of SIG leads work for the same company nothing about the org chart will say so.
Do-ocracy with lazy consensus. Whoever does the work decides, and proposals pass absent objection within some window. Debian’s package maintainership runs this way, as does most of Apache once you are past the formal voting structure. It works as long as participation is broad, and reverts to an unannounced BDFL when one person ends up doing most of the work without saying so, with the cosmetic advantage over the announced version that nobody has to admit it.
Discord-driven development. The institutional memory of the project lives in a chat server, with decisions tracked by linking to messages from GitHub issues, and the durable record limited to whoever screenshotted what before the channel scrolled. Common in JavaScript frameworks and crypto projects, with the README linking a community server in place of a CONTRIBUTING file, and issue threads that close with a pointer to chat.
Conference-driven roadmap. The annual conference is the only time the maintainers are all in one room, so the roadmap for the year gets set on a Tuesday afternoon based on which suggestions made it onto the slide deck. The conference is sponsored by the biggest user of the project, whose feedback was incorporated during the planning calls. The signature outcome is a feature appearing in the next release that nobody filed an issue for, traceable to a slide deck nobody kept a copy of.
Rough consensus and running code. IETF doctrine, codified in RFC 7282, under which no formal vote is taken, working implementations carry more weight than opinions, and the chair calls consensus when objections are addressed rather than counted. The model suits standards bodies more than codebases. It reliably produces decisions owned by whoever showed up to push back, who are usually not the people the decisions affect.
Single-vendor open source. One company holds the copyright, the trademark, and the publish keys, contributors sign a CLA on the way in, and the roadmap is whatever the company needs. MongoDB, Elastic, HashiCorp, and Redis were open source by the OSI definition for most of their history, then relicensed away from it once the strategic calculation changed. The community check is the same as for the dictator (leave and fork), and the price is the cost of rebuilding whatever the company was paying for, which OpenTofu and Valkey are currently demonstrating in practice.
Hot fork summer. The project goes through governance crises predictably enough that a sequence of forks has accumulated (project, project-ng, project-next, project-classic), each with its own claim to the legitimate inheritance. Each fork was supposed to settle the question and instead added another row to the disambiguation page. Every new README explains at length which other forks the project is not, and downstream picks based on which lockfile they already have.
Token-governed. On-chain proposals weighted by token holdings and executed by smart contract, as in Uniswap and MakerDAO. It has the only literal elections in the catalogue, with influence proportional to capital and the proportions on public ledger.
Coding agent for life. Autonomous coding agent create the repository, register the account that hosts it, write the code, open and review their own pull requests, and merge without anyone signing off. Influence over the project accrues to anyone who can phrase an issue convincingly enough that the swarm acts on it, which is a wider electorate than any other model in the catalogue.
]]>US6381742B2 - Software package management. Microsoft. Filed June 1998, granted 2002, expired 2018. Claims a distribution unit, a manifest file, and a code store data structure, with dependency resolution at install time and shared-component tracking at uninstall. Prior art: CPAN manifests (1995), dpkg control files (1995), RPM (1997), FreeBSD ports (1993).
US7222341B2 - Method and system for processing software dependencies in management of software packages. Microsoft. Filed February 2002, granted 2007, expired 2019. Continuation of US6381742B2, sharing its June 1998 priority date. Claims the install-time loop: check installed, identify missing dependencies, fetch from specified sources, extract, register, update the code store. Prior art: as for US6381742B2.
US9348582B2 - Systems and methods for software dependency management. LinkedIn (now assigned to Microsoft). Filed 13 February 2014, granted 24 May 2016, lapsed for fees. Claims retrieving a dependency declaration and selecting a valid version of an upstream product usable at the consumer’s build time. Prior art: the same build-time version-selection mechanic in apt, Maven, Bundler, and others, all predating the filing.
US8621454B2 - Apparatus and method for generating a software dependency map. Oracle America (originally Sun Microsystems), inventor Michael J. Wookey. Granted from application US20110258619A1; the family descends from an abandoned 2007 parent (Ser. No. 11/862,987). Dependency resolver feeds a graph manager that maintains a map of installed components.
US9881098B2 - Configuration resolution for transitive dependencies, with continuation US10325003. Walmart Apollo / Wal-Mart Stores. Resolves the configuration of transitive dependencies at deploy time rather than at packaging time. Closer to enterprise-Java config wiring than to package manager mechanics, but surfaces on dependency-resolution searches.
US10977024B2 - Method and apparatus for secure software update. Sierra Wireless (now Semtech). Filed 15 June 2018, granted 13 April 2021, lapsed for fees. Claims OCSP stapling for software updates: the update manager pulls OCSP responses from the CA, bundles them into the update package, and the device verifies certificate status offline. Aimed at IoT/embedded firmware updates rather than general package distribution.
US11765155B1 - Robust and secure updates of certificate pinning software. Amazon Technologies. Filed 29 September 2020, granted 19 September 2023, active until 20 November 2041. When the pinned signing certificate has rotated, the client retrieves the new certificate from a separate publishing service and verifies it through a chain of trust, rather than failing closed or requiring a bundled application update.
WO2020232713A1 - Container instantiation with union file system layer mounts. On instantiation, the runtime receives an image manifest and sends layer mount requests to the registry rather than downloading layer content. Prior art for the union-mount side: UnionFS (2005), AUFS (2006), OverlayFS (2014). Prior art for lazy and on-demand layer fetching: Slacker (FAST ‘16), eStargz, SOCI.
US12056511B2 - Container image creation and deployment using a manifest. IBM. Manifest-driven container build and deploy; claims cite inode descriptors and file hashes. Prior art: the OCI image-spec, and the content-addressable storage model from Git (2005) and earlier systems like Monotone and Venti.
US10127030B1 - Systems and methods for controlled container execution. The container manifest carries a hash or digest of each item, and a content validation engine compares the digests at execution time. Prior art: the OCI content-addressable storage model, with Git as the earlier general-purpose precedent.
If you’re aware of patents that should be included in this collection, please reach out on Mastodon or submit a pull request to the post on GitHub.
]]>Bundler 4.0.13 ships Cooldown, a configurable time window that holds back resolution to gem versions younger than N days, so a freshly published malicious release ages past the window before a bundle install will pick it up. The companion RubyGems 4.0.13 release blocks gem extraction from escaping the destination directory via pre-existing symlinks.
The Packagist supply-chain series continues. Closing Composer’s Download Fallback Paths covers how the dist-to-source fallback, originally designed for resilience, can be used to fetch a different artifact than the one Composer expected. Blocking Malware Downloads for Every Composer Version describes how Private Packagist enforces malware blocking for installs from Composer versions older than 2.10, before the dependency policy framework existed. Enforce a Safe Composer Version Across Your Organization closes the loop by letting Private Packagist organisations restrict which Composer client versions can fetch the repository at all, rejecting older clients with an error that surfaces in the developer’s terminal.
New HexDocs URLs: per-package subdomains moves public Elixir and Erlang package docs from hexdocs.pm/package to package.hexdocs.pm, and organization docs to a separate registrable domain (hexorgs.pm). The browser’s same-origin policy now isolates packages from each other, addressing a finding from Hex’s recent security audit that docs pages run maintainer-controlled HTML, CSS, and JavaScript under a shared origin.
Homebrew’s Tap-Trust documentation describes an upcoming change to how non-official taps are loaded. Today any installed tap contributes formulae, casks, and commands by default. Under Tap-Trust, taps need explicit approval via brew trust user/repo (or a per-formula variant) before Homebrew evaluates their code. The change becomes the default in Homebrew 6.0.0 or 5.2.0, whichever ships first. HOMEBREW_REQUIRE_TAP_TRUST=1 opts in early.
Composer 2.10.1 fixes shell escaping when opening an editor and verifies the backup phar’s signature before self-update --rollback restores it.
NuGet.Server 3.4.3 fixes an unauthenticated denial-of-service on the package upload endpoint (CWE-696/CWE-400) by moving API key validation ahead of the file I/O and package processing it used to do first.
Yarn 4.16.0 adds yarn npm stage for npm’s staged publishing queue, alongside editor SDK support for oxc’s formatter and linter.
Hatch 1.17.0 deprecates hatch fmt in favour of a new hatch check command group with code, fmt, and types subcommands. Type checking is wired up to Pyrefly. The release also adds hatch env lock for locking environments and switches the HTTP client from httpx to httpx2.
NixOS 26.05 “Yarara” is the latest six-monthly release of Nixpkgs and NixOS. The Nixpkgs side added 20,442 new packages and updated 20,641 since 25.11, and dropped 17,532. This is also the final release with x86_64-darwin support, since upstream Apple has deprecated the platform.
Stack 3.11.0.1 RC switches the default 64-bit Windows MSYS environment from MINGW64 to CLANG64, following the MSYS2 project’s deprecation of MINGW64 in March.
Dependabot Core 0.380.0 adds a lockfile generator for bun via PR #14882. The same release passes --config.minimumReleaseAge=0 to pnpm security updates, bypassing any pnpm-workspace.yaml cooldown setting so security PRs aren’t blocked behind the release-age policy.
mise 2026.6.0 wires npm into Corepack when node.corepack=true and node.npm_shim=false, so the Corepack-managed npm shim sits alongside yarn and pnpm, and aligns aqua’s Windows extension handling with upstream.
Windows Package Manager 1.29.250 is the 1.29 release candidate. Sources can now be assigned a numeric priority (experimental). When several sources offer the same package, installs prefer the higher-priority source without prompting. Export and import round-trip override and custom installer arguments, and the MCP server gained upgrade actions.
Also out: Cargo 0.97.1, uv 0.11.19, pip 26.1.2, Conda 26.5.2, Mamba 2.8.0, pixi 0.70.1, pnpm 11.5.2, pipx 1.14.0, Deno 2.8.2, Homebrew 5.1.15, Docker Engine 29.5.3, Go 1.25.11, Go 1.26.4, sbt 2.0.0-RC14, cargo-semver-checks 0.48.0.
Where does the money come from? (Daniel D. Beck) is a catalogue of every channel he knows that gets technical-documentation authors and maintainers paid, from foundation grants and staff tech-writer roles to docs-for-hire arrangements and tip jars.
How OSPOs can measure the impact of OSS funding (Dawn Foster) is the case OSPOs can make internally when budgets tighten and the funded projects don’t translate directly into product revenue. Dawn also has a four-page piece in IEEE Computer on how governance choices shape open source project sustainability, aimed at project leads.
The Rust Foundation Maintainers Fund launched this week as a “Maintainer in Residence” programme that pays existing Rust Project maintainers from a donor-funded pool.
Rendering a lock file with pipdeptree is a new tutorial for the from-lock subcommand, which prints the dependency tree of a PEP 751 lock file offline without resolving or installing anything.
The Reproducible Builds May 2026 report leads with Debian’s decision to require reproducibility for packages migrating into the next release (“forky”), blocking unreproducible packages from migration.
Poking Around in the Dark: Why a Shared Understanding of Components Matters (Reichmann et al., arXiv) finds that SBOM generators disagree on what counts as a component in the same software, leaving gaps in supply-chain vulnerability identification.
PyFEX: Uncovering Evasive Python-based Threats via Resilient and Exhaustive Path Exploration (Wang et al., arXiv) is a forced-execution engine for Python that recovers from crashes mid-run and flagged 212 previously unknown malicious uploads on PyPI.
crates.io PR #13855 proposes surfacing standard-library replacements on crate pages: a banner on the crate page and a marker in dependency lists, each linking to the std API that covers what the crate did. Seeded with lazy_static, once_cell, matches, and num_cpus. The PR cites my features everyone should steal from npmx post as one of the inspirations.
Send links for next week to @andrewnez@mastodon.social.
]]>setup.py, a CPAN Makefile.PL, an RPM scriptlet, a Conda post-link, a Debian postinst. A handful require explicit per-package opt-in before any of that code runs, usually called an allowlist or a trusted-dependencies list depending on the tool.
Per-package opt-in lists name which dependencies may run their install code: npm, pnpm, Bun, Deno, and Composer plugins all work this way. Global sandboxes (opam, Swift Package Manager, Nix, Guix, Portage) take a different shape, executing everything but constraining what that execution can reach. Identity and signature verification (RubyGems trust policies, Gradle dependency verification, NuGet trustedSigners, apt-secure) gates which artifacts get installed in the first place by who signed them, with no bearing on what their code subsequently does.
An npm postinstall, a setup.py, a Makefile.PL or an RPM scriptlet fires during fetch or unpack. A Cargo build.rs or a Zig build.zig runs when the project is compiled, which on a fresh build is functionally the next step but is structurally distinct. JVM build files (Gradle’s Groovy or Kotlin, Maven’s plugin goal invocations, SBT’s Scala) execute earlier still, before any project source touches the compiler.
npm shipped per-package allowlists in 11.16.0 (May 2026) via an allowScripts field in package.json, managed by npm approve-scripts and npm deny-scripts, with entries pinned to a specific version (pkg@1.2.3: true) by default and denials written name-only.
Behaviour in 11.x is advisory: scripts still execute, an end-of-install summary names anything unreviewed, and the docs signpost a hard block in a future release. The similarly-named npm trust command, added in 11.10.0 (February 2026), is for OIDC trusted publishing rather than script execution.
pnpm v10 (January 2025) blocked install scripts by default, reading the allowlist from onlyBuiltDependencies / neverBuiltDependencies in package.json or pnpm-workspace.yaml. v11 consolidated those into a single allowBuilds map, with dangerouslyAllowAllBuilds as the escape hatch. The companion pnpm approve-builds (added in 10.1.0) is an interactive picker that accepts --all for CI and from v11 takes positional arguments like pnpm approve-builds esbuild fsevents !core-js. Packages not on the list fail the install when strictDepBuilds is true (the v11 default) and warn otherwise.
Yarn Classic (v1) has no native per-package mechanism, only the global --ignore-scripts flag, with yarnpkg/yarn#7338 tracking the feature request. The @lavamoat/allow-scripts project retrofits one across Yarn v1.22+, Yarn Berry v3+, npm v8+, and pnpm: it disables scripts at the package-manager level then drives execution from a lavamoat.allowScripts map in package.json. Yarn Berry (v2+) is declarative: set enableScripts: false globally in .yarnrc.yml, then opt packages back in via dependenciesMeta.<pkg>.built: true. No interactive approval command exists, and workspace packages always run their own scripts regardless of the global setting.
Bun blocks install scripts for dependencies by default and ships a built-in default allowlist of well-known packages (esbuild, fsevents, others) auto-trusted only when sourced from the npm registry. The trustedDependencies array in package.json overrides that list, so opting a single package in drops the default-trusted set entirely. Trust is added by name via bun pm trust <pkg> or bun add --trust <pkg> (which pulls in the package’s transitive deps), and bun pm untrusted lists packages with install scripts that haven’t been granted trust.
Deno never runs npm lifecycle scripts unless explicitly approved, via the --allow-scripts=<pkg> flag on deno install and deno cache (Deno 1.45/1.46, mid-2024) that accepts comma-separated specifiers like npm:sqlite3,npm:esbuild@0.21.5. Deno 2.6 (December 2025) added deno approve-scripts, which persists per-package decisions into deno.json. Packages without approval have their scripts skipped at install time and listed in an end-of-install warning so they can be reviewed before the next run.
Composer’s top-level scripts field carries lifecycle hooks tied to events like pre-install-cmd and post-update-cmd, but only the root package’s scripts run during install: a dependency’s scripts never execute in the parent project, unlike npm’s postinstall. Plugins are the actual transitive execution surface, and the allow-plugins configuration key (Composer 2.2, 2021-12-22) made plugin activation explicit per package.
The key takes "vendor/package": true|false entries with wildcard support ("vendor/*": true), defaults to {}, and prompts interactively for unlisted plugins while persisting the answer. Non-interactive runs (--no-interaction, CI) install the package into vendor/ but skip executing its plugin code, so an unlisted plugin doesn’t break the install, it just doesn’t activate.
Python wheels conventionally have no install-time hooks, so for Python the install-script question becomes whether a package may execute PEP 517 build backend code locally when the resolver picks an sdist over a prebuilt wheel.
Pip has no per-package allowlist for that. pypa/pip#425, opened in 2012 under the title “pip should not execute arbitrary code from the Internet”, captures the historical position. The closest controls are global: pip install --only-binary :all: refuses source distributions entirely, with --no-binary <pkg> available as a per-package exception. Secure installs recommends pairing --only-binary :all: with --require-hashes. The inverse --only-binary-except=<pkg> is tracked at pypa/pip#10724.
pypa/pip#13079 (fixed in pip 25.0) showed that wheels aren’t inert in practice: a malicious wheel could overwrite pip’s own internal modules and execute code at the tail of pip install.
uv has per-package source-build controls via a set of settings that pair global and per-package toggles: no-build and no-build-package refuse sdists, no-binary and no-binary-package force source builds, no-build-isolation and no-build-isolation-package toggle PEP 517 build isolation. The combination amounts to a per-package allowlist for which packages may execute build backend code locally. astral-sh/uv#11682 asked for only-binary to gain a persistent project-level form alongside the existing CLI flag.
Poetry exposes installer.only-binary (Poetry 2.0.0+) and installer.no-binary as comma-separated package lists or the special values :all: / :none:. Combining installer.only-binary = ":all:" with installer.no-binary = "pkgA" produces a per-package source-build allowlist by composition, since the docs state that explicit package names override :all:. PDM has --no-isolation for build isolation but no no-binary-package equivalent in the CLI reference. Pipenv has neither natively. The documented workaround is --extra-pip-args="--only-binary=:all:" or setting PIP_NO_BINARY / PIP_ONLY_BINARY for pip to read directly.
Conda packages can ship pre-link, post-link, and pre-unlink shell scripts that run on the user’s machine during install and uninstall. The link-scripts documentation advises authors to avoid them but documents no allowlist, no .condarc toggle, and no CLI flag to disable them. Conda’s security configuration knobs (safety_checks, extra_safety_checks, signing_metadata_url_base, channel allowlist/denylist) cover artifact integrity and channel provenance, not per-package script execution. Mamba and micromamba reimplement the install model and inherit the same gap.
The indirect mitigation is that noarch: python packages are required by policy not to ship link scripts, so restricting yourself to noarch: python deps avoids the surface for pure-Python work.
RubyGems and Bundler have no per-gem allowlist for install-time code execution. Gems with ext/<name>/extconf.rb run arbitrary Ruby at install time to configure native extension builds, and the same applies to Rakefile / mkrf_conf variants declared under a gem’s extensions list. The signing and trust-policy mechanism at guides.rubygems.org/security (LowSecurity, MediumSecurity, HighSecurity) checks who published a gem, not whether it may run install-time code. bundle config build.<gem> -- --with-foo passes arguments to native builds without gating whether they happen.
CPAN distributions ship a Makefile.PL (ExtUtils::MakeMaker) or Build.PL (Module::Build) which are ordinary Perl scripts executed at install time by cpan, cpanm, or cpm. There is no per-distribution capability gate, no first-time prompt, and no equivalent of allow-plugins. CPAN.pm exposes makepl_arg, mbuildpl_arg, and prerequisites_policy knobs for tuning how Makefile.PL is invoked and how dependencies are resolved, none of which gate whether the code runs.
Cargo runs build.rs and proc-macros as ordinary host-native Rust code during every cargo build, test, run, and install against the affected crates. Proc-macros execute inside the rustc process during compilation, so any procedural-macro dependency runs its code on every build. There is no global flag to disable proc-macros and no sandbox around the script process. A crate’s own Cargo.toml can set build = false to suppress its own build script, but consumers cannot disable a dependency’s build.rs.
The long-running tracking issues are rust-lang/cargo#5720 (sandbox/jail build scripts, July 2018) and rust-lang/cargo#13681 (build script allowlist mode, April 2024), plus the compiler-team MCP proposing an isolating runtime shipped via rustup, none of which has landed. cargo-vet and cargo-crev flag custom-build crates for reviewer attention; neither prevents execution.
Go modules don’t run downloaded code beyond compiling it, with go run, go test, and go generate documented as the explicit exceptions in Russ Cox’s “Command PATH security in Go”. There is no per-module trust mechanism because nothing third-party runs in the first place. The cgo #cgo CFLAGS: and LDFLAGS: directives have been the escape hatch. CVE-2018-6574, CVE-2024-24787, and #42559 were each mitigated by extending a hard-coded allowlist of permitted compiler/linker flags in the toolchain. CVE-2023-39323 addressed an adjacent surface by restricting //line directives in cgo-generated files. No per-module grant was added in any of these cases.
Swift Package Manager runs both Package.swift manifest evaluation and package plugins inside a sandbox (sandbox-exec on macOS) with no network access and writes restricted to a per-plugin temporary directory by default. Plugins that need more declare permissions in their target definition using PluginPermission: writeToPackageDirectory(reason:) and allowNetworkConnections(scope:reason:) with scope none, local(ports:), all(ports:), docker, or unixDomainSocket. The user is prompted on a TTY (PR #5483) or must pass --allow-writing-to-package-directory / --allow-network-connections non-interactively, with decisions scoped per package.
The permission-grant model covers command plugins but not build tool plugins. Build tool plugins still run inside the sandbox by default but cannot declare or be granted writeToPackageDirectory / allowNetworkConnections. The build-tool sandbox permissions pitch tracks the extension to that surface.
Zig’s build.zig is arbitrary Zig code compiled to a native host binary and executed by zig build, including for every transitive dependency pulled in by the package manager. There is no sandbox and no per-package gate. The proposal at ziglang/zig#14286 (open, labelled urgent) has no merged implementation yet. It would compile every build.zig to wasm32-wasi and emit the build graph as data for a separate build_runner to execute under whatever permissions are granted.
JVM dependencies are passive JARs that don’t execute on resolve or install. Build-time plugins are the execution surface.
Maven has no built-in allowlist of which plugins may load. Plugin goals execute as ordinary Java during the build lifecycle. The Maven Enforcer plugin’s bannedPlugins and bannedDependencies rules are blocklists with includes carve-outs, so an allowlist has to be expressed as banning * and re-including specific GAVs. Core extensions declared in .mvn/extensions.xml load into Maven’s core classloader before the build starts, with no signature check or allowlist.
Gradle’s build.gradle(.kts), settings.gradle(.kts), convention plugins, and applied plugins all execute arbitrary Kotlin/Groovy at configuration time, with no per-plugin code-execution allowlist. Dependency verification via verification-metadata.xml covers regular dependencies and plugins through checksum and PGP signature verification of artifact identity. That establishes who published the artifact, not what its code may do. Init scripts (-I, $GRADLE_USER_HOME/init.gradle(.kts), init.d/*.init.gradle(.kts)) run unconditionally with no signature check. The configuration cache serialises the configured task graph for performance, not to restrict what plugin code may do.
SBT plugins declared in project/plugins.sbt run at build configuration time with full JVM access. The official docs describe classloader-level encapsulation between plugins and build definitions as an authoring convenience, not a security boundary. There is no allowlist or signature verification analogous to Gradle’s verification-metadata.xml, and SBT inherits whatever artifact-verification posture the underlying Ivy or Coursier resolver provides. Leiningen and Mill take the same approach, with project.clj in Clojure and build.sc in Scala running as configuration-time programs and neither providing a per-plugin allowlist.
Bazel sits at the opposite end of the JVM build-tool spectrum. BUILD files and .bzl extensions are written in Starlark, a Python dialect with no clock access, no recursion, no mutable global state, and no filesystem or network calls outside declared inputs. Build actions run in a sandbox that sees only what the rule declares. The escape hatches exist (repository_rule for fetching, genrule for shell, custom toolchains), but the default posture is that a BUILD file cannot observe its host, and the per-action sandbox covers what would otherwise need an allowlist.
Under PackageReference (NuGet 4.0+ and the default for SDK-style projects), the historical install.ps1 and uninstall.ps1 PowerShell scripts no longer execute on install or uninstall, per the migration guide.
The replacement execution surface is MSBuild build/, buildMultiTargeting/, and buildTransitive/ .props and .targets files, auto-imported into the consumer’s build through NuGet-generated {projectName}.nuget.g.props and .nuget.g.targets. buildTransitive lets a transitive dependency contribute targets to your project without you naming it as a direct dependency. There is no per-package allowlist for MSBuild target imports. The <trustedSigners> configuration in nuget.config controls which signed packages are accepted by signer identity, without bearing on what their MSBuild contributions then do.
Hex/Mix (Elixir) evaluates each dependency’s mix.exs and runs its compile task on mix deps.compile, with no per-package allowlist and no separate install-script field beyond compilation. Rebar3 (Erlang) supports pre_hooks, post_hooks, provider_hooks and plugins loaded from Hex, all of which execute when their declaring dependency is built, again without any allowlist.
Cabal and Stack (Haskell) historically run arbitrary Setup.hs programs for packages with build-type: Custom. The recent build-type: Hooks in Cabal 3.14 (2024) replaces wholesale Setup replacement with a fixed set of named hook points, narrowing the surface without introducing an allowlist.
Opam (OCaml) wraps every package’s build: and install: commands with sandbox.sh (opam 2.0, 2018), using bubblewrap on Linux and sandbox-exec on macOS. The build phase can write to the build directory and /tmp but sees the switch as read-only; the install phase can write to the switch. Network access is denied throughout. The sandbox is global rather than per-package, and opam init --disable-sandboxing turns it off.
Pub (Dart/Flutter) historically ran no dependency code on resolution. The hook/build.dart mechanism started as an experiment in Dart 3.2 behind --enable-experiment=native-assets and stabilised in Dart 3.10. The design is advertised as “semi-hermetic” for reproducibility, not for adversarial isolation.
LuaRocks rockspecs can declare command, make, cmake, or builtin build backends, with the command backend executing arbitrary shell during luarocks install and no allowlist over which rocks may do so.
Nimble (Nim) supports before and after template hooks in .nimble NimScript files, with exec of external processes as the documented escape hatch from NimScript’s own FFI restrictions. zef (Raku) runs a Build.rakumod or a builder module declared in META6.json unconditionally during the build phase. The --/build flag disables the build phase globally; no per-distribution gate is documented.
Crystal Shards supports a postinstall field in shard.yml with a global --skip-postinstall flag as the only opt-out. The community forum thread “postinstall considered harmful” covers the case for changing this. Julia Pkg runs deps/build.jl on first install of each dependency, with the modern alternative being BinaryBuilder-produced _jll packages referenced by hash, although build.jl remains supported.
R source packages on CRAN run a configure Bourne shell script (and configure.win on Windows) before anything else, plus arbitrary code in R/zzz.R’s .onLoad and .onAttach. CRAN’s mitigation is editorial review and pre-built Windows/macOS binaries from the build farm, with no per-package mechanism.
CocoaPods displays a per-install warning the first time a Podfile pulls in a pod with script_phase build phases, plus on every update where the pod still contains them, without persisting a stored allowlist. Carthage clones each dependency’s repo and invokes xcodebuild against its shared schemes, which executes any Run Script build phases declared in the dependency’s .xcodeproj without warning or allowlist.
Conan recipes are full Python modules whose source(), build(), package(), and package_info() methods run in the host Python process during conan install and conan create. There is no sandbox or allowlist; curation of the ConanCenter index is the trust boundary.
vcpkg ports are portfile.cmake files interpreted by CMake’s script mode and able to call execute_process and vcpkg_execute_build_process, with no per-port allowlist or sandbox per the ports documentation.
Spack package.py files are arbitrary Python with install() methods and build phases that run during spack install. Spack’s security framing covers download integrity (checksummed tarballs, pinned git commits), not per-recipe capability.
On dpkg/apt, RPM/dnf, pacman, and Alpine’s apk, install-time maintainer scripts (preinst/postinst/prerm/postrm for dpkg, %pre/%post/%preun/%postun for RPM, .INSTALL for pacman, $pkgname.{pre,post}-install plus .{pre,post}-upgrade, .{pre,post}-deinstall, and .trigger for apk) run as root with no sandbox, no chroot, and no seccomp filter. The trust model is the archive itself, with apt-secure(8) gating which packages enter the install pipeline via repository GPG signing. There is no per-package allowlist or opt-in flag, and the Debian wiki’s UntrustedDebs page treats installing a .deb from outside the trusted archive as effectively giving the package author root.
The pacman official repositories follow the same archive-curation model. The AUR exposes raw PKGBUILDs and .INSTALL files to users for review, with AUR helpers (yay, paru, pikaur, others compared in the helpers table) differing on whether they prompt for a diff of PKGBUILDs before sourcing them.
Nix and Guix run every derivation’s builder inside a chroot with a fresh PID/network/mount namespace, an unprivileged build user (Nix’s nixbld pool, Guix’s guixbuild pool), and no network access except for fixed-output derivations whose output hash is declared up front. The model is documented in the Nix configuration reference and the Guix Build Environment Setup chapter. Every builder runs inside the box, with fixed-output derivations and the small trusted-users set as the remaining trust surface. CVE-2024-27297 was a fixed-output-derivation sandbox bypass affecting both Nix and Guix.
Portage (Gentoo) enables FEATURES="sandbox" by default, an LD_PRELOAD shim that intercepts filesystem syscalls and blocks writes outside permitted build directories. userpriv runs ebuild phases as the portage user, and usersandbox combines the two. The mechanism is LD_PRELOAD-based, so static binaries and direct syscalls bypass it, as documented on the Gentoo wiki’s Sandbox (Portage) page. Trust still flows from the curated Portage tree’s signed Manifest files, with no per-ebuild capability grant. Overlays sit explicitly outside that boundary.
Homebrew, MacPorts, Scoop, and Chocolatey locate trust at the repository (tap, ports tree, bucket) level rather than per-package: tapping a repository or adding a bucket grants it the same trust as the core repository, and individual formulae, ports, or manifests have no per-package allowlist. Homebrew’s security policy makes the tap-level boundary explicit.
MacPorts signs the ports tarball (GHSA-2j38-pjh8-wfxw, disclosed December 2024, covered an rsync filter bypass that let a malicious mirror deliver unsigned Portfiles past the signed-archive boundary and trigger Tcl execution during portindex). Scoop bakes a known-bucket list into the client with per-manifest hash verification. Chocolatey adds human moderation of community submissions on top of optional package signing, with Trusted Packages bypassing manual review based on author track record.
winget differs because its YAML manifests don’t include arbitrary install-time scripts. The supported InstallerType values are real installer formats (msi, msix, appx, exe, inno, nullsoft, wix, burn, portable, zip, font, msstore), and the manifest declares a SHA256 of the installer binary. winget validate checks manifest format; PR review on the winget-pkgs repo plus Azure Pipelines bot validation covers submission integrity, alongside an optional local SandboxTest.ps1 that authors can run to test a candidate inside Windows Sandbox before submitting.
asdf plugins are Git repositories of shell scripts (bin/install, bin/list-all, others) that run as the user during asdf install, with no allowlist or sandbox: adding a plugin is functionally equivalent to running its bash. mise reduces the plugin surface by routing most tools through non-shell backends: mise discussion #4054 maps most tools to aqua, ubi, vfox, or core in the default registry, with asdf plugins forked under the mise-plugins GitHub org so commit access is controlled.
mise trust and trusted_config_paths gate execution of [env], [hooks], and [tasks] blocks in project-level mise.toml files, prompting on first cd into a directory with an untrusted config and persisting the decision per file.