Desktop package builds resolve runtime dependencies without a lockfile

[dpage]

Whilst reviewing the supply chain hardening PRs from #10363 I noticed that none of that hardening reaches the desktop package builds, which is arguably where it matters most, since whatever npm serves on the day of the build ends up inside a signed installer.

1. The runtime install runs without a lockfile

All three bundle builds copy runtime/package.json and runtime/.yarnrc.yml into the staged application directory and then run yarn workspaces focus --production there, but none of them copies runtime/yarn.lock:

• pkg/linux/build-functions.sh:244-255
• pkg/mac/build-functions.sh:64-79
• Make.bat:293-305

The lockfile does exist in the tree, and it is what CI installs and tests against, so the effect is that the runtime dependencies inside the shipped packages are resolved fresh from the semver ranges on every build, rather than being the versions we reviewed and tested. It also means that the checksumBehavior: throw which #10395 has just restored in runtime/.yarnrc.yml, and which these builds dutifully copy into the bundle, has nothing to compare anything against and sits there inert.

Copying the lockfile alongside the other two files should be most of the fix, though it wants testing on each platform, since the resolutions it pins may well differ from whatever the last few builds happened to pick up.

2. The Windows build still takes whatever Electron is newest

Make.bat:314 resolves the Electron version with npm info electron version, which returns whatever currently carries the latest dist tag on the registry. The Linux and macOS builds were changed to read the pinned version out of runtime/package.json instead, and carry a comment at pkg/linux/build-functions.sh:205-210 spelling out why: the registry lookup lets a newly published Electron release land in shipped binaries without anyone reviewing it. Windows should do the same thing.

@dev-hari-prasad this follows on directly from your work in #10363, so it seemed only fair to offer it to you first if you fancy it.

[dev-hari-prasad]

Thanks for analysis Dave. I'll look into this and do the needful.

[dev-hari-prasad]

I have opened #10413, which addresses the second issue: the Windows build using the latest Electron version.

While tracking this down, I also found something that should probably be addressed immediately:

The flow was: Make.bat calls npm info electron version, which returns whatever npm tags as latest on the day of the build, not whatever's pinned in runtime/package.json. At the time v9.17 was built, the pin was 43.1.1, but npm's latest that day was 43.2.0, so that's what Windows actually shipped. Linux and macOS, already reading from the pin directly, built with 43.1.1 as expected. Confirmed this from the shipped app's About dialog and its build SBOM.

So there is a mismatch between what Windows currently uses vs. Linux and Mac: the same release shipped two different Electron versions depending on platform, and it wasn't caught until now.

This PR fixes the flow going forward. But if the pin in runtime/package.json stays at 43.1.1, Windows would actually go backward from the 43.2.0 it already shipped. Bumping the pin to 43.2.0 avoids that and brings all three platforms in line with what's already out in production. This is a minor bump and should not create any effect on either of the platforms. Since this is something to considered before the next build tagging @asheshv.

Happy to open a follow-up PR for the pin bump if you give it a green light @dpage.

Thanks!