Created attachment 5464 [details]
test postmap configuration file

replace the IP of the server by the one you are testing and the base domain (DC=...) as well

Created attachment 5465 [details]
tcpdump capture on the same computer

Created attachment 5466 [details]
tcpdump capture from another computer

Exactly this problem is a blocker for my passwords work. We really need to get this fixed since otherwise we cannot perform password change tests over LDAPS against Windows Server. I think abartlet is working on it.

Maybe it's easy to bisect this pb ?

I have it on a 8d3fc23157376af5657a09324509abace3c5ee4f installation.
I'm pretty sure I didn't had the problem with c3632e4efc506a401a9d75c4d75b14a1a220caa2 (alpha7).

It leave a number of humm 3160 revision to test :-)

I did the bisect.

git-bisect start
# good: [c3632e4efc506a401a9d75c4d75b14a1a220caa2] Mark as the Samba 4.0 alpha7 release
git-bisect good c3632e4efc506a401a9d75c4d75b14a1a220caa2
# bad: [ca2c645156a288ca35c5120e95bb9a878a889848] Fix build of Samba4 from tarball generated by mkrelease.sh
git-bisect bad ca2c645156a288ca35c5120e95bb9a878a889848
# skip: [6b167ae53b1774950d76a15ba92d9f24e59bc565] Use a switch statement in charset_name()
git-bisect skip 6b167ae53b1774950d76a15ba92d9f24e59bc565
# skip: [8cba97a16459eb1b1dc18c85e542ca571490ec5f] Fix a winbind memleak
git-bisect skip 8cba97a16459eb1b1dc18c85e542ca571490ec5f
# bad: [4c6547e8a1f872e5bc1e132ec4ccc6f634166932] Move 16 bytes from data to r/o text segment
git-bisect bad 4c6547e8a1f872e5bc1e132ec4ccc6f634166932
# good: [266b79e004470ae1859085ca018fd6aff6836059] s3-samr: implement more info levels in _samr_QueryDomainInfo().
git-bisect good 266b79e004470ae1859085ca018fd6aff6836059
# bad: [6eadb8a2855c729e742c72afcc9585adccc7bb12] s3: refactor utility function to handle splitting the directory from the mask
git-bisect bad 6eadb8a2855c729e742c72afcc9585adccc7bb12
# bad: [1a7898e3a8f2c2e2cacd645b97da88054df931ae] s3/getdcname:  Fix 'net' crash.
git-bisect bad 1a7898e3a8f2c2e2cacd645b97da88054df931ae
# bad: [3e1b6487e76232756b854fb28a9d28717ae7d1d3] Fix detection of "enum FAMCodes"
git-bisect bad 3e1b6487e76232756b854fb28a9d28717ae7d1d3
# bad: [6ff09b323e1bb3b82a27f6015ba94ccce36993af] s3:libsmb: return NT_STATUS_CONNECTION_INVALID if the fd is -1
git-bisect bad 6ff09b323e1bb3b82a27f6015ba94ccce36993af
# bad: [54d925a30469f9318717b8e6da7b433efd4efd70] s4-smbtorture: skip SetMemberAttributesOfGroup in RPC-SAMR for s3 as well.
git-bisect bad 54d925a30469f9318717b8e6da7b433efd4efd70
# bad: [418a2eeae8912d14e32b0119232b897e78221037] Don't require external use of internal enum smb_thread_lock_type
git-bisect bad 418a2eeae8912d14e32b0119232b897e78221037
# bad: [705f36b804093f656498f7963768a418672cd422] s3-samr: Fix SetUserInfo level 7 when there has been no name change.
git-bisect bad 705f36b804093f656498f7963768a418672cd422
# bad: [3d6f4a7af7b91d9f9ac9fd0b00af63bb23e371f7] Fix bug #6330 - DFS doesn't work on AIX. Jeremy.
git-bisect bad 3d6f4a7af7b91d9f9ac9fd0b00af63bb23e371f7
# bad: [7d6e4c7e950592112d09f7d98393c41e8097bba8] s3:smbd: fix the fix for mapped IPv4 address handling in release_ip().
git-bisect bad 7d6e4c7e950592112d09f7d98393c41e8097bba8
# good: [66cf7e1835d5d711c91d0541b05eb11b61267ba8] s3-selftest: run RPC-LSA-GETUSER against Samba 3.
git-bisect good 66cf7e1835d5d711c91d0541b05eb11b61267ba8

