Hi,
When running lintian on openbsc, I get the following error:
E: osmocom-bsc-nat: possible-gpl-code-linked-with-openssl E: osmocom-nitb: possible-gpl-code-linked-with-openssl
It seems like openbsc is being linked with libcrypto from OpenSSL, but I cannot find any statement of OpenSSL exception for the AGPL. Debian policy requires this.
Can you look into this? You can have a look at wget if you need an example.
Ruben
On 19 Feb 2016, at 19:54, Ruben Undheim ruben.undheim@gmail.com wrote:
Hi,
Dear Ruben,
When running lintian on openbsc, I get the following error:
E: osmocom-bsc-nat: possible-gpl-code-linked-with-openssl E: osmocom-nitb: possible-gpl-code-linked-with-openssl
It seems like openbsc is being linked with libcrypto from OpenSSL, but I cannot find any statement of OpenSSL exception for the AGPL. Debian policy requires this.
Can you look into this? You can have a look at wget if you need an example.
if you are debian developer maybe you know someone working on lintian. What always triggers me is that it (and specially lintian.debian.org) say what is wrong but they don't point to a solution, e.g. they also link to other broken packages but never to an example how this specific program has fixed the issue. It is a bit like writing E: blub.
When picking libcrypto I considered it a system library (FreeBSD, OSX, etc. ship it in the base system). I think instead of changing the license it is easier to change the calls. From my point of view there are several options:
1.) You link against libgnutls-openssl-dev which provides a wrapper for RAND_bytes.
2.) We move to GNUtls (or gcrypt?) to call the function that RAND_bytes is wrapped around (after reading the documentation)
3.) We use GNU nettle and their yarrow-256 implementation (assuming that is a smart move)?
I think from a packaging point of view 1st might be the easiest and just means patching one line in configure.ac?
holger
1.) You link against libgnutls-openssl-dev which provides a wrapper for RAND_bytes.
2.) We move to GNUtls (or gcrypt?) to call the function that RAND_bytes is wrapped around (after reading the documentation)
3.) We use GNU nettle and their yarrow-256 implementation (assuming that is a smart move)?
Thanks. I did #1. Here's the patch:
Index: openbsc/openbsc/configure.ac =================================================================== --- openbsc.orig/openbsc/configure.ac 2016-02-19 20:39:10.824145024 +0100 +++ openbsc/openbsc/configure.ac 2016-02-19 20:39:10.820145095 +0100 @@ -27,7 +27,8 @@ PKG_CHECK_MODULES(LIBOSMOABIS, libosmoabis >= 0.2.0) PKG_CHECK_MODULES(LIBOSMOGB, libosmogb >= 0.6.4) PKG_CHECK_MODULES(LIBOSMONETIF, libosmo-netif >= 0.0.1) -PKG_CHECK_MODULES(LIBCRYPTO, libcrypto >= 0.9.5) +#PKG_CHECK_MODULES(LIBCRYPTO, gnutls) +AC_SUBST(LIBCRYPTO_LIBS, -lgnutls-openssl)
# Enabke/disable the NAT? AC_ARG_ENABLE([nat], [AS_HELP_STRING([--enable-nat], [Build the BSC NAT. Requires SCCP])], Index: openbsc/openbsc/src/libmsc/auth.c =================================================================== --- openbsc.orig/openbsc/src/libmsc/auth.c 2016-02-19 20:13:19.417462737 +0100 +++ openbsc/openbsc/src/libmsc/auth.c 2016-02-19 20:40:13.607032169 +0100 @@ -27,7 +27,7 @@
#include <osmocom/gsm/comp128.h>
-#include <openssl/rand.h> +#include <gnutls/openssl.h>
#include <stdlib.h>
Index: openbsc/openbsc/src/libmsc/db.c =================================================================== --- openbsc.orig/openbsc/src/libmsc/db.c 2016-02-19 20:13:19.421462672 +0100 +++ openbsc/openbsc/src/libmsc/db.c 2016-02-19 20:40:27.318789122 +0100 @@ -38,7 +38,7 @@ #include <osmocom/core/statistics.h> #include <osmocom/core/rate_ctr.h>
-#include <openssl/rand.h> +#include <gnutls/openssl.h>
/* Semi-Private-Interface (SPI) for the subscriber code */ void subscr_direct_free(struct gsm_subscriber *subscr); Index: openbsc/openbsc/src/osmo-bsc_nat/bsc_nat.c =================================================================== --- openbsc.orig/openbsc/src/osmo-bsc_nat/bsc_nat.c 2016-02-19 20:13:19.433462478 +0100 +++ openbsc/openbsc/src/osmo-bsc_nat/bsc_nat.c 2016-02-19 20:39:58.791294787 +0100 @@ -69,7 +69,7 @@
#include <osmocom/abis/ipa.h>
-#include <openssl/rand.h> +#include <gnutls/openssl.h>
#include "../../bscconfig.h"
It seems to work. Luckily the SSL library isn't used for anything advanced.
Cool if you also figure out a way to solve this upstream!
Cheers Ruben
On 19 Feb 2016, at 20:54, Ruben Undheim ruben.undheim@gmail.com wrote:
1.) You link against libgnutls-openssl-dev which provides a wrapper for RAND_bytes.
2.) We move to GNUtls (or gcrypt?) to call the function that RAND_bytes is wrapped around (after reading the documentation)
3.) We use GNU nettle and their yarrow-256 implementation (assuming that is a smart move)?
Thanks. I did #1. Here's the patch:
I explored 2nd and gnutls calls gcrypt so I looked at gcry_randomize[1]. In comparison to the OpenSSL RNAD_bytes documentation I feel a lot is missing. RAND_bytes will fail if the RNG is not seeded, I don't see anything like this in gcry_randomize documentation. Do I really need to call gcry_check_version or is it okay to not call it?
I will not do this weekend, but please ping me if there is not progress in the weeks to come. I think we roughly need to do:
* Call gcry_check_version in the main routine of apps using it * Switch to use gcry_randomize
holger
[1] https://gnupg.org/documentation/manuals/gcrypt/Retrieving-random-numbers.htm... [2] https://www.openssl.org/docs/manmaster/crypto/RAND_bytes.html
-
Holger Freyther -
Ruben Undheim