On 02/24, Antony Antony wrote: > Hi, > Yesterday Paul and I met with NSS guys and here are some notes from the > meeting. >
Thanks for the notes! I'm bummed I missed it considering I have been working on the x509 NSS re-write recently. > NSPR threading: no need to use NSPR threading on Linux, because on Linux it > is jut a wrapper around pthread. > Good, as I always understood it you should use either NSPR threads or pthread, never both. > Don't open a NSS DB file simultaneously(not even one app writing and another > re-reading). Due to the nature of in memory data structures things can go > wrong. Close it completely and start again. Also use new format, not the old > Berkeley DB. > Yes, the re-write uses the SQL format database which is for allowing simultaneous access. Now the decoding, verification, revocation checking and importing of certificates is handled by a helper program that does its own initialization of what will be pluto's 'runtime' nss db in the SQL format. When it imports certificates, pluto is able to pick those up right away, so it works well. > Human readable error strings in NSS is possible. They mentioned an > application(libreswan) must initialize "error code tables" in NSPR to access > it in NSS. It might be worth investigating. You may also have to install NSS > utils. > > A quick googling shows libreswan use PR_GetError. However, libreswan seems to > be missing initialization code, PR_ErrorInstallTable, > nspr_InitializePRErrorTable. I haven't looked in detail. It seems prerr.h or > prerr.c is a starting point. > Getting the human output would be really handy. I believe we have a bug entry open for this too. After the x509 changes in I would be happy to add it and get rid of all the manual translating we have to do. Matt _______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
