Reproducibility Verification Report – Ginger Wallet Desktop v2.0.21

[xrviv]

Hi Ginger Wallet team 👋,

We at WalletScrutiny.com performed an independent reproducibility verification of Ginger Wallet Desktop v2.0.21. Thank you for making the source code fully available and for adopting strong reproducibility-friendly practices in the project configuration.

Unfortunately, our builds did not match the official release binaries. Below is a detailed breakdown of what we found, along with some suggestions on how we can work together to close the gap.

---

🔧 Verification Summary

• App Name: Ginger Wallet Desktop
• Version Tested: v2.0.21 (e524d22035)
• Official Release: Ginger-2.0.21-linux-x64.zip
• Official SHA256: fa149b5382e4237a3405752e19584a93c5ee4475e8d1be2fb3f0ed1096e293c0
• Build Environment: Docker container, Ubuntu 22.04, .NET SDK 8.0.100
• Method: Deterministic build (dotnet build -c Release --no-restore) and SHA256 comparison of assemblies

---

📦 Assemblies Compared

Assembly	Our Build SHA256	Official SHA256	Status
WalletWasabi.Fluent.Desktop.dll	5c54ba7ceb001bbc82d656568d7978b9bdc2dd99893be7017605fa6e4adbbd34	008a4972ac58e953dcf28d4ac86828eca6559937c0bcc0ec021341b9da138582	❌
WalletWasabi.dll	002724119a43c32252647188693b4c5607fcf228b77dc20d72610a548e930e1c	276179c0a21a03387e47ab387cf5511934f05a25439a6484c296c95a3bf02c4e	❌
GingerCommon.dll	01f9ed9bc5670a1ee5a7fde96cee95f375b9d93321f545187598a19f8892fcc1	7ee83b9b5fb4fc928b672634038d93d19481c1011c1ecec23e41b0587671f305	❌

---

🔍 Observations

✅ Strong Points

• Deterministic build settings enabled (Deterministic=true, DebugType=none, DebugSymbols=false).
• SDK pinned (8.0.100) via global.json.
• Centralized package management and lock files in place.
• Package sources explicitly cleared and defined (nuget.org + Avalonia feed).
• Path mapping configured to normalize builds.

❌ Where Divergence Appears

• Assembly versions differ (1.0.0.0 vs 2.0.21.0) unless parameters are injected.
• Even after injecting version parameters, hashes still diverge by ±1KB–100KB.
• WalletWasabi.csproj embeds a CommitHash value that may vary between CI and local builds.
• TargetLatestRuntimePatch=true could introduce runtime-level variation.
• Prebuilt binaries (Tor, bitcoind, HWI) are bundled directly—unclear if these are deterministically sourced.

---

💡 Recommendations

To enable full reproducibility verification, it would help the community if you could:

1. Document the official build process
   • Exact dotnet publish / dotnet build commands (including AssemblyVersion, FileVersion, InformationalVersion, CommitHash parameters).
   • Whether dotnet publish with RIDs, trimming, or ReadyToRun is used.
   • Post-build steps (signing, zipping, stripping).
2. Provide environment details
   • The Docker image or VM used for official builds.
   • Confirm whether SDK 8.0.100 patch levels and runtime patching affect outputs.
3. Clarify bundled binaries
   • Provenance of Tor, bitcoind, and HWI binaries.
   • Ideally link to deterministic upstream builds or provide reproducible instructions.
4. Consider a CI reproducibility check
   • Add a GitHub Action that rebuilds from source and compares to the official release artifacts.
   • This would allow independent parties to confirm reproducibility automatically.

---

🤝 Invitation

We appreciate the great work already done to make Ginger Wallet reproducible-friendly. With a little more transparency about the official build process, we’re confident this can be fully reproducible.

Would you be open to:

• Sharing the exact build scripts/parameters used in your release pipeline?
• Clarifying the origin of the bundled binaries?
• Working with us on a reproducible build attestation?

This would let us mark Ginger Wallet as ✅ Reproducible on WalletScrutiny instead of ❌ Non-Reproducible.

---

Thanks for your time and for all the work you’re doing on privacy-preserving Bitcoin wallets! 🙏

Daniel (WalletScrutiny)
https://walletscrutiny.com

---

