Wolfgang Rosenauer wrote:
Hi,Hans Petter Jansson schrieb: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 :)I _think_ the problem when creating a new database (if one doesn't already exist) using NSS_Init() could be that the internal token (SDR) is created and people will never be able to read their passwords again even after a merge? I think what should be done is to mimic exactly what "certutil -L -X -d sql:." is doing for the initial creation of the database?
In the single cert8/key3 update to cert9/key4 (as opposed to a merge update where you are merging from cert8/key3 to a cert9/key4 in a shared location) case, which is what we are talking about here, there is a 2 step update. The second step requires a password. The code is supposed to know if the update has only half completed (I had some problem with early version of the shared DB code), where the databases are created, but the tables have not been. When it comes time to do the actual migrate, the tables are then created. If this is the case that's failing, we can simulate it with certutil as follows:
Start it a dbm database with a password. certutil -L -X -d sql:.This command does not require a password, so the databases will only partially update (databases are created, but not populated).
certutil -K -x -d sql:. <supply the password> This should successfully update the database.I've just tried this and it failed. So this looks like a good test to reproduce the problem. I'll attach it to the bug.
bob
Wolfgang _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