In fact no ... the script yield a false positive ... 

Reruning a bisect seems that we have the problem since alpha7.

After some bisect it seems that the pb is bb7e6f0f51a91e461c18efd392af3e4fc6174c34 :  Worked around a problem with select/poll/epoll and gnutls

Giving the title of the change and it's content it seems to be very good candidate!

# good: [0118b2301b29af0f22845c7e3ebb5df74ba13aeb] Don't use TMPDIR as variable, it's already used for other purposes. Don't include GIT revision in release version strings.
git-bisect good 0118b2301b29af0f22845c7e3ebb5df74ba13aeb
# bad: [c3632e4efc506a401a9d75c4d75b14a1a220caa2] Mark as the Samba 4.0 alpha7 release
git-bisect bad c3632e4efc506a401a9d75c4d75b14a1a220caa2
# good: [894d05bc41c683a47590cd237194e2b3b7ec0e67] s3-spoolss: restore delete_a_form().
git-bisect good 894d05bc41c683a47590cd237194e2b3b7ec0e67
# good: [ce71a7c9a753b8f2ec45ba35a5c46c78cacf6739] s3-spoolss: use pidl for _spoolss_ResetPrinter.
git-bisect good ce71a7c9a753b8f2ec45ba35a5c46c78cacf6739
# bad: [ca24822234d9dc77dbe3f351d6dbab5558efac39] Fix GDB_PROVISION mode
git-bisect bad ca24822234d9dc77dbe3f351d6dbab5558efac39
# bad: [2ca48d3740c40be2142ca7e7ad88aabdaa822c06] Fix printf type warning. Jeremy.
git-bisect bad 2ca48d3740c40be2142ca7e7ad88aabdaa822c06
# bad: [3089e004fe9d8f4cfee919a95f84b4611837ec87] s3: re-run make samba3-idl.
git-bisect bad 3089e004fe9d8f4cfee919a95f84b4611837ec87
# bad: [7f6618a3deb77fc5c4724c598ecacdbf87c5e9c4] tevent: rename tevent_req_set_timeout() => tevent_req_set_endtime()
git-bisect bad 7f6618a3deb77fc5c4724c598ecacdbf87c5e9c4
# good: [74940606f715bfc9d99ded2fb1d1da02d037609a] docs: extend the idmap_rid manpage
git-bisect good 74940606f715bfc9d99ded2fb1d1da02d037609a
# good: [b1ff79dbb246e717fc4a62c7a615ca7ce9ccc302] fixed some of the TLS problems
git-bisect good b1ff79dbb246e717fc4a62c7a615ca7ce9ccc302
# bad: [48ba64010046bece3b54009131f88c851ec82047] Merge branch 'master' of ssh://git.samba.org/data/git/samba into master-devel
git-bisect bad 48ba64010046bece3b54009131f88c851ec82047
# bad: [bb7e6f0f51a91e461c18efd392af3e4fc6174c34] Worked around a problem with select/poll/epoll and gnutls
git-bisect bad bb7e6f0f51a91e461c18efd392af3e4fc6174c34

Here's my start for a tstream implementation for tls.

http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-tstream

http://gitweb.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=046d35497b6614f42

Metze, 
Do you want me to try this branch and see if we have the same pb ? 

No, it's just a start... (I think it compiles but nothing more:-)

I think we should first try to fix the existing code (shouldn't be too
hard to trigger the Alert response)

Okay, ekacnet. My problem has been fixed by http://gitweb.samba.org/samba.git/?p=samba.git;a=commitdiff;h=a2286bad67a772d290fead9832b7ca52877c40b2 and yours?

Well - as you said ekacnet - the problem persists and was unrelated to mine.

tridge, could you look into this?

I  remember that andrew told me that metze has started something related to socket that should solvethe pb in the long term (tstream)

Seems like the tstream/tls implementation is now available:

