{{Header}}
{{title|title=
{{project_name_long}} Default Application Policy
}}
{{#seo:
|description=Design Documentation - How to decide which apps come with {{project_name_short}}?
}}
{{intro|
Design Documentation - How to decide which apps come with {{project_name_short}}?
}}
= How to decide which apps come with {{project_name_short}}? =
== if available from packages.debian.org ==
Overall goal: avoid jeopardizing the project due to criticism from The Tor Project and/or technical communities based on questionable decisions.

The following points are not listed by priority, only for reference. '''These are not set in stone!'''

=== Important, hopefully mostly objective, requirements: ===

# There must be a reliable upgrade path. Software available via packages.debian.org is ideal.
# Upgrading must not consume significant time from {{project_name_short}} contributors, in order to keep the project maintainable.
# <s>If the application generates network activity, there must be a way to properly configure it for [[Stream Isolation]], to keep Tor's TransPort clean for the user's own connections.</s> ([https://forums.whonix.org/t/should-strict-stream-isolation-by-a-requirement-in-whonixs-default-application-policy/3940 Deprecated])
# When downloading applications, especially over Tor, strong digital signature verification must be supported (e.g. OpenPGP, as used by APT), or the download process must be so simple that trusted developers can easily audit the code for malicious intent.
# Must be Tor-safe. (Definition: must not be fully [[Tips_on_Remaining_Anonymous#Do_not_confuse_Anonymity_with_Pseudonymity.|pseudonymous]]. No significant protocol leaks. For instance, Tor Browser is preferred over Firefox.)
# Must be Freedom Software / Open Source.
# Must not pose a major security risk.
# Must not perform network activity when the application is not in use.
# Installing or modifying the application must not overshadow discussions about {{project_name_short}} with controversies related to that application. (Example: [[FAQ#Does_{{project_name_short}}_Modify_Tor.3F|No Tor modifications.]])
# Its default inclusion in {{project_name_short}} must not cause serious issues with The Tor Project.

=== Less important, hopefully mostly objective, requirements: ===

* We believe a fair number of users appreciate it.
* We believe it is usable by a fair number of users.
* A mature, responsive upstream is required, unless the application/script is trivial and easy to maintain.

=== Contradictions and subjective influences: ===

