Ben McGinnes via luv-main <luv-main@luv.asn.au> writes:
On Thu, Apr 14, 2016 at 05:41:34PM +1000, Trent W. Buck via luv-main wrote:
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?
Because most distros will decide which options their default installation will compile with. You're assuming that the most common defaults will be so everywhere *and* that every OS or distro compiles in all the available algorithms, neither of these are true.
My actual thinking was: 1. upstream decides what's best for everyone (in general); 2. distro amends that for distro-specific requirements; 3. sysadmin amends that for site-specific requirements; & 4. end user amends that for user-specific requirements. ...so that if any one entity in that chain doesn't bother, hopefully it will fall back to the sensible defaults set above them. I was grumpy because I keep running into people assuming that one of those steps isn't needed. For example, as a (3) I cannot put folders in users' default Thunar sidebar, except via /etc/skel which- oh yeah, I only just finished ranting about that. I read your your initial assertion very... dogmatically pushing all responsibility onto (4), which felt unrealistic when the end users aren't crypto geeks. You're right that I didn't consider a desktop distro shipping very strong defaults & creating a problem when the desktop user corresponds with someone on an embedded platform with fewer resources. I assumed most distros would either * ./configure --enable-*, but leave the default cipher order as-is; or * ./configure && make, relying entirely on (1).
Surely people *writing* crypto software know better than people *packaging* crypto software, what the Best Current Practice is.
Yes, but they're also concerned about backwards compatibility to an extent, not to mention not taking decisions away from people regarding their own threat models.
[Lots more details about upstream's rationale, especially devices with fewer resources than a desktop.]
OK, fair enough.