From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6669723628337102848 X-Received: by 2002:a5d:6988:: with SMTP id g8mr13832194wru.117.1555941422469; Mon, 22 Apr 2019 06:57:02 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a5d:4046:: with SMTP id w6ls1247109wrp.14.gmail; Mon, 22 Apr 2019 06:57:01 -0700 (PDT) X-Google-Smtp-Source: APXvYqwGnGQOsK8QsDcZJlJjpTEIGCbpkH+7P5vVASPBjP1oTwdtLQGddRn/pu2PtlZ6fhdb/7m1 X-Received: by 2002:adf:cf0c:: with SMTP id o12mr13298104wrj.16.1555941421771; Mon, 22 Apr 2019 06:57:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555941421; cv=none; d=google.com; s=arc-20160816; b=TBfFc9oGQ1PnFp+6zZjeLi7Pd5mTXtn0ZgaUdjxbggBSNsUijgtmvQTypC5eLOccQg nAqPsDI/rRTH3+uHcM9Tpas8ej3cXqP1R9TVOEf1kPq68kvUp3aj1LLs4uc21bCiUGvc yeZ3cvOUgVAachSuLVhJRjJH729a4iL4SZ5CVH/RJCyMwThhDYyyvOKQ2rKVguM5oBKn tIoOC90etebHe50bZuFO1OEqXIjG/xS7fDWDs9EQ0QBVgMUxkmwu5pLoPUiRl40Hb6d8 atakcOxYMmyvnfwmjCoE7EcVavGAG/q5KPuTjSW6KMQyc9C0YV69ol9gJ8cS+G3ZDSAw E5sg== 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:cc:to :subject; bh=zbAw8jIq3CTp6KEOtYRD6MZb1sNcb1Sw3DRRdpKcKdA=; b=ha9lrpSIcpSoQHqWz+FdHx8Iw2avzbKkWk2as/SRHB82ECssabeXcGY/3yDRD7CT/E QQMNUnHK6vyxYg3zJcIyxHgBdyLL0EsHa4wr4AyFs9vM9HV1CCHz+NlleyQPY1uNKbIC IT794aTZeb/glyleA3T9v2jqrp8PySaOQUoDSLrj1M85vZYUx+o62yAPjELAhl9Niyit Go6iso8zIKCkke/Xj8fq6oASFoA89rfLFG9fK82kgIhQav9w5FhogdULwAeW+SWRqwDs ASVgnsmNlejTm2wGHAInHXOpzj3J70jJiCC2acmyYtgr/na82sdT4SP+ezMR+xcvo7tb 1mLQ== 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 t17si805214wri.5.2019.04.22.06.57.01 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 22 Apr 2019 06:57:01 -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.1.29] (98.66-180-91.adsl-dyn.isp.belgacom.be [91.180.66.98] (may be forged)) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id x3MDv0J8028125 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Apr 2019 15:57:00 +0200 Subject: Re: [PATCH v8 1/7] Revert "isar-bootstrap: Allow to set local keys in DISTRO_APT_KEYS" To: Henning Schild Cc: Andreas Reichel , isar-users@googlegroups.com References: <20190321151526.12001-1-andreas.reichel.ext@siemens.com> <20190321151526.12001-2-andreas.reichel.ext@siemens.com> <948fa832-67d1-37d1-02b0-7120ab7546d4@ilbers.de> <20190415111157.GA12152@iiotirae> <20190416101210.3092c275@md1za8fc.ad001.siemens.net> From: "Maxim Yu. Osipov" Organization: ilbers GmbH Message-ID: <9712aa06-3700-999d-80db-8c725ed19cb9@ilbers.de> Date: Mon, 22 Apr 2019 15:56:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190416101210.3092c275@md1za8fc.ad001.siemens.net> 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: moTESdAkVOaf On 4/16/19 10:12 AM, Henning Schild wrote: > Am Tue, 16 Apr 2019 06:54:51 +0200 > schrieb "Maxim Yu. Osipov" : > >> On 4/15/19 1:11 PM, Andreas Reichel wrote: >>> On Mon, Mar 25, 2019 at 12:20:10PM +0100, Maxim Yu. Osipov wrote: >>>> 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. >>> >>> Okay. >>> >>>> >>>> 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) >>> >>> in DL_DIR - Yes, where you can get name collisions with several >>> keys since you cannot rename the files with your code via bitbake >>> URL parameter. >> >> Well...And how this problem is related with my patch? >> My patch fixes the problem with locally stored keys, as >> Local fetcher module puts the file under >> ${WORKDIR}/, so >> gpg in do_generate_keyring() task can't find it. >> >> >>>> directory: >>>> >>>> I've build the current 'master' for target >>>> multiconfig:rpi-jessie:isar-image-base. >>> >>> I gave you an example where it broke for me. Raspbian is not one of >>> these. >>> >>> https://archive.raspbian.org/raspbian.public.key >>> >>> Is there a subdir after the domain? - No ! Does it fit to my >>> example? => No. Does your argument with raspbian make sense now? => >>> No. >> >> Again, my patch fixes the problem with local keys. >> It does nothing about fetching remote keys - it just doesn't break >> existing functionality. > > While i do agree that a revert looks like blaming a patch and an author > for doing something wrong, i fail to get why this comes up so late in > the review. My first feedback was ignored by unknown reason. Yes Andreas can rebase yet again and turn the revert into > something else, in the end the code will be the same. > > The revert question was already discussed in v3. Let us talk content > and that series is in very good shape. > > I would suggest to merge that and accept a test-case / example on top. Not merged, as problems with the latest v9 series were discovered during testing. Maxim. > > Henning > >> >>>> >>>> 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. >>>> >>> Then I have to rebase - without revert - , which may take some >>> time... >> >> OK. >> >> Regards, >> Maxim. >> >>> Regards, >>> Andreas >>> >>>> 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 >>> >> >> > -- 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