Open Bug 1476434 Opened Last year Updated Last year
upgrading key database from dbm to sqlite leaves behind old database (what happens if the user protects the new database with a password/pin?)
See bug 1475775. The issue is that a user was surprised their passwords could still be decrypted after setting a password on their NSS key database. What had happened is the key that encrypted the passwords had been generated and stored in the old key3.db (dbm) (this is the PKCS11SDR API). The user then updated to Firefox 58, which migrated the database to key4.db (sqlite) and then added a password. Unfortunately, the old key3.db file was still around. In Firefox, we're going to attempt to detect and remove the old file if this happens.
Sorry, summary was unclear - the "password" being added is the "master password"/pin that encrypts the key database.
Summary: upgrading key database from dbm to sqlite leaves behind old database (what happens if the user adds a password to the new database?) → upgrading key database from dbm to sqlite leaves behind old database (what happens if the user protects the new database with a password/pin?)
I think generally it should be the application's responsibility to handle the old file (as it might want to keep it around or delete or do something with it). But maybe we could add an option that allows deleting the old database when upgrading.
Priority: -- → P3
This isn't a remote attack vector so it doesn't need to be hidden: better that users have a chance of knowing about this so they can manually clean up in this situation.
You need to log in before you can comment on or make changes to this bug.