No more «version bumping» ?
What about already-existing extensions whose code (I'm talking of the fundamentals here, not about signing, hashing, or even "declared" version compatibility) happens to be already compatible with Fx3 / Tb3 / Sm2 / etc.? What about existing extensions, possibly tested with Minefield, which already declare themselves "compatible with Fx3" but include no crypto signature? What about the well-known practice of «version bumping» (unzip the xpi, change the maxVersion upwards, don't change anything else, rezip)? Tonymec 18:04, 1 July 2007 (PDT)
- There should not be any add-ons already marking themselves as compatible with Firefox 3, if there are then they are in error. It has always been the case that add-ons should not mark themselves as compatible with a version unless it has been tested on it (or at least an RC of it). If there are any such add-ons that don't meet the requirements for secure updates then they will likely be disabled Mossop
- I intend to work something out to allow some kind of version bumping to go on but the exact plans for this haven't been finalised Mossop
Non-conforming Add-ons
I understand why add-ons that provide update functionality must do so securely, but why does this proposal require that add-ons provide update functionality?--Np 17:31, 2 July 2007 (PDT)
- There is not requirement that add-ons provide update functionality, only that if they do so that it is secure. If no updateURL is specified in the add-on's install.rdf then the add-on will install (since that makes it default to using AMO for updates which already meets the criteria for secure updates) Mossop
- Can you update the page to reflect this, especially "Add-ons that do not provide either of the previous methods of retrieving a secure update manifest must not mark themselves as compatible with Firefox 3." and "When the user updates all add-ons that do not support secure updates will be disabled" and "Any other add-on authors have two options open to them"--Np 14:34, 5 July 2007 (PDT)
Update Scenarios
Can you confirm that these three scenarios are accurate and cover all possibilites?
1. Suppose install.rdf contains an em:updateURL of http://foo.com/update.rdf. When FF retrieves the resource at http://foo.com/update.rdf, if the resource does not contain an em:updateHash element or the value of the em:updateHash element is incorrect, the update is not installed.
2. Suppose install.rdf contains an em:updateURL of https://foo.com/update.rdf. When FF retrieves the resource at https://foo.com/update.rdf, FF will install the update even if no em:updateHash element exists (assuming there are no problems with the certificate for foo.com). If, however, em:updateHash does exist, it is checked for validity against the update.
3. Suppose install.rdf contains no updateURL. FF EM exclusively contacts AMO via https:// for updates.
--Grimholtz 12:18, 9 July 2007 (PDT)