Bug#913645: Oldstable also affected
Dear Maintainer, since upstream was able to reproduce the problem and locate the commits that cause it I did no further tests. It seems like they will undo two commits in order to solve the problem, hopefully not too many people get bit by this. Cheers, Bastian On 12/3/18 12:58 PM, Bastian Neuburger wrote: Hi Carsten, I forgot to report back, but I also created Upstream bug 1510212 (https://bugzilla.mozilla.org/show_bug.cgi?id=1510212). As I stated there it might take a while until I can test migration again, since I reinstalled my test machine with Buster and thus have no test environment with Jessie or Stretch right now. I'll report back to upstream how this goes.
Bug#913645: Oldstable also affected
Hi Carsten, I forgot to report back, but I also created Upstream bug 1510212 (https://bugzilla.mozilla.org/show_bug.cgi?id=1510212). As I stated there it might take a while until I can test migration again, since I reinstalled my test machine with Buster and thus have no test environment with Jessie or Stretch right now. I'll report back to upstream how this goes. Cheers, Bastian On 11/30/18 6:50 AM, Carsten Schoenert wrote: Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1505038 Hello Bastian, Am 20.11.18 um 17:44 schrieb Bastian Neuburger: Hi, I have however not yet tested what happens if you start thunderbird aftter the upgrade and close it right away (i.e. not trying to sign anything but also not entering the master password). I will try to test this later but now I need a working mail client. I also tested this variant now: 1. Have berkeley DB based profile that works fine with thunderbird 52 in Jessie 2. Upgrade thunderbird 3. Start thunderbird 4. Close it without doing anything (I am not prompted for the master password) 5. Start thunderbird again Expected results: Either key3.db is still there or I am getting prompted for a master password during step 4. Actual results: Everything under "Your certificates" and "People" in the Certificate Manager gone, all saved passwords gone. So the problem we encountered did not only wipe private keys, but also certificates of other people I already corresponded with AND stored passwords. How should reporting with upstream be handled? Should I take care of it myself or would you like to forward it? I haven't forwarded that all into a new upstream bug report, but I was able to talk about that issue with upstream. Initially upstream (in that case the NSS/Firefox team) has decided about 6 years ago to stop using the old database option [1] and use the newer NSS implementations for storing stuff within a database. Your are not the only person who is experience such problems. There is the report 1505038 [2] which is from a user with the same problems. The issue has some workaround mentioned in comment #25 which should be "solve" your current problem, could you please test this suggestion? [1] https://bugzilla.mozilla.org/show_bug.cgi?id=783994 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1505038 -- Neuburger, Bastian Telefon: +49-6159-71 1740 Abteilung: IT-Security GSI Helmholtzzentrum für Schwerionenforschung GmbH Planckstraße 1, 64291 Darmstadt, Germany, www.gsi.de Commercial Register / Handelsregister: Amtsgericht Darmstadt, HRB 1528 Managing Directors / Geschäftsführung: Professor Dr. Paolo Giubellino, Ursula Weyrich, Jörg Blaurock Chairman of the Supervisory Board / Vorsitzender des GSI-Aufsichtsrats: State Secretary / Staatssekretär Dr. Georg Schütte
Bug#913645: Oldstable also affected
Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1505038 Hello Bastian, Am 20.11.18 um 17:44 schrieb Bastian Neuburger: > Hi, > >> I have however not yet tested what happens if you start thunderbird >> aftter the upgrade and close it right away (i.e. not trying to sign >> anything but also not entering the master password). I will try to test >> this later but now I need a working mail client. >> > > I also tested this variant now: > > 1. Have berkeley DB based profile that works fine with thunderbird 52 in > Jessie > 2. Upgrade thunderbird > 3. Start thunderbird > 4. Close it without doing anything (I am not prompted for the master > password) > 5. Start thunderbird again > > Expected results: > Either key3.db is still there or I am getting prompted for a master > password during step 4. > > Actual results: > Everything under "Your certificates" and "People" in the Certificate > Manager gone, all saved passwords gone. > > So the problem we encountered did not only wipe private keys, but also > certificates of other people I already corresponded with AND stored > passwords. > > How should reporting with upstream be handled? Should I take care of it > myself or would you like to forward it? I haven't forwarded that all into a new upstream bug report, but I was able to talk about that issue with upstream. Initially upstream (in that case the NSS/Firefox team) has decided about 6 years ago to stop using the old database option [1] and use the newer NSS implementations for storing stuff within a database. Your are not the only person who is experience such problems. There is the report 1505038 [2] which is from a user with the same problems. The issue has some workaround mentioned in comment #25 which should be "solve" your current problem, could you please test this suggestion? [1] https://bugzilla.mozilla.org/show_bug.cgi?id=783994 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1505038 -- Regards Carsten Schoenert
Bug#913645: Oldstable also affected
Hello Bastian, Am 20.11.18 um 17:44 schrieb Bastian Neuburger: > Hi, > >> I have however not yet tested what happens if you start thunderbird >> aftter the upgrade and close it right away (i.e. not trying to sign >> anything but also not entering the master password). I will try to test >> this later but now I need a working mail client. >> > > I also tested this variant now: > > 1. Have berkeley DB based profile that works fine with thunderbird 52 in > Jessie > 2. Upgrade thunderbird > 3. Start thunderbird > 4. Close it without doing anything (I am not prompted for the master > password) > 5. Start thunderbird again > > Expected results: > Either key3.db is still there or I am getting prompted for a master > password during step 4. > > Actual results: > Everything under "Your certificates" and "People" in the Certificate > Manager gone, all saved passwords gone. > > So the problem we encountered did not only wipe private keys, but also > certificates of other people I already corresponded with AND stored > passwords. thanks for testing this, I'm unable to this as I don't use any of these features. > How should reporting with upstream be handled? Should I take care of it > myself or would you like to forward it? I'd prefer if you could do the interaction with upstream as I only would act as a man in the middle. And I haven't much time to work on Thunderbird now. Please give a note back about the upstream bug number so we can add a forwarding to this issue. Thanks! -- Regards Carsten Schoenert
Bug#913645: Oldstable also affected
Hi, I have however not yet tested what happens if you start thunderbird aftter the upgrade and close it right away (i.e. not trying to sign anything but also not entering the master password). I will try to test this later but now I need a working mail client. I also tested this variant now: 1. Have berkeley DB based profile that works fine with thunderbird 52 in Jessie 2. Upgrade thunderbird 3. Start thunderbird 4. Close it without doing anything (I am not prompted for the master password) 5. Start thunderbird again Expected results: Either key3.db is still there or I am getting prompted for a master password during step 4. Actual results: Everything under "Your certificates" and "People" in the Certificate Manager gone, all saved passwords gone. So the problem we encountered did not only wipe private keys, but also certificates of other people I already corresponded with AND stored passwords. How should reporting with upstream be handled? Should I take care of it myself or would you like to forward it? Kind regards, Bastian
Bug#913645: Oldstable also affected
Hi, > this is not differing between the Debian releases(, unfortunately). > Debian hasn't touched any code here. > ... > First we/you need to check please if this behavior is also existing in > the upstream binaries. To check this you can simply download the > pre-compiled binary and start the thunderbird binary from that archive. > > amd64 > http://ftp.mozilla.org/pub/thunderbird/releases/60.3.0/linux-x86_64/ > > i386 > http://ftp.mozilla.org/pub/thunderbird/releases/60.3.0/linux-i686/ > > If the issue is also existing here then this needs to be reported to the > Mozilla bugtracker and this report needs to be tagged to follow that report. > > https://bugzilla.mozilla.org/ Indeed this seems to be an upstream bug, the upstream release is also affected. I also tested some more and found out, that there is a way to avoid private key loss. The scenario that hit us was trying to sign a message after upgrade and when this failed thunderbird was restarted. The certificate was gone. But when I view an encrypted message before restarting thunderbird will prompt me for the master password and everything works fine. After entering it also signing works. While watching the nssPrivate table in key4.db I noticed that entering the master password will create a new entry in that table. After a restart, everything is still there and working. This also works when e.g. changing a server password and saving it to the password store, it seems the crucial factor is getting prompted for the master password and entering it correctly. I have however not yet tested what happens if you start thunderbird aftter the upgrade and close it right away (i.e. not trying to sign anything but also not entering the master password). I will try to test this later but now I need a working mail client. I am wondering why thunderbird will not prompt for the master password when first trying to sign a message, but only for decryption. I'll report back, Bastian
Bug#913645: Oldstable also affected
Control: severity -1 grave Hello Bastian, Am 18.11.18 um 23:01 schrieb Bastian Neuburger: > severity: critical > > Dear Maintainer, > > since I had an oldstable system with a key3.db around I also checked the > behaviour there. this is not differing between the Debian releases(, unfortunately). Debian hasn't touched any code here. > I upgraded from > thunderbird:amd64 (52.9.1-1~deb8u1, 60.3.0-1~deb8u1) > and encountered the same situation: > > I couldn't decrypt messages anymore. > Before trying to decrypt an encrypted message, my certificate was still > visible in the "Your certificates" tab, after failing to display/decrypt > an encrypted message it is no longer visible. > > I checked key4.db before this and I got the following output: > > Enter ".help" for usage hints. > sqlite> .tables > nssPrivate > sqlite> select * from nssPrivate; > sqlite> > > Also think the severity of this bug is critical since it causes severe > data loss (private key gone: encrypted data gone). No, it's not critical but grave. https://www.debian.org/Bugs/Developer#severities > Please let me know if you have further questions. First we/you need to check please if this behavior is also existing in the upstream binaries. To check this you can simply download the pre-compiled binary and start the thunderbird binary from that archive. amd64 http://ftp.mozilla.org/pub/thunderbird/releases/60.3.0/linux-x86_64/ i386 http://ftp.mozilla.org/pub/thunderbird/releases/60.3.0/linux-i686/ If the issue is also existing here then this needs to be reported to the Mozilla bugtracker and this report needs to be tagged to follow that report. https://bugzilla.mozilla.org/ -- Regards Carsten Schoenert
Bug#913645: Oldstable also affected
severity: critical Dear Maintainer, since I had an oldstable system with a key3.db around I also checked the behaviour there. I upgraded from thunderbird:amd64 (52.9.1-1~deb8u1, 60.3.0-1~deb8u1) and encountered the same situation: I couldn't decrypt messages anymore. Before trying to decrypt an encrypted message, my certificate was still visible in the "Your certificates" tab, after failing to display/decrypt an encrypted message it is no longer visible. I checked key4.db before this and I got the following output: Enter ".help" for usage hints. sqlite> .tables nssPrivate sqlite> select * from nssPrivate; sqlite> Also think the severity of this bug is critical since it causes severe data loss (private key gone: encrypted data gone). Please let me know if you have further questions. Kind regards, Bastian
