MDN may have intermittent access issues April 18 13:00 - April 19 01:00 UTC. See whistlepig.mozilla.org for all notifications.

mozilla

Revision 275129 of Versionado, actualización y compatibilidad de extensiones

  • Enlace amigable (slug) de la revisión: Versionado,_actualización_y_compatibilidad_de_extensiones
  • Título de la revisión: Versionado, actualización y compatibilidad de extensiones
  • Id de la revisión: 275129
  • Creada:
  • Creador: Jseldon
  • ¿Es la revisión actual? No
  • Comentario /* Choosing minVersion and maxVersion */

Contenido de la revisión

{{wiki.template('Traducción', [ "inglés", "Extension_Versioning%2C_Update_and_Compatibility", "en" ])}}


Versionado de extensiones

Las extensiones deberán especificar su versión utilizando el Toolkit version format. Aquí puedes ver algunos ejemplos de versiones separadas por puntos:

  • 2.0
  • 1.0b1
  • 3.0pre1
  • 5.0.1.2
Nota: Antes de la versión 1.5 de Firefox se utilizaba un formato Firefox de versiones más básico que sólo permitía dígitos: número_de_versión_principal.número_de_versión_secundario.publicación.compilación{{mediawiki.external('+')}}. El toolkit version format (formato de versiones de herramientas), aunque es más flexible, sigue siendo compatible con el formato Firefox de versiones.

Sobre cómo las aplicaciones determinan la compatibilidad

Al instalar extensiones comprueba las entradas targetApplication en el <tt>install.rdf</tt> de la extensión. Debe haber una entrada con una ID que coincida con la ID de la aplicación. Además, el número de versión de la aplicación debe encontrarse dentro del rango definido por minVersion y maxVersion.

Si la aplicación tiene una entrada targetApplication, pero se debe a una versión incompatible, la aplicación obtendrá información actualizada sobre su compatibilidad de la updateURL de la extensión.

Si el install.rdf tiene alguna entrada targetPlatform, deberás escribir un informe sobre la aplicación o cancelar su instalación.

{{template.Fx_minversion_inline(3)}} En las aplicaciones basadas en Gecko 1.9 también puedes usar una entrada targetApplication con una ID toolkit@mozilla.org; minVersion, y maxVersion que coincidan con la versión de la aplicación. Esto te permitirá garantizar que tu extensión se puede instalar en cualquier aplicación (toolkit based).

Cancelación del control de compatibilidad

{{template.Fx_minversion_inline(1.5)}} Para la evaluación de extensiones puedes hacer que la aplicación ignore los controles de compatibilidad durante su instalación. Lo único que tienes que hacer es crear la preferencia extensions.checkCompatibility y darle valor False.

Nota: Antes de la versión 1.5 de Firefox, se podía utilizar la preferencia app.extensions.version para que la aplicación ignorase su versión e instalar así extensiones de otra forma incompatibles.

Elección de minVersion y maxVersion

minVersion y maxVersion deberían especificar las versiones que has probado de la aplicación. Nunca introduzcas el maxVersion de la aplicación que sea superior a la que está disponible ya que podrían introducirse cambios en su Interfaz de Programación (API) y en su Interfaz de Usuario. Con compatibility updating no hace falta publicar una versión nueva completa de la extensión, sólo habrá que aumentar su maxVersion.

Generalmente, en maxVersion se puede sustituir el número de versión secundario de la aplicación que se admite por *, por ejemplo: 2.0.0.* significaría que admite cualquier actualización secundaria de la versión 2 de la aplicación. Normalmente, la aplicación le sugerirá al autor de extensiones con qué parte de la versión conviene más hacer lo dicho.

No pienses que el * representa una versión por sí mismo. Realmente, el * representa un número inconmensurablemente alto, por lo que lo único sensato es usarlo en el maxVersion. Por lo general, usarlo en el minVersion no suele producir el efecto deseado.

Automatic Add-on Update Checking

