On Mon, Dec 19, 2016 at 09:35:09AM +0100, Nikos Mavrogiannopoulos wrote: > 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*. > > 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. So, what exactly is the use case behind this preference? > > $ 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. Done: https://bugzilla.redhat.com/show_bug.cgi?id=1405959 -- Tomasz Torcz "Never underestimate the bandwidth of a station xmpp: zdzichubg@xxxxxxxxx wagon filled with backup tapes." -- Jim Gray _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
