apt-setup uses apt-key but probably should not anymore

Bug #1754075 reported by Manoj Iyer on 2018-03-07
130
This bug affects 26 people
Affects Status Importance Assigned to Milestone
apt-setup (Debian)
New
Unknown
apt-setup (Ubuntu)
High
Dimitri John Ledkov
Bionic
Undecided
Unassigned
gnupg (Ubuntu)
Undecided
Unassigned
Bionic
Undecided
Unassigned
gnupg2 (Ubuntu)
Undecided
Unassigned
Bionic
Undecided
Unassigned

Bug Description

In di if the kernel is in a private PPA we seed di using

d-i apt-setup/local0/key string http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=<key>

this used to work in xenial, but in bionic this fails and therefore apt update fails in base-installer. May be because add-apt-key is not installed.

Manoj Iyer (manjo) on 2018-03-07
description: updated
summary: - base-installer apt-setup fails to get gpg keys for private ppa
+ uses apt-key but probably should not anymore
affects: debian-installer (Ubuntu) → apt-setup (Ubuntu)
Manoj Iyer (manjo) on 2018-03-07
summary: - uses apt-key but probably should not anymore
+ apt-setup uses apt-key but probably should not anymore
description: updated
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in apt-setup (Ubuntu):
status: New → Confirmed
Lars Kollstedt (lk-x) wrote :

Hi,

This also seems to affect me. But with a completely local repository within the preseed-File, and a local key download using http.
d-i apt-setup/local0/key string http://software.ubuntu.man-da.de/software/key.gpg

But I'm not sure add-apt-key has anything to do with this, since this package hasn't been touched for a long time. I experienced apt-key was complaining about missing gnupg. But the last change there (Thu, 11 Jan 2018 13:33:17 +0000) is still to long ago. If this didn't stay within proposed for almost a month. ;-) And there is nothing about changing priority from important to optional mentioned in the changelog.

On Xenial this was Priority Important, on bionic it's only optional. But adding it manually within the preeseed file IMHO wont help, since this will cause problems to early.

This was still working on March 2nd 2018 with bionic.

Kind Regards
   Lars

Lars Kollstedt (lk-x) wrote :

Hi again,

https://ubuntuforums.org/showthread.php?t=2387570 may be about the same thing. But I can't see what #1553147 should have to do with this, this is referering to Xenial, we and also gregster is talking about bionic.
On Xenial I stumbled in to #1553121 which had another reason, the SHA1-Deprecation. And also stumbled into #1512347 which was due to a unclean generated sources.list for the installation of the base system.
Here we're talking about installing "normal" normal packages after the base system was successfully installed.

But I haven't found out at which time gnupg was changed from important to optional, and if there was another mechanism letting it work afterwards. Manual packages selection will not have any effect because, the entries for local0 are commented out when preparing the regular install sources.

Kind regards,
   Lars

Lars Kollstedt (lk-x) wrote :