Applications will periodically check for updates to installed add-ons by retrieving the updateURL. The information returned can be used to notify the user of an updated version to the add-on as well as inform the application of new application versions that the add-on is compatible with.

Compatibility Updates

During the automatic update checks, applications look for both new versions and updated compatibility information about the currently installed version of an add-on. This means that if your update manifest contains an entry for the currently installed version of the add-on, and the entry's targetApplication entry specifies a larger maxVersion then the application will use this value instead of that specified in the add-on's <tt>install.rdf</tt>. This can cause add-ons that are disabled for being incompatible to become enabled and add-ons that would normally not install to be installed.

Update RDF Format

If you host your add-on's updateURL yourself then you will need to return the add-on version information in an RDF format. Below is an example update manifests. It lists information about 2 different versions of the extension with id foobar@developer.mozilla.org. The versions included are 2.2 and 2.5, both of which specify compatibility with Firefox versions 1.5 to 2.0.0.*. For version 2.2 an https update link is used while version 2.5 has a regular http link with a hash to verify the file retrieved.

It is important to get the initial RDF:Description's about attribute correct. It varies depending on what type of add-on you are providing information for:

  • For an extension it must be urn:mozilla:extension:<id>
  • For a theme it must be urn:mozilla:theme:<id>
  • For any other type of add-on it must be urn:mozilla:item:<id>
<?xml version="1.0" encoding="UTF-8"?>

<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:em="http://www.mozilla.org/2004/em-rdf#">

  <!-- This Description resource includes all the update and compatibility information for
       a single add-on with the id foobar@developer.mozilla.org. You can list multiple
       add-ons information in the same RDF file. -->
  <RDF:Description about="urn:mozilla:extension:foobar@developer.mozilla.org">
    <em:updates>
      <RDF:Seq>

        <!-- Each li is a different version of the same add-on -->
        <RDF:li>
          <RDF:Description>
            <em:version>2.2</em:version> <!-- This is the version number of the add-on -->

            <!-- One targetApplication for each application the add-on is compatible with -->
            <em:targetApplication>
              <RDF:Description>
                <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
                <em:minVersion>1.5</em:minVersion>
                <em:maxVersion>2.0.0.*</em:maxVersion>

                <!-- This is where this version of the add-on will be downloaded from -->
                <em:updateLink>https://www.mysite.com/foobar2.2.xpi</em:updateLink>

                <!-- A page describing what is new in this updated version -->
                <em:updateInfoURL>http://www.mysite.com/updateinfo2.2.xhtml</em:updateInfoURL>
              </RDF:Description>
            </em:targetApplication>
          </RDF:Description>
        </RDF:li>

        <RDF:li>
          <RDF:Description>
            <em:version>2.5</em:version>
            <em:targetApplication>
              <RDF:Description>
                <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
                <em:minVersion>1.5</em:minVersion>
                <em:maxVersion>2.0.0.*</em:maxVersion>
                <em:updateLink>http://www.mysite.com/foobar2.5.xpi</em:updateLink>
                <um:updateHash>sha1:78fc1d2887eda35b4ad2e3a0b60120ca271ce6e6</em:updateHash>
              </RDF:Description>
            </em:targetApplication>
          </RDF:Description>
        </RDF:li>

      </RDF:Seq>
    </em:updates>

    <!-- A signature is only necessary if your add-on includes an updateKey
         in its install.rdf. -->
    <em:signature>MIGTMA0GCSqGSIb3DQEBBQUAA4GBAMO1O2gwSCCth1GwYMgscfaNakpN40PJfOWt
                  ub2HVdg8+OXMciF8d/9eVWm8eH/IxuxyZlmRZTs3O5tv9eWAY5uBCtqDf1WgTsGk
                  jrgZow1fITkZI7w0//C8eKdMLAtGueGfNs2IlTd5P/0KH/hf1rPc1wUqEqKCd4+L
                  BcVq13ad</em:signature>
  </RDF:Description>
