Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

21–30 of 111 posts

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

#21

Post by lrvick »

nullify88 wrote: post #11
lrvick wrote: 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.

With that rationale, why not use https://github.com/go-acme/lego which is a self contained lets encrypt client in Go?

Static binary, sure, but hardly a tiny supply chain attack surface: https://github.com/go-acme/lego/blob/master/go.sum

Also their official builds are built with Alpine which is a hobby distro that does not even do signed code or packages.

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

#23

Post by johnisgood »

candiddevmike wrote: post #18
9dev wrote: 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.

Same. I have a couple of comments as to why snap is awful.

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

#24

Post by [deleted] »

9dev wrote: post #10
H8crilA wrote: post #3

Earlier quoted context omitted.

Why would you use this for anything else than a joke given that Certbot exists, and is even in most repositories? (asking seriously)

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…

[deleted]

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

#25

Post by mholt »

H8crilA wrote: post #3
ibbtown wrote: post #2

Using it for years in DNS mode, works like a charm

Why would you use this for anything else than a joke given that Certbot exists, and is even in most repositories? (asking seriously)

The EFF themselves recently explored the question whether Certbot should just be replaced with servers like Caddy. https://www.eff.org/es/deeplinks/2024/03/should-caddy-and-tr...

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

#27

Post by eigenvalue »

I don’t get why people are saying it’s hard to install Certbot. I just do:

  sudo apt install certbot python3-certbot-nginx
And it “just works” on Ubuntu. The whole thing is super easy and takes around 1 minute to get a cert installed and configured with nginx.

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

#28

Post by vbezhenar »

eigenvalue wrote: post #27

I don’t get why people are saying it’s hard to install Certbot. I just do: sudo apt install certbot python3-certbot-nginx And it “just works” on Ubuntu. The whole thing is super easy and takes around 1 minute to get a cert installed and configured with nginx.

Not everyone's happy to allow certbot to change nginx configs. I never tried it and I'll never try it.

Also not everyone wants to install few dozens of packages just for this little thing.

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

#29

Post by sirn »

H8crilA wrote: post #3
ibbtown wrote: post #2

Using it for years in DNS mode, works like a charm

Why would you use this for anything else than a joke given that Certbot exists, and is even in most repositories? (asking seriously)

One of the biggest benefits of dehydrated is that it doesn't try to integrate with a DNS provider on its own. It just connects to ACME server and calls a hook, which can be implemented with a simple shell script[1]. The most popular third-party integration is lexicon[2], though you're not required to use Lexicon. (e.g. you're free to use awscli, gcloud, linode-cli, etc. to do the actual DNS record manipulation)[3]

This means its dependencies footprint is much smaller, and allows you to do things that can be a nightmare to configure with Certbot or other alternatives. For example, at one of the scenarios I had to set up was that we had to query a credential via HashiCorp Vault, which is then used to cURL into an API endpoint. The shell script in total was pretty short (~200 LOC) and it worked extremely well. The fact the shell script is so simple that I could test adding/removing records without ever invoking ACME process is also a huge benefit.

[1]: https://github.com/dehydrated-io/dehydrated/blob/master/docs...

[2]: https://github.com/AnalogJ/lexicon

[3]: https://github.com/dehydrated-io/dehydrated/wiki

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

#30

Post by throw0101c »

eigenvalue wrote: post #27

I don’t get why people are saying it’s hard to install Certbot. I just do: sudo apt install certbot python3-certbot-nginx And it “just works” on Ubuntu. The whole thing is super easy and takes around 1 minute to get a cert installed and configured with nginx.

> And it “just works” on Ubuntu.

Sure. Now look at the dependencies that are installed compared to dependencies that are installed for dehydrated (or acme.sh, etc) which generally are: bash, OpenSSL, cURL. This is very handy for more appliance-like system (I ran dehydrated on (RH-based) F5s for years before ACME was put into the GUI; also ran it on (FreeBSD-based) Isilons.)

Also, if you want to do an audit of the code, how many lines of Python need to be examined (including dependencies) compared to how many lines of Bash? (Both would have common dependencies like (Open)SSL and HTTP/cURL libraries.) As we saw with the recent XZ kerfuffle, 'software supply chains' are becoming important.

Personally I find it much easier to understand / configure dehydrated:

    $ git clone https://github.com/dehydrated-io/dehydrated.git
    $ sudo cp dehydrated/dehydrated /usr/bin/
    
    # cat > /etc/dehydrated/config
    WELLKNOWN="/var/www/htdocs/.well-known/acme-challenge"
    CONTACT_EMAIL="you@example.com"
    # cat > /etc/dehydrated/domains.txt
    example.com www.example.com
    # mkdir -p /var/www/htdocs/.well-known/acme-challenge

    $ sudo dehydrated -c
(Ubuntu/Debian has packages for it as well.)
Post reply on HN