canmove, Confirmed users
1,570
edits
| Line 32: | Line 32: | ||
* Ensure that the update package retrieved matches that specified by the update manifest. | * Ensure that the update package retrieved matches that specified by the update manifest. | ||
Each can be achieved in two different ways giving a total of 4 different methods available to add-on authors for securing the update process. | |||
=== Ensuring Update Manifest Security === | === Ensuring Update Manifest Security === | ||
| Line 66: | Line 66: | ||
=== Ensuring Update Package Security === | === Ensuring Update Package Security === | ||
In order to ensure that the update package is retrieved securely one of the following two methods must be used: | |||
==== Securing Update Packages Through SSL ==== | |||
Delivering the xpi package over an SSL is the simplest way to ensure that it reaches the user untampered with. | |||
==== Securing Update Packages Through Hashes ==== | |||
If the update package is not being delivered by an SSL connection then an updateHash entry must be present. This is a hash calculated from the xpi file and will currently be limited to the sha1, sha256, sha384 and sha512 algorithms. | |||
Even when using an ssl connection the updateHash may be used for added confidence that the file retrieved is the correct one, however this protects the user from a mistake by the add-on author rather than from any malicious intent. | |||
=== Covering Compromises === | === Covering Compromises === | ||