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

[Graham Percival <gperciva@tarsnap.com>]

Correct, there is absolutely no change for people compiling from source.

Cheers,
- Graham

On Thu, Oct 14, 2021 at 11:57:54AM -0700, jerry wrote:
> 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