There’s exactly one file in one of my wiki projects that’s a security control rather than a config file, and I hadn’t read it in months.
\npnpm 11 removed onlyBuiltDependencies along with four related settings and replaced all of them with a single allowBuilds map, described in the docs as “a map of package matchers to explicitly allow (true) or disallow (false) script execution.” A postinstall script is arbitrary code running on your machine at install time with your permissions, so the list of packages allowed to have one is the shortest and highest-consequence list in the repo.
Mine has six entries. Two true, four false. Here’s the true half:
allowBuilds:\n sharp: true # native libvips bindings (image processing)\n "@xenova/transformers": true # native ML runtime\nAnd here’s the count:
\n$ grep -c 'transformers' pnpm-lock.yaml\n0\n$ grep -rn 'xenova' --include='*.json' --include='*.yaml' --include='*.ts' . | grep -v node_modules\npnpm-workspace.yaml:28: "@xenova/transformers": true # native ML runtime\nZero references in the lockfile. One reference in the entire repository, and it’s the line granting the permission.
\nThis project used to run embeddings locally. That approach is gone, search goes through a hosted retrieval service now, and the project’s own direction notes say not to reintroduce local embeddings. The dependency left. The standing permission to execute native build scripts on my machine stayed behind, waiting for a package that’s never going to be installed.
\nNobody’s exploiting this. The package isn’t in the tree, so nothing runs. I want to be clear about that before anyone gets excited.
\nWhat it costs me is the ability to trust the file. An allowlist works as a control only if every entry means I read this package’s install script and I accept it. The moment one entry instead means this was true in a previous version of the project, the list becomes a record of the past, and the next person to open it has no way to tell the two kinds of entry apart without re-deriving all six from the lockfile. The next person is me, in four months, at which point I will absolutely assume the file is current.
\nThis is the failure mode of every allowlist I’ve kept. They only grow. Removing an entry requires noticing that something left, and nothing tells you when a dependency stops existing.
\ntrue entry has the opposite problemsharp is granted a native build. sharp is also not in my package.json. It shows up anyway:
$ pnpm why sharp\nsharp@0.35.3\n└─┬ astro@7.2.4\n ├─┬ @astrojs/node@11.1.4\n │ └── <package> (dependencies)\n └── <package> (dependencies)\nAstro declares it as an optional dependency. I wrote about that mechanic in a different repo a few days ago, so I’ll skip the re-explanation. What’s new to me here is that the same workspace file also pins it:
\noverrides:\n vite: ^8.2.2\n sharp: ^0.35.3\nThe comment sitting above that block warns that several of these pins are CVE remediations for transitive dependencies, and not to relax a bound without checking the advisory it was added for. That’s a good note. It’s also attached to a package I never asked for, whose version I control only because I reached into the resolver and overrode somebody else’s optional dependency.
\nfalse entries turned out to be the good news "@prisma/engines": false\n prisma: false\n better-sqlite3: false\n esbuild: false\nThese four aren’t a new restriction, and it took me a minute to work out why they’re written down at all.
\nUnder pnpm 10, onlyBuiltDependencies was an exclusive allowlist. Anything not on it got skipped. All four of these were already being skipped, silently, for as long as this project has existed. pnpm 11’s strictDepBuilds refuses to skip quietly, and exits non-zero when a dependency has an unreviewed build script.
So the upgrade changed no behavior at all. It changed whether the behavior was visible, and converted four invisible skips into four decisions I had to write down and sign. That’s the good version of a breaking change, and it’s the reason the dead @xenova/transformers entry was sitting right there for me to trip over.
$ grep -c '0.34.5' pnpm-lock.yaml\n0\n$ du -sh node_modules/.pnpm/@img+sharp-libvips-darwin-arm64@1.2.4\n 15M\nsharp@0.34.5 has zero references in the current lockfile and is still on disk, next to 15M of libvips binaries compiled for it, which in turn sit next to the 17M of libvips 1.3.2 that the current resolution actually uses. The override moved from ^0.34.4 to ^0.35.3 in a dependency sweep last week, and the old native payload never left. That’s pnpm store prune territory rather than a correctness bug, but it’s 15M of compiled image-processing code on a machine whose project doesn’t declare an image-processing dependency.
allowBuilds should resolve to something in pnpm-lock.yaml, or the build should complain. It’s maybe ten lines of test and I don’t have it.The security value of an allowlist lives in the reviewing, not in the file. I’ve been maintaining the file.
\nallowBuilds and strictDepBuilds, plus the migration table from the five settings pnpm 11 removedonlyBuiltDependencies and friendspnpm-workspace.yaml surface\n\n", "date_published": "2026-09-06T10:00:00-05:00", "url": "https://llbbl.blog/2026/09/06/i-gave-installscript-permission-to.html", "tags": ["security","javascript","Dependencies","Pnpm"] } ] }I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @logan@llbbl.blog.
\n