search

amnezia-vpn / amnezia-client

Amnezia VPN Client (Desktop+Mobile)
https://amnezia.org
GNU General Public License v3.0
5.3k stars 329 forks source link

(Question) Why the 3rd-party binaries for Linux? #1027

Closed zimbabwe303 closed 1 month ago

zimbabwe303 commented 1 month ago

Hello! I can build amnezia-client alright on my Debian system, but what makes me somewhat uncomfortable is that I have to trust the 3rd-party binaries included with the source code. I don't see anything special there which is not included in the official Debian repositories, only libssh, openssl and openvpn, all of which are regularly updated by the Debian team to the latest versions. As far as I know the same applies to Ubuntu. Then why the binaries? Are they patched? Then where are the sources of the patches? How can I avoid using anything besides the source code to build amnezia-client?

tannisroot commented 1 month ago

You can alternatively use amneziawg, their fork of wireguard

SergeiMinaev commented 1 month ago

I tried to run precompiled linux client, but the binary asked for the root password (again) without providing any info about what would happen if I continued. And now I've learned about precompiled libssl, libcrypto etc even in "open sourced" version. That's shady.

pokamest commented 1 month ago

You can find build pipelines here - https://github.com/amnezia-vpn/3rd-build-ga/tree/master/.github/workflows All binaries equipped with sha256 hash, you can compare hashes on GitHub actions and from bundled binaries. Anyway, the project was audited by 7ASecurity.

I don't see anything special there which is not included in the official Debian repositories, only libssh, openssl and openvpn, all of which are regularly updated by the Debian team to the latest versions. As far as I know the same applies to Ubuntu. Then why the binaries?

Feel free to develop solution (Ubuntu, Debian and CentOS support required), test it on most popular distros, and make pull request ))

zimbabwe303 commented 1 month ago

Yeah... When binaries are distributed alongside an open-source project there could be two diametrically opposite reasons for doing so:

  1. Benevolent: providing the verified versions which have undergone security audit
  2. Malevolent: providing the patched versions with backdoors included

The sha256 hashes are a good reason to think the first was the reason but still why no explanation was given anywhere in the docs or in README.md? One more thing: GitHub workflows is far from the best way to make reproducible builds to check against the hashes, it's convenient for developers but not for the users. How about a script instead?