Ben McGinnes via luv-main <[email protected]> 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. _______________________________________________ luv-main mailing list [email protected] https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
