canmove, Confirmed users
1,570
edits
m (fixed bolding) |
|||
| 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) | **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. | |||
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. | 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. | ||