From alexvong1995 at gmail.com Tue Nov 3 16:31:26 2015 From: alexvong1995 at gmail.com (Alex Vong) Date: Tue, 3 Nov 2015 23:31:26 +0800 Subject: [gnutls-devel] gnutls-guile segfault during test Message-ID: Hi, The bug is being fixed with a newer version of gnutls. Feel free to ignore this bug report. Cheers, Alex From tim.ruehsen at gmx.de Tue Nov 10 16:23:02 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Tue, 10 Nov 2015 16:23:02 +0100 Subject: [gnutls-devel] Automatic library initialization Message-ID: <1851199.M1iFb0Yqm5@blitz-lx> Hi, an executable, dynamically linked with GnuTLS, automatically calls gnutls_global_init(). And thus (in my case) eats up 60x more CPU cycles than needed. The executable only needs GnuTLS under some conditions (TLS connection requested). In this case it 'manually' calls gnutls_global_init(). Is there a ./configure option (or similar) that the packagers should/could use to avoid that automatic initialization ? Or anything I can do when compiling/linking the executable ? I would like to understand, what is going on here. I am on Debian SID amd64, GnuTLS version 3.3.18-1. Best Regards, Tim R?hsen From nmav at gnutls.org Wed Nov 11 11:33:32 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 11 Nov 2015 11:33:32 +0100 Subject: [gnutls-devel] Automatic library initialization In-Reply-To: <1851199.M1iFb0Yqm5@blitz-lx> References: <1851199.M1iFb0Yqm5@blitz-lx> Message-ID: On Tue, Nov 10, 2015 at 4:23 PM, Tim Ruehsen wrote: > Hi, > > an executable, dynamically linked with GnuTLS, automatically calls > gnutls_global_init(). And thus (in my case) eats up 60x more CPU cycles than > needed. > The executable only needs GnuTLS under some conditions (TLS connection > requested). In this case it 'manually' calls gnutls_global_init(). There is the undocumented env variable GNUTLS_NO_EXPLICIT_INIT. If you set it to 1 you disable the use of constructor and destructors to load gnutls. > Is there a ./configure option (or similar) that the packagers should/could use > to avoid that automatic initialization ? Or anything I can do when > compiling/linking the executable ? There is no compile time flag for that. regards, Nikos From tim.ruehsen at gmx.de Mon Nov 16 10:36:41 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Mon, 16 Nov 2015 10:36:41 +0100 Subject: [gnutls-devel] Automatic library initialization In-Reply-To: References: <1851199.M1iFb0Yqm5@blitz-lx> Message-ID: <1461001.dLWv5szkBB@blitz-lx> On Wednesday 11 November 2015 11:33:32 Nikos Mavrogiannopoulos wrote: > On Tue, Nov 10, 2015 at 4:23 PM, Tim Ruehsen wrote: > > Hi, > > > > an executable, dynamically linked with GnuTLS, automatically calls > > gnutls_global_init(). And thus (in my case) eats up 60x more CPU cycles > > than needed. > > The executable only needs GnuTLS under some conditions (TLS connection > > requested). In this case it 'manually' calls gnutls_global_init(). > > There is the undocumented env variable GNUTLS_NO_EXPLICIT_INIT. If you > set it to 1 you disable the use of constructor and destructors to load > gnutls. Hi Nikos, this variable does not exist in 3_3_x branch. In 3_4_x it is documented. Bad luck for me :-(, Debian still uses 3.3.x. Could you backport it to 3.3 (commit 205ad24f and 9b43ac82) ? Regards, Tim From tim.ruehsen at gmx.de Mon Nov 16 11:02:48 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Mon, 16 Nov 2015 11:02:48 +0100 Subject: [gnutls-devel] Automatic library initialization In-Reply-To: <1461001.dLWv5szkBB@blitz-lx> References: <1851199.M1iFb0Yqm5@blitz-lx> <1461001.dLWv5szkBB@blitz-lx> Message-ID: <25854347.EqMqb72FCz@blitz-lx> 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). 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. Just my thoughts. Regards, Tim On Monday 16 November 2015 10:36:41 Tim Ruehsen wrote: > On Wednesday 11 November 2015 11:33:32 Nikos Mavrogiannopoulos wrote: > > On Tue, Nov 10, 2015 at 4:23 PM, Tim Ruehsen wrote: > > > Hi, > > > > > > an executable, dynamically linked with GnuTLS, automatically calls > > > gnutls_global_init(). And thus (in my case) eats up 60x more CPU cycles > > > than needed. > > > The executable only needs GnuTLS under some conditions (TLS connection > > > requested). In this case it 'manually' calls gnutls_global_init(). > > > > There is the undocumented env variable GNUTLS_NO_EXPLICIT_INIT. If you > > set it to 1 you disable the use of constructor and destructors to load > > gnutls. > > Hi Nikos, > > this variable does not exist in 3_3_x branch. In 3_4_x it is documented. > > Bad luck for me :-(, Debian still uses 3.3.x. > > Could you backport it to 3.3 (commit 205ad24f and 9b43ac82) ? > > Regards, Tim > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-devel From nmav at gnutls.org Mon Nov 16 11:24:40 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 16 Nov 2015 11:24:40 +0100 Subject: [gnutls-devel] Automatic library initialization In-Reply-To: <25854347.EqMqb72FCz@blitz-lx> References: <1851199.M1iFb0Yqm5@blitz-lx> <1461001.dLWv5szkBB@blitz-lx> <25854347.EqMqb72FCz@blitz-lx> Message-ID: On Mon, Nov 16, 2015 at 11:02 AM, Tim Ruehsen 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)? 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. > 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? regards, Nikos From tim.ruehsen at gmx.de Mon Nov 16 12:12:52 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Mon, 16 Nov 2015 12:12:52 +0100 Subject: [gnutls-devel] Automatic library initialization In-Reply-To: References: <1851199.M1iFb0Yqm5@blitz-lx> <25854347.EqMqb72FCz@blitz-lx> Message-ID: <12928776.XuYPWOxMiv@blitz-lx> Tim On Monday 16 November 2015 11:24:40 Nikos Mavrogiannopoulos wrote: > On Mon, Nov 16, 2015 at 11:02 AM, Tim Ruehsen 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 From jgh at wizmail.org Mon Nov 16 12:27:23 2015 From: jgh at wizmail.org (Jeremy Harris) Date: Mon, 16 Nov 2015 11:27:23 +0000 Subject: [gnutls-devel] Automatic library initialization In-Reply-To: References: <1851199.M1iFb0Yqm5@blitz-lx> Message-ID: <5649BD9B.6040808@wizmail.org> On 11/11/15 10:33, Nikos Mavrogiannopoulos wrote: > On Tue, Nov 10, 2015 at 4:23 PM, Tim Ruehsen wrote: >> an executable, dynamically linked with GnuTLS, automatically calls >> gnutls_global_init(). And thus (in my case) eats up 60x more CPU cycles than >> needed. >> The executable only needs GnuTLS under some conditions (TLS connection >> requested). In this case it 'manually' calls gnutls_global_init(). > > There is the undocumented env variable GNUTLS_NO_EXPLICIT_INIT. If you > set it to 1 you disable the use of constructor and destructors to load > gnutls. Question: in a forking server will the initialisation cost be paid only at service start, and not per-worker? Is this a valid model for GnuTLS? -- Thanks, Jeremy From tim.ruehsen at gmx.de Mon Nov 16 14:39:04 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Mon, 16 Nov 2015 14:39:04 +0100 Subject: [gnutls-devel] Automatic library initialization In-Reply-To: <5649BD9B.6040808@wizmail.org> References: <1851199.M1iFb0Yqm5@blitz-lx> <5649BD9B.6040808@wizmail.org> Message-ID: <1541579.jnAzN7pAAD@blitz-lx> On Monday 16 November 2015 11:27:23 Jeremy Harris wrote: > On 11/11/15 10:33, Nikos Mavrogiannopoulos wrote: > > On Tue, Nov 10, 2015 at 4:23 PM, Tim Ruehsen wrote: > >> an executable, dynamically linked with GnuTLS, automatically calls > >> gnutls_global_init(). And thus (in my case) eats up 60x more CPU cycles > >> than needed. > >> The executable only needs GnuTLS under some conditions (TLS connection > >> requested). In this case it 'manually' calls gnutls_global_init(). > > > > There is the undocumented env variable GNUTLS_NO_EXPLICIT_INIT. If you > > set it to 1 you disable the use of constructor and destructors to load > > gnutls. > > Question: in a forking server will the initialisation cost be paid only > at service start, and not per-worker? Is this a valid model for GnuTLS? On Linux, cost will be only once at service start. This is true for automatic init and for manual init (assuming that a forking server would call gnutls_global_init() before calling fork()). Regards, Tim From nmav at gnutls.org Mon Nov 16 15:17:24 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 16 Nov 2015 15:17:24 +0100 Subject: [gnutls-devel] Automatic library initialization In-Reply-To: <12928776.XuYPWOxMiv@blitz-lx> References: <1851199.M1iFb0Yqm5@blitz-lx> <25854347.EqMqb72FCz@blitz-lx> <12928776.XuYPWOxMiv@blitz-lx> Message-ID: On Mon, Nov 16, 2015 at 12:12 PM, Tim Ruehsen 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. > 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. It is not theoretical as you imply. There were real issues that had to be solved somehow. >> > 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. We need to find something better to prevent the constructor being run for specific applications. regards, Nikos From nmav at gnutls.org Mon Nov 16 16:23:31 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 16 Nov 2015 16:23:31 +0100 Subject: [gnutls-devel] Automatic library initialization In-Reply-To: References: <1851199.M1iFb0Yqm5@blitz-lx> <25854347.EqMqb72FCz@blitz-lx> <12928776.XuYPWOxMiv@blitz-lx> Message-ID: On Mon, Nov 16, 2015 at 3:17 PM, Nikos Mavrogiannopoulos wrote: >>> > 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. We need to find something > better to prevent the constructor being run for specific applications Something like the following. Have each program not wishing to use global initialization to define a symbol which overrides a weak one from gnutls. In practice that would mean setting: GNUTLS_SKIP_GLOBAL_INIT in some global section in your program. That can also be easily backported in 3.3.x and you can check for that feature with an ifdef. Would that be acceptable? regards, Nikos -------------- next part -------------- A non-text attachment was scrubbed... Name: skip-global-init.patch Type: text/x-diff Size: 1741 bytes Desc: not available URL: From tim.ruehsen at gmx.de Mon Nov 16 16:52:08 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Mon, 16 Nov 2015 16:52:08 +0100 Subject: [gnutls-devel] Automatic library initialization In-Reply-To: References: <1851199.M1iFb0Yqm5@blitz-lx> <12928776.XuYPWOxMiv@blitz-lx> Message-ID: <1785998.bcRpExjOff@blitz-lx> On Monday 16 November 2015 15:17:24 Nikos Mavrogiannopoulos wrote: > On Mon, Nov 16, 2015 at 12:12 PM, Tim Ruehsen 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 From tim.ruehsen at gmx.de Mon Nov 16 16:54:18 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Mon, 16 Nov 2015 16:54:18 +0100 Subject: [gnutls-devel] Automatic library initialization In-Reply-To: References: <1851199.M1iFb0Yqm5@blitz-lx> Message-ID: <1676759.OG3GPZkmOx@blitz-lx> On Monday 16 November 2015 16:23:31 Nikos Mavrogiannopoulos wrote: > On Mon, Nov 16, 2015 at 3:17 PM, Nikos Mavrogiannopoulos > > wrote: > >>> > 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. We need to find something > > better to prevent the constructor being run for specific applications > > Something like the following. Have each program not wishing to use > global initialization to define a symbol which overrides a weak one > from gnutls. In practice that would mean setting: > GNUTLS_SKIP_GLOBAL_INIT > > in some global section in your program. That can also be easily > backported in 3.3.x and you can check for that feature with an ifdef. > Would that be acceptable? Brilliant idea. I'll use it for my projects... but other projects won't benefit immediately (they first have to know). Regards, Tim From nmav at gnutls.org Mon Nov 16 17:24:29 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 16 Nov 2015 17:24:29 +0100 Subject: [gnutls-devel] Automatic library initialization In-Reply-To: <1676759.OG3GPZkmOx@blitz-lx> References: <1851199.M1iFb0Yqm5@blitz-lx> <1676759.OG3GPZkmOx@blitz-lx> Message-ID: On Mon, Nov 16, 2015 at 4:54 PM, Tim Ruehsen wrote: >> Something like the following. Have each program not wishing to use >> global initialization to define a symbol which overrides a weak one >> from gnutls. In practice that would mean setting: >> GNUTLS_SKIP_GLOBAL_INIT >> in some global section in your program. That can also be easily >> backported in 3.3.x and you can check for that feature with an ifdef. >> Would that be acceptable? > Brilliant idea. I'll use it for my projects... but other projects won't > benefit immediately (they first have to know). I'll then include it in 3.4.x and 3.3.x releases. regards, Nikos From andrew.w.nosenko at gmail.com Mon Nov 16 18:10:02 2015 From: andrew.w.nosenko at gmail.com (Andrew W. Nosenko) Date: Mon, 16 Nov 2015 19:10:02 +0200 Subject: [gnutls-devel] Automatic library initialization In-Reply-To: References: <1851199.M1iFb0Yqm5@blitz-lx> <1676759.OG3GPZkmOx@blitz-lx> Message-ID: On Mon, Nov 16, 2015 at 6:24 PM, Nikos Mavrogiannopoulos wrote: > On Mon, Nov 16, 2015 at 4:54 PM, Tim Ruehsen wrote: > >> Something like the following. Have each program not wishing to use > >> global initialization to define a symbol which overrides a weak one > >> from gnutls. In practice that would mean setting: > >> GNUTLS_SKIP_GLOBAL_INIT > >> in some global section in your program. That can also be easily > >> backported in 3.3.x and you can check for that feature with an ifdef. > >> Would that be acceptable? > > Brilliant idea. I'll use it for my projects... but other projects won't > > benefit immediately (they first have to know). > > I'll then include it in 3.4.x and 3.3.x releases. > > First at all, IMHO, _current_ API, which eliminates requirement to call explicitly some init function is a good. And the "old-style API" with requirement to call some init function before any thread and/or child processes will be forked, which you want to resurrect, is a bad. Very simple example: DSO uses some library, which have requirement to global init. DSO loaded on demand. How you meet this "global init before any thread forked" requirement? -- Andrew W. Nosenko -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Mon Nov 16 18:57:49 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 16 Nov 2015 18:57:49 +0100 Subject: [gnutls-devel] Automatic library initialization In-Reply-To: References: <1851199.M1iFb0Yqm5@blitz-lx> <1676759.OG3GPZkmOx@blitz-lx> Message-ID: On Mon, Nov 16, 2015 at 6:10 PM, Andrew W. Nosenko wrote: >> >> Something like the following. Have each program not wishing to use >> >> global initialization to define a symbol which overrides a weak one >> >> from gnutls. In practice that would mean setting: >> >> GNUTLS_SKIP_GLOBAL_INIT >> >> in some global section in your program. That can also be easily >> >> backported in 3.3.x and you can check for that feature with an ifdef. >> >> Would that be acceptable? >> > Brilliant idea. I'll use it for my projects... but other projects won't >> > benefit immediately (they first have to know). >> I'll then include it in 3.4.x and 3.3.x releases. > First at all, IMHO, _current_ API, which eliminates requirement to call > explicitly some init function is a good. And the "old-style API" with > requirement to call some init function before any thread and/or child > processes will be forked, which you want to resurrect, is a bad. I believe you misunderstood the intention. There will be a way for certain applications to disable the "automatic" initialization. Otherwise, all other applications and libraries will take advantage of that, and need not to call gnutls_global_init(). regards, Nikos From tim.ruehsen at gmx.de Mon Nov 16 19:37:27 2015 From: tim.ruehsen at gmx.de (Tim =?ISO-8859-1?Q?R=FChsen?=) Date: Mon, 16 Nov 2015 19:37:27 +0100 Subject: [gnutls-devel] Automatic library initialization In-Reply-To: References: <1851199.M1iFb0Yqm5@blitz-lx> Message-ID: <14338381.8g3DYUo2hc@debian> Am Montag, 16. November 2015, 19:10:02 schrieb Andrew W. Nosenko: > On Mon, Nov 16, 2015 at 6:24 PM, Nikos Mavrogiannopoulos > > wrote: > > On Mon, Nov 16, 2015 at 4:54 PM, Tim Ruehsen wrote: > > >> Something like the following. Have each program not wishing to use > > >> global initialization to define a symbol which overrides a weak one > > >> from gnutls. In practice that would mean setting: > > >> GNUTLS_SKIP_GLOBAL_INIT > > >> in some global section in your program. That can also be easily > > >> backported in 3.3.x and you can check for that feature with an ifdef. > > >> Would that be acceptable? > > > > > > Brilliant idea. I'll use it for my projects... but other projects won't > > > benefit immediately (they first have to know). > > > > I'll then include it in 3.4.x and 3.3.x releases. > > First at all, IMHO, _current_ API, which eliminates requirement to call > explicitly some init function is a good. And the "old-style API" with > requirement to call some init function before any thread and/or child > processes will be forked, which you want to resurrect, is a bad. > > Very simple example: DSO uses some library, which have requirement to > global init. DSO loaded on demand. How you meet this "global init before > any thread forked" requirement? I already wrote some words regarding this scenario earlier in this thread. Please re-read. Despite that, Nikos found a solution that doesn't touch current behavior. Tim From luto at amacapital.net Mon Nov 16 19:45:19 2015 From: luto at amacapital.net (Andy Lutomirski) Date: Mon, 16 Nov 2015 10:45:19 -0800 Subject: [gnutls-devel] Automatic library initialization In-Reply-To: <14338381.8g3DYUo2hc@debian> References: <1851199.M1iFb0Yqm5@blitz-lx> <14338381.8g3DYUo2hc@debian> Message-ID: On Mon, Nov 16, 2015 at 10:37 AM, Tim R?hsen wrote: > Am Montag, 16. November 2015, 19:10:02 schrieb Andrew W. Nosenko: >> On Mon, Nov 16, 2015 at 6:24 PM, Nikos Mavrogiannopoulos >> >> wrote: >> > On Mon, Nov 16, 2015 at 4:54 PM, Tim Ruehsen wrote: >> > >> Something like the following. Have each program not wishing to use >> > >> global initialization to define a symbol which overrides a weak one >> > >> from gnutls. In practice that would mean setting: >> > >> GNUTLS_SKIP_GLOBAL_INIT >> > >> in some global section in your program. That can also be easily >> > >> backported in 3.3.x and you can check for that feature with an ifdef. >> > >> Would that be acceptable? >> > > >> > > Brilliant idea. I'll use it for my projects... but other projects won't >> > > benefit immediately (they first have to know). >> > >> > I'll then include it in 3.4.x and 3.3.x releases. >> >> First at all, IMHO, _current_ API, which eliminates requirement to call >> explicitly some init function is a good. And the "old-style API" with >> requirement to call some init function before any thread and/or child >> processes will be forked, which you want to resurrect, is a bad. >> >> Very simple example: DSO uses some library, which have requirement to >> global init. DSO loaded on demand. How you meet this "global init before >> any thread forked" requirement? > > I already wrote some words regarding this scenario earlier in this thread. > Please re-read. > > Despite that, Nikos found a solution that doesn't touch current behavior. > > Tim > What exactly does gnutls do during initialization that takes this much time? Could it be made to generate whatever tables it needs at compile time? (I guess it needs to self-tests, but that should only apply in FIPS mode, which shouldn't be the default.) --Andy > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-devel -- Andy Lutomirski AMA Capital Management, LLC From tim.ruehsen at gmx.de Mon Nov 16 21:14:33 2015 From: tim.ruehsen at gmx.de (Tim =?ISO-8859-1?Q?R=FChsen?=) Date: Mon, 16 Nov 2015 21:14:33 +0100 Subject: [gnutls-devel] Automatic library initialization In-Reply-To: References: <1851199.M1iFb0Yqm5@blitz-lx> <14338381.8g3DYUo2hc@debian> Message-ID: <3544348.zKZA7VGFkC@debian> Am Montag, 16. November 2015, 10:45:19 schrieb Andy Lutomirski: > On Mon, Nov 16, 2015 at 10:37 AM, Tim R?hsen wrote: > > Am Montag, 16. November 2015, 19:10:02 schrieb Andrew W. Nosenko: > >> On Mon, Nov 16, 2015 at 6:24 PM, Nikos Mavrogiannopoulos > >> > >> > >> wrote: > >> > On Mon, Nov 16, 2015 at 4:54 PM, Tim Ruehsen wrote: > >> > >> Something like the following. Have each program not wishing to use > >> > >> global initialization to define a symbol which overrides a weak one > >> > >> from gnutls. In practice that would mean setting: > >> > >> GNUTLS_SKIP_GLOBAL_INIT > >> > >> in some global section in your program. That can also be easily > >> > >> backported in 3.3.x and you can check for that feature with an > >> > >> ifdef. > >> > >> Would that be acceptable? > >> > > > >> > > Brilliant idea. I'll use it for my projects... but other projects > >> > > won't > >> > > benefit immediately (they first have to know). > >> > > >> > I'll then include it in 3.4.x and 3.3.x releases. > >> > >> First at all, IMHO, _current_ API, which eliminates requirement to call > >> explicitly some init function is a good. And the "old-style API" with > >> requirement to call some init function before any thread and/or child > >> processes will be forked, which you want to resurrect, is a bad. > >> > >> Very simple example: DSO uses some library, which have requirement to > >> global init. DSO loaded on demand. How you meet this "global init > >> before > >> any thread forked" requirement? > > > > I already wrote some words regarding this scenario earlier in this thread. > > Please re-read. > > > > Despite that, Nikos found a solution that doesn't touch current behavior. > > > > Tim > > What exactly does gnutls do during initialization that takes this much > time? Could it be made to generate whatever tables it needs at > compile time? > > (I guess it needs to self-tests, but that should only apply in FIPS > mode, which shouldn't be the default.) You can have a look at code in lib/gnutls_global.c (branch gnutls_3_3_x). To see what function calls takes how many cycles, I use (on Debian SID, KDE): $ valgrind --tool=callgrind wget $ kcachegrind callgrind.out.xxxxx Shows ~16.000.000 cycles. Most (65%) of the time goes into _gnutls_rnd_init() which calls wrap_nettle_rnd_init(). But please check this yourself. What I currently don't understand is why currently so many cycles go into _dl_start() and the like (relocation, symbol lookups) - ~4.000.000 cycles. This has been much less a few months ago... looks like immediate binding, but 'hardening-check' says no. Something has changed in Debian - looks like all symbols are relocated directly at startup, currently. Regards, Tim From andrew.w.nosenko at gmail.com Mon Nov 16 22:35:50 2015 From: andrew.w.nosenko at gmail.com (Andrew W. Nosenko) Date: Mon, 16 Nov 2015 23:35:50 +0200 Subject: [gnutls-devel] Automatic library initialization In-Reply-To: <3544348.zKZA7VGFkC@debian> References: <1851199.M1iFb0Yqm5@blitz-lx> <14338381.8g3DYUo2hc@debian> <3544348.zKZA7VGFkC@debian> Message-ID: On Mon, Nov 16, 2015 at 10:14 PM, Tim R?hsen wrote: > Am Montag, 16. November 2015, 10:45:19 schrieb Andy Lutomirski: > > On Mon, Nov 16, 2015 at 10:37 AM, Tim R?hsen wrote: > > > Am Montag, 16. November 2015, 19:10:02 schrieb Andrew W. Nosenko: > > >> On Mon, Nov 16, 2015 at 6:24 PM, Nikos Mavrogiannopoulos > > >> > > >> > > >> wrote: > > >> > On Mon, Nov 16, 2015 at 4:54 PM, Tim Ruehsen > wrote: > > >> > >> Something like the following. Have each program not wishing to > use > > >> > >> global initialization to define a symbol which overrides a weak > one > > >> > >> from gnutls. In practice that would mean setting: > > >> > >> GNUTLS_SKIP_GLOBAL_INIT > > >> > >> in some global section in your program. That can also be easily > > >> > >> backported in 3.3.x and you can check for that feature with an > > >> > >> ifdef. > > >> > >> Would that be acceptable? > > >> > > > > >> > > Brilliant idea. I'll use it for my projects... but other projects > > >> > > won't > > >> > > benefit immediately (they first have to know). > > >> > > > >> > I'll then include it in 3.4.x and 3.3.x releases. > > >> > > >> First at all, IMHO, _current_ API, which eliminates requirement to > call > > >> explicitly some init function is a good. And the "old-style API" with > > >> requirement to call some init function before any thread and/or child > > >> processes will be forked, which you want to resurrect, is a bad. > > >> > > >> Very simple example: DSO uses some library, which have requirement to > > >> global init. DSO loaded on demand. How you meet this "global init > > >> before > > >> any thread forked" requirement? > > > > > > I already wrote some words regarding this scenario earlier in this > thread. > > > Please re-read. > > > > > > Despite that, Nikos found a solution that doesn't touch current > behavior. > > > > > > Tim > > > > What exactly does gnutls do during initialization that takes this much > > time? Could it be made to generate whatever tables it needs at > > compile time? > > > > (I guess it needs to self-tests, but that should only apply in FIPS > > mode, which shouldn't be the default.) > > You can have a look at code in lib/gnutls_global.c (branch gnutls_3_3_x). > > To see what function calls takes how many cycles, I use (on Debian SID, > KDE): > $ valgrind --tool=callgrind wget > $ kcachegrind callgrind.out.xxxxx > > Shows ~16.000.000 cycles. > > Most (65%) of the time goes into _gnutls_rnd_init() which calls > wrap_nettle_rnd_init(). > But please check this yourself. > > What I currently don't understand is why currently so many cycles go into > _dl_start() and the like (relocation, symbol lookups) - ~4.000.000 cycles. > This has been much less a few months ago... looks like immediate binding, > but > 'hardening-check' says no. Something has changed in Debian - looks like all > symbols are relocated directly at startup, currently. > Just a side note: it would be interesting to verify valgrind's results by something like DTrace/SystemTap... I.e. by something that probes running system instead of simulated environment. About relocation: some sort of ASLR? -- Andrew W. Nosenko -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.w.nosenko at gmail.com Mon Nov 16 22:50:00 2015 From: andrew.w.nosenko at gmail.com (Andrew W. Nosenko) Date: Mon, 16 Nov 2015 23:50:00 +0200 Subject: [gnutls-devel] Automatic library initialization In-Reply-To: References: <1851199.M1iFb0Yqm5@blitz-lx> <1676759.OG3GPZkmOx@blitz-lx> Message-ID: On Mon, Nov 16, 2015 at 7:57 PM, Nikos Mavrogiannopoulos wrote: > On Mon, Nov 16, 2015 at 6:10 PM, Andrew W. Nosenko > wrote: > >> >> Something like the following. Have each program not wishing to use > >> >> global initialization to define a symbol which overrides a weak one > >> >> from gnutls. In practice that would mean setting: > >> >> GNUTLS_SKIP_GLOBAL_INIT > >> >> in some global section in your program. That can also be easily > >> >> backported in 3.3.x and you can check for that feature with an ifdef. > >> >> Would that be acceptable? > >> > Brilliant idea. I'll use it for my projects... but other projects > won't > >> > benefit immediately (they first have to know). > >> I'll then include it in 3.4.x and 3.3.x releases. > > First at all, IMHO, _current_ API, which eliminates requirement to call > > explicitly some init function is a good. And the "old-style API" with > > requirement to call some init function before any thread and/or child > > processes will be forked, which you want to resurrect, is a bad. > > I believe you misunderstood the intention. There will be a way for > certain applications to disable the "automatic" initialization. > Otherwise, all other applications and libraries will take advantage of > that, and need not to call gnutls_global_init(). > > I understood the intention. Just a solution is fragile, if my assumption is correct. Assumption: library can inadvertently or intentionally define "hard" symbol. It will overplay the weak symbol in GnuTLS. It affects the whole process, not the only library, which set that symbol. So, we have library, which functioning as intended (or not, it depends), and all other pieces of process, which are damaged. -- Andrew W. Nosenko -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.mavrogiannopoulos at gmail.com Tue Nov 17 07:30:36 2015 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Tue, 17 Nov 2015 07:30:36 +0100 Subject: [gnutls-devel] Automatic library initialization In-Reply-To: <3544348.zKZA7VGFkC@debian> References: <1851199.M1iFb0Yqm5@blitz-lx> <14338381.8g3DYUo2hc@debian> <3544348.zKZA7VGFkC@debian> Message-ID: <1447741836.3226.6.camel@gmail.com> On Mon, 2015-11-16 at 21:14 +0100, Tim R?hsen wrote: > To see what function calls takes how many cycles, I use (on Debian > SID, KDE): > $ valgrind --tool=callgrind wget > $ kcachegrind callgrind.out.xxxxx > > Shows ~16.000.000 cycles. > > Most (65%) of the time goes into _gnutls_rnd_init() which calls > wrap_nettle_rnd_init(). Interesting. That's should be the yarrow and salsa20 initialization for the random number generation. That doesn't seem to be something we can easily optimize unless we switch to different RNG. I'll try to check whether there can be parts of the global init that provide a significant optimization if moved to a static initialization. regards, Nikos From nmav at gnutls.org Tue Nov 17 07:32:39 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 17 Nov 2015 07:32:39 +0100 Subject: [gnutls-devel] Automatic library initialization In-Reply-To: References: <1851199.M1iFb0Yqm5@blitz-lx> <1676759.OG3GPZkmOx@blitz-lx> Message-ID: <1447741959.3226.8.camel@gnutls.org> On Mon, 2015-11-16 at 23:50 +0200, Andrew W. Nosenko wrote: > I understood the intention. Just a solution is fragile, if my > assumption is correct. > Assumption: library can inadvertently or intentionally define "hard" > symbol. It will overplay the weak symbol in GnuTLS. It affects the > whole process, not the only library, which set that symbol. So, we > have library, which functioning as intended (or not, it depends), and > all other pieces of process, which are damaged. I understand, but the alternative would be not allowing a quick initialization to applications like wget. Is there anything we can do to prevent that symbol from being included in shared libraries? regards, Nikos From nmav at gnutls.org Sun Nov 22 13:44:37 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 22 Nov 2015 13:44:37 +0100 Subject: [gnutls-devel] gnutls 3.3.19 Message-ID: <1448196277.22666.1.camel@gnutls.org> Hello, I've just released gnutls 3.3.19. This is a bug-fix release on the current stable branch. * Version 3.3.19 (released 2015-11-22) ** libgnutls: Properly require TLS 1.2 to all the CBC-SHA256 and CBC-SHA384 ciphersuites. This solves an interoperability issue with openssl. Reported by Viktor Dukhovni. ** libgnutls: Fixed memory leak in gnutls_pubkey_get_preferred_hash_algorithm(), patch by Lennert Buytenhek. ** libgnutls: When writing a certificate into a PKCS #11 token, ensure that CKA_SERIAL_NUMBER and CKA_ISSUER are written. ** libgnutls: Allow the presence of legacy ciphers and key exchanges in priority strings and consider them a no-op. ** libgnutls: On a rehandshake allow switching from anonymous to ECDHE and DHE ciphersuites. ** libgnutls: Added GNUTLS_SKIP_GLOBAL_INIT macro to allow programs skipping the implicit global initialization. ** gnutls.pc: Don't include libtool specific options to link flags. Reported by Dan Kegel. ** API and ABI modifications: GNUTLS_SKIP_GLOBAL_INIT: Added Getting the Software ==================== GnuTLS may be downloaded directly from .??A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.19.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.19.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.19.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.19.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Sun Nov 22 13:46:35 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 22 Nov 2015 13:46:35 +0100 Subject: [gnutls-devel] gnutls 3.4.7 Message-ID: <1448196395.22666.3.camel@gnutls.org> Hello, I've just released gnutls 3.4.7. This version fixes bugs and adds minor features to the next stable branch. * Version 3.4.7 (released 2015-11-22) ** libgnutls: Properly require TLS 1.2 in all CBC-SHA256 and CBC-SHA384 ciphersuites. This solves an interoperability issue with openssl. Reported by Viktor Dukhovni. ** libgnutls: Corrected the setting of salt size in gnutls_pkcs12_mac_info(). ** libgnutls: On a rehandshake allow switching from anonymous to ECDHE and DHE ciphersuites. ** libgnutls: Corrected regression from 3.3.x which prevented ARCFOUR128 from using arbitrary key sizes. Reported by Andreas Schneider. ** libgnutls: Added GNUTLS_SKIP_GLOBAL_INIT macro to allow programs skipping the implicit global initialization. ** gnutls.pc: Don't include libtool specific options to link flags. Reported by Dan Kegel. ** tools: Better support for FTP AUTH TLS negotiation ** API and ABI modifications: gnutls_x509_crt_set_issuer_unique_id: Added gnutls_x509_crt_set_subject_unique_id: Added gnutls_certificate_set_flags: Added GNUTLS_CERTIFICATE_SKIP_KEY_CERT_MATCH: Added Getting the Software ==================== GnuTLS may be downloaded directly from .??A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.7.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.7.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.7.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.7.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Mon Nov 23 11:23:29 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 23 Nov 2015 11:23:29 +0100 Subject: [gnutls-devel] Automatic library initialization In-Reply-To: References: <1851199.M1iFb0Yqm5@blitz-lx> <1676759.OG3GPZkmOx@blitz-lx> Message-ID: On Mon, Nov 16, 2015 at 5:24 PM, Nikos Mavrogiannopoulos wrote: >> Brilliant idea. I'll use it for my projects... but other projects won't >> benefit immediately (they first have to know). > I'll then include it in 3.4.x and 3.3.x releases. It was included in the 3.4.x and 3.3.x releases, but this option must be used with extreme care. Even though you may know where in your application gnutls usage starts, you may not know whether some library that you use will use it. You may not know for example that getpwnam() will end up requiring to call gnutls in some setups. For that it should not be used lightly as you'll rediscover the bugs that the initialization to constructor was solving. regards, Nikos From tim.ruehsen at gmx.de Tue Nov 24 10:38:41 2015 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Tue, 24 Nov 2015 10:38:41 +0100 Subject: [gnutls-devel] Automatic library initialization In-Reply-To: References: <1851199.M1iFb0Yqm5@blitz-lx> Message-ID: <2158272.OFI6WWqjVg@blitz-lx> On Monday 23 November 2015 11:23:29 Nikos Mavrogiannopoulos wrote: > On Mon, Nov 16, 2015 at 5:24 PM, Nikos Mavrogiannopoulos > > wrote: > >> Brilliant idea. I'll use it for my projects... but other projects won't > >> benefit immediately (they first have to know). > > > > I'll then include it in 3.4.x and 3.3.x releases. > > It was included in the 3.4.x and 3.3.x releases, but this option must > be used with extreme care. Even though you may know where in your > application gnutls usage starts, you may not know whether some library > that you use will use it. You may not know for example that getpwnam() > will end up requiring to call gnutls in some setups. For that it > should not be used lightly as you'll rediscover the bugs that the > initialization to constructor was solving. Thanks for pointing out (I wasn't aware of getpwnam pulling in gnutls). As far as I can see, on (most ?) multi-threaded environments gnutls_global_init is thread-safe via GNUTLS_STATIC_MUTEX* !? If a system offers multi-threading, it will also offer mutexes/locks that could/will be used by gnutls. What am I missing ? Regards, Tim From nmav at gnutls.org Tue Nov 24 13:45:10 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 24 Nov 2015 13:45:10 +0100 Subject: [gnutls-devel] Automatic library initialization In-Reply-To: <2158272.OFI6WWqjVg@blitz-lx> References: <1851199.M1iFb0Yqm5@blitz-lx> <2158272.OFI6WWqjVg@blitz-lx> Message-ID: On Tue, Nov 24, 2015 at 10:38 AM, Tim Ruehsen wrote: >> It was included in the 3.4.x and 3.3.x releases, but this option must >> be used with extreme care. Even though you may know where in your >> application gnutls usage starts, you may not know whether some library >> that you use will use it. You may not know for example that getpwnam() >> will end up requiring to call gnutls in some setups. For that it >> should not be used lightly as you'll rediscover the bugs that the >> initialization to constructor was solving. > Thanks for pointing out (I wasn't aware of getpwnam pulling in gnutls). > As far as I can see, on (most ?) multi-threaded environments > gnutls_global_init is thread-safe via GNUTLS_STATIC_MUTEX* !? > If a system offers multi-threading, it will also offer mutexes/locks that > could/will be used by gnutls. What am I missing ? [replying again on list] It would be safe only if the library that uses gnutls calls gnutls_global_init() explicitly. If it relies on it being called on a constructor you'll run into issues. regards, Nikos From andrew.w.nosenko at gmail.com Tue Nov 24 16:06:41 2015 From: andrew.w.nosenko at gmail.com (Andrew W. Nosenko) Date: Tue, 24 Nov 2015 17:06:41 +0200 Subject: [gnutls-devel] Automatic library initialization In-Reply-To: References: <1851199.M1iFb0Yqm5@blitz-lx> <2158272.OFI6WWqjVg@blitz-lx> Message-ID: On Tue, Nov 24, 2015 at 2:45 PM, Nikos Mavrogiannopoulos wrote: > On Tue, Nov 24, 2015 at 10:38 AM, Tim Ruehsen wrote: > >> It was included in the 3.4.x and 3.3.x releases, but this option must > >> be used with extreme care. Even though you may know where in your > >> application gnutls usage starts, you may not know whether some library > >> that you use will use it. You may not know for example that getpwnam() > >> will end up requiring to call gnutls in some setups. For that it > >> should not be used lightly as you'll rediscover the bugs that the > >> initialization to constructor was solving. > > Thanks for pointing out (I wasn't aware of getpwnam pulling in gnutls). > > As far as I can see, on (most ?) multi-threaded environments > > gnutls_global_init is thread-safe via GNUTLS_STATIC_MUTEX* !? > > If a system offers multi-threading, it will also offer mutexes/locks that > > could/will be used by gnutls. What am I missing ? > > [replying again on list] > > It would be safe only if the library that uses gnutls calls > gnutls_global_init() explicitly. If it relies on it being called on a > constructor you'll run into issues. > > No, because library doesn't know and has no way to know whether process spawned some threads already or not. -- Andrew W. Nosenko -------------- next part -------------- An HTML attachment was scrubbed... URL: From ametzler at bebt.de Tue Nov 24 19:49:45 2015 From: ametzler at bebt.de (Andreas Metzler) Date: Tue, 24 Nov 2015 19:49:45 +0100 Subject: [gnutls-devel] 3.3.19 / 3.4.7 Guile related testsuite segfaults Message-ID: <20151124184945.GB4525@downhill.g.la> Hello, on amd64 there are segfaults in the guile testsuite: (sid-AMD64)ametzler at argenau:/tmp/GNUTLS/gnutls-3.3.19/guile/tests$ while make t est-suite.log TEST_LOGS=openpgp-auth.scm.log ; do sleep .3 ; rm openpgp-auth.scm.log openpgp-auth.scm.trs test-suite.log ; done PASS: openpgp-auth.scm [...] ../../build-aux/test-driver: line 107: 16038 Segmentation fault (core dumped) "$@" > $log_file 2>&1 FAIL: openpgp-auth.scm ============================================================================ Testsuite summary for GnuTLS 3.3.19 ============================================================================ # TOTAL: 1 # PASS: 0 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 ============================================================================ See guile/tests/test-suite.log Please report to bugs at gnutls.org ============================================================================ Makefile:1492: recipe for target 'test-suite.log' failed make: *** [test-suite.log] Error 1 The coredump is not helpful at all: sid-AMD64)ametzler at argenau:/tmp/GNUTLS/gnutls-3.3.19/guile/tests$ gdb --core=core [...] Core was generated by `/usr/bin/guile -L . ./openpgp-auth.scm'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007ff1c5d94d50 in ?? () [Current thread is 1 (LWP 16038)] (gdb) bt full #0 0x00007ff1c5d94d50 in ?? () No symbol table info available. #1 0x0000000000000000 in ?? () No symbol table info available. (gdb) quit This is , the bug does not always happen and it is not the always the same test that fails (the original submitter hat "better" luck with x509-auth.scm). cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -------------- next part -------------- FAIL openpgp-auth.scm (exit status: 139) -------------- next part -------------- :test-result: FAIL :global-test-result: FAIL :recheck: yes :copy-in-global-log: yes -------------- next part -------------- =============================================== GnuTLS 3.3.19: guile/tests/test-suite.log =============================================== # TOTAL: 1 # PASS: 0 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: openpgp-auth.scm ====================== FAIL openpgp-auth.scm (exit status: 139) From ludo at gnu.org Thu Nov 26 12:27:33 2015 From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Date: Thu, 26 Nov 2015 12:27:33 +0100 Subject: [gnutls-devel] 3.3.19 / 3.4.7 Guile related testsuite segfaults In-Reply-To: <20151124184945.GB4525@downhill.g.la> (Andreas Metzler's message of "Tue, 24 Nov 2015 19:49:45 +0100") References: <20151124184945.GB4525@downhill.g.la> Message-ID: <87k2p5yp96.fsf@gnu.org> Andreas Metzler skribis: > on amd64 there are segfaults in the guile testsuite: > > (sid-AMD64)ametzler at argenau:/tmp/GNUTLS/gnutls-3.3.19/guile/tests$ while make t > est-suite.log TEST_LOGS=openpgp-auth.scm.log ; do sleep .3 ; rm openpgp-auth.scm.log openpgp-auth.scm.trs test-suite.log ; done > PASS: openpgp-auth.scm > [...] > ../../build-aux/test-driver: line 107: 16038 Segmentation fault (core dumped) "$@" > $log_file 2>&1 > FAIL: openpgp-auth.scm So this test does not fail systematically, right? I tested in an isolated build environment with 3.4.7 but I can?t reproduce the problem, even when running ?make check -C guile/tests? in a loop. This reminds me of , but I think that bug would lead to systematic segfaults. > Core was generated by `/usr/bin/guile -L . ./openpgp-auth.scm'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x00007ff1c5d94d50 in ?? () > [Current thread is 1 (LWP 16038)] > (gdb) bt full > #0 0x00007ff1c5d94d50 in ?? () > No symbol table info available. > #1 0x0000000000000000 in ?? () > No symbol table info available. Could you check ?info files? too, just in case some conflicting versions of libguile or something are being used? Also, what Guile and libgc versions are these? I?m testing with Guile 2.0.11 and libgc 7.4.2. Thanks, Ludo?. From ametzler at bebt.de Thu Nov 26 19:34:40 2015 From: ametzler at bebt.de (Andreas Metzler) Date: Thu, 26 Nov 2015 19:34:40 +0100 Subject: [gnutls-devel] 3.3.19 / 3.4.7 Guile related testsuite segfaults In-Reply-To: <87k2p5yp96.fsf@gnu.org> References: <20151124184945.GB4525@downhill.g.la> <87k2p5yp96.fsf@gnu.org> Message-ID: <20151126183439.GA2736@downhill.g.la> On 2015-11-26 Ludovic Court?s wrote: > Andreas Metzler skribis: >> on amd64 there are segfaults in the guile testsuite: >> (sid-AMD64)ametzler at argenau:/tmp/GNUTLS/gnutls-3.3.19/guile/tests$ while make t >> est-suite.log TEST_LOGS=openpgp-auth.scm.log ; do sleep .3 ; rm openpgp-auth.scm.log openpgp-auth.scm.trs test-suite.log ; done >> PASS: openpgp-auth.scm >> [...] >> ../../build-aux/test-driver: line 107: 16038 Segmentation fault (core dumped) "$@" > $log_file 2>&1 >> FAIL: openpgp-auth.scm > So this test does not fail systematically, right? Hello, It does not fail on every invocation, but when I uploaded 3.3.19 and 3.4.7 on Sunday both autobuilds failed. > I tested in an isolated build environment with 3.4.7 but I can?t > reproduce the problem, even when running ?make check -C guile/tests? in > a loop. I have just reprodiced this (with a loop) on both 3.3.18 and 3.3.19. > This reminds me of > , > but I think that bug would lead to systematic segfaults. > > Core was generated by `/usr/bin/guile -L . ./openpgp-auth.scm'. > > Program terminated with signal SIGSEGV, Segmentation fault. > > #0 0x00007ff1c5d94d50 in ?? () > > [Current thread is 1 (LWP 16038)] > > (gdb) bt full > > #0 0x00007ff1c5d94d50 in ?? () > > No symbol table info available. > > #1 0x0000000000000000 in ?? () > > No symbol table info available. > Could you check ?info files? too, just in case some conflicting versions > of libguile or something are being used? For help, type "help". Type "apropos word" to search for commands related to "word". [New LWP 29066] [New LWP 29074] Core was generated by `/usr/bin/guile -L . ./openpgp-auth.scm'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f4b896c5630 in ?? () [Current thread is 1 (LWP 29066)] (gdb) bt full #0 0x00007f4b896c5630 in ?? () No symbol table info available. #1 0x0000000000000000 in ?? () No symbol table info available. (gdb) info files Local core dump file: `/tmp/GNUTLS/gnutls-3.3.19/guile/tests/core', file type elf64-x86-64. 0x0000000000400000 - 0x0000000000401000 is load1 0x0000000000601000 - 0x0000000000602000 is load2 0x0000000000602000 - 0x0000000000603000 is load3 0x00000000023bc000 - 0x0000000002787000 is load4 0x00007f4b862a2000 - 0x00007f4b862a3000 is load5a 0x00007f4b862a3000 - 0x00007f4b862a3000 is load5b 0x00007f4b862d4000 - 0x00007f4b862d4000 is load6 0x00007f4b864d4000 - 0x00007f4b864d5000 is load7 0x00007f4b864d5000 - 0x00007f4b864d6000 is load8 0x00007f4b864d6000 - 0x00007f4b864d7000 is load9a 0x00007f4b864d7000 - 0x00007f4b864d7000 is load9b 0x00007f4b8650b000 - 0x00007f4b8650b000 is load10 0x00007f4b8670a000 - 0x00007f4b8670c000 is load11 0x00007f4b8670c000 - 0x00007f4b8670d000 is load12 0x00007f4b8670d000 - 0x00007f4b8670e000 is load13a 0x00007f4b8670e000 - 0x00007f4b8670e000 is load13b 0x00007f4b8671f000 - 0x00007f4b8671f000 is load14 0x00007f4b8691e000 - 0x00007f4b8691f000 is load15 0x00007f4b8691f000 - 0x00007f4b86920000 is load16 0x00007f4b86920000 - 0x00007f4b86921000 is load17a 0x00007f4b86921000 - 0x00007f4b86921000 is load17b 0x00007f4b8697a000 - 0x00007f4b8697a000 is load18 0x00007f4b86b7a000 - 0x00007f4b86b84000 is load19 0x00007f4b86b84000 - 0x00007f4b86b86000 is load20 0x00007f4b86b86000 - 0x00007f4b86b87000 is load21a 0x00007f4b86b87000 - 0x00007f4b86b87000 is load21b 0x00007f4b86ba0000 - 0x00007f4b86ba0000 is load22 0x00007f4b86d9f000 - 0x00007f4b86da0000 is load23 0x00007f4b86da0000 - 0x00007f4b86da1000 is load24 0x00007f4b86da1000 - 0x00007f4b86da2000 is load25a 0x00007f4b86da2000 - 0x00007f4b86da2000 is load25b 0x00007f4b86eb7000 - 0x00007f4b86eb7000 is load26 0x00007f4b870b7000 - 0x00007f4b870c0000 is load27 0x00007f4b870c0000 - 0x00007f4b870c2000 is load28 0x00007f4b870c2000 - 0x00007f4b870c3000 is load29 0x00007f4b870c3000 - 0x00007f4b870c4000 is load30a 0x00007f4b870c4000 - 0x00007f4b870c4000 is load30b 0x00007f4b870f0000 - 0x00007f4b870f0000 is load31 0x00007f4b872ef000 - 0x00007f4b872f2000 is load32 0x00007f4b872f2000 - 0x00007f4b872f5000 is load33 0x00007f4b872f5000 - 0x00007f4b872f6000 is load34a 0x00007f4b872f6000 - 0x00007f4b872f6000 is load34b 0x00007f4b872f7000 - 0x00007f4b872f7000 is load35 0x00007f4b874f6000 - 0x00007f4b874f7000 is load36 0x00007f4b874f7000 - 0x00007f4b874f8000 is load37 0x00007f4b874f8000 - 0x00007f4b874f9000 is load38 0x00007f4b874f9000 - 0x00007f4b87cf9000 is load39 0x00007f4b87cf9000 - 0x00007f4b87cfa000 is load40a 0x00007f4b87cfa000 - 0x00007f4b87cfa000 is load40b 0x00007f4b87cfc000 - 0x00007f4b87cfc000 is load41 0x00007f4b87efb000 - 0x00007f4b87efc000 is load42 0x00007f4b87efc000 - 0x00007f4b87efd000 is load43 0x00007f4b87efd000 - 0x00007f4b87efe000 is load44a 0x00007f4b87efe000 - 0x00007f4b87efe000 is load44b 0x00007f4b87f06000 - 0x00007f4b87f06000 is load45 0x00007f4b88105000 - 0x00007f4b88106000 is load46 0x00007f4b88106000 - 0x00007f4b88107000 is load47 0x00007f4b88107000 - 0x00007f4b88108000 is load48a 0x00007f4b88108000 - 0x00007f4b88108000 is load48b 0x00007f4b88189000 - 0x00007f4b88189000 is load49 0x00007f4b88388000 - 0x00007f4b88389000 is load50 0x00007f4b88389000 - 0x00007f4b8838a000 is load51 0x00007f4b8838a000 - 0x00007f4b8838b000 is load52a 0x00007f4b8838b000 - 0x00007f4b8838b000 is load52b 0x00007f4b8849d000 - 0x00007f4b8849d000 is load53 0x00007f4b8869d000 - 0x00007f4b886a0000 is load54 0x00007f4b886a0000 - 0x00007f4b886a1000 is load55 0x00007f4b886a1000 - 0x00007f4b886a1000 is load56 0x00007f4b886a2000 - 0x00007f4b886a3000 is load57a 0x00007f4b886a3000 - 0x00007f4b886a3000 is load57b 0x00007f4b886a9000 - 0x00007f4b886a9000 is load58 0x00007f4b888a9000 - 0x00007f4b888aa000 is load59 0x00007f4b888aa000 - 0x00007f4b888ab000 is load60 0x00007f4b888ab000 - 0x00007f4b888ac000 is load61a 0x00007f4b888ac000 - 0x00007f4b888ac000 is load61b 0x00007f4b888d7000 - 0x00007f4b888d7000 is load62 0x00007f4b88ad7000 - 0x00007f4b88ad9000 is load63 0x00007f4b88ad9000 - 0x00007f4b88b1b000 is load64 0x00007f4b88b1b000 - 0x00007f4b88b1c000 is load65a 0x00007f4b88b1c000 - 0x00007f4b88b1c000 is load65b 0x00007f4b88cba000 - 0x00007f4b88cba000 is load66 0x00007f4b88eba000 - 0x00007f4b88ebe000 is load67 0x00007f4b88ebe000 - 0x00007f4b88ec0000 is load68 0x00007f4b88ec0000 - 0x00007f4b88ec4000 is load69 0x00007f4b88ec4000 - 0x00007f4b88ec5000 is load70a 0x00007f4b88ec5000 - 0x00007f4b88ec5000 is load70b 0x00007f4b88edc000 - 0x00007f4b88edc000 is load71 0x00007f4b890db000 - 0x00007f4b890dc000 is load72 0x00007f4b890dc000 - 0x00007f4b890dd000 is load73 0x00007f4b890dd000 - 0x00007f4b890e1000 is load74 0x00007f4b890e1000 - 0x00007f4b890e2000 is load75a 0x00007f4b890e2000 - 0x00007f4b890e2000 is load75b 0x00007f4b891e1000 - 0x00007f4b891e1000 is load76 0x00007f4b893e0000 - 0x00007f4b893e1000 is load77 0x00007f4b893e1000 - 0x00007f4b893e2000 is load78 0x00007f4b893e2000 - 0x00007f4b893e3000 is load79a 0x00007f4b893e3000 - 0x00007f4b893e3000 is load79b 0x00007f4b893ea000 - 0x00007f4b893ea000 is load80 0x00007f4b895e9000 - 0x00007f4b895ea000 is load81 0x00007f4b895ea000 - 0x00007f4b895eb000 is load82 0x00007f4b895eb000 - 0x00007f4b895eb000 is load83 0x00007f4b89619000 - 0x00007f4b8961a000 is load84a 0x00007f4b8961a000 - 0x00007f4b8961a000 is load84b 0x00007f4b8976f000 - 0x00007f4b8976f000 is load85 0x00007f4b8996e000 - 0x00007f4b89980000 is load86 0x00007f4b89980000 - 0x00007f4b8999e000 is load87 0x00007f4b8999e000 - 0x00007f4b899ab000 is load88 0x00007f4b899ab000 - 0x00007f4b899ac000 is load89a 0x00007f4b899ac000 - 0x00007f4b899ac000 is load89b 0x00007f4b89b1f000 - 0x00007f4b89b1f000 is load90 0x00007f4b89b22000 - 0x00007f4b89b22000 is load91 0x00007f4b89b27000 - 0x00007f4b89b27000 is load92 0x00007f4b89b2d000 - 0x00007f4b89b2d000 is load93 0x00007f4b89b3a000 - 0x00007f4b89b3a000 is load94 0x00007f4b89b3d000 - 0x00007f4b89b3d000 is load95 0x00007f4b89b3f000 - 0x00007f4b89b3f000 is load96 0x00007f4b89b71000 - 0x00007f4b89b71000 is load97 0x00007f4b89b74000 - 0x00007f4b89b74000 is load98 0x00007f4b89bb6000 - 0x00007f4b89bb6000 is load99 0x00007f4b89bbd000 - 0x00007f4b89bc4000 is load100 0x00007f4b89bc4000 - 0x00007f4b89bc4000 is load101 0x00007f4b89bc5000 - 0x00007f4b89bc5000 is load102 0x00007f4b89bc9000 - 0x00007f4b89bcb000 is load103 0x00007f4b89bcb000 - 0x00007f4b89bcc000 is load104 0x00007f4b89bcc000 - 0x00007f4b89bcd000 is load105 0x00007f4b89bcd000 - 0x00007f4b89bce000 is load106 0x00007ffcb5eac000 - 0x00007ffcb5ece000 is load107 0x00007ffcb5f0f000 - 0x00007ffcb5f11000 is load108 0x00007ffcb5f11000 - 0x00007ffcb5f13000 is load109 0xffffffffff600000 - 0xffffffffff601000 is load110 -------------- FWIW looping over the test directly runs faster while GUILE_AUTO_COMPILE=0 GUILE_WARN_DEPRECATED=detailed GUILE_LOAD_PATH="/tmp/GNUTLS/gnutls-3.3.19/guile/modules:$GUILE_LOAD_PATH" GNUTLS_GUILE_EXTENSION_DIR="/tmp/GNUTLS/gnutls-3.3.19/guile/src" /usr/bin/guile-2.0 -L . ./openpgp-auth.scm ; do echo $? ; done I get a crash after less than ten seconds. throw to `wrong-type-arg' with args (#f "Wrong type: ~S" (Segmentation fault (core dumped) > Also, what Guile and libgc versions are these? > I?m testing with Guile 2.0.11 and libgc 7.4.2. 2.0.11+1-10 / 1:7.4.2-7.2 cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From tim.ruehsen at gmx.de Thu Nov 26 22:00:07 2015 From: tim.ruehsen at gmx.de (Tim =?ISO-8859-1?Q?R=FChsen?=) Date: Thu, 26 Nov 2015 22:00:07 +0100 Subject: [gnutls-devel] Automatic library initialization In-Reply-To: References: <1851199.M1iFb0Yqm5@blitz-lx> Message-ID: <7585947.94vllCb2WH@debian> Am Dienstag, 24. November 2015, 17:06:41 schrieb Andrew W. Nosenko: > On Tue, Nov 24, 2015 at 2:45 PM, Nikos Mavrogiannopoulos > > wrote: > > On Tue, Nov 24, 2015 at 10:38 AM, Tim Ruehsen wrote: > > >> It was included in the 3.4.x and 3.3.x releases, but this option must > > >> be used with extreme care. Even though you may know where in your > > >> application gnutls usage starts, you may not know whether some library > > >> that you use will use it. You may not know for example that getpwnam() > > >> will end up requiring to call gnutls in some setups. For that it > > >> should not be used lightly as you'll rediscover the bugs that the > > >> initialization to constructor was solving. > > > > > > Thanks for pointing out (I wasn't aware of getpwnam pulling in gnutls). > > > As far as I can see, on (most ?) multi-threaded environments > > > gnutls_global_init is thread-safe via GNUTLS_STATIC_MUTEX* !? > > > If a system offers multi-threading, it will also offer mutexes/locks > > > that > > > could/will be used by gnutls. What am I missing ? > > > > [replying again on list] > > > > It would be safe only if the library that uses gnutls calls > > gnutls_global_init() explicitly. If it relies on it being called on a > > constructor you'll run into issues. > > No, because library doesn't know and has no way to know whether process > spawned some threads already or not. That is why gnutls_global_init() has been made thread-safe. It doesn't matter if the process spawned threads or not. Tim From nmav at gnutls.org Sun Nov 29 11:13:21 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 29 Nov 2015 11:13:21 +0100 Subject: [gnutls-devel] marking gnutls 3.4.x as stable Message-ID: <1448792001.10238.3.camel@gnutls.org> Hello, I mark the gnutls 3.4.x releases as the current stable branch. That means that only minor features may enter this branch and new development is diverted to the 3.5.x (master) branch. For an overview of the 3.4.x releases see my blog post: http://nmav.gnutls.org/2015/11/an-overview-of-gnutls-34x.html regards, Nikos From jenny.yung at oracle.com Mon Nov 30 23:47:16 2015 From: jenny.yung at oracle.com (Jenny Yung) Date: Mon, 30 Nov 2015 14:47:16 -0800 Subject: [gnutls-devel] pkcs11_common(NULL) issue in 3.4.6 Message-ID: <565CD1F4.1010808@oracle.com> Hi, This issue is found in 3.4.6. Currently in src/tpmtool.c, pkcs11_common(NULL) is being called when PKCS11 is not enabled. We have p11 disabled in our configure options, so it was unable to build. I have the suggested patch here: --- gnutls-3.4.6/src/tpmtool.c Tue Jul 21 02:42:08 2015 +++ gnutls-3.4.6/src/tpmtool.c Thu Nov 19 13:43:02 2015 @@ -184,7 +184,9 @@ gnutls_datum_t data, sig = {NULL, 0}; int pk; +#ifdef ENABLE_PKCS11 pkcs11_common(NULL); +#endif data.data = (void*)TEST_DATA; data.size = sizeof(TEST_DATA)-1; Thanks, Jenny Yung Oracle Solaris Security