GPL and Openssl incompatibilities in u-boot and possibly others

  • Open
  • quality assurance status badge
Details
8 participants
  • Adonay Felipe Nogueira
  • Dr. Arne Babenhauserheide
  • Danny Milosavljevic
  • Jack Hill
  • Leo Famulari
  • Ludovic Courtès
  • Maxime Devos
  • Vagrant Cascadian
Owner
unassigned
Submitted by
Vagrant Cascadian
Severity
normal
V
V
Vagrant Cascadian wrote on 3 Mar 2019 02:58
(address . bug-guix@gnu.org)
87tvgkiurn.fsf@ponder
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:


It doesn't explain the details of *why* they're incompatibly, which is
astoundingly unhelpful. The best explanation I've found is here:


Essentially, the Openssl/SSLeay license(s) place additional restrictions
requiring "advertising" clause when distributing in binary form, while
the GPL forbids placing additional restrictions on distribution.


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.


Since I believe the incompatibility is only invoked when distributing
binaries, GNU Guix may be in an interesting position to at least make a
simple workaround for affected packages by using:

(arguments `(#:substitutable? #f))

Thus disabling substitutes. Though it poses a curious philosophical
question weather that is an acceptible/appropriate workaround for GNU
Guix...


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.


Other more long-term approaches:

Patch (and submit upstream) the affected packages to support using other
GPL compatible libraries, such as gnutls.

If upstream is reasonably able to add a license exception, that could
also resolve the issue:



live well,
vagrant
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCXHs0vAAKCRDcUY/If5cW
qpx5AQD1tIZOPkaVIfPvFxiCO5fh+3pHugUaX4ysih2phFjTAAEAvlbLHriinnPU
PbP4TpS6+1WPLiuGiADU1wz75h8LZQk=
=iuiX
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 6 Mar 2019 16:15
(name . Vagrant Cascadian)(address . vagrant@debian.org)(address . 34717@debbugs.gnu.org)
87zhq8f2zz.fsf@gnu.org
Hi Vagrant,

Vagrant Cascadian <vagrant@debian.org> skribis:

Toggle quote (6 lines)
> 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.

Toggle quote (6 lines)
> 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@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.

Toggle quote (10 lines)
> Since I believe the incompatibility is only invoked when distributing
> binaries, GNU Guix may be in an interesting position to at least make a
> simple workaround for affected packages by using:
>
> (arguments `(#:substitutable? #f))
>
> Thus disabling substitutes. Though it poses a curious philosophical
> question weather that is an acceptible/appropriate workaround for GNU
> Guix...

Hmm yeah, that doesn’t sound right. :-)

Toggle quote (5 lines)
> 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.

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 guess this should be discussed with upstream.

Thanks,
Ludo’.
D
D
Danny Milosavljevic wrote on 6 Mar 2019 19:12
(name . Ludovic Courtès)(address . ludo@gnu.org)
20190306191252.577335c1@scratchpost.org
Hi,

Toggle quote (3 lines)
> openssl@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.

I can't believe I seriously suggest the following but:

A license algebra and guix commands that automate part of the lawyering,
by using the "license" field of the packages, which would now have at
least "and-license" and "or-license" operators and maybe also finer-grained
ones, and a placeholder for "it's too difficult, sort it out manually"
(maybe just detect the list we have now as "it's too difficult").

If we do it, we should add a disclaimer that it doesn't replace the need
for legal counsel entirely.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlyADaQACgkQ5xo1VCww
uqUcfQf/evYYUJTPsIxtOB2gIzcrO3GAluInaWhNSbYX29HbvxukUou4FEBxMqd5
qxm6G8jaKiwwSm9KgDEmp6hQ6B/nWzKHq0ZjSryX3QWG3nO/wr8rw3BtgWv/bAr0
IKhcw9lO+dV9OXDN6LLM/8oQ83hyyJpez2NkHQaOAJQ2bl5dNnMErtwFSZ2FCb+b
R0Y3sJOb6Ni5eQ1iCHWaQqWjyMsV+7+dKHMqZ66jX/nKcfw7DTCEdmtFFPW/0nqL
H/tzqTwaQtQp5WboYu2n8rPbHBEc4xRSCADgCIh7bOFgpN5rTM6aMicSfOjdFsuo
vPqUYRv0OnCiMgrzBlu1BYLpbj3fyg==
=dirL
-----END PGP SIGNATURE-----


V
V
Vagrant Cascadian wrote on 7 Mar 2019 05:17
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 34717@debbugs.gnu.org)
87ftrzuxmh.fsf@ponder
On 2019-03-06, Ludovic Courtès wrote:
Toggle quote (19 lines)
> Vagrant Cascadian <vagrant@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@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.


Toggle quote (8 lines)
>> 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.


Toggle quote (5 lines)
> 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.


Toggle quote (2 lines)
> 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:


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


live well,
vagrant
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCXICbRwAKCRDcUY/If5cW
qslIAP9ScQrLSi6R54J1NV5/L6Uh/os0qMg+RiswaDGV+kWtvQEAlfpxaLRUbI7+
Bt+71U4GBtM71PoXnDh1xExzjF9A5Ag=
=JlTa
-----END PGP SIGNATURE-----

V
V
Vagrant Cascadian wrote on 8 Mar 2019 00:02
(name . Ludovic Courtès)(address . ludo@gnu.org)
87o96m8f09.fsf@ponder
On 2019-03-06, Vagrant Cascadian wrote:
Toggle quote (7 lines)
> On 2019-03-06, Ludovic Courtès wrote:
>> Vagrant Cascadian <vagrant@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
...
Toggle quote (12 lines)
>>> 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.

I've tested that the attached patch builds all u-boot-* targets on
x86_64 (cross-building most of them), with openssl removed from
native-inputs.

Unfortunately, u-boot-tools fails it's tests on aarch64 and armhf, but
that appears to be the case with or without this patch, so it's no worse
off than it was...

I'm not sure where it would be appropriate to add more comments
regarding the GPL/Openssl incompatibilities; e.g. if someone were to
propose adding one of the u-boot targets that requires it, they might
just go ahead and re-add the openssl input...


live well,
vagrant
From ee613387c49ca60905e0a40af8af017828c8aec8 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian <vagrant@debian.org>
Date: Thu, 7 Mar 2019 21:50:58 +0000
Subject: [PATCH] gnu: u-boot: Remove openssl input.


* gnu/packages/bootloaders (u-boot): Remove openssl from native-inputs.
(u-boot-tools): Disable FIT_SIGNATURES in tests.
---
gnu/packages/bootloaders.scm | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)

Toggle diff (30 lines)
diff --git a/gnu/packages/bootloaders.scm b/gnu/packages/bootloaders.scm
index b0617f452a..15953ab75e 100644
--- a/gnu/packages/bootloaders.scm
+++ b/gnu/packages/bootloaders.scm
@@ -391,7 +391,6 @@ tree binary files. These are board description files used by Linux and BSD.")
("dtc" ,dtc)
("flex" ,flex)
("lz4" ,lz4)
- ("openssl" ,openssl)
("python-2" ,python-2)
("python2-coverage" ,python2-coverage)
("python2-pytest" ,python2-pytest)
@@ -440,9 +439,14 @@ also initializes the boards (RAM etc).")
(("def test_ctrl_c")
"@pytest.mark.skip(reason='Guix has problems with SIGINT')
def test_ctrl_c"))
- ;; This test requires a sound system, which is un-used in u-boot-tools.
(for-each (lambda (file)
(substitute* file
+ ;; Disable signatures, due to GPL/Openssl
+ ;; license incompatibilities. See
+ ;; https://bugs.gnu.org/34717 for details.
+ (("CONFIG_FIT_SIGNATURE=y") "CONFIG_FIT_SIGNATURE=n")
+ ;; This test requires a sound system, which is un-used
+ ;; in u-boot-tools.
(("CONFIG_SOUND=y") "CONFIG_SOUND=n")))
(find-files "configs" "sandbox_.*defconfig$"))
#t))
--
2.20.1
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCXIGjCAAKCRDcUY/If5cW
qtC9AQCxXgZ4A+ZUWsro4IGGBHoxoNvhGIxLvlKKKhjU3IFtJwEAyLgcEDnw6zlK
3gBaT/P4/RQGQJh9nPCsyM31s/KkcA4=
=fg6f
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 8 Mar 2019 10:59
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)
87imwtit4p.fsf@gnu.org
Danny Milosavljevic <dannym@scratchpost.org> skribis:

Toggle quote (4 lines)
> I can't believe I seriously suggest the following but:
>
> A license algebra [...]

Yeah, licensing is anything but an algebra, so let’s not take that path.
:-)

Ludo’.
L
L
Ludovic Courtès wrote on 8 Mar 2019 11:08
(name . Vagrant Cascadian)(address . vagrant@debian.org)(address . 34717@debbugs.gnu.org)
87bm2lispp.fsf@gnu.org
Hi

Vagrant Cascadian <vagrant@debian.org> skribis:

Toggle quote (2 lines)
> On 2019-03-06, Ludovic Courtès wrote:

[...]

Toggle quote (10 lines)
>> openssl@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.

Here’s an estimate:

Toggle snippet (4 lines)
$ guix package -s "" |recsel -e 'license ~ "GPL"' -e 'dependencies ~ "openssl"' |grep ^name| wc -l
265

You can view the list of packages like this:

Toggle snippet (3 lines)
guix package -s "" |recsel -e 'license ~ "GPL"' -e 'dependencies ~ "openssl"' -p name,version

Toggle quote (12 lines)
>>> 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.

