Dependabot first reported and then retracted a security problem in a package. The basis of the retraction isn't given, just that the package "is no longer vulnerable." That makes no sense. The original CVE is still out there and the affected code is still referenced.
On investigation I find that the given package is in yarn.lock twice, once in a version that contains the vulnerability and later in a version that contains the patch:
ansi-regex#^2.0.0:
version "2.1.1"
ansi-regex#^5.0.0:
version "5.0.0"````
I'd be grateful for any way to make sense of this.
If you landed on this question due to your own "no longer vulnerable" error in a different package: you may still be vulnerable.
According to one of the Dependabot maintainers, the (suspected) most common cause of "no longer vulnerable" is when you are using multiple versions of the same dependency, and one of them is vulnerable, but not the lowest version. The maintainer's post says, in part:
Here's my current understanding:
The alerts are triggered by manifest parsing code that is a separate code path from dependabot-core's parsing code. So if the
alert manifest parsing code thinks the repo is still vulnerable, the
alert will persist.
npm allows multiple versions of a dependency in the dep tree... and these are used in the code at runtime... the newest is not
superseding the old one. So if those exist, you're still vulnerable.
dependabot-core has a known bug where it only updates the lowest version of a dependency... so Dependabot may try to create a PR, then
report that npm is no longer vulnerable, when in fact a later version
of the dependency is vulnerable and is still in the tree. That's
tracked in npm erroneously reports no longer vulnerable with multiple versions of dependency. #5741
The alerts are generated based on information in the GitHub advisory database. So if that database lists all versions > 0.16.5 are
vulnerable, but the maintaner just pushed v0.17.0 which fixes the
issue, then the alert will not disappear until the advisory database
is updated. Thankfully, you can submit a PR to the advisory DB to fix
an incorrect version specifier.
So I suspect that the majority of these cases are symptoms of #5741.
Dependabot issue #5741 says:
when there is a vulnerability that affects some versions of the dependency but not the lowest version. In this case Dependabot incorrectly reports that no security update is needed.
If this source is accurate, it's because the two ansi-regex versions you've listed do not contain the vulnerability:
Confirmed 4.1.0 and 3.0.0 as affected testing using the provided reproducer. 2.1.1 does not reproduce the issue.
3.0.0 is the first affected, as that's the first version that includes 69bebf6 that the problematic part of the regex.
Thanks to answerers for your expertise.
I think the most likely diagnosis is a Dependabot bug. Generally it is wishful thinking to blame your tools but in this case it is the simplest answer by far.
Related
What is the policy when one enforces a newer (Node.js) engine version?
Is it semver MAJOR or semver MINOR?
Context: I'm the author of a package with 2k stars on github (30k downloads per week) and I recently enforced Node.js v14 (because I'm starting to use optional chaining and null coalescing everywhere), and made it a new MINOR version.
But some of my users are complaining and asking me to make that change a new MAJOR version.
Also previously, nobody complained when I enforced Node.js v10 on a MINOR version.
I can't find any resource about that matter, even the semver spec does not specify this (not even in the FAQ section). The spec only talks about the API.
I want to keep my project in line with the correct policy.
Quoting Isaacs from Twitter (#izs), author of the semver npm package (and by the way founder of npm):
I've always considered SemVer Major to mean "you will have to change something on your end to start using this update".
If the previous version worked on platform version X, and the new version requires platform version X+n, then that qualifies, yes.
This has been discussed here in many threads as well SemVer discusions. Some claim it is subjective, but I think if you were to replace the opinionated terms (API, Package, Product) with something like OBV (Object Being Versioned), you will see that spec and most of the knowledgeable participants agree with each other.
If your customer's build environment is broken because you issued a minor or patch release, they have every right to complain. The SemVer spec really focuses more on API versioning, than packages, though it does mention the later in a few places. So the key here is, most of us never actually version just an API, we version packages and the manifests within them, which also implicitly/explicitly include transitive dependencies.
The whole point of SemVer is to communicate risks to consumers of those OBV's. As a publisher, you are responsible for the entire dependency tree that you include in your OBV's. You can chose whether to implicitly or explicitly introduce a breaking transitive dependency into your OBV, therefore it is your responsibility to inform your customers of the risk by bumping the major version.
Which is the best practice while saving package.json dependencies?
For example, i see that lot's of dependencies are not fixed, like:
"tslint": "~5.11.0"
I would like to have fixed dependencies, so that will not change in the future when new developers join a team.
I have little knowledge about package-lock.json and shrinkwrap, but I'm not sure about the "best practice" on this.
On this case is an Angular app, but it can be everything. Keeping for example package-lock.json on the repo caused some issues in the past (i know! it is a best practice to push it!)
Any thoughts?
Short answer: Carets (^) and committing your package-lock.json is probably your best approach. This ensures developers always get the same dependencies, and is the least surprising.
Why package-lock.json?
npm specifically recommends you commit your package-lock.json.
It is highly recommended you commit the generated package lock to source control: this will allow anyone else on your team, your deployments, your CI/continuous integration, and anyone else who runs npm install in your package source to get the exact same dependency tree that you were developing on.
(from the npm documentation)
You mentioned pushing package-lock.json to your repository caused some issues in the past. I'm guessing this was due to this issue where the package lock was being ignored and rewritten every time anyone installed anything. This was not the correct behaviour and was fixed in npm#5.4.2, according to this answer.
What you should not do is leave out the package-lock.json and just specify exact versions in your package.json. If you do this, your top level dependencies will look nice and consistent, but their dependencies won't have locked down versions. This way, you're almost as likely to run into bugs, but they'll be harder to find.
Why not npm-shrinkwrap.json?
You also mention shrinkwrap files. Shrinkwrap files are meant for
applications deployed through the publishing process on the registry
(from the npm documentation)
You probably aren't npm publishing your angular webapp, so there's no reason to use npm-shrinkwrap.json.
Why use caret ranges?
I can't find any documentation saying caret (^) ranges are best practice, but I believe they are.
npm makes caret ranges the default option, so it's clear they think this is best practice, though I can't find any of their documentation to justify it.
Using the default is the least surprising approach. If I saw any other kind of version in a package.json, I'd assume it was changed for a good reason, and would be hesitant to update the package without knowing what that reason is, even if it really needed to be updated.
If you ever decide to update all your dependencies at once, caret ranges will serve you well. You're dependencies will normally be locked, but deleting your package-lock.json and rerunning npm install will automatically install the latest versions that are supposedly backwards compatible with the versions you specified (see the npm docs for details on the caret range).
In summary, it's standard to use caret ranges and a package-lock.json. This fulfills your requirement of fixed dependencies, and provides a few other benefits, so it's best to do what's standard, unless you find another reason to change.
On the website of Debian, it's written about point releases:
They usually incorporate the security fixes released until the time of
the update and fixes for grave bugs in the current release.
If I correctly understand, that means only minor updates can occur in the packages of the current stable version, right?
In other words, I want to know if a binary who depends of a library in a specific version (libmicrohttpd.so.12 for instance) will stay compatible in the next point releases of Debian.
Yes, but it is very seldom.
In general you are right, the point releases should not change existing API and ABI.
But there could be problems on doing that: security changes would require a lot of work, and upstream will do only for the new version. In such cases the version will be dump. But this is very seldom: it would need a security bug which effect the fundamental design of a library (not just some coding error).
In any case the old version will remain on archives, and you can keep it (so that it would not be automatically removed), so that you can still use, hopefully with relevant safe guard.
We have a node.js project, and we want to start managing its dependencies using npm's package.json with specified versions for each dependency.
However, we are afraid that one of the packages our project depends on might get unpublished. Should I worry about unpublishing or is it a rare occurrence? What is the most effective way to handle this kind of problems?
It is very rare occurence. Never happened to me.
Unpublish is mostly used to remove a published version in which a major bug is reported. Thus, automatic semantic versioning upgrade will not fetch this version until a new one is published.
When browsing the packagist.org repositories you see packages with these version numbers e.g. If you look at the Phpunit repo
There are a few instances
4.5.x-dev
4.3.x-dev
4.2.x-dev
Do these packages contain the current work the developers are performing towards basic updates, security and bugfixes etc on an otherwise basically stable package?
These are the dev branches. These are unstable and contain bug fixes, etc. This will eventually be released as 4.5.8 for instance (if the library is still supported).
You can get it by using 4.5.x-dev or 4.5.*#dev as version constraint.