People have to understand that the Node.js ecosystem is different than in other programming languages/platforms. Modules are composed from smaller modules with a granularity so small that it is almost unique. When you're publicly publishing something low-level to npm you really should understand that the community may build on top of it to the point where it is used by many modules and as a result used by many end-users. You are not obligated to maintain it, but it's not really fair to be totally careless either. The community is like society, if you're in it, try to be a good citizen or the community will move against you to preserve it's ideals.
Backdoor in event-stream library dependency
181–190 of 509 posts
Re: Backdoor in event-stream library dependency
#182Earlier quoted context omitted.
Especially given that Dominic maintains hundreds of packages[1]. He's a good guy and a great developer, and he's always been supportive of others who want to help out. When working on Scuttlebutt[2] I got some flak for a change I made and he said this[3]: > I argued against this before, but @christianbundy wanted to do it, so I figured okay do it then. Maybe it is annoying for everyone (in which case christian probab…
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…
> Lieutenants gain authority based on the merit of their contributions
Meritocracy is an outdated discriminatory practice.
https://www.theguardian.com/commentisfree/2017/mar/20/merito...
Re: Backdoor in event-stream library dependency
#183Someone post a list of every public package that depend on that one https://github.com/dominictarr/event-stream/issues/116#issue...
A lot of very common packages...
Re: Backdoor in event-stream library dependency
#184Earlier quoted context omitted.
It’s about ethically handing off a package. No one is forcing him to maintain it. But when you make a package used by millions of people, you become responsible for their safety. To then hand over a package to a hacker or unknown party is just morally wrong. Just mark it as deprecated and call it a day, like a normal and responsible person.
>But when you make a package used by millions of people, you become responsible for their safety. Says you! I don't agree with that. Author clearly doesn't either. You're painting it as though the author knowingly handed it over to some hacker when in reality he had 0 cares about this package and just handed it over to the first guy who asked. I would have done the same probably.
This is incredibly irresponsible.
If you don't have the care to maintain it or do any sort of vetting, you shouldn't have the care to do anything at all. Literally, leaving this unmaintained would have been a better solution.
Re: Backdoor in event-stream library dependency
#185Earlier quoted context omitted.
Please substantiate your own open source projects at any and all sizes so that we may, too, cast aspersions on your relationships with governmental agencies. I'm sure that will improve things mightily . This is a community problem based on insufficient incentives and the way that the software development community is content to allow individual labor to replace community efforts and you, as a member of that community…
antocv, like many of us values security over feelings. If you want to run maybe insecure code to help be supportive of someone, go for it. His point is valid though and you can ignore it at your own risk.
There's a significant difference between caring about security and one's reputation and jumping to conclusions as antocv has here. Dominic clearly handled this poorly, but there isn't a need to exaggerate for what he "could" have done as a means of impinging his reputation further than what's been done here and now.
Re: Backdoor in event-stream library dependency
#186Earlier quoted context omitted.
Especially given that Dominic maintains hundreds of packages[1]. He's a good guy and a great developer, and he's always been supportive of others who want to help out. When working on Scuttlebutt[2] I got some flak for a change I made and he said this[3]: > I argued against this before, but @christianbundy wanted to do it, so I figured okay do it then. Maybe it is annoying for everyone (in which case christian probab…
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…
> that doesn't have a strong measurable reason
I think that's the key here - organization/hierarchy is important as a project scales up, but he didn't want to stifle a new contribution without good reason.
Re: Backdoor in event-stream library dependency
#187Earlier quoted context omitted.
If you have tons of depedencies then it's not feasible to check every diff. You may able to do it or pay someone if you are a bigger organization, but a small shop or solo developer can't do this.
That's why you lock your dependencies.
Hope you don’t start your project with the compromised version — and then lock it in.
Re: Backdoor in event-stream library dependency
#188I had this exact same problem from both sides (not working on a project any more and wanting to find someone to maintain it/wanting to maintain a project someone wasn't working on because I found it interesting). It's not always easy to find people who are interested, and, while giving maintainer access to someone you know very little is usually fine and works out great, sometimes you get results like these. In the e…
There's a similar effort in the Python / Django world called Jazzband ( https://jazzband.co/ ). This model will probably become more and more necessary as maintainers need to move on from projects for whatever reason. Having a safe place to transfer a project to with a formal process (announcement of the change, code review before acceptance, etc.) would certainly help combat this issue.
Yes, I was inspired by Jazzband, but Jazzband has two things that led me to develop Code Shelter: It's pretty specific to Django, whereas I wanted something general, and people have to move their projects to the Jazzband org, which many people don't like doing (because they understandably want to keep their attribution).
With Code Shelter you don't have to move the project anywhere, you just give repo admin access to the app and the app can add/remove maintainers as required.
There's obviously a corrective component as well, where maintainers who don't do a good job are removed, but this hasn't happened yet so it's not clear how it will be handled.
Re: Backdoor in event-stream library dependency
#189Earlier quoted context omitted.
Liability is very often not exclusive in law, and, in particular, tends to flow the whole way up supply chains. With nothing being sold you probably aren't dealing with strict product liability upstream, but exposure of end users is reasonably foreseeable so there's no immediately obvious blanket reason for ruling out upstream negligence liability to end users. The idea that the party most proximate to end users is e…
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…
> You honestly think that the author of software released as open source is going to be liable for vulnerabilities in that software
Where the type of harm that results is reasonably foreseeable and could have been prevented by reasonable care by the developer (or maintainer; different though often co-occurring roles), I don't see how the general law of negligence doesn't fit. AFAIK, negligence has no open source software escape hatch.
Re: Backdoor in event-stream library dependency
#190Well, it would not happen if people used Elm :)
This doesn't make sense because Elm is client-side only, and all code that ships is client-side executable.
Node, a general purpose language, has a scope that's much, much larger.