Ed25519-CLI – command-line interface for the Ed25519 signature system (2024) • Hacker News Board

Post by gnull » Tue, Jan 06, 2026, 5:04 PM UTC

minitech wrote: post #60

gnull wrote: post #55

Earlier quoted context omitted.

Make a named pipe then. Shells have built-in primitives for that. I.e. () subshells in bash, or psub in fish. Or have an option to read either a file descriptor or a file. I can't understand why you keep inflating the difficulty of simple commandline parsing, which the tool needs to do anyway — we shouldn't even be talking about it. Commandline parsing code is done once (and read once per audit) while a hostile user…

(nicer reply to this) Yes, I’m aware of the readability benefit of named arguments, and made the original comment with that awareness too. > Make a named pipe then. Shells have built-in primitives for that. I.e. () subshells in bash, That’s /proc/self/fd again. But okay, you can make a named pipe to trade the procfs mount and corresponding open-for-read permission requirement for a named pipe open-for-write permissio…

I see, you are more focused on providing the core functionality in the simplest way possible from purely technical perspective, and less so on what kind of "language" or interface it provides the end user — assuming someone who wants an interface can make a wrapper. I can see that your points make sense from this perspective, the solution with FDs is indeed simpler from this viewpoint.

I, on the other hand, criticized it as a complete interface made with some workflow in mind that would need no wrappers, would help the user discover itself and avoid footguns. Your interpretation sounds like what the authors may have had in mind when they made it.

> who’s trying to audit use of these tools without the manual?

I'd try to work on different levels when understanding some system. Before getting into details, I'd try to understand the high-level components/steps and their dataflows, and then gradually keep refining the level of detail. If a tool has 2-3 descriptively named arguments and you have a high-level idea of what the tool is for, you can usually track the dataflows of its call quite well without manual. Say, understanding a command like

  make -B -C ./somewhere -k

may require the manual if you haven't worked with make in some time and don't remember the options. But

  make --always-make --directory=./somewhere --keep-going

gives you a pretty good idea. On the second read, where you're being pedantic with details, you may want to open the manual and check what those things exactly mean and guarantee, but it's not useless without the manual either.