I noticed today that a malware add-on that we blocked, IB Updater, seems to have pushed out an update on February 27th which updated existing blocked users to a new version with a non-blocked ID: http://panorama.khan.mozilla.org/fisheye/ecosystem/addon/%7B336D0C35-8A85-403a-B9D2-65C292C39087%7D http://panorama.khan.mozilla.org/fisheye/ecosystem/addon/%7BFE1DEEEA-DB6D-44b8-83F0-34FC0F9D1052%7D This is a pretty huge problem, since it means that any add-on that we've blocked can be trivially re-enabled by authors, so long as it supports updates.
What would you want changed here, barring blockisted add-ons from updating entirely or just from being able to update to a new ID?
I think that preventing them from updating to a new ID is the right solution. Preventing them from updating entirely would limit our ability to block add-ons with issues that could be addressed in an update. It would be nice to have a blocklist flag to prevent updates entirely, but that's something for the blocklist service rewrite, I think.
(In reply to Kris Maglione [:kmag] from comment #2) > I think that preventing them from updating to a new ID is the right > solution. Preventing them from updating entirely would limit our ability to > block add-ons with issues that could be addressed in an update. > > It would be nice to have a blocklist flag to prevent updates entirely, but > that's something for the blocklist service rewrite, I think. Agree.
tracking-firefox22: ? → ---
tracking-firefox23: --- → +
tracking-firefox24: --- → +
status-b2g18: --- → wontfix
status-firefox22: --- → wontfix
status-firefox23: --- → affected
status-firefox24: --- → affected
status-firefox-esr17: --- → affected
Dave: can you find an owner for this? Let me know if my team can help.
(In reply to :Gavin Sharp (use firstname.lastname@example.org for email) from comment #4) > Dave: can you find an owner for this? Let me know if my team can help. The fix here is simple I think, add something like this here http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/XPIProvider.jsm#5141: if (self.existingAddon.id != self.addon.id && self.existingAddon.blocklistState == STATE_BLOCKED) return self.downloadFailed(<some sensible reason>); I don't have any spare time to write tests for this though. Blair do you have some spare cycles?
Flags: needinfo?(dtownsend+bugmail) → needinfo?(bmcbride)
Sadly, the amount of cycles I have is a negative number. I actually thought Kris had offered to take this, after we discussed it originally.
Yeah, I can take it if you guys don't have the cycles, but I'm in the same boat.
Assignee: nobody → kmaglione+bmo
status-firefox25: --- → affected
tracking-firefox25: --- → ?
At this stage in FF23 beta cycle we'll have to call this a miss, but keep tracking for later versions so this doesn't slip through the cracks.
status-firefox23: affected → wontfix
Any progress, Kris? Rating this sec-critical seems like an overestimation, since we don't know of this posing a problem in practice at all, AFAIK. Is that right?
When I wrote my tests, I found out that this was not quite the issue I thought it was. The update winds up being allowed only if the new version number served in the update.rdf is unblocked for the add-on's current ID. Which means, unfortunately, that the add-on mentioned in comment 0 was probably updated by a system service and there's probably nothing we can do to properly disable it.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
Removing tracking as this is resolved invalid.
tracking-firefox24: + → -
tracking-firefox25: + → -
You need to log in before you can comment on or make changes to this bug.