{{Header}} {{Title|title= Build Anonymity }} {{#seo: |description=Staying anonymous while building {{project_name_long}} from source code. |image=Building-1089861640.jpg }} [[File:Building-1089861640.jpg|thumb]] {{intro| Staying anonymous while building {{project_name_short}} from source code. }} = Build Anonymity = This does only apply, if you are going to build {{project_name_short}} from source, and/or if you are going to redistribute {{project_name_short}} and/or if you are going to use Physical Isolation. This is not a {{project_name_short}} specific problem. Most projects do not even have a chapter about build anonymity. While building {{project_name_short}}, software has to be downloaded. It is a unique selection of software and there is no way to make it non-unique. Therefore your '''i'''nternet '''s'''ervice '''p'''rovider (ISP) could guess, that you are building {{project_name_short}}. This should not be of any concern in a free country (free by your own definition), if the content of your traffic is not being observed or logged. Especially, but not exclusively, in case you want to redistribute {{project_name_short}}, you might be interested to hide the fact, you are building {{project_name_short}} (i.e. you want to stay anonymous). To prevent any kind of personally identifiable or even fingerprintable information leaking from the build system into the {{project_name_short}} images, it is recommended to build inside of an already torified Virtual Machine. Yes, this creates a bootstrap, chicken or egg problem. To solve it you can either download already existing {{project_name_short}} binary builds or if you prefer to build from source, build a minimal torified machine yourself first while running any network traffic over Tor. Any help required with that? [[Contact]] us. See also [[Manually Creating Whonix|Manually Creating {{project_name_short}}]]. {{project_name_short}} build process attempts to not leak anything (such as /etc/resolv.conf) from the host system into the VM image since that would also a bug hindering the implementation of [https://reproducible-builds.org reproducible builds]. However, in software nothing can be guaranteed with absolute certainty. By using a VM, this risk is minimized. You can build {{project_name_short}} inside an existing {{project_name_workstation_long}}, but it can also be built on a headless server. It is also recommended to build in an already torified Virtual Machine, because that prevents leaks from the build system, which could help an attacker (with root access to the {{project_name_workstation_short}}), to gather identifiable information about that build system, that could ultimately lead back to your identity. Beginning with {{project_name_short}} 0.4.0, grml-debootstrap and chroot is being used for virtual machine image creation. The grml-debootstrap source code tells, that it copies /etc/network/interfaces and /etc/resolv.conf into the chroot. grml-debootstrap also mounts a lot devices (/dev, /proc etc.) inside the chroot and later {{project_name_short}} chroot also mounts some devices. That's why it is recommended to build inside an already torified virtual machine. Building from source code naturally also leaves local traces on the disk, such as the source code itself and build dependencies. If that is of concern to you, it can be more easily disposed, when it is contained in a Virtual Machine. It would also be possible to build directly on the host and torify all connections the scripts make, but it is unknown what other grml-debootstrap/chroot related leaks there might be. It is a known issue the build anonymity requires building inside a VM. == VirtualBox inside VirtualBox == See [[Nested Virtualization]]. == corridor-Gateway == [https://github.com/rustybird/corridor corridor, a Tor traffic whitelisting gateway] might be useful. See also [https://lists.torproject.org/pipermail/tor-talk/2014-February/032152.html discussion on the tor-talk mailing list]. = Footnotes = {{reflist|close=1}} {{Footer}} [[Category:Documentation]] [[Category:Development]]