303523 - "Do not load remote images ..." blocks enigmail

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Patrick Mairif]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de_DE; rv:1.7.10) Gecko/20050726
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de_DE; rv:1.7.10) Gecko/20050726

The option "Do not load remote images ..." activated in mozilla 1.7.10 and 1.7.11 
blocks invokations of messenger.loadURL(..., "enigmail:xxx"). That causes
enigmail not decrypting/verifying PGP/MIME messages.

I posted this on the enigmail bugtracker first. see
http://bugzilla.mozdev.org/show_bug.cgi?id=11142 for details.

Reproducible: Sometimes

Steps to Reproduce:
1. set "Do not load remote images in Mail & Newsgroup messages"
2. restart mozilla
3. open PGP/MIME encrpyted or signed or encrypted/signed message and let
enigmail verify/decrypt it.

Actual Results:  
The encrypted Message is shown as attachment ("Part 1.1" and "encrpted.asc").
Signed messages are not verified.

Expected Results:  
Message signatures should be verified. Encrypted messages should decrypted inline.

Comment 1

[Patrick Mairif]

Attachment: Indicate location for this issue/possible fix

Thanks to Norbert Warmuth for this patch.
It is to indicate the location for this issue (and a possible fix without
deactivating the ""Do not load remote images ..." option completely).

Comment 2

[Frank Wein [:mcsmurf]]

Somehow i don't like this fix (since it special-cases a extension in Mozilla
code), maybe someone can come up with a better fix...

Comment 3

[Frank Wein [:mcsmurf]]

David: Another fallout from Bug 294307?

Comment 4

[Jason Bassford]

*** This bug has been marked as a duplicate of 300689 ***

Comment 5

[Jason Bassford]

Oops!  Sorry.

Comment 6

[David :Bienvenu]

yes, fallout, and the patch would fix it, but I really don't like hard-coding
enigmail in there either. Why is enigmail trying to run its own urls? Boris, any
ideas for allowing extensions to do this kind of thing in a general way? 

Comment 7

[Boris Zbarsky [:bzbarsky]]

Not offhand, no. Darin, biesi, thoughts?  Note that in tbird this is not a
problem since tbird uses a protocol _blacklist_, effectively, but for suite on
the 1.7 branch a blacklist is not really acceptable.

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

I suppose you could invent a protocol handler flag...

Comment 9

[Darin Fisher]

Sorry, I don't know what to suggest.  I'd probably reluctantly add enigmail to
the list on the 1.7 branch since at least it solves the very real problem of a
busted enigmail in a very safe and minimal way.

Comment 10

[Boris Zbarsky [:bzbarsky]]

The basic problem is that we somehow want to limit loading to the protocols we
know are "safe" in mailnews (that is, only the internal ones used by mailnews
itself)...  This could be a probmlem in tbird as well, if an extension that
implements a protocol handler is installed, btw -- the remote images check would
allow that protocol handler through, I suspect.

Comment 11

[David :Bienvenu]

yeah, since it's for the 1.7.x branch, I guess I'm ok with that. But there will
need to be a fix for the seamonkey trunk when a fix for bug 294307 lands on the
trunk.

Comment 12

[Patrick Brunschwig]

(In reply to comment #6)
> Why is enigmail trying to run its own urls?  

Enigmail uses this mechanism to load and display inline-PGP messages (i.e.
Content-Type "text/plain" or "multipart/mixed"). These messages would otherwise
be _very_ tricky to display nicely in decrypted form, since text/plain and
multipart/mixed are not content-types to be handled by Enigmail.

Given the many difficulties of inline-PGP all over the code, I suppose this was
considered an elegant way to display an inline-PGP message nicely (but that was
before I joined the team).

Comment 13

[Frank Wein [:mcsmurf]]

Comment on attachment 191677 [details] [diff] [review]
Indicate location for this issue/possible fix

So lets do it like this for 1.7 branch only? I do not like this, but i also see
no other easy solution for our code or the Enigmail code.

Comment 14

[Darin Fisher]

Comment on attachment 191677 [details] [diff] [review]
Indicate location for this issue/possible fix

sr=darin (reluctantly)

Comment 15

[Boris Zbarsky [:bzbarsky]]

This isn't just a seamonkey problem, is it?  Thunderbird has the same issue any
time a protocol handler is installed and the relevant
network.protocol-handler.expose.* pref is not set.  If the pref _is_ set, then
links using that scheme can conceivably be used to retrieve remote content from
emails...  So there's no really safe way to add new protocols to mail that I can
see...

Comment 16

[Daniel Veditz [:dveditz]]

Comment on attachment 191677 [details] [diff] [review]
Indicate location for this issue/possible fix

a=dveditz for drivers, please add fixed1.7.13 keywords when checked in.

Comment 17

[David :Bienvenu]

fixed on moz 1.7 branch

Comment 18

[Marcia Knous [:marcia]]

Patrick: Since I don't have a mail profile set up in the Mozilla Suite with Enigmail on Linux, can you verify this fix in the Linux build dated 20060302-12?

Comment 19

[Patrick Brunschwig]

Marcia, I'm not sure which Patrick you meant :-) Anyway, I tested the Linux build you mentioned, and it's working fine.