Integrity check always fails for nitropad-t430-v1.4.npf

[tlikonen]

When trying to flash nitropad-t430-v1.4.npf the integrity check always fails. I have manually checked the SHA256 sums of the said .npf file itself and its internal .rom file. Both verify correctly. So I have had to unzip the .npf file and use .rom file for flashing. That worked.

First I tried to flash .npf file with rom version 1.3.1. Later I had rom version 1.4 and tried the flashing again: the automatic file integrity check always fails.

[marmarek]

Same here. It seems create-npf.sh script includes sha256sum file, while flash-gui.sh expects sha256sum.txt.
Furthermore, sha256sum -cs call in flash-gui.sh is called in a wrong directory, so it has no chance to find file extracted into /tmp/verified_rom...

cc @daringer

[szszszsz]

Thank you for checking that!

@daringer It should suffice then to rebuild/repack the npf archive with the proper hash file naming

[marmarek]

@daringer It should suffice then to rebuild/repack the npf archive with the proper hash file naming

It may work if you include full path (including /tmp/verified_rom/) too. But I think that's something worth fixing anyway.

BTW, it might be a good idea to include sha256sum.txt.sig there too, and verify the signature first. But that's separate feature.

[tlaurion]

I would like to hijack this issue for a second for important considerations. Heads is not reproducible for a while now, and I would love to see more collaboration into fixing them (fixing the cause) instead of distributing signed binaries from forks of the main project.

Ideally, the ROMs produced by CIs should produce the exact same ROM as a local build for the same commit.

Those ROMs, being produced from multiple untrusted sources, should produce the same ROMs for the same upstream commits and same hashes.

If we (Insurgo, Nitrokey, Purism) would collaborate into fixing reproducibility issues, then the ROMs should be the same, produced upstream then from other CI and the hashes should be the same everywhere where produced. And ROm produced locally by users not matching the ones found online should raise valid concerns. Otherwise, nobody can produce the same ROM. And this is really problematic.

The non-reproducible modules are listed here as of yesterday verification: linuxboot/heads-wiki#70

Once that is resolved, the next step would be to create tags and releases, on which final hashes should be provided for specific commits.

Of course, signing those is a plus to attest to end user that we recognise and reviewed the changes that were applied upstream and in our branches up to that point and validate their integrity prior of flashing as well. Authenticity and integrity validation.

But signing non reproducible builds not only diverge from Heads original mission, divide efforts of maintainership that should be happening upstream, but also bring users to our own produced documentation and guides instead of bonifying upstream one that benefit everyone.

[szszszsz]

@daringer Can you let us know, if the binary is updated?

[daringer]

updated create-npf.sh, replaced the files (.npf inside the release) should work now...

[nord73]

The checksum for the file sha256 is still wrong and fails the sha256 verification with:
sha256sum: FAILED
sha256sum: WARNING 1 of 9 computed checksums did NOT match
Then the ROM Integrity Check also fails with:
/media/nitropad-x230-v1.4-npf integrity check failed. Did not flash.

[marmarek]

Furthermore, sha256sum -cs call in flash-gui.sh is called in a wrong directory, so it has no chance to find file extracted into /tmp/verified_rom...

I believe this is still the case.

[daringer]

okok, this calls for a new release ... or not... this would force ppl to use .rom until flash-gui.sh is updated, so maybe I'll modify the sha256sums.txt which is included into the .npf so that it contains the full paths ...

[daringer]

updated the release, should work now(tm) ... sorry for the inconvenience, just updated the npf build process, no actual changes inside the firmware, thus no new release, confirmed and tested here, can someone else retest?

[szszszsz]

AFAIK this was tested at Nitrokey. Closing as fixed.