Confirm
394
edits
Changes
no edit summary
== Details ==
The file structure in a nut-shell is a header (HEADER), follow by zero or more hash signtures (S IGNATURES), followed by a list of variable length files, and finally ending with an index of the files (INDEX). The index is a list of variable length entries (INDEX_ENTRY).
HEADER
4 bytes : offset to INDEX in bytes (big endian) relative to start of file
SIGNATURES
''Zero or more of the following:''
4 bytes : Hash ID
N bytes : Holds the signed hash as defined below
INDEX
4 bytes : size of INDEX in bytes (big endian)
The flags field is used to store file permission bits (in the standard unix-style format).
== Signatures ==
One or more signatures can be specified
== Defined Signature IDs ==
ID 1: An SHA1 hash signed with RSA 2048, the first certificate shipped with FF must be used.
== Source Code ==
The source code can be found under {{source|modules/libmar}}.
See {{bug|296303}} and {{bug|699700}}
== Why not use ZIP or some other standard file format? ==
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.
