Live data from Hacker News

Backdoor in event-stream library dependency

github.com

111–120 of 509 posts

Re: Backdoor in event-stream library dependency

#111
post #9

It looks like no one is even sure what the code actually does? Or am I misreading that thread.

No one knows what it does but we do know that it seems to execute some encrypted bytecode. This seems remarkably unconventional and likely a good way to bundle malware.

Re: Backdoor in event-stream library dependency

#112
post #7

I really have a hard time putting as much blame on the author as the people in that Github thread are doing. Maybe they could have handled this specific issue a little better, but the underlying problem is just one of the flaws in the open source community that everyone has to accept. Maintaining a project is a lot of work (even just having your name attached to a dead project involves work) and the benefit from doin…

Allowing the first person to express interest to "adopt" your project, seems to me to have all the same potential bad outcomes as allowing the first person to express interest to adopt a child from an orphanage.

For children, that's much of the reason for Child Protective Services to exist: to regulate orphanages and adoption agencies such that they will thoroughly vet prospective adoptive parents; and to establish and regulate a fostering system—pool of known-good temporary guardians (foster parents) that can take care of children temporarily when no vetted-as-good outsider can be found to take them more permanently.

Now imagine a software org that acts on abandonware software projects the way a CPS-regulated orphanage acts on abandoned children. Start by picturing a regular software foundation like the ASF, but then 1. since all the software is currently abandonware, the foundation itself steps in and installs temporary maintainers; and 2. since the foundation's presence in the project is temporary, they seek to find (and vet!) a new long-term maintainership to replace the existing one.

Of course, that level of effort is only necessary if you care about project continuity. If it's fine for the project to die and then be reborn later under new maintainership, you can just let it die.

Re: Backdoor in event-stream library dependency

#113
post #7

I really have a hard time putting as much blame on the author as the people in that Github thread are doing. Maybe they could have handled this specific issue a little better, but the underlying problem is just one of the flaws in the open source community that everyone has to accept. Maintaining a project is a lot of work (even just having your name attached to a dead project involves work) and the benefit from doin…

It's better if the new maintainer's intentions are altruistic. From @dominictarr, the maintainer: > he emailed me and said he wanted to maintain the module, so I gave it to him. I don't get any thing from maintaining this module, and I don't even use it anymore, and havn't for years. That's just plain irresponsible. He must have known how popular the library was. Taking ownership of browser extensions and common soft…

> That's just plain irresponsible. He must have known how popular the library was. Taking ownership of browser extensions and common software libraries is becoming a very popular attack vector. Owners of these need to be a little more diligent when transferring ownership.

I'm sure he would do it for $150k/year. He won't do it for $150k/year? Increase the price until he says "Yeah, sure I will maintain it". Or maybe he will find someone else would would maintain it for that money.

Re: Backdoor in event-stream library dependency

#114

Move fast and break things. I view this as an endemic fault of how npm, and to a larger extent javascript, culture works and thinks. I believe npm to be a giant landmine of untrustwothy packages thrown together. No package is trustyworthy as the dependency chain runs too wide and too deep. And having unwieldy dependency trees is considered a feature of npm.

This must be the fifth incident that could have been readily prevented if npm simply required signing for it's packages.

Just do the same thing we have for SSH: on first connection (installation), ask if you trust the other side. That goes into your authorized_keys (lock file). If you connect again (update) and the key changed, print a big scary warning. No blockchain needed.

Re: Backdoor in event-stream library dependency

#115
post #40

Earlier quoted context omitted.

I'm not a crypto guy but this change really makes me scratch my head: https://github.com/right9ctrl/node-scrypt/commit/52a1cb792bc...

That just looks like a convenience function to me. Rather than passing 1,2,4,8,16 in as the value of N, you pass in 0,1,2,3,4. Has the benefit that it's not possible to pass in a number that's not a power of 2 (which might not be valid, I don't know how scrypt works).

IIRC scrypt is only defined for powers of 2 for N.

Re: Backdoor in event-stream library dependency

#116
post #65

Earlier quoted context omitted.

> maintains hundreds of packages Might be worth looking over some of these to see if he has also given access of them to some dodgy people. As most of them appear to be as old as event-stream and are also probably as unused by him. And if we are concerned, we should, he would advise, simply make a fork and write an email to npm to warn them. But hes a good guy, so don't blame him if you find that he's done this befor…

> And if we are concerned, we should, he would advise, simply make a fork and write an email to npm to warn them. Well... yeah. If you don't trust him, don't trust him. If you don't trust NPM's vetting, don't trust NPM's vetting.

npm does vetting?

Re: Backdoor in event-stream library dependency

#117
post #70

Earlier quoted context omitted.

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…

There's a difference between legal liability and moral liability.

I hope everyone talking about motel responsibility are donating to all the open source projects they depend on. If not I find the moral preaching a bit one sided.

Re: Backdoor in event-stream library dependency

#118
post #7

I really have a hard time putting as much blame on the author as the people in that Github thread are doing. Maybe they could have handled this specific issue a little better, but the underlying problem is just one of the flaws in the open source community that everyone has to accept. Maintaining a project is a lot of work (even just having your name attached to a dead project involves work) and the benefit from doin…

No. Transferring a project wholesale to an unknown maintainer is effectively a fork; I'd much rather have my dependencies die than start silently pulling in a fork. If I want to swap in right9ctrl/event-stream, I'll do it myself.

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.

Re: Backdoor in event-stream library dependency

#119
post #34
post #7

I really have a hard time putting as much blame on the author as the people in that Github thread are doing. Maybe they could have handled this specific issue a little better, but the underlying problem is just one of the flaws in the open source community that everyone has to accept. Maintaining a project is a lot of work (even just having your name attached to a dead project involves work) and the benefit from doin…

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.

If I thought I might be on the hook for damages caused by a mistake in how I run an open source project, I would never open source anything.

Re: Backdoor in event-stream library dependency

#120
IMHO there are only 2 long-term solutions to this type of problems: 1) Reduce the number of external dependences as much as possible 2) Pay authors to properly maintain the packages that you rely on. If you use them on commercial projects it's the first and the cheapest possible security measure you should invest in.
Post reply on HN