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

[Vagrant Cascadian]

On 2021-10-22, Andre Przywara wrote:
> On Fri, 22 Oct 2021 09:47:35 -0700
> Vagrant Cascadian <vagrant at 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 at 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 at 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...


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20211022/63ac5c22/attachment.sig>