</RDF:RDF>

Some people prefer this alternate format (note that much of the information has been trimmed from this example for brevity in order to show the basic structure):

<?xml version="1.0" encoding="UTF-8"?>

<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:em="http://www.mozilla.org/2004/em-rdf#">

  <!-- This Description resource includes all the update and compatibility information for
       a single add-on with the id foobar@developer.mozilla.org. You can list multiple
       add-ons information in the same RDF file. -->
  <RDF:Description about="urn:mozilla:extension:foobar@developer.mozilla.org">
    <em:updates>
      <RDF:Seq>
        <!-- The resource attribute points to an RDF:Description entry below with
             a matching about attribute. The actual uri can be whatever you like -->
        <RDF:li resource="urn:mozilla:extension:foobar@developer.mozilla.org:2.2"/>
        <RDF:li resource="urn:mozilla:extension:foobar@developer.mozilla.org:2.5"/>
      </RDF:Seq>
    </em:updates>
    <em:signature>MIGTMA0GCSqGSIb3DQEBBQUAA4GBAMO1O2gwSCCth1GwYMgscfaNakpN40PJfOWt
                  ub2HVdg8+OXMciF8d/9eVWm8eH/IxuxyZlmRZTs3O5tv9eWAY5uBCtqDf1WgTsGk
                  jrgZow1fITkZI7w0//C8eKdMLAtGueGfNs2IlTd5P/0KH/hf1rPc1wUqEqKCd4+L
                  BcVq13ad</em:signature>
  </RDF:Description>

  <!-- This represents the same Description within the li from the previous example -->
  <RDF:Description about="urn:mozilla:extension:foobar@developer.mozilla.org:2.2">
    <em:version>2.2</em:version>

    <!-- Trimmed the rest of the contents here -->

  </RDF:Description>

  <RDF:Description about="urn:mozilla:extension:foobar@developer.mozilla.org:2.5">
    <em:version>2.5</em:version>

    <!-- Trimmed the rest of the contents here -->

  </RDF:Description>

</RDF:RDF>

Providing Details about Updates

{{template.Fx_minversion_header(3)}}

It is possible to provide the user some details about what is new in an updated version of your add-on. This is visible when the user gets an add-on update notification and should be used to give a quick overview of what new features have been added and any security issues that have been resolved.

In order to do this you must add an updateInfoURL entry to the update manifest (see the example below). The page at this URL will be retrieved and displayed to the user. Since it is being displayed outside of a normal webpage context it is heavily sanitized, which means there are very few formatting options available and scripting and images aren't allowed. As a general rule, you may only use the following tags (any others are ignored):

  • h1, h2 and h3 for general headings
  • p for paragraphs
  • ul and ol for lists.

Within lists use the usual li tag for each list item.

Within h1, h2, h3, p and li tags you may use:

  • b or strong for bolder text
  • i or em for italicised text

The information page retrieved must currently be totally valid XHTML, including being delivered with the MIME type application/xhtml+xml.

Securing Updates

{{template.Gecko_minversion_header(1.9)}} {{template.Fx_minversion_header(3)}}

Gecko 1.9 has added additional requirements designed to protect users from man-in-the-middle attacks and the like during add-on updates. In the install.rdf of the already installed add-on updateURL must be specified in one of the following ways:

  • The updateURL uses https, or there is no updateURL at all (which defaults to <tt>addons.mozilla.org</tt> which is https)
  • The updateURL uses http and the updateKey entry is specified which will be used to verify the data in the update manifest.

When you specify an updateKey in the <tt>install.rdf</tt>, you must include a digital signature in the update manifest or the information will be rejected.

In the update manifest delivered from the updateURL the updateLink must be specified in one of the following ways:

  • The updateLink to the XPI file must use https
  • The updateLink can use http and you must include an updateHash for the XPI file using sha1, sha256, sha384 or sha512 hash algorithms.

Any entries in the update manifest that do not meet one of those two requirements will be ignored when checking for new versions.

Note that https links to sites with invalid certificates or that redirect to http sites will fail for both the <tt>update.rdf</tt> and updateLink cases.

Update Hashes

In order to verify the integrity of the downloaded XPI you may provide an updateHash entry alongside the updateLink. This should be a hash generated against the file data in string form. The hashing algorithm used is put at the start of the string and separated from the hash by a :.

  <em:updateHash>sha1:78fc1d2887eda35b4ad2e3a0b60120ca271ce6e6</em:updateHash>

When a hash is specified the downloaded file is compared with the hash and an error shown if it does not match.

Signing Update Manifests

{{template.Gecko_minversion_header(1.9)}} {{template.Fx_minversion_header(3)}}

If you wish to serve your update RDF over regular http, Gecko 1.9 based applications will require that you digitally sign the update manifest to ensure that it's information isn't tampered with between you creating it and applications retrieving it. The McCoy tool should be used to sign the update RDF.

The technical details of the signing mechanism are beyond the scope of this document however the basics are as follows:

The add-on author creates a public/private RSA cryptographic key pair.

The public part of the key is DER encoded and then base 64 encoded and added to the add-on's <tt>install.rdf</tt> as an updateKey entry.

When the author creates the update rdf file a tool is used to sign it using the private part of the key. Roughly speaking the update information is converted to a string, then hashed using a sha512 hashing algorithm and this hash is signed using the private key. The resultant data is DER encoded then base 64 encoded for inclusion in the update rdf as an em:signature entry.


{{ wiki.languages( { "en": "en/Extension_Versioning,_Update_and_Compatibility", "fr": "fr/Versions_d\'une_extension,_mise_\u00e0_jour_et_compatibilit\u00e9", "ja": "ja/Extension_Versioning,_Update_and_Compatibility" } ) }}

Fuente de la revisión

