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
