© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
Digging somewhat deeper, it appears that the CA file cannot be loaded. strace shows a stat to bzr.dev/
https:/
Unfortunately, the warning curl emits at that location doesn't make it to the console or log. Otherwise we would have read this message:
WARNING: failed to load NSS PEM library libnsspem.so. Using OpenSSL PEM certificates will not work.
As that module cannot be loaded, loading the certificate will fail as well:
https:/
That's the reason the testing ca certificate will not be available as a trust root. In Fact I find no "libnsspem.so" on my system. Don't know why (yet), but please compare to your systems where this selftest passes.
Btw, in https:/
> The code use self.cabundle to set pycurl.CAINFO (originally for windows,
> later on for tests too). But reading the doc now, I wonder if
> CURLOPT_ISSUERCERT (aka pycurl.ISSUERCERT) should be used instead for *tests*
> (I think windows still needs to use CAINFO but I may be wrong).
I believe that CAINFO is still the correct thing, even for tests, and we should not switch to ISSUERCERT. The way I read it, CAINFO tells curl: "These are the CA roots I trust, try to verify against any of these". So it accepts a bundle and will choose among them. ISSUERCERT tells it "I definitely want this single cert to bee in the chain". It makes no statement about certs above the given one in the chain. I guess ISSUERCERT is a special case, not likely encountered in the wild, not supported by the bzr command line tool, and should therefore be avoided. CAINFO on the other hand mimics common setups with a set of root certificates, so it's the one we should use for testing as well.