Verifying firmware sha256

[Ingo-Albrecht]

The releases' sha256sum files do not include the hash for the respective firmware-nk3-*.zip (I looked at releases >=1.5). At the same time this archive is what nitropy nk3 validate-update expects as input-file. While the zip file itself contains a separate sha256sum file for its content, it should still be listed for the release so that users can verify the download prior to validating it with the tool.

[robin-nitrokey]

Adding it to sha256sum is not trivial because this one is generated by the CI before the images are signed and zipped into the container. But we could maybe add a separate file that only has the checksum for the container.

[Ingo-Albrecht]

Yes, I understand the zip creation has to trail the release of the firmware(s) and is a service to pick the correct image. A separate hash file would be ok, of course.

I realize a hash might seem superfluous for a zip with signed files, but keep in mind the tools signature validation outputs versions followed by "signed by: Nitrokey" only (e.g. no key ID). A lot of users will download but perform updates later and offline, hence, may want to double-check the firmware-zip to use at that moment.

[robin-nitrokey]

For v1.5.0-test.20231030, I’ve manually added a firmware-nk3-v1.5.0-test.20231030.zip.sha256sum file. It is to be discussed whether we want to do that for all releases. If yes, it should be automated, documented and used in pynitrokey.

[Ingo-Albrecht]

Thanks, having it available for a manual hash-check works fine for me. Once it's decided how to handle it in the future, I can make a suggestion perhaps.

As far as I've now seen in my test, pynitrokey already does check for the sha256sum inside the zip with the validate-update action. While the problem with the sha256sum in the zip is that users cannot use it to easily do a consistency check of the download (or firmware file) themselves, it suffices for validate-update itself. Of course this would change, if it's decided to drop the sha inside the zip, but then users would always have to download two files - not worthwhile in my opinion. So, aside for a couple more sentences in its user guidance and/or output, pynitrokey validation already is done and dusted™.(?)

[robin-nitrokey]

I would keep the checksum inside of the container. validate-update would not have to use the additional checksum file, but it could make sense to use it when downloading the update in nk3 fetch-update or nk3 update. But I agree that it’s not important or required.