Firefox is built with Node.js's release build, a layer no zone gets

[DevomB]

What was wrong

The browser's second build round stopped at the devtools debugger's generated modules: Firefox ESR 153 runs Node.js there. --disable-nodejs only gets configure past a missing Node.js (it warns), and the build then fails over an hour later.

What changed

• The node layer (build/images/node.sh, image_ships=no). It takes only bin/node from Node.js's linux-x64 release build and puts it in /usr/lib/node-24; npm and the headers are not needed. Its check runs a script, since --version returns before the engine starts, so a node that cannot run in the build chroot fails in this layer within seconds.
• The browser (build/images/browser.sh) is built over node. --disable-nodejs is dropped, and the mozconfig exports NODEJS=/usr/lib/node-${V_NODE%%.*}/bin/node, following the pin as the llvm path follows V_LLVM. In ESR 153's build/moz.configure/node.configure, NODEJS is an environment option, and without --disable-nodejs a node that is missing or older than 12.22.12 is a FatalCheckError. So a wrong path stops configure at the start, not an hour into the build.
• The pin. V_NODE=24.22.0 (an LTS line). Its row in tools/fetch-sources.sh is sums:SHASUMS256.txt.sig. The tarball's digest is in build/images/sources.lock. The currency rule reads https://nodejs.org/dist/index.json, keeping the major (major).
• The signer. Node.js signs each release's SHASUMS256.txt. The row takes the .sig beside it, a detached signature. The .asc is the list clearsigned, and is_pgp_signature would not take it: gpg's packet listing of it shows a literal data packet and no signature packet, so the source would be unverifiable. Richard Lau's key C82FA3AE1CBEDC6BE46B9360C43CEC45C17AB93C signs 24.22.0. It is pinned in PINNED_FPRS, as listed in https://github.com/nodejs/node#release-keys. Its origin row in tools/key-provenance.tsv takes the key from the nodejs/release-keys repository. A later release signed by another releaser needs that releaser's key pinned the same way. The run would refuse it until then.
• A cached list that names another release. verify_sums caches a list under its own name in .signatures, and CI restores that directory by prefix. Every Node.js release names its list SHASUMS256.txt, so after a bump the cached list would be the previous release's and would refuse the new tarball. A cached list that does not name the file is now dropped with its signature and fetched again. The versioned lists (cmake, pixman, cairo) are unaffected.
• Docs. docs/design/browser-and-graphics.md now lists node among the browser's layers, with its floor. Its build paragraph no longer says --disable-nodejs spares the build.

How checked

• I fetched https://nodejs.org/dist/v24.22.0/SHASUMS256.txt and its .sig. The list gives cc2f601c…5008 for node-v24.22.0-linux-x64.tar.xz, which is the lock's line. The .sig names issuer fingerprint C82FA3AE…B93C as a v4 primary, with no subkey. gpg verifies it (GOODSIG, VALIDSIG, made 2026-10-14) against the key from the release-keys URL in the origin row. The same fingerprint is in the README's release keys.
• I read ESR 153's node.configure at FIREFOX_153_5_0esr_RELEASE for the NODEJS option and the fatal path.
• tools/tests/verify-signatures.sh has a new case: one release's list is cached under a name the next release's list shares. With the old verify_sums, its second run fails ("does not match a digest in SHASUMS256.txt"). A fix that kept the old signature would fail it as a bad signature. The existing case "a file the signed list does not name fails" still fails as before, after one more fetch. CI runs the suite; I did not run it on the laptop.
• bash -n passes on each changed script. The design document is wrapped at its width. CI's strict signature step will fetch the new row from nodejs.org and verify it.