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 [http://bugs.debian.org Debian's], [https://launchpad.ubuntu.com/malone/distros/ubuntu Ubuntu's], and possibly upstream's bug tracking systems must be evaluated.

   • The package should not deal with exotic hardware which we cannot support.

5. Standards compliance: The package should meet the [http://www.pathname.com/fhs/ FHS], [http://www.de.debian.org/doc/debian-policy/ Debian Policy], and (if applicable) the [http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html Debian library packaging guide] standards. Major violations should be documented and justified. Also, the source packaging should be reasonably easy to understand and maintain.

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

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

  • http://people.ubuntu.com/~pitti/ubuntu-cve/unfixed.html

  • http://people.ubuntu.com/~pitti/ubuntu-cve/unchecked.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).