Not that bad!

Toggle quote (14 lines)
>> 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.

Yeah, GnuTLS’ OpenSSL compat layer has been bitrotting since forever.

But really rather than GnuTLS they should target one of these crypto
libraries, which seem to be a better fit.

Toggle quote (12 lines)
>> 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.

I guess “we” should consider doing it at some point. Changing the RSA
signature code to use another API can’t be that hard™. ;-)

I see from the message above that PEM encoding/decoding may also be
needed, which Gcrypt doesn’t provide.

Thanks,
Ludo’.
L
L
Ludovic Courtès wrote on 8 Mar 2019 11:16
(name . Vagrant Cascadian)(address . vagrant@debian.org)(address . 34717@debbugs.gnu.org)
877ed9isc2.fsf@gnu.org
Ludovic Courtès <ludo@gnu.org> skribis:

Toggle quote (2 lines)
> Here’s an estimate:

Oops, I was doing an “or” instead of an “and”; here’s the fix:

Toggle snippet (4 lines)
$ guix package -s "" |recsel -e 'license ~ "GPL" && dependencies ~ "openssl"' |grep ^name | wc -l
154

Still a lot, and that doesn’t take into account indirect GPL dependents.

Ludo’.
L
L
Ludovic Courtès wrote on 8 Mar 2019 11:23
(name . Vagrant Cascadian)(address . vagrant@debian.org)
871s3his1i.fsf@gnu.org
Hi,

Vagrant Cascadian <vagrant@debian.org> skribis:

Toggle quote (8 lines)
> I've tested that the attached patch builds all u-boot-* targets on
> x86_64 (cross-building most of them), with openssl removed from
> native-inputs.
>
> Unfortunately, u-boot-tools fails it's tests on aarch64 and armhf, but
> that appears to be the case with or without this patch, so it's no worse
> off than it was...

This can be fixed separately then.

Toggle quote (5 lines)
> I'm not sure where it would be appropriate to add more comments
> regarding the GPL/Openssl incompatibilities; e.g. if someone were to
> propose adding one of the u-boot targets that requires it, they might
> just go ahead and re-add the openssl input...

There’s always a risk. I guess we’ll have to be careful when doing
reviews.

In addition, we can add a ‘lint’ checker for this case, WDYT?

Toggle quote (10 lines)
> From ee613387c49ca60905e0a40af8af017828c8aec8 Mon Sep 17 00:00:00 2001
> From: Vagrant Cascadian <vagrant@debian.org>
> Date: Thu, 7 Mar 2019 21:50:58 +0000
> Subject: [PATCH] gnu: u-boot: Remove openssl input.
>
> Fixes: https://bugs.gnu.org/34717
>
> * gnu/packages/bootloaders (u-boot): Remove openssl from native-inputs.
> (u-boot-tools): Disable FIT_SIGNATURES in tests.

Applied, thanks!

Ludo’.
V
V
Vagrant Cascadian wrote on 8 Mar 2019 20:14
(name . Ludovic Courtès)(address . ludo@gnu.org)
87k1h9i3gl.fsf@ponder
On 2019-03-08, Ludovic Courtès wrote:
Toggle quote (9 lines)
> Vagrant Cascadian <vagrant@debian.org> skribis:
>> I'm not sure where it would be appropriate to add more comments
>> regarding the GPL/Openssl incompatibilities; e.g. if someone were to
>> propose adding one of the u-boot targets that requires it, they might
>> just go ahead and re-add the openssl input...
>
> There’s always a risk. I guess we’ll have to be careful when doing
> reviews.

Sure. I was thinking maybe putting a comment in the native-inputs where
"openssl" was removed, but wasn't sure what the conventions might be.


Toggle quote (2 lines)
> In addition, we can add a ‘lint’ checker for this case, WDYT?

Does the lint checker have a way to identify a confidence level,
e.g. *maybe* it has this issue vs. *certainly*? Is there a way to
override the lint checker issues for known false positives? Otherwise,
it might just be annoying noise for packagers where it isn't
appropriate.


live well,
vagrant
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCXIK+/AAKCRDcUY/If5cW
quhvAQDhH6LGasQ+bEPiayw0lRVOy+wQ1G9tonnTYZf7Slg8WwD/YHtuLplr6HTf
Q13lEIYqEm/OZi4pan+meRF64kwAxAs=
=zy4Q
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 9 Mar 2019 22:57
(name . Vagrant Cascadian)(address . vagrant@debian.org)
87h8cb4sou.fsf@gnu.org
Vagrant Cascadian <vagrant@debian.org> skribis:

