* npm allows a module to be deleted
so all fetches of published name-oldversion fail
* npm allows you to take-over the name of a deleted module
and publish name-newversion
* npm does not allow you to "re-publish" name-oldversion
which had existed before the deletion
but npm ops forced this publish for your special case
For the record they made sure the exact same code was published to 0.0.3 so that I didn't maliciously inject anything. I control subsequent versions though.
You meet someone at a conference and the next conference he shows up again and you should know right away he's not actually somebody else.
Since old code is under a very permissive license, then the new owner could create v0.0.4 add code and make the new version closed with a restrictive license.
This is where a license like GPL would benefit overall, since all future code requires to be under the same license.
Either way, it seems like a dangerous policy to allow someone to re-own a previous owned and published module. Licensing is not the real threat but malicious code that potentially could be deployed.
The WTFPL licensing comes from the package.json file, which is in the GitHub repo.
I guess this is why debian takes licenses so serious.
And vast numbers of people are suddenly shocked (shocked!) to realize there's no mechanical verification of stuff like this. It can all happen whimsically, and the result isn't just a loss of service, it's service with different results and no verification nor notice.
From this thread it sounds like: a) npm specifically overrode their normal process to allow him to publish new code at the same version number b) npm did verify that the code he was publishing was the same as the old code at that version number as part of this.
So sounds like immutability of specific versions is systematically enforced by npm?
There's a difference between trusting a server to do something, and having the software you're using check that the server hasn't changed its behaviors in ways that may... fuck with the continuity of your zen.
If someone can decide to do a special thing that happens to break all promises, and my side of the tooling doesn't let me know, much less let me confirm acceptance of the changes, then my side of the tooling is seriously deficient.
And in a situation where this tooling then starts executing new code from a new author on my host as my user without any authentication except "trust the server"... the same behavior describes $script_kiddie_virus_of_the_week! "download code from C&C server; run it, thanks:D" What's the difference between this and outright RCE exploit? "good intentions"?
I'd rather have something more than "good intentions" controlling what code ends up running on my computer, thanks.