{% extends "global/layout.html" %} {% block title %}{% trans %}I2P Software Update Specification{% endtrans %}{% endblock %} {% block lastupdated %}{% trans %}November 2014{% endtrans %}{% endblock %} {% block accuratefor %}0.9.17{% endblock %} {% block content %}
{% trans -%} I2P uses a simple, yet secure, system for automated software update. The router console periodically pulls a news file from a configurable I2P URL. There is a hardcoded backup URL pointing to the project website, in case the default project news host goes down. {%- endtrans %}
{% trans -%} The contents of the news file are displayed on the home page of the router console. In addition, the news file contains the most recent version number of the software. If the version is higher than the router's version number, it will display an indication to the user that an update is available. {%- endtrans %}
{% trans -%} The router may optionally download, or download and install, the new version if configured to do so. {%- endtrans %}
{% trans -%} This format is replaced by the su3 news format as of release 0.9.17. {%- endtrans %}
{% trans -%} The news.xml file may contain the following elements: {%- endtrans %}
<i2p.news date="$Date: 2010-01-22 00:00:00 $" /> <i2p.release version="0.7.14" date="2010/01/22" minVersion="0.6" />
{% trans -%} Parameters in the i2p.release entry are as follows. All keys are case-insensitive. All values must be enclosed in double quotes. {%- endtrans %}
{% trans -%} The elements may be included inside XML comments to prevent interpretation by browsers. The i2p.release element and version are required. All others are optional. NOTE: Due to parser limitations an entire element must be on a single line. {%- endtrans %}
{% trans -%} As of release 0.9.9, the signed update file, named i2pupdate.su3, will use the "su3" file format specified below. Approved release signers will use 4096-bit RSA keys. The X.509 public key certificates for these signers are distributed in the router installation packages. The updates may contain certificates for new, approved signers, and/or contain a list of certificates to delete for revocation. {%- endtrans %}
{% trans -%} This format is obsolete as of release 0.9.9. {%- endtrans %}
{% trans -%} The signed update file, traditionally named i2pupdate.sud, is simply a zip file with a prepended 56 byte header. The header contains: {%- endtrans %}
{% trans commonstructures=site_url('docs/spec/common-structures') -%} The signature covers only the zip archive - not the prepended version. The signature must match one of the DSA public keys configured into the router, which has a hardcoded default list of keys of the current project release managers. {%- endtrans %}
{% trans -%} For version comparison purposes, version fields contain [0-9]*, field separators are '-', '_', and '.', and all other characters are ignored. {%- endtrans %}
{% trans -%} As of version 0.8.8, the version must also be specified as a zip file comment in UTF-8, without the trailing zeroes. The updating router verifes that the version in the header (not covered by the signature) matches the version in the zip file comment, which is covered by the signature. This prevents spoofing of the version number in the header. {%- endtrans %}
{% trans -%} The router first downloads the header of the update file from one in a configurable list of I2P URLs, using the built-in HTTP client and proxy, and checks that the version is newer. This prevents the problem of update hosts that do not have the latest file. The router then downloads the full update file. The router verifies that the update file version is newer before installation. It also, of course, verifies the signature, and verifes that the zip file comment matches the header version, as explained above. {%- endtrans %}
{% trans -%} The zip file is extracted in the base $I2P installation directory. {%- endtrans %}
{% trans -%} As of release 0.7.12, the router supports Pack200 decompression. Files inside the zip archive with a .jar.pack or .war.pack suffix are transparently decompressed to a .jar or .war file. Update files containing .pack files are traditionally named with a '.su2' suffix. Pack200 shrinks the update files by about 60%. {%- endtrans %}
{% trans -%} As of release 0.8.7, the router will delete the libjbigi.so and libjcpuid.so files if the zip archive contains a lib/jbigi.jar file, so that the new files will be extracted from jbigi.jar. {%- endtrans %}
{% trans -%} As of release 0.8.12, if the zip archive contains a file deletelist.txt, the router will delete the files listed there. The format is: {%- endtrans %}
{% trans -%} The router will then delete the deletelist.txt file. {%- endtrans %}
{% trans -%} This specification is used for router updates as of release 0.9.9, and reseed data as of release 0.9.14. {%- endtrans %}
Bytes | Contents |
---|---|
0-5 | Magic number "I2Psu3" |
6 | unused = 0 |
7 | su3 file format version = 0 |
8-9 | Signature type
|
10-11 | Signature length, e.g. 40 (0x0028) for DSA-160 |
12 | unused |
13 | Version length (in bytes not chars, including padding) must be at least 16 (0x10) for compatibility |
14 | unused |
15 | Signer ID length (in bytes not chars) |
16-23 | Content length (not including header or sig) |
24 | unused |
25 | File type
|
26 | unused |
27 | Content type
|
28-39 | unused |
40-55+ | Version, UTF-8 padded with trailing 0x00, 16 bytes minimum, length specified at byte 13. Do not append 0x00 bytes if the length is 16 or more. |
xx+ | ID of signer, (e.g. "zzz@mail.i2p") UTF-8, not padded, length specified at byte 15 |
xx+ | Content, length and format specified in header |
xx+ | Signature, length specified in header, covers everything starting at byte 0 |
{% trans -%} All unused fields must be set to 0 for compatibility with future versions. {%- endtrans %}
The content type specifies the trust domain. For each content type, clients maintain a set of X.509 public key certificates for parties trusted to sign that content. Only certificates for the specified content type may be used. The certificate is looked up by the ID of the signer. Clients must verify that the content type is that expected for the application.
While signature verification and content extraction may be implemented in one pass, an implementation must read and buffer the first 10 bytes to determine the signature type before starting to verify. All values are in network byte order (big endian).{% trans -%} As of 0.9.17, the news is delivered in an "su3" file format. {%- endtrans %}
SU3 Details:
Atom <feed> Details:
The following <feed> elements are used:Atom <entry> Details:
Each Atom <entry> in the news feed may be parsed and displayed in the router console. The following elements are used:Atom <i2p:release> Details:
There must be one <i2p:release> entity in the feed, containing the following attributes and entities: