304833 - help: doesn't work on linux (MacOS security issue)

Status: RESOLVED FIXED

(Core :: Networking, defect, P1)

Description

[Chris Lahey]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050715 Firefox/1.0.6 SUSE/1.0.6-8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050715 Firefox/1.0.6 SUSE/1.0.6-8

help: was blacklisted because of a security hole on MacOS.  However, on linux,
help: is used in KDE and probably will be in gnome soon.

Therefore, help: should only be blacklisted on MacOS.

Reproducible: Always

Steps to Reproduce:
1. Link to a help: uri.
Actual Results:  
Doesn't show up as a link.

Expected Results:  
Shown a link.

Comment 1

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

bug 243699 added this pref

Comment 2

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

Attachment: patch

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This particular symptom only happens in 1.7. In 1.8 and later, the situation is
different because for a blocked protocol we still allow the URI to be created,
we just assign it a "blocked" protocol handler.

Although this could would be a problem if we want GNOME or KDE to be able to
really load "help:" URLs from the browser via an external protocol handler. Do
we? If we don't, or we only want help: URLs to work in particlar embedding
applications, then I suggest we *not* use this fix. A particular embedding
application could use a profile where this preference was explicitly set to true.

Comment 4

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

Comment on attachment 192832 [details] [diff] [review]
patch

dveditz is on vacation, switching sr request

I think we still want this. For example, when browsing local documentation, it
may want to link to a help file.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 192832 [details] [diff] [review]
patch

ok. this is safe enough as far as we know.

Comment 6

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

Checking in modules/libpref/src/init/all.js;
/cvsroot/mozilla/modules/libpref/src/init/all.js,v  <--  all.js
new revision: 3.589; previous revision: 3.588
done

Comment 7

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

Comment on attachment 192832 [details] [diff] [review]
patch

allows loading help: uris on non-macos systems; this should be safe since the
security issue is only with help: uris on macos.

Comment 8

[Asa Dotzler [:asa]]

approving but this would have been nice to have nominated earlier in the cycle.

Comment 9

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

sorry, this bug was only pointed out to me a week ago.
MOZILLA_1_8_BRANCH:
Checking in modules/libpref/src/init/all.js;
/cvsroot/mozilla/modules/libpref/src/init/all.js,v  <--  all.js
new revision: 3.585.2.3; previous revision: 3.585.2.2
done

Comment 10

[benc]

Can someone explain to me... what is the valid format of a help: URL?

The big problem here is apple went and created a couple lame URL types for their
OS. (Then again, Netscape probably was the originator of this bad practice)