Software Update:MAR: Difference between revisions

m
No edit summary
m (→‎SIGNATURE_ENTRY.SignatureAlgorithmID: Fix SHA384 signature size)
 
(14 intermediate revisions by 4 users not shown)
Line 27: Line 27:
ADDITIONAL_SECTION_ENTRY (Only present if NumAdditionalSections is more than 0)
ADDITIONAL_SECTION_ENTRY (Only present if NumAdditionalSections is more than 0)
   4 bytes: BlockSize - (Z)
   4 bytes: BlockSize - (Z)
   4 bytes: BlockIdentifier - Used to identify the optional section, 1 for a Product Information Block.
   4 bytes: BlockIdentifier - Used to identify the additional section, 1 for a Product Information Block.
   (Z-8) bytes: The rest of the block.
   (Z-8) bytes: The rest of the block.


Line 55: Line 55:
   
   
   1: RSA-PKCS1-SHA1 (2048 bits / 256 bytes)
   1: RSA-PKCS1-SHA1 (2048 bits / 256 bytes)
  2: RSA-PKCS1-SHA384 (4096 bits / 512 bytes)


The updater will only accept the MAR file if at least one of the signatures verify.
The updater will only accept the MAR file if at least one of the signatures verify.
Some versions of the updater may not apply a MAR file unless a valid signature of a particular <tt>SIGNATURE_ENTRY.SignatureAlgorithmID</tt> is included in the MAR file.
Some versions of the updater may not apply a MAR file unless a valid signature of a particular <tt>SIGNATURE_ENTRY.SignatureAlgorithmID</tt> is included in the MAR file.


As of Firefox 10, only RSA-PKCS1-SHA1 signatures are accepted.
From Firefox 10-56, only RSA-PKCS1-SHA1 signatures are accepted. [https://bugzilla.mozilla.org/show_bug.cgi?id=1105689 Bug 1105689] adds support for SHA-384 and is slated for Firefox 56.
There is no indicator in the MAR file for which operating system the MAR is for.
There is no indicator in the MAR file for which operating system the MAR is for.


Line 87: Line 88:


The product information block identifies the product and channel this MAR file applies to.  It also includes the new version number to avoid downgrades.  
The product information block identifies the product and channel this MAR file applies to.  It also includes the new version number to avoid downgrades.  
The product and channel are combined in the MARChannelName field.


PRODUCT INFORMATION BLOCK
PRODUCT INFORMATION BLOCK


   4 bytes: Block size
   4 bytes: BlockSize - The size of the product information block.
   4 bytes: Block identifier with a value of 1
   4 bytes: BlockIdentifier - The identifier of the product information block, with a value of 1
   <64 bytes: ApplicationID used to identify the product (such as from MOZ_APP_ID) Example: {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
   <64 bytes: MARChannelName used to identify the product and channel (such as from MAR_CHANNEL_ID) Example: mozilla-central
  1 byte: null terminator
  <64 bytes: ChannelName (such as from MOZ_UPDATE_CHANNEL) Example: default
   1 byte: null terminator
   1 byte: null terminator
   <32 bytes: ProductVersion string (such as from MOZ_APP_VERSION) Examples: 12.0.1.5371, 12.0a1
   <32 bytes: ProductVersion string (such as from MOZ_APP_VERSION) Examples: 12.0.1.5371, 12.0a1
   1 byte: null terminator
   1 byte: null terminator
  * bytes: Optional unused data adding up to BlockSize.


== Source Code ==
== Source Code ==
Line 107: Line 108:


This question was given a fair amount of consideration.  Ultimately, we decided to go with a custom file format because using libjar would have required a fair bit of hacking.  Writing custom code was a simpler option, and it resulted in less code (mar_read.c is less than 300 lines of code).  Moreover, the update system does not need a standard file format.  The elements stored in the archive are bzip2 compressed binary diffs, generated using a variation of bsdiff.  So, being able to unpack the archive file using standard tools wouldn't be very useful in and of itself.
This question was given a fair amount of consideration.  Ultimately, we decided to go with a custom file format because using libjar would have required a fair bit of hacking.  Writing custom code was a simpler option, and it resulted in less code (mar_read.c is less than 300 lines of code).  Moreover, the update system does not need a standard file format.  The elements stored in the archive are bzip2 compressed binary diffs, generated using a variation of bsdiff.  So, being able to unpack the archive file using standard tools wouldn't be very useful in and of itself.
== MAR extraction tools ==
There’s 2 different python scripts:
* http://hg.mozilla.org/build/tools/file/b77b517eab66/buildfarm/utils/mar.py
* https://github.com/mozilla/build-mar
Note:
* The latter is more recent, but has more dependencies.
* The former works just fine for extracting files
** to use the former: cd tmp_dir; mar.py -x ../foo.mar
** for bzip2'ed files such as b2g mar files:  try 'mar.py -x -j fota-flame-update.mar'
** or 'mv update.zip update.zip.bz2; bunzip2 update.zip.bz2'
Confirmed users
2,456

edits