ulisesgascon / browser-redirect Goto Github PK

However, none of the tips you give would actually work.

This is analogous to a well reputed developer working for an interesting organization going rogue by pushing wrong/bad code to npm directly.

So the tips:

• Use well-known and well-maintained libraries - will not work. Some times we need a simple browser redirect library that can be fresh in the market
• Get involved in the community and help the maintainers by contributing code or financially supporting projects and their maintainers - Great. But how is this a security fix for a malicious package?
• Use NQP to help you evaluate any new packages for your project - advert!
• Use Snyk to keep up to date with new vulnerabilities and monitor your projects - Sorry won't help. No dependency scanner can magically find flaws in a legit sounding package. No we can't do credit checks on the reputability of every single developer.
• Review the code of your dependencies from npm and not just form GitHub, Bitbucket or other version control systems - yes kinda. But if people have time to do this they don't need any scanning products

My free million dollar tip:

What we need is a concept of reproducible builds for nodejs, python and other languages. npm and other public repositories should flag down packages that cannot be built from source to produce a hash that matches the binary. There should be an arg on npm/pip/conda install to either install from source or install only packages that are reproducible.

Thanks for the blog post! However, I was wondering why go for a more descriptive name for the package like browser-redirect-do-not-install or browser-redirect-malicious-example, to significantly reduce the chances of unwanted installs and free the name space? Similarly to how dangerouslySetInnerHTML is intentionally verbose and obvious.