5 ms·

> but unfortunately gpg is such a terrible program I can't understand what people find to be so bad in it. It took half an hour to learn the basic usage and th

> but unfortunately gpg is such a terrible program I can't understand what people find to be so bad in it. It took half an hour to learn the basic usage and the commands aren't hard to remember at all. Can you please elaborate?

ryan-c 10y ago
That is an order of magnitude more effort than most people are willing to put into it. Try teaching a not-computer-savvy relative to use it and exchange email with them.
- leshow 10y ago
  we're talking about developers signing commits here, not sending emails to your grandma gpg encrypted
DasIch 10y ago
Essentially you want 3 operations. Generate keypair, encrypt X with key, decrypt X with key. You want this as a library that's impossible to misuse and a nice CLI on top. The fact that it took you half an hour to understand the "basic usage" is ridiculous. The GPG developers have failed in the worst possible way when it comes to the design of their software. It's so bad I find it incomprehensible how that could have happened on accident. If they would be working on something non-cryptographic, that would be one thing but for a cryptographic tool that's unacceptable. The design and ease of use is just as important as the cryptographic algorithms themselves for such a tool because any friction causes people to avoid cryptography.
- ashitlerferad 10y ago
  What about signing and verification?
  - DasIch 10y ago
    Right, forgot about those. Still those are just two more commands, which brings us to 5. That shouldn't push the complexity up significantly and doesn't change anything about my argument.
    - ashitlerferad 10y ago
      What about getting someone's key? What about distributing your key? What about backing up your secret keys on paper? What about binding your primary secure key that is usually stored in a safe on a Yubikey with secondary keys stored on Yubikeys you carry around with you? What about revoking a secondary key after a laptop or Yubikey got stolen? Perhaps you see where I'm going with this :) The problem domain is just complex.
- lmm 10y ago
  > Essentially you want 3 operations. Generate keypair, encrypt X with key, decrypt X with key. You need key rotation if you want security, so you need master keys and subkeys (or you'll end up reimplementing them by hand with conventions that everyone will interpret differently). Multiple identities on a key are I guess not strictly necessary but they're a very useful feature. You absolutely need the ability to sign other people's identities. You need to be able to sign and encrypt both text and binary (and do symmetric encryption), and export the result of everything in both text and binary. Smartcard support is a very good idea. Agent support is vital. What things do you think GPG should cut? > You want this as a library that's impossible to misuse and a nice CLI on top. Agreed. A rock-solid OpenPGP library would be great. I do think that's one place where there's a lot of real room for improvement. > The fact that it took you half an hour to understand the "basic usage" is ridiculous. The GPG developers have failed in the worst possible way when it comes to the design of their software. It's so bad I find it incomprehensible how that could have happened on accident. IIRC: developer, singular, unpaid and part-time. Also GPG is 20+ years old and doesn't want to change the CLI radically so as a) not to disrupt existing users b) not to disrupt existing scripts. A frontend or alternative with great UX would be really useful. But who's going to pay for that work?
pdkl95 10y ago
I have little direct evidence, but I suspect the problem is a set of programmers that hate the command line and never learned to rely on man pages. When they try gpg, they try --help and see the giant list of options, and immediately panic. This same attitude may also explain the tendency to reinvent things like rsync and other tools that have accumulated a large set of options over the years.
- ubernostrum 10y ago
  I consider myself pretty comfortable with command lines, given that I more or less live in a terminal window for work purposes. GPG's particular command-line interface is still a counterintuitive mishmash of stuff that essentially boils down to having to look up a tutorial every single time I want to do anything related to key management. I've actually been known to ask people to email me just so I can fire up a mail client with Enigmail and have it auto-fetch the key into my keyring and set trust on it through their interface. Which, while not great, is light-years better than GPG's native key-editing interface.
  - pdkl95 10y ago
    Is the command line interface that is confusing? Or is it that the crypto jargon is confusing? I suspect the latter, maybe? Regardless, just like any feature-rich technical library, this is easily solved by a front-end. For example, > Enigmail ...is an outstanding front end for many common uses. Unfortunately, the idea of writing a better UI front end for GPG - possibly many, specialized for various tasks - just like we've done for every other complicated piece of technology, it seems like everyone says "it's too complicated" and writes off GPG entirely. > native key-editing interface While I agree that interface is not the best (use Enigmail), I don't necessarily find it hard. It's very unrefined, tedious, and can be very annoying.
    - ubernostrum 10y ago
      It's very unrefined, tedious, and can be very annoying. This is the same as saying "hard".

