527664 - Remote content is no longer blocked

Status: RESOLVED FIXED

(Thunderbird :: Security, defect)

Description

[Mark Banner (:standard8)]

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.

Comment 1

[Mark Banner (:standard8)]

Attachment: The fix

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:).

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

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.

Comment 3

[David :Bienvenu]

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.

Comment 4

[Mark Banner (:standard8)]

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)