I routinely update my system whenever it notifies me of software updates. This is one of those things that I just trust to work without knowing the details, but I have become curious recently: How do I know that

  • the process checking for updates will only show legitimate updates?
  • the updates I receive and install are not malicious?

I know that I have a set of software sources that I specify myself by URL and that whether I trust those sources is my decision. But what happens once I specified those URLs?

From what is common these days, I would suspect that the authenticity of those sources is verfied with something along the lines of HTTPS / SSL, i. e. I have some certificates that are verified against some authority, meaning, I need reliable root certificates installed somewhere (probably they come with the system).

Further, I guess the packages are cryptographically signed, like with GPG or similar.

Are those assumptions correct? Where can I inspect keys / certificates used? How can I verify if they are the right ones? How can I verify that they are, in fact, used? Are there configuration options that make the process more or less prudent, and what are their defaults? Are there known attacks, or have there been vulnerabilities recently? I seem to remember Windows having a problem like that not long ago.

I'm on 12.04, but I'm assuming that this can be answered more generally.


This is a great question. The answer is (of course) fairly complex, but let me try and break it down for you. Let's first look at the technical processes:

The Chain of Trust

We don't use SSL to secure APT, we use cryptographic hashes (SHA256, these days) and OpenPGP signatures. This allows you to trust untrusted mirrors, and avoids having to trust the CA PKI.

When you add a repository to APT's sources.list, you also have to add its PGP key to APT's trusted keyring, with the apt-key command. The keyring comes with the keys for Ubuntu's repositories included. And when you use the apt-add-repository command to add a PPA, it adds the key (obtained from Launchpad over SSL) for you.

The chain of trust is:

  1. Each sources.list entry points APT to a Release file in the repository, with a Release.gpg signature (or they can be combined as an InRelease file). This file describes the repository, and must be signed by a key in your APT's keyring.
  2. The Release file contains cryptographic hashes of all the Packages and Sources files. These list all the packages and versions available in the repository.
  3. The Packages and Sources files contain the cryptographic hashes of each package.
  4. The packages themselves aren't signed. It's unnecessary, there's a chain of trust to them, from the Release file, signed by the mirror. However, the source packages, used to build the binary packages are PGP signed, by the developer who uploaded them.

You can read more about the repository format on the Debian wiki.

This chain means that we don't have to trust any intermediary mirrors, we can trust that the package we install is identical to the one present when the Release file was signed.

You can inspect APT's keyring by running sudo apt-key finger.

Verifying Ubuntu's Archive Keys

How do you know what should be there? If you don't trust your computer, you can't trust any program on it not to lie to you (such as apt-key), and this exercise is futile. So let's assume this is just out of academic interest, and verify the contents of the keyring from the definitive source package, which is PGP signed by the developer who uploaded it.

Download the ubuntu-keyring source package, and see what should be there:

$ apt-get source ubuntu-keyring
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Need to get 20.0 kB of source archives.
Get:1 http://localhost/ubuntu/ quantal/main ubuntu-keyring 2012.05.19 (dsc) [1542 B]
Get:2 http://localhost/ubuntu/ quantal/main ubuntu-keyring 2012.05.19 (tar) [18.5 kB]
Fetched 20.0 kB in 0s (0 B/s)               
dpkg-source: info: extracting ubuntu-keyring in ubuntu-keyring-2012.05.19
dpkg-source: info: unpacking ubuntu-keyring_2012.05.19.tar.gz
$ gpg --verify ubuntu-keyring_2012.05.19.dsc
gpg: Signature made Sat May 19 03:33:12 2012 SAST
gpg:                using RSA key 0x393587D97D86500B
gpg: Good signature from "Colin Watson <cjwatson@chiark.greenend.org.uk>"
gpg:                 aka "Colin Watson <cjwatson@debian.org>"
gpg:                 aka "Colin Watson <cjwatson@ubuntu.com>"
gpg:                 aka "Colin Watson <cjwatson@canonical.com>"
$ gpg --no-default-keyring --keyring ubuntu-keyring-2012.05.19/keyrings/ubuntu-archive-keyring.gpg --fingerprint
pub   1024D/0x40976EAF437D05B5 2004-09-12
      Key fingerprint = 6302 39CC 130E 1A7F D81A  27B1 4097 6EAF 437D 05B5
uid                            Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
sub   2048g/0x251BEFF479164387 2004-09-12

pub   1024D/0x46181433FBB75451 2004-12-30
      Key fingerprint = C598 6B4F 1257 FFA8 6632  CBA7 4618 1433 FBB7 5451
