> Such 'nagging donation requests' were banned by npm pretty much days after they first appeared, IIRC, What does "banned by npm" mean? Here's an example from

> Such 'nagging donation requests' were banned by npm pretty much days after they first appeared, IIRC, What does "banned by npm" mean? Here's an example from the source of the latest version of nodemailer (with 1.4M weekly downloads) sleeping for 4,100 ms on every install so that it can show a "Sponsor us to remove this lag" message: https://github.com/nodemailer/nodemailer/blob/a455716a22d22f80e1ffdfd7171e92123ab38cc8/postinstall.js#L96-L101 https://github.com/nodemailer/nodemailer/blob/a455716a22d22f... > and npm itself is literally a tool for installing code to execute later, so there's no security issue here. If someone wanted to embed malware into a package, they wouldn't need postinstall scripts for it. It's fine to have a standard mechanism for postinstall steps. It should be opt-in by the end user rather than opt-out. That way people know that they're running additional code and ideally selectively pick which packages are allowed to do so. The vast majority of packages do not need it anyway as they do not have C++ bindings or need to generate data. The defaults for NPM are such that you have to know quite a bit of how NPM works to download a package and inspect the contents without executing random code. > This is really a complete nothingburger. It's defensive in depth. With the default being to execute remote code, a single typo could be installing a package that immediately runs malware.