Promoting a package into main

Scope

This document describes the requirements for a package to be considered for inclusion into the supported set of Ubuntu packages (into main), which entails that this package receives the full scope of security and QA support.

The MainInclusionProcess page describes the steps of the process.

Requirements

The package must fulfil the following requirements:

1. Availability: The package must already be in the Ubuntu universe, and must build for the architectures it is designed to work on.

2. Rationale: There must be a certain level of demand for the package, for example:

   • The package is useful for a large part of our user base.
   • The package is a new build dependency or dependency of a package that we already support.
   • The package replaces another package we currently support and promises higher quality and/or better features, so that we can drop the old package from the supported set.

3. Security: The security history and the current state of security issues in the package must allow us to support the package for at least 18 months without exposing its users to an inappropriate level of security risks. This requires checking of several things that are explained in detail in the subsection Security checks.

4. Quality assurance:

   • After installing the package it must be possible to make it working with a reasonable effort of configuration and documentation reading.
   • There are no long-term outstanding bugs which affect the usability of the program to a major degree. To support a package, we must be reasonably convinced that upstream supports and cares for the package.

   • The status of important bugs in Debian's, Ubuntu's, and possibly upstream's bug tracking systems must be evaluated.

   • The package should not deal with exotic hardware which we cannot support.
   • Nontrivial packages need maintenance commitment from an Ubuntu developer or team.

5. UI standards:

   • End-user applications must be internationalized (translatable), using the standard intltool/gettext build and runtime system and produce a proper PO template during build.
   • End-user applications must ship a standard conformant desktop file.

6. Standards compliance: The package should meet the FHS, Debian Policy, and (if applicable) the Debian library packaging guide standards. Major violations should be documented and justified. Also, the source packaging should be reasonably easy to understand and maintain.

7. Dependencies: Any build or binary dependencies which are not yet in main.

8. Maintenance: The package must have an acceptable level of maintenance corresponding to its complexity. Simple packages (e.g. language bindings, simple Perl modules, small command-line programs, etc.) might not need very much maintenance effort. More complex packages will usually need a developer or team of developers paying attention to their bugs, whether that be in Ubuntu or elsewhere (often Debian). Packages that deliver major new headline features in Ubuntu should have Ubuntu developers willing to spend substantial time on them.

Security checks

• Check how many vulnerabilities the package had in the past and how they were handled by upstream and the Debian/Ubuntu package:

  • http://cve.mitre.org/cve/ -> search for the package as a keyword

  • http://secunia.com/products

  • Ubuntu CVE Tracker

    • http://people.ubuntu.com/~ubuntu-security/cve/main-all.html

    • http://people.ubuntu.com/~ubuntu-security/cve/universe-all.html

    • http://people.ubuntu.com/~ubuntu-security/cve/partner-all.html

• Check for security relevant binaries. If any are present, this requires a more in-depth security review.

  • Executables which have the suid or sgid bit set.

  • Executables in /sbin, /usr/sbin.

  • Packages which install daemons (/etc/init.d/*)

  • Packages which open privileged ports (ports < 1024).