Revision 171390 of Extension Versioning, Update and Compatibility

  • 리비전 슬러그: Extension_Versioning,_Update_and_Compatibility
  • 리비전 제목: Extension Versioning, Update and Compatibility
  • 리비전 아이디: 171390
  • 제작일시:
  • 만든이: Jeongkyu
  • 현재 리비전인가요? 아니오
  • 댓글 /* Securing Updates */
태그: 

리비전 내용

Add-on Versioning

Add-ons should specify their versions using the Toolkit version format. As a rough overview this is a version string split by periods, some examples:

  • 2.0
  • 1.0b1
  • 3.0pre1
  • 5.0.1.2
Note: Before Firefox 1.5 the more basic Firefox Version Format was used: major.minor.release.build{{mediawiki.external('+')}} where only digits were allowed. The toolkit version format supports the Firefox version format but allows greater flexibility.

How Applications Determine Compatibility

When installing add-ons applications look at the targetApplication entries in the add-on's <tt>install.rdf</tt>. An entry must exist with an ID matching the ID of the application. Additionally the minVersion and maxVersion of this entry must be a range that includes the version of the running application.

If the application has a targetApplication entry but it is for an incompatible version then the application will retrieve updated compatibility information from the add-on's updateURL.

If the install.rdf contains any targetPlatform entries then the platform of the currently running application must be listed or the installation will be rejected.

{{template.Fx_minversion_inline(3)}} In applications based on Gecko 1.9 you can also use a targetApplication entry with an id toolkit@mozilla.org and minVersion and maxVersion that match the toolkit version of the running application. This allows you to say that your add-on will install into any toolkit based application.

Overriding Compatibility Checking

{{template.Fx_minversion_inline(1.5)}} For testing purposes you can tell the application to somewhat ignore compatibility checks when installing add-ons. Simply create the boolean preference extensions.checkCompatibility and set it to false.

Note: Before Firefox 1.5 the preference app.extensions.version could be used to override the version that the application believed itself to be to allow normally incompatible extensions to install.

Choosing minVersion and maxVersion

minVersion and maxVersion should specify the range of versions of the application you have tested with. In particular you should never specify a maxVersion that is larger than the currently available version of the application since you do not know what API and UI changes are just around the corner. With compatibility updating it is not necessary to release a whole new version of the extension just to increase its maxVersion.

For the maxVersion it is generally permissible to use a * in place of the minor version of the application you support, for example 2.0.0.* would mean that you support any minor update to version 2 of the application. The application will usually suggest to extension authors which version part it is sensible to do this with.

Do not mistakenly think that * in a version represents any version. The * actually represents an infinitely high number and so is really only sensibly used in the maxVersion. Using it in a minVersion usually doesn't produce the effect you want.

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>

In either of the examples below, the sequence of the versions within the <RDF:Seq> element is significant, with the later versions needing to be presented after earlier versions. One does not need to list all versions if the latest version is being provided (?).

<?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>
                <em: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 above). 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 italicized text

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

You may include %APP_LOCALE% in your updateInfoURL if you want to have locale information included in the URL -- this allows you to customize the text based on the user's locale. You may also use the other substitution strings supported by updateURL, although those may be less useful.

Securing Updates

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

Gecko 1.9는 부가 기능 업데이트와 같은 경우에 사용자를 man-in-the-middle attacks에서 보호하기 위해 설계된 부가적인 요구 사항을 추가했습니다. 이미 설치된 부가 기능의 install.rdf에서 updateURL을 다음 방법 중 한 가지로 지정해야 합니다.

  • updateURL이 https를 사용하거나 updateURL이 전혀 없습니다 (which defaults to <tt>addons.mozilla.org</tt> which is https).
  • updateURL이 http를 사용하고 업데이트 선언에 있는 데이터를 확인하는데 사용할 updateKey 항목을 지정합니다.

<tt>install.rdf</tt>에서 updateKey를 지정할 때는 업데이트 선언에 digital signature를 포함해야 하며 그렇지 않으면 정보가 거부됩니다.