https://walletscrutiny.com/verifier/?pubkey=1f9e547c2f31942623b8ad1d07713282e8640fd8cf474e9f79f18ace8af216ed#verificationId=d3ffaa521b8f7e79dc3ab14488e581cd1c51b094582b0b0819a3555a56f0ea68

[RolandUI]

Thanks for the feedback. We’ll review the release process and follow up.
This is the documentation for it: https://github.com/GingerPrivacy/GingerWallet/blob/master/WalletWasabi.Documentation/ClientRelease/ClientDeployment.md

[luzius1089]

@xrviv Thanks for your report! I’ll review it in the next few days and get back to you. This is important for Ginger, and I’m confident we can resolve it. In most cases, issues like this are caused by timestamps or randomly generated method identifiers.

[luzius1089]

I found an issue, see my PR. #153

GingerWallet is a fork of Wasabi Wallet, so basically, the instructions are the same:

https://github.com/GingerPrivacy/GingerWallet/blob/master/WalletWasabi.Documentation/Guides/DeterministicBuildGuide.md

[luzius1089]

I tried to address some of the suggestions, but it is making the build procedure more complex: #154

It is not the right direction, but I made another build for testing purposes:

https://github.com/luzius1089/GingerWallet/releases/tag/v2.0.21

[xrviv]

Hi,

Should we be closing this issue already? I believe we'd need independent testing first?

[xrviv]

This is my latest build by the way:

[RolandUI]

Hi,

Should we be closing this issue already? I believe we'd need independent testing first?

It was closed automatically by GitHub. Reopened.

cc @luzius1089

[luzius1089]

Sorry @xrviv, my instructions were not clear.

There is a test release here (not an official version, version number was NOT increased, but is it different from the official v2.0.21): https://github.com/luzius1089/GingerWallet/releases/tag/v2.0.21

1. Install that version https://github.com/luzius1089/GingerWallet/releases/tag/v2.0.21 on Windows.
2. Calculate the hash of the release: Get-FileHash 'C:\Program Files\GingerWallet\wassabee.exe' -Algorithm SHA256 => EC8EAD734252B59C2D6155ED7F06723FB4CCA0F3BDA40726959523E3364E6D1A
3. Verify release commit hash =>Go to C:\Program Files\GingerWallet\BUILDINFO.json => GitCommitHash: e524d22035e88f9efd8892b843ac1e0f1b5c3d75
4. Go to C:\temp (or whatever) git init GingerWallet; cd GingerWallet; git remote add origin https://github.com/GingerPrivacy/GingerWallet.git; git fetch --depth 1 origin e524d22035e88f9efd8892b843ac1e0f1b5c3d75; git checkout FETCH_HEAD
5. Create the binaries: C:\temp\GingerWallet\WalletWasabi.Packager> dotnet run -- --onlybinaries
6. Check the hash of the binaries: C:\temp\GingerWallet\WalletWasabi.Packager> Get-FileHash C:\temp\GingerWallet\WalletWasabi.Fluent.Desktop\bin\dist\win-x64\wassabee.exe -Algorithm SHA256 => EC8EAD734252B59C2D6155ED7F06723FB4CCA0F3BDA40726959523E3364E6D1A
7. Hashes are the same

[luzius1089]

Hey @xrviv, just checking in to see if you’ve had a chance to look at this.
Since our last message, a new release has been published — it includes the fixes we discussed.
The build should now produce the same hash as generating it manually from the correct commit using the onlybinaries option in our packager.

[xrviv]

Hi @luzius1089, thanks for checking in and for the detailed reproduction steps.

I'm currently working on automating the reproducible build verification. The key challenge is that
GingerWallet's official releases are built on Windows, so I'm setting up a GitHub Actions workflow
on a windows-latest runner to match the build environment as closely as possible.

The workflow checks out the tagged source, sets up the .NET SDK version from BUILDINFO.json, and
runs dotnet run -- --onlybinaries via the Packager — following the same steps you outlined. I then
download the resulting artifacts and do a per-file SHA-256 comparison against the official release.

I'm currently debugging a NuGet lock file mismatch that causes the Packager's internal dotnet
restore --locked-mode to fail. The lock files differ between Debug and Release configurations, and
the Packager runs its own restore internally. Working through it now.

Will update once the automated verification is producing results against the latest release.