{{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: not killing the project for being badmouthed by The Tor Project and/or geeks due to bad decisions.

The following numbers are not referring to priorities, just to reference them. '''Not written in stone!'''

Important hopefully mostly objective requirements:

# There must be a reliable upgrade path. Software that is in packages.debian.org is perfect.
# Upgrading must not eat up {{project_name_short}} contributor's time to keep {{project_name_short}} maintainable.
# <s>If the applications 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 stuff.</s> (https://forums.whonix.org/t/should-strict-stream-isolation-by-a-requirement-in-whonixs-default-application-policy/3940 Deprecated)
# When downloading applications, especially since downloads run over Tor, strong verification must be supported (Ex: OpenPGP, APT does that well) or be so trivial that some trusted devs can audit the code for being not intentionally malicious.
# Must be Tor-safe. (Definition: must not be totally [[Tips_on_Remaining_Anonymous#Do_not_confuse_Anonymity_with_Pseudonymity.|pseudonymous]]. No major protocol leaks. For example, using Tor Browser instead of Firefox.)
# Must be Freedom Software / Open Source.
# Must not be a total security disaster.
# Must not issue network activity while the application is not in use.
# Installation/modification must not limit discussion about {{project_name_short}} to the controversy of that application. (Ex: [[FAQ#Does_{{project_name_short}}_Modify_Tor.3F|No Tor modifications.]])
# Installing it by default in {{project_name_short}} must not totally f*ck up The Tor Project.

Less important hopefully mostly objective requirements:

* We must believe that a fair amount of users likes it.
* We must believe that it is usable by a fair amount of users.
* Mature behaving and communicative upstream, not important if the application/script is trivial and maintenance is simple.

Contradictions and subjective influences:

* It's not possible to have perfectly logical, rational, consistent decisions.
* Discussions on default installed applications are prone to [https://forums.whonix.org/t/law-of-triviality-bikeshed/6739 law of triviality / bikeshed].
* Selection is a shadow of the preference of the [[Contributors|contributors of Whonix]].
* Requests by supporters of {{project_name_short}} weight higher in relation to their contribution.
* A degree of arbitrariness.
* Disagreements are to be expected. There are hundreds or 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 image] to get a feeling on how many [https://en.wikipedia.org/wiki/Fork_(software_development) software forks] exist. With the growth of popularity of a Linux distribution, it is to be expected that disagreements arise and forks happen.

Manually installed by default software would be a nightmare for reasons explained in [[#Others|this chapter]].

Examples:

a) There is no torrent client installed by default in {{project_name_short}}, because we know of none that fulfills point number 3. If one has been found, this topic has to be brought up on tor-talk mailing list, asking for their official position, due to [[File_Sharing#Updates|contradictory prior statements]] to fulfill 10.

== if not available from packages.debian.org ==
The conditions from chapter [[#if available from packages.debian.org]] apply. On top of these, the following conditions apply.

* Few (security) updates required. Low maintenance overhead. Must not eat up {{project_name_short}} contributor's time to keep {{project_name_short}} maintainable.
* Much higher requirement in popular demand compared to if the software was available from packages.debian.org.
* Packaging difficulty.
** For example, in the case of [[electrum]], an AppImage was available, which is a self-contained binary independent from any other dependencies on the system. Technically easy to add.
** Less but still a chance: Applications available from a third-party deb package repository have a higher chance.
** Less but still a chance: Software that is available for direct deb package download.
** Dependencies: The more complicated/unforgiving the dependencies are, the less likely. The less picky dependencies, the higher the chances.
** Complex software not packaged yet has the smallest chances of inclusion.
* Security: Upstream developers must digitally sign their software (therefore support [[Verifying Software Signatures]]). An exception could be made for software that has so little or so simple source code that it can be easily reviewed by the {{project_name_short}} project.

See also package [https://github.com/Kicksecure/binaries-freedom <code>binaries-freedom</code>] and 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]]