updateURL에서 전달된 업데이트 선언에서는 updateLink를 다음 방법 중 한 가지로 지정해야 합니다.

  • XPI 파일을 가리키는 updateLink는 꼭 https를 사용해야 합니다.
  • updateLink가 http를 사용할 수 있으며, sha1, sha256, sha384, sha512 중 하나의 알고리즘을 이용하여 XPI 파일에 대한 updateHash를 포함해야 합니다.

업데이트 선언에서 위의 두 가지 요구 사항 중 하나를 만족하지 못하는 모든 항목은 새로운 버전을 확인할 때 무시됩니다.

잘못된 인증서를 가진 사이트로 가는 https 링크나 http 사이트로 리디렉트하는 것은 <tt>update.rdf</tt>와 updateLink의 두 가지 경우에 모두 실패합니다.

업데이트 해시

다운로드한 XPI의 무결성을 확인하기 위하여 updateLink와 함께 updateHash 항목을 제공해야 합니다. 이 해시는 파일 데이터에 대하여 문자열 형식으로 생성해야 합니다. 문자열의 시작에 사용한 해시 알고리즘을 넣고 :으로 해시와 구별합니다.

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

해시가 지정되면 다운로드한 파일을 해시와 비교하고 일치하지 않으면 오류를 표시합니다.

업데이트 선언 서명하기

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

업데이트 RDF를 일반 http로 제공하기를 원한다면, Gecko 1.9 기반의 애플리케이션에서는 업데이트 선언을 서명해야 합니다. 이는 해당 정보를 생성한 여러분과 그것을 추출하는 애플리케이션 사이에서 간섭이 없었다는 것을 확인하기 위한 것입니다. 업데이트 RDF를 서명하는 데에는 McCoy 도구를 사용해야 합니다.

서명 방식에 대한 기술적인 세부 사항은 이 문서의 범위를 벗어나지만 기본적인 사항은 다음과 같습니다.

부가 기능 작성자가 공개/개인 RSA 암호 키 쌍을 생성합니다.

공개키는 DER로 인코드된 후에 base 64로 인코드되어 부가 기능의 <tt>install.rdf</tt>에 updateKey 항목으로 추가됩니다.

작성자가 업데이트 RDF 파일을 생성할 때 도구를 사용하여 개인키로 서명합니다. 대략적으로 이야기하면, 업데이트 정보는 문자열로 변환되어 sha512 해시 알고리즘으로 해시되고 개인키로 이 해시를 서명합니다. 결과 데이터는 DER로 인코드하고 base 64로 인코드한 후 업데이트 RDF에 em:signature 항목으로 포함합니다.



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

리비전 소스

