Allow whitelist configuration for what plugins can and cannot be ran within a gecko-based application

VERIFIED FIXED in mozilla16

Status

()

Core
Plug-ins
VERIFIED FIXED
5 years ago
2 years ago

People

(Reporter: jsmith, Assigned: johns)

Tracking

15 Branch
mozilla16
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking-kilimanjaro:+, firefox16-)

Details

(Whiteboard: [Desktop WebRT], [qa!], [blocking-webrtdesktop1+])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
The desktop web runtime needs the ability to configure the underlying core to only allow versions of flash to run within the runtime. All other plugins are planned to not be allowed within the runtime, although we should be ready to evolve and change quickly if we discover later down the line that we need to enable other plugins.

The implementation I heard discussed in today's apps meeting considered configuring a whitelist of the plugins that are allowed to run.

This is needed for the first release of the desktop web runtime (Fx 15).
(Reporter)

Updated

5 years ago
Blocks: 755554
(Assignee)

Comment 1

5 years ago
I can look into this, it shouldn't be very difficult
Assignee: nobody → jschoenick
(Reporter)

Updated

5 years ago
Whiteboard: [Desktop WebRT]
(Reporter)

Comment 2

5 years ago
Nominating for k9o - this is needed for the desktop web runtime to only enable flash in the runtime.
blocking-kilimanjaro: --- → ?
blocking-kilimanjaro: ? → +
jst, this has been called out as the correct implementation for bug 755554, can you confirm?
(Assignee)

Comment 4

5 years ago
Created attachment 638498 [details] [diff] [review]
Implement plugin.allowed_types whitelist

This adds plugin.allowed_types, which limits what MIME types plugins can claim (comma separated)

Right now it does not completely suppress (mark invalid) plugins that claim no valid types -- they'll be in the plugin registry, but will not be associated with any types or suffixes. We could suppress these, but that would mean that modifying this pref would require deleting pluginreg.dat
(Reporter)

Updated

5 years ago
tracking-firefox16: --- → ?
(Reporter)

Comment 5

5 years ago
Flagging for tracking FF 16 - we need this for desktop web runtime 1st release
(Assignee)

Comment 6

5 years ago
Comment on attachment 638498 [details] [diff] [review]
Implement plugin.allowed_types whitelist

Note that the 'IsTypeInPrefList' helper duplicates some nsPluginTag::RegisterWithCategoryManager code, which goes away with a patch on bug 751237 (it just makes sense to land this first)
Attachment #638498 - Flags: review?(joshmoz)

Updated

5 years ago
Attachment #638498 - Flags: review?(joshmoz) → review+

Updated

5 years ago
tracking-firefox16: ? → +
Comment on attachment 638498 [details] [diff] [review]
Implement plugin.allowed_types whitelist

>diff --git a/dom/plugins/base/nsPluginHost.cpp b/dom/plugins/base/nsPluginHost.cpp

>+nsPluginHost::IsTypeWhitelisted(const char *aMimeType)
>+{
>+  if (!Preferences::HasUserValue(kPrefWhitelist)) {
>+    return true;

This will mean that a default value of the preference won't be effective - isn't that what we need for bug 755554?
https://hg.mozilla.org/mozilla-central/rev/b6488e90d566
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla16
(Reporter)

Updated

5 years ago
Whiteboard: [Desktop WebRT] → [Desktop WebRT], [qa-
(Reporter)

Updated

5 years ago
Whiteboard: [Desktop WebRT], [qa- → [Desktop WebRT], [qa-]
(Assignee)

Comment 9

5 years ago
Created attachment 640453 [details] [diff] [review]
Followup, check if the preference has a value, not necessarily a user value
(Assignee)

Comment 10

5 years ago
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #7)
> This will mean that a default value of the preference won't be effective -
> isn't that what we need for bug 755554?

Bah, I intended that the whitelist not be enforced if it was empty, but clearly HasUserValue is not going to work if we're giving it defaults.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla16 → ---
(Assignee)

Updated

5 years ago
Attachment #640453 - Flags: review?(joshmoz)
Comment on attachment 640453 [details] [diff] [review]
Followup, check if the preference has a value, not necessarily a user value

Why not just put the pref check in IsTypeInPrefList() itself, since it's already reading the pref anyways?
(Assignee)

Comment 12

5 years ago
Created attachment 640476 [details] [diff] [review]
Followup, check if the preference has a value, not necessarily a user value
Attachment #640476 - Flags: review?(joshmoz)
(Assignee)

Comment 13

5 years ago
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #11)
> Comment on attachment 640453 [details] [diff] [review]
> Followup, check if the preference has a value, not necessarily a user value
> 
> Why not just put the pref check in IsTypeInPrefList() itself, since it's
> already reading the pref anyways?

IsTypeInPrefList is a helper to deduplicate code between this and the category manager changes in bug 751237, where we don't want to return true if the pref is empty. I can change it to just move the GetString call out of the helper for simplicity
(Assignee)

Updated

5 years ago
Attachment #640453 - Attachment is obsolete: true
Attachment #640453 - Flags: review?(joshmoz)
(Reporter)

Updated

5 years ago
Whiteboard: [Desktop WebRT], [qa-] → [Desktop WebRT], [qa-], [blocking-webrtdesktop1+]

Updated

5 years ago
Attachment #640476 - Flags: review?(joshmoz) → review+
(Assignee)

Comment 14

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/686cf6e6ed4b
https://hg.mozilla.org/mozilla-central/rev/686cf6e6ed4b
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla16
Should bugs be filed blocking this if we want to add other plugins to the whitelist? Silverlight for Netflix, for example.
(Assignee)

Comment 17

5 years ago
(In reply to Reuben Morais [:reuben] from comment #16)
> Should bugs be filed blocking this if we want to add other plugins to the
> whitelist? Silverlight for Netflix, for example.

Enabling the whitelist in webrt was done in bug 755554, so that may be a better target
(Reporter)

Comment 18

5 years ago
Verified through testing of bug 755554 for Win 7, OS X 10.7, and Ubuntu 12.
Status: RESOLVED → VERIFIED
Whiteboard: [Desktop WebRT], [qa-], [blocking-webrtdesktop1+] → [Desktop WebRT], [qa!], [blocking-webrtdesktop1+]
tracking-firefox16: + → -
(Assignee)

Updated

5 years ago
Attachment #638498 - Flags: checkin+
(Assignee)

Updated

5 years ago
Attachment #640476 - Flags: checkin+
It seems like this bug missed the daily check for updates and is the cause of https://bugzilla.mozilla.org/show_bug.cgi?id=768521?
Blocks: 768521
You need to log in before you can comment on or make changes to this bug.