From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Subject: bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others Date: Fri, 08 Mar 2019 11:08:34 +0100 Message-ID: <87bm2lispp.fsf@gnu.org> References: <87tvgkiurn.fsf@ponder> <87zhq8f2zz.fsf@gnu.org> <87ftrzuxmh.fsf@ponder> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([209.51.188.92]:49753) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h2CR5-0003uj-Bf for bug-guix@gnu.org; Fri, 08 Mar 2019 05:09:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h2CR4-00025I-8u for bug-guix@gnu.org; Fri, 08 Mar 2019 05:09:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:50540) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h2CR4-000251-3F for bug-guix@gnu.org; Fri, 08 Mar 2019 05:09:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1h2CR3-0006FE-Q6 for bug-guix@gnu.org; Fri, 08 Mar 2019 05:09:01 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87ftrzuxmh.fsf@ponder> (Vagrant Cascadian's message of "Wed, 06 Mar 2019 20:17:10 -0800") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Vagrant Cascadian Cc: 34717@debbugs.gnu.org Hi Vagrant Cascadian skribis: > On 2019-03-06, Ludovic Court=C3=A8s wrote: [...] >> 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=3D ..." could be extended to to also search > other fields, e.g. license: and dependencies: ... it might not be so > difficult a search. Here=E2=80=99s an estimate: --8<---------------cut here---------------start------------->8--- $ guix package -s "" |recsel -e 'license ~ "GPL"' -e 'dependencies ~ "opens= sl"' |grep ^name| wc -l 265 --8<---------------cut here---------------end--------------->8--- You can view the list of packages like this: --8<---------------cut here---------------start------------->8--- guix package -s "" |recsel -e 'license ~ "GPL"' -e 'dependencies ~ "openssl= "' -p name,version --8<---------------cut here---------------end--------------->8--- >>> 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=E2=80=99d be great. We could definitely remove the OpenSSL depende= ncy when >> it=E2=80=99s 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! >> In cases where it is needed, it would be nice to see what it=E2=80=99s u= sed >> for. Many projects use OpenSSL just for its cryptographic hash >> functions, for example, and there=E2=80=99s plenty of options to choose = from if >> that=E2=80=99s all that=E2=80=99s 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=E2=80=99 OpenSSL compat layer has been bitrotting since foreve= r. But really rather than GnuTLS they should target one of these crypto libraries, which seem to be a better fit. >> 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 =E2=80=9Cwe=E2=80=9D should consider doing it at some point. Chang= ing the RSA signature code to use another API can=E2=80=99t be that hard=E2=84=A2. ;-) I see from the message above that PEM encoding/decoding may also be needed, which Gcrypt doesn=E2=80=99t provide. Thanks, Ludo=E2=80=99.