From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D4518C43217 for ; Fri, 22 Oct 2021 17:21:02 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 176666121F for ; Fri, 22 Oct 2021 17:21:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 176666121F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 7B214834A9; Fri, 22 Oct 2021 19:20:59 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id AC628834C1; Fri, 22 Oct 2021 19:20:57 +0200 (CEST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by phobos.denx.de (Postfix) with ESMTP id C5AD68327C for ; Fri, 22 Oct 2021 19:20:53 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=andre.przywara@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0513A1063; Fri, 22 Oct 2021 10:20:53 -0700 (PDT) Received: from donnerap.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 382563F73D; Fri, 22 Oct 2021 10:20:51 -0700 (PDT) Date: Fri, 22 Oct 2021 18:20:49 +0100 From: Andre Przywara To: Vagrant Cascadian Cc: Tom Rini , Marek =?UTF-8?B?QmVow7pu?= , Peter Robinson , Matthias Brugger , Heinrich Schuchardt , Samuel Holland , Pali =?UTF-8?B?Um9ow6Fy?= , u-boot@lists.denx.de, Jagan Teki , "Alex G ." , Artem Lapkin , Priyanka Jain , Sughosh Ganu Subject: Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL Message-ID: <20211022182049.2ff35e08@donnerap.cambridge.arm.com> In-Reply-To: <87v91pnh08.fsf@yucca> References: <20211020024455.48136-2-samuel@sholland.org> <20211020072925.drf6622qhq4yykg6@pali> <20211020142902.12219c45@donnerap.cambridge.arm.com> <20211020134752.62k4fxukucj5rodh@pali> <20211021150048.59bb90d6@thinkpad> <20211022165922.22164ef8@thinkpad> <20211022150927.GJ3577824@bill-the-cat> <20211022165609.1725e93b@donnerap.cambridge.arm.com> <20211022162219.GK3577824@bill-the-cat> <87v91pnh08.fsf@yucca> Organization: ARM X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; aarch64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On Fri, 22 Oct 2021 09:47:35 -0700 Vagrant Cascadian wrote: Hi, > On 2021-10-22, Tom Rini wrote: > > On Fri, Oct 22, 2021 at 04:56:09PM +0100, Andre Przywara wrote: =20 > >> On Fri, 22 Oct 2021 11:09:27 -0400 > >> Tom Rini wrote: =20 >=20 > >> > On Fri, Oct 22, 2021 at 04:59:22PM +0200, Marek Beh=C3=BAn wrote: =20 > >> > > On Fri, 22 Oct 2021 12:09:19 +0200 > >> > > Heinrich Schuchardt wrote: > >> > > =20 > >> > > > On 10/21/21 15:00, Marek Beh=C3=BAn wrote: =20 > >> > > > > BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for= mvebu > >> > > > > platform in Kconfig? > >> > > > > =20 > >> > > >=20 > >> > > > We should only use 'imply' for suggested settings and never for = hard=20 > >> > > > requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So implyi= ng it=20 > >> > > > for mvebu would be redundant. > >> > > >=20 > >> > > > In an OS distribution we only want to ship a single version of m= kimage.=20 > >> > > > So it is good to elimate symbol CONFIG_MXS. > >> > > >=20 > >> > > > How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPTO. > >> > > >=20 > >> > > > Tom wrote regarding this aspect in=20 > >> > > > https://lists.denx.de/pipermail/u-boot/2021-September/460251.htm= l: > >> > > >=20 > >> > > > "if we're building a generically useful tool, we don't want anot= her > >> > > > symbol for it." =20 > >> > >=20 > >> > > OK, so mkimage and dumpimage should be always generic and always > >> > > support all platforms, that makes sense, since the tools can be > >> > > installed as a distribution package. > >> > >=20 > >> > > But I still think it should be possible to cripple these tools if = the > >> > > developer wants to disable libcrypto due to embedded environment. = =20 > >>=20 > >> Well, I don't think this is the real question here, is it? > >> I think the tools part is clear: distros want to build just mkimage, > >> supporting as many platforms as possible, and might need to avoid Open= SSL. > >> This should be covered by TOOLS_LIBCRYPTO=3D[yn] and "make > >> tools-only_defconfg && make tools", and Samuel's patch actually fixes = the > >> build (at least somewhat, I still get link errors). =20 > > > > The problem is, are distros doing a tools-only build, for tools, or are > > they doing it per board? Like, hey, ugh, OpenEmbedded uses > > sandbox_defconfig and cross_tools as the targets. That's not quite what > > I was hoping to see. So I want to know everyone else is doing, rather > > than we hope they're doing. =20 >=20 > Thanks for bringing this to my attention! >=20 > In Debian, the u-boot-tools package is built using tools-only, and for > each of the board-specific targets, it still ends up building the > relevent tools, but we throw them away and do not ship them in any > packages. >=20 > With 2021.10, the board-specific builds made it harder to avoid openssl > with the corresponding tools, and I reluctantly added a dependency on > openssl... (which is technically permitted in Debian, having declared > openssl as a system library to avoid the GPL incompatibilities, but > ... meh.) But this is purely a *build-time* dependency only, right? The resulting images do not have any openssl code in them, they were just *created* (signed) using that code. I don't think this a legal issue? The problems are about *shipping* openssl code, which you only do for u-boot-tools - where it now can be disabled. > I also have been doing some packaging of u-boot for GNU Guix, where I > suspect the stance wouldn't be as willing to accept such a compromise... >=20 > So... I would *love* an option to be able to build a board-only config > without any of the tools; Why is this a problem (see above)? Who is building board builds? It's either the maintainer when creating the binary package, or a curious user, right? And they can surely *use* OpenSSL during build time - if it's needed by the board. Cheers, Andre > do some boards use board-specific tools as > part of their build processes? >=20 >=20 > live well, > vagrant