Closed
Bug 547490
Opened 14 years ago
Closed 5 years ago
mail.password_protect_local_cache does not protect cache when set to true, mails/messages in thread pane are visible/displayed and can be viewed/accessed
Categories
(Thunderbird :: Preferences, defect)
Tracking
(blocking-thunderbird3.0 -, thunderbird3.0 wanted)
RESOLVED
WORKSFORME
People
(Reporter: albinary01, Unassigned)
References
()
Details
(Keywords: privacy, regression)
User-Agent: Opera/9.80 (Windows NT 6.1; U; en) Presto/2.2.15 Version/10.10 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 When boolean value mail.password_protect_local_cache, in config editor, is set to true on Thunderbird 3.0.1 for Windows (on Win 7 OS), after canceling the password dialog or clicking OK on failed to connect to mail server dialog box, the thread pane displays all messages and they can be clicked and viewed. In previous versions of Thunderbird (to be precise 2.0.22) this feature worked well and messages weren't displayed when that value was set to true. This feature is seriuos flaw if computer is used by more then one person on the same system account. This was tested with Thunderbird configured to connect to IMAP server, but I doubt it could be the related to the issue. Reproducible: Always Steps to Reproduce: 1. Click on Tools -> Options -> Advanced -> General tab -> Config editor button 2. In about:config Filter field start to type password and find below the option named: mail.password_protect_local_cache 3. Double-click it to change it to True 4. Restart Thunderbird 5. If either Thunderbird cannot connect to mail server or you enter wrong password thread pane will display the messages which can be viewed Actual Results: Thread pane shows the mail messages, although mail.password_protect_local_cache is set to true Expected Results: Thread pane should not reveal cached mail messages, it should be empty or show the page which is shown when clicked on account name in Folder pane Theme: Pitch Dark 3.0.0 - the bug is still reproducable with deafult theme chosen
Comment 1•14 years ago
|
||
confirming on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.2pre) Gecko/20100221 Lanikai/3.1b1pre
Status: UNCONFIRMED → NEW
blocking-thunderbird3.0: --- → ?
blocking-thunderbird3.1: --- → ?
Ever confirmed: true
Keywords: privacy,
regression
Updated•14 years ago
|
Also on: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1 Thunderbird/3.0 I've changed platform to all since it happens on (up to now) three different OSes.
OS: Windows 7 → All
Version: unspecified → 3.0
Comment 3•14 years ago
|
||
We're resetting the blocking flag for 3.1 on this bug. We have too many blocking-3.1 bugs, to the point where it doesn't mean much, and managing the list is making it hard to actually work on closing bugs, which helps no one. Thunderbird 3.1's primary purpose is to allow us to offer a prompted major update to Thunderbird 2 users, to ensure their continued ability to safely use Thunderbird. Thunderbird 2 is built on an outdated version of Gecko, and our long-term ability to maintain the users' safety for Thunderbird 2 users is limited. If you think this bug meets the requirements below, please renominate with a detailed explanation of how it meets the following two criteria, and we will reconsider. To qualify, this bug must either: a) make the upgrade experience from TB2 very painful for a large number of users or b) be a new, reproducible, severe quality issue (eg dataloss, frequent crashes) Just because this bug doesn't block TB3.1 doesn't mean it can't or won't make the release. Once they're done with their blockers (if any), we encourage developers to keep working on non-blocking bugs, and to try to land them as early in the cycle as possible, as non-blocking bugs will become increasingly difficult to land in the later stages of the cycle.
blocking-thunderbird3.1: ? → ---
Comment 4•14 years ago
|
||
Not going to block a 3.0.x release on this as it is only meant to prevent casual usage as files can still be accessed anyway. We would take a fix if it is sensible and low enough risk for the stable branch.
blocking-thunderbird3.0: ? → -
status-thunderbird3.0:
--- → wanted
Updated•5 years ago
|
Severity: major → normal
Comment 6•5 years ago
|
||
I wasn't aware of hidden pref mail.password_protect_local_cache
But I just tested it. I set a master password, restarted, and didn't enter the master password.
In that scenario, no messages are shown.
Looks like this is WFM.
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(kaie)
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•