Bug 9350

Summary:	As a developer, I want a global variable exist for choosing the default SSL/TLS provider.
Product:	[Build System, Metadata & Runtime] OE-Core	Reporter:	Ming Liu <liu.ming50>
Component:	core	Assignee:	Jussi Kukkonen <jku>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	enhancement
Priority:	Medium	CC:	jku, meta.mr.watcher, meta.watcher, ross.burton
Version:	2.3
Target Milestone:	2.4
Hardware:	x86
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	Don't know

Description Ming Liu 2016-03-29 11:02:16 UTC

As described in:
http://www.gnu.org/licenses/license-list.html#OpenSSL

The license of OpenSSL has an advertising clause, which creates practical problems like those of the original BSD license, including incompatibility with the GNU GPL.

This BSD “obnoxious advertising clause” said:

3. All advertising materials mentioning features or use of this software
   must display the following acknowledgement:
     This product includes software developed by the University of
     California, Berkeley and its contributors.


My company wants to get rid of the “obnoxious advertising clause” of OpenSSL, for instance, set GNUTLS instead of OpenSSL from global aspsect, but seems there is not a global variable like VIRTUAL-RUNTIME_tls/VIRTUAL-RUNTIME_ssl that we could use to choose the default ssl/tls provider.

I know some packages already have the pkgconfigs for switching between OpenSSL and GNUTLS, it should be easy to add this VIRTUAL-RUNTIME_tls/VIRTUAL-RUNTIME_ssl for them, but some other packages probably are still explicitly depending on OpenSSL, it might not so straightforward for them to comply with this VIRTUAL-RUNTIME_tls/VIRTUAL-RUNTIME_ssl, we need manually patch them, but is this something worth to have?

Comment 1 Jussi Kukkonen 2016-03-31 13:07:55 UTC

The idea has enough merit for trying it, I'd say. This patch started a related discussion in February: http://lists.openembedded.org/pipermail/openembedded-core/2016-February/117193.html

Some points to consider:
 * Some uses of e.g. openssl are not for TLS/SSL but other crypto features
 * Some projects do not support multiple TLS implementations and "manually patching them" to do so sounds like massive amount of work and a very bad idea from a security point of view.

The best we can do might be just a distro-wide suggestion: "if recipes can use $CRYPTO_X, they should do so". In some cases that would mean you only get the crypto implementation you want, in others you might still end up with multiple ones -- this is still something you'd have to catch in your license review -- but at least you wouldn't need to modify loads of individual PACKAGECONFIGs to achieve this.



As a sidenote, avoiding openssl because of license reasons may lead you to use a _very_ old version of nettle as gnutls dependency (if you also happen to avoid LGPLv3).

Comment 2 Jussi Kukkonen 2016-09-05 07:39:30 UTC

Considering the phase of 2.2, it seems fair to admit this won't happen in this release. Trying again for 2.3.

Comment 3 Ross Burton 2017-08-08 13:40:15 UTC

Some observations:

- OpenSSL is moving away from the custom license with adverting clause, and towards the Apache license.
- gnutls and openssl are not API-compatible.
- Many upstreams only support one or the other, complicated by OpenSSL 1.1 having a different API to OpenSSL 1.0.

I think that it's best to continue accepting patches to add PACKAGECONFIG options for recipes that support multiple crypto providers, but the ideal of having a global "crypto provider" variable just isn't possible.