Repeating Comment to make the Bugs clickable (can't edit):

Hi again,

https://ubuntuforums.org/showthread.php?t=2387570 may be about the same thing. But I can't see what Bug #1553147 should have to do with this, this is referering to Xenial, we and also gregster is talking about bionic.
On Xenial I stumbled in to Bug #1553121 which had another reason, the SHA1-Deprecation. And also stumbled into Bug #1512347 which was due to a unclean generated sources.list for the installation of the base system.
Here we're talking about installing "normal" normal packages after the base system was successfully installed.

But I haven't found out at which time gnupg was changed from important to optional, and if there was another mechanism letting it work afterwards. Manual packages selection will not have any effect because, the entries for local0 are commented out when preparing the regular install sources.

Kind regards,
  Lars

Lars Kollstedt (lk-x) wrote :

apt-key complains about missing necessary gnupg or gnupg2 package.

affects: apt-setup (Ubuntu) → gnupg (Ubuntu)
Lars Kollstedt (lk-x) wrote :

Didn't want to throw out apt-setup.

affects: gnupg (Ubuntu) → apt-setup (Ubuntu)
Lars Kollstedt (lk-x) wrote :

Hi,

looks like this has happened when changing the source of gnupg to gnupg2 with 2.2.4-1ubuntu1.

The old source
svn://anonscm.debian.org/pkg-gnupg/gnupg/trunk/
contains the Package as important.

The new source
https://anonscm.debian.org/git/pkg-gnupg/gnupg2.git
contains the Package as optional.

gnupg2 was present before, but the did not build a gnupg-Package.

Kind regards,

Lars Kollstedt (lk-x) wrote :

Hi again,

on March 2nd we were already on 2.2.4-1ubuntu1 so there obviously was something fixing this. Since the package already wasn't marked as important this time.

On this time adding the keys still worked fine.

The last days it didn't on bionic.

Kind regards,
  Lars

Lars Kollstedt (lk-x) wrote :

Hi again,

switching to installation shell, and doing a

chroot /target
apt install gnupg2
exit
exit

allows me to complete the installation, when continuing with the installation step preparing installation sources after this.

The /var/log/syslog from the installation system shows the following messages before doing this:

Apr 5 19:09:46 main-menu[2796]: (process:23507): 2018-04-05 19:09:37 URL:http://software.ubuntu.man-da.de/software/key.gpg [3121/3121] -> "/target/tmp/_fetch-url_key0.pub.24311" [1]
Apr 5 19:09:46 main-menu[2796]: (process:23507): E: gnupg, gnupg2 and gnupg1 do not seem to be installed, but one of them is required for this operation

A few lines above there is also the message:
Apr 5 19:09:38 apt-setup: warning: /usr/lib/apt-setup/generators/60local returned error code 255; discarding output

Kind regards,
   Lars

Lars Kollstedt (lk-x) wrote :

In apt-setup-0.104ubuntu5/generators/60local there is an call

$chroot $ROOT apt-key add "/tmp/key$i.pub"

which would be the origin of this message.

Hi,

by the way apt-key belongs to the package apt:

root@bionic-test:/home/kollstedt# apt-file search apt-key
[...]
apt: /usr/bin/apt-key
[...]

It is installed when the error occurs and is exitting with the error mentioned
above.

But there is indeed another way to add the public key without using "apt-key
add".

They can simply be copied to /etc/apt/trusted.gpg.d, with the ending *.gpg if
it's binary format. With the ending *.asc for ASCII-amored format.

Please find a patch attached that use this way to add instead of the old way
with apt-key.

The two following Debian Bugs for this lead me tho this:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851774

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886473

I also sent this message to the first one I considered to be the main one.

For the ones reading the debian bug, this was mainly send to

https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/1754075

Since this also found it's way to Ubunut 18.4 bionic (unreleased LTS).

But there is some (more or less) usefull disscussion but as far as I can see
no patch, yet. So I prepared one. Thanks to Marga Manterola and Philipp Kern
for the idea.

One of the most important errors in stuff discussed there is IMHO the lack of
"-- " which is necessary to prevent grep from interpreding the leading --. I
also decided not to filter for things that are not relevant. Since comments
describing the Publickey or it's origin might be placed above the -----BEGIN
PGP PUBLIC KEY BLOCK----- (without hitting gpgv), and we would not be able to
prevent all possible syntax evil here, without having gpg to import and export
the public key to and from a temporary keyring.
I'm also trying to assign a useful name to the key added this way.

This patch should IMHO work, but I have no opportunity to test it without your
help, since we're in udeb and testing preseed issues. ;-)

Kind regards,
 Lars

--
Lars Kollstedt

Telefon: +49 6151 16-71027
E-Mail: <email address hidden>

man-da.de GmbH
Dolivostraße 11
64293 Darmstadt

Sitz der man-da.de GmbH: Darmstadt
Amtsgericht Darmstadt, HRB 9484
Geschäftsführer: Andreas Ebert

Lars Kollstedt (lk-x) wrote :

On Monday, 9 April 2018 12:56:12 CEST Lars Kollstedt wrote:
[...]
> This patch should IMHO work, but I have no opportunity to test it without
> your help, since we're in udeb and testing preseed issues. ;-)

Hi again,

20 times looked at it and still overlooked one detail.

This must of course be 'echo "$comment"'.

Kind regards,
 Lars

--
Lars Kollstedt

Telefon: +49 6151 16-71027
E-Mail: <email address hidden>

man-da.de GmbH
Dolivostraße 11
64293 Darmstadt

Sitz der man-da.de GmbH: Darmstadt
Amtsgericht Darmstadt, HRB 9484
Geschäftsführer: Andreas Ebert

The attachment "replace_apt_key_add.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Stefan Dietrich (stdietrich) wrote :

Hello,

I have build locally an updated apt-setup.udeb with the patch from #12 and it works for me.

Installation of the rebuild udeb is a bit hacky via early_command:

d-i preseed/early_command string wget -q -O /tmp/apt-setup.udeb http://<internal server>/apt-setup-udeb_0.104ubuntu5_amd64.udeb; udpkg -i /tmp/apt-setup.udeb

I have used a preseed file, which contains 2 local repositories:

# Ubuntu DESY Repository
d-i apt-setup/local0/repository string \
    deb http://<internal server>/extra/desy/ bionic desy
d-i apt-setup/local0/source boolean false
d-i apt-setup/local0/comment string desy
d-i apt-setup/local0/key string http://<internal server>/extra/desy/DESY-Debian-key.asc

# Puppet PC1
d-i apt-setup/local1/repository string \
    deb http://<internal server>/extra/puppet.apt.timeline/current/ bionic PC1
d-i apt-setup/local1/source boolean false
d-i apt-setup/local1/comment string puppetlabs
d-i apt-setup/local1/key string http://<internal server>/extra/puppet.apt.timeline/current/pubkey.gpg

The updated udeb downloads the keys and copies them to /target/etc/apt/trusted/gpg.d:
~ # ls -la /target/etc/apt/trusted.gpg.d/
drwxr-xr-x 2 root root 4096 Apr 11 20:32 .
drwxr-xr-x 6 root root 4096 Apr 11 20:32 ..
-rw-r--r-- 1 root root 971 Feb 25 2015 desy.asc
-rw-r--r-- 1 root root 3139 Feb 22 23:34 puppetlabs.asc
-rw-r--r-- 1 root root 2796 Feb 6 17:15 ubuntu-keyring-2012-archive.gpg
-rw-r--r-- 1 root root 2794 Feb 6 17:15 ubuntu-keyring-2012-cdimage.gpg

Additionally, detection of non-binary format for the puppetlabs key worked as well, as it now contains the .asc extension.

Side remark, a similar bug entry exists for debian-installer on launchpad as well:
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1761030

Regards,
Stefan

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnupg (Ubuntu):
status: New → Confirmed
Changed in gnupg2 (Ubuntu):
status: New → Confirmed
Lars Kollstedt (lk-x) wrote :

Hello,

Bug #1761030 indeed describes the same issues.

I've also a modified udeb in use, now. And it's working for me, but the setup is almost the same.

d-i apt-setup/local0/source boolean false
d-i apt-setup/local0/key string http://software.ubuntu.man-da.de/software/key.gpg
d-i apt-setup/local0/repository string deb http://software.ubuntu.man-da.de/software bionic extras
d-i apt-setup/local0/comment string local server

After the installation completed the key was in /etc/apt/trusted.gpg.d/local_server.asc since our internal repository key was also ASCII-Armored.

But I used the overlay_host configuration to get the udeb in:
apt-mirror-setup apt-setup/overlay_host string software.ubuntu.man-da.de
apt-mirror-setup apt-setup/overlay_directory string /software/
apt-mirror-setup apt-setup/overlay boolean true

The repository key was also integrated into our modified initrd to get this working, but this alone didn't resolve the issues. With the patched udeb in http://software.ubuntu.man-da.de/software/dists/bionic/main/debian-installer/binary-amd64/Packages it works for me.

Kind regards
    Lars

Lars Kollstedt (lk-x) wrote :

Hello again,

I don't really have an opinion if this should be solved by
  - changing the priority of gnupg or gnupg2 (if that wasn't only another unrelated side effect of the change described in Comment #7)
  - adding a dependency to gnupg2 | gnupg to apt-setup-udeb if that would be possible.
  - using the patch from Comment #12

As far as I can see there was no progress in the upstream bug ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851774 ), yet. But they're not releasing on April 26th 2018. ;-)

This might be a bug affecting only advanced admins using depoyment via preseed, but it will IMHO affect everyone of them. If they haven't deactivated key verification at all. ;-)

Kind regards
   Lars

Lars Kollstedt (lk-x) wrote :

Of course only if they're inheriting special repositories this way. But the bugs referenced here IMHO are showing lot's of examples representing different reasons and ways to do this. ;-)