Toggle quote (13 lines)
> On 2019-03-08, Ludovic Courtès wrote:
>> Vagrant Cascadian <vagrant@debian.org> skribis:
>>> I'm not sure where it would be appropriate to add more comments
>>> regarding the GPL/Openssl incompatibilities; e.g. if someone were to
>>> propose adding one of the u-boot targets that requires it, they might
>>> just go ahead and re-add the openssl input...
>>
>> There’s always a risk. I guess we’ll have to be careful when doing
>> reviews.
>
> Sure. I was thinking maybe putting a comment in the native-inputs where
> "openssl" was removed, but wasn't sure what the conventions might be.

Yeah that would have worked I guess.

Toggle quote (8 lines)
>> In addition, we can add a ‘lint’ checker for this case, WDYT?
>
> Does the lint checker have a way to identify a confidence level,
> e.g. *maybe* it has this issue vs. *certainly*? Is there a way to
> override the lint checker issues for known false positives? Otherwise,
> it might just be annoying noise for packagers where it isn't
> appropriate.

No it doesn’t have that notion of a confidence level.

The warning could be triggered only when a package is GPL’d and has a
direct dependency on OpenSSL (we’d forget about indirect dependencies in
this case.) The noise would be rather limited and justified in this
case, I think. WDYT?

Thanks,
Ludo’.
V
V
Vagrant Cascadian wrote on 10 Mar 2019 00:10
(name . Ludovic Courtès)(address . ludo@gnu.org)
871s3f1w5d.fsf@ponder
On 2019-03-09, Ludovic Courtès wrote:
Toggle quote (13 lines)
> Vagrant Cascadian <vagrant@debian.org> skribis:
>> On 2019-03-08, Ludovic Courtès wrote:
>>> Vagrant Cascadian <vagrant@debian.org> skribis:
>>> In addition, we can add a ‘lint’ checker for this case, WDYT?
>>
>> Does the lint checker have a way to identify a confidence level,
>> e.g. *maybe* it has this issue vs. *certainly*? Is there a way to
>> override the lint checker issues for known false positives? Otherwise,
>> it might just be annoying noise for packagers where it isn't
>> appropriate.
>
> No it doesn’t have that notion of a confidence level.

And I presume no overrides either, given no comment about that?


Toggle quote (5 lines)
> The warning could be triggered only when a package is GPL’d and has a
> direct dependency on OpenSSL (we’d forget about indirect dependencies in
> this case.) The noise would be rather limited and justified in this
> case, I think. WDYT?

The openssl package currently ships the "openssl" binary, as well as the
libraries. I suspect there are at least three potential cases where a
package might depend on it:

* Calls the "openssl" binary as part of test suite or run-time. No
licensing compatibility issue, no worries!

* Using include files from the openssl headers; I guess you could search
for "include .* openssl/*.h" in the source code. Might get some false
positives. Can be run without actually even building it.

* Linking against the library which should actually be easy to detect
with ldd or other tools. Would need to build and then run the checks to
be sure.


live well,
vagrant
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCXIRIAAAKCRDcUY/If5cW
qqQ6AP9s1kqBzKCk/E1isIYoAqG4Wm5vclZ2dGtd0XZ8WJFTqwD/VHC5r3ue4Giv
pg+mJl6s5mVQsGLYLjE1PWsRv8RmXQo=
=ljv9
-----END PGP SIGNATURE-----

J
J
Jack Hill wrote on 10 Mar 2019 04:58
Re: bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others
(address . 34717@debbugs.gnu.org)
alpine.DEB.2.20.1903092253180.16784@marsh.hcoop.net
Hi,

Hopefully the OpenSSL re-licensing [0] will help with this problem in the
long-term. At least for code that can be distributed under GPLv3, which
may include u-boot [1].

Best,
Jack

L
L
Ludovic Courtès wrote on 10 Mar 2019 18:12
Re: bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others
(name . Vagrant Cascadian)(address . vagrant@debian.org)
87tvga3b6x.fsf@gnu.org
Hi,

Vagrant Cascadian <vagrant@debian.org> skribis:

Toggle quote (16 lines)
> On 2019-03-09, Ludovic Courtès wrote:
>> Vagrant Cascadian <vagrant@debian.org> skribis:
>>> On 2019-03-08, Ludovic Courtès wrote:
>>>> Vagrant Cascadian <vagrant@debian.org> skribis:
>>>> In addition, we can add a ‘lint’ checker for this case, WDYT?
>>>
>>> Does the lint checker have a way to identify a confidence level,
>>> e.g. *maybe* it has this issue vs. *certainly*? Is there a way to
>>> override the lint checker issues for known false positives? Otherwise,
>>> it might just be annoying noise for packagers where it isn't
>>> appropriate.
>>
>> No it doesn’t have that notion of a confidence level.
>
> And I presume no overrides either, given no comment about that?

We could arrange for this lint “checker” to honor some per-package
property that would silence it. We do that with the ‘cve’ checker and
the ‘lint-hidden-cve’ property.

