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

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

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.

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.

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.

They were also suggesting that user's ran the utility as root...

All really shady...

What the ACME protocol wants to do is hand over a CSR (Certificate Signing Request), and get back a certificate, and to achieve that it has to explain how you'll prove you're entitled to such a certificate.

Most ACME clients will also make a suitable proof (in at least some cases), and also generate a suitable CSR from first principles, for which they will need to generate a new private key - but that's not a necessary part of the system, and it's certainly not rare to generate your own CSR, either because you must technically, or because your own security processes say strange women, lying in ponds, distributing swords is no basis for a system of government sorry, I mean, that this key is private and shouldn't be on the host running ACME services.