Re: [PATCH 0/1] Fix remote key fetching apt keyring

[Andreas Reichel <andreas.reichel.ext@siemens.com>]

On Wed, Feb 20, 2019 at 12:58:09PM +0100, Maxim Yu. Osipov wrote:
> On 2/20/19 12:27 PM, Jan Kiszka wrote:
> > On 20.02.19 12:21, [ext] Andreas J. Reichel wrote:
> > > From: Andreas Reichel <andreas.reichel.ext@siemens.com>
> > > 
> > > Since my last mail was not answered, but this is an important topic,
> > > here is a patch that shows what the problem is.
> > > 
> > > If we fetch the user apt key from remote, we need the basename,
> > > if we fetch it locally we need the absolute path...
> > > 
> > > While this might not be the best way to fix this, it works as good
> > > as the rest of this code...
> > > 
> > > At least it fixes Isar again up to adding the key to the keyring.
> > > 
> > > But this still does not fix the next problem with the docker-ce key:
> > > 
> > > | I: Running command: debootstrap --arch arm64 --foreign --verbose
> > > --variant=minbase --include=locales
> > > --components=main,contrib,non-free --keyring /build/build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/apt-keyring.gpg
> > > stretch
> > > /build/build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/rootfs
> > > http://ftp.debian.org/debian
> > > 
> > > | I: Retrieving InRelease
> > > | I: Retrieving Release
> > > | I: Retrieving Release.gpg
> > > | I: Checking Release signature
> > > | E: Release signed by unknown key (key id EF0F382A1A7B6500)
> > > 
> > > So something additionally must be done. Since I am not an expert on
> > > debian keyring/debootstrap and dpkg signing I will try to find a
> > > solution but maybe somebody has a good idea already?
> > > 
> > 
> > Baurzhan, Maxim, any idea?
> 
> Strange...I thought that commit af983a13 fixes the reported problem
> When testing my patch signing base-apt I've tried both - remote keys (used
> by Raspberry Pi target) and local key.
> 
> @Andreas
> I was really busy these days - I'll look on your problem ASAP.
> 
Meanwhile I found, that there are several implementation problems and one design
problem:

* When I tried to add keys to the corresponding gpg key rings I found
  that the trust DB is always inside the home directory given to gpg,
  i.e. inside the DL_DIR. This way new keys are always unknown if apt
  has a look at it since apt does not know anything about what we tell
  gpg.

  Also adding My keyrings to etc/apt/trusted.gpg.d/ did not work.
  My first example in thep revious email was incorrect since I did not
  specify --no-default-keyring and thus, inside my build environment,
  gpg created a ~/.gnupg/trustdb

  This way, we have host pollution and hard to control host-target mixtures.

* I managed to get the first bootstrap working, but afterwards, when
  apt tries to install docker dependencies, it does not work again since
  keys are not there and/or untrusted.

Most problematic is the way things are implemented. I already had a
discussion with Hening:

What is done in ISAR: The key management is done with gpg outside of the
rootfs and everything is being tried to put together manually which
eventually fails in my case and is difficult to fix.

Repos are added manually, lists are parsed manually, etc...

What should be done: There are several tools that are already provided
by Debian:

1. apt-key

Isar should just download the keys provided without manually adjusting
any keyring.

Also, apt-key should be called in the corresponding root file systems.
The idea is that all keys are fetched to a common location like

TMPDIR/aptkeys

Afterwards in every root file system, apt-key can be used to import
these keys.

2. Debian's `add-apt-repository`

This command is available since Jessie in the
'software-properties-common' package and should be used to automatically
add source list entries.

The steps should work as follows:

	a) debootstrap with a base repo, use key if needed
	   maybe destinguish between upstream and local
	b) chroot into the new rootfs,
	   use apt-key and add-apt-epository
	   use apt-get update
           install the rest.
	c) also for cross chroot-target

Thus the whole thing should be refactored. Since I am already on it I
would like to do so and propose a patch for this within the next days.

Thanks,
Andreas

> Thanks,
> Maxim.
> 
> > Jan
> > 
> 
> 
> -- 
> Maxim Osipov
> ilbers GmbH
> Maria-Merian-Str. 8
> 85521 Ottobrunn
> Germany
> +49 (151) 6517 6917
> mosipov@ilbers.de
> http://ilbers.de/
> Commercial register Munich, HRB 214197
> General Manager: Baurzhan Ismagulov

-- 
Andreas Reichel
Dipl.-Phys. (Univ.)
Software Consultant

Andreas.Reichel@tngtech.com, +49-174-3180074
TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterfoehring
Geschaeftsfuehrer: Henrik Klagges, Dr. Robert Dahlke, Gerhard Mueller
Sitz: Unterfoehring * Amtsgericht Muenchen * HRB 135082