suite-desktop produces different sha256 of that on website and stuck in "dev" build.

[0xNegnin]

sha256sum < curl -L -O https://github.com/trezor/trezor-suite/releases/download/v23.12.3/Trezor-Suite-23.12.3-linux-x86_64.AppImage
Produces
1c05d9a46cf58cd5c7e2596004c933db75bf981834c0d37961428f7077b856ae

Yet when compiling from source with:
git clone https://github.com/trezor/trezor-suite.git
cd trezor-suite
git checkout v23.12.3
yarn && yarn build:libs
yarn workspace @trezor/suite-desktop build:linux

Produces a different hash for sha256sum ./packages/suite-desktop/build-electron/Trezor-Suite-23.12.3-linux-x86_64.AppImage every time.

Also, running Trezor-Suite-23.12.3-linux-x86_64.AppImage shows in the window title that its 'dev', but yet in package.json it shows that NODE_ENV="production" so why doesn't it build in a production envrironment?

[MiroslavProchazka]

Hello @0xNegnin,

yarn workspace (@trezor/suite-desktop build:linux) gives you dev build, which is not exactly the same as production. The differences are minor. You can find more on this topic in this closed issue.

[0xNegnin]

Hi @MiroslavProchazka,

Yes looking through the code I saw that you could manually set IS_CODESIGN_BUILD to true in an environment variable to use the product public key. However this isn't the answer to the issue, no one except the Trezor team is able to produce a binary that has a sha256 which matches the one on the website, which means no one in the public knows how you've compiled your binary and if there is anything additional or removed. The Trezor Suite binaries need to be reproducible so anyone can verify the repo indeed used to build the binary, why should users have to trust Trezors signed binary if no one can reproduce it?

[0xNegnin]

@matejkriz Neither thread ended with a real resolution, is anything going to be changed so that the public can reproduce an exact binary for Trezor Suite? with IS_CODESIGN_BUILD we can't yarn build:libs only yarn workspace @trezor/suite-desktop build:linux after building libs with the dev private key. Why does the build process include steps which make it so that no one can reproduce the same binary anyway?

[komret]

@0xNegnin Unfortunately, I don't think there is a way anyone can produce a binary with the same hash unless we reveal the signing key to them. It is possible to compare the source codes or build Suite locally to eliminate trust.

[0xNegnin]

@komret Currently even if we do have the signing key this repo still produces a different hash for the output every time. Right now the public is using the dev signing key in the repo and we still get non deterministic build hashes.

Why do we even need Trezor's signing key to build:libs and build:?

[komret]

You are right that the build is not fully deterministic. Looks like it is quite a common issue with Electron apps.

One of the private keys is required for build:libs for the message system so that Suite can verify that the message was signed by Trezor. This signed message is part of Suite build in order to work offline. And it is one of the (probably many) reasons why the hashes are different.

[0xNegnin]

You are right that the build is not fully deterministic. Looks like it is quite a common issue with Electron apps.

One of the private keys is required for build:libs for the message system so that Suite can verify that the message was signed by Trezor. This signed message is part of Suite build in order to work offline. And it is one of the (probably many) reasons why the hashes are different.

Could we at least acknowledge this as an issue then? I don't know why @MiroslavProchazka was so quick to close this off. Not saying this can be solved overnight but we need to at least have this as a future goal.

[MiroslavProchazka]

Hey, thanks for pushing this through.
I will leave this issue open so we can get back to it once we will solve higher priority issues (product roadmap etc).
Thanks for your insight.

[0xNegnin]

This needs to be prioritized after a point, it's been 2 years and Trezor refuses to make reproducible builds? Isn't this company supposed to be about security first? @MiroslavProchazka

[komret]

We encourage anyone to submit a pull request addressing the issue, that's the best thing you can do to help us resolve it.