Signal-Desktop: ways to verify build?
Hello!
I would like to install Signal-Desktop. Signal-Desktop itself appears to be free-ish (the sourcecode is available on github + it is released under the AGPL v3). On the download page there is a package source for integration via sources.list. However I would like to make sure that this binary-package is the actual result of the sourcecode and not tampered with. Is there a way to verify this or is compiling the code the only way to make sure the code matches the binary?
Yeah, reproducibility is what can grant you the proof that it is in fact what you are using, aka rebuild from source code yourself ™.
IIRC there are some details where Signal won't allow to change anything from the client (if you were to rebuild from source), otherwise they prevent to connect to their "Signal" network, meaning to install your own Signal server, which can't be called "Signal" because trademark, etc. So, yeah if that matter got some social network relationship status, it would surely be: "It's complicated"
Then again, IIRC that's one of the reasons Debian / Ubuntu / Trisquel have no Signal desktop client in the repos nor F-Droid, but that's a whole different topic.
Here you can check some info about reproducibility at: https://reproducible-builds.org/
And here some of Simon's work related to it on Trisquel: https://blog.josefsson.org/2023/04/10/trisquel-is-42-reproducible/
Regards
Thanks for those insights. Sounds indeed complicated in the case of Signal.
I assume the "Trisquel is 42% reproducible" statement from Simon is due to the limited number of packages he had time/resources to check and not due to inconsistencies between the package contents and rebuilds.
For some reason I assumed that a verification-process was already part of the packagemanaging-process. In case of Trisquel there are other parties like Ubuntu and Debian involved so tampering could theoretically happen on various levels and at any given time. It's good that some progress has been made
to automate reproducability.
"So what causes my rebuilds to be different from the official rebuilds? Some are trivial like the classical problem of varying build paths, resulting in a different NT_GNU_BUILD_ID causing a mismatch. Some are a bit strange, like a subtle difference in one of perl’s headers file. Some are due to embedded version numbers from a build dependency. Several of the build logs and diffoscope outputs doesn’t make sense, likely due to bugs in my build scripts, especially for Ubuntu which appears to strip translations and do other build variations that I don’t do."
https://blog.josefsson.org/2024/07/10/towards-idempotent-rebuilds
In that perspective, 42% sounds quite high.