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
