On Wed, 2016-09-28 at 11:43 -0400, Matthew Miller wrote: > > The libraries that should be preferred instead of arbitrary other > crypto stacks are (in the order of the preference): > > 1. NSS > 2. GNUTLS (with nettle as crypto backend, but nettle never used > directly by applications) > 3. OpenSSL > 4. libgcrypt > > and it might be reasonable to keep this as a "if possible, please > prefer" policy rather than a mandate. That is out of date. NSS should not be at the top now, for Fedora. Our packaging guidelines¹ say that packages SHOULD work seamlessly with PKCS#11 — if I plug in my Yubikey, or if I want to use a cert from SoftHSM or GNOME keyring or something like that, then I should just be able to use a standard PKCS#11 URI like 'pkcs11:manufacturer=piv_II;id=%01' Applications should automatically accept an identifier like that in place of a filename, whenever they can use certs from a file. With GnuTLS and OpenSSL, this works fine (OpenSSL apps need to use the ENGINE but it's relatively simple). With NSS... it's broken. Bugs² have been filed upstream... patches have even been attached to those bugs. But it looks like with Fedora 25, YET ANOTHER Fedora release is going out the door without NSS getting fixed. There are bugs open against packages like curl which would be *fixed* by moving them away from NSS and onto something else. Anything else. I strongly suspect that any historical anecdotal bugs about switching crypto libraries are irrelevant now. All three major crypto libraries now conform to the same system policy about which versions of TLS to use and which ciphers to enable — which was the most likely reason for any sudden change in interoperability in the past. But without bug numbers, any such anecdotes were immediately discardable anyway, of course. -- dwmw2 ¹ https://fedoraproject.org/wiki/Packaging:SSLCertificateHandling ² https://bugzil.la/1296263 and https://bugzil.la/1162897
<<attachment: smime.p7s>>
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
