Certbot is a massive pile of dependencies that you need to care and feed and update. You should not need 100s of megs of nonsense for something that can be done with a shell script.
It doesn't even work well in my experience. ACME.sh is a lot more hassle free, I've always had issues with Certbot's DNS verification.
Basically I'm not avoiding Certbot to make a point, I just think it's inferior for my specific use cases. I don't know about Dehydrated but I also expect it to be BS free.
Yup, I gave up on certbot after trying to understand why I couldn't get the Digital Ocean DNS plugin to work, which is maintained as part of the Certbot repo. (This was a few years ago, so details may have changed.)
I discovered the issue was that the plugin does some pretty broad-brush guesswork about which domain in your DNS hosting it should actually populate with the response value. If you own a bunch of similar domain names (as many orgs do), the plugin may guess wrong.
Much happier to be using dehydrated, and I don't regard it as a major impediment that I had to spend 10 minutes hand writing the necessary API call to the DNS provider.
Brainfart from my side. When I first installed dehydrated.sh it was originally named letsencrypt.sh (not acme.sh) and later renamed to dehydrated. That was quite a while ago.
I am, yes. Alpine is not full-source-bootstrapped, often imports and trusts external binaries blindly, has no signed commits, no signed reviews, no signed packages, and is not reproducible. It is one phished git account away from a major supply chain attack any day now.
Alpine chooses low security for low contribution friction. It is the Wikipedia of Linux distros, which granted it a huge package repository fantastic for experimental use and reference, but it is not something sane to blindly trust the latest packages of in production.
It is one of the reasons why I made stagex, which in most cases is a near drop-in replacement.
People are always talking like shell scripts are without dependencies. Shell scripting ist mostly piping program outputs to different programs, that have dependencies on libraries themselves. Each of them have to be kept up to date to stay secure. Just because they are mostly preinstalled on the system doesn't make them not a dependency.
This, together with the fact that most shell scripting is bash based which is, in my opinion, not a very good language, makes it less secure to me than a python tool.
If it is just a few curl and openssl commands, why make a user install hundreds of megs of python deps just to ultimately call mostly openssl commands anyway
One of the biggest risks today is supply chain attacks. The more dependencies you have, the more people you are giving the ability to tamper with your critical code paths.
The only things that are a bit heavy in the list are openssl and curl. Still, they are relatively self-contained tools, nothing to do with the dependency hell of certbot.
Wouldn't this bash script be just as susceptible to supply chain attacks? What dependencies does openssl, cURL, sed, grep, awk, mktemp pull in, and could it be vulnerable to attack like we saw with xz?
I think the point is to minimize the total attack surface on a system. If the bash script only depends on programs like those you list, which Linux distros package as default anyway, the shell script has not introduced any new dependencies on your system.
> Wouldn't this bash script be just as susceptible to supply chain attacks? What dependencies does openssl, cURL, sed, grep, awk, mktemp pull in, and could it be vulnerable to attack like we saw with xz?
All the packages listed are already probably installed on your system, so you have to worry about their integrity already (your system package manager (RPM, Deb) probably leverages them).
Something like Certbot pulls in dependencies on top of what your system already has, whereas Dehydrated or Acme.sh use tools that you already have to worry about anyway because they're part of the base OS.
I’m pretty sure every open source repository ever created is vulnerable to “an attack like we saw with xz,” and by that I mean a labyrinthine, multi-year effort involving highly sophisticated exploits combined with psychological manipulation, coordinated sock-puppets, global actors, and deep intrigue—to the extent that it’s absurd to cite as a threat that “dependency management” can meaningfully prevent.
I actually full source bootstrapped a Linux distribution from zero recently. Most distros have a lot of dependencies you do not need.
In this case you only actually need curl, openssl, and busybox. Those depend on at least a small libc implementation and a kernel but those are certainly already present.
Coreutils or busybox is probably already installed too. Still, I will grant the requirement of musl and a linux kernel since we are being pedantic or maybe talking about an embedded linux use case, so 5 deps total to boot from metal and get a cert.
To be fair I would never actually ship openssl or busybox in a real embedded project. Would probably write a simple standalone binary using the standard library of Go or something.
Basically I'm not avoiding Certbot to make a point, I just think it's inferior for my specific use cases. I don't know about Dehydrated but I also expect it to be BS free.