Needless to mention there's been a wave of npm supply chain attacks recently (Shai-Hulud, the axios hijack, TanStack compromise, etc.), often through install scripts. Given how many packages we depend on, it would be good to harden the setup of pgAdmin and vist the idea once.
A few suggestions:
1. Block install scripts from running automatically
By default, any package can run arbitrary code during install via preinstall/postinstall scripts, almost always without the knowledge of maintainers or ddevloper. This is actually how most of these recent attacks execute their payload. Setting enableScripts: false in .yarnrc.yml blocks this by default, with an explicit allowlist for packages that genuinely need it (like sharp, which downloads a native binary on install).
2. Enforce immutable lockfile checks in CI
yarn.lock can be tampered with or silently modified during CI builds to pull in mismatched hashes or unreviewed dependencies. Not to say the maintainers here aren't careful, but this kind of change is easy to miss in a normal PR review, since nobody reads a thousand-line lockfile diff line by line. Switching to yarn install --immutable in our GitHub Actions workflows and setting checksumBehavior: throw in .yarnrc.yml would catch any lockfile drift or hash mismatch automatically before a build even runs. This benefits the project by guaranteeing 100% reproducible builds and failing early if a lockfile is out of sync or compromised, ensuring unverified code is never bundled into public releases.
3. Pin @fortawesome/fontawesome-free to an explicit version
@fortawesome/fontawesome-free is currently the only package in web/package.json set to "latest" instead of a version number. Not sure if there was a specific reason for leaving it open-ended, but it risks pulling in surprise breaking changes whenever dependencies are refreshed. Pinning it to ^7.2.0 (which is what's already in the lockfile) would bring it in line with the rest of the repo and allow Dependabot to track and open PRs for future updates properly. That said, this is just a recommendation; you can disregard this if you only assume there isn't already a substantial reason to keep it on latest.
4. Bump the minimum release age gate
Yarn 4.15.0 (which we are already pinned to) defaults npmMinimalAgeGate to 1 day, delaying the install of just-published package versions. Worth bumping this to 3 days, since most compromised packages take a bit longer than 24 hours to get caught and pulled. Renovate also defaults to a 3-day cooldown, so it's not an unusual number.
Pls share your insights @dpage @asheshv.
Needless to mention there's been a wave of npm supply chain attacks recently (Shai-Hulud, the axios hijack, TanStack compromise, etc.), often through install scripts. Given how many packages we depend on, it would be good to harden the setup of pgAdmin and vist the idea once.
A few suggestions:
1. Block install scripts from running automatically
By default, any package can run arbitrary code during install via
preinstall/postinstallscripts, almost always without the knowledge of maintainers or ddevloper. This is actually how most of these recent attacks execute their payload. SettingenableScripts: falsein.yarnrc.ymlblocks this by default, with an explicit allowlist for packages that genuinely need it (likesharp, which downloads a native binary on install).2. Enforce immutable lockfile checks in CI
yarn.lockcan be tampered with or silently modified during CI builds to pull in mismatched hashes or unreviewed dependencies. Not to say the maintainers here aren't careful, but this kind of change is easy to miss in a normal PR review, since nobody reads a thousand-line lockfile diff line by line. Switching toyarn install --immutablein our GitHub Actions workflows and settingchecksumBehavior: throwin.yarnrc.ymlwould catch any lockfile drift or hash mismatch automatically before a build even runs. This benefits the project by guaranteeing 100% reproducible builds and failing early if a lockfile is out of sync or compromised, ensuring unverified code is never bundled into public releases.3. Pin
@fortawesome/fontawesome-freeto an explicit version@fortawesome/fontawesome-freeis currently the only package inweb/package.jsonset to"latest"instead of a version number. Not sure if there was a specific reason for leaving it open-ended, but it risks pulling in surprise breaking changes whenever dependencies are refreshed. Pinning it to^7.2.0(which is what's already in the lockfile) would bring it in line with the rest of the repo and allow Dependabot to track and open PRs for future updates properly. That said, this is just a recommendation; you can disregard this if you only assume there isn't already a substantial reason to keep it onlatest.4. Bump the minimum release age gate
Yarn 4.15.0 (which we are already pinned to) defaults
npmMinimalAgeGateto 1 day, delaying the install of just-published package versions. Worth bumping this to 3 days, since most compromised packages take a bit longer than 24 hours to get caught and pulled. Renovate also defaults to a 3-day cooldown, so it's not an unusual number.Pls share your insights @dpage @asheshv.