Hi, Since few release we have nifty, consolidated way to select system-wide crypto policy. It's great, but granularity of selection is little lacking. We have basically two sensible choices: - DEFAULT, which is, well, default - FUTURE, which is said to be more secure; if the admin wants to change the policy, (s)he will have to switch to FUTURE So let's imagine Joe Sysadmins who in the face of LogJam and other vulnerabilites, wants to tighten security a bit. He switches to FUTURE and now GitHub doesn't work: $ update-crypto-policies --set FUTURE Setting system policy to FUTURE $ wget https://github.com Resolving github.com (github.com)... 192.30.253.112, 192.30.253.113 Connecting to github.com (github.com)|192.30.253.112|:443... connected. ERROR: The certificate of 'github.com' is not trusted. ERROR: The certificate of 'github.com' was signed using an insecure algorithm. Not only github: Connecting to getfedora.org (getfedora.org)|2001:4178:2:1269::fed2|:443... connected. ERROR: The certificate of 'getfedora.org' is not trusted. ERROR: The certificate of 'getfedora.org' was signed using an insecure algorithm. Switching back to DEFAULT make those working again. But it buys us nothing, we have one setting which is default and the other is unusable. Why have this setting at all, then? Should we introduce another level, like FUTURE-BUT-WORKING? With secure settings, post-quantum cryptographic algorithms but working with today websites? -- Tomasz Torcz 72->| 80->| xmpp: zdzichubg@xxxxxxxxx 72->| 80->| _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
