439
edits
(long answer deleted) |
|||
Line 111: | Line 111: | ||
* I don't see anything about this proposal that uniquely ties it to Linux. Seems to me that an improved Module DB Library would be useful on all platforms. | * I don't see anything about this proposal that uniquely ties it to Linux. Seems to me that an improved Module DB Library would be useful on all platforms. | ||
** [The primarily tie is the suggestion that apps open /etc/pki/nssdb, and the expectation that the OS will supply appropriate code so that a user specific database will be opened when one opened /etc/pki/nssdb. It's true that any OS can implement this proposal. Some OS's may chose a different path for /etc/pki/nssdb [Windows will certainly have to, Mac probably would as well, though they wouldn't need to]. The purpose was to nail down the exact specifics for Linux, and thus the title I initially gave it.] | ** [The primarily tie is the suggestion that apps open /etc/pki/nssdb, and the expectation that the OS will supply appropriate code so that a user specific database will be opened when one opened /etc/pki/nssdb. It's true that any OS can implement this proposal. Some OS's may chose a different path for /etc/pki/nssdb [Windows will certainly have to, Mac probably would as well, though they wouldn't need to]. The purpose was to nail down the exact specifics for Linux, and thus the title I initially gave it.] | ||
* in the old dbm days, secmod.db was combined in the softoken PKCS #11 module primarily because that's where the dbm code was. With the sql database, it's possible to separate the moduleDB load from softoken. That might be a good plan for 3.13, removing yet more code from the cryptographic boundary of NSS. |
edits