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. 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? 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?
