[gnutls-devel] Automatic library initialization

[Tim Ruehsen]

On Monday 16 November 2015 15:17:24 Nikos Mavrogiannopoulos wrote:
> On Mon, Nov 16, 2015 at 12:12 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> >> 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 ?
> 
> Yes, a common bug reported was applications crashing when they
> attempted to call gnutls_global_init() from awkward situations (e.g.,
> having several of threads which all called gnutls_global_init). The
> applications themselves didn't even know they were calling
> gnutls_global_init(), it was some intermediate library, which also
> didn't expect to be used by multithreaded applications. The way to
> solve that was handling all initialization in a constructor. I don't
> have the exact names of the projects with that issue, but they are in
> the mailing list.

In this case, IMO, gnutls was the wrong place to fix it.

As you say, this intermediate library didn't expect to be used in a multi-
threaded environment. This should have been clearly documented by these 
libraries ! And could have been fixed at some point (e.g. by introducing an 
API for the calling apps to set a locking/unlocking function or by introducing 
an init function - documented as being not thread safe).

But 'fixing' this in gnutls by introducing automatic initialization pulled 
gnutls into a swamp... That's how it is now, how can we get out of there ?

> >> > 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.
> 
> That is hardly a solution. An API is not distribution specific, and if
> the gnutls' API doesn't require gnutls_global_init(), that should be
> for any distribution including debian.

The API isn't touched, it is the internal functionality of the library. Most 
libraries / APIs have ./configure options to influence internal details. Each 
distribution uses it's own set of flags for compilation/packaging. That is 
absolutely common and seems not to be a big deal.

> We need to find something
> better to prevent the constructor being run for specific applications.

Out of ideas right now.
1. dlopen instead of dynamic linking is not an option
2. an env variable is not an option
3. since the library loading/contruction happens before the instruction of the 
executable, an additional function is not an option

Just braindumping:
Compiling two gnutls libraries ? One with an tail of e.g. -ac (for Automatic 
Contruction). Distributions could offer two packages (parallel installable).

I wrote a script to check Debians packages that depend on libgnutls for usage 
of gnutls_global_init. Almost all call this function explicitly. And the ones 
that don't: I hand-checked a few just to see the the dependencies where wrong.

OK, I just got your email about GNUTLS_SKIP_GLOBAL_INIT... I'll send you this 
for your interest. GNUTLS_SKIP_GLOBAL_INIT+function override is a very good 
idea and I'll use it in my code. But please consider my text regarding 'fixing 
at the wrong place'.

Thanks and regards, Tim