Ubuntu packages
Software for Ubuntu is delivered using a range of packaging technologies — each is optimal for specific scenarios.
'Deb' packages are the heart of Ubuntu
The 'deb' package format comes from the Debian Linux distribution and is widely considered the best package format for system-level libraries and applications with rich and dynamic dependencies. We use .deb packages to create the base Ubuntu operating system and we include tens of thousands of debs for a wide range of open source applications.
Deb packages are installed without confinement - that means that a deb package has full control of your system when it is being installed, and you should only install deb packages that you trust completely with your system security. Be very careful when you are asked to add third-party deb packages manually, or additional archives or repositories of deb packages, because they will have effective control of your machine. We recommend you decline to install debs from third parties unless you have very specific reasons to do so.
Deb packaged software can include AppArmor profiles that limit their reach, which is beneficial for general system security but does not confine or limit the scripts which handle package installation and updates or removal. Debs cannot be used in the appliance-oriented Ubuntu Core.
The standard Ubuntu packages are built on a trusted infrastructure from open source. While they cannot be guaranteed to be secure, the provenance of the code and the build system ensure that they can be audited and known to work in a particular way.
Updates to debs are not managed; a problematic upgrade can leave files on your disk which cause problems later. When debs are unpacked on your system it is no longer possible to validate them precisely and efficiently, which means that compromises and intrusions on a deb based system are more difficult to identify.
Get started with the Ubuntu Packaging Guide
'Snap' packages have better security and updates
Newer 'snap' packages are preferred for free-standing components, especially applications. They can be rigorously confined, meaning that every stage of the application installation and operation can be kept secure. A 'strictly' confined snap has a very specific set of features that it is allowed to use, which requires appropriate oversight by Canonical, and if that software is compromised then those safeguards should limit the impact of the vulnerability.
There are also 'classic' snaps, which are not confined and which are thus equivalent to third-party debs. We strongly recommend that you establish the bona-fides of any third-party classic snap publisher. Important or widely-used classic snaps should have 'verified' publishers in the store.
Snaps are less likely to have problems with dependencies over their lifetime because they bundle these dependencies or use standard system-provided dependencies in a standardised way. However, it is up to the publisher of the snap to ensure that issues in dependencies are addressed with newer versions of the snap because snaps are build and published directly by the upstream vendor of the software. That also means that the architectures supported by a snap are determined by the vendor, not Canonical, and the security of the build system is often up to the vendor as well. Some snaps are build on trusted infrastructure for all architectures. You can ask your vendor to follow that approach for snaps where this is important to you.
The update mechanism for snaps is highly reliable, with automatic backups of relevant data and the ability to roll back to the previous version of the update fails.
Snaps are always stored in a format which supports signature validation, meaning that intrusions are easier to detect.
Get started making a snap with Snapcraft
Charms are packages for cloud software operations
In the cloud world, it is useful to share software operations code as much as it is useful to share the code of the applications themselves. Rather than having many different organisations code operations separately, Ubuntu enables community-based operations collaboration with a standard 'charm' package for operations.
Charms handle the application lifecycle - deployment, integration and configuration, upgrades, and teardown.
There are charms for both VM-based cloud operations, and Kubernetes-based cloud operations. Charms can use a range of operating systems, but most charms as Ubuntu-based, so they benefit from the standard security and familiarity of the rest of Ubuntu.