5 ms·
Using it for years in DNS mode, works like a charm
by ibbtown 2y ago
Using it for years in DNS mode, works like a charm
- H8crilA 2y agoWhy would you use this for anything else than a joke given that Certbot exists, and is even in most repositories? (asking seriously)
- lrvick 2y agoCertbot 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.
- BadBadJellyBean 2y agoPeople 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.
- lrvick 2y agoIf 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.
- nullify88 2y agoWouldn'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?
- semi-extrinsic 2y agoI 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.
- lrvick 2y agoAbsolutely there is still supply chain risk there. But less risk in 3 dependencies than 300.
- BadBadJellyBean 2y ago3? You think you underestimate the number of libraries your software uses.
- lrvick 2y agoI 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.
- BadBadJellyBean 2y agoHow is that in any way realistic? Most people don't bootstrap Linux systems. And just because it is pre-installed doesn't make it safe. Most software on a modern Linux distribution is dynamically linked to several libraries which might depend on other libraries.
- 2y ago
- BadBadJellyBean 2y agoI saw the following programs whil skimming the code: awk, grep, curl, getent, sudo, mkdir, mv, ln, cat, rm, openssl, touch Most of these have around 10 dependencies on libs. Don't misunderstand me. I have nothing against the script. I just don't like the argument that bash is better because it has no dependencies.
- rany_ 2y agoIt 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.
- radiowave 2y agoYup, 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.
- enkrs 2y agoExactly. 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.
- systemz 2y agoDehydrated and acme.sh seems different. Is one of them fork? https://github.com/acmesh-official/acme.sh https://github.com/acmesh-official/acme.sh https://github.com/dehydrated-io/dehydrated https://github.com/dehydrated-io/dehydrated
- enkrs 2y agoBrainfart 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.
- nullify88 2y agoWith that rationale, why not use https://github.com/go-acme/lego https://github.com/go-acme/lego which is a self contained lets encrypt client in Go?
- lrvick 2y agoStatic binary, sure, but hardly a tiny supply chain attack surface: https://github.com/go-acme/lego/blob/master/go.sum 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.
- chrisweekly 2y agoAre you saying that any use of Alpine is, by definition, a supply-chain security problem?
- lrvick 2y agoI 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. https://codeberg.org/stagex/stagex https://codeberg.org/stagex/stagex
- chrisweekly 2y agoThanks for the detailed response! EDIT: Also, stagex looks pretty compelling; I hope it catches on!
- 9dev 2y agoThe 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 recommend to use Snap instead. It’s an insult for professionals.
- bakugo 2y ago> the Certbot team advertises alternative install methods, of which none work I've only been using it for a little while, but the pip + venv method seems to work decently well: https://certbot.eff.org/instructions?ws=other&os=pip https://certbot.eff.org/instructions?ws=other&os=pip
- 9dev 2y agoDid you see that bold disclaimer on top? > Partial support > The Certbot team supports this installation method on a best effort basis. If you are on a more obscure or heavily customized system, these instructions may not work and the Certbot team may be unable to help you resolve the problem. This is an instant no-go for any professional environment I ever worked in.
- crispyambulance 2y agoYep, this. So ridiculous to have to install yet another package manager, snapd, to get certbot installed "the easy way". The alternative to get around snapd works fine (IMHO, for my situation, a lightsail instance running amazon linux 2023 where installing snapd is a pain in the ass), but you still have to jump through some hoops.
- candiddevmike 2y agoI'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.
- mholt 2y agoThe 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-traefik-replace-certbot https://www.eff.org/es/deeplinks/2024/03/should-caddy-and-tr...
- sirn 2y agoOne 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/dns-verification.md https://github.com/dehydrated-io/dehydrated/blob/master/docs... [2]: https://github.com/AnalogJ/lexicon https://github.com/AnalogJ/lexicon [3]: https://github.com/dehydrated-io/dehydrated/wiki https://github.com/dehydrated-io/dehydrated/wiki
- groestl 2y agoUsing it with Hetzner DNS API that way.
- blackfawn 2y agoDoes DNS mode work to issue for internal servers that don't expose 80/443 to the internet?