On Sun, Oct 17, 2010, Michael Orlov wrote: > So, the usecase is instead: not having libssl/openssl installed at all, > but still having the individual certificates in various directories > (most bundled with the ca-certificates package), and having the ability > to combine the trusted ones into ca-certificates.crt, using > update-ca-certificates, for use by gnutls (or nss). > > c_rehash is not needed for that. I suggest removing the openssl > dependency, and putting a check for c_rehash existence into > update-ca-certificates.
It's a fair request to avoid the openssl dependency. I am an user of the hashed certificates feature, and there is an important performance gain for processes not to have to read and parse the whole pile of certs in /etc/ssl/certs/ca-certificates.crt but instead just load the right one by fingerprint from /etc/ssl/certs/ symlinks. This is what Postfix does with its smtp_tls_CApath and smtpd_tls_CApath options, and the Postfix TLS README explains that this is faster than using a single CAfile. (See openssl s_client -CAfile/-CApath flags for implementations.) In the case of Postfix, it's important because the processes are short-lived, I expect Apache to be in a similar situation. Now, in terms of implementation, update-ca-certificates supports hooks; I think hooks should be used to generate these symlinks, and that a new openssl hook should test whether c_rehash is present before calling it. There's a catch that ca-certificates.crt is in the same directory as the other certificates, and should be moved away before calling c_rehash. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110928133419.ga8...@bee.dooz.org
