Strict Apk 2 hash compliance - #2153
Open
dgtlrift wants to merge 2 commits into
Open
Conversation
…sh_datatar_sha1): ownership fields (uid/gid/uname/gname/magic) were rewritten but the tar header checksum was never recalculated afterward, corrupting the checksum apk validates on every header. SHA1 per-file hash included tar padding: hash_record_sha1 was hashing the full 512-byte-aligned record buffer instead of just the real file content, so every APK-TOOLS.checksum.SHA1 pax extension was wrong. Datahash computed on the wrong bytes entirely: the .PKGINFO datahash field is checked by apk against the SHA-256 of the compressed data.tar.gz bytes, not the uncompressed data.tar. fpm was hashing the raw tar before compression. I confirmed this by patching apk-tools' extract_v2.c to print the digest it calculates - it matched sha256(data.tar.gz) exactly, not sha256(data.tar). Fixed by restructuring output to gzip the data tar first, hash those compressed bytes, then build .PKGINFO/control tar/compress it, then concatenate the two already-compressed streams. Found and fixed a related latent bug in hash_datatar_sha1: ownership-header rewriting was being applied even to the null (end-of-archive) terminator blocks, polluting bytes that must stay all-zero.
Author
|
Created new PR per @jordansissel recommendation |
Author
|
Can someone review and commit? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stale tar header checksums (cut_tar_record, and the main header in hash_datatar_sha1): ownership fields (uid/gid/uname/gname/magic) were rewritten but the tar header checksum was never recalculated afterward, corrupting the checksum apk validates on every header.
SHA1 per-file hash included tar padding: hash_record_sha1 was hashing the full 512-byte-aligned record buffer instead of just the real file content, so every APK-TOOLS.checksum.SHA1 pax extension was wrong.
Datahash computed on the wrong bytes entirely: the .PKGINFO datahash field is checked by apk against the SHA-256 of the compressed data.tar.gz bytes, not the uncompressed data.tar. fpm was hashing the raw tar before compression. I confirmed this by patching apk-tools' extract_v2.c to print the digest it calculates - it matched sha256(data.tar.gz) exactly, not sha256(data.tar). Fixed by restructuring output to gzip the data tar first, hash those compressed bytes, then build .PKGINFO/control tar/compress it, then concatenate the two already-compressed streams.
Found and fixed a related latent bug in hash_datatar_sha1: ownership-header rewriting was being applied even to the null (end-of-archive) terminator blocks, polluting bytes that must stay all-zero.