News for hackers. Stuff that matters.
Re:What NPM should do to stop a new colors attack by sam0x17 on Monday January 10, 2022 @09:10PM (#29886338)
> The project's author committed a change to his own open source project, which he had every right to do.

Indeed, and it goes beyond this. I think the real implication is that software published on NPM and similar networks isn't truly free and open source, in the sense that the platform owner can and will step in and make editorial changes without the knowledge or consent of the software maintainers.

Re:What NPM should do to stop a new colors attack by kristjansson on Monday January 10, 2022 @11:11PM (#29887432)
Sure, he’s free to make new versions of it that do whatever he wants - spam zalgo, mine bitcoin, fire the mussels, whatever. That doesn’t obligate anyone to _use_ that code, nor does it obligate NPM or anyone to distribute it.
Re:What NPM should do to stop a new colors attack by sam0x17 on Friday January 14, 2022 @12:15PM (#29937133)
Nor does it give NPM permission to tamper with his code and pretend it was he who published it. I firmly believe what they did is in violation of the underlying open source license, and if it isn't, the major licenses should be updated to account for this concerning scenario.
Re:What NPM should do to stop a new colors attack by spankalee on Monday January 10, 2022 @09:40PM (#29886648)
What changes did they make to the code?

None as far as I can see.

Re:What NPM should do to stop a new colors attack by sam0x17 on Tuesday January 11, 2022 @01:23PM (#29895465)
The maintainer's intended release was text spamming the console. They replaced it with the old faker. This is changing the maintainer's code.
Re:What NPM should do to stop a new colors attack by Macha on Tuesday January 11, 2022 @02:10PM (#29896212)
> https://github.com/Marak/colors.js/blob/5152d16f22789d66e107...

So can you point me to where this license says you cannot modify this code? Or that by accepting distribution of one version of this code, you are obligated to distribute future versions?

You can't hide behind "The license doesn't say he has to play nice, so you can't complain about him not playing nice", then say it's unfair that npm don't go behind their license and TOS obligations to host his spite version.

Re:What NPM should do to stop a new colors attack by sam0x17 on Tuesday January 11, 2022 @04:00PM (#29897801)
Because they are interfering with _his_ distribution of the code. They are free to distribute it separately and make changes in those cases, but instead they are essentially re-writing history without the knowledge of the package owner, and for reasons that are largely editorial and, I think, unprecedented. They are interfering with his right to distribution, essentially. I know that in a slimy, technical way, you are correct, but I think it is relevant if at the end of the day it is practically impossible to distribute code without some unauthorized third party modifying it in transit, essentially. The implication is we need to start running our own git servers.
Re:What NPM should do to stop a new colors attack by Macha on Tuesday January 11, 2022 @05:13PM (#29898884)
I feel that replacing a package with one that doesn't fulfil the same needs in a patch update because you feel that "no warranty implied" justified it is as much "slimy, technical" use of that license.

Again, if Marak is going to rely on technicalities, I don't blame npm for treating him with as much good faith as he treated his users.

Re:What NPM should do to stop a new colors attack by spankalee on Tuesday January 11, 2022 @03:07PM (#29897080)
They changed the package metadata only by setting `latest` to point to the last non-malicious version.

Can you actually point to any code - or any package contents at all - that they changed?