{{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. Stuff that is in Debian is perfect.
# Upgrading must not eat up {{project_name_short}} contributor's time to keep {{project_name_short}} maintainable.
# <s>If the applications issues 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 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 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 as if the software was available from packages.debian.org.
* Packaging difficulty.
** For example in 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 as from a third party deb package repository have 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, higher chances.
** Complex software not packaged yet has 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 easy source code that it can be easily reviewed by {{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, if they were compromised, all {{project_name_short}} users would be compromised at once through an malicious upgrade. That's how Debian works. All packages have full system access. No sandboxing.
* no need for 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 vendors website
** no verification of signature from the vendors website
** no upload / install test from developers repository [a broken package could break the whole system, not in malicious ways, but for example broken connectivity that cannot be restored without hacking command into a console]
** no upload / install test from testers repository, have more people try to run into such issues
** no migrate to stable repository
** no remember the state, bug reports, look if it was actually tested of the whole thing
** it is not very difficult technically, but demanding on mental resources and time, without a dedicated release manager, it is better to pick 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 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 intense 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 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 task 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 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 internal updater as well as Tor Browser Updater ({{project_name_short}}) as documented on the [[Tor Browser]] page.

Historically one of the biggest sources of development work because tb-updater broke as Tor Project applied changes to Tor Browser and its download location and therefore also one of the biggest sources of support requests.

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

* Users wouldn't know how it was installed and 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 into <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 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 into instead 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 is made 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 =
<references />
{{Footer}}

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