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

Bug#886473: marked as done (apt-setup lacks a dependency on gnupg)



Your message dated Mon, 9 Sep 2019 14:29:18 +0200
with message-id <20190909122916.GA31803@korn.westfalen.local>
and subject line Re: apt-setup lacks a dependency on gnupg
has caused the Debian Bug report #886473,
regarding apt-setup lacks a dependency on gnupg
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
886473: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886473
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: apt-setup
Version: 1:0.134

Using additional repositories by preseeding with apt-setup/local0/repository and apt-setup/local0/key is currently broken, causing the installation to fail with a non-obvious error message at a late stage of the install. The reason seems to be that apt-key fails on line 38 of generators/60local, since apt requires gnupg to be installed for the attempted operation.

Until recently, base-installer has always pulled in gnupg. Presumably due to some other package depending on it. This is no longer the case.

As long as 60local is implemented as is, and the example-preseed.txt documents the use of additional repositories, apt-setup should ensure installing from additional repositories works.

My undestanding of prepare_gpg_home() in cmdline/apt-key.in of apt is that it is an active choice to not have apt itself depend on gnupg, thus making it the responsibility of the caller.

I can see that there is a wishlist bug #877013 addressing a similar issue. Don't know more about it's status than the bug report reveals, but would consider this is a separate issue of higher severity since it now actually breaks functionality rather than merely is about adding more granular security controls.

A work around which helped me and might be interesting for other bitten by this bug is to add "d-i base-installer/includes string gnupg" to the preseed file.

Unfortunately I cannot provide a patch, since I do not fully understand which mechanism to use to make a udeb of the installer environment pull in a package in the base-install of the target system. None of the packages I could suspect to be changed have seen any recent relevant commit activity, so I can't figure out exactly what made this break. It should not make much difference since it likely has been a missing dependency in apt-setup all along.
--
/Martin

--- End Message ---
--- Begin Message ---
Version: 1:0.151

On Sat, Jan 06, 2018 at 03:22:41PM +0100, Martin wrote:
> Package: apt-setup
> Version: 1:0.134
> 
> Using additional repositories by preseeding with apt-setup/local0/repository
> and apt-setup/local0/key is currently broken, causing the installation to
> fail with a non-obvious error message at a late stage of the install.

This was fixed in 1:0.151 (and was also backported to Buster 10.1)

Cheers,
        Moritz

--- End Message ---

Reply to: