Bitcoin.org: Wasabi Deterministic Build Does Not Work

[nopara73]

I'd just like to note that our deterministic build stopped working, although we're working on fixing it (https://github.com/zkSNACKs/WalletWasabi/issues/3783#issuecomment-646994894) and probably it's just temporary, anyhow at this moment we aren't qualified according to @davterra who tested it): https://github.com/zkSNACKs/WalletWasabi/issues/3659

Also pinging @molnard.

[nopara73]

Turns out it was tested with the wrong .NET Core version, so dismiss this issue for now.

[davterra]

As someone not really used to using .NET or WIndows for testing, there's a good chance I made a mistake somewhere...but after reverting to SDK 3.1.202 and verifying that 3.1.202 was the active version, I redid the above-mentioned test and still got a display full of "diffs".

[nopara73]

Yeah to add to this, it's also possible that @MaxHillebrand or whoever ported it to the docs changed some important wording in the guide, anyway I'll verify myself after the next release as sort out this mess.

[nopara73]

There were a couple of issues with the deterministic build.

• Avalonia, our UI library started building paths into the final binaries,
• We started using a handy code element [CallerFilePath] for logging that also somehow resulted in paths built into the final binaries,
• We started doing Apple code signing, but unfortunately it makes it impossible for anyone to perfectly deterministically reproduce the OSX release as the signatures are modifying the files.

The first two issues are fixed for the current release, but the Apple Code Signing seems like is complete blocker. Issue and more explanation here: https://github.com/zkSNACKs/WalletWasabi/issues/4110

"According to this, it is impossible to have both deterministic build and code signature on macOS. macOS Gatekeeper won't let you run software without it - thus code signature is prior to the deterministic build." - @molnard

I'm closing this issue. If the maintainers think the Apple code signing stuff should result in taking Wasabi's deterministic build tick away, then I acknowledge the decision and I open the PR for that.

[crwatkins]

@nopara73 Thanks for the followup! The following are questions, not recommendations.

Would it be possible to create a tool to compare the images while ignoring the signature (or perhaps a tool that replaces the signature with a known value)?

Would it be possible to create two distributions for MacOS, one signed to keep Gatekeeper happy and one built deterministically to keep those happy that might value that more?

I would think that either of the above would meet the scoring criteria for deterministic builds. Also, please note, if we can't find a way to resolve this, the listing mechanism allows for a different scoring for a different OS (so we can continue to show deterministic builds for the appropriate OS).

[molnard]

Hi @crwatkins,

Thanks for the reply!
How about this?
I can add an additional binary package for macOS that is not signed. I could guarantee the deterministic builds for that - in that case, the package is not signed. On the other hand, the user can choose to download the signed package too.

[crwatkins]

I can add an additional binary package for macOS that is not signed. I could guarantee the deterministic builds for that - in that case, the package is not signed. On the other hand, the user can choose to download the signed package too.

That sounds good to me.