Talk:Extension Manager:Addon Update Security

From MozillaWiki
Jump to: navigation, search

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 retrieve it? --Grimholtz
            • It reads well. It's the wording above (in this thread) that confused me. I thought you were writing that the public key is included in the update.rdf. However, based on the link you provided, it's clear that's not what you meant. It sounds like the public key will be in install.rdf or in some other file packaged in the XPI... perhaps it can be specified as a URL in install.rdf so we can publish the public key in a public place instead of hiding it in the XPI. Anyway, thanks for the clarification and good luck with the implementation. --Grimholtz 13:26, 9 July 2007 (PDT)
              • Publishing the public key on a url would break the security it provides unless that url was secure, thus making the use of the signature pointless.

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
    • I would like to see the requirement for updateHashes dropped if SSL is used for the updateLink (assuming that does not leave any security holes). Why? Because for some of my company's extensions we generate a custom .xpi file on the fly at download time (in order to embed user preferences and so on)... which makes it very expensive to provide an updateHash. --Mark Smith

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)

1. I already sign my XPI files with signtool and my code signing cert which creates the META files with the hash embedded. Will there be a check to see if that is used instead having to also sign the updates.rdf file?

2. If that wouldn't be possible then could the same cert also generate a new updates.rdf file that includes the hash. I could create a new build script to do just that and it would still make everything pretty painless making a release.

--Sgrayban 11:48, 18 July 2007 (PDT)

No-SSL downloads

Am I correct in my assumption that this proposal allows you to get away with not using SSL for any part of the updates process if:

  1. Sign the updates.rdf file with your private key; install your public key with your .xpi file during the initial install.
  2. Provide updateHash for each xpi in updates.rdf (that has been signed by your private key).

--Silfreed 19:36, 16 July 2007 (PDT)

PHP implementation

Will there be a PHP implementation of the tool (used to hash the xpi, add it to the update.rdf file and sign it) ?
I'm part of an extensions translation team, who hosts some of our translations on our site (I'm not talking about BabelZilla, which is used when the extension author collaborates). If each of us has to use the xulrunner tool to make the updates work, we'll have to create a private key and make it public so every translators can upload their translations. Of course, this is insecure, but it's the only way to avoid breaking extension updates (translator change, key lost...).
A PHP implementation would make it easier for us and would increase the security of the updates. The RedBurn 02:43, 15 September 2007 (PDT)

There are no plans to provide such a version of the tool, firstly we can only really concentrate on one form of the tool for the time being and the simple application will be usable by the majority of authors. Secondly what you are suggesting is questionable from a security perspective since it requires you keep your cryptographic keys and passwords on a webserver. Really for what you are suggesting either one person should do the ultimate signing of the update, or simply host using ssl which is the preferred option for large scale hosting. Mossop

As you guess, it's not a commercial site, so a paid SSL certificate is not an option.
What about delivering SSL certificates signed by Mozilla (which should be added to the trusted authorities) ?
I think that the price of the certificates is the main obstacle for the authors to use SSL. The RedBurn 07:23, 15 September 2007 (PDT)

SSL certificates are far from expensive. StartCom do a free certificate that is trusted by Firefox and a number of other browsers. For a certificate that is trusted by all browsers then GoDaddy have a $18 per year option (first year free if you are an open source project). Mossop

Retrieved from "https://wiki.mozilla.org/index.php?title=Talk:Extension_Manager:Addon_Update_Security&oldid=84471"