[gnutls-devel] Automatic library initialization

[Tim Ruehsen]

Tim

On Monday 16 November 2015 11:24:40 Nikos Mavrogiannopoulos wrote:
> On Mon, Nov 16, 2015 at 11:02 AM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> > Hi Nikos,
> > after thinking a bit, ... having GNUTLS_NO_EXPLICIT_INIT is nice, but does
> > not solve my issue.
> > We are in a world of mixed plain-text and TLS connections. The library
> > doesn't know what will be requested (TLS or plain text) - but it rushes
> > ahead and does a heavyweight initialization in any case. This is IMO a
> > bad idea (think of 'Green IT', embedded devices, low power apps, etc).
> > I recognize the additional CPU usage when tuning my projects to less CPU
> > utilization. Dynamic loading GnuTLS doesn't make sense right now. Tuning
> > any other code doesn't make sense (GnuTLS load factor of ~60 in
> > comparison to the rest of the code).
> 
> Is that for some specific use of gnutls (e.g., in an embedded system)
> or for its generic use (i.e., in a distribution)?

Automatic init of GnuTLS makes sense *only* for a TLS only application.
I have have apps like Wget and Curl in mind, that are called a billion times 
each day without a TLS/SSL usage.

> In a distribution
> the automatic initialization helps to have users of gnutls who
> couldn't otherwise use it. For example a library which has no
> equivalent global_init function couldn't use gnutls easily.

Do you have a special project in mind ?
I am not aware of any such library.
Also, your theoretical example applies to any library that uses another 
library. AFAIK, it is a good practice to avoid code in the library 
constructor.

Given a library that wraps around GnuTLS (and likely other TLS libraries as 
well): That will likely have a global init function - since it doesn't know 
(or shouldn't rely) on automatic initialization.

Look at curl's VTLS code (almost a library code) or at Wget (GnuTLS / OpenSSL 
wrapped into an own API). Look at libwget (right now being prepared for 
Wget2). They all explicitely call gnutls_global_init, and that is a good 
choice: these are compilable/linkable with GnuTLS <3.3 and don't rely on 
automatic initialization.

> 
> > IMO, you should revert your decision and should not automatic initialize.
> > For someone who badly needs that (beyond my imagination right now), a
> > ./configure flag and GNUTLS_NO_EXPLICIT_INIT should do it. Maybe it
> > should be
> > GNUTLS_AUTOMATIC_INIT, defaulting to 0.
> 
> That is too late now as it would be an ABI break. However a configure
> flag is certainly an easy thing to be added, but it would only solve
> your problem if you target some specific systems. What is the use case
> you are trying to address?

A ./configure flag would be enough. I'll ask the Debian maintainer(s) to apply 
such a flag. As long as there are no packages/projects that *rely* on 
automatic init, there should be no problem. If there are, these packages 
should be fixed.

If you add such a flag, it may be wise to let GNUTLS_NO_EXPLICIT_INIT still 
work. Explicitly setting it to 0 would enable automatic init even when 
switched off at compiled time.
In other words: the ./configure flag should just change the default behavior.

WDYT ?

Regards, Tim