1881122 - Mac installer size can vary *a lot* for the same contents

Status: NEW

(Firefox Build System :: General, defect, P3)

Description

[Mike Hommey [:glandium]]

The four builds on https://treeherder.mozilla.org/jobs?repo=autoland&searchStr=os%2Cx%2Cnightlyasrelease%2Copt%2Cprofile-guided%2Coptimization%2Cbuilds%2Cbuild-macosx64-nightlyasrelease%2Fopt%2Cbnar&revision=a39978d779e2f23b325bb042f23c42517d1b7b37 are actually identical. The only differences they have once extracted are timestamps. Yet, this is what their installer sizes are:

• 90827825
• 90743736
• 90889674
• 90839089

Comment 1

[[e-mail] (:bhearsum)]

This could be related to the work we did making macOS DMGs attributable or some changes to libdmg-hfsplus that we happened to pick up as part of that work, that were already sitting on the main branch. gsvelto can speak better to those.

For the work related to attribution, the most notable change is that we keep 1 or 2 blocks of the dmg uncompressed. However, I don't think these builds are even using an attribution sentinel, so we shouldn't be hitting this code path at all?

Interestingly, I extracted the hfs filesystem from each of these dmgs - and while they are all identical in size, each one has a different hash:

~/tmp/2024-02-20 ❯ ls -l *.hfs                                                                                     
-rw-rw-r-- 1 bhearsum bhearsum 290455552 Feb 20 16:31 target1.hfs
-rw-rw-r-- 1 bhearsum bhearsum 290455552 Feb 20 16:31 target2.hfs
-rw-rw-r-- 1 bhearsum bhearsum 290455552 Feb 20 16:31 target3.hfs
-rw-rw-r-- 1 bhearsum bhearsum 290455552 Feb 20 16:32 target4.hfs
~/tmp/2024-02-20 ❯ shasum *.hfs                                                                                       
198830131614a0bbea23130bfb942df90df5ea8d  target1.hfs
d9fd614536cbb8305b5ae399be6af2286f04f625  target2.hfs
82a72a653ed5f5ba2b52f4a8365e98b729f56d81  target3.hfs
4c543935c0dac1392ccbc120709b6f2f213c2666  target4.hfs

I also see that the final block of each dmg varies in size - but not enough to account for for total size difference:

run 1107: start=290193408 sectors=512, length=52870, fileOffset=0x567f53e
run 1107: start=290193408 sectors=512, length=56542, fileOffset=0x5669e6d
run 1107: start=290193408 sectors=512, length=28655, fileOffset=0x569456e
run 1107: start=290193408 sectors=512, length=40251, fileOffset=0x568528d

My best guess is that the differences in the HFS filesystems is causing the bzip2 compression done by the dmg to perform better or worse.

There were changes to that in both PRs, but https://github.com/mozilla/libdmg-hfsplus/pull/6/files only affects extended attributes, so I think it's more likely that something from https://github.com/mozilla/libdmg-hfsplus/pull/8 is at fault.

Comment 2

[Mike Hommey [:glandium]]

Note that hfs with a different content may have the same size (if you look at the target.dmgs on the parent push, for example, the .hfs has the same size, but the contents are vastly different).
As I mentioned, the only visible difference in the .hfs files once extracted is the file timestamps. We should probably force them to use the MOZ_BUILD_DATE.
I'm also not excluding the possibility that this isn't a new issue. It's just the first time I noticed it.

Comment 3

[Gabriele Svelto [:gsvelto]]

I don't really have any good ideas here but out of curiosity I checked if we'd have alternatives to build the HFS+ filesystem... and we don't. Former mozillian Gregory Szorc wrote a bunch of crates to build/sign/notarize bundles but it doesn't include an HFS+ filesystem writer (he's working on an APFS one but it's in its early stages).