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