On 02/26, Paul Wouters wrote: > On Tue, 24 Feb 2015, Matt Rogers wrote: > > >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. > > When you say "runtime" you mean an ephemeral store right? I think Bob > called this the "cached nss db". That is, the "runtime" nss.db is the > file based nss.db plus the cached nss.db. On stop the cache is lost. >
Sorry, I meant a 'runtime db' as in a merged SQL copy of the /etc/ipsec.d/ db in a build configured spot (default /var/lib/pluto). Both pluto and the helper program share this copy. The difference with their initialization is pluto is read-only, the helper is read-write, and pluto ends up only using the permanent items stored in the db. There is a ephemeral cache used by the helper process during verification. This task involves a temporary import so a chain verification can involve permanent db certs (i.e. loaded CA) along with the temporary ones. When the verify succeeds the temporary objects are imported permanently, and returning to pluto, it picks up the new objects out of the DB (by searching using the original DER blobs). Matt _______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
