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: 275135
  • Creada:
  • Creador: RickieesES
  • ¿Es la revisión actual? No
  • Comentario Revisión ortográfica y gramatical de Cómo determinan la compatibilidad las aplicaciones

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 formato de versión de Toolkit. 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 formato de versión de Toolkit, aunque es más flexible, sigue siendo compatible con el formato Firefox de versiones.

Cómo determinan la compatibilidad las aplicaciones

Al instalar extensiones las aplicaciones comprueban 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 es para 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, entonces la plataforma de la aplicación que se está ejecutando debe aparecer listada en ellas, o se 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 basada en Toolkit.

Cancelar el 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 un 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.

Comprobación automática de actualización de extensiones

Periódicamente, las aplicaciones buscarán actualizaciones de las extensiones instaladas recuperando el updateURL. La información recuperada puede servir para notificar al usuario de la existencia de una actualización de la extensión e informar a la aplicación de las nuevas versiones con las que la extensión es compatible.

Actualizaciones de compatibilidad

Durante la comprobación automática de actualizaciones, las aplicaciones buscarán versiones nuevas e información actualizada sobre la compatibilidad de la versión instalada de una extensión. Esto quiere decir que si el manifiesto de tu actualización incluye una entrada para la versión de la extensión instalada, y el targetApplication de la entrada especifica un maxVersion mayor la aplicación utilizará este valor en lugar del especificado en el <tt>install.rdf</tt> de la extensión. Esto puede hacer que se activen extensiones que estaban desactivadas por ser incompatibles y que se instalen aquellas que normalmente no se instalarían.

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/Formato_de_versi%c3%b3n_de_Toolkit">formato de versión de Toolkit</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 formato de versión de Toolkit, aunque es más flexible, sigue siendo compatible con el formato Firefox de versiones.</div>
<h2 name="C.C3.B3mo_determinan_la_compatibilidad_las_aplicaciones">Cómo determinan la compatibilidad las aplicaciones</h2>
<p>Al instalar extensiones las aplicaciones comprueban 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 es para 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>, entonces la plataforma de la aplicación que se está ejecutando debe aparecer listada en ellas, o se 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 basada en Toolkit.
</p>
<h3 name="Cancelar_el_control_de_compatibilidad">Cancelar el 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 un <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="Comprobaci.C3.B3n_autom.C3.A1tica_de_actualizaci.C3.B3n_de_extensiones">Comprobación automática de actualización de extensiones</h2>
<p>Periódicamente, las aplicaciones buscarán actualizaciones de las extensiones instaladas recuperando el <code><a href="es/Install.rdf#updateURL">updateURL</a></code>. La información recuperada puede servir para notificar al usuario de la existencia de una actualización de la extensión e informar a la aplicación de las nuevas versiones con las que la extensión es compatible.
</p>
<h3 name="Actualizaciones_de_compatibilidad">Actualizaciones de compatibilidad </h3>
<p>Durante la comprobación automática de actualizaciones, las aplicaciones buscarán versiones nuevas e información actualizada sobre la compatibilidad de la versión instalada de una extensión. Esto quiere decir que si el manifiesto de tu actualización incluye una entrada para la versión de la extensión instalada, y el <code>targetApplication</code> de la entrada especifica un maxVersion mayor la aplicación utilizará este valor en lugar del especificado en el <tt>install.rdf</tt> de la extensión. Esto puede hacer que se activen extensiones que estaban desactivadas por ser incompatibles y que se instalen aquellas que normalmente no se instalarían.
</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