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

71–80 of 111 posts

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

#71

Post by exceptione »

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.

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

#72

Post by IshKebab »

justsomehnguy wrote: post #66
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.

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

3.6 is pretty much universally available at this point.

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

#73

Post by IshKebab »

akshayshah wrote: post #37

Apparently the author recently sold the project to a company called apilayer: https://lukas.im/2020/01/30/selling-dehydrated/index.html They plan to keep the project open source and employ Lukas to continue maintaining it.

Jesus, not only do people seriously use this but somebody bought it? The world is insane.

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

#74

Post by sirn »

heyoni wrote: post #68
omoikane wrote: post #55

What's the motivation behind closing file descriptors 3 and 4? # Close weird external file descriptors exec 3>&- exec 4>&- From this commit: https://github.com/dehydrated-io/dehydrated/commit/b116e6bc2...

When are those ever used? Is it to customize output for when you’re sending to a file vs terminal?

systemd socket activation opens extra fds starting from fd 3 (SD_LISTEN_FDS_START). Though I can't think of a scenario where this may be relevant for dehydrated. Maybe some weird systemd unit somewhere that invoke dehydrated does this?

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

#75

Post by BadBadJellyBean »

lrvick wrote: post #9
BadBadJellyBean wrote: post #6

Earlier quoted context omitted.

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.

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.

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

#76

Post by kwhitefoot »

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.

Surely it could just include jq.

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

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

#77

Post by lrvick »

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.

busybox, openssl, curl. Done. :)

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

#78

Post by lrvick »

BadBadJellyBean wrote: post #58
lrvick wrote: post #19

Earlier quoted context omitted.

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.

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

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

#79

Post by lrvick »

chrisweekly wrote: post #65
lrvick wrote: post #21

Earlier quoted context omitted.

Static binary, sure, but hardly a tiny supply chain attack surface: 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.

Are you saying that any use of Alpine is, by definition, a supply-chain security problem?

I 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

Post reply on HN