From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6658246660386193408 X-Received: by 2002:ac2:4207:: with SMTP id y7mr2037145lfh.7.1550674021565; Wed, 20 Feb 2019 06:47:01 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:9a18:: with SMTP id o24ls1234002lji.3.gmail; Wed, 20 Feb 2019 06:47:01 -0800 (PST) X-Google-Smtp-Source: AHgI3IaPerCUVdX7Dq7NFLmARrHTg1jAoVUyc+j5XRNcEwzQsYRSmQ2EKYKjFjO/eBn5F4KG3vVA X-Received: by 2002:a2e:9693:: with SMTP id q19-v6mr2106078lji.20.1550674021010; Wed, 20 Feb 2019 06:47:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550674021; cv=none; d=google.com; s=arc-20160816; b=rQvvQIes3WM+RELMqi0V+ateOXW5DmLyt/cVOM2EBHcej4U5RfyEL+rR4kZRuafnzt pFnPAcO+nK5NInDCaycyoSESHo/TiqfBlPv2LCv6XE+xmAzqaHGyOYPykbELfaPSXIz7 hYeIPOS0qcvh3g1vgvtcv8DmGac52sgExOioD+pRHCt1WNBm9D9VpIxsFEvfiyXyz18s mQXBLQ5lgIpUtllDl5KvmTVWs2NqrwAsnwr5+8Q865sdt9qpx4tmUPSC7H0PrYwLicPz DYm41/jOI9LIH3uzLVTXnx2KOoiO1/QRaO8fZVhxvgh6gDW6/DaclHnrBHktG+AZEPeG BkJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:content-description :mime-version:references:message-id:subject:cc:to:from:date; bh=l4Uo6VC9F4lktG47+EiFtApyIMoK7BqmIPAS6mLXf/s=; b=SNHSLJrjKR7QSbgZMHfZb3YKt8tqs20jG/QxWmyAe28ZlOKA55rz0ReEnEEH0sFrLy nDbSJWw0aHOGPqbpoSTeK8Rabf80Y7j7UecRj3JeAwnIVeNW8DWDJwJ9yVNwsqiDZt9R KPpdvXtt68ZAhODzN9SwKgJFTqpAIn49UFJO+wKMaw2+niNtej1teGRykpT510wMJke3 y06csrCLNFYY+KWBEuKAsrTkbSs913PkAYYlkZtpYRW0GPkTYOiE+64eiCTfUKx7F4ce p//PlNKlWbXcs354h+6C/Cu0Yntym/VDjYpcew1hrFtR2eZyw19VGJ4RzCEel+lQx8sC EDxA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of andreas.reichel.ext@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=andreas.reichel.ext@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id w23si916340lfl.5.2019.02.20.06.47.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Feb 2019 06:47:00 -0800 (PST) Received-SPF: pass (google.com: domain of andreas.reichel.ext@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of andreas.reichel.ext@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=andreas.reichel.ext@siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id x1KEkxZd030002 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 20 Feb 2019 15:47:00 +0100 Received: from iiotirae (golem.ppmd.siemens.net [139.25.69.17]) by mail1.sbs.de (8.15.2/8.15.2) with SMTP id x1KEkxAA028269; Wed, 20 Feb 2019 15:46:59 +0100 Date: Wed, 20 Feb 2019 15:45:28 +0100 From: Andreas Reichel To: "Maxim Yu. Osipov" Cc: Jan Kiszka , isar-users@googlegroups.com, Baurzhan Ismagulov Subject: Re: [PATCH 0/1] Fix remote key fetching apt keyring Message-ID: <20190220144526.GA23122@iiotirae> References: <20190219162942.6bfb794b@md1za8fc.ad001.siemens.net> <20190220112133.23122-1-andreas.reichel.ext@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Description: message Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-TUID: FgC5ef6qzpP5 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 > > > > > > 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