[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: experimental .deb packages using "signed-by"



All,

So can I understand that this is strictly a debian/apt issue? That those of us
who download the source and build it, aren't affected?

                     - Jerry Kaidor

On 2021-10-13 11:45, Graham Percival wrote:
We have experimental packages and instructions for .deb packages which support "signed-by" repositories. This is relevant for people using Debian, Ubuntu,
Mint, ElementaryOS, Pop!_OS, etc.

The old method (using apt-key) is marked as deprecated, and is planned to be removed from new distributions in mid-2022. As far as I'm aware, any existing installation should be fine in the future -- this isn't something that they would change in the middle of a stable release's lifetime. (For example, if
you're running Ubuntu 18.04, don't worry.)

We're currently testing:
- a new tarsnap-archive-keyring package.
- installation instructions which depend on the user's version of apt.
https://www.tarsnap.com/pkg-deb.html#experimental

If there's no reports of problems, we'll migrate them to the real packages in a
week.


History
- before apt 1.1~exp9 2015-08-18, gpg keys for third-party
  repositories had to either be added to /etc/apt/trusted.gpg directly,
  or added to /etc/apt/trusted.gpg.d/ as a separate file.  These keys
  are completely trusted by the system.

  Hypothetically, if a third-party repository includes a package called
  "passwd" which has a higher version number than the normal "passwd"
  package, the distro would happily install the third-party package.
I leave the security implications of this as an exercise for the reader.

- after apt 1.1~exp9 (related stable release: apt 1.1 2015-11-26),
  repositories entries in sources.list could be marked as "signed-by".
  For example,
    deb http://pkg.tarsnap.com/deb/stretch ./
  turns into:
    deb [signed-by=/usr/share/keyrings/tarsnap-archive-keyring.gpg]
http://pkg.tarsnap.com/deb/stretch ./
  (all on one line)

  As a result, the system no longer needs to completely trust
  third-party keys; a malicious third-party "passwd" package would not
  be viewed as an upgrade to the base system "passwd" package.

- apt 2.1.8 2020-08-04 marked "apt-key" (which manages
  /etc/apt/trusted.g) as deprecated; scheduled for removal in Q2/2022.


What does that mean for us?

- people using old (2015 or earlier) distros still need the
  tarsnap-archive-keyring package to write the keyring to
  /etc/apt/trusted.gpg.d/
- people using the most recent (2021 or later) distros should use the
  "signed-by" method for new installations.
- people using distros between 2016 and 2021 could use either method for
  new installations.  (We will tell them to use the newer method.)
- if at all possible, people with existing tarsnap installations should
  not need to know about any changes.
  (i.e. `apt-get update && apt-get upgrade` should just work.)

Our solution for the tarsnap-archive-keyring packate is:
- if the system already has a
    /etc/apt/trusted.gpg.d/tarsnap-archive-keyring.gpg
  then copy the new archive keyring over that existing file.
- otherwise, don't write to /etc/apt/trusted.gpg/

This requires the use of postinst / postrm scripts, which is discouraged by the Debian New Maintainer's Guide, but I can't see an alternate solution which would work for new installations and existing installations at the same time
(without requiring existing users to manually edit files in /etc/).


For more details, here's the initial discussion:
https://github.com/Tarsnap/tarsnap/issues/475
and here's the commit in the tarsnap-public-keys repository:
https://github.com/Tarsnap/tarsnap-public-keys/commit/cc32d2b5fc2c3e955efe651dbeb65a6c708b8fab

Cheers,
- Graham Percival