<p>
</p><p>{{wiki.template('Traducción', [ "inglés", "Extension_Versioning%2C_Update_and_Compatibility", "en" ])}}
</p><p><br>
</p>
<h2 name="Versionado_de_extensiones">Versionado de extensiones</h2>
<p>Las extensiones deberán especificar su versión utilizando el <a href="es/Toolkit_version_format">Toolkit version format</a>. Aquí puedes ver algunos ejemplos de versiones separadas por puntos:
</p>
<ul><li> 2.0
</li><li> 1.0b1
</li><li> 3.0pre1
</li><li> 5.0.1.2
</li></ul>
<div class="note"><b>Nota:</b> Antes de la versión 1.5 de Firefox se utilizaba un formato Firefox de versiones más básico que sólo permitía dígitos: número_de_versión_principal.número_de_versión_secundario.publicación.compilación{{mediawiki.external('+')}}. El toolkit version format (formato de versiones de herramientas), aunque es más flexible, sigue siendo compatible con el formato Firefox de versiones.</div>
<h2 name="Sobre_c.C3.B3mo_las_aplicaciones_determinan_la_compatibilidad">Sobre cómo las aplicaciones determinan la compatibilidad</h2>
<p>Al instalar extensiones comprueba las entradas <code><a href="es/Install.rdf#targetApplication">targetApplication</a></code> en el <tt>install.rdf</tt> de la extensión. Debe haber una entrada con una ID que coincida con la ID de la aplicación. Además, el número de versión de la aplicación debe encontrarse dentro del rango definido por <code>minVersion</code> y <code>maxVersion</code>.
</p><p>Si la aplicación tiene una entrada <code>targetApplication</code>, pero se debe a una versión incompatible, la aplicación obtendrá información actualizada sobre su compatibilidad de la <code><a href="es/Install.rdf#updateURL">updateURL</a></code> de la extensión.
</p><p>Si el install.rdf tiene alguna entrada <code><a href="es/Install.rdf#targetPlatform">targetPlatform</a></code>, deberás escribir un informe sobre la aplicación o cancelar su instalación.
</p><p>{{template.Fx_minversion_inline(3)}} En las aplicaciones basadas en Gecko 1.9 también puedes usar una entrada <code>targetApplication</code> con una ID <code>toolkit@mozilla.org</code>; <code>minVersion</code>, y <code>maxVersion</code> que coincidan con la versión de la aplicación. Esto te permitirá garantizar que tu extensión se puede instalar en cualquier aplicación (toolkit based).
</p>
<h3 name="Cancelaci.C3.B3n_del_control_de_compatibilidad">Cancelación del control de compatibilidad </h3>
<p>{{template.Fx_minversion_inline(1.5)}} Para la evaluación de extensiones puedes hacer que la aplicación ignore los controles de compatibilidad durante su instalación. Lo único que tienes que hacer es crear la preferencia <code>extensions.checkCompatibility</code> y darle valor False.
</p>
<div class="note"><b>Nota:</b> Antes de la versión 1.5 de Firefox, se podía utilizar la preferencia <code>app.extensions.version</code> para que la aplicación ignorase su versión e instalar así extensiones de otra forma incompatibles.</div>
<h2 name="Elecci.C3.B3n_de_minVersion_y_maxVersion">Elección de minVersion y maxVersion</h2>
<p><code>minVersion</code> y <code>maxVersion</code> deberían especificar las versiones que has probado de la aplicación. Nunca introduzcas el <code>maxVersion</code> de la aplicación que sea superior a la que está disponible ya que podrían introducirse cambios en su Interfaz de Programación (API) y en su Interfaz de Usuario. Con <a href="#Compatibility_Updates">compatibility updating</a> no hace falta publicar una versión nueva completa de la extensión, sólo habrá que aumentar su <code>maxVersion</code>.
</p><p>Generalmente, en <code>maxVersion</code> se puede sustituir el número de versión secundario de la aplicación que se admite por *, por ejemplo: 2.0.0.* significaría que admite cualquier actualización secundaria de la versión 2 de la aplicación. Normalmente, la aplicación le sugerirá al autor de extensiones con qué parte de la versión conviene más hacer lo dicho.
</p><p>No pienses que el * representa una versión por sí mismo. Realmente, el * representa un número inconmensurablemente alto, por lo que lo único sensato es usarlo en el <code>maxVersion</code>. Por lo general, usarlo en el <code>minVersion</code> no suele producir el efecto deseado.
</p>
<h2 name="Automatic_Add-on_Update_Checking">Automatic Add-on Update Checking</h2>
<p>Applications will periodically check for updates to installed add-ons by retrieving the <code><a href="es/Install.rdf#updateURL">updateURL</a></code>. The information returned can be used to notify the user of an updated version to the add-on as well as inform the application of new application versions that the add-on is compatible with.
</p>
<h3 name="Compatibility_Updates">Compatibility Updates</h3>
<p>During the automatic update checks, applications look for both new versions and updated compatibility information about the currently installed version of an add-on. This means that if your update manifest contains an entry for the currently installed version of the add-on, and the entry's <code>targetApplication</code> entry specifies a larger maxVersion then the application will use this value instead of that specified in the add-on's <tt>install.rdf</tt>. This can cause add-ons that are disabled for being incompatible to become enabled and add-ons that would normally not install to be installed.
</p>
<h3 name="Update_RDF_Format">Update RDF Format</h3>
<p>If you host your add-on's <code>updateURL</code> yourself then you will need to return the add-on version information in an RDF format. Below is an example update manifests. It lists information about 2 different versions of the extension with id <code>foobar@developer.mozilla.org</code>. The versions included are 2.2 and 2.5, both of which specify compatibility with Firefox versions 1.5 to 2.0.0.*. For version 2.2 an https update link is used while version 2.5 has a regular http link with a hash to verify the file retrieved.
</p><p>It is important to get the initial RDF:Description's about attribute correct. It varies depending on what type of add-on you are providing information for:
</p>
<ul><li> For an extension it must be <code>urn:mozilla:extension:&lt;id&gt;</code>
</li><li> For a theme it must be <code>urn:mozilla:theme:&lt;id&gt;</code>
</li><li> For any other type of add-on it must be <code>urn:mozilla:item:&lt;id&gt;</code>
</li></ul>
<pre>&lt;?xml version="1.0" encoding="UTF-8"?&gt;

