Signal-Desktop: ways to verify build?
- Login o registrati per inviare commenti
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.
Right under these circumstances 42% is indeed very high considering that Ubuntu got only < 10% with debdistrebuild. Thanks for clarifying this prospero.
Meanwhile I looked into the Signal sourcecode and found out that signal-desktop is an electron app which means that the whole app is run within a customized chromium browser. So building this is probably easy (npm install or similar) but I wouldn't recommend installing google/alphabet apps on your system even if they claim it's FOSS if you can avoid it.
> the whole app is run within a customized chromium browser
This is no different from QtWebEngine, which is included in Trisquel.
The main freedom issue with Chromium is that Chromium includes the nonfree version of unrar for use with Google SafeBrowsing. I don't know if Electron uses this component because I haven't looked into it. QtWebEngine and ungoogled-chromium (which is included in Guix), as well as the Debian and Fedora packagings of regular Chromium, build without unrar. Chromium also includes some nonfree files that are part of test suites - none of these are ever run or end up in the actual binaries, but free distributions strip them out of the source package.
As for the privacy issues, QtWebEngine strips out the portions of Chromium that connect to Google services. I believe the same is true of Electron but I haven't checked.
That said, Electron is a resource hog and I prefer to use signald and the Weechat client. I think it's ridiculous to embed an entire web browser for a messaging app.