http://gitweb.samba.org/?p=samba.git;a=commit;h=ca360fba107f7948c52a5f7595ab0f99c8142e07

The problem with TLS/SSL connection however still
exists.

Thanks! We really appreciate people who help to keep bug reports up-to-date.

(In reply to comment #17)
> Seems like the tstream/tls implementation is now available:
> 
> http://gitweb.samba.org/?p=samba.git;a=commit;h=ca360fba107f7948c52a5f7595ab0f99c8142e07
> 
> The problem with TLS/SSL connection however still
> exists.
> 

There's still this commit missing

http://gitweb.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=eafc4677cef045be

I haven't pushed it yet, because it needs a lot of testing.

It would be nice if you could test that one on top of master.
I'd really like to see if starttls works, I only tested SASL and LDAPS.
It would be great if someone could upload captures of postfix once using
StartTLS and once using LDAPS, as well as plain LDAP. 

metze

On your setup ldaps worked?

Just to make sure I got it right: master is
git://git.samba.org/samba.git, right?

After applying patch http://gitweb.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=eafc4677cef045be
to master - SSL handshake seems to be completely broken on my test machine.

Simple test(s) to reproduce:

# openssl s_client -connect atom:636
CONNECTED(00000003)
depth=0 /O=Samba Administration/OU=Samba - temporary autogenerated certificate/CN=ATOM.linex.r00t.la
verify error:num=18:self signed certificate
verify return:1
depth=0 /O=Samba Administration/OU=Samba - temporary autogenerated certificate/CN=ATOM.linex.r00t.la
verify return:1
9716:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:

# ldapsearch -x -H ldaps://atom
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Metze,

With a recent tree: 2:35AM  on 2/10/2010 with your patch I'm ok with my postfix pb (I run it in 3 minutes loop without pb).

for openssl I have this:

 openssl s_client -connect ares.home.matws.net:636
CONNECTED(00000003)
depth=0 /O=Samba Administration/OU=Samba - temporary autogenerated certificate/CN=ARES.home.matws.net
verify error:num=18:self signed certificate
verify return:1
depth=0 /O=Samba Administration/OU=Samba - temporary autogenerated certificate/CN=ARES.home.matws.net
verify return:1
---
Certificate chain
 0 s:/O=Samba Administration/OU=Samba - temporary autogenerated certificate/CN=ARES.home.matws.net
   i:/O=Samba Administration/OU=Samba - temporary autogenerated certificate/CN=ARES.home.matws.net
---
Server certificate
-----BEGIN CERTIFICATE-----
MIICnDCCAgegAwIBAgIEfSKmTDALBgkqhkiG9w0BAQUwczEdMBsGA1UEChMUU2Ft
YmEgQWRtaW5pc3RyYXRpb24xNDAyBgNVBAsTK1NhbWJhIC0gdGVtcG9yYXJ5IGF1
dG9nZW5lcmF0ZWQgY2VydGlmaWNhdGUxHDAaBgNVBAMTE0FSRVMuaG9tZS5tYXR3
cy5uZXQwHhcNMTAxMDAxMTgwMzQxWhcNMTIwODMxMTgwMzQxWjBzMR0wGwYDVQQK
ExRTYW1iYSBBZG1pbmlzdHJhdGlvbjE0MDIGA1UECxMrU2FtYmEgLSB0ZW1wb3Jh
cnkgYXV0b2dlbmVyYXRlZCBjZXJ0aWZpY2F0ZTEcMBoGA1UEAxMTQVJFUy5ob21l
Lm1hdHdzLm5ldDCBnDALBgkqhkiG9w0BAQEDgYwAMIGIAoGA6qsW65SEi2avIOJ1
w9ENWu+GxWhYNXUq2oJOh5nuo+ZaXvtRqs7zRZdHdVwhWQGEqa3y4W4RbEvcC9mE
xNhVE5+xqBivwlOG33sqoWn2dBnB7ccy+xmr+zbVURyr1W5Yntfx+phpCjctfYFr
OefzE7mTg+hqKuyULlUq7UxOIn8CAwEAAaNEMEIwDAYDVR0TAQH/BAIwADATBgNV
HSUEDDAKBggrBgEFBQcDATAdBgNVHQ4EFgQUKWFPPrL8BEoBj774Dz/EQLLO6wsw
CwYJKoZIhvcNAQEFA4GBAEhWAJXROsKmgIld7ku60R4Dou3smiGQPYmsARJBf9Je
qxDHg1JJyFMXazIla8PJz1tTpPo9DYrBgtbTR6ajtRs5IPG8s78zSOoa5AFEVeMJ
fEI2jKIGgi/4l2ObzSBBWPjqnqryS4dECj9wbe+fqKgI6T0Jvsu8/RyxUUNqZewi
-----END CERTIFICATE-----
subject=/O=Samba Administration/OU=Samba - temporary autogenerated certificate/CN=ARES.home.matws.net
issuer=/O=Samba Administration/OU=Samba - temporary autogenerated certificate/CN=ARES.home.matws.net
---
Acceptable client certificate CA names
/O=Samba Administration/OU=Samba - temporary autogenerated certificate/CN=ARES.home.matws.net
---
SSL handshake has read 1465 bytes and written 331 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 97DB807BF97CE777BE966C54287049E09BC79D3A57B439AC7D19E798EADA07B2
    Session-ID-ctx: 
    Master-Key: 8F2C821FA155F694F987239E8D6367C77EDC5CEA1C26747B565C2E5D10C07E35FDBFE35A61366A5CAC40597848F3726E
    Key-Arg   : None
    Start Time: 1285972490
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---


but as I told you already I have time to time a double free error.

Hi Matthieu,

what OS/gnutls version are you testing on?

On my SLES 11 box, with gnutls 2.4.1, "openssl s_client ..." still fails with patch applied.

Samba reports this:

TLS ../lib/tls/tls_tstream.c:1213 - GnuTLS internal error.
ldapsrv_terminate_connection: ldapsrv_accept_tls_loop: tstream_tls_accept_recv() - 5:Input/output error - disconnecting
Terminating connection - 'ldapsrv_accept_tls_loop: tstream_tls_accept_recv() - 5:Input/output error'
single_terminate: reason[ldapsrv_accept_tls_loop: tstream_tls_accept_recv() - 5:Input/output error]

Marcel,

I'm on ubuntu 10.04 
* libgnutls26 2.8.5-2
* libgnutls-dev 2.8.5-2

Just downloaded an compiled gnutls-2.10.2, set LD_LIBRARY_PATH, started samba 4, and finally: TLS/SSL works fine - no more errors.

So I tried some more versions to find out in what gnutls version things got fixed 

Tested versions:
2.4.1 -> broken
2.4.2 -> broken
2.6.0 -> broken
2.8.0 -> broken
2.8.1 -> broken
2.8.2 -> OK
2.8.3 -> OK
2.8.4 -> OK
2.8.5 -> OK
2.8.6 -> OK
2.10.0 -> broken
2.10.1 -> broken
2.10.2 -> OK

Searching gnutls git, I guess those are the two
patches fixing the problem. Maybe this helps to
find a work-around to make samba4 work with all
versions of gnutls:

Change 2.8.1 -> 2.8.2:
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=28fb34099edaf62e5472cc6e5e2749fed369ea01

Change 2.10.1 -> 2.10.2:
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=0d07d8432d57805a8354ebd6c1e7829f3ab159cb

Thanks I got that reproduced with gnutls-2.4.1.

But I don't know how we can work arround it...

Ok, I found a workaround...

The problem is that gnutls_handshake() triggers tstream_tls_push_function()
more than one time and it doesn't expect to get EAGAIN.
Now we'll wait for the next event cycle to trigger the write
and let the tstream_tls_push_function fill the buffer.

Can this be marked as "FIXED"?

Let's give us the test with different version, as I observed different behavior in the handshake with the previous patch.

Seems Matthieu was correct - problem is solved for
some gnutls versions, but not all:
 
Tested versions:
2.4.1 -> OK
2.4.2 -> OK
2.6.0 -> OK
2.8.0 -> broken
2.8.1 -> broken
2.8.2 -> OK
2.8.3 -> OK
2.8.4 -> OK
2.8.5 -> OK
2.8.6 -> OK
2.10.0 -> broken
2.10.1 -> broken
2.10.2 -> OK

Well, but it improved quiet a bit (comment #24). But is for example release 2.8.1 a minor release of 2.8? So we could argue that in order to get this working simply upgrade to the latest minor release.
Or other question: are the mentioned broken releases still in use by important Linux/UNIX distributions?

(In reply to comment #29)
> Tested versions:
> 2.4.1 -> OK
> 2.4.2 -> OK
> 2.6.0 -> OK
> 2.8.0 -> broken
> 2.8.1 -> broken
> 2.8.2 -> OK
> 2.8.3 -> OK
> 2.8.4 -> OK
> 2.8.5 -> OK
> 2.8.6 -> OK
> 2.10.0 -> broken
> 2.10.1 -> broken
> 2.10.2 -> OK
> 

Created attachment 6077 [details]
Patch proposal

Hi marcel,

can you try this patch and see if it fix the broken version, it fix the pb on ubuntu 10.10 with gnutls 2.9.10.

The idea of this patch is to increase the size of buffer of tstream so that the different step of the SSL handcheck are pushed in the same packet as the different implementation of gnutls time to time fails to have  a correct behavior when we chunk each step in a different package

If increasing the buffer 'fixes' it, why shouldn't we just create a dynamic buffer here and hold a potentially infinite buffer?  Then we would not need to bother GnuTLS with the EAGAIN error that it clearly doesn't handle so well.

Hi, the proposed patch fixes the problems with early 2.10 releases, not for 2.8.0/1 (and 2.2.4)

(number at end of line is exit status of ldapsearch)

using gnutls version: 2.2.4 -> 254
using gnutls version: 2.2.5 -> 0
using gnutls version: 2.4.0 -> 0
using gnutls version: 2.4.1 -> 0
using gnutls version: 2.4.2 -> 0
using gnutls version: 2.4.3 -> 0
using gnutls version: 2.6.0 -> 0
using gnutls version: 2.6.1 -> 0
using gnutls version: 2.6.2 -> 0
using gnutls version: 2.6.3 -> 0
using gnutls version: 2.6.4 -> 0
using gnutls version: 2.6.5 -> 0
using gnutls version: 2.6.6 -> 0
using gnutls version: 2.8.0 -> 255
using gnutls version: 2.8.1 -> 255
using gnutls version: 2.8.2 -> 0
using gnutls version: 2.8.3 -> 0
using gnutls version: 2.8.4 -> 0
using gnutls version: 2.8.5 -> 0
using gnutls version: 2.8.6 -> 0
using gnutls version: 2.10.0 -> 0 (without patch: 255)
using gnutls version: 2.10.1 -> 0 (without patch: 255)
using gnutls version: 2.10.2 -> 0
using gnutls version: 2.10.3 -> 0

Marcel, but do you agree to integrate this patch?

(In reply to comment #34)
> Hi, the proposed patch fixes the problems with early 2.10 releases, not for
> 2.8.0/1 (and 2.2.4)
> 
> (number at end of line is exit status of ldapsearch)
> 
> using gnutls version: 2.2.4 -> 254
> using gnutls version: 2.2.5 -> 0
> using gnutls version: 2.4.0 -> 0
> using gnutls version: 2.4.1 -> 0
> using gnutls version: 2.4.2 -> 0
> using gnutls version: 2.4.3 -> 0
> using gnutls version: 2.6.0 -> 0
> using gnutls version: 2.6.1 -> 0
> using gnutls version: 2.6.2 -> 0
> using gnutls version: 2.6.3 -> 0
> using gnutls version: 2.6.4 -> 0
> using gnutls version: 2.6.5 -> 0
> using gnutls version: 2.6.6 -> 0
> using gnutls version: 2.8.0 -> 255
> using gnutls version: 2.8.1 -> 255
> using gnutls version: 2.8.2 -> 0
> using gnutls version: 2.8.3 -> 0
> using gnutls version: 2.8.4 -> 0
> using gnutls version: 2.8.5 -> 0
> using gnutls version: 2.8.6 -> 0
> using gnutls version: 2.10.0 -> 0 (without patch: 255)
> using gnutls version: 2.10.1 -> 0 (without patch: 255)
> using gnutls version: 2.10.2 -> 0
> using gnutls version: 2.10.3 -> 0
> 

I've created a patch with a dynamic buffer, see
http://gitweb.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=a051005679b0e64c

metze

The dynamic buffer patch works for me on ubuntu 10.10 

Results of a test run including the "dynamic buffer size" patch:

using gnutls version: 2.2.4 -> 254
using gnutls version: 2.2.5 -> 0
using gnutls version: 2.4.0 -> 0
using gnutls version: 2.4.1 -> 0
using gnutls version: 2.4.2 -> 0
using gnutls version: 2.4.3 -> 0
using gnutls version: 2.6.0 -> 0
using gnutls version: 2.6.1 -> 0
using gnutls version: 2.6.2 -> 0
using gnutls version: 2.6.3 -> 0
using gnutls version: 2.6.4 -> 0
using gnutls version: 2.6.5 -> 0
using gnutls version: 2.6.6 -> 0
using gnutls version: 2.8.0 -> 255
using gnutls version: 2.8.1 -> 255
using gnutls version: 2.8.2 -> 0
using gnutls version: 2.8.3 -> 0
using gnutls version: 2.8.4 -> 0
using gnutls version: 2.8.5 -> 0
using gnutls version: 2.8.6 -> 0
using gnutls version: 2.10.0 -> 0
using gnutls version: 2.10.1 -> 0
using gnutls version: 2.10.2 -> 0
using gnutls version: 2.10.3 -> 0

Ok, the dynamic buffer fix is on its way to master.

Can someone debug the still broken versions?

The following discussion is about the problem
existing in gnutls-2.8.0/1:

http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3668

Applying the mentioned gnutls patch to 2.8.0 or 2.8.1
makes these versions work. Maybe this helps to debug the
samba tsl problems:

http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commit;h=90bff7862c48c9a628e797b62ee9de6f34e0601f

Can you test this
http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-tls-tstream
fixes more versions

Just ran the test with latest samba git and your
two patches applied:

  s4:tls_tstream: also use a dynamic buffer for the pul...
  s4:tls_tstream: fix partial reads, so that the gnutls... 

Results are the same as above (s. Comment #38)

Btw. the two mentioned patches have made it into "master".

Marcel, would you still like to keep this open?
Do you strictly depend on the broken versions of GnuTLS? Otherwise we could simply suggest our users to update to the latest minor release (e.g. 2.2.5, 2.8.6).

Hi Matthias,

I think it's not necessary to keep this open - it
really looks like a gnutls bug, so there's no real
way for samba to fix it.

However it'd be nice if "(waf) configure" or samba
itself could check the gnutls version. Or (even better)
tries to establish a ssl/tsl connection at startup
and give a hint about broken gnutls versions if this
connection fails. Just an idea :-)

PS: Keep up the great work!

Marcel,

at the moment we've the following checks:
> Checking for gnutls >= 1.4.0                                            : yes 
> Checking for library gnutls                                             : yes 
> Checking for gnutls_global_init                                         : ok  
> Checking for header gnutls/x509.h                                       : yes 
> Checking for variable gnutls_x509_crt_set_version                       : ok  
> Checking for variable gnutls_x509_crt_set_subject_key_id                : ok  
> Checking for gnutls_datum                                               : ok  
> Checking for gnutls_datum_t                                             : ok  

And these are derived by the WAF file "source4/lib/tls/wscript". Probably there could be made some enhancements (exclude the broken versions).
The other idea to prove the fitness at runtime by trying to execute a short test program is also possible in WAF - but the code has to be written by someone. Would you like to provide us something? Basically it should be a short C snippet - "lib/replace/wscript" CHECK_CODE paragraphs show the functionality (return 0 is success, != 0 failure).

Marcel, is it possible for you to write such a patch or do I have to find someone else?

Hi Matthias,

during the tests on this bug I had a few looks into the gnutls code, and I don't think that I'll find the time to truly understand it enough to write a clean check in the foreseeable future, sorry.

Marcel

The patch should soon land in "master".

Finally got this long bug report fixed.