A malicious audit assertion is grounds to consider the package malicious. Thus you just mark the parent package as malicious.
Edit: I think your misunderstanding is you're considering "malicious config" and "malicious code" significantly different issues, and arguing malicious config won't be noticed as malicious because it's only malicious in the context of what it enables. I believe this is incorrect. Innocuous seeming usage of a legitimate feature that actually has malicious effect is not a new issue.
Looking at the issue in more detail you were told essentially exactly this.
> A far, far easier version that already exists is: put malicious code directly into an otherwise innocuous package (or as a dependency). No vulnerability warning would exist, and thus there'd be no need for assertions. In other words, your "exploit" is just a more complex way of doing something that has always been possible.
> Once you've trusted a maintainer, you have already completely surrendered any protections to their judgement. If they make a mistake with an assertion, they could also make a mistake with code, or by depending on a package with an unknown vulnerability. Similarly, if they're malicious, they already own you because you depend on their code. This RFC does not introduce any new problems or attack kinds - all it does is add another vector that is more complex and easier to fix than existing ones.
Edit2: Another way of saying it is you're essentially arguing "this feature means that given sufficient control of a popular package to make innocuous seeming but actually malicious changes essentially any compromise is possible", and the proponents of this feature are saying there are already so many ways for that level of access to be exploited this makes no difference.
I don’t regret linking the issue, I hope someone who isn’t going to be as emotionally impacted by it will recognize the risks it introduces. But I regret the energy I’ve spent even trying to get past my own physical pain from nearly two years of burnout being dismissed this way even as I’ve tried to discuss the problem in good faith.
I don’t have energy for this. You, like the people in the issue, are welcome to explain away the similarities between different attack vectors and refuse to imagine how this might present different opportunities. I frankly can’t engage in it anymore. The link is there for people who can.
Is the concern that it will encourage library maintainers to do essentially something analogous to an empty catch block to make the error go away without having to think too hard?
try:
use_thirdparty_library()
except SecurityIssues:
# Make error go away. It's probably fine.
pass
This would then hide the problem instead of letting it noisily bubble up the stack.
One way to view it is that someone writes a package that their expected usage is as a build tool. It uses a library that has a input validation vulnerability. Since they view their tool as build tooling they mark their package as not impacted. Npm audit no longer shows the vulnerability.
Someone uses that build tool in a production system in a way the maintainer never even considered.
Npm audit shows nothing to that end user. They are vulnerable.
People will say they misused the tool. But either way, shit gets compromised and it is something could have been prevented if you take the stance that the end user was paying attention to audit findings.
And yes, many corporations and govt agencies take audit findings seriously. Hiding this because a maintainer said not impacted is scary IMO
Edit: I think your misunderstanding is you're considering "malicious config" and "malicious code" significantly different issues, and arguing malicious config won't be noticed as malicious because it's only malicious in the context of what it enables. I believe this is incorrect. Innocuous seeming usage of a legitimate feature that actually has malicious effect is not a new issue.
Looking at the issue in more detail you were told essentially exactly this.
> A far, far easier version that already exists is: put malicious code directly into an otherwise innocuous package (or as a dependency). No vulnerability warning would exist, and thus there'd be no need for assertions. In other words, your "exploit" is just a more complex way of doing something that has always been possible.
> Once you've trusted a maintainer, you have already completely surrendered any protections to their judgement. If they make a mistake with an assertion, they could also make a mistake with code, or by depending on a package with an unknown vulnerability. Similarly, if they're malicious, they already own you because you depend on their code. This RFC does not introduce any new problems or attack kinds - all it does is add another vector that is more complex and easier to fix than existing ones.
Edit2: Another way of saying it is you're essentially arguing "this feature means that given sufficient control of a popular package to make innocuous seeming but actually malicious changes essentially any compromise is possible", and the proponents of this feature are saying there are already so many ways for that level of access to be exploited this makes no difference.