package unrightfully marked as malware

[tlouisse]

Hi there,

An npm package called 'ing-web' is unrightfully marked as malware: GHSA-5fx7-hqw3-mg99
However, the malicious code is already removed from the registry for a long time: https://www.npmjs.com/package/ing-web

Can this please be updated?

Thanks in advance!

[shelbyc]

Hi @tlouisse, ing-web was removed from npmjs.com and a security package put in its place to prevent accidental downloading of malware. The removal of the malware from npmjs.com and replacement with a security package doesn't prompt a withdrawal or removal of the advisory. Are there any factors that lead you to believe GHSA-5fx7-hqw3-mg99 should no longer issue alerts about ing-web?

[tlouisse]

So this advisory is there to prevent people from downloading a malicious package from npm, I suppose? It seems like it's not possible anymore to get malicious content via ing-web because of the measures npm took (removing it and putting a security package in place).

GHSA-5fx7-hqw3-mg99 now says:

• Improvements are not currently accepted on this advisory because this package is malware and has no patched versions. If there is something to change, please open an issue at => it has patched versions as it's removed/replaced
• Affected versions: >= 0 => there are no affected versions?

In our company, we have ing-web in an internal npm feed, but GHSA-5fx7-hqw3-mg99 gives a lot of confusing false positives, because our security tools also depend on github reports.

[ljharb]

Your internal packages should be only behind a scope, one you own publicly - that's the proper solution here.

[tlouisse]

Ah, thanks. We thought about that indeed. I hope we can solve it without doing breaking changes, though. It's a package with a lot of consumers and a huge migration cost. That means a lot of false positives for the foreseeable future until everyone has migrated.

Would it also be possible to ask ownership from npm and release something (0.0.1 or smth) that would be considered safe?

[ljharb]

There is approximately zero chance of them doing that :-)

Changing a package name with no other code changes shouldn't be that disruptive.

[tlouisse]

There is approximately zero chance of them doing that :-)

Changing a package name with no other code changes shouldn't be that disruptive.

On a project level it is not disruptive, but on a full software landscape (around ~2000 dependents that we want to properly dedupe for performance) including all documentation referring to it, it's not completely trivial...

But thanks, if this is our only option, it's worth considering :)

[ljharb]

It's a critical task to prevent supply chain attacks - for any internal packages you have - so I hope you're able to roadmap it.

[tlouisse]

Thanks, but my line of reasoning was that the supply chain attacks are prevented by the fact that npm owns the package now and took security measures. Hence I don't understand why it's not possible to update the status of GHSA-5fx7-hqw3-mg99 (I assume this would have been withdrawn for the latest version of a package in case we owned the package on npm and released a security fix?)

[ljharb]

For that specific package, yes, but I mean in general, one should never have an internal package with a name that's publicly owned by somebody else.

[emr550m]

@ljharb @shelbyc Thanks for your support on this. I am the Product Manager for Design System of ING , the topic that we are discussing is a subject that somebody try to harm our company before, it seems they knew what they are doing, they picked the same package and put a vırus on it. Anyway we took action and make npm folks block it.

Now github report gives a result for >= version alert which is not also correct, latest package on npm was neutralized by npm and it does not contain a virus any more. So github report is wrong and needs to be corrected. For older versions , yoy are right it should stay there for keeping people safe.

For current state it creates problem to a huge corporate since all off our security scans generates false positive result according to this incorrect versioning that contains all versions.

Can you help us at least not block all versions but only effected ones? It does not even needed to be accurate , we can block 0<>1 , since latest version on npm is safe technically it does not contain a virus.

According to version history 0.0.1-security version and later is safe.

I wish you a great day!

[leobalter]

Hi @emr550m @tlouisse,

I recommend submitting a name dispute so you may eventually re-use the package name, deprecate it, or unpublish it if criteria is properly satisfied.

Hi @tlouisse, ing-web was removed from npmjs.com and a security package put in its place to prevent accidental downloading of malware. The removal of the malware from npmjs.com and replacement with a security package doesn't prompt a withdrawal or removal of the advisory. (...)

I second @shelbyc's comment, the security advisory is used to inform and prevent download of said package.

As for now, we should maintain the package with the common security advisory as referred below without any expiration date, making the record persistent unless ownership is transferred for reasons such as name dispute.

This package contained malicious code and was removed from the registry by the npm security team. A placeholder was published to ensure users are not affected in the future.

Thanks for understanding!