[cyphar]

> Sorry, but if you deploy a random chunk of third-party code into your production environment without knowing exactly what it does, you deserve to be sacked.

Have you reviewed all of Linux, glibc, nginx/Apache, bash, all several thousand node dependencies, and so on? Do you do such a review each time you have to update a package?

Don't get me wrong, I think there's a serious problem with the micro-dependency insanity, but every single person on the planet depends on others. "We stand on the shoulders of giants" is more of a truism today than it has ever been. It's not a sacking offense to trust people (because you wouldn't be able to do your job if you spent all of it reviewing other people's work).

Most people have a reasonable expectation that maintainers of a project are reasonable people -- which is why the micro-package insanity is particularly problematic. I trust most kernel maintainers and so I don't check each Linux release to see whether a backdoor was added (I only check if I've noticed a problem). The blame should be on the maintainers here -- it isn't acceptable to add Easter eggs like this to a library used by many people (especially if it's being used for Serious Business™).

Would you blame every glibc user (which is all Linux users) if they decided to make all math functions return 25 on Christmas? Of course you wouldn't -- you'd blame the maintainers for having lost their minds.

[marcus_holmes]

I do deliberately try to limit what goes into my production machines, yes. I choose to trust some things, carefully, and choose not to trust others. No, I can't review everything out there. But technically, I should. And if it goes wrong and there's a problem with some code that I put on the production machine, then that's my problem.

I don't really understand why we have "reasonable expectations that maintainers of a project are reasonable people". We absolutely know for a fact that a not-insignificant percentage of our users are malicious. Why do we assume that zero percent of package maintainers are malicious?

The only qualification someone has to be a maintainer is to have written something that someone else wants to use, and to publish that thing on a package repository. Or that they volunteered to take over maintenance of a thing that other people want to use. There's nothing in there about not being malicious.

And yes, I would absolutely blame every glibc user for trusting the glibc maintainers. Glibc is a gift. I don't have any contract with the maintainers of glibc that says they have to act in my interests. I choose to use their work because it saves me time. If that stops being the case, I'll find an alternative (together with everyone else), or roll back to the last known good version of their work that they let me use. If the glibc maintainers really want to make it Christmas Day every day, then that is entirely their right. I do not have the right to demand anything from them or their code. I don't have to use their code, and they don't have to take my needs into consideration when writing it.

[cyphar]

> And if it goes wrong and there's a problem with some code that I put on the production machine, then that's my problem.

While I understand this sentiment, it's not practically possible -- and if every business did audits of all code on their production machines (do we include firmware?) they would never get any work done or update anything. Which would lead to objectively worse outcomes (outdated/insecure software or no software developed at all) -- so there needs to be a middle-ground somewhere. In fact, you've already picked one (which is reasonable -- I think limiting dependencies is a good thing):

> I do deliberately try to limit what goes into my production machines, yes. I choose to trust some things, carefully, and choose not to trust others.

I would expect NASA/JPL to audit everything they run in production on a space telescope or shuttle. I wouldn't expect the same from the next "Uber for Dogs", nor would I think it a reasonable standard.

> I don't really understand why we have "reasonable expectations that maintainers of a project are reasonable people".

For a variety of reasons. Maintainers are public entities, so they know if anything they do is malicious they will feel immense backlash (such as is happening here over a somewhat minor issue compared to exfiltrating user data). People have pride in their work -- this is a known psychological effect -- and this is especially true in the free software world, so it's much less likely they'd sabotage something they'd put their time into. Developers that contribute to a project (likely for work or something like that) can become maintainers and thus the most motivated users usually become maintainers (and given that it takes time to become a maintainer of most large projects, doing it to sabotage the project is a long-haul gig).

> And yes, I would absolutely blame every glibc user for trusting the glibc maintainers.

I think this is far from reasonable -- you are talking about literally every single user of any program built on any Linux distribution for the past 30 years. Would you level more blame on the glibc maintainers for betraying their users in this manner? Do you blame websites for CVEs like Heartbleed -- even if they fix them as soon as they can?

> I don't have any contract with the maintainers of glibc that says they have to act in my interests.

Not a legal contract, but a social one. People who are in positions of power have an ethical duty to our society. Those who don't, don't deserve to be in such positions.