E2E encryption in closed source automatically updated programs doesn't provide any real assurance: whoever makes the program can subvert your privacy at any time.
Do you trust the author of the program? Then E2E doesn't add much. Do you not trust the author of the program? E2E doesn't help. Either way, what's the point? Sure, I guess E2E provides some kind of additional privacy at the margin or something, but you can't rely on it for anything.
Are you verifying that all your OSS binaries you’re running match a reproducible build hash that’s been validated by multiple trusted sources? If not, you’re already engaging in a level of trust.
The real question is how do you establish trust in the code you run and while OSS provides benefits at the margin or something, you can’t really rely on it for anything.
For an example to illustrate the fallacious reasoning of OSS = trust, consider the malicious compiler that Ken Thompson presented[1].
Not GP, but: although I'm not currently doing this consistently (I don't have the resources to set up build servers and there aren't many build servers for my distro yet) the distro I use does make it pretty straightforward to do this: https://guix.gnu.org/manual/en/html_node/Invoking-guix-chall...
If I want to do this for any particular package as a one-off, it's two commands.
Reproducible builds are a step up but remember that it requires you to build with the exact same binary-identical toolchain. If that’s already compromised your guix challenge isn’t really doing anything of value.
Again, I’m not saying these aren’t valuable things that make attacks more difficult/expensive but the uncomfortable truth is we haven’t figured out how to truly establish zero-knowledge trust. So on that spectrum, ultimately Guix + OSS is closer to WhatsApp than where we’d like to be.
I mean, sure, we're not there yet. If the Guix folks are able to get a bootstrap path going all the way from something like stage0, though, we'll be in a pretty good place I think: http://bootstrappable.org/projects/mes.html
Maybe the current state is closer to WhatsApp than where we'd really like to be, but that should be a challenge rather than a reason to give up.
Never said anyone should give up but my point is that to my knowledge there's no actual proof of how to solve this. We're just stumbling in the dark trying ideas.
I'm curious if you've actually had a chance to read Ken Thompson's compiler virus hack. The Guix bootstrap path from stage0 still doesn't solve the problem as at the end of the day all compilers eventually self-host from a previous version. So whatever compiler you're using for stage0 can have the virus, inject it into the produced binary, & you'll never find it since the virus is in the binary not in the source. Now obviously this is an extreme example and no one actually has any knowledge of whether or not such attacks are practical or have existence proofs beyond a proof of concept.
My overall point though is that everything boils down to trust & the question is who you choose to trust & where. Ultimately, we're all "careless" on that front as there's just too many dimensions to evaluate on. Beyond just basic malware packaged with the code, is the privacy being respected? Are the security practices good enough to withstand attacks? etc etc. Complaining that WhatsApp is slurping a copy of your messages that you are reporting to them & therefore E2E encryption isn't valuable is a fallacious & misdirected argument IMHO.
>The Guix bootstrap path from stage0 still doesn't solve the problem as at the end of the day all compilers eventually self-host from a previous version. So whatever compiler you're using for stage0 can have the virus, inject it into the produced binary, & you'll never find it since the virus is in the binary not in the source.
The point of stage0 is that it doesn't need to be compiled, only assembled, and that it's small enough to inspect the binary or assemble it by hand if you really wanted to. (Not that you necessarily want to, but if you have to...)
Are you referring to https://github.com/oriansj/stage0? This stage0 gets you a basic C compiler. An impressive achievement for sure. I don’t see how it really solves anything though.
More generally each language would need it’s own path from this basic assembler to a compiler implementing that language in C which doesn’t necessarily exist. While initial versions of the Rust compiler were written in C, more recent versions are self hosted and rely on the previous version. This goes for projects like LLVM too since it requires a c++14 compiler to start with.
A better approach is to figure out how to cross compile stage0 and how to make sure the cross compilation step can be trusted. Going the approach of trying to build a “trusted” path from source is noble but IMO ultimately futile.
This is what I mean when I say this as an unsolved problem. It may be getting better but there are fundamental unsolved challenges to this exploration and very little guarantee the task can be accomplished in the first place (ie no mathematical theory that might present a path to follow rather than just trying to accomplish it through sheer effort). Some small part of the problem might get solved but that’s very different from saying that any package will be verifiable in this way.
Yep, that's the one.
>More generally each language would need it’s own path from this basic assembler to a compiler implementing that language in C which doesn’t necessarily exist. While initial versions of the Rust compiler were written in C, more recent versions are self hosted and rely on the previous version. This goes for projects like LLVM too since it requires a c++14 compiler to start with.
Sure. This part has largely been done for many languages, including Rust: https://guix.gnu.org/blog/2018/bootstrapping-rust/
...and there's a bootstrap path for the bottom of that graph all the way from Guix's (fairly minimal but not quite stage0 yet) bootstrap binaries. LLVM too; since you mentioned it and I was curious, here's the dependency graph of LLVM 9.0.1 on my system, in GraphViz and PDF formats:
https://terracrypt.net/upload/llvm.pdf https://terracrypt.net/upload/llvm.dot
(That's from `guix graph -t bag-with-origins [email protected]` on my laptop.)
It's my understanding that being bootstrappable in this way is a requirement for being included in upstream Guix, so generally everything that's available in Guix can be bootstrapped like this.
Now, what's not done yet is the path from stage0 to building the bootstrap binaries, but that's the eventual goal. The rest of it? It's not futile, it's done. Not all software is in Guix, but enough of it is that I'm typing this from a laptop running almost exclusively software from Guix.