Hi, this email is directed at Dave Townsend, who is listed as the assignee of "Bug 378216 – Disable insecure extension updates by default." [1] I'm cc'ing [EMAIL PROTECTED]
Brief background: We are hosting 280 Firefox extensions on libx.org (using http, unsigned as of now) and need to prepare for the impending update to FF3.0. Since the libx codebase is hosted on libx.mozdev.org, I consulted the mailing list for project owners for advice. However, there is confusion about whether Firefox provides an acceptable migration path to using secure updates or not. Some claim there is no migration path without an interim update before the FF 3.0 update, some believe that FF 3.0 will allow 1 unsafe update before enforcing safe updates. The online documentation is inconclusive and contradictory. For instance, [2] states: "In order to support updating add-ons which do not currently meet the new requirements there will be the possibility of a insecure update checks for the add-on after the user updates to Firefox 3." This grammatically incorrect sentence is difficult to parse, but it seems to imply that FF 3.0 would allow 1 insecure update; yet below, it says under "Impact on Other Authors" "In either case in order to continue to deliver automatic updates to their users after Firefox 3 is released they must release a new version of their add-on supporting Firefox 3 before their users update to Firefox 3." Which seems to imply there is no migration path unless end users update before installing FF 3.0. This would be a tremendous hassle for us since we do not directly create .xpi files - the maintainers of LibX editions do. It would be wonderful if you clarify the situation, both in a reply to this list and on the website above. In addition, [2] talks about a "Proposed Implementation" - it is not unequivocally clear if the page describes a proposal that was adopted or one that was rejected or one that's still being discussed. The documentation that is provided here [3] does not discuss migration at all. On a related note, we are currently discussing whether to use https or to switch to signed .xpis in preparation. Would switching to https help us? For instance, could we 302 redirect the currently installed updateLinks to an https: location on our servers and convince FF3.0 to accept our updates this way? Could you describe what behavior end users will see if the "redirect-to-https" method does not work and if there is no other migration path available to us. Again, the documentation at [2] is inconclusive. It says: "However Firefox will continue to check for updates to the extension normally. It will only install updates that meet the new criteria for extension installs, that is the update add-on must support secure updates." If the "criteria" is that the extension is either signed by hash, or the updateLink is a https:// URL (as said in [3]) in the already installed extension, then what will Firefox continue to check for? The criteria, which depend on what's already installed, won't change unless the user reinstalls the extension. I am probably misunderstanding the discussion, but as the confusion on the project owners mailing list shows, I may not be the only one. Thank you for any insights you could provide. - Godmar [1] https://bugzilla.mozilla.org/show_bug.cgi?id=378216 [2] http://wiki.mozilla.org/User:Mossop:Fx-Docs:AddonUpdateSecurity [3] http://developer.mozilla.org/en/docs/Extension_Versioning%2C_Update_and_Compatibility#Securing_Updates _______________________________________________ Project_owners mailing list [email protected] https://www.mozdev.org/mailman/listinfo/project_owners
