4 ms·

Why are MSI files designed like this? Why allow for just a specific part of the file to be signed? (I have no technical experience dealing with them.)

banthar 6y ago
Extra bytes at end of file will be ignored by most formats. You generally don't want to depend on file length.
Varriount 6y ago
Other than a possible checksum calculated from the entire file contents, many binary formats use either: - Headers describing a section, including the length of a section. - Prefixing each section with a size. - Using a marker pattern (such as a null byte) to mark the end of a section of data. (there are more than these three, but these are the most common) That last one isn't used very often, and when it is, it's mostly for textual data. The consequence of using the first two techniques is that it's entirely possible to add data to the end of the format, since a parser would just read the last section and stop (assuming the format supports knowing what the last section is).
Lammy 6y ago
If you hashed the entire file you wouldn't be able to append that hash to the file for distribution because it would change the hash of the file. That's why FOSS software signatures are usually MD5/SHAwhatever in a separate text file.
- wwright 6y ago
  The format could still be "hash of everything else + everything else"
- Xylakant 6y ago
  RPMs contain the signatures in the archive. DEB packages don’t, something I consider a major shortcoming in the Debian package format.
- hnick 6y ago
  You can, if the consuming system is format-aware. I think MSI can fall into that category. I developed something like this to put an md5 hash in a comment in the first line of a code module at a place I worked. It simply read the file, removed that line, and hashed the rest of the file data to generate the hash for comparison. This was just to stop programmers changing the code without submitting it to a secondary system for validation/tracking (easy to work around, but that shows intent to bypass policies when we see it in the repo).

banthar 6y ago

Extra bytes at end of file will be ignored by most formats. You generally don't want to depend on file length.

Varriount 6y ago

Other than a possible checksum calculated from the entire file contents, many binary formats use either: - Headers describing a section, including the length of a section. - Prefixing each section with a size. - Using a marker pattern (such as a null byte) to mark the end of a section of data. (there are more than these three, but these are the most common) That last one isn't used very often, and when it is, it's mostly for textual data. The consequence of using the first two techniques is that it's entirely possible to add data to the end of the format, since a parser would just read the last section and stop (assuming the format supports knowing what the last section is).

Lammy 6y ago

If you hashed the entire file you wouldn't be able to append that hash to the file for distribution because it would change the hash of the file. That's why FOSS software signatures are usually MD5/SHAwhatever in a separate text file.

wwright 6y ago
The format could still be "hash of everything else + everything else"
Xylakant 6y ago
RPMs contain the signatures in the archive. DEB packages don’t, something I consider a major shortcoming in the Debian package format.
hnick 6y ago
You can, if the consuming system is format-aware. I think MSI can fall into that category. I developed something like this to put an md5 hash in a comment in the first line of a code module at a place I worked. It simply read the file, removed that line, and hashed the rest of the file data to generate the hash for comparison. This was just to stop programmers changing the code without submitting it to a secondary system for validation/tracking (easy to work around, but that shows intent to bypass policies when we see it in the repo).