Toggle quote (20 lines)
>> The warning could be triggered only when a package is GPL’d and has a
>> direct dependency on OpenSSL (we’d forget about indirect dependencies in
>> this case.) The noise would be rather limited and justified in this
>> case, I think. WDYT?
>
> The openssl package currently ships the "openssl" binary, as well as the
> libraries. I suspect there are at least three potential cases where a
> package might depend on it:
>
> * Calls the "openssl" binary as part of test suite or run-time. No
> licensing compatibility issue, no worries!
>
> * Using include files from the openssl headers; I guess you could search
> for "include .* openssl/*.h" in the source code. Might get some false
> positives. Can be run without actually even building it.
>
> * Linking against the library which should actually be easy to detect
> with ldd or other tools. Would need to build and then run the checks to
> be sure.

So for the 1st case we’d definitely need that property to tell ‘lint’
that everything is known-good.

‘guix lint’ does very inexpensive tests, so unpacking the tarball and
grepping it would be beyond its scope. However, if we can provide the
warning and people have a way to silence it, I guess we’re fine?

Thanks,
Ludo’.
A
A
Adonay Felipe Nogueira wrote on 16 Mar 2019 00:55
(address . bug-guix@gnu.org)
9137e5b2-4fbb-c908-2b00-64c086d5f318@hyperbola.info
Hi there! :D

Em 07/03/2019 01:17, Vagrant Cascadian escreveu:
Toggle quote (2 lines)
> How many of them are also license:gpl* though? That would hopefully

My Guix pull is from commit d22d246a256814784dfb03437949bdc2efd746a5.

I made a little recsel trick to get all packages licensed under [A]GPL
(any version) and which are dependent on any package licensed under
OpenSSL. However, this doesn't check if the [A]GPL'd packages use the
OpenSSL'd dependencies' library or the object code/executable. That
said, there might be plenty of false entries here.

------------------------------------------------------------------------
$ guix package -s '' | recsel -CR "name,version" -e 'license ~
"([[:space:]]|^)[A]?GPL" && dependencies ~ "([[:space:]]|^)('$(guix
package -s '' | recsel -CR 'name,version' -e 'license ~ "OpenSSL"' | tr
'\n' '|' | sed 's/[[:space:]]/@/g; s/\(\.\)/\\\1/g;
s/|\($\)/\1/g')')([[:space:]]|$)"' | sed 's/ /@/g' | tr '\n' ' '
------------------------------------------------------------------------

This gives the following list:

------------------------------------------------------------------------
neon@0.30.2 fetchmail@6.3.26 git-crypt@0.5.0 socat@1.7.3.2 scribus@1.5.4
389-ds-base@1.4.0.13 bigloo@4.3e1 kdelibs4support@5.55.0 munge@0.5.13
gnunet@0.10.1 mupdf@1.14.0 slurm@17.11.3 sssd@1.16.2 wesnoth@1.14.6
yapet@1.1 keepalived@2.0.5 perl-net-ssleay@1.85 r-ggally@1.4.0
john-the-ripper-jumbo@1.8.0-1 psyclpc@20160821-2.61cf9aa hexchat@2.14.2
glusterfs@3.10.12 openvpn@2.4.7 libesmtp@1.0.6 httping@2.5
clamav@0.101.1 python2-mysqlclient@1.3.13 python-mysqlclient@1.3.13
openrct2@0.2.1 calibre@3.35.0 encfs@1.9.5 mosh@1.3.2 qbittorrent@4.1.5
mongodb@3.4.10 wimlib@1.13.0 libsignal-protocol-c@2.3.2 kicad@5.0.0
stunnel@5.48 ceph@13.2.2 looking-glass-client@a12-182c475
warzone2100@3.2.3 linuxdcpp@1.1.0 openvswitch@2.10.1 transmission@2.94
gvpe@3.1 ppp@2.4.7 libgit2@0.27.7 u-boot-novena@2019.01 uwsgi@2.0.18
icecast@2.4.4 rdesktop@1.8.4 gandi.cli@1.3 thc-ipv6@3.4-0.4bb7257
linux-libre-arm-omap2plus@4.20.13 linux-libre-arm-omap2plus@4.19.26
linux-libre-arm-omap2plus@4.14.104 linux-libre-arm-generic@4.20.13
linux-libre-arm-generic@4.19.26 linux-libre-arm-generic@4.14.104
cadaver@0.23.3 rtorrent@0.9.6 libmesode@0.9.2 restbed@4.6-1.6eb385f
virtuoso-ose@7.2.5 libtorrent@0.13.6 libstrophe@0.9.2
jupyter-guile-kernel@0.0.0-1.a7db924 clementine@1.3.1-2.4619a4c
linux-libre@4.9.161 linux-libre@4.4.176 linux-libre@4.20.13
linux-libre@4.19.26 linux-libre@4.14.104 synergy@1.10.1 moc@2.5.2
netsurf@3.8 git-minimal@2.21.0 kodi@18.1 mysql@5.7.23 strongswan@5.6.3
perl-crypt-openssl-rsa@0.31 perl-crypt-openssl-random@0.13 libcmis@0.5.2
git@2.21.0 hydra@20151030.1ff48da perl-crypt-openssl-bignum@0.09
links@2.18 neomutt@20180716 u-boot-tools@2019.01 burp@2.3.0
u-boot-nintendo-nes-classic-edition@2019.01 cgit@1.2.1 dillo@3.0.5
isync@1.3.0 testdisk@7.0 r-git2r@0.24.0 khtml@5.55.0 tinc@1.0.35
4store@1.1.6 u-boot-a20-olinuxino-micro@2019.01
u-boot-a20-olinuxino-lime2@2019.01 efitools@1.9.2
u-boot-a20-olinuxino-lime@2019.01 u-boot-bananapi-m2-ultra@2019.01
u-boot-am335x-boneblack@2019.01 u-boot-vexpress-ca9x4@2019.01
profanity@0.5.1 virt-viewer@7.0 irssi@1.1.2 wesnoth-server@1.14.6
u-boot-puma-rk3399@2019.01 u-boot-pine64-plus@2019.01 mariadb@10.1.37
u-boot-cubietruck@2019.01 u-boot-cubieboard@2019.01
u-boot-wandboard@2019.01 u-boot-mx6cuboxi@2019.01
u-boot-pinebook@2019.01 u-boot-malta@2019.01 xen@4.11.1 faust@2.5.23
mutt@1.11.3 sbsigntools@0.9.2
------------------------------------------------------------------------


