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

461–470 of 509 posts

Re: Backdoor in event-stream library dependency

#461

Post by kps »

marshray wrote: post #456
bmurphy1976 wrote: post #431

Earlier quoted context omitted.

Do you really think cat is as simple as left-pad? https://github.com/freebsd/freebsd/blob/master/bin/cat/cat.c Also, cat is kind of an important primitive for building a functional system that uses files as one of its core abstractions. It makes total sense that it would (a) exist and (b) be well maintained by an authoritative and reliable source. Left pad it is not.

> `cat` without any options Interestingly, the `raw_cat()` function is 37 lines long. https://github.com/freebsd/freebsd/blob/e511976db9f51bae1a59...

UNIX `cat`, unchanged from V2 through V6 until it was rewritten in V7, was 44 instructions.

Re: Backdoor in event-stream library dependency

#462

Post by mncharity »

jerf wrote: post #315
pcwalton wrote: post #291

Earlier quoted context omitted.

I'm not convinced that this incident argues in favor of Go's "a little copying is better than a little dependency", which I continue to strongly disagree with. Rather, it indicates that you shouldn't blindly upgrade. Dependency pinning exists for a reason, and copying code introduces more problems than it solves.

I don't think you have to get all the way to the Go community's opinions to be in a reasonable place; I think the JS community is at a far extrema in the other direction and suffer this problem particularly badly, but that doesn't mean the other extreme is the ideal point. I don't personally know of any other community where it's considered perfectly hunky-dory to have one-line libraries... which then depend on other…

I suggest a different narrative. That node.js achieved the decades-old aspiration of fine-grain software reuse... and has some technical debt around building the social and technical infrastructure to support that.

Fine-grain sharing gracefully at scale, is a hard technical and social challenge. A harder challenge than CPAN faced, and addressed so imperfectly. But whereas the Perl community was forced to struggle over years to build it's own infrastructure - purpose-built infrastructure - node.js was able to take a different path. A story goes, that node.js almost didn't get an npm, but for someone's suggestion "don't be python" (which struggled for years). It built a minimum-viable database, and leaned heavily on github. The community didn't develop the same focus on, and control over, its own communal infrastructure tooling. And now faces the completely unsurprising costs of that tradeoff. Arguably behind time, due to community structure and governance challenges.

Let's imagine you were creating a powerful new language. Having paragraph- and line-granularity community sharing could well be a worthwhile goal. Features like multiple dispatch and dependent types and DSLs and collaborative compilation... could permit far finer-grain sharing than even the node.js ecosystem manages. But you would never think npm plus github sufficient infrastructure to support it. Except perhaps in some early community-bootstrap phase.

Re: Backdoor in event-stream library dependency

#463

Post by zeroname »

tjholowaychuk wrote: post #255
zeroname wrote: post #198

Everyone is fired. If you insist on pushing out hundreds of packages on npm, then drop support for them and hand over rights to random strangers, you are acting completely irresponsibly. You shouldn't be given a pass because you're doing it all voluntarily. Your professional reputation should suffer for it.

Easy for people who have zero packages and no pressure to say. Don't contribute to OSS and you have no problems. If these huge companies profiting off OSS work actually contributed financially and with time, maybe maintainers would happily remain maintaining.

> Easy for people who have zero packages and no pressure to say.

If you have this "no warranty, no responsibility" attitude then how can you have pressure to maintain anything? How does that translate into pressure to hand off the project to strangers? Nobody asked for that.

> Don't contribute to OSS and you have no problems.

Yes, please don't contribute if you have this kind of attitude. It's harmful. If you can't maintain the package, deprecate it. Don't hand it over to an unvetted entity. If we can just agree on that M.O. we'll have a much better situation.

> If these huge companies profiting off OSS work actually contributed financially and with time, maybe maintainers would happily remain maintaining.

Ifs and buts and sugar and nuts. They don't contribute, they never have and they probably never will, you are responsible for your packages even if you are doing it voluntarily.

Re: Backdoor in event-stream library dependency

#464

Post by Ayesh »

meowface wrote: post #445
tclancy wrote: post #419

Earlier quoted context omitted.

