On Mon, Jul 01, 2019 at 08:40:22PM +0200, Raphaël Halimi wrote: > Hi Cyril, > > Le 29/06/2019 à 16:20, Cyril Brulebois a écrit : > >> If installing gnupg is what it takes to fix the bug, IMHO it should be > >> done; anyway, with this patch, it would be installed only if a local > >> repository with a GnuPG key is used at all.
@kibi: Fixing this for the 10.1 point release sounds good, I can easily reproduce this against apt.wikimedia.org, so happy to test a build when the MR is merged. > > Well, I proposed doing so a while ago but that didn't happen. Looking at > > the current gnupg package, it's not about installing just a single, > > extra package: > > > > Depends: dirmngr (<< 2.2.13-2.1~), dirmngr (>= 2.2.13-2), gnupg-l10n (= > > 2.2.13-2), gnupg-utils (<< 2.2.13-2.1~), gnupg-utils (>= 2.2.13-2), gpg (<< > > 2.2.13-2.1~), gpg (>= 2.2.13-2), gpg-agent (<< 2.2.13-2.1~), gpg-agent (>= > > 2.2.13-2), gpg-wks-client (<< 2.2.13-2.1~), gpg-wks-client (>= 2.2.13-2), > > gpg-wks-server (<< 2.2.13-2.1~), gpg-wks-server (>= 2.2.13-2), gpgsm (<< > > 2.2.13-2.1~), gpgsm (>= 2.2.13-2), gpgv (<< 2.2.13-2.1~), gpgv (>= 2.2.13-2) > > I agree with you on the fact that the dependencies are quite heavy. I > noticed that, but I didn't realize that the GnuPG keys could just be > dropped in /etc/apt/trusted.gpg.d/ (more on that later). Good point. There's a simple workaround you can use in your preseed config (which we've also applied for the Wikimedia servers): https://github.com/wikimedia/puppet/commit/d783a56d7ef7a1bc44a5b4b0323565c24e7ae6a1 > If you don't change your mind, please at least agree that this bug (and > its possible workarounds) must absolutely be documented with big fat > warnings in the preseed documentation [3]. > > I have to say that I **really** miss the times when a new Debian release > was ready "when it's ready"... :( This is already broken in Stretch, so you're overly dramatic... Cheers, Moritz