uid                            Ubuntu CD Image Automatic Signing Key <cdimage@ubuntu.com>

pub   4096R/0x3B4FE6ACC0B21F32 2012-05-11
      Key fingerprint = 790B C727 7767 219C 42C8  6F93 3B4F E6AC C0B2 1F32
uid                            Ubuntu Archive Automatic Signing Key (2012) <ftpmaster@ubuntu.com>

pub   4096R/0xD94AA3F0EFE21092 2012-05-11
      Key fingerprint = 8439 38DF 228D 22F7 B374  2BC0 D94A A3F0 EFE2 1092
uid                            Ubuntu CD Image Automatic Signing Key (2012) <cdimage@ubuntu.com>

I know that that is actually Colin Watson's signature, as I've met him several times and we've verified each other's identities and signed each other's keys. If you have a key in the PGP strong set, you should be able to find a trust path to him. I also know that I can trust him to upload the correct ubuntu-keyring package.

For Debian, there's a package (debian-keyring) containing the PGP keys of all Debian Developers, and you can use this to verify source package signatures. Ubuntu doesn't have an equivalent, but many Ubuntu Developers are also Debian Developers, and all our developer's PGP keys are available on their profiles in Launchpad.

The other questions

How do I know updates aren't malicious?

It comes down to trust. You have to fully trust every repository you use. You are giving the maintainers of each repository permission to run things as root on your machine.

Ubuntu packages can only be uploaded by Ubuntu Developers who have been granted upload rights by the Developer Membership Board (which I currently serve on). To apply for upload rights you must be advocated by several existing Ubuntu Developers who have worked with you and trust your abilities to work on your own. Without upload rights, uploads have to be sponsored by developers who have the rights (which should include review of the upload).

For post-release updates, Ubuntu has strict policies about the contents of updates. They should only contain minimal patches to fix known bugs. The patches are reviewed by members of the SRU / Security teams before being accepted.

Obviously, PPAs and 3rd party repositories don't have all these restrictions. You have to trust the PPA owners to be sensible.

All Ubuntu & PPA packages have the source available, so they can be inspected by anyone.

Are there configuration options that make the process more or less prudent, and what are their defaults?

You can turn off signature verification in APT, but of course it's on by default. When you try and install something from an unsigned / untrusted repository, apt makes you confirm that you really want to do this.

Are there known attacks, or have there been vulnerabilities recently?

I recall one, Debian bug 499897. Debian gets around this by giving Release files an expiry date, after which they can't be trusted. Ubuntu doesn't support this yet.


There is no SSL/https that I'm aware of, and there is no certification authority outside your own computer.

To check for updates your computer contacts the servers that you have designated as your sources. It will download a index file from those servers using normal http. This index files are signed, so no one can give you a false index, but the correct file could be served from any computer, allowing easy use of mirrors.

Using this index your own computer will calculate which new packages its needs to download. Again that packages will be retrieved using normal http. A md5 sum of each package will be checked with the release file. In addition, Ubuntu official repositories packages are also signed. Some third party sources could have unsigned packages (but the md5 check is still used), when this happens the installation program (apt, Ubuntu Software Center, ...) will warn you.

To summarise it, the security is not in the servers or in the connections, but in the packages themselves. An attacker breaking into an update server can't damage your computer, but someone who can obtain a valid signature can.

You can find more details in an explanation of secure apt here. To summarize: all packages have a GPG signature and apt trusts those that were issued by the persons whose public key are in the apt keychain (/etc/apt/trusted.gpg)

  • 1
    Minor detail: individual packages are not signed, instead a checksum is calculated over their contents (using both SHA and MD5, it appears) and those checksums are in the signed index file. The practical upside of this is that there are less of random collections of almost working packages like there are for RPM.
    – taneli
    Jan 4 '13 at 12:53
  • Ubuntu official repositories require that the packages are signed in addition to checking its md5 sum against de release file. See wiki.ubuntu.com/PackagingGuide/Complete. It's possible to have unsigned packages in a repository, but they will usually show a warning while installing. I will make an edit. Jan 4 '13 at 15:25

Related answer: beyond checking the package signatures for authenticity, you can take things one step further and verify that systems are fully up to date to the latest applicable security patches with Landscape's compliance report feature.

It is a pie-chart updated on the spot showing you how many and which systems are still vulnerable. This is likely overkill for a single person, but it is an FAQ for large enterprise and small business.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.