On Wed, Apr 20, 2016 at 08:20:13PM +1000, Trent W. Buck via luv-main wrote:
My actual thinking was:
1. upstream decides what's best for everyone (in general); 2. distro amends that for distro-specific requirements;
And a lot of them just inherit from no. 1, without considering the full algorithm availability. Which is why we see things like hash digest preferences that go SHA256, SHA1 and then digests larger than 256.
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.
Heh.
I read your your initial assertion very... dogmatically pushing all responsibility onto (4), which felt unrealistic when the end users aren't crypto geeks.
My only real quibbling here is with people who want to fill the world with 16K keys without considering any other security precaution as if having a 16K key is all that they need to protect themselves from, say, the NSA. Nevermind the fact that if they came to that level of attention they'd experience the wonderful world of trojans and keystroke loggers.
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).
The other fun one is corresponding with and encrypting to multiple recipients ... to the tune of around 30+ recipients. Even when most of them have 2K keys you'll still end up with most messages being around 40K (and the actual messages being fairly short). Regards, Ben