From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6699413522129879040 X-Received: by 2002:a1c:e914:: with SMTP id q20mr6482141wmc.55.1561709691249; Fri, 28 Jun 2019 01:14:51 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a7b:cb50:: with SMTP id v16ls512603wmj.3.gmail; Fri, 28 Jun 2019 01:14:50 -0700 (PDT) X-Google-Smtp-Source: APXvYqzMpslKMx+dI04rrlA4GZ8wEt67Ym3PLQuMZcnu9fqE/FvXSZ5H7jx3R7vO/hPw4H9KiLkt X-Received: by 2002:a1c:9696:: with SMTP id y144mr6271363wmd.73.1561709690695; Fri, 28 Jun 2019 01:14:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561709690; cv=none; d=google.com; s=arc-20160816; b=pCtWVEdkWjjd8ihDbHGTdrBewGDtAeg92fM9QjfmE/hLdtGy6HLtPXTkPGW40CyqNd T4nwxLgLbH8rZ1t2U1HmzRwvkeHnxUBbFgOyzTXIGfmfTSbux0tkMoDHdA/L6Jy0An5H TeEzp6vki97Rhq6hT2BmvT6juU2EYy+Qh1VBWEuSH0u2iRuxXJ6cNnCUATRinl4F0fJR +iTJrxh1xmVpnH/9l2M4vkeKrAdEEOcCrJrTSKiOUtVMFX/yfS8Rigq+kiz9vI6vXGfG pDNd3W3+NAzalT6MWh3fzED5/hx5yGw4huVKG7MS8wcvV3x5msViRsacNCt6LKtFA4lE HCCg== 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=8PfaJz16yS04Unn+0b9VbY+iXC1/j289JXzuJfhSKvs=; b=kI1z3SHTzyjUa4eGhRweNB2R4fVYEnPj5kbQa+0dJ9XG/NhPwGUfMhT7sOZrW03EHP XdWFI3mU09qpRNdPNSQWmBuQCGCIoLUEXqBGevKI34TPFULuByrNFmfzwr8uXTZsdO+t AD0HA+JXiFUAELEKSXwiUntN6kG30htcFUjojdT0mUs8Cbf28DW7FjD5KwvqDrankoUd Q8UI+UDaMOpqLj8oqmUt2eeV6enWnb+IgB0HrOQbU6aZLlst9VzdDGRwKd65PqqREBws h8N4Ft2Y2WdM4oGo/ZBDgwzL8bAtMGE9l8FjwSBl7fY0hdJMDy32Hu/ttSeoZN/iFH2u /2UA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id v21si480103wmc.1.2019.06.28.01.14.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Jun 2019 01:14:50 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.2 as permitted sender) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id x5S8En2u026327 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 28 Jun 2019 10:14:50 +0200 Received: from md1za8fc.ad001.siemens.net ([139.25.69.32]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id x5S8En63024900; Fri, 28 Jun 2019 10:14:49 +0200 Date: Fri, 28 Jun 2019 10:14:48 +0200 From: Henning Schild To: Cc: isar-users Subject: Re: base-apt signing interface could be improved Message-ID: <20190628101448.7ce52953@md1za8fc.ad001.siemens.net> In-Reply-To: <1146168d-aa91-44b6-b37c-3a3b20f7a013@googlegroups.com> References: <20190606154558.7eea07bd@md1za8fc.ad001.siemens.net> <20190614102255.0c782b51@md1za8fc.ad001.siemens.net> <20190617131937.2852d692@md1za8fc.ad001.siemens.net> <51ca3229-73cd-20d6-2c8d-722a4311d13e@siemens.com> <1146168d-aa91-44b6-b37c-3a3b20f7a013@googlegroups.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: fTosbbXHLOnS Hi Vijai, you are assuming kas and the agent implementation that mentor proposed there. two things to keep in mind: - kas is not just for Isar, but also yocto/oe - Isar can be used without kas - kas can be used without docker The current implementation does not work in so many places because it was never applied on a real use-case. You now find the limitations because you have that use-case. Again, please implement the full story, including documentation, and propose patches that enable such a use-case. These small intermediate steps just bring isar and kas into the next intermediate state between early-feature and working. And what might seem correct today may become a revert and an API breakage tomorrow. Henning Am Thu, 27 Jun 2019 23:30:31 -0700 schrieb : > Hi Claudius, > > Just wondering, why cant the BASE_REPO_KEY be a list of key ids > instead of the keyfile itself. Since we are using the host gpg agent > anyways for signing. > > Later if this key needs to be added to apt sources key ring, it can > be exported. > > The one advantage is that it eliminates the need to maintain the > keyfiles in host. It is redundant. Anyway one would need to have the > keys as part of gpg keyring to successfully sign the repo. > > Thanks, > Vijai Kumar K > > On Monday, June 17, 2019 at 5:06:29 PM UTC+5:30, Claudius Heine wrote: > > > > Hi, > > > > On 17/06/2019 13.19, [ext] Henning Schild wrote: > > > Am Fri, 14 Jun 2019 06:50:58 -0700 > > > schrieb "Amy_...@mentor.com " > >: > > > > > >> On Friday, 14 June 2019 04:23:00 UTC-4, Henning Schild wrote: > > >>> > > >>> Am Thu, 13 Jun 2019 09:55:29 -0700 > > >>> schrieb "Amy_...@mentor.com " > >>> >: > > >>> > > >>>> On Thursday, 6 June 2019 09:46:02 UTC-4, Henning Schild > > >>>> wrote: > > >>>>> > > >>>>> Hi, > > >>>>> > > >>>>> i just had a quick look at the implementation of the base-apt > > >>>>> signing for the first time. The interface is not ideal and > > >>>>> has potential for the signing key and the checking key not > > >>>>> actually belonging together. > > >>>>> > > >>>>> As far as i understand the code i read, Isar will start > > >>>>> signing base-apt if BASE_REPO_KEY is set to anything. The > > >>>>> private key it will use to sign the repo is not specified at > > >>>>> all, it will be whatever gnupg defaults to, given its > > >>>>> configuration. > > >>>>> > > >>>>> I would suggest to switch from "SignWith yes" to "SignWith > > >>>>> ", and derive the id from BASE_REPO_KEY. > > >>>>> > > >>>>> Further improvements would be to actually configure gnupg > > >>>>> inside Isar and not rely on an outside configuration. Relying > > >>>>> on the outside config means that all (multi)configs will have > > >>>>> to use the same keypair. So we would add > > >>>>> > > >>>>> BASE_REPO_KEY_PRIVATE and ..._PASSPHRASE > > >>>>> > > >>>>> Now we would create a new gpg homedir next to where we store > > >>>>> base-apt. We would import that one key there and potentially > > >>>>> unlock it with its passphrase. If we clean and rebuild we get > > >>>>> a working gpghome for sure. > > >>>>> > > >>>>> Henning > > >>>>> > > >>>> > > >>>> Hi, > > >>>> > > >>>> Perhaps something like the following ... > > >>>> > > >>>> Of course, since BASE_REPO_KEY permits specifying > > >>>> multiple keys, this raises a question of which keyid? > > >>> > > >>> Oh that is a nice hidden feature, indeed one can specify > > >>> multiple keys there. So that variable should be called > > >>> BASE_REPO_KEYS instead. > > >>> > > >>> And yes reprepro also supports multiple values. So i guess your > > >>> patch is correct and it would probably sign the repo with all > > >>> the keys specified. > > >>> > > >>> Whether that is what we want is another question, and i am not > > >>> sure whether "yes" will also use all keys or just the default > > >>> one. > > >>>> Amy > > >>>> > > >>>> From 5ceb4a2ef97bc7fa6c44cd9ce6f73f9a831773f3 Mon Sep 17 > > >>>> 00:00:00 2001 From: Amy Fong > >>>> > Date: Thu, 13 Jun 2019 12:52:06 -0400 > > >>>> Subject: [PATCH] base-apt: Use BASE_REPO_KEY for signing > > >>>> > > >>>> Extract keyid from BASE_REPO_KEY for signing > > >>>> > > >>>> Signed-off-by: Amy Fong > > > >>>> --- > > >>>> meta/recipes-devtools/base-apt/base-apt.bb | 9 ++++++++- > > >>>> 1 file changed, 8 insertions(+), 1 deletion(-) > > >>>> > > >>>> diff --git a/meta/recipes-devtools/base-apt/base-apt.bb > > >>>> b/meta/recipes-devtools/base-apt/base-apt.bb > > >>>> index 1c0b4c6..81245f7 100644 > > >>>> --- a/meta/recipes-devtools/base-apt/base-apt.bb > > >>>> +++ b/meta/recipes-devtools/base-apt/base-apt.bb > > >>>> @@ -19,8 +19,15 @@ do_cache_config() { > > >>>> sed -e "s#{CODENAME}#"${BASE_DISTRO_CODENAME}"#g" \ > > >>>> ${WORKDIR}/distributions.in > > > >>>> ${CACHE_CONF_DIR}/distributions if [ "${BASE_REPO_KEY}" ] ; > > >>>> then > > >>>> + option="yes" > > >>> > > >>> maybe there is a better name for the variable? > > >>> > > >>> Henning > > >>> > > >>>> + for key in ${BASE_REPO_KEY}; do > > >>>> + keyid=$(wget -qO - $key | gpg --keyid-format > > >>>> 0xlong --with-colons - 2>/dev/null |grep "^pub:" |awk -F':' > > >>>> '{print $5;}') > > >>>> + if [ -n "$keyid" ]; then > > >>>> + option="$keyid" > > >>>> + fi > > >>>> + done > > >>>> # To generate Release.gpg > > >>>> - echo "SignWith: yes" >> > > >>>> ${CACHE_CONF_DIR}/distributions > > >>>> + echo "SignWith: $option" >> > > >>>> ${CACHE_CONF_DIR}/distributions fi > > >>>> fi > > >>>> > > >>> > > >> > > >> How about BASE_REPO_SIGN_KEY? > > > > > > I do not understand what you are trying to solve with changing > > > that name and going back to one-key-only, after you have found > > > that BASE_REPO_KEY is indeed an array and reprepro also accepts > > > an array. > > > > > > Now we need to know what "yes", compared to the array. > > > > > > And any tiny patch like this one, without a proper commit message > > > and description, is not going to lead anywhere good. > > > > > > You guys are doing the full story. kas, signed base-apt, multiple > > > keys, agent-forwarding ... > > > After you are done you should have a clear picture of what > > > currently does not work as expected, and how it can be fixes > > > (your initial implementation). > > > We can then discuss that implementation and incorporate a full > > > patch series including docs into kas and Isar. > > > > > >> commit 42ee1139e8383fc27e7d98be522cb4d306fd170c (HEAD -> > > >> apt_sign) Author: Amy Fong > > > >> Date: Thu Jun 13 12:52:06 2019 -0400 > > >> > > >> base-apt: Use BASE_REPO_SIGN_KEY for signing > > >> > > >> Extract keyid from BASE_REPO_SIGN_KEY for signing > > >> > > >> Signed-off-by: Amy Fong > > > >> > > >> diff --git a/meta/recipes-devtools/base-apt/base-apt.bb > > >> b/meta/recipes-devtools/base-apt/base-apt.bb > > >> index 1c0b4c6..c896add 100644 > > >> --- a/meta/recipes-devtools/base-apt/base-apt.bb > > >> +++ b/meta/recipes-devtools/base-apt/base-apt.bb > > >> @@ -18,9 +18,14 @@ do_cache_config() { > > >> if [ ! -e "${CACHE_CONF_DIR}/distributions" ]; then > > >> sed -e "s#{CODENAME}#"${BASE_DISTRO_CODENAME}"#g" \ > > >> ${WORKDIR}/distributions.in > > > >> ${CACHE_CONF_DIR}/distributions > > >> - if [ "${BASE_REPO_KEY}" ] ; then > > >> + if [ "${BASE_REPO_SIGN_KEY}" ] ; then > > >> + option="yes" > > >> + keyid=$(wget -qO - "${BASE_REPO_SIGN_KEY}" | gpg > > > > > > Using wget, but that is most likely a "file:///" URI. And > > > whenever you do networking in a task, you need to take care of > > > proxies. > > > > Fetching should not be done like this anyway. If something needs to > > be fetched then it should be part of the SRC_URI and be fetched by > > the do_fetch task. The reasons for this are offline reproducibility > > among others. > > > > regards, > > Claudius > > > > > > > > Henning > > > > > >> --keyid-format 0xlong --with-colons - 2>/dev/null |grep "^pub:" > > >> |awk -F':' '{print $5;}') > > >> + if [ -n "$keyid" ]; then > > >> + option="$keyid" > > >> + fi > > >> # To generate Release.gpg > > >> - echo "SignWith: yes" >> > > >> ${CACHE_CONF_DIR}/distributions > > >> + echo "SignWith: $option" >> > > >> ${CACHE_CONF_DIR}/distributions fi > > >> fi > > >> > > >> > > > > > > > -- > > DENX Software Engineering GmbH, Managing Director: Wolfgang > > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, > > Germany Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: > > c...@denx.de > > >