Talk:Extension Manager:Addon Update Security

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.

• That is correct. However in order for the updateURL to be used at all it must be digitally signed. --Mossop

• • So the resource at http://foo.com/update.rdf would never be retrieved? In other words, both https:// URLs in install.rdf and em:updateHash values in update.rdf are required? --Grimholtz 12:35, 9 July 2007 (PDT)

• • • There are two possibilities. It will be retrieved if the add-on has provided a public key for the purposes of verifying the digital signature in the update manifest. It would also be retrieved for older extensions not yet compatible with Firefox 3 which have not yet been updated to meet the security requirements. Otherwise no it would not be retrieved. --Mossop

• • • • It [update.rdf] will be retrieved if the add-on has provided a public key for the purposes of verifying the digital signature in the update manifest. Doesn't this create a chicken-and-egg problem? I'm assuming by "update manifest" you mean update.rdf. If so, how will FF know if a public key has been provided in the update manifest if it can't download it?

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.

• This is currently incorrect. The current version of the proposal requires updateHashes to be present at all times. There have been suggestions that this should be dropped in the event that the updateLink is on a secure server but that has not been finally decided. --Mossop

3. Suppose install.rdf contains no updateURL. FF EM exclusively contacts AMO via https:// for updates.

• This is correct for a regular install of Firefox yes. Obviously it is possible for users to change the extensions.update.url preference to point anywhere they like, but that should be the only case where this wasn't true. Obviously third party applications may choose to use somewhere else for update checking by default. --Mossop

--Grimholtz 12:18, 9 July 2007 (PDT)