2 ms·
> One should always assume the encryption is compromised. In commercial applications, yes. In free-software that received audit and is built in a more-or-less
by southerntofu 5y ago
> One should always assume the encryption is compromised.
In commercial applications, yes. In free-software that received audit and is built in a more-or-less reproducible manner, there is less concerns.
I'd have more trust in Conversations.im built by F-Droid.org repository than any proprietary messenger, for example.
- shapefrog 5y agoI love it when the veil slips and 'open source purists' show they are really about it just being free.
- deleted 5y ago[deleted]
- southerntofu 5y agoSo one commenter here said that was nearly not enough, but the comment has been deleted since then. Here's my answer anyway: I agree with your point. You'll see in my previous comment i never said such a solution was secure, just that it has "less concerns" and therefore i have "more trust". But i would rather not place my life in the hands of ANY KIND of software, or hardware that's beyond my mechanical comprehension. In the case of OpenSSL, nobody had dared to even look at the code maintained by a single person. That's a huge problem. That code is not reproducible is another huge problem. It's also a huge problem that even when it is reproducible you don't have a convenient way to bootstrap the environment, to automatically audit code signatures (PGP) on the repository, and to compare checksums with another build environment. The GNU/guix project is addressing all these issues. Their blog is full of good stuff about their work on bootstrap seeds, on their new "guix git authenticate" command which follows a "channel introduction" to validate signatures on the repo, and with "guix challenge" command to compare build output from several repositories. Exciting days ahead of us!