For cert8 format databases, if the databases don't exist, the error code is SEC_ERROR_BAD_DATABASE. This allows products to identify an un-configured database and suppress diagnostics. However, for an upcoming version of the product on which I work we're using the cert9 format (adding "sql:" prefix to path) by default. If the databases doesn't exist, I'm seeing SEC_ERROR_INVALID_ARGS (-8187) instead of SEC_ERROR_BAD_DATABASE (-8174). This would be an incompatible interface change. See bug 273624 for additional information.
So I need to code a workaround for this bug so it stops causing problems for our testing. My plan is to stat() cert9.db prior to trying to initialize NSS. If I get ENOENT from the stat, I'll force the error code to SEC_ERROR_BAD_DATABASE in my error callback. I know this violates the "private interface" rule about cert9.db, but I can't think of an alternative. Any other suggestions for a workaround?
Chris, Is it correct to assume that the function that sets a different error code with cert9 is NSS_Init* ?
Yes, our code only uses NSS_Initialize to initialize NSS.
Chris: thanks for the bug report. You are most likely running into bug 495097. Are you using NSS 3.12.x, where x < 4, on a 64-bit OS?
Yes, I had let the version of NSS on my 64-bit development machine get out of date (3.12.3). It does appear bug 495097 is the culprit. I'm marking as duplicate and removing workaround code. Apologies for the mistake on my part and thank you for the assistance.
Chris, We can search for dups. It's better to open a bug and have it closed a dup than to not open a bug that becomes an even bigger issue later. Thanks for taking the time to write this bug. bob