some NSS_Initialize() questions
Guenter
I've some questions regarding proper initializing NSS.
From what I've read newer NSS now supports / prefers SQLite cert databases:
https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX#Type_3_packages:_Libraries
now what I need to know is when I want to open the certdb readonly and in
a backward-compatible way is it valid to allways prefix the certdb path
with sql: like:
char *certDir = PR_smprintf("sql:%s", SSL_DIR);
rv = NSS_Initialize(certDir, NULL, NULL, NULL, NSS_INIT_READONLY);
does NSS then still proper initialize even if SSL_DIR points to a folder
holding an older DBM certdb (certX, keyX, secmod) ?
Which is the lowest NSS version which understands and works with the sql:
prefix?
Then I've seen code like:
rv = NSS_Initialize(certDir, NULL, NULL, "secmod.db", NSS_INIT_READONLY);
is it really necessary to specify secmod.db with NSS_Initialize() ?
finally in the NSS docs I found somewhere a sample for initializing where
the parameters are not NULL but empty strings:
rv = NSS_Initialize(certDir, "", "", "", NSS_INIT_READONLY);
what is the correct way?
thanks, Günter.
Nelson Bolyard
> Hi all,
> I've some questions regarding proper initializing NSS.
> From what I've read newer NSS now supports / prefers SQLite cert databases:
Supports: yes
Prefers: I would say no. NSS must be explicitly instructed to use the new
SQLite3 databases in each and every process that uses it, or else, by
default, it will use the old Berkeley DBs, even if the SQLite3 DB files
exist and the Berkeley DB files do not.
> https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX#Type_3_packages:_Libraries
> now what I need to know is
> when I want to open the certdb readonly and in a backward-compatible way
> is it valid to allways prefix the certdb path with sql: like:
> char *certDir = PR_smprintf("sql:%s", SSL_DIR);
> rv = NSS_Initialize(certDir, [...] NSS_INIT_READONLY);
> does NSS then still proper initialize even if SSL_DIR points to a folder
> holding an older DBM certdb (certX, keyX, secmod) ?
Yes, it is valid to use the sql: prefix, even with read-only, even when
only the older Berkeley cert8.db and key3.db files exist.
You can test this easily with the certutil program. Given a directory
named DB containing a cert8/key3 pair containing some certs, the command
certutil -L -d sql:DB
will initialize NSS read-only with that certDir string, and will list the
contents of the old DBs, without creating new SQLite3 DBs.
> Which is the lowest NSS version which understands and works with the sql:
> prefix?
NSS 3.12.0
> Then I've seen code like:
> rv = NSS_Initialize(certDir, NULL, NULL, "secmod.db", NSS_INIT_READONLY);
> is it really necessary to specify secmod.db with NSS_Initialize() ?
No. A NULL or empty string will be replaced by an appropriate default.
Note that when used with the Berkeley DBs, the PKCS#11 module configuration
information is stored in secmod.db, which is also a Berkeley DB; but when
used with the SQLite3 DBs, the PKCS#11 module configuration information is
stored into a file named pkcs11.txt, which (as the name suggests) is a
plain text file.
> finally in the NSS docs I found somewhere a sample for initializing where
> the parameters are not NULL but empty strings:
> rv = NSS_Initialize(certDir, "", "", "", NSS_INIT_READONLY);
> what is the correct way?
NSS_Initialize treats NULL and "" equivalently, turning them both into
newly allocated empty strings (e.g. ""), which is then replaced by the
appropriate default.
> thanks, Günter.
>
--
12345678901234567890123456789012345678901234567890123456789012345678901234567890
00000000011111111112222222222333333333344444444445555555555666666666677777777778
Guenter
thanks for your quick reply!
Am 13.09.2009, 01:30 Uhr, schrieb Nelson Bolyard
<NOnels...@nobolyardspam.me>:
> On 2009-09-12 09:23 PDT, Guenter wrote:
>> Then I've seen code like:
>> rv = NSS_Initialize(certDir, NULL, NULL, "secmod.db",
>> NSS_INIT_READONLY);
>> is it really necessary to specify secmod.db with NSS_Initialize() ?
>
> No. A NULL or empty string will be replaced by an appropriate default.
>
> Note that when used with the Berkeley DBs, the PKCS#11 module
> configuration
> information is stored in secmod.db, which is also a Berkeley DB; but when
> used with the SQLite3 DBs, the PKCS#11 module configuration information
> is
> stored into a file named pkcs11.txt, which (as the name suggests) is a
> plain text file.
yup, know that, and therefore asked to ommit secmod.db - so I assume that:
rv = NSS_Initialize(certDir, "", "", "", NSS_INIT_READONLY);
works also fine with pre-3.12.0, and there's no need to specify secmod.db
as 4th argument, right?
conclusion - would something like that work from 3.2.1 to recent?
char *certDir = PR_smprintf("%s%s",
NSS_VersionCheck("3.12.0") ? "sql:" : "",
SSL_DIR);
rv = NSS_Initialize(certDir, "", "", "", NSS_INIT_READONLY);
PR_smprintf_free(cerDir);
I guess I can already right after the call to NSS_Initialize() call
PR_smprintf_free() ?
thanks, Günter.
Nelson Bolyard
> rv = NSS_Initialize(certDir, "", "", "", NSS_INIT_READONLY);
> works also fine with pre-3.12.0, and there's no need to specify secmod.db
> as 4th argument, right?
You only need to specify a non-empty string for the 4th argument if you
want/need to use a non-standard file name for the PKCS#11 module
configuration information file.
> conclusion - would something like that work from 3.2.1 to recent?
>
> char *certDir = PR_smprintf("%s%s",
> NSS_VersionCheck("3.12.0") ? "sql:" : "",
> SSL_DIR);
> rv = NSS_Initialize(certDir, "", "", "", NSS_INIT_READONLY);
> PR_smprintf_free(cerDir);
3.2.1? Yikes!
I do not think that trying to write a program that is fully backwards
compatible with all versions of NSS back to 3.2.1 is a noble objective.
If you really want to do that, you should write, build and test your
program with NSS 3.2.1, and then rely on the newer versions of NSS to
maintain backwards binary compatibility.
Writing and building a program to work with the newest version of NSS,
and then hoping that it will also work with older versions of NSS is
very likely to result in lots of failure and frustration. It is very
likely that your program will call functions that did not exist in older
versions of NSS, or will rely on features that did not exist.
But the biggest reason not to attempt it, in my opinion, is that the
older versions of NSS all have various serious security vulnerabilities.
Those vulnerabilities were fixed in newer versions of NSS. That's how
we always fix security vulnerabilities in NSS. We release new versions
that are backwards binary compatible and contain the fixes. If anyone
is still running NSS 3.2.1, I can think of numerous serious ("critical")
security vulnerabilities to which they are still vulnerable.
I'd say that in the interest of the security of your customers/users,
your best bet would be to write code that checks the version of NSS
being used on the customer's system, and if it's old, put up an error
message about unpatched security vulnerabilities and refuse to start.
Tell the user that you cannot claim to offer any serious security claims
while running on top of an old version of the library with known security
vulnerabilities.
> I guess I can already right after the call to NSS_Initialize() call
> PR_smprintf_free() ?
Yes. I believe so.
> thanks, Günter.
/Nelson
Guenter
Am 15.09.2009, 03:05 Uhr, schrieb Nelson Bolyard
<NOnels...@nobolyardspam.me>:
> 3.2.1? Yikes!
>
> I do not think that trying to write a program that is fully backwards
> compatible with all versions of NSS back to 3.2.1 is a noble objective.
naaaa, that wasnt meant in that way!
I wrote 3.2.1 only because I saw that it is the earliest version which
supports NSS_VersionCheck() :)
All I want to change with our current code is:
1. remove the secmod.db as 4th argument to NSS_Initialize() (which we have
currently in the code for whatever reason)
2. add the 'sql:' prefix for NSS 3.12.0 and up, and add NSS_VersionCheck()
to check for that version at runtime.
The rest of the code is not written by me, and since it works fine so far
with recent NSS I'm not going to touch further;
all I want to intruduce is that NSS works automatically with both old and
new certdb format so that the user doesnt have to care about ...
also setting the env var NSS_DEFAULT_DB_TYPE is not optimal since it can
quickly affect other NSS consuming apps.
thanks very much for your helpful replies!
Günter.