Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Backdoor in event-stream library dependency

github.com

Post reply on HN
Print view View original

271–280 of 509 posts

Re: Backdoor in event-stream library dependency

#271

Post by perfunctory »

michaelmrose wrote: post #132
perfunctory wrote: post #96

Earlier quoted context omitted.

I don't even see any moral issues here. Is there any reason to believe the original author acted in bad faith? If you sell your used car and it gets used to rob a bank, did you act immorally?

If you run a business where you have convinced people to give you access to their house to do some chore and you sell your business and your copy of their keys to a criminal it could be morally problematic. A car is merely a fungible vehicle the customer would have been no better or worse off had the robber been driving a different car. This would be an apt analogy for just giving / selling a code base. Had it been d…

> sell your business and your copy of their keys to a criminal

This implies the seller _knows_ the one they are handing over the keys to is indeed a criminal. In that case it is certainly morally problematic.

I see your point but I still think calling the maintainer's behaviour immoral is going a bit too far. Perhaps careless. Or maybe naive. But not more than that.

Re: Backdoor in event-stream library dependency

#272

Post by always_good »

sorisos wrote: post #175
programmarchy wrote: post #123

Earlier quoted context omitted.

Dominic is wrong. If there's no authority, then there's nobody taking responsibility. This is a perfect example of how lack of organizational structure simply does not work in the real world. Dominic's other projects like scuttlebutt are likely doomed to fail as well because of his wrongheaded views about organization. For a successful counter-example, one can look at the well-structured, hierarchical organization be…

I would rather see it as if contributors gain _trust_ based on their contributions, which is not necessarily the same as authority.

If a contributor's end goal is to publish a backdoor, then making them wait 0 or 100 commits to the project before trusting them doesn't change the end result.

In fact, if you had the energy to do the attack at all here (which took some work), having to fake trustworthiness doesn't require much more effort. Just look like a super enthusiastic contributor, put work into the readme, bike-shed over some issues every month, and bam.

Re: Backdoor in event-stream library dependency

#273

Post by raesene9 »

jrochkind1 wrote: post #224
raesene9 wrote: post #179

Earlier quoted context omitted.

You honestly think that the author of software released as open source is going to be liable for vulnerabilities in that software ... really? If that were the case, you'd pretty much wipe out the software industry as it stands today :) I'd be very interested in case law where you can see the users of a service (which might not even disclose what software they use) are able to sue the author of a package used as part…

I'm pretty sure they'll be legally liable for intentionally inserted malicious code, no matter what the license text says. I'm not talking about the original maintainer (who didn't introduce malicious code intentionally), but the person he turned it over to (who seems to have). Legal liability and ethical responsibility are not always the same thing, although it's generally only the first that matters in court.

oh sure the criminal who put the backdoor in place, no-one's arguing his/her liability.

But the point that I was referring to is any suggestion that the repo. owner who handed it over could bear any liability for doing so, I'd suggest that's not probable/practicable.

Re: Backdoor in event-stream library dependency

#274

Post by slg »

jrochkind1 wrote: post #218
ryandrake wrote: post #118

Earlier quoted context omitted.

Why would someone update to a new version of a dependency if they don’t trust the new maintainer? Can’t you pin dependencies to a particular version with npm? In my world, you should have a really great reason to update a third party dependency—“there’s a new version” is not a sufficiently good reason.

> Why would someone update to a new version of a dependency if they don’t trust the new maintainer? They didn't know there was a new maintainer, let alone that they didn't trust them. > In my world, you should have a really great reason to update a third party dependency—“there’s a new version” is not a sufficiently good reason. Because new versions come out with bugfixes _and_ security patches all the time. In my wo…

Without locking in to a specific version you are trusting the maintainer in perpetuity. That trust extends to things like reviewing their own dependencies, reviewing pull requests, adding other maintainers, or just flat writing bad code. I don't blame the author any more in this instance than if any of those other possible examples occurred.

Security patches are part of my original point regarding why it is bad for a project to die. I have no data on this, but I have a feeling that there are a lot more unpatched security bugs in widely used dead projects than there are popular projects that are taken over by a malicious maintainer.

