From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6669723628337102848 X-Received: by 2002:a17:906:4595:: with SMTP id t21mr13487943ejq.153.1553512812157; Mon, 25 Mar 2019 04:20:12 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a17:906:b20c:: with SMTP id p12ls1041597ejz.7.gmail; Mon, 25 Mar 2019 04:20:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqzdUY1Lr81ivcSMDX+OfE/kaqnUAM/sPZ+J9WUlozLKQV1E3sj3i4zJnfLBMew7SE+NuXdE X-Received: by 2002:a17:906:c50:: with SMTP id t16mr13261404ejf.97.1553512811739; Mon, 25 Mar 2019 04:20:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553512811; cv=none; d=google.com; s=arc-20160816; b=Q2JwXnUV26bGiUxEXzv201E3eFj8KFgoRSKzg5i1YrUHZOnSdDUqQLDb/z/eAAVC6l 7CE3g9UioQWZ18sPPboOR9GUGnbSw3t5S/aMzJREmQapgB6liqDuN6F3kb3ot7YD8SBH x/aTPHZ36iKs6d/PFVXsOcd4fBY93bUeyk89izKWabM2Mg3EcFUButbJNsdOjTQ4B51A rtz3PFPLKxmEfag3uwkMulXs8nihfHAuX4ZZc6kW/9VEKDM6yILLz7lGOqx64qLAvo4O yIqcnCAehBcbrVXdOjVmaNIIBFpRSM6UMBTycUMp4XcBTZQKTP/wpwGPvrra4aGF5M8o 3GEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:organization:from:references:to:subject; bh=pWoWvQ4knYtPt0yQE7+KA01MAciGkY2Ud4PxUbiDOyw=; b=ujprnGepSwGMuw9B7Mt95J8MnpRFp9+m7XB3a8LZZBi0RxruIdaQ51jWSPVncUHZ1M iHP9SotWN3BXLmmUU8ZKxjKwQeYDFWIQ0l6tDS8l/FgStXyYC26fHe/vSACcSwWpWdAH nuVSAh+X1NmbbNuT0BtOoQTP85vbuOgAGR3Vzlr4uOdd6nklAAQm8yg4vXY1WDGXqP8k 8cR+APHLK2tTrljFBRNBLfxVPjTY6SFS6tiNIgDRuhAnN2dkKJsFHGtIFmtLFVOS9n6a d+gB1GI51KPtjJgUPcrEBPtvzavrfct91cfk7H5BmQsAq3KekLh+lM5SBDZL6eGhyMNj /4Hg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of mosipov@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=mosipov@ilbers.de Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id a7si694350edb.1.2019.03.25.04.20.11 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 25 Mar 2019 04:20:11 -0700 (PDT) Received-SPF: pass (google.com: domain of mosipov@ilbers.de designates 85.214.156.166 as permitted sender) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of mosipov@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=mosipov@ilbers.de Received: from [192.168.50.164] (d51a48a80.access.telenet.be [81.164.138.128]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id x2PBKAn5017552 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 25 Mar 2019 12:20:10 +0100 Subject: Re: [PATCH v8 1/7] Revert "isar-bootstrap: Allow to set local keys in DISTRO_APT_KEYS" To: "Andreas J. Reichel" , isar-users@googlegroups.com References: <20190321151526.12001-1-andreas.reichel.ext@siemens.com> <20190321151526.12001-2-andreas.reichel.ext@siemens.com> From: "Maxim Yu. Osipov" Organization: ilbers GmbH Message-ID: <948fa832-67d1-37d1-02b0-7120ab7546d4@ilbers.de> Date: Mon, 25 Mar 2019 12:20:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190321151526.12001-2-andreas.reichel.ext@siemens.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: Yd+UFNYUqNKh Hi Andreas, On 3/21/19 4:15 PM, Andreas J. Reichel wrote: > From: Andreas Reichel > > This reverts commit af983a13b6f4cee5d4af5e5cf6318231e02775c9. > > This commit broke usage of remote keys, where they usually come from. > If fetching "http://example.com/dir1/dir2/key", the file is fetched > into the subdir WORKDIR/dir1/dir2/, which breaks with this code. > However it succeeds with absolute paths. > We do not want to guess where the downloaded file will be. This does > not work anymore if the key is downloaded from remote with a URL. > Furthermore, a user could specify "subdir" as fetcher parameter > or other things, which break this. In general it's better to avoid reverting the patches. I disagree with the statement that "commit af983a13 broke usage of remote keys" - I wrote you a month ago (see forwarded email below) that this patch doesn't break Raspbian build - the key is put also under downloads (DL_DIR) directory: I've build the current 'master' for target multiconfig:rpi-jessie:isar-image-base. Sorry for copy-paste ;): <<<< isar/build$ find -name raspbian.public.key ./downloads/raspbian.public.key ./tmp/work/raspbian-jessie-armhf/isar-bootstrap-target/raspbian.public.key >>> So I don't accept this patch. Regards, Maxim. -------- Forwarded Message -------- Subject: Re: [PATCH 0/1] Fix remote key fetching apt keyring Date: Wed, 20 Feb 2019 12:58:09 +0100 From: Maxim Yu. Osipov Organization: ilbers GmbH To: Jan Kiszka , [ext] Andreas J. Reichel , isar-users@googlegroups.com, Baurzhan Ismagulov 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. > > This is really fixed in a follow-up commit. > > Signed-off-by: Andreas Reichel > --- > meta/recipes-core/isar-bootstrap/isar-bootstrap.inc | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc b/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc > index c1b571a..2910eea 100644 > --- a/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc > +++ b/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc > @@ -40,8 +40,9 @@ python () { > d.setVar("DEBOOTSTRAP_KEYRING", "--keyring ${APTKEYRING}") > for key in distro_apt_keys.split(): > url = urlparse(key) > - d.appendVar("SRC_URI", " " + key) > - d.appendVar("APTKEYFILES", " " + wd + url.path) > + filename = os.path.basename(url.path) > + d.appendVar("SRC_URI", " %s" % key) > + d.appendVar("APTKEYFILES", " %s" % filename) > if bb.utils.to_boolean(d.getVar('ISAR_USE_CACHED_BASE_REPO')): > own_pub_key = d.getVar("BASE_REPO_KEY", False) > if own_pub_key: > -- 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