6 ms·
> It looks as though cryptkeeper makes assumptions about encfs' command-line interface that are no longer valid. This looks like a developer mistaking a comman
by jhdevos 10y 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)
- mhogomchungu 10y agoIt seems to be,look at documentation for option "-S" here: https://linux.die.net/man/1/encfs https://linux.die.net/man/1/encfs
- makomk 10y agoThere's a warning against using -S for filesystem creation, and the --standard option exists to avoid this problem.
- hueving 10y agoIf 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.
- JoshTriplett 10y agoBetter yet, don't offer a CLI as the primary interface; provide a reasonable library to use instead.
- notheguyouthink 10y agoThough, that only works for the language that you use. Other languages may opt to use the CLI as the API
- raverbashing 10y agoThinking 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
- JoshTriplett 10y ago> 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.
- raverbashing 10y agoYes, 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
- zimbatm 10y agoA 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.
- JoshTriplett 10y agoA C library, or a library with a C interface, is usable by any language with an FFI.
- 3pt14159 10y agoThat'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.
- deong 10y agoI 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.
- marcoperaza 10y agoOne of the important lessons that the profession has yet to fully internalize is that there is very little software that is NOT security-related.
- Kalium 10y agoIt's very, very difficult to get product managers to internalize that there are real security restrictions on how they can enable users to make things pretty. Almost everything is security-related. Almost nobody is willing to work with this.
- chaosfox 10y agoits 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/ https://xkcd.com/1172/
- marcoperaza 10y agoIt'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.
- tangus 10y agoI 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.
- woah 10y agoCan you go over some good ways to use expect to avoid this type of issue?
- tangus 10y agoYou 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 }
- deleted 10y ago[deleted]
- burnbabyburn 10y agoexpecially for a tool intended for those use cases as encfs.
- GFK_of_xmaspast 10y agoAKA the unix philosophy.
- travisby 10y agoThanks 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
- kdeldycke 10y agoMaybe implementing a mandatory '--json' flag to all our favorite CLIs might solve the issue of parseable outputs once and for all.