How to use this tool if I built binary myself and just have hash published by Dasharo Team?

[pietrushnic]

I'm trying to use this tool, but it assumes I can access the Dasharo Team-produced binary, which I don't want to rely on since I think there should be a process without such access. I have a binary that I built myself. Obviously, coreboot generated dev keys and used those for signing. So, I have a hash of binary signed with Dasharo Team keys, which I cannot produce, or a hash of binary signed by some randomly generated dev keys. Neither of those hashes help me anyway. So why those hashes are published? And how I can confirm I built binary which match one produced by Dasharo Team.

https://docs.dasharo.com/variants/hardkernel_odroid_h4/releases/#v090-2025-02-20

Such a solution should be covered in the documentation: https://docs.dasharo.com/guides/reproducible-build-verification/#romscope

And linked in release templates behind published hashes to prove what value is in those artifacts. The last step of the building process should also be verifying the hash.

[mkopec]

or a hash of binary signed by some randomly generated dev keys

@pietrushnic the dev keys are always the same. They're commited to the vboot repo directly. If you build a binary and we have reproducibility, the hash should be identical.

it assumes I can access the Dasharo Team-produced binary, which I don't want to rely on since I think there should be a process without such access

Well, this tool was created with NovaCustom UEFI use case in mind, where binaries are published publicly, and anyone can verify those. To make it work without access to the binary, you'd need to publish a list of hashes of every FMAP region for every binary in that release. Can be done, but nobody has requested that yet.

[pietrushnic]

@pietrushnic the dev keys are always the same. They're committed directly to the vboot repo. If you build a binary and we have reproducibility, the hash should be identical.

That helps, but it also means the Odroid H4+ build is not reproducible. I'd like to know if we tested it.

Well, this tool was created with NovaCustom UEFI use case in mind, where binaries are published publicly, and anyone can verify those. To make it work without access to the binary, you'd need to publish a list of hashes of every FMAP region for every binary in that release. Can be done, but nobody has requested that yet.

Ok, if keys are static, that helps a lot because the build should give the same result. I'm afraid that nobody has tested that, and the binaries are not reproducible.

I will create a bug in dasharo-issues for that. OTOH, it is worth adding information about reproducibility in such cases and linking it appropriately depending on the end user's expectations against a given release type. We should correct all templates. I will add issue also about that.

[mkopec]

I'm afraid that nobody has tested that, and the binaries are not reproducible.

Usually when I upload binaries, the person holding the signing key builds and checks if the hashes match. But that's using our internal build scripts, sadly the public instructions don't always match and can produce a different hash. That's partly what https://github.com/Dasharo/fwbuild was meant to fix :)

[pietrushnic]

@mkopec I'm not sure how it should fix that for DPP releases?

[miczyg1]

Ok, if keys are static, that helps a lot because the build should give the same result. I'm afraid that nobody has tested that, and the binaries are not reproducible.

We often check reproducibility. Just as @mkopec explained. Someone uploads the binary to the cloud for signing and another person is supposed to sign it. But before that happens, the signer builds the binary again and checks if the hash matches. If the image is built from the same revision and using the same coreboot-sdk container, builds ARE reproducible. The only problem we had was with heads. Specific software packages had hardcoded paths inside, which led to the lack of reproducibility: linuxboot/heads#1616 SIcne then we haven't had reproducibility incidents (except for missing blobs for MTL laptops...)

@pietrushnic here I have explained your small mistake in reproducibility check: Dasharo/dasharo-issues#1250 (comment)

I may agree that the dev_signed thingies are poorly documented (or if documented at all). Again, as many things, we introduced our own vboot signing in a hurry, patching just the necessary things in the release scripts, without providing changes to the documentation about what happened and how that affects the processes. I saw we have added "something" recently: https://github.com/Dasharo/docs/pull/983/files but it is still far from sufficient I think.

[pietrushnic]

Ok, now I understand what is going on. Documenting that and linking correctly in relevant release templates would be sufficient. I guess it has to be addressed in the issues that have already been created.