[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: experimental .deb packages using "signed-by"
- To: email@example.com
- Subject: Re: experimental .deb packages using "signed-by"
- From: Graham Percival <firstname.lastname@example.org>
- Date: Thu, 14 Oct 2021 09:29:15 -0700
- In-reply-to: <YWcpUmQV5NhL4gHY@beastie.local>
- References: <YWcpUmQV5NhL4gHY@beastie.local>
Apologies for being unclear here: we have an experimental
tarsnap-archive-keyring package, but no new tarsnap packages.
If tarsnap-archive-keyring 2021.09.29 installs without any errors or warnings,
then all is well and there is nothing further to test.
On Wed, Oct 13, 2021 at 11:45:38AM -0700, 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.
> If there's no reports of problems, we'll migrate them to the real packages in a
> - 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
> - 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
> 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:
> and here's the commit in the tarsnap-public-keys repository:
> - Graham Percival