No software can be trusted
Open source can be maliciously modified.
Closed source can have malicious intent built in.
There is no such thing as trustworthy code.
So the facts are that the package was changed to break if the diva's installer was not the one used. Maybe the diva did it, maybe his account got hacked.
I have my opinion on that, but let me just ask why someone would hack an account and modify it to break only if a different installer was used ? I'm guessing that if a hacker was intent on wreaking havoc, he'd want it to break whatever installer was used.
Okay, I get that you pour hours and days into something and you get attached to your project, but this kind of behavior is puerile and seriously lacks of professionalism. Either you accept to transfer ownership and then get over it, or you refuse and accept the consequences.
Accepting to relinquish control and then throwing a fit is just childish.
The lack of other elements in this 'hack' makes it look very much like a 'FU'. How Watanabe can deny the clear implication is beyond me, even if he is innocent he must acknowledge how it looks objectively? Flat denial just makes it look even more dubious, after all it's his reputation on the line, you'd think he would be doing his best to identify the real source (assuming he isn't) rather than just protesting his innocence.
It sounds like instead of creating their own, better installer, the Purescript people decided to compel the owner of the existing one to give up control. This sounds like a dick move, to be honest. Making the installer not work was also a dick move. Neither party comes out of this looking good, from my reading of this article.
We've also asked NPM to elaborate on whether it has any investigated the incident or taken any action against Watanabe based on these allegations. No word yet.
Aren't they too busy taking legal action against their own employees?
1) Write open-source, cloud-hosted module which does something useful
2) Go work for Company X. Hook their system into your module
3) Leave the company
4) Use your insider knowledge to update your library so that it will perform $dodgy_thing when it's ran by company X
5) Wait for them to pull down the new version of your library
After all, the odds that the company is going to be diligent enough to review all the third-party open-source code it pulls in is pretty minimal! Though to be fair, there's other ways to mitigate this, such as ensuring that all modules should be set to a specific version.
Also, there's the hope that someone in the Open Source community will spot that there's something dodgy in the code.
But for every project which has tens or hundreds of eyeballs on it, there's thousands which have a single contributer. And as we've seen numerous times, things like this are often only caught after the horse has already left the stable!
Also Harry is a really great guy.
Biting the hand that feeds IT © 1998–2020