Closed
Bug 527664
Opened 15 years ago
Closed 15 years ago
Remote content is no longer blocked
Categories
(Thunderbird :: Security, defect)
Thunderbird
Security
Tracking
(Not tracked)
RESOLVED
FIXED
Thunderbird 3.0rc1
People
(Reporter: standard8, Assigned: standard8)
References
Details
(Whiteboard: [no l10n impact])
Attachments
(1 file)
(deleted),
patch
|
dmosedale
:
review+
Bienvenu
:
superreview+
|
Details | Diff | Splinter Review |
This is fallout from bug 516776 - we're no longer blocking remote content. Although I didn't look at them straight away, the mozmill tests alerted me to this.
The issue is that in nsMsgContentPolicy we're using the values of the network.protocol-handler.expose.* preferences to determine if to blindly allow the load of the protocol or not.
SeaMonkey do something different and just use a hard-coded table to compare the scheme of the content being loaded against (because network.protocol-handler.expose-all will be true for them).
I think we can do the same as SeaMonkey here - we shouldn't need to do it on a prefs basis. I'm working on a patch.
Flags: blocking-thunderbird3+
Updated•15 years ago
|
Whiteboard: [no l10n impact]
Assignee | ||
Comment 1•15 years ago
|
||
This fixes the content policy tests - just use what SeaMonkey does (which is basically the same as our previous list apart from the addition of about:).
Attachment #411405 -
Flags: superreview?(dmose)
Attachment #411405 -
Flags: review?(dmose)
Assignee | ||
Updated•15 years ago
|
Whiteboard: [no l10n impact] → [no l10n impact][needs review dmose]
Comment 2•15 years ago
|
||
Comment on attachment 411405 [details] [diff] [review]
The fix
I'm not a big fan of adding another hardcoded list in addition to the one in the prefs, but I don't have a good alternative to propose. r=dmose, if you add comments both to the content policy and to all-thunderbird.js making it clear that someone who is touching one probably also wants to touch the other.
Since this is code is security sensitive and known to be complex, I'd like to get a second pair of eyes on it. Moving sr to bienvenu.
Attachment #411405 -
Flags: superreview?(dmose)
Attachment #411405 -
Flags: superreview?(bienvenu)
Attachment #411405 -
Flags: review?(dmose)
Attachment #411405 -
Flags: review+
Updated•15 years ago
|
Whiteboard: [no l10n impact][needs review dmose] → [no l10n impact][has patch, review; needs sr bienvenu]
Updated•15 years ago
|
Attachment #411405 -
Flags: superreview?(bienvenu) → superreview+
Comment 3•15 years ago
|
||
Comment on attachment 411405 [details] [diff] [review]
The fix
Seems reasonable. At some point, it might be worthwhile to have some centralized function that says if a content scheme is a mailnews scheme.
Updated•15 years ago
|
Whiteboard: [no l10n impact][has patch, review; needs sr bienvenu] → [no l10n impact][ready to land]
Assignee | ||
Comment 4•15 years ago
|
||
Checked in:
http://hg.mozilla.org/comm-central/rev/0706c60f5c0c
http://hg.mozilla.org/releases/comm-1.9.1/rev/7d8eeb4a4458
(setting in-testsuite+ as this is already covered by testsuite)
Status: NEW → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [no l10n impact][ready to land] → [no l10n impact]
You need to log in
before you can comment on or make changes to this bug.
Description
•