Have you ever created a package that people started to use, which you then had to maintain for purposes that didn't do anything for you and then no longer even need the package? Pretty much any rando offering to take over maintenance is going to be welcome to it compared to the dozens of requests and insults offered as bug reports.

Yes, I am in this situation right now, actually. I have a project with around 700 stars on GitHub with over a million downloads per month (according to PyPI) which I no longer have the time, interest, or willpower to continue maintaining. I placed an open call to find a new maintainer months ago, and have received many requests. Every single request I've received has been roughly as shady as the request sent to event…

This is good maintainership right here!

For outsiders, it looks like the maintainer is greedy to keep the project to themselves. The bug reports pile up, and dozens of people are offerring to maintain. And then insults start to come up, because it looks like you don't want to hand it over.

If you want to take over a project, you just earn the trust if the current maintainer, be it patches for existing PRs, finding security vuons, etc over the time. Linux has gotten this right.

Re: Backdoor in event-stream library dependency

#465

Post by Ayesh »

xvector wrote: post #258
jsd1982 wrote: post #234

Earlier quoted context omitted.

Explain how you would be able to evaluate the trustworthiness of a person asking to transfer ownership to.

If you can't evaluate the trustworthiness who you're handing the package over to, just don't hand it over. Mark it as deprecated and call it a day. This is Open Source 101.

GitHub has a Read Only option, and package managers of most languages have a way to convey that the project is abandoned or provided security fixes only.

You don't have to feel guilty to abandon the projects. Most us do it, every day.

Re: Backdoor in event-stream library dependency

#466

Post by marcus_holmes »

We're going to see a lot more of this. Dependencies are a security risk. If you're writing a secure system that will be storing personally-identifiable information as GDPR defines it, then you need to audit every dependency that you include in your project (and every dependency that each of those dependencies include). And then again every time they change version.

The golden days of including any old gem or npm package that seems to solve the problem you're looking at are over.

Re: Backdoor in event-stream library dependency

#467

Post by olingern »

I was understanding until I read:

"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."

in the thread. Then, I looked through the commits and realized how not ready @right9ctrl was to maintain a heavily used package. Basic linting and small, iterative changes are absent.

So, when I see Dominic-さん just "handing" the package over -- it seems careless. This is often why -- I try to write my own packages unless I absolutely need some sort of framework. It's trading one set of problems for another (the potentiality for bugs vs. a package as a security issue).

Re: Backdoor in event-stream library dependency

#469

Post by Ayesh »

slg wrote: post #397
jrochkind1 wrote: post #373

Earlier quoted context omitted.

And yet, to produce the software that nearly any employer or client in 2018 wants at the price they want, requires using open source dependencies without manually reviewing every diff from every version released. I don't really understand what you are trying to suggest. Yes, whether we realize it or not, we are trusting the maintainers of our dependencies. Sometimes that trust is misplaced. That might lead us to try…

I am generally advocating for being an informed user of open source software. As for something more specific, I would echo the two suggestions from the original author in one of his Github comments: >1. Pay the maintainers!! Only depend on modules that you know are definitely maintained! >2. When you depend on something, you should take part in maintaining it. You can't expect someone to maintain your code for you wi…

I suppose this is hard in NPM.

For example of I have a project with 5 dependencies, this explodes to hundreds of tiny projects. These individual projects are almost always just a few lines of code, and there's no way anyone's going to become a donor for them.

Many major projects are well funded (webpack, etc), but all it takes is one of those tiny packages to send a malware.

Re: Backdoor in event-stream library dependency

#470

Post by michaelmrose »

jodrellblank wrote: post #460
michaelmrose wrote: post #413

Earlier quoted context omitted.

Google isn't the ultimate source of truth of the meaning of words. When someone says that another party is morally liable they mean morally responsible. That he ought to feel responsible and act according and consider others actions in the future lest he feel like he has morally failed people in the future. Ultimately we are often and are often expected to be our harshest critic and ought not to limit our duty to oth…

The meaning of words isn't what I want to focus on, but the irrelevance of any response to this event along the lines of "well he SHOULD feel bad". If "he is morally responsible" leads only to "he should feel bad" and nothing more, then what does it matter if he is/isn't morally responsible? Ok he (does/doesn't) feel (justifiably/unjustifiably) bad .. now what?

Nothing.
Post reply on HN