--
- Página com formas de contato:
- Ativista do software livre (não confundir com o gratuito). Avaliador
da liberdade de software e de sites.
- Página com lista de contribuições:
- Para uso em escritórios e trabalhos, favor enviar arquivos do padrão
internacional OpenDocument/ODF 1.2 (ISO/IEC 26300-1:2015 e
correlatos). São os .odt/.ods/.odp/odg. O LibreOffice é a suíte de
escritório recomendada para editar tais arquivos.
- Para outros formatos de arquivos, veja:
- Gosta do meu trabalho? Contrate-me ou doe algo para mim!
- Use comunicações sociais federadas padronizadas, onde o "social"
permanece independente do fornecedor. #DeleteWhatsApp. Use #XMPP
#DeleteInstagram #DeleteTwitter #DeleteYouTube. Use #ActivityPub via
- #DeleteNetflix #CancelNetflix. Evite #DRM:
Attachment: signature.asc
V
V
Vagrant Cascadian wrote on 22 Oct 2021 08:17
(address . 34717@debbugs.gnu.org)
87y26loa74.fsf@yucca
On 2019-03-08, Ludovic Courtès wrote:
Toggle quote (23 lines)
> Vagrant Cascadian <vagrant@debian.org> skribis:
>> I'm not sure where it would be appropriate to add more comments
>> regarding the GPL/Openssl incompatibilities; e.g. if someone were to
>> propose adding one of the u-boot targets that requires it, they might
>> just go ahead and re-add the openssl input...
>
> There’s always a risk. I guess we’ll have to be careful when doing
> reviews.
>
> In addition, we can add a ‘lint’ checker for this case, WDYT?
>
>> From ee613387c49ca60905e0a40af8af017828c8aec8 Mon Sep 17 00:00:00 2001
>> From: Vagrant Cascadian <vagrant@debian.org>
>> Date: Thu, 7 Mar 2019 21:50:58 +0000
>> Subject: [PATCH] gnu: u-boot: Remove openssl input.
>>
>> Fixes: https://bugs.gnu.org/34717
>>
>> * gnu/packages/bootloaders (u-boot): Remove openssl from native-inputs.
>> (u-boot-tools): Disable FIT_SIGNATURES in tests.
>
> Applied, thanks!

For the last couple years guix has been applying simple workarounds in
u-boot packages to disable the features that required openssl due to
GPL/openssl license incompatibilities.

I made an attempt at updating guix to u-boot 2021.10, which seems to
have made openssl harder to workaround... many of the u-boot-BOARD
packages now require it, and the previous workarounds to disable openssl
in u-boot-tools seem ineffective.

I see a few ways forward:

* Dig deeper into figuring out how to disable the workarounds...

* Refactor the code that uses openssl to use an alternate
implementation. Upstream would welcome the fixes, at least in
theory. Most promising candidate might be wolfssl, last I looked, but
it may miss some features.

* Convince upstream u-boot to relicense relevent GPLed portions of code
with an openssl exception. Upstream is dubious about this being
practical, largely due to the sheer number of potential contributors
who would have to agree to it.

* ???


While openssl 3.0 is licensed compatibly with GPLv3, u-boot has portions
which are GPLv2-only, so that's not as attractive of a way forward as
one might hope for...


