[predictabl3]

Sounds about par for the course for folks that think shell is a productively sustainable way of writing secure or reliable software. Not even remotely sorry about that opinion. The gall to claim ACME compat, then force require a single client, all so you can remote execute arbitrary commands. Should be enough to ruin the CA, but we know how people handle things like this "oh, won't affect me" (until it does). Seemingly just so they can avoid some reverse proxy rules to host the challenge endpoints at the right place? Holy wow. Oh there we go baby, eval'ing with arbitrary input in the shell script, complete with lazy inproper string quoting. I should probably just stop before I say more unkind things.

Was it even run through shellcheck?!

Stop writing this stuff in shell people. 95% of the time I review any (posix, nushell lacks most of these issues) shell scripts, it's obvious they would fall apart the second any string unexpectedly had a space in it. Even scripts written by darling companies of HN.

[l0b0]

How did we get here?

- The barrier to entry for shell scripting is tiny. You basically start with `ls` in an interactive shell and end up writing a frickin' 500-line monstrosity within a month.

- POSIX has fossilised scripting languages. I hoped we'd have something like PowerShell by now, but although we have some fine alternatives, none of them seem to be good enough to actually overcome the inertia of POSIX.

- Doing something that looks correct is easy, but doing the right thing is super effing hard. See looping through complex sets of files.

- People use statements like "It's just a script", as if scripts are somehow easy to write. Bullshit.

[SergeAx]

Script may be not easy to write, but it's universally easy to deploy. Single almost cross-platform file, no dependencies. Publish the text on a webpage or in an email newsletter so everyone can copy-paste it to their system. Brilliant.

[dundarious]

There is almost never a good reason to use constructs like eval in any language (and it exists in many languages), just like there are barely any good reasons to use constructs like system() in C. It appears acme.sh was running eval. I haven't looked into it, but the most common reason I see eval in use is because people don't know that you do it much simpler/more directly by just geting the shell to run commands that are variables with no issue, e.g., `doit() { printf "running: %s\\n" "$*" ; "$@" ; } ; doit ls /` which works in POSIX sh, no bashisms. (Obviously you should only call it with at least the first argument being trusted)

But shell is really not hard if people stick to a few easy guidelines:

- quote all var expansion, e.g., "$var" not $var or ${var} (very rare to need otherwise, and never for untrusted data)

- use "$@" to perfectly forward arguments (not $@, not $*, not "$*" except when you want to turn many arguments into one)

- don't use eval

- use `set -eu` and explicitly handle functions/commands that may benignly return/exit non-zero, e.g., `diff -U10 ./a ./b || true`

- use printf on untrusted strings instead of echo (just use it generally, I say), e.g., printf %s\\n "$var" instead of echo "$var". One of the few times you want to use "$*" is with printf though, e.g., printf %s\\n "$*" instead of echo "$@". Try them out, easy to see why, as with one thing to format and multiple arguments, `printf %s\\n "$@"` is equivalent to `for i in "$@" ; do printf %s\\n "$i" ; done`

