[Warning: super ranty email follows.] Ben McGinnes wrote:
On Wed, Apr 13, 2016 at 10:06:11PM +1000, Russell Coker wrote:
On Wed, 13 Apr 2016 05:26:49 PM Ben McGinnes via luv-main wrote:
As far as I'm concerned if you can't be bothered editing your algorithm preference order in gpg.conf and editing your keys and subkeys (actually they're set according to each UID) to match then you have no business trying to make keys larger than the default maximums.
Actually I think it's the responsibility of DDs in question (and other OS developers) to ensure that GPG defaults to the correct algorithm preference.
Currently the default in most Linux distros (or OSes for that matter) is to create ~/.gnupg/ if its not there when the program is invoked, but not to generate a default gpg.conf.
Why is it the DD's responsibility, rather than upstream GnuPG project's responsibility? Surely people *writing* crypto software know better than people *packaging* crypto software, what the Best Current Practice is. Upstream & distro might choose different defaults because of a balance between usability & security (especially if it's a specialist distro), but in general I'd expect upstream to lean heavily towards security. Is gnupg upstream defaulting to weak settings? If so, why? Just to avoid bikeshedding on the ML, or something?
Distributions could set more sensible defaults by setting a basic system wide gpg.conf to be copied to a user's directory if it didn't exist, but the problem is that the first command for a lot of new users is --gen-key and if the gpg.conf is not already in place when the command is run then it won't affect the results.
If there's a host-wide default, it shouldn't need to be copied into ~ to take effect. If it has to be copied in, what happens when both /etc and ~ versions are edited? Do the upstream improvements just get ignored for existing users? Compare with how OpenSSH built-in defaults are overridden by /etc/ssh_config, which is in turn overriden by ~/.ssh/config. [BEGIN TANGENTIAL RANT] One problem I had configuring OpenSSH is that you can say My preferred cipher order is: <strong ciphers as at 2016> But you can't have JUST a blacklist Never use: <weak ciphers as at 2016> If means if I set up my .ssh/config sensibly TODAY, then forget to go back and maintain them, I'll end up with security that's *worse* than the upstream default, instead of better then the upstream default. Because upstream will say KexAlgorithms <strong as at 2020>, <medium as at 2020> And my .ssh/config will override it to say KexAlgorithms <strong as at 2016> Where <strong as at 2016> will equate to <medium as at 2020>, and my config never sees <strong as at 2020>. [END TANGENTIAL RANT] I dunno if that applies to GnuPG because, frankly, I've been obscenely lazy.
Also it would be handy if there was a tool to check your GPG configuration and key setup for obvious mistakes.
An actively maintained "linter" that checked both config and the keys themselves, to make sure they followed current best practice, sounds like a great idea. I am thinking something like lintian or perlcritic, which not only says "this is wrong", but also explains why it's wrong, & suggests how to fix it.