Hans Petter Jansson wrote, On 2008-11-15 17:57: > On Fri, 2008-11-14 at 22:56 -0800, Nelson B Bolyard wrote: >> Hans Petter Jansson wrote, On 2008-11-14 21:54: > >>> This works for some databases, but not others.
> 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? >> Let's start with basics. >> Might some of them have corrupt cert8 DBs? > > I doubt it - this affects many users on different systems, and the old > databases are working in their original contexts. Could there be an > entry in the database that cannot be migrated, or that confuses the > migration code for some reason? Perhaps. The migration tries to copy ALL the old DB entries. It's possible to have a bogus entry that never gets used by the browser in normal circumstances, and so causes no problem for the browser, but is a problem for the migration software. The fact that you can get DB listings with certutil is evidence that suggests that the DB is not corrupted, but I wouldn't call it disproof. > 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. >> What version of NSS are you using? > > 3.12.0. At this point, I think the problem probably lies in one of these classes of problems (in no particular order or probability): a) The DB is corrupt b) Using a "wrong" version of the NSS shared libs c) a bug in NSS 3.12.0 d) a bug in your program I can suggest a couple more tests that might help eliminate one or more of those classes. With the browser not running, and the cert8 DBs not in use, and the DBs in a directory that has no cert9.db or key4.db, use certutil from NSS 3.12.x to do this command: certutil -L -X -d sql:DBDIR where "sql:" is that literal prefix (that's lower case SQL), and DBDIR is the path name of the directory that holds the cert8.db file. If that succeeds, it should generate cert9 and key4.db files in the directory that held the cert8. You can then try the command certutil -L -d sql:DBDIR (no -X this time) and if that also lists the certs, then the conversion was probably successful. That would pretty strongly disprove a DB corruption. OTOH, if that also fails, it suggests there is a DB problem. Note that this test won't be using NSS_InitWithMerge. It's using ordinary NSS_Init. It won't merge two DBs together. It only upgrades the old DB. However, knowing if that works, or not, will help us narrow down the problem, and decide what to do next. > Yeah... I think I can provide you with a problem DB in private that you > can look at if you've got the time. Let's try some other things first. /Nelson _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
