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)

x86
All
defect
Not set
normal

Tracking

(blocking-thunderbird3.0 -, thunderbird3.0 wanted)

RESOLVED WORKSFORME
Tracking Status
blocking-thunderbird3.0 --- -
thunderbird3.0 --- wanted

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
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
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
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: ? → ---
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: ? → -
Severity: major → normal

I didn't remember we has such an option

Flags: needinfo?(kaie)

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.