[alexjurkiewicz]

(2024)

My favourite part of these tools is the zany use of numbered file descriptors. `keypair` outputs the public key on fd 5 and secret key on fd 9. But signing reads the secret key on fd 8, while verification reads the public key on fd 4! Why aren't they the same?? I have to read the manpage every time.

[Retr0id]

I'm curious, what do you actually use it for?

I'd have otherwise guessed that this tool mainly exists just to test lib25519. Personally I'd only ever want a library, or some higher-level tool. A CLI tool that just does raw signing feels like a weird (and footgun-shaped) middle ground.

[tptacek]

This mostly exists to test lib25519 and ostensibly to build systems with shell scripts (though: few people would do that). It is a weird and footgun-shaped middle ground.

[XorNot]

It's why no one has succeeded in replacing GPG: you need a lot of systems to work in order to have an actual viable one, the ability to spit out signatures from keys is required but not sufficient.

[Fnoord]

> I'm curious, what do you actually use it for?

FTA:

> These tools allow lib25519 to be easily used from shell scripts.

I've never used ed25519-cli, but not having to use a library is nice for someone who isn't a programmer.

[gnull]

That's such a user-hostile design decision. I can't fathom what justifies it (other than kinky taste).

Makes your commands unreadable without a manual, leaves a lot of room for errors that are quietly ignored. And forces you into using a shell that comes with its own set of gotchas, bash is not known to be a particularly good tool for security.

And to those who stay this adds flexibility: it doesn't. Those file descriptors are available under/dev/fd on linux, with named options you can do --pk /dev/fd/5. Or make a named pipe.

[minitech]

> Those file descriptors are available under/dev/fd on linux, with named options you can do --pk /dev/fd/5.

If you have a procfs mounted at /proc and the open syscall to use on it, sure (and even then, it’s wasteful and adds unnecessary failure paths). Even argument parsing is yet more code to audit.

I think the design is pretty good as-is.

[PunchyHamster]

it being option can be nice if you don't want your keys touching disk and need to pass it over to other apps.

it being default is insanity

[jedahan]

I was wondering the same thing. My best guess is that is to guard against operator misuse. Like usb-a only plugging in one way. Anything that is secret will never accidentally print to stdout. String interpolation in bash with `—option $empty` might be safer than `8<$empty`. Have to explore more but yeah, this is a new pattern for me as well.

[yellowapple]

Another possible factor driving the decision to use numbered file descriptors: the logic to validate that a file exists (or can exist) at a given path, is readable/writable, etc. gets punted to the shell instead of being something the program itself has to worry about.

[gnull]

Those descriptors like 5 could be mapped to anything, including descriptor 1, stdout.

[chuckadams]

What a strange convention. I'm partial to minisign, which works on plain old files.

[tptacek]

This little CLI is not meaningfully an alternative for signify/minify. Here's a good piece on signify from its author (who also comments here):

https://www.openbsd.org/papers/bsdcan-signify.html

[alfiedotwtf]

I’m guessing it’s to support the test framework it’s built with?

[PunchyHamster]

support is fine. Being default is crazy

[pseudohadamard]

It's djb's web site so it's a djb design. With great genius comes great different thinking.