Notices by Geoffrey Thomas (geofft@mastodon.social)

@dalias @marcan @theartlav Do any users who are not aware of the risks of curl|bash run ./configure in a build sandbox?

Also what build sandbox do you use? I would like to try to escape it. :)

@dalias @marcan @theartlav One argument in favor of curl|bash: all realistic alternatives - third-party rpm/deb/etc., pip install, building from source, etc. - are just as capable of running arbitrary code but they _look_ less dangerous. curl|bash is honest about its risk and makes people think whether they trust the source.

If a project can use a sandboxed app store or run on a web page, that's meaningfully better, but almost no project considering curl|bash can do that.

@dalias @marcan @theartlav But there is no such rule! Plenty of projects that are _not_ security clowncars recommend curl|bash for thoughtful reasons. Plenty of projects that are security clowncars ship source tarballs with unreproducible ./configure scripts.

There is a _perception_ that it's bad, yes. I think a respected project using curl|bash is just as likely to to rehabilitate curl|bash and fix that perception, especially if (as here, as Sandstorm did, etc.) they write about why it's okay.

LRT: I wonder if open-source projects will start treating aggressive questions about "when is the next release" as a potential attack. I'm undecided about whether this is good; it may well be.

This is, btw, why I think it's morally incumbent on corporate users of open source to have a way to build patched versions of the software internally, well before they need it. You have the resources to do so, and your timeline is not the maintainer's timeline. At some point you will need to apply a patch to one of your dependencies. Do not engineer yourself into a place where the the thing that delivers the most business value is to bully the maintainer.

@luis_in_brief @glyph @eb I should try harder to figure out what a Tidelift is and how to convince my employer to sign up. But also... IMO Microsoft or Google (whom I am subtooting) etc. can singlehandedly employ all the maintainers of `ldd sshd` and that would get results that fractionally paying for the commons never will.

Like this should be the job of a distro, and RH/SUSE/Canonical/Oracle kinda do this, but clearly none of them actually saved their customers (or the world) from this.

@glyph @luis_in_brief @diazona @eb Yes, e.g., what if the current maintainer is genuinely unavailable/uninterested? As may well have happened with xz even with a job offer.

Funding a new maintainer is by itself defensible, but doing so will drastically change both the pressure on the current maintainer and the choice of who becomes maintainer (e.g. there's now a bias in favor of those who have US work authorization).

I'm curious if either Tidelift or the commercial distros have norms for this.

@luis_in_brief @diazona @glyph @eb Yeah that resonates with my experience. People like GvR get hired (which is great!) but there's a whole dependency stack underneath. Their maintainers often have a strong résumé to get hired for a normal big tech job at a company that uses the language/ecosystem/etc. but not necessarily for maintaining the project as their job. Sometimes the job is even "build something similar for an internal non-OSS ecosystem."

@glyph @eb I'm frustrated that big tech's efforts to increase core library security are "your project is too popular, you must use 2FA" and "the best reverse engineers in the world will find your bugs and put you on a 90 day disclosure deadline" and not "here is $100K/year and benefits to keep doing what you're doing at your own pace."