live well,
vagrant
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCYXJXXwAKCRDcUY/If5cW
qiiHAQC5L39PlUYNCXr5sP/1lAUhUbNmU3jJ4hgOFGbA/lDttAD/aUHpWqnDpciZ
G8K2Ch9pNIi7Ui3glQ/WQW8jLEuQ0AM=
=jM1/
-----END PGP SIGNATURE-----

L
L
Leo Famulari wrote on 22 Oct 2021 22:35
(name . Vagrant Cascadian)(address . vagrant@debian.org)
YXMgmR33gtyA8tgZ@jasmine.lan
On Thu, Oct 21, 2021 at 11:17:03PM -0700, Vagrant Cascadian wrote:
Toggle quote (4 lines)
> While openssl 3.0 is licensed compatibly with GPLv3, u-boot has portions
> which are GPLv2-only, so that's not as attractive of a way forward as
> one might hope for...

What are other distros doing? Surely we can't be the only group
distributing u-boot?
V
V
Vagrant Cascadian wrote on 22 Oct 2021 23:15
(name . Leo Famulari)(address . leo@famulari.name)
87fsssoj6z.fsf@yucca
On 2021-10-22, Leo Famulari wrote:
Toggle quote (8 lines)
> On Thu, Oct 21, 2021 at 11:17:03PM -0700, Vagrant Cascadian wrote:
>> While openssl 3.0 is licensed compatibly with GPLv3, u-boot has portions
>> which are GPLv2-only, so that's not as attractive of a way forward as
>> one might hope for...
>
> What are other distros doing? Surely we can't be the only group
> distributing u-boot?

Both fedora and (recently) debian have openssl declared as a system
library, invoking the GPL's system library exception... which I
personally find at best to be a grey area workaround.

I wouldn't be surprised if most distros simply ignore the issue
entirely.

Interestingly, today I was called in on a relevent discussion on the
u-boot mailing list:


Though, it is *possible* that various u-boot-BOARD in some cases doesn't
include any openssl code at all in the resulting binaries, but builds
some tools used during the build process, that are then used to produce
various cryptographic signatures in the build:


If that's true, it should be ok for various boards (though the
possibility of openssl code getting linked in would be hard to
catch).

u-boot-tools would still need a viable workaround, though.


live well,
vagrant
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCYXMp1QAKCRDcUY/If5cW
qu0wAP9qDXN8FxaMiOU6E/dilauNpVEPnvqtYhi1pxXb7Z2z4AD5AVhfL9squoCc
XofEkqgqQEIlUdOZMN3DLHt7yIJjwQE=
=05U9
-----END PGP SIGNATURE-----

V
V
Vagrant Cascadian wrote on 22 Oct 2021 23:17
(address . 34717@debbugs.gnu.org)(address . guix-devel@gnu.org)
87cznwoj2q.fsf@yucca
On 2021-10-21, Vagrant Cascadian wrote:
Toggle quote (23 lines)
> For the last couple years guix has been applying simple workarounds in
> u-boot packages to disable the features that required openssl due to
> GPL/openssl license incompatibilities.
>
> I made an attempt at updating guix to u-boot 2021.10, which seems to
> have made openssl harder to workaround... many of the u-boot-BOARD
> packages now require it, and the previous workarounds to disable openssl
> in u-boot-tools seem ineffective.
>
> I see a few ways forward:
>
> * Dig deeper into figuring out how to disable the workarounds...
>
> * Refactor the code that uses openssl to use an alternate
> implementation. Upstream would welcome the fixes, at least in
> theory. Most promising candidate might be wolfssl, last I looked, but
> it may miss some features.
>
> * Convince upstream u-boot to relicense relevent GPLed portions of code
> with an openssl exception. Upstream is dubious about this being
> practical, largely due to the sheer number of potential contributors
> who would have to agree to it.

* Disable substitutes for relevent packages. Technically correct as
license incompatibility is only triggered on transmission of binary,
though maybe missing something about the spirit of the GPL.


live well,
vagrant
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCYXMqbgAKCRDcUY/If5cW
qiKaAQCTLWxn3fODFSj+gOHuQj7N6Wil2ZgQJc66DZVDdZMeNgEA8ik5/Qy0+9ve
vxdJc9+IuMgQNxa8gkzTnNuZUsGNOA0=
=Npsj
-----END PGP SIGNATURE-----

M
M
Maxime Devos wrote on 23 Oct 2021 11:08
c4b60036e9aa7d2459f6ed2a71cfc274206b6b70.camel@telenet.be
Vagrant Cascadian schreef op vr 22-10-2021 om 14:15 [-0700]:
Toggle quote (14 lines)
> [...]
> Though, it is *possible* that various u-boot-BOARD in some cases
> doesn't
> include any openssl code at all in the resulting binaries, but builds
> some tools used during the build process, that are then used to
> produce
> various cryptographic signatures in the build:
>
>   https://lists.denx.de/pipermail/u-boot/2021-October/464533.html
>
> If that's true, it should be ok for various boards (though the
> possibility of openssl code getting linked in would be hard to
> catch).

