On 31/10/2025 06:57, Bryan Ellis wrote:
I have a security and release-related question from the perspective of an
NPM-based project.
Periodically, we receive Dependabot pull requests (PRs) in GitHub. These
PRs usually appear when a direct or transitive dependency has an update
that resolves a security issue.
In most cases, I've noticed that these issues come from
**sub-dependencies**, not direct dependencies. As a result, the PRs
typically modify the `package-lock.json` file.
The `package-lock.json` file pins the dependency tree for reproducible
installs but is used **only during development**. When creating a release
package for a vote or publishing to the NPM registry, this lock file is
**not bundled or used**. This is part of NPM's standard process, not
something we control directly.
Because of how dependencies are declared in `package.json`, reinstalling
the package generally fetches the **latest compatible versions** of
dependencies, depending on how each is pinned.
---
Question:
If a Dependabot PR appears during the middle of a release vote — and it
updates a sub-dependency to fix a security issue — **does that invalidate
or terminate the vote?**
Things to consider:
What exactly are we voting on?
1. **The "release vote package"** — the tarball uploaded to `dist/dev`,
created using `npm pack`, representing what a consumer would receive when
installing the package.
>> 2. **The Git release tag** — the tag created in the repository, which a
consumer could also install directly (e.g., `npm install
github:apache/project-repo#1.0.0`).
3. **The repository clone** — a developer clones the repo, checks out the
release tag, and runs `npm install` within the repository.
From a strict ASF perspective the answer is always "the source
tarball". That said, having an awareness of how your user community
typically consumes your project and taking that into account is the
right thing to do.
If we are voting on the package that will be consumer-facing and the
general process in how they would consume it, the following two cases is
considered:
**Use Case 1:**
* Download the release vote package from `dist/dev`.
* Open another NPM project where you want to use the package.
* Run: "npm install /path/to/downloaded/release/vote/package.tar.gz"
**Use Case 2:**
* Open another NPM project where you want to use the package.
* Run: "npm install github:apache/project-repo#1.0.0"
Obviously, once the vote has passed and is officially published to the NPM
registry, they would just run "npm install package-name".
In both cases, NPM fetches the **latest compatible dependencies**, so there
should be **no vulnerabilities** present — assuming the dependency
constraints in `package.json` allow the patched versions.
The only scenario where you would still see the vulnerabilities is when you
**clone the repository** directly and run `npm install` inside it, because
that uses the `package-lock.json`. This lock file exists in all branches
and tags but only affects the installation of the project **itself**, not
when it's installed as a dependency to the end-users project.
It's also worth noting that while Use Case 2 installs from a Git tag, where
we know a package-lock.json file exists, NPM will not apply the lock file
as it's being installed as a **dependency**.
---
To summarize: does this terminate a vote if it is discovered that
"package-lock.json" contains a sub-dependency that was flagged with a
vulnerability—discovered in the middle of an ongoing release vote, but not
flagged at the start—and is only seen during development when installing
within the repo, not from the consumer's point of view?
Based on what i have read above, I don't see why it should.
Additionally, this raises a second question: if a release tag "rel/0.0.0"
contains the same vulnerability in "package-lock.json" from a development
perspective, but shows zero vulnerabilities when installed through the
consumer process, would any action need to be taken?
Specifically, I think not.
More generally, what I would suggest that is somewhere where developers
would be expected to read if they were going to clone the repo (maybe in
the building instructions if you have them) that you document that if
they clone the repo and build locally they will get fixed versions that
might include vulnerabilities. You'll want to put that into NPM language
but I hope you get the idea.
My impression is that this should be something that is known and
understood by developers working with NPM but I don't think there is any
harm in explicitly documenting it.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
