Live data from Hacker News

Dehydrated: Letsencrypt/acme client implemented as a shell-script

github.com

41–50 of 111 posts

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#41
I think the amount of alternative ACME clients is a testament to the absolute mess that certbot is.

Constant breakage unless you're using snaps on the most popular distributions. The CLI is absolutely idiotic and convoluted and the plugins do a lot of guess work without informing you, which results in some fun debugging. It's also a large pile of dependencies that take up space.

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#42
I created a k8s deployment which spins up nginx in a job to update TLS secrets with dehydrated because I couldn’t get an admin to install cert-manager. It works great, especially because I had scheduled rebuilds of the base container off of latest images. I left the job 3 years ago, and it’s still running fine and staying ahead of the vuln scanners.

I had also used a pre-shared private key, which I put on a F5 BigIp, and just scheduled a job on the F5 to pull the updated certs daily.

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#43
post #8
post #4

Earlier quoted context omitted.

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.

Exactly. I've been using dehydrated on two servers since it was named acme.sh (pre-2015) and updated it once. It just works and no dependecies.

Dehydrated and acme.sh seems different. Is one of them fork?

https://github.com/acmesh-official/acme.sh

https://github.com/dehydrated-io/dehydrated

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#44

As a bash script actually, not a (implied POSIX) shell script. Do not mix these two.

Seems to work in zsh too. Both bash and zsh are shells like c-shell ksh etc. Nowhere is it implied that shell-scripts are written for Bourne shell.

both bash and zsh are orders of magnitude more complex than sh or even ksh

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#45
Parsing json in shell? Easy!

filter="$(printf 's/.\[%s\][[:space:]]\([^"]*\)/\\1/p' "$(json_path "${1:-}" "${2:-}")")"

Please, no! How can you know this is safe?

Why not just use Python? It is installed pretty much everywhere, supports json without such hacks.

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#46
post #10

Earlier quoted context omitted.

The only joke here is Certbot, a tool intended for use on servers but distributed on a channel intended for consumer use - Snap. The only package manager that will update on its own, when it feels like it, without a killswitch, runs as a daemon intertwined with the system. Icing on the cake is that the Certbot team advertises alternative install methods, of which none work and all of the lengthy guides for them recom…

I'm a simple man, I see a comment complaining about snap and I automatically upvote. It's 2024. If you're still distributing snaps as the preferred method of install, you're alienating your users. AppImage, Flatpak, and regular containers are all far better deployment options.

I wish I could upvote this more... snaps are the worst!

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#48
post #45

Parsing json in shell? Easy! filter="$(printf 's/. \[%s\][[:space:]] \([^"]*\)/\\1/p' "$(json_path "${1:-}" "${2:-}")")" Please, no! How can you know this is safe? Why not just use Python? It is installed pretty much everywhere, supports json without such hacks.

A very relevant question. Acme.sh, a similar shell script ACME client, had a remote code execution problem last year.

https://github.com/acmesh-official/acme.sh/issues/4668

Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script

#50

Apparently the author recently sold the project to a company called apilayer: https://lukas.im/2020/01/30/selling-dehydrated/index.html They plan to keep the project open source and employ Lukas to continue maintaining it.

APILayer = ZeroSSL
Post reply on HN