> 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?
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?
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.
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.
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?
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.
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.
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.
This is the same as saying "hard".
Note that GPG is not a technical library. The primary "library" for using GPG consists of some functions that system() out to GPG and pipe data back and forth. I think this is a big impediment to getting better frontends (particularly on platforms other than linuxlike desktops).