Yes, if you attack infrastructure that you do not have permission to test. Here people downloaded code, ran it on their own infrastructure (or worse: shipped it to their users!) and were surprised this code did not do what they expected.
So, the only malicious actors here are those who shipped the package to their end users. Not the developer, they did not ship the code to anyone. They simply released a new version that other people chose to download and include in their own work.
To be clear, it's a total dick move and I don't support it at all, but the real blame should go to those who blindly download such code and run or redistribute it.
If you choose to download my code and include it in your project and it doesn't do what you expect, that is on you.
The colors library has an infinite loop and you shipped that version to your end users? That's on you. Test and pin your dependencies. Not doing so is the true offense. Be upset with AWS and the likes who will run unvetted third party code on your machine.
Also note that an infinite loop is not malware. Implying such is insane. Are you now going to call every piece of crashing software malware?
> People didn't actively go seek out a new version.
They did. They chose not to pin their dependency versions, so this is their clear explicit choice. They also chose not to test their dependency updates before pushing it through to their end users, pure negligence by e.g. AWS who was affected by this.
No, that is madness. A new developer clones the repo and gets wildly different dependency versions than the previous devs tested with. Then once you PR your changes, you include that lockfile and production explodes. Insane. And yes, this is a real problem. See the thread we're posting in and how many projects it affected.
Tell them about requirements.txt, pip freeze & virtualenv. You can also curl | bash but that doesn't mean bash is to blame, because it doesn't encourage this bad behavior. NPM is literally built around this broken behavior.
I've had smart lights for a few years now, and I'm pretty happy with them. I can turn them off remotely, dim them as a group and change them to a soft red at night to not blind myself.
Of course this quickly escalated to maintaining a full blown Home Assistant installation...
Yes, if you attack infrastructure that you do not have permission to test. Here people downloaded code, ran it on their own infrastructure (or worse: shipped it to their users!) and were surprised this code did not do what they expected.
So, the only malicious actors here are those who shipped the package to their end users. Not the developer, they did not ship the code to anyone. They simply released a new version that other people chose to download and include in their own work.
To be clear, it's a total dick move and I don't support it at all, but the real blame should go to those who blindly download such code and run or redistribute it.