On Thursday, January 19, 2017 13:39:44 Pawel Veselov wrote:
> Things work perfectly fine if I use the database, i.e. no MT problems.
> Unfortunately, this is not a workaround to what I'm trying to achieve,
> but it is pointing to nss-pem as a culprit, isn't it?

Exactly.

> Anywhere in particular you'd like me to dig in there?

The nss-pem module maintains a global array of objects named pem_objs. I
guess it could be a problem if accesses to the array were not synchronized.
But they should be thanks to the patch I referenced in my previous reply.

Are your private keys encrypted?

If so, I would also focus on the decryption code in pem_mdSession_Login(),
or better try reproducing the bug with unencrypted keys first.

> P.S. I also discovered that if database is used (even if it just
> exists, may be it needs to have a CA, may be it doesn't), then
> CURLOPT_CAINFO is ignored, or at least the cert that is provided by it
> is no longer trusted. May be because the same cert is in the DB, and
> without the C flag. If it is the latter, it is probably still a
> problem, because if I say I need to trust cert X, there is no other
> way for me to do it (if it is a system database, for example).

You can try it with your own (e.g. empty) NSS database. You can set the
$SSL_DIR environment variable to make libcurl use a different database.

Kamil
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-01-20