The simple fact of the matter is that you are responsible for all the open source code you run. If you allow the code to be updated automatically you are abdicating your responsibility to review that code as a trade for being relieved of the responsibility of keeping up to date with patches. You are the one liable when something goes wrong because you are the one who made that decision and misplaced that trust. That is an inherent agreement you make when you use open source code and is often spelled out explicitly in the license.

Re: Backdoor in event-stream library dependency

#275

Post by dmitriid »

raesene9 wrote: post #44
nmg wrote: post #34

Earlier quoted context omitted.

The author's stance is that because it was a volunteer effort, he bears no responsibility for transferring ownership to an unknown third party who wants to commandeer the code used by millions of people. I believe this is false. He also feels that there's nothing anyone can do about it except scramble to control the damage. I believe this is currently true.

You may not like it but from a license standpoint, I think you may be incorrect As quoted elsewhere in this thread " THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILIT…

This license is invalid in quite a few jurisdictions around the world.

Re: Backdoor in event-stream library dependency

#276

Post by koolba »

Is there a way to run npm and show what would be installed via an 'npm install' short of actually installing it? That combined with a diff tool against package-lock versions would limit the review list. AFAIK, the way it is now you can't tell if one thing changed or one thousand until after completed.

Re: Backdoor in event-stream library dependency

#277

Post by gkya »

joshmanders wrote: post #267
gkya wrote: post #264

Earlier quoted context omitted.

> Is it the Github-ization of package creation and maintenance? Is it the pervasiveness of left-pad style packages? Is it npm's governance? Is it the community's perspective and culture? A nasty combination of all of those, probably some more. I was very excited with Node.js when I first heard about it here on HN years ago. I enjoyed watching Dahl's presentation. But as soon as the crowd that went "it's JS, I can doc…

> I don't want to defend or encourage gatekeeping Goes on to defend and encourage gatekeeping.

Yes, that's what I do, and thats what the word "but" after the part you quoted indicates.

If gatekeeping is bad, not checking who's passing through those gates when they're wide open is worse.

Re: Backdoor in event-stream library dependency

#278

Post by btbuildem »

cellis wrote: post #246
ufmace wrote: post #240

Makes me wonder if there's a business opportunity. Make your own version of NPM, based off of the real NPM, but some level of auditing for package updates. Don't report suspicious commits from new contributors right away, that sort of thing. Charge companies a few hundred $ a month to use your site instead of NPM, and they can update packages at will without risk of picking up something nasty. Then again, the fact th…

Not really: http://www.paulgraham.com/schlep.html

Schlep is precisely a business opportunity -- tedious drudgery that you have to do regularly OR can pay and not worry about it again.

Re: Backdoor in event-stream library dependency

#279

Post by perfunctory »

michaelmrose wrote: post #132
perfunctory wrote: post #96

Earlier quoted context omitted.

I don't even see any moral issues here. Is there any reason to believe the original author acted in bad faith? If you sell your used car and it gets used to rob a bank, did you act immorally?

If you run a business where you have convinced people to give you access to their house to do some chore and you sell your business and your copy of their keys to a criminal it could be morally problematic. A car is merely a fungible vehicle the customer would have been no better or worse off had the robber been driving a different car. This would be an apt analogy for just giving / selling a code base. Had it been d…

> Had it been distributed under a new account/name users could have decided to trust or not trust a new maintainer.

This is the myth we keep telling each other but I don't seriously believe this is how open source works in reality.

Re: Backdoor in event-stream library dependency

#280

Post by vhost- »

Might be unpopular, but I'm super okay with maintainers just disappearing and ignoring their projects. Stop putting so much weight on the original package namespace. I know it's a lot of work, but in my experience, when maintainers disappear, the community creates a fork that's better maintained and people migrate to that version.

I think if you want to stop working on a project, and it's on github, just leave a note in the README, archive it and move on with your life. Don't give the keys to someone on the internet.

Post reply on HN