EasyGnuPG

[Peter Lebbing]

First of all, let me say that I regret that I didn't start my mail with feedback
on your project on a positive note. I think it's good that people spend effort
trying to make things more usable, and I applaud you for it. It would have been
a lot nicer of me to start out with that. There's no excuse for forgetting basic
civility and just being friendly to one another. Sorry.

Please don't feel put off by the fact that I might lack some tact here and there...

On 22/03/16 20:53, Dashamir Hoxha wrote:
> The implementation will not break, as long as it is based on the latest stable
> release.
> When the next stable release of gpg is out, the implementation will be adjusted
> to match it.

So you should do a check on the version and fail if it is different than the
version you worked with. And you need to support all the versions of all your
users; on short notice as well, probably. Plus the elephant in the room that the
developers of GnuPG are very explicit in that this interface is not for
scripting, yet you use it as such. You can reason about it all you want, in the
end, you're still using it differently than upstream intended.

> Regarding your main question above (I have also answered it previously), I think
> that `gpg` (the command) is monolithic

All asymmetric crypto is done in the agent by now, there are separate programs
for several tasks like keyserver communication and smartcard communication. Sure
you can argue that the tasks are not spread in the way you would like, but in a
strict sense it is definitely not monolithic. "Fairly monolithic" at most.

>, bloated with functionality and options,

You might be bothered by this on principal grounds, since it is security
software and there's the attack surface and amount of code to consider, but it's
not a practical issue, purely a principal one. That's like saying you don't like
Inkscape because it lets you paint in pink and you hate pink and never use it...

> the docs are like a maze and not clearly structured

A reasonably fair criticism... writing good documentation is hard, very hard. In
fact, it turned out to be easier to write academical papers on why it is so
difficult to make crypto easy to use than to write documentation that makes
crypto easy to use.

When I refer to the man page, which is just one bloody long list without
structure (and hence not a maze either), I use search terms to find what I look
for. If specific ones will not do, a generic one, repeating the search until I
find the option I want. Then again, by now I've referred to it reasonably often
when trying to help people on this list or playing around.

>, the number of commands and
> options is huge,

Yes. Again, if we had documentation that omitted these, you would not be
bothered by it, right?


> there is no clear distinction between the commands and the
> options

This one is odd. Have you examined the structure of the man page? Let me quote
(quite) a bit:

> COMMANDS
>        Commands are not distinguished from options except for the fact that only one
>        command is allowed.
> 
>        [...]
>    Commands not specific to the function
>        [...]
>    Commands to select the type of operation
>        [...]
>    How to manage your keys
>        [...]
> OPTIONS
>        gpg2 features a bunch of options to control the exact behaviour and to change
>        the default configuration.
>
>        [...]
>    How to change the configuration
>        [...]
>    Key related options
>        [...]
>    Input and Output
>        [...]
>    OpenPGP protocol specific options.
>        [...]
>    Compliance options
>        [...]
>    Doing things one usually doesn't want to do.
>        [...]
>    Deprecated options
>        [...]

This is the structure of the two sections 'commands' and 'options'. I find it
perfectly obvious which are which. If you're lost in the massive list of options
and wonder whether you're looking at a command or an option, you do a backwards
search for a line that doesn't start with a blank. You'll end up at either
"COMMANDS" or "OPTIONS", and you'll have your answer. Basic man page voodoo,
searching for a non-blank first character to navigate sections.

>, the supported use cases are not so clear (it actually tries to support
> everything)

Everything OpenPGP related, yes. The gpg2 binary is the front end to GnuPG with
regards to OpenPGP. Is this the same argument as "it's monolithic"? What
practical gain do you get if, for instance, key management were done with a
binary called "keymgr", and so on? In the end, when you verify a signature, you
want to know the validity of the key, so the same code gets exercised, whether
it's in a library shared by several binaries or one binary.

And even the library, GPGME, executes a binary: that way you get address space
separation. That way, all the crypto is in a separate process, out of the grubby
hands of whatever calls it. The private key is even further away in the agent
:). Again a separate process.

>, the default values are not well-thought

This I strongly reject. A /lot/ of thought has gone into the defaults, for as
far as I can see from the sideline.

Your one month expiry thing is not well thought through. Not only will the owner
need to re-sign and redistribute every damn month, but all his contacts will
pretty much always need tor refresh the key before they can use it, /even/ if
they are currently working offline (e.g., commuting), which means they simply
need to wait until they have network coverage again. The 4k RSA primary key with
3 subkeys grows by 2 kilobytes on the keyserver every single month (new expiry
signatures). When, not if but when the user forgets to renew, his contacts have
no other recourse than to contact the user in plain text to remind them of their
forgetfulness.

And why is your primary key capable of encryption? One of the reasons for
subkeys is so you don't have to use the same key material for both encryption
and signing, since this opens up some subtle points of attack that are easily
avoided.

>, the terminology is
> confusing and counter-intuitive,

There is definitely some source of confusion: sometimes validity is referred to
with some construction with the word "trust" in it, whereas ownertrust is
something completely different. Also, the word key is overloaded: is it key
material, or is it a certificate? Heck, in the vernacular, keys go with locks,
not other keys.

But if something in GnuPG, in official documentation, refers to validity with
"trust" somewhere, I think you should definitely report it, because I think it's
only third parties that do this.

Unfortunately, I think it's a bit too late to introduce a different term than
"key" for the certificate, even though it is clearly confusing. You could rename
stuff to "contacts", but you have an established body of users and terminology.
You can't just wish it away, unfortunately.

That crypto is really hard from a usability standpoint is well-established.

Renaming public keys of others to contacts might be pretty smart. But there is
then some asymmetry. I send them my key, but they do not get my key, they get a
contact. When my key preferences change, they should refresh their... contact
information I suppose. It could work, I just think it's several decades too late
to actually change it.

> Do you think these can be fixed with simple patches?

I think you're being overly critical of what is already there. Somebody one day
might get it completely right; it could be you. But I personally don't feel that
your current solution is it. It's too disconnected from the rest, and it meddles
with stuff it should leave well alone.

Current GnuPG is the culmination of several decades of very hard work by
talented people. Don't forget that when you think something isn't as you think
it should be.

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>