On Sat, 2016-12-17 at 16:19 +0100, Tomasz Torcz wrote: > 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
That is one of the main goals of crypto policies. To set a sensible default across the system applications, irrespective of which back-end library it uses. It should not be underestimated, as even now we are not there yet, especially with the applications depending on the less known tls libraries, or applications using libssh*. > - 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: As a general goal, the intention of the FUTURE policy is not to be compatible with the rest of the internet. That's the goal of the DEFAULT policy. The FUTURE is intended to be compatible with servers using parameters which are considered secure. > $ 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 > 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. The example you have above is a glitch on the combination of the shared system store use and crypto policies at gnutls. Please file a bug on it. That host should have been within the crypto policies FUTURE requirements. > Should we introduce another level, like FUTURE-BUT-WORKING? With > secure settings, No. The purpose of the policies is to provide levels of assurance. A connection is within that set or not. FUTURE-BUT-WORKING doesn't mean anything; the DEFAULT policy serves that purpose. regards, Nikos _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
