Talk:Extension Manager:Addon Update Security: Difference between revisions

5,256 bytes added , 25 February 2008

m

User talk:Mossop:Fx-Docs:AddonUpdateSecurity moved to Talk:Extension Manager:Addon Update Security: Moving out of my user area to somewhere more sensible

Mossop

canmove, Confirmed users

1,567

edits

@@ Line 23: / Line 23: @@
 **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? --[[User:Grimholtz|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. --[[User:Mossop|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? --[[User:Grimholtz|Grimholtz]]
+***** The public key is available in the already installed add-on. I believed that [[User:Mossop:Fx-Docs:AddonUpdateSecurity#Securing_Update_Manifests_Through_Digital_Signatures]] was reasonably clear on that. Possibly you could suggest a rewording that makes it clearer? --[[User:Mossop|Mossop]]
+****** 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. --[[User:Grimholtz|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.
 . 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. --[[User:Mossop|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.  --[[User:mcs|Mark Smith]]
 . Suppose install.rdf contains no updateURL. FF EM exclusively contacts AMO via https:// for updates.
@@ Line 32: / Line 43: @@
 --[[User:Grimholtz|Grimholtz]] 12:18, 9 July 2007 (PDT)
+. 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?
+. 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.
+--[[User:Sgrayban|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:
+# Sign the updates.rdf file with your private key; install your public key with your .xpi file during the initial install.
+# Provide updateHash for each xpi in updates.rdf (that has been signed by your private key).
+--[[User:Silfreed|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) ?<br />
+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...).<br />
+A PHP implementation would make it easier for us and would increase the security of the updates. [[User:The RedBurn|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.
+[[User:Mossop|Mossop]]
+As you guess, it's not a commercial site, so a paid SSL certificate is not an option.<br />
+What about delivering SSL certificates signed by Mozilla (which should be added to the trusted authorities) ?<br />
+I think that the price of the certificates is the main obstacle for the authors to use SSL. [[User:The RedBurn|The RedBurn]] 07:23, 15 September 2007 (PDT)
+SSL certificates are far from expensive. [http://cert.startcom.org/ 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 [http://www.godaddy.com GoDaddy] have a $18 per year option (first year free if you are an open source project).
+[[User:Mossop|Mossop]]

Talk:Extension Manager:Addon Update Security: Difference between revisions

Talk:Extension Manager:Addon Update Security (view source)

Revision as of 12:24, 25 February 2008