pgadmin-org / pgadmin-org/pgadmin4

Desktop package builds resolve runtime dependencies without a lockfile

Open
#10,407 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
3.8k
Forks
891
Avg merge
4d 7h
Merged PRs (30d)
8

Description

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the staging and dependency-resolution steps in pkg/linux/build-functions.sh:244-255, pkg/mac/build-functions.sh:64-79, and Make.bat:293-305, then inspect Make.bat:314 and the pinned Electron version in runtime/package.json. Build each desktop package to verify that runtime/yarn.lock is used and that Windows reads the pinned Electron version rather than the registry latest.

Written by the indexing model from the issue text.

Assessment

Tech stack
electron
Domain
build-system, desktop, security
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
75/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.