Security

The Termux team takes all security vulnerabilities seriously and we encourage external parties and users to report them. We are also a strong believer of security-through-transparency and we publicly disclose all vulnerabilities that our own team finds or are reported by others as per responsible disclosure timelines.

 

Timeline and Disclosure Policy

  1. Once the report sent to us by an external party has been received, it will be triaged by our team to see if it is valid and what its impact is. It will normally be acknowledged within 3 business days if valid and will then be assigned to a maintainer who will handle the communication with the reporter and coordinate the deployment of fixes and the vulnerability disclosure.
  2. We will normally deploy fixes for the security vulnerability within 90 days. However, if the vulnerability is being actively exploited, then we aim to deploy fixes within 7 days.
  3. After the fixes have been deployed and available to users, the vulnerability report will be disclosed publicly after 30 days on GitHub security advisories and/or on our Termux site posts.

 

Acknowledgement and Rewards

The first entity who reports the vulnerability to us, whether they are in our own Termux team or are an external party, only they will be acknowledged and/or rewarded, depending on if they want to be acknowledged and under what name and link they want to be acknowledged with.

If the vulnerability exists only in older versions than the currently latest version, or if the vulnerability had already been fixed in the public/private git repository before the report was submitted, or if the vulnerability has already been reported or discovered by the maintainers but not yet fixed, then acknowledgements may not be given.

As for rewards, we currently do not have a rewards program, as all Termux services are primarily provided for free (beer) to our users and our Donations are rather limited and do not even cover the development costs itself of our entire team. However, for severe vulnerabilities, we may make an exception and pay out a token reward from our Open Collective, depending on our budget.

The security impact (and any potential reward) is judged based on the actual reported impact of the vulnerability, and not on a potential impact of the vulnerability. Vulnerabilities without a valid attack scenario are not accepted.

 

What To Include in the Report

When reporting, the following things must be considered.

A good quality report has all the relevant details for the security vulnerability and has the following characteristics:

Additionally:

 

Where To Report

Security vulnerabilities can be reported in two ways:

  1. GitHub Security Advisories is the the preferred way to report security vulnerabilities as it is the standard way for open source projects and allows multiple people to securely and privately collaborate on a fix, and our dependents and forks can be notified of the security vulnerabilities as well once it is published.

    You can use the Security tab of the affected repository to report the vulnerability. Check GitHub docs for more info on how to report.

    Note that normal bugs are not security vulnerabilities, and must not be reported to GitHub Security Advisory and instead should be reported as an Issue to its respective repository. Sending repeated non-security bugs to GitHub Security Advisory or sending spam to it will result in a ban.

  2. Emails can also be sent to one or more maintainers that (seem to) maintain the affected component, as listed after the repository links in sections below, or as per git history or CODEOWNERS file. Emails should preferably be gpg encrypted to maintain confidentiality from people who may have access to the intermediate mail servers. You can find the public gpg keys of our common maintainers in the termux-keyring package or at the https://github.com/<username>.gpg URL. If the gpg key is not available for any maintainer who is responsible for the affected component, you may send an unencrypted report, or preferably email an encrypted report to @agnostic-apollo ([email protected]) or @Grimler91 ([email protected]), whose keys are available.

 

The following lists the most popular and critical Termux repositories and their maintainers. You may email the respective maintainers if you want to report a vulnerability and cannot use GitHub security advisories, or if private questions/support/discussion is required. For the repositories below that are maintained by the "Termux team", either email to the maintainer that maintains the affected component as per git history or CODEOWNERS file, or email to @agnostic-apollo or @Grimler91.

Termux Apps

Termux Packages Build and Repository Infrastructure

If you have found a security issue in a specific external package not developed by Termux itself, for example openssh, and the issue can be reproduced in non-termux installations as well, then the issue should be reported to the upstream maintainers as well.

Termux Internal Packages

Termux Site