feat: support delaying installation of recently published npm packages#24334
Conversation
Adds a minimum package age check (default 2 days) so that npm, pnpm and bun are instructed not to install package versions newer than the configured threshold. This mitigates supply-chain attacks where a compromised version is briefly published to the registry. The threshold is exposed via Options#withMinimumPackageAgeDays(int); setting it to 0 disables the check.
Surfaces the new minimum-package-age option through the Vaadin Maven plugins so it can be configured per project or via the -Dvaadin.npm.minimumPackageAgeDays=<days> system property. Defaults to 2 days; set to 0 to disable.
pnpm exposes minimumReleaseAge as a setting rather than a top-level CLI option, so it has to be set through the --config.<name>=<value> form (matching how --config.node-linker=hoisted is already passed). The previous form caused pnpm to fail with "Unknown option: 'minimum-release-age'" during the production bundle build.
|
While I'm a total fan of this.. how can I use the latest vaadin version with it? e.g. 25.2.1 got released and I wanna use it the same day? :( |
|
What if that npm package was hijacked and nobody has noticed it yet? |
The only thing you can do is to change the configuration to 0 days. npm doesn't have an option to use different rules for different packages and that does makes sense since it would be hypocritical of us to assert that we would be immune to these types of attacks. The core question though is whether users will understand what goes on if they try to update to a new Vaadin version on the day it's released? |
|
If we do this, we should always release the web components 2 days before the rest |
The typical flow user won't understand it.. and complains...
Sounds like a good trade-off! |
Artur-
changed the title
|
Let's tune this PR to only add the possibility and make a followup PR for setting a default. Maybe 1 day would be a reasonably compromise on the default - the recent tanstack case was detected in less than an hour |
The 2-day default blocks legitimate same-day Vaadin platform upgrades because npm has no per-package exclusion mechanism (tracked upstream in npm/cli#8979). Default the option to 0 (disabled) until that lands; the flag stays in place so users and CI can opt in for testing.
Without this, Gradle users would silently fall back to the default
method on PluginAdapterBuild and have no way to change or disable the
minimum-package-age check from the vaadin {} DSL or via
-Pvaadin.npm.minimumPackageAgeDays=N.
mcollovati
left a comment
mcollovati
left a comment
There was a problem hiding this comment.
I did not test it yet, but I added a bunch of comments.
Also, --config.minimum-release-age was added in pnpm 10.16.0; in Flow DEFAULT_PNPM_VERSION is 11.0.8, so it is fine, but we have SUPPORTED_PNPM_VERSION 7.0. Should we upgrade this value?
Similar for bun, we have SUPPORTED_BUN_VERSION 1.0.6, but is --minimum-release-age supported on that version?
Per @mcollovati's review: - Rename the option to minimumFrontendPackageAgeDays everywhere (Options field+accessors, PluginAdapterBuild method, InitParameters constant and value, Maven and Gradle parameter name) so the term is unambiguous outside JavaScript-only contexts. - Move the Maven @parameter from FlowModeAbstractMojo to BuildFrontendMojo (and BuildDevBundleMojo), since only those two mojos implement PluginAdapterBuild and actually run the install. - Fix Gradle plugin convention to default 0 (matching Maven) instead of 1. - Mention bun (alongside npm and pnpm) in field/setter/helper Javadoc; drop the stale "bun does not support" comment. - Document the minimum tool versions required for the per-tool flag (pnpm >= 10.16.0, bun >= 1.3.0). - Drop the redundant pnpm "override value" test that only varied by day count from the existing pnpm test.
… to 1.3.0 These are the first versions that support the minimumReleaseAge setting (pnpm) and --minimum-release-age flag (bun) used by the new minimumFrontendPackageAgeDays option. Older tool versions would fail the install with "unknown option" once the option is enabled. DEFAULT_PNPM_VERSION (11.0.8) is already above the new minimum, so no managed-pnpm change is needed.
|
bumped SUPPORTED_PNPM_VERSION to 10.16 and SUPPORTED_BUN_VERSION to 1.3.0 |
- Document IllegalArgumentException via @throws on Options#withMinimumFrontendPackageAgeDays. - Add vaadin.npm.minimumFrontendPackageAgeDays to DeprecatedPropertyResolver.NOT_MIGRATED so the resolver doesn't try to look up a non-prefixed legacy form for this brand-new property.
|
|
Running the maven plugin from this branch on the spring skeleton gives me errors if I use |
|
Now I deleted the pnpm cache and I get the following error, so maybe it's expected because of snapshot usage? |
|
OK, after deleting the pnpm cache and using Vaadin stable + Flow snapshot, the error is gone. |
|
Seems to work fine with bun as well. |
|
There is a pnpm issue about that ”time” error and apparently it has been fixed two or three times already.. something to do with the pnpm cache |
|
Hi @Artur- and @Artur-, when i performed cherry-pick to this commit to 25.1, i have encountered the following issue. Can you take a look and pick it manually? |
#24334) (CP: 25.1) (#24348) Adds a minimum package age check (default disabled) so that npm, pnpm and bun are instructed not to install package versions newer than the configured threshold. This mitigates supply-chain attacks where a compromised version is briefly published to the registry. The threshold is exposed via Options#withMinimumPackageAgeDays(int); setting it to 0 disables the check.
5 participants
Adds a minimum package age check (default disabled) so that npm, pnpm and bun are instructed not to install package versions newer than the configured threshold. This mitigates supply-chain attacks where a compromised version is briefly published to the registry.
The threshold is exposed via Options#withMinimumPackageAgeDays(int); setting it to 0 disables the check.