TLDR; yes, fresh end users won't get vulnerable node-tar on npm install. Existing end users might need to run `npm upgrade`.
We still need to fix the repo, so that our own package-lock.json doesn't contain a vulnerable node-tar version pin, but this only effects cordova-lib contributors and can be corrected at anytime, outside of a release cycle. So we don't need to block the release just because this node-tar vulnerability appeared. Long version: It depends, cause NPM operates a bit differently depending on context. For end users, installing the cordova-lib package from NPM... by default installs the latest satisfiable version of all dependencies. This assumes there is no existing node_modules / local package- lock.json (not to be confused with cordova-lib's package-lock). NPM will reuse dependecies that already exists and is already at a satisfiable version. So `npm install` may omit updating node-tar. That is where `npm upgrade` command becomes useful. So yes, if an npm install on a "fresh project" does not introduce the vulnerability, then it's not installing the vulnerable version of node- tar. For end users, it will only be an issue if they installed Cordova at the time where the vulnerable version was the latest version of node- tar. In those cases, npm install might not update node-tar, and that is where the `npm upgrade` should fix that. For cordova-lib constributors cloning the cordova-lib repo, the package-lock.json comes into play. NPM will use versions pinned inside package-lock and the vulnerable version of node-tar is likely pinned. So NPM install will continue to install the vulnerable node-tar version. If we issue `npm upgrade`, it will update all sub-dependencies to their latest non-breaking versions. `npm upgrade` does not update direct dependencies (anything explicitly listed inside `package.json`). That's why I said this probably doesn't need to block the release. Because end-users can correct the problem, in-fact if they are in a situation where they require using `npm upgrade` then only they can correct the problem. For our contributors, we just need to update our package-lock.json via `npm upgrade` and that can be done anytime, outside of a release, because these users are working against the actual repo. Even if we block the release, ensured our package-lock is updated and built a new release... That does not fix end-users who already have a vulnerable node-tar version already in their dependency tree. They will still need to correct their own tree using `npm upgrade`. Or by deleting their own package-lock and node_modules folder and re-running `npm install` (which will have the same outcome as running `npm upgrade`). On Fri, 2025-10-31 at 19:59 +0900, Niklas Merz wrote: > I just did a very simple test. Not sure if this helps but: > > If you create a blank new npm project with "npm init" and install the > tar from dist/dev, there are no audit issues. So npm doesnt install > the > vulnerable version right? > > On October 31, 2025, norman breau <[email protected]> > wrote: > > I don't think this important enough to block a release. > > > > Because like you said, there is no shrinkwrap file, so the version > > is > > not locked to particular release. The dependency is pinned inside > > package-lock.json but that only affects developers working on the > > cordova repository, not any end-users. > > > > So we can correct this anytime. We could add a note in our release > > blog > > stating that they may need to use `npm upgrade -g cordova` (or `npm > > upgrade cordova` if they use local installs) to get the patched > > sub- > > dependencies. > > > > If they already have cordova, `npm install` may not update the sub- > > dependencies if the installed sub-dependency still satisfies all > > the > > version pins in the dependency tree. > > > > On Thu, 2025-10-30 at 10:45 -0700, Darryl Pogue wrote: > > > We've just got a warning about a node-tar vulnerability: > > > https://github.com/apache/cordova-lib/security/dependabot/35 > > > This causes `npm audit` to fail. > > > > > > However, this is a sub-dependency and the fix is within the > > > semver > > > range and we don't have a shrinkwrap file, so a published version > > > of > > > cordova-lib should automatically pull in the updated dependency. > > > > > > How does this impact the voting? > > > > > > ~Darryl > > > > > > > > ------------------------------------------------------------------- > > -- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > ------------------------------------------------------------------- > > -- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
