{{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 applies only if you are going to build {{project_name_short}} from source, and/or redistribute {{project_name_short}}, and/or use Physical Isolation. This is not a {{project_name_short}}-specific problem. Most projects do not even address build anonymity. While building {{project_name_short}}, software must be downloaded. It involves a unique selection of software, making it inherently non-unique. Therefore, your '''i'''nternet '''s'''ervice '''p'''rovider (ISP) could deduce that you are building {{project_name_short}}. This should not be a concern in a free country (free as per your definition) if the content of your traffic is neither observed nor logged.

Especially, but not exclusively, if you intend to redistribute {{project_name_short}}, you might wish to hide the fact that you are building {{project_name_short}} (i.e., maintain anonymity).

To prevent any personally identifiable or fingerprintable information from leaking from the build system into the {{project_name_short}} images, it is recommended to build inside an already torified Virtual Machine. <ref>
Yes, this creates a bootstrap, chicken-or-egg problem. To solve it, you can either download existing {{project_name_short}} binary builds or, if you prefer to build from source, create a minimal torified machine yourself first while routing all network traffic through Tor. </ref> <ref>
{{project_name_short}}’s build process attempts to avoid leaking anything (such as <code>/etc/resolv.conf</code>) from the host system into the VM image. Such a leak would also be a bug hindering the implementation of [https://reproducible-builds.org reproducible builds]. However, in software, nothing can be guaranteed with absolute certainty. Using a VM minimizes this risk.
</ref> 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 it prevents leaks from the build system. Such leaks could help an attacker (with root access to the {{project_name_workstation_short}}) gather identifiable information about the build system, potentially tracing back to your identity.

Beginning with {{project_name_short}} 0.4.0, grml-debootstrap and chroot are used for virtual machine image creation. The grml-debootstrap source code indicates that it copies <code>/etc/network/interfaces</code> and <code>/etc/resolv.conf</code> into the chroot. Additionally, grml-debootstrap mounts several devices (<code>/dev</code>, <code>/proc</code>, etc.) inside the chroot, and the {{project_name_short}} chroot mounts some devices later. This is why it is recommended to build inside an already torified virtual machine.

Building from source code also leaves local traces on the disk, such as the source code itself and build dependencies. If this is a concern, it can be more easily disposed of when contained within a Virtual Machine.

While it is possible to build directly on the host and torify all connections the scripts make, it is unclear what other grml-debootstrap/chroot-related leaks might occur.

It is a known issue that 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]]