On Thu, Nov 8, 2012 at 8:14 AM, Phil Pennock <[email protected]> wrote:
>> (this is about smart cards) is transparent and system wide because we >> want all applications that use gnutls to be able to use smart cards >> transparently (e.g. you can load your private key from a smart card >> the same way you'd load it from a file). > This doesn't make sense in all cases; for system daemons, mostly not, > and Exim does TLS init at start-up, to validate the config. Well a system daemon may use a hardware security module (HSM) to speed up, e.g., RSA and protect its keys, so it still makes sense there (smart cards and HSMs are both accessed via the PKCS #11 API). > So we got > user complaints when I released 4.80 in May with my changes to overhaul > the GnuTLS integration. I wrote the fix below a few months back and it > will be part of 4.82 (whenever that's released). Perhaps this approach > is of use to others? ... > If we ever have Exim daemons which need pkcs11 support and folks still > want to run mailq with GNOME_* environment variables set, I may have to > start inhibiting the start-up TLS check for some cases. The approach seems correct to disable PKCS #11. I should also document it if it is not already there. However, were the requests to disable PKCS #11 due to the messages being printed by gnome-keyring, or because of some other reason? If it is the former could the gnome-keyring module be more silent on failures and print messages only if some debugging environment variable is present? regards, Nikos _______________________________________________ Help-gnutls mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-gnutls
