Re: NSS DB migration problem
On Sat, 2008-11-15 at 19:06 -0800, Nelson B Bolyard wrote: Hans Petter Jansson wrote, On 2008-11-15 17:57: It's on separate workstations, but in some cases one database migrates successfully while another fails on the same system. Is is possible that more than one version of the NSS shared libraries is installed, and that the two users have different LD_LIBRARY_PATHs, so that the two users are getting different versions of the NSS when they attempt this? It's highly unlikely. This database only fails to migrate if the target database was not already created by another, successful merge, though. I think you're saying that the failures only occur if the target (cert9) DB doesn't already exist when your program is run, but does succeed if the target is already a legit cert9 DB. Is that what you're saying? That would not surprise me. I think that the function you're using, NSS_InitWithMerge, does assume that the target DB already exists. Almost. I'm saying that if the database fails to migrate the first time, and leaves an empty database, then subsequent merges to that database also fail. However, if the first merge is successful (creating the database and populating it), then subsequent merges always work. I have a small sample size, though, since I don't have (nor want, really) direct access to other users' databases. It looks like Wolfgang found the problem, or at least a problem, in the Firefox' password manager thread, so I'm going to test using a normal NSS_Init() to create the database if it doesn't already exist, and see if that works. Thanks, Wolfgang :) -- Hans Petter Jansson [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
NSS DB migration problem
I've been looking in NSS docs and ML archives for a solution to the
following problem, with no luck. Asking around on IRC, I was pointed to
this ML. Hopefully it's the appropriate forum.
I'm trying to migrate existing NSS DBs from the old Berkeley DB format
to the new, SQLite-based format that can be shared by multiple
applications, using a snipped of C code from your migration guide. The
relevant code looks like this (abbreviated for clarity):
/* STEP 1: Signal that update/merge may be needed */
rv = NSS_InitWithMerge (sql:/home/user/new_db,
, , secmod.db,
/home/user/old_db, , ,
myapp, myapp,
flags);
if (rv == SECFailure)
{
/* Fallback code */
return rv;
}
slot = PK11_GetInternalKeySlot ();
/* Step 2: Determine if update/merge is needed. */
if (PK11_IsRemovable (slot))
{
/* need to update/Merge the database */
/* Step 3: Authenticate to the token */
rv = PK11_Authenticate (slot, PR_FALSE, pwdata);
if (rv != SECSuccess)
{
fprintf (stderr, *** Auth call failed: %u.\n, PORT_GetError ());
return rv;
}
}
This works for some databases, but not others. It doesn't seem to matter
which application created the database (I've tried with databases from
Firefox and Evolution) - e.g. one user's database may fail while another
user's database may migrate properly. When it fails, it's always on the
first PK11_Authenticate () call (step 3). The code above produces the
following output:
*** Auth call failed: 4294959104.
That is, 0xe000. If I set up an auth callback, it never gets called.
Do you have any suggestions as to what I'm doing wrong here?
--
Hans Petter Jansson [EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
