5 ms·

...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 t

by d33 6y ago

...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?)

e12e 6y ago
There already is a gpg Api - gpg me (made easy): https://www.gnupg.org/related_software/gpgme/ 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 https://wiki.gnupg.org/APIs
- deleted 6y ago
  [deleted]
- capitol_ 6y ago
  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.
chromedev 6y ago
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
amluto 6y ago
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.
- R0b0t1 6y ago
  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.
- axaxs 6y ago
  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.
- jcranmer 6y ago
  ffmpeg is pretty nasty as well, and I don't have much fondness for ImageMagick's command line either.
  - dgellow 6y ago
    They are both old and really complex tools, that explains part of it.
  - smichel17 6y ago
    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.
- forty 6y ago
  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.
dane-pgp 6y ago
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-stateless-cli-02 https://datatracker.ietf.org/doc/html/draft-dkg-openpgp-stat...
- digianarchist 6y ago
  Looks like it expired on September 7th. Does that mean it's not being considered?
amenghra 6y ago
mkisofs wins the trophy imho.
agumonkey 6y ago
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.
mjw1007 6y ago
You can see the help for the proposed `sq` command line interface here: https://docs.sequoia-pgp.org/sq/index.html https://docs.sequoia-pgp.org/sq/index.html Thought the article says they're not planning to release this with v1.0
mlindner 6y ago
The git command line is very good actually, and constantly improving.

by d33 6y ago

e12e 6y ago

There already is a gpg Api - gpg me (made easy): https://www.gnupg.org/related_software/gpgme/ 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 https://wiki.gnupg.org/APIs

deleted 6y ago
[deleted]
capitol_ 6y ago
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.

chromedev 6y ago

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

amluto 6y ago

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.

R0b0t1 6y ago
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.
axaxs 6y ago
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.
jcranmer 6y ago
ffmpeg is pretty nasty as well, and I don't have much fondness for ImageMagick's command line either.
- dgellow 6y ago
  They are both old and really complex tools, that explains part of it.
- smichel17 6y ago
  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.
forty 6y ago
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.

dane-pgp 6y ago

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-stateless-cli-02 https://datatracker.ietf.org/doc/html/draft-dkg-openpgp-stat...

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

amenghra 6y ago

mkisofs wins the trophy imho.

agumonkey 6y ago

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.

mjw1007 6y ago

You can see the help for the proposed `sq` command line interface here: https://docs.sequoia-pgp.org/sq/index.html https://docs.sequoia-pgp.org/sq/index.html Thought the article says they're not planning to release this with v1.0

mlindner 6y ago

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