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 15936C433EF for ; Fri, 22 Oct 2021 19:47:15 +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 225C860E8C for ; Fri, 22 Oct 2021 19:47:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 225C860E8C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org 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 C8FAA831B2; Fri, 22 Oct 2021 21:47:10 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=debian.org 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 9FF8280615; Fri, 22 Oct 2021 21:47:08 +0200 (CEST) Received: from cascadia.aikidev.net (cascadia.aikidev.net [173.255.214.101]) by phobos.denx.de (Postfix) with ESMTP id C634D80615 for ; Fri, 22 Oct 2021 21:47:04 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=debian.org Authentication-Results: phobos.denx.de; spf=none smtp.mailfrom=vagrant@debian.org Received: from localhost (unknown [IPv6:2600:3c01:e000:21:21:21:0:100b]) (Authenticated sender: vagrant@cascadia.debian.net) by cascadia.aikidev.net (Postfix) with ESMTPSA id 421401AA2C; Fri, 22 Oct 2021 12:47:03 -0700 (PDT) From: Vagrant Cascadian To: Andre Przywara Cc: Tom Rini , Marek =?utf-8?Q?Beh=C3=BAn?= , Peter Robinson , Matthias Brugger , Heinrich Schuchardt , Samuel Holland , Pali =?utf-8?Q?Roh=C3=A1r?= , 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 In-Reply-To: <20211022182049.2ff35e08@donnerap.cambridge.arm.com> 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> <20211022182049.2ff35e08@donnerap.cambridge.arm.com> Date: Fri, 22 Oct 2021 12:46:59 -0700 Message-ID: <87ilxoon9o.fsf@yucca> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" 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 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2021-10-22, Andre Przywara wrote: > On Fri, 22 Oct 2021 09:47:35 -0700 > Vagrant Cascadian wrote: >> On 2021-10-22, Tom Rini wrote: >> > On Fri, Oct 22, 2021 at 04:56:09PM +0100, Andre Przywara wrote:=20=20 >> >> On Fri, 22 Oct 2021 11:09:27 -0400 >> >> Tom Rini wrote:=20=20 >>=20 >> >> > On Fri, Oct 22, 2021 at 04:59:22PM +0200, Marek Beh=C3=BAn wrote:= =20=20 >> >> > > On Fri, 22 Oct 2021 12:09:19 +0200 >> >> > > Heinrich Schuchardt wrote: >> >> > >=20=20=20=20=20 >> >> > > > On 10/21/21 15:00, Marek Beh=C3=BAn wrote:=20=20=20=20 >> >> > > > > BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO fo= r mvebu >> >> > > > > platform in Kconfig? >> >> > > > >=20=20=20=20=20=20=20 >> >> > > >=20 >> >> > > > We should only use 'imply' for suggested settings and never for= hard=20 >> >> > > > requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So imply= ing it=20 >> >> > > > for mvebu would be redundant. >> >> > > >=20 >> >> > > > In an OS distribution we only want to ship a single version of = mkimage.=20 >> >> > > > So it is good to elimate symbol CONFIG_MXS. >> >> > > >=20 >> >> > > > How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPT= O. >> >> > > >=20 >> >> > > > Tom wrote regarding this aspect in=20 >> >> > > > https://lists.denx.de/pipermail/u-boot/2021-September/460251.ht= ml: >> >> > > >=20 >> >> > > > "if we're building a generically useful tool, we don't want ano= ther >> >> > > > symbol for it."=20=20=20=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=20=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 Ope= nSSL. >> >> 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=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 wh= at >> > I was hoping to see. So I want to know everyone else is doing, rather >> > than we hope they're doing.=20=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?=20 The various .h includes are all that I saw, and I *think* all in the tools/ directory, but yeah, if this is really the case that no openssl code ends up in the board-specific binaries, that simplifies things considerably. > The problems are about *shipping* openssl code, which you only do for > u-boot-tools - where it now can be disabled. Probably won't disable it for u-boot-tools in Debian (reluctantly riding on the system library exception), but the tools builds that are part of the build process would be nice to be able to disable. >> 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. Sure, if there is no actual openssl code embedded in the resulting binary with GPLv2 code, it shouldn't be a problem... It's a mess of an issue to tease out exactly what codepaths trigger and do not trigger the compatibility issues between openssl and GPL... Depending on openssl in a project with GPLv2-only code does seem at risk to introduce license compatibility issues without sufficient and constant review and dilligence, even if it is technically ok how it is done right now... live well, vagrant --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCYXMVNAAKCRDcUY/If5cW qg4zAQC2aM3Q+O1QbGgV/GswMwWVTXlz1VHufPuBLmAIsGL+OgEAracyAWxnI/Qe /nI6kQ0jFWXNTNA8JJ0gsM4MOC6fqAA= =+Yn2 -----END PGP SIGNATURE----- --=-=-=--