- when using xargs, use -0 if available, or at least -d\\n if available (busybox doesn't have it for example). also usually want to use -r

[predictabl3]

And then run shellcheck because even those of us that painful have this seared into our brains make mistakes.

Or just use a scripting language that eliminates many of these headaches (nushell) or a real programming language.

I get it, I really do. At least now I have nushell for some sanity, but I still find myself constantly writing a shell script and then realizing after a few iterations that I should've just written in nushell/Rust.

As a thought experiment, how many places rolled out acme.sh to prod and didn't bother code reviewing it or running it through shellcheck?

[dundarious]

Every language exists on this spectrum, and pretty much every language is clustered near shell. All languages require you to be "principled" in a few key areas, and many projects (open source and closed source) don't do a great job at that.

At least shell is good at a specific and very useful thing (sequences and pipelines of other commands), and is already installed on most machines -- even windows nowadays since almost everyone has git installed. My "build system" for C projects is just doing the following from pwsh: `& "$env:GIT_INSTALL_ROOT\bin\bash.exe" .\build.sh`

Most software is not great. That is the issue.

[predictabl3]

I'm happy (and spoiled) that I live in a world where I get to use reliable software and not worry about it being inaccessible. With a single nix command, I'm dropped in an environment with secrets mounted by a single age key, with all programs and configuration exactly as I want. It's trivial for me to "just switch" to nushell/rust and not worry about such things. And nushell and rust are not clustered near shell for the aspects I'm talking about in this discussion.

"bash is everywhere" is just more lipstick on the pig, in my strong opinion.

[superkuh]

People write in bash because you can expect bash to be forward compatible with how people write bash. A bash script written by the average person today will run on a bash interpreter from 2006 (or 2023). Very few languages have the developer culture to achieve this in practice even if it might be possible in theory. And it's not like Bash doesn't get new features. It does constantly. But unlike, say, Rust or JS, the developers don't instantly start using forwards incompatible features. It's a different mindset. If you're writing in shell you're writing for longevity and compatibility.

Unfortunately requiring approval and authentication from a random incorporated entity running a CA every 90 days is inherently complex. And all the ACME protocol implementations do is hide that inherent complexity by adding even more. CA TLS HTTP is very fragile but it could be made less so if corporate browsers didn't demand short lifetime certs-- a demand reasonable for businesses but not for human people or things expected to last longer than a few years without being touched.

[predictabl3]

This doesn't make any sense to me. Stable Rust is forward compatible just as much as shell scripts are. Bash, for example, does introduce things in newer versions and they're near universally ignored.

All of this also excludes that the fact that your shell script will be just as janky in 10 years as it is now. Again, I regularly, regularly see shell scripts from companies that HN fawns over that don't pass shellcheck and have inherent issues that don't occur in better scripting languages, or full programming languages.

"Forward-compat" is not unique, and not a value proposition to me if it inherently means less reliable function.

[superkuh]

Here's an anecdote to provide sense. I recall when I was using a 3 month old (1.48.0 2020-11-19) rustc on Debian 11 (right before it was officially released) and I kept running into rust software I couldn't compile because rust devs used bleeding edge 1.50 (2021-02-11) features. This wasn't a debian is old thing. The rustc was literally 3 months old at this point. At least one of the devs was a person I knew on IRC. He was kind enough to re-write it ("plotsweep" a rust software defined radio program) using only 1.48 and older features. But that's the exception. Most rust devs assume your toolchain is from 3rd party out-of-repository and latest and think forwards compatibility is useless like you do.

Shell scripts can be and often are jank. But at least it's stable jank. Shell devs tend to write portable, stable code because that's the entire point of dealing with the shell jank.

[predictabl3]

Yeah, I think we're not going to agree on this. I very much like living in a world where I get to use stable, released software, provided by my distro, to build reliable software that is forward compatible.

> This wasn't a debian is old thing.

From my reading and understanding, yeah, it was.

[bheadmaster]

Three months old software is new enough to be in Arch repository, so in this case it's not about Debian being old, it's about rust devs using bleeding edge features.

If you're contradicting a person's argument ("yeah, it was") at least provide some more explanation, otherwise your comment is rarely more than a "is too!".

[yjftsjthsd-h]

Shell is a bad fit for many uses (an ACME client is more ambitious than I would build in shell, personally), but the things it's good at, it's really good at. I have yet to find anything else that's even close to as good for glue code when I have a handful of tools and/or a bunch of files that I need to string together. Unless you're writing in Ada, I promise whatever language you think is better has its own sharp edges (if we're allowing eval, then not many languages are going to be safe, really).

[Bystroushaak]

I usually replace shell scripts with python (using sh module: https://amoffat.github.io/sh/ for calling other scripts/programs).

[pdimitar]

Golang is better suited for this, for my needs at least.

[ianlevesque]

Yeah, lego-acme is a solid alternative.

https://github.com/go-acme/lego

[yjftsjthsd-h]

Er, are we comparing ACME clients or shell alternatives?

[cozzyd]

yeah until your scripts stop running someday because python...

[Bystroushaak]

Can you elaborate?

[cozzyd]

Python scripts will often break with system upgrades, most acutely when Python2 went away, but under many other circumstances as well.

[yjftsjthsd-h]

I would expect python2 to only have gone away across major versions of an OS, which is about as non-disruptive as it could have been, considering.

Of course, as I write this ansible is broken on one of my machines for reasons that appear to stem from a python 3.x->3.y update, so...

[broknbottle]

macOS doesn’t even come with Python..

[monetus]

Ever tried TCL? Curious on your thoughts.

[electroly]

This is a Chinese CA, I don't think there was a danger of any of us using it, and none of them are here to receive this criticism. Most of your complaints are about the shell script that the Chinese CA is injecting and that's... not really the problem at all. It's amazing that it's not literally a rootkit; that's what I expected when they said a Chinese CA was injecting a shell script that acme.sh was running. You're missing the forest for the trees here.

This doesn't get better if they had injected a better-written script or a Rust program or whatever else. They could still have injected anything, and that's the problem. The people who wrote acme.sh (different people than the Chinese CA), which has the security vulnerability that the Chinese CA exploited, might have some soul-searching to do.

[catkitcourt]

I had wrote some shell software (~5k loc without comment i think?) and agree.

I was using shell because the project want to maintain compatibility between different distros (including some weird customized one without `ps` and `sed`), but that's all. Shell is not a good choice for things other than scripting.