&lt;RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:em="http://www.mozilla.org/2004/em-rdf#"&gt;

  &lt;!-- This Description resource includes all the update and compatibility information for
       a single add-on with the id foobar@developer.mozilla.org. You can list multiple
       add-ons information in the same RDF file. --&gt;
  &lt;RDF:Description about="urn:mozilla:extension:foobar@developer.mozilla.org"&gt;
    &lt;em:updates&gt;
      &lt;RDF:Seq&gt;

        &lt;!-- Each li is a different version of the same add-on --&gt;
        &lt;RDF:li&gt;
          &lt;RDF:Description&gt;
            &lt;em:version&gt;2.2&lt;/em:version&gt; &lt;!-- This is the version number of the add-on --&gt;

            &lt;!-- One targetApplication for each application the add-on is compatible with --&gt;
            &lt;em:targetApplication&gt;
              &lt;RDF:Description&gt;
                &lt;em:id&gt;{ec8030f7-c20a-464f-9b0e-13a3a9e97384}&lt;/em:id&gt;
                &lt;em:minVersion&gt;1.5&lt;/em:minVersion&gt;
                &lt;em:maxVersion&gt;2.0.0.*&lt;/em:maxVersion&gt;

                &lt;!-- This is where this version of the add-on will be downloaded from --&gt;
                &lt;em:updateLink&gt;https://www.mysite.com/foobar2.2.xpi&lt;/em:updateLink&gt;

                &lt;!-- A page describing what is new in this updated version --&gt;
                &lt;em:updateInfoURL&gt;http://www.mysite.com/updateinfo2.2.xhtml&lt;/em:updateInfoURL&gt;
              &lt;/RDF:Description&gt;
            &lt;/em:targetApplication&gt;
          &lt;/RDF:Description&gt;
        &lt;/RDF:li&gt;

        &lt;RDF:li&gt;
          &lt;RDF:Description&gt;
            &lt;em:version&gt;2.5&lt;/em:version&gt;
            &lt;em:targetApplication&gt;
              &lt;RDF:Description&gt;
                &lt;em:id&gt;{ec8030f7-c20a-464f-9b0e-13a3a9e97384}&lt;/em:id&gt;
                &lt;em:minVersion&gt;1.5&lt;/em:minVersion&gt;
                &lt;em:maxVersion&gt;2.0.0.*&lt;/em:maxVersion&gt;
                &lt;em:updateLink&gt;http://www.mysite.com/foobar2.5.xpi&lt;/em:updateLink&gt;
                &lt;um:updateHash&gt;sha1:78fc1d2887eda35b4ad2e3a0b60120ca271ce6e6&lt;/em:updateHash&gt;
              &lt;/RDF:Description&gt;
            &lt;/em:targetApplication&gt;
          &lt;/RDF:Description&gt;
        &lt;/RDF:li&gt;

      &lt;/RDF:Seq&gt;
    &lt;/em:updates&gt;

    &lt;!-- A signature is only necessary if your add-on includes an updateKey
         in its install.rdf. --&gt;
    &lt;em:signature&gt;MIGTMA0GCSqGSIb3DQEBBQUAA4GBAMO1O2gwSCCth1GwYMgscfaNakpN40PJfOWt
                  ub2HVdg8+OXMciF8d/9eVWm8eH/IxuxyZlmRZTs3O5tv9eWAY5uBCtqDf1WgTsGk
                  jrgZow1fITkZI7w0//C8eKdMLAtGueGfNs2IlTd5P/0KH/hf1rPc1wUqEqKCd4+L
                  BcVq13ad&lt;/em:signature&gt;
  &lt;/RDF:Description&gt;
