mwu has added support for blocklisting plugins in bug 330511.
Bug 271559 actually adds the code that reads and uses plugins blocklisting information from blocklist.xml.
Depends on: 271559
Is there anything about plugins that extends past the scope of the current blocklist.xml schema? See: http://wiki.mozilla.org/Extension_Blocklisting:Code_Design
12 years ago
The plugin blocklisting update to the blocklist.xml schema are fairly simple. Here's an example: <blocklist> <pluginItems> <pluginItem> <!-- All match tags must match a plugin to blocklist a plugin --> <match name="name" exp="some plugin"/> <match name="description" exp="1[.]2[.]3"/> </pluginItem> </pluginItems> </blocklist> The name attribute in the match tag can match any string attribute defined in http://lxr.mozilla.org/mozilla/source/modules/plugin/base/public/nsIPluginTag.idl . The exp attribute contains a regular expression which is used to match an attribute in the plugin tag. If all the match tags in a pluginitem match, the plugin is blocklisted.
Flags: blocking-firefox3? → blocking-firefox3+
hi, just wondering what the status and timeline for this feature. is there plans to target beta 3?
I thought plugin blocklisting works, since bug 388445 was verified; see https://bugzilla.mozilla.org/show_bug.cgi?id=388445#c19
thats what i thought too. when i verified that bug, at least the notification part was working. If this is really fixed, can we get this bug properly commented and status changed?
TODO: * update blocklist schema wiki page (see comment #2) * create new table for pluginitems (kind of like blitems, but blpluginitems instead) * add logic in script to pull from plugin table * add logic in script to iterate over results and display plugin list in the XML ETA is Feb 7-ish.
Assignee: nobody → morgamic
Stephen/Tony -- plugins don't have GUIDs, so the name/regex matching in pluginItem entries is a fix for that. Since they followed a different install method for a pretty long time before we centered on the method used for today's extensions, they are a special case and aren't covered by the existing schema.
mwu -- so just description, filename and name, right?
One more quesiton -- if I have a <pluginItem> entry is it possible to define an application range for it, or is blocklisting of a plugin application-agnostic? For extensions it was possible to define this: <emItem id="item_4@domain"> <versionRange> <targetApplication> <versionRange minVersion="1.5" maxVersion="1.5.*"/> </targetApplication> </versionRange> </emItem> I'm guessing it's app-agnostic since they are pure binaries, but want to confirm.
Answers: #9: yes, just those #10: yes, app-agnostic Wanted to make sure. So we'll move forward with those assumptions. I updated the wiki to reflect this: http://wiki.mozilla.org/Extension_Blocklisting:Code_Design#Blocklist_syntax
Will add tests tomorrow -- Fred can you take a look at the schema and basics?
Attachment #308590 - Flags: review?(fwenzel)
Comment on attachment 308590 [details] [diff] [review] first stab at schema and blocklist.php patch In general, the patch looks good. But please use a MySQL index that spans the two columns we are querying here together, not each separately. (Also, if you want to remove a typo, line 240 says "errer" for "error").
Attachment #308590 - Flags: review?(fwenzel) → review-
K, fixed typo -- pretty sure that a multicolumn index won't make any difference, but will check...
Target Milestone: 3.2 → 3.4
Mike, ETA on getting this into production?
Just gotta write test so tomorrow looks peachy.
Tony - will work with you to stage it first as well.
thanks, i just need to know which plugin we plan to blocklist, version, and where to point my settings to. I'll have time to test this after we ship beta 5
Actually I need to know what we're blocklisting as far as plugins... so I can create a record for it?
To test, have to set SERVICE_URL and make sure you have TEST_DB_* setup correctly in your config (which you should already!!!) >:P
Comment on attachment 313592 [details] [diff] [review] v2, proper index, tests and test data, fixed typo Passes the test suite, looks good. Good job.
Attachment #313592 - Flags: review?(fwenzel) → review+
Checked in on trunk. Tony, let's meet on Friday to test a random plugin -- I'll ping ya.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [needs status update]
We need to add support for version _ranges_ in the app (Firefox can't parse them as with blitems/blapps). So reopening until version range checking is added. For now we can test with a specific version, though. Won't push until range support is added.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
ETA on this is Saturday.
S/Saturday/Monday/ -- started the patch but wasn't able to finish this weekend. Patch later this PM.
Patch on top of v2 which adds support for version ranges, tests included.
Attachment #314194 - Flags: review?(fwenzel)
Comment on attachment 314194 [details] [diff] [review] v3, adding support for version ranges WFM. New tests look good and pass as well. Not something to r- it for, but maybe you want to avoid the relative path in the require_once since it relies on the CWD and make it relative to dirname(__FILE__) instead?
Attachment #314194 - Flags: review?(fwenzel) → review+
Yeah, added dirname(__FILE__) thanks Fred. Checked in on r12064.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
Verified FIXED; I tested this today using Tony's Litmus testcases, and they all passed (Java, QuickTime, etc.), with rc1.
Status: RESOLVED → VERIFIED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.