This is a common sentiment people say about C, and I have a the same opinion about it. I would rather we use systems in place that don’t give people the opportunity to make mistakes.
The issue with C is it lets you make mistakes that commonly lead to security vulnerabilities - allowing a malicious third party to do bad stuff.
The Bash examples you linked are not security vulnerabilities. They don't let malicious third parties do anything. They done have CVEs, they're just straight up data loss bugs. Bad ones, sure. (And I fully support not using Bash where feasible.)
Viable alternative for what? Packaging.
A viable way to install something that works on all Linux distros (and Mac!), and doesn't require root.
The reason people use curl | bash is precisely so they don't have to faff around making a gazillion packages. That's not a good answer.
Hilarious, but not a security issue. Just shitty Bash coding.
And I agree it's easier to make these mistakes in Bash, but I don't think anyone here is really making the argument that curl | bash is bad because Bash is a shitty error-prone language (it is).
Definitely the most valid point I've read in this thread though. I wish we had a viable alternative. Maybe the Linux community could work on that instead of moaning about it.
No because there's very little point. Checking signatures only makes sense if the signatures are distributed in a more secure channel than the actual software. Basically the only time that happens is when software is distributed via untrusted mirror services.
Most software I install via curl | bash is first-party hosted and signatures don't add any security.
No, the point I am making is there are no additional security implications from executing a Bash script that someone sends you over executing a binary that they send you. I don't know how to make that clearer.
Based on my experience of AI coding I think this will only work for simple/common tasks, like writing a Python script download a CSV file and convert it to JSON.
As soon as you get anywhere that isn't all over the internet it starts to bullshit.
But if you're working in a domain it's decent at, why not? I found in those cases fixing the AI's mistakes can be faster than writing it myself. Actually often I find it useful for helping me decide how I want to write code because the AI does something dumb, and I go "no I obviously don't want it like that"...
it is detectable on server side, if you download the script or pipe it into a shell
Irrelevant. This is just an excuse people use to try and win the argument after it is pointed out to them that there's actually no security issue with curl | bash.
It's waaaay easier to hide malicious code in a binary than it is in a Bash script.
You can still see the "hidden" shell script that is served for Bash - just pipe it through tee and then into Bash.
Can anyone even find one single instance of that trick ever actually being used in the wild (not as a demo)?
I understand that we have the same problems with the installed application, even if it was downloaded and installed manually. But I feel the bar for making a mistake in a shell script is much lower than in whatever language the main application is written.
So you are concerned with security, but you understand that there aren't actually any security concerns... and actually you're worried about coding mistakes in shitty Bash?
The thing is that "learning C" means "I can write C code that compiles and might be full of bugs", whereas "learning Rust" means "I can write Rust code that compiles and has a small number of bugs". It's not apples-to-apples.
It's like saying "I found it easier to learn primary school maths than I did to learn a physics degree".
Yeah that's definitely true, but also the people who have been doing it for 20 years have a huge amount of knowledge and experience invested in dealing with memory unsafety. Lots of people don't want that investment to be "wasted", so they try to maintain the status quo, even if it is worse for them.
[memory safety] is a more or less solved research problem
I don't know if I would go that far. There are some interesting alternative approaches to Rust's borrow checker that might turn out to be better. There's definitely more research that can be done.
But we do have at least one solution that works very well.
The issue with C is it lets you make mistakes that commonly lead to security vulnerabilities - allowing a malicious third party to do bad stuff.
The Bash examples you linked are not security vulnerabilities. They don't let malicious third parties do anything. They done have CVEs, they're just straight up data loss bugs. Bad ones, sure. (And I fully support not using Bash where feasible.)
A viable way to install something that works on all Linux distros (and Mac!), and doesn't require root.
The reason people use curl | bash is precisely so they don't have to faff around making a gazillion packages. That's not a good answer.