Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 5888 bytes --]

On Fri, Oct 22, 2021 at 12:46:59PM -0700, Vagrant Cascadian wrote:
> On 2021-10-22, Andre Przywara wrote:
> > On Fri, 22 Oct 2021 09:47:35 -0700
> > Vagrant Cascadian <vagrant@debian.org> wrote:
> >> On 2021-10-22, Tom Rini wrote:
> >> > On Fri, Oct 22, 2021 at 04:56:09PM +0100, Andre Przywara wrote:  
> >> >> On Fri, 22 Oct 2021 11:09:27 -0400
> >> >> Tom Rini <trini@konsulko.com> wrote:  
> >> 
> >> >> > On Fri, Oct 22, 2021 at 04:59:22PM +0200, Marek Behún wrote:  
> >> >> > > On Fri, 22 Oct 2021 12:09:19 +0200
> >> >> > > Heinrich Schuchardt <heinrich.schuchardt@canonical.com> wrote:
> >> >> > >     
> >> >> > > > On 10/21/21 15:00, Marek Behún wrote:    
> >> >> > > > > BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for mvebu
> >> >> > > > > platform in Kconfig?
> >> >> > > > >       
> >> >> > > > 
> >> >> > > > We should only use 'imply' for suggested settings and never for hard 
> >> >> > > > requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So implying it 
> >> >> > > > for mvebu would be redundant.
> >> >> > > > 
> >> >> > > > In an OS distribution we only want to ship a single version of mkimage. 
> >> >> > > > So it is good to elimate symbol CONFIG_MXS.
> >> >> > > > 
> >> >> > > > How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPTO.
> >> >> > > > 
> >> >> > > > Tom wrote regarding this aspect in 
> >> >> > > > https://lists.denx.de/pipermail/u-boot/2021-September/460251.html:
> >> >> > > > 
> >> >> > > > "if we're building a generically useful tool, we don't want another
> >> >> > > > symbol for it."    
> >> >> > > 
> >> >> > > 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.
> >> >> > > 
> >> >> > > But I still think it should be possible to cripple these tools if the
> >> >> > > developer wants to disable libcrypto due to embedded environment.    
> >> >> 
> >> >> 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 OpenSSL.
> >> >> This should be covered by TOOLS_LIBCRYPTO=[yn] and "make
> >> >> tools-only_defconfg && make tools", and Samuel's patch actually fixes the
> >> >> build (at least somewhat, I still get link errors).  
> >> >
> >> > 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.  
> >> 
> >> Thanks for bringing this to my attention!
> >> 
> >> 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.
> >> 
> >> 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 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...
> >> 
> >> 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...

There's still the long standing request to migrate the tooling to use a
different library, but it's apparently not been a large enough concern
of company with concerns to fund a developer of theirs to do the
migration.  I feel like that might be one of the better, at least in
terms of license, fixes for this issue.

And then maybe we do just need a way to say if you're building for
platform X then you must also have the crypto requirement resolved to
build mkimage.  And conversely if you aren't building those platforms,
it's OK to not.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]