Ubuntu Weekly Recipe

The "apt-key" command used to add a third-party APT package repository will be "deprecated ⁠" from 2.1.8 in August 2020 and will be removed in mid-2022. It became a schedule. This time, let's explain the reason and alternatives.

Mechanism to ensure the legitimacy of the repository

A package management system in Linux is a critical operation that replaces important system data. Therefore, when downloading a package from the Internet, you must confirm its validity. When we say "package legitimacy," it generally has multiple meanings.

1. The package does not contain malicious code
2. Packages created by a third party other than the package maintainer have not been uploaded to the repository.
3. You have not downloaded the package from a location other than the original repository

First of all, regarding 1 which is the most worrisome, this is not covered by APT protection. Users can only trust the maintainers of the package. In other words, when registering a third-party repository that contains PPA, consider not only its convenience but also its reliability.

Strictly speaking, 2 is also outside the scope of APT. For the official Ubuntu repository, uploading the source package requires the maintainer's signature, and after verifying that signature, the build server builds the package and places it in the appropriate location. However, from the user's point of view, there is no other way but to trust the administrator of the repository for this part as well.

Only 3 is actually confirmed by APT. Assuming that the correct administrator has uploaded a package that does not contain malicious code to the repository and is operating it correctly, we guarantee that it is the package uploaded by that administrator that we are trying to download. increase.

In order to "guarantee the validity", in the case of APT, it is verified by the public key method using GPG. There are some differences depending on the version, settings, and repository, but the verification method when downloading a package from the repository is as follows.

1. Download the InRelease file from the URL recorded in the sources. list
2. Validate the InRelease file with the repository key saved locally in advance
3. Download packages files such as main / binary-amd64 / Packages
4. Verify the hash of the Packages file with the information in InRelease
5. Download the target package file from pool / main / etc. according to the path of Packages
6. Verify the hash of the downloaded package file with the information in the Packages file

InRelease can only be signed by someone who has a private key that is paired with the repository key. In other words, this is the administrator of the repository itself, and the official Ubuntu repository is called "ftpmaster". By the verification flow that follows from the signature of InRelease, it is possible to confirm that the downloaded package file was downloaded from the site by the administrator of the repository (* 1 ⁠) ⁠.

* 1

You can also check this information with " man apt-secure ".

For example, the InRelease file (* 2) of one day of Ubuntu 20.04 LTS has the following contents.

* 2

You may also use Release or Release. Gpg separately from InRelease. Release is the main data, and Release. Gpg is the signature information for it. InRelease is a file (Inline signed Release) that combines Release and Release. Gpg into one file. Also, the InRelease and Release files acquired by APT are " /var/ lib/ apt/ lists ". It is saved under.

  ----- BEGIN PGP SIGNED MESSAGE ----- Hash: SHA512Origin: UbuntuLabel: UbuntuSuite: focalVersion: 20.04Codename: focalDate: Thu, 23 Apr 2020 17:33:17 UTCArchitectures: amd64 arm64 armhf i386 ppc64el riscv64 s390xComponents: main restricted universe multiverseDescription: Ubuntu Focal 20.04 (Omitted) 7ef83228ec207df10acac48fbdd811125826751 main / binary-amd64 / Packages (Omitted) + m9MS1XP0RN13iWp3zXSlWJGPO / mDezqQ7vZ8Iwx = 7xQ1-----END

The hash value of MD5SUM / SHA1 / SHA256 is posted for each content indicated by the URL of the metadata information including Packages.

On the other hand, the Packages file (* 3) that can be downloaded from the repository is the following file with various hash values ​​as described above.

* 3

The official repository only contains xz and gz compressed ones because it contains all the package information for a particular component in the repository.

  Package: accountsserviceArchitecture: amd64Version: 0.6.55-0ubuntu13.2Priority: standardSection: gnomeOrigin: UbuntuMaintainer: Ubuntu Developers Original-Maintainer: Debian freedesktop.org maintainers Bugs: https://bugs.launchpad.net/ubuntu/+filebugInstalled-Size: 452Depends: dbus, libaccountsservice0 (= 0.6.55-0ubuntu13.2), libc6 (> = 2.4), libglib2.0-0 (> = 2.44), libpolkit-gobject-1-0 (> = 0.99) Suggests: gnome- control-centerFilename: pool/main/a/accountsservice/accountsservice_0.6.55-0ubuntu13.2_amd64.debSize: 61424MD5sum: 8d0c520e5edae8a0526a76982530ce2aSHA1: 6859166c5c490cf4be3ce74dce3816bb56d4a5f0SHA256: 344201d66fa1327b1dfce472dc062c5eba482f4caaecb1b832ec658869660b51SHA512: 964b9ceef71c3cb3cf88dfda3344814c19030de01a59d514268bb2fa89d6495bf9bd587a44517aa960f71b06c04550d5fe9b9cfbd83840e06179708adc4e85cfHomepage: https://www.freedesktop.org/wiki/Software/AccountsService/Description: query and manipulate user account informationTask: standardDescription-md5: 8aeed0a03c7cd494f0c4b8d9774  83d7ePackage: acctArchitecture: amd64 (omitted)

And " accountsservice_ 0. 6.55-0ubuntu13. 2_ amd64. deb "" Can be verified by verifying with the hash values ​​listed above. This allows Ubuntu repositories to download packages without having to worry about man-in-the-middle attacks without using HTTPS etc. (* 4 ⁠) ⁠.

※Four

In particular, official repositories and their mirror repositories have a high storage network load, so they cannot be converted to HTTPS, and there is not much point in converting them to HTTPS as a result of the above mechanism. However, if you also want to distribute the public key of the repository, it is essential to make it HTTPS. By the way, if a badly behaved proxy is sandwiched between them, there will be a discrepancy between the above metadata and hash correspondence, and an error such as "hash sum does not match" will appear in "⁠apt update" etc. and the package will be updated. I fail. Please also refer to the 331st "How-to Collection of Package Management" for the countermeasures in this area.

The point here is the "repository key" for verifying the InRelease signature. Assuming that the repository administrator uses the private key to sign the InRelease, the user must obtain and manage the public key in some way. The official Ubuntu repository is automatically registered by clicking "Include in the installer". It is provided as ubuntu-keyring package.

  $ gpg --list-keys --keyring /etc/apt/trusted.gpg.d/ubuntu-keyring-2018-archive.gpg/etc/apt/trusted.gpg.d/ubuntu-keyring-2018-archive.gpg -------------------------------------------------- -------------------------------------------------- ---- pub rsa4096 2018-09-17 [SC] F6ECB3762474EDA9D21B7022871920D1991BC93Cuid [Unknown] Ubuntu Archive Automatic Signing Key (2018)

For example, download the InRelease file and verify it.

 $ wget http://jp.archive.ubuntu.com/ubuntu/dists/focal/InRelease $ gpgv --keyring /etc/apt/trusted.gpg.d/ubuntu-keyring-2018-archive.gpg InReleasegpgv: 2020 April 24, 02:34:17 Signing on JST gpgv: Using RSA key 3B4FE6ACC0B21F32 gpgv: Unable to verify signature: No public key gpgv: April 24, 2020 02:34:17 on JST Signed gpgv: Using RSA key 871920D1991BC93C gpgv: Correct signature from "Ubuntu Archive Automatic Signing Key (2018)"

The key "3B4FE6ACC0B21F32" is a key that was used before 2018. It is also signed with the old key so that it can be verified with older releases of Ubuntu.

In this way, the validity of the package by APT depends on the repository key. It was the apt-key command that managed the repository key.