Reproducible builds

[retsifp]

I'm currently planning to set up an autobuild-server, which automatically checks for updates (with the same mechanism as the updater on the phone), downloads them and automatically builds the rooted boot-images.

Things would be a lot easier, if the builds would be identical (so I could easily check if the builds on the server are OK), but currently they are not. I'm not aware if this is necessary, can you please enlighten me why this is the case? :wink:

In addition to that, the fairphone community has currently two sources for boot-images, and it would be great if they would be identical, so anyone could check them by comparing the SHA256-Hashes.

[phhusson]

I'm not sure what are the causes of non reproducible builds, but I have no problem taclking this problem, for one exception: The boot.img are signed with my private key, and I want to keep signing them. So we would have to provide a tool which gives the fingerprint of the body of the boot.img without the signature

Now, I assume there might be other problems (like timestamps) preventing from reproducible builds.

Could you take a look? My advice would be to vbindiff the full boot.img, to see if the differences are only the signature. If they are not, do a vbindiff on the uncompressed initramfs, you'll see the cpio structure and you can find the differences right there.

[retsifp]

Well, I think the signature with your key is only there when you are generating them?

I uploaded samples on my server, these files are generated from the same orig-boot.img and the latest version of this repo.

I took a look with vbindiff, first there are just a few characters difference, then there is a lot of difference, but honestly, I don't have a clue why the difference is there :wink:

[phhusson]

Just to be sure, I must compare this to http://superuser.phh.me/fairphone/fp2/fp2_1.7.0/boot-fp2-fp2_1.7.0-su-eng-r250.img ? Also as mentioned in the name, it's a r250, while latest git commit is r259. Considering the git commit is referenced in the cpio, it could be a problem as well

[retsifp]

No, I compared the two files (a/b) inside the linked boot.img.7z, I'm not interested in comparing them with your "official" files :wink:

I just read your tip above and unpacked the files, but now I can't find any difference... :sweat_smile:

[phhusson]

Right, so the vbindiff after gunzip of the initramfs shows that every file has a field which changes, thus I assume there is indeed a timestamp difference.

[phhusson]

And timestamp is the only difference I'm seeing.

[retsifp]

Great! So I think a touch -t 197001011200 * inside the folder before packing it should do the trick. I tested this at the and of build.sh (Edit: sorry, bootimg.sh), but it didn't work. Maybe you can give me a clue where I should do that? :wink:

[phhusson]

in scripts/bootimg.sh at the start of doneBootImgEdit()

[retsifp]

Great! I added find . -exec touch -t 197001011200 * {} \; (which produces A LOT of errors due to rights, but we can fix that later... :wink: Edit: fixed in retsifp/super-bootimg@d96512dff367a1062e72f35474c927ba854ab96a) to bootimg.sh in line 86.

Now there was only a small difference:

It's the timestamp of the ramdisk inside ramdisk.gz.

Unfortunately, I didn't find another possibilty as doing it here: retsifp/super-bootimg@44e367f

Are you aware of any side effects this could have? Is any code inside my phone checking the timestamps of the files?

[retsifp]

Had to do another change (retsifp/super-bootimg@9d558111c2cd6642d74a81c44c0012e29b32fb63), I'm now testing this on my phone. :wink:

I also had another idea: We could set the date of all files to the date of creation of the orig-boot.img by using touch -r "$homedir"/orig-boot.img <target>

[phhusson]

Nope, all timestamps are useless. Your method seem okay to me.

[retsifp]

Ok, may I open a pull request or do you want to make it optional or don't you want it at all? :wink:

[phhusson]

You can open a PR as-is