net-libs/neon with gnutls fails correctly work with issuers. Reproducible: Always Steps to Reproduce: 1.svn co https://crossfire.svn.sourceforge.net/svnroot/crossfire 2. 3. Actual Results: segfault Expected Results: repository should be cloned Part of a backtrace: ==1483== Invalid read of size 8 ==1483== at 0x8C938D4: gnutls_x509_crt_get_subject (x509.c:2091) ==1483== by 0x789734E: populate_cert (ne_gnutls.c:470) ==1483== by 0x78983CE: ne__negotiate_ssl (ne_gnutls.c:775) ==1483== by 0x7886A79: send_request.isra.6 (ne_request.c:1650) ==1483== by 0x788729B: ne_begin_request (ne_request.c:1189) ==1483== by 0x788692C: ne_request_dispatch (ne_request.c:1400)
Created attachment 328066 [details] patch that fixes situation This patch fixes situation.
(In reply to comment #1) > Created attachment 328066 [details] > patch that fixes situation > > This patch fixes situation. works for me
(In reply to comment #1) > Created attachment 328066 [details] > patch that fixes situation I've been asked by Alexander to take a look at the patch. While I agree the patch is correct and it works for me too, I don't think it has much to do with the root cause of the issue. The problem is that at the start that crossfire checkout in svn the fragment of neon code in question is executed several times, and while with gnutls-3.1.2 and earlier versions all calls to x509_crt_copy() are successful, with gnutls-3.1.3 every single one fails. It is a bit worrisome that with gnutls-3.1.2 a bunch of neon autotests started to fail with certificate errors, and now there is this problem with gnutls-3.1.3 -- it all worked fine with gnutls-3.1.1. I don't know though whether these are regressions in gnutls or just neon bugs that didn't show up earlier.
It seems to break also for code.google.com subversion (and git-svn). One example URL would be https://esteid.googlecode.com/svn/packages/gentoo/trunk
There was a patch for proper gnutls-3 support on the neon mailinglist. See http://lists.manyfish.co.uk/pipermail/neon/2012-September/001510.html Unfortunately, there haven't been any replies yet.
(In reply to comment #5) This very patch is already included in portage's neon, see bug #421441. The problem is that despite the patch, neon apparently doesn't work too well with gnutls >=3.1.2 (3.1.1, against which I wrote the patch, worked fine, but gnutls is not supposed to break between patchlevel versions...).
*** Bug 441838 has been marked as a duplicate of this bug. ***
*** Bug 443094 has been marked as a duplicate of this bug. ***
This got fixed with recent vesion gnutls-3.1.4.
(In reply to comment #9) > This got fixed with recent vesion gnutls-3.1.4. Can't confirm this. I rebuilt net-libs/gnutls-3.1.4 (latest version in tree as of writing this), neon and subversion and I still get segfaults :(
segfaults with gnutls-3.1.4
Problem persists with gnutls-3.1.5 (I rebuilt neon and subversion after the gnutls-update)
Yes, problem still persist. I've created a bug report on gnutls site [1]. Bartosz, I've tried git bisect and had a problem on all versions of gnutls >= 2.99.4, can you contact me if you have working gnutls-3 libraries. To all, as there is no information from neon upstream (seems dead) I will make next steps: 1). if there will no reaction on bugreport until this weekend (1 dec) and no objections from other devs, I'll add a workaround fix (or userpatch support if there will be an objections), if one a hit by this problem you can use neon[-gnutls] it will work for the most of the repos (and inform in this bug). [1] https://savannah.gnu.org/support/index.php?108189
I've backported changes that fixes situation. It's in tree neon-0.29.6-r2.
