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> _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
