Re: NSS support quirks
Date: Mon, 16 Jun 2008 15:09:02 +0200
Daniel Stenberg <daniel_at_haxx.se> writes:
> On Fri, 13 Jun 2008, Axel Tillequin wrote:
>> #include "certdb.h" /* for SEC_DestroyCrl */
>> #include "nss/base64.h" /* for ATOB_ConvertAsciiToItem */
> Both these should be using <> and not "" since the headers won't be in
> the same dir as the .c file, right?
Using "" should do the job but <> would probably be less misleading for
everyone. IMHO, the best solution would be the one pointed by Rob in a
>> the nss/ prefix is needed because curl already has a base64.h file that
>> will be chosen instead of the nss one otherwise...
> Even if you use <base64.h> instead of "base64.h" ?
>> in nss.c, replace
>> else if (CERT_CompareCerts(cert_issuer,issuer)==PR_FALSE)
>> else if (SECITEM_CompareItem(&cert_issuer->derCert,
> Can someone please verify that this works first?
AFAICT, in his previous patch, Axel just extracted the line of code from
the function was *not* exported by NSS and inlined it instead of making
a private copy of the wrapper. Rob, can you comment?
The stuff *compiles* with NSS support with no warning.
Daniel, I don't know if it would be a huge amount work but a good way to
test things would be to had to curl (the command line utility) the
options for passing CRL and issuer cert (or the equivalent for NSS) and
then test things (also adding regression tests for that if time is not
a matter). At least associated time would not be completely lost. That's
just an idea.
- application/pgp-signature attachment: stored