David tells dependency is insecure. Is this a bug, or am I wrong?

[dkern]

I have an issue with one of my repos. The badge shows insecure dependencies and this belongs to jQuery, as the detail page of david told me (and as this is the only dependency too).

https://david-dm.org/eisbehr-/jquery.lazy

The plugin depends on any version greater or equal than 1.7.2. This is simply to keep the range as wide as possible, even for very old projects, like some IE stuff some companies has still live.

My question is simply, why is my dependency unsecure? On a new install, the most common version 3.2.1 would be picked, what is secure. In my eyes this is a wrong message / badge here. I don't depend on 1.7.2 directly, I depend on everything above too. On a normal install the latest version would be picked.

Can someone tell me the problem?

[alanshaw]

Your range includes vulnerable versions.

People may have installed your module long ago and by virtue they may have installed a vulnerable version of jquery. Updating the version you depend on to not include a vulnerable version of jquery will force npm to install a version that isn't vulnerable rather than leaving the existing vulnerable version because it satisfies your range.

[ncoden]

@alanshaw What about lockfiles ? If a lockfile is provided and the latest jQuery version is pined in it, users with a vulnerable jQuery version will get it updated.

A package may be compatible with a large jQuery version range and package.json should only reflect this, letting the user to choose the actual version according to their use case. A lot of vulnerabilities are only relevant some particular cases and can be safely ignored.

[dkern]

A package may be compatible with a large jQuery version range and package.json should only reflect this

Yes, exactly this is my problem too! Nice idea.

[blgm]

@ncoden, unfortunately a package-lock.json file applies only to the top level package, The lockfile is ignored when installing modules from npm. So if the package-lock.json only has secure versions, a user of that package does not benefit. https://docs.npmjs.com/files/package-lock.json#description

[dkern]

As far as I undestand his suggestions, thats not the point. Davaid should just look to the package-lock.json in a project, if it uses secure deps or not. Because in the package.json the developers need to tell with what versions this project will work at least, but that has nothing to do with security. So @ncoden just suggested a way we could work around this ...

[alanshaw]

I'm not sure I understand how this would work - could you provide some examples?

Specifically, I don't understand why you wouldn't just update the version in your package.json.

[dkern]

The package.json only specifies the versions a module is compatible with. And that can be a very wide range. It has nothing to do with security issues. You have a package that works with jQuery 1.0.0 an up, then you tell it's working with this version.

The problem here is, that David forces the devs to put the version as high as possible in the package.json to be not shown as insecure. But that is not a good choice, because our module would be incompatible to others then.

For example, we have this two modules in a random project:

• moduleA is compatible to jQuery >= 1.7
• moduleB is compatible to jQuery >= 2.1 <= 2.9

Then NPM would probably pick a Version of jQuery 2.9.X for both. But now the dev of moduleA pushes the version to max, because he don't want to be insecure:

• moduleA is compatible to jQuery ~= 3.3.1
• moduleB is compatible to jQuery >= 2.1 <= 2.9

Now NPM can't pick a compatible version for both. The two modules are incompatible in this project. But that's not true, because moduleA would be compatible down to jQuery 1.7.

Maybe moduleB should be marked as insecure, because this package.json limits the max version to 2.9, what could possible be a risk. But not a open version declaration, like greater than 1.7.

I hope you understand my point, it's a bit tricky to explain for me. ;)

[blgm]

Would a peer dependency be an option?

[dkern]

Depends on the module, I think. For some, yes. But for frontend modules, this would not always be an option, imo. Because you wound inject multiple copies of, for example, jQuery to your page. Or didn't I get the point?!

[blgm]

If jQuery were a peer dependency of your module, then users would have to install it independently (it would not be automatically installed when your module is installed). Because David-dm does not check that peer dependencies are up to date, your badge would go green.

I realise this is a tradeoff because it changes the contract with your users. But perhaps a peer dependency is a better description of the relationship with jQuery?