Goal

Snaps represent a new way of building packages that work across multiple versions of Ubuntu, with reduced barriers to entry for upstream and community developers. By design, the snapcraft tooling imposes very little packaging policy to avoid also introducing friction. Snaps deal with integration through confinement and isolation rather than through shared policy.

As more software becomes available as snaps, we want to take advantage of this body of packages as part of the default Ubuntu experience. Maintaining the Ubuntu community’s commitments around this default experience means reintroducing policy on top of snaps. This document is an attempt to translate existing committments for the Ubuntu 'main' archive to the new world of the Snap Store.

The key commitments that we make to software installed by default in Ubuntu are that:

The license of the software is known, and non-free software can be excluded with a single decision by the user at install time
Packages have been built on trusted infrastructure by Canonical
Packages will receive the standard, free, five-year LTS maintenance commitment from Canonical (or nine months for non-LTS releases)

Channel availability

Including software in the default install of Ubuntu implies a certain commitment to handle upgrades cleanly and to provide continuity of behavior across updates within the stable release. The best way to ensure this commitment holds true in the snap case is to only include snaps that come from the stable channel.

As a side effect, since devmode snaps may not be published to the stable channel, only strict and classic confined snaps may be included.

Snaps included in images will be installed referencing a per-Ubuntu-series branch following the name format ubuntu-$version (e.g.: ubuntu-16.04). This ensures forwards-compatibility by allowing publishing to this branch if the mainline of a snap becomes incompatible with a given Ubuntu release, without requiring up-front maintenance of multiple snap channels.

The default track is used for seeding, which usually is called latest. Publishers may request seeding from a different track, if it better matches longevity of a given Ubuntu Series. Example: request to use lts track for Ubuntu 20.04 LTS release.

During a release upgrade, a seeded snap's channel will update to the new release channel if it is available. For example, upgrading from 18.04 LTS to 20.04 LTS, the seeded snaps following the stable/ubuntu-18.04 channel will transition to stable/ubuntu-20.04. If the channel does not exist, the snap will remain on the current channel.

Maintainer

Packages in the Ubuntu archive arrive there by one of two means: they are synced from Debian as upstream, or they are uploaded by an Ubuntu developer. Similarly, to be included in an Ubuntu image, a snap should have as its publisher either the upstream, or the Ubuntu developer community. For the latter, a common team should initially be created in the Snap Store whose membership is managed by the Developer Membership Board, and kept in sync with the ubuntu-core-dev team in Launchpad, with the Ubuntu Security team additionally included.

Source availability

Unlike the deb archive, the Snap Store allows publishers to upload binary snaps directly. While a valuable option in the general case, for snaps installed by default we should ensure that they are built from source in the same trusted Launchpad environment in which debs are built. This helps to avoid any increase to the build time attack surface and provides a known good environment that can be similarly duplicated if the snaps needs to be rebuilt in the future.

In addition, maintainability of the product demands that the package remains buildable if no changes have been made to the product’s source. For .deb packages, we enforce this by only building against other packages in the Ubuntu distribution. Launchpad allows snap builds to pull from third-party repositories; this means that if those repositories change - or disappear - the snap may no longer be functionally equivalent when rebuilt, or may not build at all. To address this, official Ubuntu snaps should be built only from source that is available in Launchpad. Snap recipe builds already require a launchpad-hosted branch to host the snapcraft.yaml, so it is a logical extension to require launchpad hosting for the parts also.

Both of these requirements will likely depend on changes to Launchpad and possibly the Snap Store, to either support enforcing a different network policy at build time or to tag builds as compliant or not with this policy.

License

The license policy covering Ubuntu main and restricted is documented at https://www.ubuntu.com/about/about-ubuntu/licensing. Snaps included by default in Ubuntu installs should comply with this policy just as debs do.

Partner-specific images and images for community flavors may include software that does not meet the Ubuntu main/restricted licensing policy, at the discretion of those images’ owners, in accordance with existing practice.

Security Support

Maintenance of the snap must include a clear designation of accountability for security support. The process for including a snap in an Ubuntu image should include a sign-off by the Ubuntu Security Team to confirm that the security support story is adequate. The snap confinement model means that in-depth code reviews should not generally be required for strict-mode snaps that only require safe interface connections. Classic mode snaps will likely require more scrutiny. The security checks used for deb main inclusion, listed on https://wiki.ubuntu.com/UbuntuMainInclusionRequirements, are also relevant to snaps. The MIR team will be the gatekeeper for the snap inclusion process and coordinate with the Security Team as appropriate. As an initial policy, “as appropriate” means every snap to be installed by default in the Ubuntu image. This policy can be revisited after a period of one year. Owning teams are responsible for security support in accordance with the Ubuntu Security Team’s guidelines for security support of Canonical-supported snaps. A report will be provided by the Ubuntu engineering team of the high-level CVE status across all the snaps included in the Ubuntu image (part of this process involves keeping the review-tools list of publisher_emails up to date).

The Snap Store ecosystem empowers snap publishers to make their own decisions about how and whether to backport security fixes to stable releases vs. updating the package in the channel to a new upstream version. We accept this model as well for installed-by-default snaps, with the understanding that the publisher of each of these snaps is expected to deliver a good experience to their users.

For cases where the Ubuntu community is the maintainer of the snap rather than upstream, it is recommended to prefer targeted backports of security fixes where possible.

Bases

Seeded snaps which use a base, must use base: core18 or higher. Existing snaps are grandfathered, but are encouraged to update to base: core18 or higher.

Contact

The Contact field must be set in the Snapstore to a URL where bug reports and support requests can be filed. If a public tracker is not available, email contact address may be used, but is discouraged. These are used by apport / ubuntu-bug tools to guide users to file issues. Examples: