Dehydrated: Letsencrypt/acme client implemented as a shell-script
1–10 of 111 posts
Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script
#2Using it for years in DNS mode, works like a charm
Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script
#3Using 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)
Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script
#4Using 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)
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.
Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script
#5Dehydrated has been my ACME client of choice for many years now. Nice and simple and easy to use.
Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script
#6Earlier 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)
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.
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.
Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script
#7Earlier 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)
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.
Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script
#8Earlier 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)
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.
Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script
#9Earlier 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.
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, i…
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.
Re: Dehydrated: Letsencrypt/acme client implemented as a shell-script
#10Using 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 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.