Malcolm Scott (malcscott) wrote :

Any progress on this? This is a serious regression for us which makes preseed substantially less functional in bionic...

Malte Schmidt (maltris) wrote :

Easy workaround which does not require another apt-setup.udeb:

d-i preseed/late_command string \
        in-target wget -q -O /etc/apt/trusted.gpg.d/bla.asc http://bla.de/bla.asc ; \
        in-target sed -i '/keyword to uncomment specific line in file/s/^# *//' /etc/apt/sources.list ; \
        in-target apt-get update ; \
        in-target apt-get -y install packages to install ;

Benjamin Long (benjamin-long) wrote :

I've just been bitten by this bug while upgrading our business PXE/preseed installations from Xenial to Bionic. We use an internal private repository for company specific packages. I'm unable to get the apt key installed with the preseed, so nothing works.

I'm going to attempt the workaround mentioned above.

PorkCharSui (porkcharsui) wrote :

I too used the workaround:
d-i preseed/late_command string \
   in-target wget -q -O /etc/apt/trusted.gpg.d/repo_key.asc http://our.repo/repo_key.asc ; \

We mirror the repositories we offer to our clients, so they can keep doing their stuff in case the intarwebz is inaccessible. None of those repo keys can be added the normal preseed way:
d-i apt-setup/local0/key string http://our.repo/repo_key.asc

I can add the repo this way, just not the key.

tags: added: rls-bb-incoming
tags: added: id-5c4b9a39fe71d33a8db94ec3
tags: removed: rls-bb-incoming
Julian Andres Klode (juliank) wrote :

From the apt side: The patch in #12 looks correct - we want people to put the keys in trusted.gpg.d like this.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in apt-setup (Ubuntu Bionic):
status: New → Confirmed
Changed in gnupg (Ubuntu Bionic):
status: New → Confirmed
Changed in gnupg2 (Ubuntu Bionic):
status: New → Confirmed
Changed in apt-setup (Debian):
status: Unknown → New
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.