And there’s a reimplementation of Git in Rust. Not sure how complete it is though.

Crypto is used. It is called TLS.

You have to have some trust of publishing infrastructure, otherwise how do you know your signatures are correct?

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.

That would be very difficult because Typescript isn’t sound.

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.

No it isn’t. What could a Bash script do that the executable it downloads couldn’t do?

So what? I’ve seen that in every language.

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”…

deleted by creator

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?

600?? Did you automate it or something?

I’m talking about things like Perceus. It’s not a compiler update.

Definitely the best option.

Yeah that is true. Not all IDEs support that though.

Nice! According to the video it’s about 3½x faster by using Go and the rest from multi threading.

I don’t think I could ever go back to writing Go code after Rust, in spite of the way faster compile time, GC, not having to deal with the borrow checker, easier cross-compilation, bigger standard library, etc.

Writing the code is just too tedious.

No, the alternative solutions definitely wouldn’t work with existing Rust code. You need a new language.

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