[Bug 1553121] Re: Xenial preseed fails to load key for 3rd party repo with apt-setup/local0/key

[Lars Kollstedt]

Hi all,

to clarify somthing that might be missunderstood in my previous post.

Of course the hpe stuff is OT. What I meant to say with this, is that
the list on https://wiki.debian.org/Teams/Apt/Sha1Removal is still
incompletely reflecting the repositories affected, and will probably
always be.

There are plenty of additional repositories. Workaround in some cases
might be to inherit the repository by adding it after installation.
"apt-get update" only displays a warning. We were already doing this
because, not all our servers were from HPE, and this works so far with
the mentioned warning. ;-)

But in some cases such workarrounds aren't wanted. Or people are simply
deploying the repository URL via preseed and get weired errors, now.

At least the last case *should* be fixed, since this will burn a lot of
time. IMHO for nothing!


As far as I can see, neither apt-setup and base-installer are dealing with the keys themselves the verification done in  debootstrap (used by base-installer) doesn't look like there is anything done with the HASH-Algorithm. Both are dealing with apt-get, but:
| root at xenial-test2:/home/kollstedt# apt-get -o APT::Get::List-Cleanup=false update; echo "return code = $?"
[...]                                        
| Ign:7 http://downloads.linux.hpe.com/SDR/repo/mcp/ubuntu trusty/current InRelease                                              
| Hit:8 http://downloads.linux.hpe.com/SDR/repo/mcp/ubuntu trusty/current Release     
| Reading package lists... Done 
| W: http://downloads.linux.hpe.com/SDR/repo/mcp/ubuntu/dists/trusty/current/Release.gpg: Signature by key 
| 882F7199B20F94BD7E3E690EFADD8D64B1275EA3 uses weak digest algorithm (SHA1)
| return code = 0
Used the HPE for test, since our internal reposiory has a SHA-2-256 now.

I don't see them dealing with any output. ;-)

Any ideas so far?

Kind regards
   Lars

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to base-installer in Ubuntu.
https://bugs.launchpad.net/bugs/1553121

Title:
  Xenial preseed fails to load key for 3rd party repo with apt-
  setup/local0/key

Status in apt-setup package in Ubuntu:
  Confirmed
Status in base-installer package in Ubuntu:
  Confirmed

Bug description:
  I have an automated preseed installation that uses these lines to add
  custom repos during the installation:

  d-i apt-setup/local0/repository string deb http://jschule.github.io/ubuntu/ /
  d-i apt-setup/local0/comment string JTS local repository
  d-i apt-setup/local0/source boolean false
  d-i apt-setup/local0/key string http://jschule.github.io/ubuntu/repo.key

  d-i apt-setup/local1/repository string deb http://dl.google.com/linux/chrome/deb/ stable main
  d-i apt-setup/local1/comment string Google Chrome Browser
  d-i apt-setup/local1/source boolean false
  d-i apt-setup/local1/key string http://dl.google.com/linux/linux_signing_key.pub

  (seehttps://github.com/jschule/ubuntu/blob/d46f1cef49ed71dc4bfe317119cccd3f39097ef4/preseed/jts.txt
  for complete preseed file that causes the problem).

  In xenial the installation fails because the GPG key for the local0
  repo is not loaded into the system so that it can be used (see
  screenshot). Strangely, "chroot /target apt-key list" shows the key
  9E62229E to be installed.

  Just to be sure that there is no problem with my repo and key I
  started the Xenial live CD and installed my repo there manually. All
  works well. IMHO this shows that the problem is clearly related to the
  automated installation with preseed.

  Maybe this is related to #1512347, that was the only thing I could
  find on Launchpad that is in the same area.

  If you want to reproduce this then you can checkout the scripts from
  https://github.com/jschule/ubuntu/tree/gh-pages/qemu and run "./run.sh
  xenial" to start my installation.

  I found a very ugly workaround by changing the apt-setup lines to
  this:

  d-i apt-setup/local0/repository string deb http://archive.canonical.com/ubuntu trusty partner
  d-i apt-setup/local0/source boolean false

  d-i apt-setup/local1/repository string deb http://jschule.github.io/ubuntu/ /
  d-i apt-setup/local1/comment string JTS local repository
  d-i apt-setup/local1/source boolean false
  d-i apt-setup/local1/key string http://jschule.github.io/ubuntu/repo.key

  d-i apt-setup/local2/repository string deb http://dl.google.com/linux/chrome/deb/ stable main
  d-i apt-setup/local2/comment string Google Chrome Browser
  d-i apt-setup/local2/source boolean false
  d-i apt-setup/local2/key string http://dl.google.com/linux/linux_signing_key.pub

  I suppose that the workaround works because now the local0 repo is one
  where the signing key is already part of Ubuntu. I just hope that
  there is no package in the trusty partner repo that is not also in the
  xenial partner repo.

  For me it is very important that you fix this bug before 16.04 is
  released so that I can continue to use Ubuntu with an automated setup.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt-setup/+bug/1553121/+subscriptions