Post AiBzCLJMZxGJS5eyum by dalias@hachyderm.io
(DIR) More posts by dalias@hachyderm.io
(DIR) Post #AiBHdQpFmxkiOFgQGO by shironeko@fedi.tesaguri.club
2024-05-23T11:14:33.351741Z
0 likes, 0 repeats
@marcan Totally agree with you that cur|sh to install an OS works just as fine as any. I think what's happening is simply classical conditioning; people are conditioned by the 99.99% of cases where curl|sh is used as sloppy packaging/proprietary crapware/accidental rm -rf/shell script footguns/etc and the response becomes automatic and subconscious.
(DIR) Post #AiBIKR1quPv9TM582C by shironeko@fedi.tesaguri.club
2024-05-23T11:22:21.542097Z
0 likes, 0 repeats
@marcan to phrase another way, in almost all cases, curl|sh is being used as a poor substitute of some other, more suitable mechanism. It just happens that, as a special case, for aftermarket OS install on apple devices there are no more suitable mechanism.
(DIR) Post #AiBYpwIyH1eYiX8KG0 by shironeko@fedi.tesaguri.club
2024-05-23T14:27:18.946159Z
0 likes, 0 repeats
@marcan @CounterPillow I doubt many people are seriously verifying DNSSEC, because of how fragile and weak it is. see also https://sockpuppet.org/blog/2015/01/15/against-dnssec/
(DIR) Post #AiBzCLJMZxGJS5eyum by dalias@hachyderm.io
2024-05-23T11:27:31Z
0 likes, 0 repeats
@marcan @theartlav > not just "someone may sub in a malicious script...Not only is that still relevant, just not usually the biggest problem; validating the curlbash antipattern by copying it, even in a context where it's less dangerous, seems bad too.
(DIR) Post #AiBzCLrOXQU59da9xY by dalias@hachyderm.io
2024-05-23T11:32:33Z
0 likes, 0 repeats
@marcan @theartlav The flip side is it detracts from your credibility when you do it. Folks know "curlbash bad, projects recommending it are security clowncars" as a rule but don't understand the subtleties to evaluate "well in this instance it's not as bad".
(DIR) Post #AiBzCMcBjRulUlTWtc by geofft@mastodon.social
2024-05-23T12:56:09Z
0 likes, 0 repeats
@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.
(DIR) Post #AiBzCN85opR35iP0cq by dalias@hachyderm.io
2024-05-23T13:29:19Z
0 likes, 0 repeats
@geofft @marcan @theartlav curlbash should not be "rehabilitated". It's *always wrong*, just to varying degrees.Your comparison of "unreproducible configure scripts" doesn't work because the scope of those is such that they run fine in a build sandbox where you discard everything but the build artifacts. curlbash on the other hand is full of commands to install packages, modify config files, etc.
(DIR) Post #AiBzCNddvWfkfZACno by jpetazzo@hachyderm.io
2024-05-23T15:29:38Z
0 likes, 0 repeats
@dalias not wanting to be pedantic, but if I build a package (in a sandboxed environment), then install that package, and the postinstall script of the package backdoors my system, how am I being more secure than curl|sh?(My stance is that curl|sh per se isn't bad; the key thing is to look at provenance: https on a well-known domain with legit-looking URL = good; anything else = beware. And same thing for any package or any artifact in any form. I'm happy to revise said stance tho!)
(DIR) Post #AiBzCO4wI2VU2Dw0Lg by dalias@hachyderm.io
2024-05-23T16:47:06Z
0 likes, 0 repeats
@jpetazzo "Postinstall scripts" are the same evil as curlbash and should not exist.There is no excuse for "scripted modification of the user's system". You document what has to be done and either they do that manually, write their own script, or use their trusted distro provider to install it.
(DIR) Post #AiBzCOGHbra4bPF41w by geofft@mastodon.social
2024-05-23T13:02:13Z
0 likes, 0 repeats
@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.
(DIR) Post #AiBzCOr9On4URkUVUm by dalias@hachyderm.io
2024-05-23T16:51:35Z
1 likes, 0 repeats
@jpetazzo My understanding is that the prevalence of tooling for automating deployments to *your own systems* has somehow made people shipping software think they can do the same thing for other people's systems...That, or they come from Windows-land where the 🤮 professional thing to do is ship installers rather than self-contained zips that you extract and execute in place that don't touch anything outside their dir.
(DIR) Post #AiBzCPZSk2W6fBDtZ2 by puppygirlhornypost@transfem.social
2024-05-23T16:52:37.506Z
0 likes, 0 repeats
@dalias@hachyderm.io @jpetazzo@hachyderm.io post install scripts are the bane of any package maintainers' existence.
(DIR) Post #AiBzCQ4ItNBeCpeWdU by puppygirlhornypost@transfem.social
2024-05-23T16:54:15.076Z
0 likes, 0 repeats
@dalias@hachyderm.io @jpetazzo@hachyderm.io unironically though, really i want you to realize something. I am going to provide an example of why this is the case, and why we have to rely on things such as fakeroot with proot or what have you to sandbox packaging your apps. https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issues/123 WHY? Actually horrific this happened, and impacted a non insignificant amount of people installing bumblebee before NVIDIA wanted to play nice.
(DIR) Post #AiBzCQYn41ZbjNus9g by puppygirlhornypost@transfem.social
2024-05-23T17:00:43.987Z
0 likes, 0 repeats
@dalias@hachyderm.io @jpetazzo@hachyderm.io It defeats the purpose of the package manager which is supposed to be the one deciding what goes where. If you are shipping software standalone that is fine, but you should realize that if you want people to use it with systems that rely heavily on a package manager to do the heavy lifting you should focus on your post installation instructions. Not a minified, code golfed shell script that does god knows what. Let people figure out how to package that in their ecosystem (or, maintain your packages if you want strict control of the process) this is how it has been, this is how it should be, and anyone who deviates should be ousted. https://wiki.archlinux.org/title/PKGBUILD we have things like PKGBUILD on arch, we have all these native to a package manager's ecosystem way of doing "post install" scripts. do not just write some posix shell, or python, or perl script that requires a BUILD TIME dependency just to make your shit work. Why is curl | sh bad? Because it's easy to see if it's curl pulling unless someone bothers to type out user agent flags and so on. Would it be bad practice to curl and then review a script? No. That requires the script to be readable though which most of these curl | sh scripts are absolutely not. I am talking about those horrific thousands of lines posix scripts that have multiple cases, falling through because no adequate testing. https://github.com/valvesoftware/steam-for-linux/issues/3671 do not be that person. it's easier to provide instructions of how to configure the software than to maintain a monolithic script that does everything for them. Not to mention that most of the time these scripts exist to bypass package manager ecosystems. cough https://rustup.rs/
(DIR) Post #AiBzCQyfVoH11e1XUW by jpetazzo@hachyderm.io
2024-05-23T18:27:42Z
0 likes, 0 repeats
@puppygirlhornypost @dalias I agree with you; I'm going to try to rephrase my initial question 😅Given that virtually all¹ package managers have some way to run arbitrary postinstall scripts (as root!); what makes a deb/rpm/AUR/... better than curl|sh?My stance is that if I install packages from "core" repos, I'm probably good, because these maintainers usually care *a lot* and to a fantastic job (at least compared to the average dev trying to package their stuff).But with 3rd party stuff…
(DIR) Post #AiBzCRQJr0OKPOxcae by dalias@hachyderm.io
2024-05-23T19:14:45Z
1 likes, 0 repeats
@jpetazzo @puppygirlhornypost Yes, it's basically the difference between trusting one party you chose to mediate these things and make good decisions for you, and N parties who at best are sloppy, if they don't have outright conflicts of interest that disqualify them from making these decisions for you.
(DIR) Post #AiBzCU4nzRxsdXuyyO by jpetazzo@hachyderm.io
2024-05-23T18:30:45Z
0 likes, 0 repeats
…the package will only be as good or as safe as the person who authored the package. Maybe it'll be awesome! Maybe it'll be horrendous. Just like with curl|sh, at the end of the day: some is okay, some is terrible.(3rd party=launchpad, stray deb/rpm files, AUR...)¹I suppose the exceptions would be stuff like Flatpak, Docker images, ... I'm not well-versed enough in other distros to know if some of them are hardened around that!So at the end of the day, I prefer to think in terms of…
(DIR) Post #AiBzCXdIleLDfP54eu by jpetazzo@hachyderm.io
2024-05-23T18:32:04Z
0 likes, 0 repeats
…provenance (who made that install script/package/artifact? how are they vetted?) rather than dogmatically saying that method A is better than method B.
(DIR) Post #AiBzVrSPHlSOeXCI08 by portaloffreedom@social.linux.pizza
2024-05-23T10:52:02Z
1 likes, 0 repeats
@marcanI think the scariest thing is to make curl|bash normalized and then people running this from random websites for every single tool all the time. Then I don't have the same guarantees that a project like Asahi has.Maybe a project is malicious, or their website is compromised.I'm mostly scared about malicious project personally.
(DIR) Post #AiBzag2BBR8cfmE48G by CounterPillow@mastodon.social
2024-05-23T12:07:13Z
1 likes, 0 repeats
@marcan $ curl --cert-status https://alx.shcurl: (91) No OCSP response receivedDon't worry though, I'm sure your Let's Encrypt cert is safe from hijack, just ask these guys: https://notes.valdikss.org.ru/jabber.ru-mitm/
(DIR) Post #AiBziayFtOk7HnAMgS by dalias@hachyderm.io
2024-05-23T13:32:25Z
1 likes, 0 repeats
@geofft @marcan @theartlav The core problem with curlbash is the *philosophy* - presume the user doesn't know how to admin their own system, install deps they need, etc. and ask them to let a script you wrote play admin on their box. (Along with that, it acts as license *not to document* what the user would need to do things themselves.)
(DIR) Post #AiC07ajduE2LnKFa6K by geofft@mastodon.social
2024-05-23T13:31:09Z
0 likes, 0 repeats
@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. :)
(DIR) Post #AiC07bphpATtCQ5wBs by dalias@hachyderm.io
2024-05-23T13:34:26Z
0 likes, 0 repeats
@geofft @marcan @theartlav The question is not whether users unaware of the risks of curlbash do that.The question is whether users who are aware of the risks have a viable path to install without reverse engineering the curlbash garbage somebody shipped in place of build/installation instructions.
(DIR) Post #AiC07cnGFk7UB7xV1E by dalias@hachyderm.io
2024-05-23T13:36:49Z
1 likes, 0 repeats
@geofft @marcan @theartlav The sandbox I use for builds is not claimed to be tight against outright intentional malice, but at least against malice that folks shipping software think is them being "helpful". If you want to play with escapes I'd love to hear your results. https://github.com/richfelker/usand
(DIR) Post #AiCbCvYRck8u7IQ6IS by dalias@hachyderm.io
2024-05-24T02:23:47Z
1 likes, 0 repeats
@marcan @geofft @theartlav That's like 2 offenses there: (1) not using the system's provided python but downloading your own, and (2) downloading anything at all as part of running the installer, vs letting the user download the whole thing in advance so install can be performed offline.
(DIR) Post #AiLjnuppoGl0eiLFg0 by CounterPillow@mastodon.social
2024-05-28T10:28:05Z
0 likes, 0 repeats
@shironeko Let's Encrypt, according to their own documentation, verifies DNSSEC. And that is the only party who needs to be verifying it in this case to prevent a misissued cert. I do not care about DNSSEC rollout beyond that usecase.If you've found evidence that Let's Encrypt issues a certificate for a DNSSEC-signed domain that fails DNSSEC verification, you should report that to them.
(DIR) Post #AiLjnvkCQhqNTWiGX2 by shironeko@fedi.tesaguri.club
2024-05-28T12:17:17.920718Z
0 likes, 0 repeats
@CounterPillow does LE requires DNSSEC?
(DIR) Post #AiLnR8iuPINisyUtZQ by CounterPillow@mastodon.social
2024-05-28T12:32:31Z
0 likes, 0 repeats
@shironeko No, and I know where you're trying to go with this. "If DNSSEC with LE is optional, can't an attacker just strip DNSSEC thereby rendering it useless?" and the answer is no they can't because that's not how DNSSEC works.
(DIR) Post #AiLnR9vLwVvibrKLbc by shironeko@fedi.tesaguri.club
2024-05-28T12:58:01.948748Z
0 likes, 0 repeats
@CounterPillow care to explain? I'm pretty sure I've seen talks of DNSSEC downgrade attacks.