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

51–60 of 111 posts

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

#51

Post by 9dev »

chx wrote: post #31
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 am doing docker run -it --rm certbot/certbot Is there a problem with that?

I wouldn’t call it a problem, but let’s hear what the Certbot docs have to say:

> this mode of operation is unable to install certificates or configure your webserver, because our installer plugins cannot reach your webserver from inside the Docker container. > > Most users should use the instructions at certbot.eff.org. You should only use Docker if you are sure you know what you are doing and have a good reason to do so.

These problems are solvable if you know what you do, but the whole premise of ACME was making it easier to obtain certificates; plus, I shouldn’t need to decide between an autonomous and hostile package manager or keeping a container environment running, secure, and configured - to set up bloody TLS certificates for a Webserver. That said, good for you if it works :)

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

#54

Post by [deleted] »

8organicbits wrote: post #48
rini17 wrote: 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

[deleted]

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

#56

Post by chx »

9dev wrote: post #51
chx wrote: post #31

Earlier quoted context omitted.

I am doing docker run -it --rm certbot/certbot Is there a problem with that?

I wouldn’t call it a problem, but let’s hear what the Certbot docs have to say: > this mode of operation is unable to install certificates or configure your webserver, because our installer plugins cannot reach your webserver from inside the Docker container. > > Most users should use the instructions at certbot.eff.org. You should only use Docker if you are sure you know what you are doing and have a good reason to…

I mount webserver docroot and /etc/letsencrypt directories into the certbot container, /docroot and /etc/letsencrypt mount points respectively, it is totally prepared for this.

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

#57

Post by eyegor »

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.

I wish everything in linux land just had an AUR equivalent.

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

#58

Post by BadBadJellyBean »

lrvick wrote: post #19
nullify88 wrote: post #15

Earlier quoted context omitted.

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?

Absolutely there is still supply chain risk there. But less risk in 3 dependencies than 300.

3? You think you underestimate the number of libraries your software uses.

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

#59

Post by enkrs »

systemz wrote: post #43
enkrs wrote: post #8

Earlier quoted context omitted.

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

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.
Post reply on HN