Add openssl to #:disallowed-references. Then the build will fail
if the store item has a reference to openssl.

This most likely won't catch uses of the _static_ OpenSSL libraries
though, so the "openssl:static" input would need to be removed for
this approach to work.

Greetings,
Maxime.
--
not hacking on guix for a while, only occassionally looking at IRC logs
and bug reports. E-mails are unsigned until backup is located.
L
L
Leo Famulari wrote on 23 Oct 2021 21:44
(name . Vagrant Cascadian)(address . vagrant@debian.org)
YXRmAoyt3X3DNTeX@jasmine.lan
On Fri, Oct 22, 2021 at 02:17:33PM -0700, Vagrant Cascadian wrote:
Toggle quote (4 lines)
> * Disable substitutes for relevent packages. Technically correct as
> license incompatibility is only triggered on transmission of binary,
> though maybe missing something about the spirit of the GPL.

Maybe, but did anyone with standing ever take action regarding these
licensing incompatibilities?

Perhaps, looking at these issues too closely is also missing something
about the spirit of the GPL.
D
D
Dr. Arne Babenhauserheide wrote on 24 Oct 2021 10:50
(name . Leo Famulari)(address . leo@famulari.name)
87v91m3itj.fsf@web.de
Leo Famulari <leo@famulari.name> writes:

Toggle quote (11 lines)
> On Fri, Oct 22, 2021 at 02:17:33PM -0700, Vagrant Cascadian wrote:
>> * Disable substitutes for relevent packages. Technically correct as
>> license incompatibility is only triggered on transmission of binary,
>> though maybe missing something about the spirit of the GPL.
>
> Maybe, but did anyone with standing ever take action regarding these
> licensing incompatibilities?
>
> Perhaps, looking at these issues too closely is also missing something
> about the spirit of the GPL.

It just needs one person. Also see this weeks newsletter from Cory
Doctorov on the lawsuit against Vizio. It might soon only take one user.

Best get licensing problems fixed sooner than later. GPLv2-only is a
problem quickly getting closer.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
-----BEGIN PGP SIGNATURE-----

iQJEBAEBCAAuFiEE801qEjXQSQPNItXAE++NRSQDw+sFAmF1HvgQHGFybmVfYmFi
QHdlYi5kZQAKCRAT741FJAPD6/qtEAC9pCyi8fl/5PBk0nmMvs5bb4M+v4FbFxMf
1Z4Bg/hkdQU0HTOvaw8pjhtFArQAFS8Jz37iUT6yPpb/GT/MkjIk/f8g2XaYZYZV
3k8FXczHibnOcR2+7giwg35bZfdGjEkS0vQUtCg8tV/gWTYiGJpkzePpUwjHtAGR
jemUZZA2rVvoJMqEV+RdUkl/OdKE2JvkbHWjiihcNUw9W6wrkSpJUTIpktnRLBxe
EiWLnDw5dcjTap9dEH9+XbDdKOXpTM8Sh2CcMHbLZ7lXmEekcB5ZX5vlFl+2siUm
rFom/YWE8yZmynBu5p4JYvBO+T07YjhrTx4O9qgod8FFVdrAJ68vl5xDFLClguN0
STPH8vYsWQDY9tToj43FDNMFHO2okSLdGWG/a+svg2EFH0SyVvvsin42ggnYPvCp
nGPSJrncVb2BPg+jmF8TAb1txBeT7rUlDxvnyiH0ULUAkSPQygE3SVU5hHpFjz1A
43rSHSw7MZkfxQ0PFGtYofGncyaftsoZAS/ElaWJ+dR5FbIZ7nI7p7aCwgosqGOb
6qLV98olMOy3kDRmaKwyXqenn/Jpu54udZeNBJreqqcQD9d7FOGLWsG0JfxmjTGw
H9R05IX5TRG6VchgBNQTPLUAWC4lziPt/zeYvn2Lm7at42vD4QUwrynn/6mk/oXj
Nu9g92SPbojEBAEBCAAuFiEE3Si95tmHXKvOSosd3M8NswvBBUgFAmF1HvgQHGFy
bmVfYmFiQHdlYi5kZQAKCRDczw2zC8EFSG1sBACEdX446VpzJPJPH2Hy9g8QF/A1
1AI3Ym5l9SWZdcbd8pMYuvQm81XrBKrlIOt/hg2d+y8KxREWdwOukfPBErygiKhU
2PkENsjaDtutXUXQB9INOJeKZyx/YyiP7FC0HhHZz1jSNatONo6pfa7TxKUVpmfa
xxddzJWGZ0bMpvvXKQ==
=GfL2
-----END PGP SIGNATURE-----

?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 34717@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 34717
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch