Suggest ignoring a vulnerability by the package maintainer

[naugtur]

In a discussion of this: npm/rfcs#18
@wesleytodd suggested I bring it up here to collect feedback on the feature itself, but mostly to ask one thing:

If this can be leveraged for the package maintainers to declare a vulnerability in their own dependency does not affect the security of the package. And if so - how would you want to indicate that as opposed to ignoring the issue for your internal needs of stopping the CI from failing while there's no fix to update to.

[MarcinHoppe]

I think this would be a very useful option to have to increase the signal to noise ratio for vulnerability reports.

[naugtur]

Any thoughts on how to do it?
I see two options

• special option in audit-resolve file
• a field in package.json

Second option has the appeal of it being crawled by package managers when creating the lock file anyway, so the info could be pulled from there.

[ljharb]

I’ve suggested this to npm many times; the challenge/pushback I’ve heard is that, how would you stop a malicious maintainer from hiding a cve report for the purposes of leaving users vulnerable?

[MarcinHoppe]

Malicious maintainer has more direct opportunities for embedding malware in their package, IMO.

[naugtur]

And these would not be ignored by default but provides as hint for decision making.
Just a field on audit output.

[mhdawson]

Sounds like a good idea. I saw a tweet today from @lirantal mentioning that Snyk is doing something to try an figure that out automatically.

One way I could see that fitting with that suggestion is that a maintainer could use the info from Synck to populate the data that needs to be provided so that all users of the module benefit.

[wesleytodd]

how would you stop a malicious maintainer from hiding a cve report for the purposes of leaving users vulnerable?

Maybe the question should be phrased as "lazy maintainer". I fully agree that if you have a malicious maintainer you are owned already, but what incentivizes a lazy maintainer to not just ignore all at their level?

That said, I think optimizing for this behavior means we might miss out on the more impactful feature here, which will save "good" maintainers from this burden they have today. So I don't think the answer to this question should block anything as long as we are not making the situation worse.

---

So the format I think this should move forward is as a spec for the json file. I think the implementation of it in npm will be awesome, but to get broad adoption and enable other tooling ecosystems (yarn, snyk, etc) to build on it we would want an official spec to live somewhere. I think this group is a find place for that to live if @naugtur agrees.

[ljharb]

However, if npm and github (the tools who we'd need to respect this ignore setting) don't consider that a worthy tradeoff, then it's not really up to us :-/

[naugtur]

There was a suggestion on today's RFC meeting to donate the package for embedders with the JSON schema within to an org. I'm on board with that.

If there's a place to put the tiny schema for the file, I'd love to do it.
Being in control of it was fun and all, but that's not the point.
Looking forward to suggestions.

[naugtur]

However, if npm and github (the tools who we'd need to respect this ignore setting) don't consider that a worthy tradeoff, then it's not really up to us :-/

It's up to us to come up with something for them to consider and I believe it's likely to succeed coming from the fine folks here ;)

[ljharb]

I certainly hope so; however the reasons I explained are why npm has said no to me on multiple occasions for this very request, so I'm not sure why they'd have a different opinion now.

[naugtur]

Both the people involved and the NPM Inc. are different. If we come up with something reasonable, I'm pretty sure it'll get introduced into audit.

There's also an idea in the RFCs to audit licenses, which will require going to package.jsons in the tree and checking something, I think gathering vulnerability resolution recommendations should be doable in the same pass.

[ljharb]

npm, inc. has 100% full control over npm audit, so i'm not sure what you mean.

We can try to persuade, and we should, but it's entirely their decision.

[naugtur]

I never said we're the decision makers here. It's not something that'd stop me.
I came here to collect some opinions on what'd work and maybe put some of it in my RFC that's older than my now fluently speaking kid. I'm doing it in my rare spare time. I've got other unusual hobbies too 😉

Would you mind sharing the details of what you proposed before and what you think about it nowadays?