&lt;/RDF:RDF&gt;
</pre>
<p>Some people prefer this alternate format (note that much of the information has been trimmed from this example for brevity in order to show the basic structure):
</p>
<pre>&lt;?xml version="1.0" encoding="UTF-8"?&gt;

&lt;RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:em="http://www.mozilla.org/2004/em-rdf#"&gt;

  &lt;!-- This Description resource includes all the update and compatibility information for
       a single add-on with the id foobar@developer.mozilla.org. You can list multiple
       add-ons information in the same RDF file. --&gt;
  &lt;RDF:Description about="urn:mozilla:extension:foobar@developer.mozilla.org"&gt;
    &lt;em:updates&gt;
      &lt;RDF:Seq&gt;
        &lt;!-- The resource attribute points to an RDF:Description entry below with
             a matching about attribute. The actual uri can be whatever you like --&gt;
        &lt;RDF:li resource="urn:mozilla:extension:foobar@developer.mozilla.org:2.2"/&gt;
        &lt;RDF:li resource="urn:mozilla:extension:foobar@developer.mozilla.org:2.5"/&gt;
      &lt;/RDF:Seq&gt;
    &lt;/em:updates&gt;
    &lt;em:signature&gt;MIGTMA0GCSqGSIb3DQEBBQUAA4GBAMO1O2gwSCCth1GwYMgscfaNakpN40PJfOWt
                  ub2HVdg8+OXMciF8d/9eVWm8eH/IxuxyZlmRZTs3O5tv9eWAY5uBCtqDf1WgTsGk
                  jrgZow1fITkZI7w0//C8eKdMLAtGueGfNs2IlTd5P/0KH/hf1rPc1wUqEqKCd4+L
                  BcVq13ad&lt;/em:signature&gt;
  &lt;/RDF:Description&gt;

  &lt;!-- This represents the same Description within the li from the previous example --&gt;
  &lt;RDF:Description about="urn:mozilla:extension:foobar@developer.mozilla.org:2.2"&gt;
    &lt;em:version&gt;2.2&lt;/em:version&gt;

    &lt;!-- Trimmed the rest of the contents here --&gt;

  &lt;/RDF:Description&gt;

  &lt;RDF:Description about="urn:mozilla:extension:foobar@developer.mozilla.org:2.5"&gt;
    &lt;em:version&gt;2.5&lt;/em:version&gt;

    &lt;!-- Trimmed the rest of the contents here --&gt;

  &lt;/RDF:Description&gt;

