Hacker News Reader

Hacker News

Comment by rini17 | Hacker News Reader

Parent Full thread

rini17

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.

View on HN

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

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

The point of using '#!/usr/bin/env python3' is that you don't have to mess with virtual environments.

Using this exact shebang line signals "This script is intended to be executed directly (not a python module) and it only needs the python3 standard library."

Surely it could just include jq.

https://jqlang.github.io/jq/

I would not trust that script. If Python is such a hassle then there is also Lego: https://github.com/go-acme/lego which supports tons of DNS providers and is very well documented.

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

Interesting how that was achieved. Most popular Linux distributions are very hard to install without python3 an perl5. LSB https://refspecs.linuxfoundation.org/lsb.shtml defines them as standard.

Maybe not so hard as you might think. On my openSUSE desktop, uninstalling python3 would remove only calibre and virt-manager. Most of my server/container/vm installs don't have any python version. Perl isn't much harder to get rid of depending on the use case, for example some development stuff uses it.

I'm also not sure distros generally care about LSB. Debian dropped it years ago and did any distro even bother to implement it correctly?

I don't get all these arguments. You would really prefer to use hard-to-check shell script to simply installing system python package if it isn't installed already?

You said distros can't install without python and perl, my argument is the opposite. Shell scripts aren't in the picture.

Why would I want a system level python install?

Because it allows for scripting infrastructure with far fewer obfuscated hacks than bash/awk. And if you use system python, vulnerabilities are more likely to get patched by distribution vendor. Your homebrewn json parsing regexes won't.

> 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

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

I don't think anyone using RHEL 7 is in the target audience for this software. Be realistic.

I don't think you really have any idea what you're talking about, to be honest - there are millions of RHEL 7 and CentOS 7 boxes in production right now, and many of them are serving websites and could benefit from SSL certificates.

I know of a couple large organizations that have tens of thousands of RHEL 7 machines that use letsencrypt for customer websites, and I sent this project to sysadmins on their teams, so it's very realistic to expect that businesses are still using supported software.

Not everyone can just upgrade to the latest version of Ubuntu every 6 months for their production workloads like you might expect.

There are still machines on 2.6 kernels where I work.

> I don't think

> target audience

You != people

And do those machines have web servers exposed to the world?

Do you ask that question to bash me for having an old, unsupported OSes open to the world?

Then address this to the owners of those machines. And get a load of cash ready to give it to them, so they could migrate to somehitng newer.

Yes, why wouldn't they? There are multiple vendors who still provide security updates for CentOS 6

Hase the json module api chnged in the past decades?

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

Not the modules, but Python itself.

Reply on news.ycombinator.com