GNU bug report logs - #34717
GPL and Openssl incompatibilities in u-boot and possibly others

Previous Next

Full log

View this message in rfc822 format

From: Vagrant Cascadian <vagrant <at> debian.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 34717 <at> debbugs.gnu.org
Subject: bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others
Date: Wed, 06 Mar 2019 20:17:10 -0800

[Message part 1 (text/plain, inline)]

On 2019-03-06, Ludovic Courtès wrote:
> Vagrant Cascadian <vagrant <at> debian.org> skribis:
>
>> The u-boot package definition includes openssl amoung it's inputs, but
>> is also a GPL2+ software project... but the GPL and OpenSSL licenses are
>> incompatible:
>>
>>   https://www.gnu.org/licenses/license-list.html#OpenSSL
>
> Thanks for bringing it up.
>
>> I'm not sure if there's a simple way to search for other packages with
>> license:gpl and openssl as an input in order to do a quick pass at
>> auditing... some packages may use the openssl binary as part of the
>> build process or tests, and not linking any GPLed code against it; in
>> those cases there would be no license conflict.
>
> openssl <at> 1.0 has 7,029 dependent packages, so it may be hard to sort it
> out.  I wonder what would be the best way to approach it.

How many of them are also license:gpl* though? That would hopefully
reduce the scope somewhat, or maybe even significantly...

If "guix package --search= ..." could be extended to to also search
other fields, e.g. license: and dependencies: ... it might not be so
difficult a search.


>> In the Debian u-boot packaging, some of the features using openssl are
>> disabled, and some of the u-boot targets that require openssl are not
>> part of the packages. I'd be happy to help with making such adjustments
>> if this is deemed the better approach for u-boot specifically.
>
> That’d be great.  We could definitely remove the OpenSSL dependency when
> it’s not needed.

For what it's worth, I did do local builds of all the current u-boot-*
targets in guix with openssl removed from inputs, and the only one that
failed to build without openssl was u-boot-tools.


> In cases where it is needed, it would be nice to see what it’s used
> for.  Many projects use OpenSSL just for its cryptographic hash
> functions, for example, and there’s plenty of options to choose from if
> that’s all that’s needed (Gcrypt, Nettle, etc.).

I think it is using it for generating and verifying rsa signatures, and
probably other similar basic things. So far I had only thought about
gnutls, but if gcrypt or nettle are other options, then so much the
better.

I briefly looked at gnutls's openssl compatibility layers, but it didn't
seem to implement sufficiently similar include files, which is largely
all that it is doing.


> I guess this should be discussed with upstream.

I did bring it upstream a little over a year ago, and the response was
pretty much to rewrite it with gnutls, and I pointed out the most likely
files that needed updating:

  https://lists.denx.de/pipermail/u-boot/2017-November/312483.html
  https://lists.denx.de/pipermail/u-boot/2017-December/313616.html
  https://lists.denx.de/pipermail/u-boot/2017-December/313742.html

I suspect it's pretty much a "patches accepted" sort of scenario.


live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.