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

81–90 of 111 posts

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

#81

Post by rini17 »

exceptione wrote: post #71
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.

In my experience Python software is not really nice when it comes to distribution. Hate the venv stuff and pip install hassles. Besides, it is slow. Honestly, if runtime interpretation is a requirement, PHP would be better then in these respects.

You can do letsencrypt stuff using python standard library, without touching pip and virtualenv. This is my own weekly cron script, unchanged since 2020, with openssl(which is usually preinstalled) and acme_tiny.py with system python. You can easily check what the script is doing by adding set -x and acme_tiny.py is quite readable too. Unlike the monstrosity above.

#!/bin/sh

set -eu

set -o pipefail

cd /home/letsencrypt

openssl verify -CAfile lets-encrypt-x3-cross-signed.pem -attime `date -d 'next month' '+%s'` mah_domain.crt | grep expired || exit 0

DT=`date "+%Y%m%d"`

python3 acme-tiny/acme_tiny.py --account-key account.key --csr mah_domain.csr --acme-dir /srv/www/mah_domain/htdocs/.well-known/acme-challenge/ > signed_${DT}.crt

curl -sO https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.p...

cat signed_${DT}.crt lets-encrypt-x3-cross-signed.pem > mah_domain_chained_${DT}.pem

mv mah_domain_chained_${DT}.pem mah_domain_chained.pem

mv signed_${DT}.crt mah_domain.crt

set +e

nginx -c /srv/nginx/conf/nginx.conf -s reload

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

#82

Post by jasongill »

IshKebab wrote: post #72
justsomehnguy wrote: post #66

Earlier quoted context omitted.

> It is installed pretty much everywhere Yes, but which version?

3.6 is pretty much universally available at this point.

RHEL 7 (which still has 4 years of extended lifecycle support left) ships with Python 2.7.5

MacOS Sonoma (the latest version) doesn't include Python at all; older versions of MacOS which are still supported ship with Python 2.x

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

#83

Post by justsomehnguy »

cyanydeez wrote: post #70
justsomehnguy wrote: post #66

Earlier quoted context omitted.

> It is installed pretty much everywhere Yes, but which version?

Hase the json module api chnged in the past decades?

https://news.ycombinator.com/item?id=40100587

Not the modules, but Python itself.

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

#84

Post by arisudesu »

bananskalhalk wrote: post #16
arisudesu wrote: post #14

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.

I am not familiar with zsh, but is it really interpreted by zsh? Because the script has #!/usr/bin/env bash in its shebang, isn't it executed by bash on your system, even if launched from zsh?

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

#85

Post by rini17 »

jasongill wrote: post #82
IshKebab wrote: post #72

Earlier quoted context omitted.

3.6 is pretty much universally available at this point.

RHEL 7 (which still has 4 years of extended lifecycle support left) ships with Python 2.7.5 MacOS Sonoma (the latest version) doesn't include Python at all; older versions of MacOS which are still supported ship with Python 2.x

Even python2 is muchly preferable to bash/awk, thanks.

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

#86

Post by arisudesu »

keybored wrote: post #49
arisudesu wrote: post #14

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

Bash is a shell script. Posix is not implied.

This script is explicitly a Bash script and it is not executable by every other shell present on modern unix-like systems. Examples are Korn shell, Almquist shell. Hence the distinction: if one states that the script is a shell-script, it implies that it can be interpreted by any modern shell, for which there is only one common denominator, POSIX. This script is explicitly only Bash shell compatible, not any-shell compatible.

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

#87

Post by ale42 »

BadBadJellyBean wrote: post #75
lrvick wrote: post #9

Earlier quoted context omitted.

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.

I 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.

The OS itself depends on many libs ;-)

The only things that are a bit heavy in the list are openssl and curl. Still, they are relatively self-contained tools, nothing to do with the dependency hell of certbot.

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

#88

Post by arccy »

vbezhenar wrote: post #63
nickf wrote: post #50

Earlier quoted context omitted.

APILayer = ZeroSSL

ZeroSSL are the only ones providing certificates for IP addresses and free year-long certificates. Cudos to them for disrupting this market, almost monopolized by letsencrypt. Don't have high hopes, though, big players probably will kill them as they killed other free certificate issuers. For some reason letsencrypt status-quo as the only free certificate issuer benefits big players.

letsencrypt is hardly the only free cert issuer. even google offers them https://security.googleblog.com/2023/05/google-trust-service...

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

#89

Post by 9dev »

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

Earlier quoted context omitted.

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.

How did you implement reloading the modified TLS certificates after renewal tho?

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

#90

Post by arccy »

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.

python hasn't been installed by default in almost any env i've worked in for the past ~5 years

maybe for dev environments, but certainly not for servers

Post reply on HN