From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6662306185101705216 X-Received: by 2002:ac2:43a1:: with SMTP id t1mr1382855lfl.9.1551193621877; Tue, 26 Feb 2019 07:07:01 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:63c4:: with SMTP id s65ls2085532lje.12.gmail; Tue, 26 Feb 2019 07:07:01 -0800 (PST) X-Google-Smtp-Source: AHgI3IY0zm3mOW9s190sL7mxFTFd4Srk0aQQzq9wUwPYtYahFCC4HKQBqRib8ns5HZuZFNQRF5Bn X-Received: by 2002:a2e:9ec6:: with SMTP id h6mr792115ljk.23.1551193621311; Tue, 26 Feb 2019 07:07:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551193621; cv=none; d=google.com; s=arc-20160816; b=WWPeV6yJbYFXnPMG6s6IzJrASUkgUQ2Ayoh1Fqb6II3T53H5NEHVXmVMBh7fuzS4AE BsP6AMK7iYR9zt9MolxtcpSzQ68YQOLM2I/kaUikqrto+j7+RMDOKe2Vv8SSGHbJV2KG MWBwdD4LgMVK9jNHQn5acAfuVbB67fJxZ4oKEo3HclrqhVTWniH6v1BjB6aVhOIg5Dba Dayf5RqL8ASg20CV30pfgWm4MjhxVK0Rrz8DDlMKzN4gIlF75V4pmQUGxEr9/oWR/L+V 0mqMfet+aUG0cPZSB+hMMO2+hSlzoF5cUO99+Vt72n/bHrLltP0ACXK326wva6i+CbS7 ZoAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date; bh=jUG5aH0DwLBTDh4SWgc2MfQ74RybHPmwKpeN/B/8E08=; b=07flvbHqUZ/sqAbK1tiyNvpuCia9PFA3gYobGhlVGvYFKtc7ukeFneuhJPwmn/o3+K ZTSTWpKlBdsl5QyK0RKm4t0SEyKimdip7+fD6uIXaaFfUpApVu7w/VvtclpNUMzsRbkh Zb0WgB8X5nesKiCisFsNjt6n4wZSD4aE4MA+gvazQ0aC098BPpBtxjSijbpmvKwfKZxH a5A8sVmoRQ6NvhvjSurqyJFvUF4wJzKLbXm4QxgoyTHfHRHoW9utWLApKXJEFVkROI65 IxQP2ybpyuLyjyWNTAtgF04CU6OtOspO32HdurgdnbTcfw7vyfpwmo2TPjYT58ZmnBEE 6XLA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from lizzard.sbs.de (lizzard.sbs.de. [194.138.37.39]) by gmr-mx.google.com with ESMTPS id h17si188967lfm.1.2019.02.26.07.07.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Feb 2019 07:07:01 -0800 (PST) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.39 as permitted sender) client-ip=194.138.37.39; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id x1QF70dI031654 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 26 Feb 2019 16:07:00 +0100 Received: from md1za8fc.ad001.siemens.net ([139.25.68.253]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id x1QF70Hh005231; Tue, 26 Feb 2019 16:07:00 +0100 Date: Tue, 26 Feb 2019 16:06:59 +0100 From: Henning Schild To: "[ext] Andreas J. Reichel" Cc: Subject: Re: [RFC v1 0/3] Fix additional apt repos with foreign keys Message-ID: <20190226160659.33e7a6f8@md1za8fc.ad001.siemens.net> In-Reply-To: <20190226134844.8632-1-andreas.reichel.ext@siemens.com> References: <20190226134844.8632-1-andreas.reichel.ext@siemens.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: gA8vFYo6GKxe Am Tue, 26 Feb 2019 14:48:41 +0100 schrieb "[ext] Andreas J. Reichel" : > From: Andreas Reichel > > This patch series fixes problems when adding a additional repos > which need different gpg keys for authentication. > > The patches are designed to make the existing 'API', i.e. bitbake > variables work, not to solve the remaining design problems. > > On basis of this series, we should discuss how to further proceed > since there should be a destinction wether we change the bootstrapping > apt source or if we change the apt source for additional packages. > > If we change the bootstrapping apt source, we already need keys > installed in the build environment to do the first debootstrap. > > If we only want additional packages in the target rootfs, we only > need to add keys inside the target chroot. > > Currently this is not possible and requires additional bitbake > variables, i.e. APT_KEYS_TARGET_PKGS, or APT_KEYS_TARGET_BOOTSTRAP. I think it is useful to establish the trust twice and forget about extra variables. People might want to bootstrap from "new/unknown" mirrors, like i.e. the cache. So use the variables we know to establish trust on the guy running debootstrap and inside the chroots. That is two "apt-key" like in your current patches. But i would argue that you should play with "apt-key --keyring ". The goal would be to create a keyring just for that one debootstrap call, which you will remove/distrust later. For people not using docker that will prevent "messing with the host". > Also the reason for the option I delete in patch 3 is unclear to me. > This way we could never add additional repositories. Good catch. That pattern is used in a few places, assuming that isar-apt is the only repo that could have possibly changed. Maybe that whole pattern should be revised and we go for plain "apt-get update" Henning > Andreas Reichel (3): > Fix path to user gpg-keys > Refactor gpg code to use apt code > Use all source lists in target root apt > > meta/classes/isar-bootstrap-helper.bbclass | 14 ++++++++---- > .../isar-bootstrap/isar-bootstrap.inc | 22 > +++++++++---------- 2 files changed, 21 insertions(+), 15 deletions(-) >