ryan-c 10y ago

That is an order of magnitude more effort than most people are willing to put into it. Try teaching a not-computer-savvy relative to use it and exchange email with them.

leshow 10y ago
we're talking about developers signing commits here, not sending emails to your grandma gpg encrypted

DasIch 10y ago

Essentially you want 3 operations. Generate keypair, encrypt X with key, decrypt X with key. You want this as a library that's impossible to misuse and a nice CLI on top. The fact that it took you half an hour to understand the "basic usage" is ridiculous. The GPG developers have failed in the worst possible way when it comes to the design of their software. It's so bad I find it incomprehensible how that could have happened on accident. If they would be working on something non-cryptographic, that would be one thing but for a cryptographic tool that's unacceptable. The design and ease of use is just as important as the cryptographic algorithms themselves for such a tool because any friction causes people to avoid cryptography.

ashitlerferad 10y ago
What about signing and verification?
- DasIch 10y ago
  Right, forgot about those. Still those are just two more commands, which brings us to 5. That shouldn't push the complexity up significantly and doesn't change anything about my argument.
  - ashitlerferad 10y ago
    What about getting someone's key? What about distributing your key? What about backing up your secret keys on paper? What about binding your primary secure key that is usually stored in a safe on a Yubikey with secondary keys stored on Yubikeys you carry around with you? What about revoking a secondary key after a laptop or Yubikey got stolen? Perhaps you see where I'm going with this :) The problem domain is just complex.
lmm 10y ago
> Essentially you want 3 operations. Generate keypair, encrypt X with key, decrypt X with key. You need key rotation if you want security, so you need master keys and subkeys (or you'll end up reimplementing them by hand with conventions that everyone will interpret differently). Multiple identities on a key are I guess not strictly necessary but they're a very useful feature. You absolutely need the ability to sign other people's identities. You need to be able to sign and encrypt both text and binary (and do symmetric encryption), and export the result of everything in both text and binary. Smartcard support is a very good idea. Agent support is vital. What things do you think GPG should cut? > You want this as a library that's impossible to misuse and a nice CLI on top. Agreed. A rock-solid OpenPGP library would be great. I do think that's one place where there's a lot of real room for improvement. > The fact that it took you half an hour to understand the "basic usage" is ridiculous. The GPG developers have failed in the worst possible way when it comes to the design of their software. It's so bad I find it incomprehensible how that could have happened on accident. IIRC: developer, singular, unpaid and part-time. Also GPG is 20+ years old and doesn't want to change the CLI radically so as a) not to disrupt existing users b) not to disrupt existing scripts. A frontend or alternative with great UX would be really useful. But who's going to pay for that work?

pdkl95 10y ago

I have little direct evidence, but I suspect the problem is a set of programmers that hate the command line and never learned to rely on man pages. When they try gpg, they try --help and see the giant list of options, and immediately panic. This same attitude may also explain the tendency to reinvent things like rsync and other tools that have accumulated a large set of options over the years.

ubernostrum 10y ago
I consider myself pretty comfortable with command lines, given that I more or less live in a terminal window for work purposes. GPG's particular command-line interface is still a counterintuitive mishmash of stuff that essentially boils down to having to look up a tutorial every single time I want to do anything related to key management. I've actually been known to ask people to email me just so I can fire up a mail client with Enigmail and have it auto-fetch the key into my keyring and set trust on it through their interface. Which, while not great, is light-years better than GPG's native key-editing interface.
- pdkl95 10y ago
  Is the command line interface that is confusing? Or is it that the crypto jargon is confusing? I suspect the latter, maybe? Regardless, just like any feature-rich technical library, this is easily solved by a front-end. For example, > Enigmail ...is an outstanding front end for many common uses. Unfortunately, the idea of writing a better UI front end for GPG - possibly many, specialized for various tasks - just like we've done for every other complicated piece of technology, it seems like everyone says "it's too complicated" and writes off GPG entirely. > native key-editing interface While I agree that interface is not the best (use Enigmail), I don't necessarily find it hard. It's very unrefined, tedious, and can be very annoying.
  - ubernostrum 10y ago
    It's very unrefined, tedious, and can be very annoying. This is the same as saying "hard".