* Perfectly logical, rational, consistent decisions are not always possible.
* Discussions about default installed applications often fall into [https://forums.whonix.org/t/law-of-triviality-bikeshed/6739 law of triviality / bikeshed].
* The final selection reflects the preferences of the [[Contributors|contributors of Whonix]].
* Requests from {{project_name_short}} supporters carry more weight relative to their contributions.
* There is some level of arbitrariness involved.
* Disagreements are natural. There are hundreds or even thousands of [https://en.wikipedia.org/wiki/Linux_distribution Linux distributions]. See [https://upload.wikimedia.org/wikipedia/commons/1/1b/Linux_Distribution_Timeline.svg this diagram] for an overview of [https://en.wikipedia.org/wiki/Fork_(software_development) software forks]. As a distribution grows in popularity, disagreements and forks become more likely.

Including software that must be manually installed by default would be highly problematic, for reasons explained in the [[#Others|relevant chapter]].

=== Examples: ===

a) There is no torrent client installed by default in {{project_name_short}}, because none are known to fulfill point number 3. If one that does becomes available, this issue should be raised on the tor-talk mailing list to seek an official stance, due to [[File_Sharing#Updates|previously conflicting statements]], in line with requirement 10.

== if not available from packages.debian.org ==
The conditions from chapter [[#if available from packages.debian.org]] apply. In addition, the following conditions must also be met:

* Requires few (security) updates. Must have low maintenance overhead and must not consume {{project_name_short}} contributor time needed to keep the project maintainable.
* Must demonstrate significantly higher popular demand compared to software available from packages.debian.org.
* Packaging difficulty is a key consideration.
** Example: For [[electrum]], an AppImage was available, which is a self-contained binary independent of system dependencies. This made it technically easy to add.
** Slightly less likely but possible: Applications from a trusted third-party .deb package repository.
** Slightly less likely but possible: Software available for direct .deb package download.
** Dependencies: Software with complex or demanding dependencies is less likely to be included. Simpler, more forgiving dependencies increase the chances.
** Complex software not yet packaged has the lowest chance of being included.
* Security: Upstream developers must digitally sign their software (i.e., support [[Verifying Software Signatures]]). An exception may be made for software with minimal or simple source code that can be easily reviewed by the {{project_name_short}} project.

See also the [https://github.com/Kicksecure/binaries-freedom <code>binaries-freedom</code>] package and the related forum discussion: [https://forums.whonix.org/t/policy-for-inclusion-of-compiled-software/6635 Policy for Inclusion of Compiled Software].

= Package Origin =
{{Anchor|Binary Software}}
== Compiled Software ==
{{Anchor|From APT Package Source}}
=== From APT Package Sources ===
==== packages.debian.org ====
<code>packages.debian.org</code> gives us:

* Always stable, not breaking stable, a contributor testing the package with Debian.
* Some vetting that the package does not contain an obvious backdoor.
* Easily installable without much long-term time sunk from developer side, just add once to anon-meta-packages and be done with it.
* No extra repository signing keys (that have the ability to replace any package on the system). If we theoretically added something like deb.gnunet.org, and it was compromised, all {{project_name_short}} users would be compromised at once through a malicious upgrade. That's how Debian works. All packages have full system access, with no sandboxing.
* No need to follow up on security issues of the package, no quick security fix uploads, all done by Debian.
* No time sunk as in reuploading new packages to <code>deb.whonix.org</code>.
** No download from the vendor's website.
** No verification of signature from the vendor's website.
** No upload/install test from developer's repository (a broken package could break the whole system, not in malicious ways, but for example broken connectivity that cannot be restored without hacking commands into a console).
** No upload/install test from tester's repository, allowing more people to run into such issues.
** No migration to stable repository.
** No need to remember the state, bug reports, or check if it was actually tested in the whole process.
** While technically not very difficult, it is demanding on mental resources and time. Without a dedicated release manager, it is better to pick fewer "special" packages from other sources than packages.debian.org.

==== deb.torproject.org ====
The <code>tor</code> <ref>binary and source package</ref> package is downloaded from <code>deb.torproject.org</code> and uploaded to <code>deb.whonix.org</code> by {{project_name_short}} developers. <ref>
Function <code>get_tpo_packages</code> in https://github.com/{{project_name_short}}/derivative-maker/blob/master/build-steps.d/2100_create-debian-packages
</ref> Reasons:

* One of the most crucial components of {{project_name_short}}.
* Compatibility with latest stable version of Tor Browser. Why compatibility with Tor Browser is a goal is documented in [[Dev/Default_Application_Policy#dist.torproject.org|this chapter]].
* [[Dev/Tor#Tor_Version|Other reasons]].

A maintenance-intensive task.

{{Anchor|From Non-APT Package Source}}

=== From Non-APT Package Sources ===
==== Summary ====
There are issues with security as well as maintenance overhead.

Security issues are mentioned in chapter [[Install_Software#Best_Practices|Best Practices]] which include:

* Prefer APT
* Avoid Third Party Package Managers
* Avoid Manual Software Installation
* Always Verify Signatures
* Prefer Packages from Debian Stable Repository

All of the above are explained in greater detail in chapter [[Install_Software#Best_Practices|Best Practices]].

==== dist.torproject.org ====
'''Tor Browser'''

Anonymous web browsing is one of the most, if not the most, popular tasks when using {{project_name_short}} or Tor. For usability and crucial anonymity reasons, it is required to easily make the latest stable version of Tor Browser available in {{project_name_short}}. The [[Tor Browser]] page describes this in greater detail. Due to issues outside of the control of {{project_name_short}}, there is no APT package source providing Tor Browser. See this [[Tor_Browser/Advanced_Users#Linux_Generally|chapter]] for more details on that.

Therefore [https://github.com/Kicksecure/tb-updater tb-updater] is being used to install Tor Browser by default in {{project_name_short}} from <code>dist.torproject.org</code>.

It can be easily kept up to date by Tor Browser's internal updater as well as Tor Browser Updater ({{project_name_short}}), as documented on the [[Tor Browser]] page.

Historically, this has been one of the biggest sources of development work because tb-updater broke as Tor Project applied changes to Tor Browser and its download location, making it one of the biggest sources of support requests.

==== Others ====
Installing software other than Tor Browser (as documented above) from non-APT package sources by default would be a nightmare, because:

* Users wouldn't know how it was installed and would not update it.
* Updating would be left to the user.
* It is better if the whole process of download, verification, install, upgrade notification, and upgrade is up to the user.

Experiences made with tb-updater and Tor Browser (see above chapter) further discourage this.

=== Shipping Compiled Software in Binary Packages ===
Forum discussion: https://forums.whonix.org/t/policy-for-inclusion-of-compiled-software/6635

Currently:

* none

Future candidates for inclusion in <code>binaries-freedom</code> package:

* https://git.openprivacy.ca/cwtch.im/cwtch/issues/314
* https://git.openprivacy.ca/cwtch.im/cwtch/issues/312
* https://github.com/HelloZeroNet/ZeroBundle/issues/17

== Source Package ==
=== Uploading Source Packages to deb.whonix.org ===
Usability-wise, not very useful. Users could download and compile source packages. As far as I know, there is no install/upgrade mechanism for source packages. Even if there was, they would not auto compile and upgrade. Would require quite some documentation: `apt source pkg-name`, `cd pkg-name`, install build dependencies, install dependencies, build, install. More support overhead. Plus almost the same issues as for binary packages.

== guix ==

GNU Guix is a compromise between tracking/maintaining the dependency hell of a non-Debian program or completely excluding them for that reason.

By including and maintaining Guix as a gateway, we cut down the effort needed to obtain external programs for us and for the program devs too.

Brief Intro:
In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection (more details in the manual). <ref>
https://lists.gnu.org/archive/html/gnu-system-discuss/2012-11/msg00000.html
</ref>

'''Where to download? How to verify? How to install? (Any compilation required?)'''

Download here:
https://www.gnu.org/software/guix/download/

Verification and install instructions:
https://guix.gnu.org/manual/en/html_node/Binary-Installation.html

No compilation required. A signed binary tarball is distributed. The binary installation tarball can be (re)produced and verified simply by running the following command in the Guix source tree:

<pre>
make guix-binary.system.tar.xz
</pre>

Full manual:
https://www.gnu.org/software/guix/manual/guix.html

There is also an installation script:

https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh

At time of writing, the installation script does not pass the {{TUF3}} threat model. <ref>
{{TUF}}
</ref> <ref>
The following source code using gpg for verification of software signature is vulnerable to rollback attacks and indefinite freeze attacks.

<pre>
    gpg --verify "${bin_ver}.tar.xz.sig" >/dev/null 2>&1
    if [[ "$?" -eq 0 ]]; then
        _msg "${PAS}Signature is valid."
        popd >/dev/null
    else
        _err "${ERR}could not verify the signature."
        exit 1
    fi
</pre>

See also [https://github.com/Kicksecure/gpg-bash-lib gpg-bash-lib].

The installation script is also vulnerable to endless data attacks and slow retrieval attacks.

Minor: It uses wget, which has a [https://lists.gnu.org/archive/html/bug-wget/2012-07/msg00015.html buggy TLS certificate verification] instead of [[Secure_Downloads|secure curl]].
</ref>

'''Installable from packages.debian.org using APT?'''

Not yet. Maybe in Debian <code>bullseye</code>:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850644#95

https://packages.debian.org/experimental/guix

'''Any ready-made repositories available that we can start using? Like, if one manages to install Guix on Debian or {{project_name_short}}, what packages can be installed? How does that work in practice?'''

The Guix library consists of ~5K packages. They carry Libre packages only:
https://www.gnu.org/software/guix/packages/

Packages are installed with:

<pre>
guix package -i hello
</pre>

'''Any onion repositories?'''

No. I think they might be open to running one. I can talk with them and the Tor people to make it happen.

Update: Planned with serious discussions happening around this topic.
https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00189.html

'''Does it pass TUF's threat model?'''

Not yet, but being worked towards and should be there by v.1.0

https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00192.html

Update: Was this done?

'''Socks proxy support or can torsocks work?'''

Package configuration definitions include support for defining network access including redirecting traffic to Tor. Manual example:

Scheme Procedure: tor-service [config-file] [#:tor tor]

    Return a service to run the Tor anonymous networking daemon.

    The daemon runs as the tor unprivileged user. It is passed config-file, a file-like object, with an additional User tor line and lines for onion services added via tor-hidden-service. Run man tor for information about the configuration file.

https://www.gnu.org/software/guix/manual/guix.html#Networking-Services

'''How does its sandboxing work and why is it secure?'''

Not sandboxing as in Apparmor isolation but the ability to build/install/upgrade software without requiring root ever. Guix packages can also be shared among unprivileged user profiles.

'''Any example packages?'''

There is the hello package as an example or any of the ones listed in the directory mentioned above(?)

Info on making packages:

https://www.gnu.org/software/guix/manual/guix.html#Packaging-Guidelines

'''How to create a repository?'''

In the manual there is support for fetching source from git repositories and building that. So potentially any git repo can act as a decentralized package hosting. Edit: I can confirm that all packages in their package list are indeed git repos hosted on savannah.

All packages and their dependencies are available in the Guix main collection.

Interesting reading:
https://arxiv.org/pdf/1305.4584.pdf

= Footnotes =

= Footnotes =
<references />
{{Footer}}

[[Category: Design]] [[Category: Development]]