&lt;/RDF:RDF&gt;
</pre>
<h3 name="Providing_Details_about_Updates">Providing Details about Updates</h3>
<p>{{template.Fx_minversion_header(3)}}
</p><p>It is possible to provide the user some details about what is new in an updated version of your add-on. This is visible when the user gets an add-on update notification and should be used to give a quick overview of what new features have been added and any security issues that have been resolved.
</p><p>In order to do this you must add an <code>updateInfoURL</code> entry to the update manifest (see the example below). The page at this URL will be retrieved and displayed to the user. Since it is being displayed outside of a normal webpage context it is heavily sanitized, which means there are very few formatting options available and scripting and images aren't allowed. As a general rule, you may only use the following tags (any others are ignored):
</p>
<ul><li> h1, h2 and h3 for general headings
</li><li> p for paragraphs
</li><li> ul and ol for lists.
</li></ul>
<p>Within lists use the usual <code>li</code> tag for each list item.
</p><p>Within h1, h2, h3, p and li tags you may use:
</p>
<ul><li> b or strong for bolder text
</li><li> i or em for italicised text
</li></ul>
<p>The information page retrieved must currently be totally valid XHTML, including being delivered with the MIME type <code>application/xhtml+xml</code>.
</p>
<h3 name="Securing_Updates">Securing Updates</h3>
<p>{{template.Gecko_minversion_header(1.9)}}
{{template.Fx_minversion_header(3)}}
</p><p>Gecko 1.9 has added additional requirements designed to protect users from <a class="external" href="http://en.wikipedia.org/wiki/Man-in-the-middle_attack">man-in-the-middle attacks</a> and the like during add-on updates. In the install.rdf of the already installed add-on <code>updateURL</code> must be specified in one of the following ways:
</p>
<ul><li> The <code><a href="es/Install.rdf#updateURL">updateURL</a></code> uses https, or there is no <code>updateURL</code> at all (which defaults to <tt>addons.mozilla.org</tt> which is https)
</li><li> The <code><a href="es/Install.rdf#updateURL">updateURL</a></code> uses http and the <code><a href="es/Install.rdf#updateKey">updateKey</a></code> entry is specified which will be used to verify the data in the update manifest.
</li></ul>
<p>When you specify an <code>updateKey</code> in the <tt>install.rdf</tt>, you must include a <a href="#Signing_Update_Manifests">digital signature</a> in the update manifest or the information will be rejected.
</p><p>In the update manifest delivered from the <code>updateURL</code> the <code>updateLink</code> must be specified in one of the following ways:
</p>
<ul><li> The <code>updateLink</code> to the XPI file must use https
</li><li> The <code>updateLink</code> can use http and you must include an <code><a href="#Update_Hashes">updateHash</a></code> for the XPI file using sha1, sha256, sha384 or sha512 hash algorithms.
</li></ul>
<p>Any entries in the update manifest that do not meet one of those two requirements will be ignored when checking for new versions.
</p><p>Note that https links to sites with invalid certificates or that redirect to http sites will fail for both the <tt>update.rdf</tt> and <code>updateLink</code> cases.
</p>
<h4 name="Update_Hashes">Update Hashes</h4>
<p>In order to verify the integrity of the downloaded XPI you may provide an <code>updateHash</code> entry alongside the updateLink. This should be a hash generated against the file data in string form. The hashing algorithm used is put at the start of the string and separated from the hash by a <code>:</code>.
</p>
<pre>  &lt;em:updateHash&gt;sha1:78fc1d2887eda35b4ad2e3a0b60120ca271ce6e6&lt;/em:updateHash&gt;
</pre>
<p>When a hash is specified the downloaded file is compared with the hash and an error shown if it does not match.
</p>
<h4 name="Signing_Update_Manifests">Signing Update Manifests</h4>
<p>{{template.Gecko_minversion_header(1.9)}}
{{template.Fx_minversion_header(3)}}
</p><p>If you wish to serve your update RDF over regular http, Gecko 1.9 based applications will require that you digitally sign the update manifest to ensure that it's information isn't tampered with between you creating it and applications retrieving it. The <a href="es/McCoy">McCoy</a> tool should be used to sign the update RDF.
</p><p>The technical details of the signing mechanism are beyond the scope of this document however the basics are as follows:
</p><p>The add-on author creates a public/private RSA cryptographic key pair.
</p><p>The public part of the key is DER encoded and then base 64 encoded and added to the add-on's <tt>install.rdf</tt> as an <code><a href="es/Install.rdf#updateKey">updateKey</a></code> entry.
</p><p>When the author creates the update rdf file a tool is used to sign it using the private part of the key. Roughly speaking the update information is converted to a string, then hashed using a sha512 hashing algorithm and this hash is signed using the private key. The resultant data is DER encoded then base 64 encoded for inclusion in the update rdf as an <code>em:signature</code> entry.
</p><p><br>
</p>
<div class="noinclude">
</div>
{{ wiki.languages( { "en": "en/Extension_Versioning,_Update_and_Compatibility", "fr": "fr/Versions_d\'une_extension,_mise_\u00e0_jour_et_compatibilit\u00e9", "ja": "ja/Extension_Versioning,_Update_and_Compatibility" } ) }}
Revertir a esta revisión