Closed Bug 523116 Opened 15 years ago Closed 15 years ago

[AMO] Update production to fix blocklist issue

Categories

(Infrastructure & Operations Graveyard :: WebOps: Other, task)

All
Other
task
Not set
blocker

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: clouserw, Assigned: fox2mike)

Details

We wrote a patch for /webroot/services/blocklist.php to add severities and fix the WPF stuff that's floating around.

Please apply a local patch to production AMO.  You can either replace the entire file:

http://viewvc.svn.mozilla.org/vc/addons/trunk/site/app/webroot/services/blocklist.php?view=co

or apply a patch:

http://viewvc.svn.mozilla.org/vc/addons/trunk/site/app/webroot/services/blocklist.php?r1=53674&r2=53641

Let me know if you have questions.
->blocker
Severity: normal → blocker
Assignee: server-ops → shyam
The staged blocklist - https://preview.addons.mozilla.org/blocklist/1/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/3.5.3/ contains an entry that looks like this:

<pluginItem>
 <match name="name" exp="Windows Presentation Foundation"/>
 <versionRange severity="1"/>
</pluginItem>

which matches Dave's spec sent by email. It also adds empty <versionRange/> tags to some of the other plugins, but that looks to me like a safe thing, given the defensive way nsBlocklistService is coded (e.g. http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/src/nsBlocklistService.js#1097 which does a good job of not assuming attributes exist before using them).

Based on the above, I think this is the right call, I've copied Dave in though so that he can chime in with any concerns. I don't think we should block on Dave though, this matches his description.
Patch pushed to prod.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
[root@mradm02 addons.mozilla.org-remora]# patch -p2 < 523116.patch 
patching file site/app/webroot/services/blocklist.php
(In reply to comment #2)
> It also adds empty <versionRange/>
> tags to some of the other plugins, but that looks to me like a safe thing,
> given the defensive way nsBlocklistService is coded

Yes this should be fine.
Component: Server Operations: Web Operations → WebOps: Other
Product: mozilla.org → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.