Hacker News Reader

Comment by d33 | Hacker News Reader

...I really don't want to sound entitled, but while you're at it, could you please only keep the old CLI for compatibility purposes and come up with something that can actually be used? GPG's command line is second only to the one of openssl. And maybe git. It would really help adoption if usability was improved. Having an API instead of just CLI might also help (doesn't Enigmail just run the binary?)

View on HN

Second to openssl? I would rank gpg as the worst by a considerable margin.

Although, come to think of it, tex and its relatives (pdflatex, etc) have really quite terrible command line interfaces.

Importing and managing keys and encrypting messages is something I do via CLI because it is easier to do what I mean, not what some developer thinks I mean. The CLI is more expressive and I don't think to the detriment of usability.

It's just for most people, they're not used to working with a tool that merges communication and text processing with a CLI interface.

I dunno, Openssl CLI is one hairy beast. To be honest I don't really know the best solution to such problems. Smaller, more specialized binaries? I mean, s_client is so vastly different than say, rsa.

ffmpeg is pretty nasty as well, and I don't have much fondness for ImageMagick's command line either.

They are both old and really complex tools, that explains part of it.

At least ffmpeg makes it easy to do the very easiest thing. I don't have to look up this one:

    ffmpeg -i input.file output.file

Now, usually I want to do something more complicated, so I end up having to look it up, but it's hardly the ffmpeg folks' fault that audio and video encoding is such an ungodly mess of different containers and encodings; while it could be better, I think most of its complexity is inherent to the problems it's trying to solve. I do think there's an argument that it tries to do too much, and the complexity could be mitigated if it were split into several smaller tools and a wrapper for the most common commands, like apt.

Agreed, I'm not sure what's wrong with openssl's cli and git's cli (I do agree gpg's sucks).

Those are pretty complex tools that can do many things, so they cannot be expected to be used without learning to use them or reading the manual.

I think the mantra of "Make simple things easy and hard things possible" applies here. These tools all do a poor job of the former.

Now, if you're writing a low-level tool (in git's terminology, plumbing), that doesn't matter as much, because it's designed to be wrapped; maintainability and (interface) stability probably take priority over being maximally intuitive. But if you're writing a tool for end users (including developers), some focus on UX is warranted.

(How much each of these tools are intended for end users, can be argued separately, not by me)

Except that gpg also fails to make the hard things possible.

Want to verify a signed file against a key that’s in another file? Nope, not supported.

Want to load a private key into a smart card without wiping the key from your keyring? Not supported.

In general, gpg has a very strong idea of how you’re supposed to use it, and it makes it very hard to do anything differently.

You can see the help for the proposed `sq` command line interface here: https://docs.sequoia-pgp.org/sq/index.html

Thought the article says they're not planning to release this with v1.0

There already is a gpg Api - gpg me (made easy):

https://www.gnupg.org/related_software/gpgme/

It would probably make sense to implement and expose that?

Ed: see also https://wiki.gnupg.org/APIs

No, this is not a very good suggestion. gpg-me just wraps the gpg binary and relies on a lot of global state, environmental variables for example.

This makes the library really painful to use in multithreaded contexts, or when you need to have a controlled env. (like unit tests).

I use gpg-me in one of my projects, and it's very far from pleasant to use.

There is a proposal for a "stateless command-line interface for dealing with OpenPGP messages" that Daniel Kahn Gillmor brought to the IETF:

https://datatracker.ietf.org/doc/html/draft-dkg-openpgp-stat...

Looks like it expired on September 7th. Does that mean it's not being considered?

I think a good balance between ease and options would be important for a crypto tool. The nicer it is the more people will use it.

The git command line is very good actually, and constantly improving.

mkisofs wins the trophy imho.

Have you ever used tab auto-completion before? GPG's CLI is actually pretty intuitive and self-explanatory. You can also type:

  gpg --help

Or,

  man gpg

Reply on news.ycombinator.com