User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008012204 Minefield/3.0b3pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008012204 Minefield/3.0b3pre Try to intall http://www.krickelkrackel.de/autohide/autohide.xpi with latest trunk. The following message appears: "Autohide" will not be installed because it does not provide secure updates Autohide 1.1.5 is not compatible with Fx3 and the user should get that information and not the information about security. For me it sounds like Autohide is insecure and not the update mechanism of Fx2. Autohide is clearly marked as NOT compatible with Fx3, because Fx3 is not mentioned at all in install.rdf or update.rdf. Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: The user gets information about security. Expected Results: The user should get information about compatibility.
So there is an interesting question here. For most extensions, if they appear to be incompatible, we can check the update information and still install them if they appear to be compatible according to the server side. Obviously we can't do that if the extension is not using a secure update path so we can't decisively say that the extension is incompatible. I would hope that this is a situation that won't come up much soon, all extension's will have to use a secure update path so there should end up being very few that aren't, only old ones. Possibly we could just change the error message for insecure extensions to just say they are equally incompatible.
I think it should be enough to check the version compatibility first. Of course the situation will not come up very often, but I think that before marking an extension as "insecure" a simple check of compatibility with the extensions "install.rdf" is more than fair. Forget about the possible "update.rdf". Too much hassle I think. I simply don't want "Autohide" marked to be insecure, because it is only incompatible. (And yes: I've received several emails talking about security) So Autohide is being "branded" as insecure only because Fx2 was insecure and Autohide used the update mechanism provided by Fx2. Imho, it is perfectly ok to change the error message.
> So Autohide is being "branded" as insecure only because Fx2 was insecure and > Autohide used the update mechanism provided by Fx2. Firefox 2 had several update mechanisms and you chose the one that is insecure. Firefox 2 is only "insecure" in this way if you have installed extensions that chose the insecure mechanism. So I don't think the message in Firefox 3 is as misleading as you claim.
(In reply to comment #3) > Firefox 2 had several update mechanisms and you chose the one that is insecure. > Firefox 2 is only "insecure" in this way if you have installed extensions that > chose the insecure mechanism. So I don't think the message in Firefox 3 is as > misleading as you claim. > Sorry. It was not my intention to complain that I have used an insecure mechanism. I only wanted to complain (with comment 2) that an update mechanism provided by the app is now turned into a security hole of an extension. But the real bug remains. Fx3 is talking about security although the extension is not compatible with Fx3. So I think that checking the updateURL should take place after checking the compatibility info within the extension. (NOT from a remote update.rdf) I have no problem with the current (trunk) solution of securing updates. But I have a problem providing words like "security" to joe average about extensions that would normally not install at all because they are not compatible. And to my disliking there are enough "joe average people" trying Fx3beta.
Seems a reasonable issue
Seems to be an old issue. -> wfm