<p>
</p>
<h2 name="Add-on_Versioning">Add-on Versioning</h2>
<p>Add-ons should specify their versions using the <a href="ko/Toolkit_version_format">Toolkit version format</a>. As a rough overview this is a version string split by periods, some examples:
</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>Note:</b> Before Firefox 1.5 the more basic Firefox Version Format was used: major.minor.release.build{{mediawiki.external('+')}} where only digits were allowed. The toolkit version format supports the Firefox version format but allows greater flexibility.</div>
<h2 name="How_Applications_Determine_Compatibility">How Applications Determine Compatibility</h2>
<p>When installing add-ons applications look at the <code><a href="ko/Install.rdf#targetApplication">targetApplication</a></code> entries in the add-on's <tt>install.rdf</tt>. An entry must exist with an ID matching the ID of the application. Additionally the <code>minVersion</code> and <code>maxVersion</code> of this entry must be a range that includes the version of the running application.
</p><p>If the application has a <code>targetApplication</code> entry but it is for an incompatible version then the application will retrieve updated compatibility information from the add-on's <code><a href="ko/Install.rdf#updateURL">updateURL</a></code>.
</p><p>If the install.rdf contains any <code><a href="ko/Install.rdf#targetPlatform">targetPlatform</a></code> entries then the platform of the currently running application must be listed or the installation will be rejected.
</p><p>{{template.Fx_minversion_inline(3)}} In applications based on Gecko 1.9 you can also use a <code>targetApplication</code> entry with an id <code>toolkit@mozilla.org</code> and <code>minVersion</code> and <code>maxVersion</code> that match the toolkit version of the running application. This allows you to say that your add-on will install into any toolkit based application.
</p>
<h3 name="Overriding_Compatibility_Checking">Overriding Compatibility Checking</h3>
<p>{{template.Fx_minversion_inline(1.5)}} For testing purposes you can tell the application to somewhat ignore compatibility checks when installing add-ons. Simply create the boolean preference <code>extensions.checkCompatibility</code> and set it to false.
</p>
<div class="note"><b>Note:</b> Before Firefox 1.5 the preference <code>app.extensions.version</code> could be used to override the version that the application believed itself to be to allow normally incompatible extensions to install.</div>
<h2 name="Choosing_minVersion_and_maxVersion">Choosing minVersion and maxVersion</h2>
<p><code>minVersion</code> and <code>maxVersion</code> should specify the range of versions of the application you have tested with. In particular you should never specify a <code>maxVersion</code> that is larger than the currently available version of the application since you do not know what API and UI changes are just around the corner. With <a href="#Compatibility_Updates">compatibility updating</a> it is not necessary to release a whole new version of the extension just to increase its <code>maxVersion</code>.
</p><p>For the <code>maxVersion</code> it is generally permissible to use a * in place of the minor version of the application you support, for example 2.0.0.* would mean that you support any minor update to version 2 of the application. The application will usually suggest to extension authors which version part it is sensible to do this with.
</p><p>Do not mistakenly think that * in a version represents any version. The * actually represents an infinitely high number and so is really only sensibly used in the <code>maxVersion</code>. Using it in a <code>minVersion</code> usually doesn't produce the effect you want.
</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="ko/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>
<p>In either of the examples below, the sequence of the versions within the &lt;RDF:Seq&gt; element is significant, with the later versions needing to be presented after earlier versions. One does not need to list all versions if the latest version is being provided (?).
</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;!-- 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;em: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 above). 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 italicized 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><p>You may include <code>%APP_LOCALE%</code> in your <code>updateInfoURL</code> if you want to have locale information included in the URL -- this allows you to customize the text based on the user's locale.  You may also use the other substitution strings supported by <code>updateURL</code>, although those may be less useful.
</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는 부가 기능 업데이트와 같은 경우에 사용자를 <a class="external" href="http://en.wikipedia.org/wiki/Man-in-the-middle_attack">man-in-the-middle attacks</a>에서 보호하기 위해 설계된 부가적인 요구 사항을 추가했습니다. 이미 설치된 부가 기능의 install.rdf에서 <code>updateURL</code>을 다음 방법 중 한 가지로 지정해야 합니다.
</p>
<ul><li> <code><a href="ko/Install.rdf#updateURL">updateURL</a></code>이 https를 사용하거나 <code>updateURL</code>이 전혀 없습니다 (which defaults to <tt>addons.mozilla.org</tt> which is https).
</li><li> <code><a href="ko/Install.rdf#updateURL">updateURL</a></code>이 http를 사용하고 업데이트 선언에 있는 데이터를 확인하는데 사용할 <code><a href="ko/Install.rdf#updateKey">updateKey</a></code> 항목을 지정합니다.
</li></ul>
<p><tt>install.rdf</tt>에서 <code>updateKey</code>를 지정할 때는 업데이트 선언에 <a href="#Signing_Update_Manifests">digital signature</a>를 포함해야 하며 그렇지 않으면 정보가 거부됩니다.
</p><p><code>updateURL</code>에서 전달된 업데이트 선언에서는 <code>updateLink</code>를 다음 방법 중 한 가지로 지정해야 합니다.
</p>
<ul><li> XPI 파일을 가리키는 <code>updateLink</code>는 꼭 https를 사용해야 합니다.
</li><li> <code>updateLink</code>가 http를 사용할 수 있으며, sha1, sha256, sha384, sha512 중 하나의 알고리즘을 이용하여 XPI 파일에 대한 <code><a href="#Update_Hashes">updateHash</a></code>를 포함해야 합니다.
</li></ul>
<p>업데이트 선언에서 위의 두 가지 요구 사항 중 하나를 만족하지 못하는 모든 항목은 새로운 버전을 확인할 때 무시됩니다.
</p><p>잘못된 인증서를 가진 사이트로 가는 https 링크나 http 사이트로 리디렉트하는 것은 <tt>update.rdf</tt>와 <code>updateLink</code>의 두 가지 경우에 모두 실패합니다.
</p>
<h4 name=".EC.97.85.EB.8D.B0.EC.9D.B4.ED.8A.B8_.ED.95.B4.EC.8B.9C">업데이트 해시</h4>
<p>다운로드한 XPI의 무결성을 확인하기 위하여 updateLink와 함께 <code>updateHash</code> 항목을 제공해야 합니다. 이 해시는 파일 데이터에 대하여 문자열 형식으로 생성해야 합니다. 문자열의 시작에 사용한 해시 알고리즘을 넣고 <code>:</code>으로 해시와 구별합니다.
</p>
<pre>  &lt;em:updateHash&gt;sha1:78fc1d2887eda35b4ad2e3a0b60120ca271ce6e6&lt;/em:updateHash&gt;
</pre>
<p>해시가 지정되면 다운로드한 파일을 해시와 비교하고 일치하지 않으면 오류를 표시합니다.
</p>
<h4 name=".EC.97.85.EB.8D.B0.EC.9D.B4.ED.8A.B8_.EC.84.A0.EC.96.B8_.EC.84.9C.EB.AA.85.ED.95.98.EA.B8.B0">업데이트 선언 서명하기</h4>
<p>{{template.Gecko_minversion_header(1.9)}}
{{template.Fx_minversion_header(3)}}
</p><p>업데이트 RDF를 일반 http로 제공하기를 원한다면, Gecko 1.9 기반의 애플리케이션에서는 업데이트 선언을 서명해야 합니다. 이는 해당 정보를 생성한 여러분과 그것을 추출하는 애플리케이션 사이에서 간섭이 없었다는 것을 확인하기 위한 것입니다. 업데이트 RDF를 서명하는 데에는 <a href="ko/McCoy">McCoy</a> 도구를 사용해야 합니다.
</p><p>서명 방식에 대한 기술적인 세부 사항은 이 문서의 범위를 벗어나지만 기본적인 사항은 다음과 같습니다.
</p><p>부가 기능 작성자가 공개/개인 RSA 암호 키 쌍을 생성합니다.
</p><p>공개키는 DER로 인코드된 후에 base 64로 인코드되어 부가 기능의 <tt>install.rdf</tt>에 <code><a href="ko/Install.rdf#updateKey">updateKey</a></code> 항목으로 추가됩니다.
</p><p>작성자가 업데이트 RDF 파일을 생성할 때 도구를 사용하여 개인키로 서명합니다. 대략적으로 이야기하면, 업데이트 정보는 문자열로 변환되어 sha512 해시 알고리즘으로 해시되고 개인키로 이 해시를 서명합니다. 결과 데이터는 DER로 인코드하고 base 64로 인코드한 후 업데이트 RDF에 <code>em:signature</code> 항목으로 포함합니다.
</p><p><br>
</p><p><br>
</p>
<div class="noinclude">
</div>
{{ wiki.languages( { "en": "en/Extension_Versioning,_Update_and_Compatibility", "es": "es/Versionado,_actualizaci\u00f3n_y_compatibilidad_de_extensiones", "fr": "fr/Versions_d\'une_extension,_mise_\u00e0_jour_et_compatibilit\u00e9", "ja": "ja/Extension_Versioning,_Update_and_Compatibility" } ) }}
현재 리비전 복원