Hacker News new | ask | show | jobs
by jhdevos 3420 days ago
> It looks as though cryptkeeper makes assumptions about encfs' command-line interface that are no longer valid.

This looks like a developer mistaking a command line interface for an API.

Unless an (interactive) CL interface is explicitly marked as being an API, and documented in such a way, and regression tests exist to make sure the interface remains backwards-compatible - you should never program against it. Ask for a proper API to access.

(edit: formatting)

4 comments

If you offer a cli with output reasonable to parse as a text stream, assume someone is going to script against it and don't change the args without detecting and warning on the old usage.
I agree, but if a script is going to use the CLI then it's the script's responsibility to parse the prompts and not to blindly send strings to the program. `expect` exists since 1990, use it or reinvent it.
Can you go over some good ways to use expect to avoid this type of issue?
You simply use it to wait for the appropriate prompt before sending anything. If the expected prompt never arrives, something is wrong (CLI changed), so abort. The snippet for this particular case could be something like

    set timeout=1
    expect {
      "enter \"p\" for pre-configured paranoia mode"  { puts p\n }
      timeout     abort
      eof         abort
    }
Better yet, don't offer a CLI as the primary interface; provide a reasonable library to use instead.
A CLI is usable by any language that can fork/exec and read/write IO. A library is more likely to be usable by only one language.
A C library, or a library with a C interface, is usable by any language with an FFI.
That's true in theory, but in practice most Ruby developers don't know how to use C or the FFI well enough to build a library out of a C or C++ library.

It's reasonable to shell out sometimes. It's what Github did when they were first starting. It's what 500px did when they were first starting. Trying to do everything the right way early on is just going to slow you down.

I think with security-related software in particular, the proper answer there is "tough". If you can't figure out how to call a C function, you should probably just not write critical software.
OTOH, a C library will almost certainly be unsafe and insecure, while POSIX pipes can be secure.
Exactly what I had in mind when I said "or a library with a C interface".

(Someday, I hope we have a better cross-language ABI than C.)

Thinking a bit about this problem, I'm a bit torn

In one side, a CLI offers a "better" way of using the product (as with a library it's easier to misuse something)

On another, issues like this

(But I guess in this specific case the issue is that encfs is not doing a minimal validity check of the password being provided)

It would be good if CLIs would/could be more consistent, but in the Unix/Gnu options world, probably it won't

> In one side, a CLI offers a "better" way of using the product (as with a library it's easier to misuse something)

A CLI provides a better interactive interface, but a terrible programmatic interface.

Yes, it is awful in the programmatic sense, I don't want to assemble command lines by hand or parse error messages

It is nice in the conceptual sense, because it usually fits the common use cases

Though, that only works for the language that you use. Other languages may opt to use the CLI as the API
expecially for a tool intended for those use cases as encfs.
its not up to the developer to guess all the wrong ways[1] users are using the software. such changes will be described in the changelog, I expect you read that if you are updating the software.

1. https://xkcd.com/1172/

It's worth noting that what is arguably the largest and most successful software project in history, Microsoft Windows, has succeeded in large part because of an obsession with maintaining backwards compatibility, even with the "wrong" ways of using the software.
AKA the unix philosophy.
Thanks for posting this. I was working on a chrome native messaging extension to talk to GPG... and I was just using the CLI. You're right, that's not the right solution, even if learning their API is more work.

I'm going to do some refactoring now

It seems to be,look at documentation for option "-S" here: https://linux.die.net/man/1/encfs
There's a warning against using -S for filesystem creation, and the --standard option exists to avoid this problem.
Maybe implementing a mandatory '--json' flag to all our favorite CLIs might solve the issue of parseable outputs once and for all.