Hi Bryan,
*TL;DR*: Don’t cut new ASF releases just to bump dependencies unless we
ship them. Instead, document clearly when dependency updates are safe or
when reported vulnerabilities are non-exploitable.
On 1.11.2025 10:55, Bryan Ellis wrote:
> Any thoughts on deleting the package-lock.json during the preparation of
> the release package, so that it's not included in the source code package?
>From what I can see, the Cordova source archives on downloads.apache.org
don’t actually include a `package-lock.json`. Am I missing something?
> The main concern is that if it stays in the package and contains a pinned
> vulnerable sub-dependency, we'd need to address that issue as soon as
> possible. Meanwhile, for end-users who would install the package through
> the npm registry (the preferred method) would have received the patched
> sub-dependency would already have been patched. In this case, the current
> published package would have zero vulnerabilities as there was no lock file.
>
> Just to make note, for end-users that had already installed the package,
> they would need to run npm upgrade or possibly just reinstall the package.
>
> Preparing a new source code package would then require bumping the version
> number. But what's the point of publishing a new version to the npm
> registry if it only includes a version bump and no actual code changes? Not
> saying this is the case all the time but there are cases where packages are
> pretty stable and do not actively receive any code changes to promote a
> release.
I agree it makes little sense to issue a new ASF release *just* because
a dependency was flagged by Dependabot. For npm consumers the fix
arrives automatically, and while Maven users don’t get that convenience,
they can still upgrade the dependency on their side without waiting for us.
In my view, the major package ecosystems (Maven, npm, PyPI) were
designed primarily to resolve *compatible* dependencies, with *security*
considerations added later as an afterthought. As a result, we end up
with two opposite but equally problematic extremes:
- Maven is often criticized for its use of “pinned” (more accurately,
recommended [1]) versions, which can lead to shipping known
vulnerabilities.
- npm and PyPI, on the other hand, prioritize rapid updates, which
enables quick patching, but also allows malicious packages to spread
just as quickly.
That’s why I like the direction Jarek described: have a file/list that
*isn’t* committed to the package repository (but can be audited) and
that you can update *whenever* a dependency CVE appears, without redoing
the whole ASF release. That gives us a place to say:
“we tested dependency X at version Y and it’s OK.”
What I think we’re missing, and what your mail is really pointing at, is
the ability to distinguish three different “versions” for a dependency
(assuming semver-ish deps):
1. Baseline version (API floor)
- This is the oldest version we promise we still work with.
- Some users can’t jump to “latest” because of environment
constraints.
- In Maven this is often what we put for “provided” deps in the POM.
- Raising this in PyPI (`>=x.y.z`) can lock such users out.
2. Recommended / release-tested version
- That’s the version we actually ran the release tests against.
- It’s safe *today*, but it can become “CVE-noisy” with time.
- In Java/Maven this ends up as “the” version if there is no conflict
resolution.
3. Latest tested version
- Every time Dependabot opens a PR, we *could* test the newer dep and
mark it “known good.”
- Right now we have no good, public way to publish that without
cutting a new release, which is overkill.
I had a related discussion this week with the Solr developers [2] about
the misaligned expectations between library and application maintainers
when dealing with vulnerable dependencies:
- My view as a library maintainer: “I won’t cut a new release just to
bump a dependency; application developers can override it themselves”.
- Application maintainers’ view: “Please bump it in the library first so
*you* confirm it doesn’t introduce bugs”.
As a result, both sides often wait for the other to act, and no one
releases an update unless it’s a major incident like Log4Shell, leaving
end users potentially exposed.
Piotr
[1] In Maven they are not really hard-pinned: consumers can still
override them, and ranges exist, they’re just rarely used.
[2] https://the-asf.slack.com/archives/CEKUCUNE9/p1761901493592529
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
