gnutls servers can't link against gnutls servers {certfp regression} about charybdis

[mrflea]

gnutls support is entirely broken and not worth the time investment to fix because openssl works fine. Use openssl instead.

[anarcat]

The problem with OpenSSL is that there are licensing issues in linking GPL code against OpenSSL. See:

http://en.wikipedia.org/wiki/OpenSSL#Licensing

Notice how it is possible to add a licensing exception to the Charybdis code to workaround that problem.

Because of the licensing issue, the Debian package currently links against GnuTLS and not OpenSSL.

[alyx]

@mrflea Maybe we should just /remove/ the gnutls code (Since it doesn't work and whatnot, instead of leaving it there for people to think it does work)?

[anarcat]

Well, if that code is removed and the license is not updated, the package would have to be removed from Debian as it would technically infringe on the GPL license. Deluge, for example, has the following excerpt on top of its LICENSE file:

Deluge is licensed under the GNU General Public License version 3 with the
addition of the following special exception:

In addition, as a special exception, the copyright holders give
permission to link the code of portions of this program with the OpenSSL
library.
You must obey the GNU General Public License in all respects for all of
the code used other than OpenSSL. If you modify file(s) with this
exception, you may extend this exception to your version of the file(s),
but you are not obligated to do so. If you do not wish to do so, delete
this exception statement from your version. If you delete this exception
statement from all source files in the program, then also delete it here.

See the full license here.

[micah]

Thanks for reporting this issue, I was wanting the same thing!

Please don't rip out the gnutls code instead of fixing it! A lot of work went into that and it would be really nice if it worked with gnutls instead of openssl!

[mrflea]

@anarcat: I don't believe we can legally re-license most of Charybdis. At a quick glance, the OpenSSL code's copyright seems to belong to ratbox. (see libratbox/src/openssl.c)

@micah: A few months back I put a whole lot of time into trying to fix GnuTLS support for Charybdis, but I didn't have the required expertise to get it to work. Everyone else on the Charybdis project doesn't seem to want to do it either. I wouldn't hold your breath.

I'll take another stab at it, but it'll likely be fruitless.

[kaniini]

frankly, i think openssl is broken in other ways. gnutls has other problems...

regarding ratbox, relicensing there is no problem, it's the 2.8 derived code and the stuff dianora and adrian imported from squid way back when hybrid-7 was still being developed that is the problem.

i think the real solution moving forward is to allow the openssl backend to be built against libNSS. if someone wants to experiment with the gnutls code, that is fine, but it is presently ripped out of trunk for other reasons anyway. aaron (ratbox) has worked on it recently, so resyncing it from ratbox might be a good approach if you want to hack on it there.

irregardless, i think supporting NSS is the best win because really i don't trust either openssl or gnutls after having worked with both's sources.

[kaniini]

@anarcat regarding openssl, it wouldn't have to be removed. debian handles ircd-hybrid by allowing you to optionally rebuild it locally with openssl support, while keeping it off on the official builds.

but, as previously mentioned i believe NSS to be a better solution anyway. NSS is FIPS-certified, which neither OpenSSL or GNUTLS are anyway.

[anarcat]

The Debian package already allows us to build against OpenSSL fairly easily. The annoying thing is that our builds are custom, and therefore the community can't use our backports. Plus it means the official builds are basically unsupported and buggy, as things stand right now.

I wish we could have a standard build that we could share with the community. I don't care much whether it's OpenSSL (with a license exception), GNUtls or libNSS, I don't know enough about those tools to make an informed decision - although I share your mistrust of OpenSSL.

(For those, like me, who had no clue what FIPS was, here's the wikipedia docs. Basically, it's a US government standard for non-military cryptographic applications.)

[kaniini]

Doing some testing, I have found that:

ratbox openssl -> ratbox gnutls is OK
ratbox gnutls -> ratbox gnutls is OK
ratbox gnutls -> ratbox openssl is OK
charybdis openssl -> ratbox gnutls is OK
charybdis gnutls -> ratbox openssl is OK
charybdis gnutls -> charybdis gnutls is NOT OK

looking at what is different between between ratbox and charybdis here, the only thing that stands out at me is the certfp code. when i stub it out, charybdis gnutls links to other gnutls servers fine.

[anarcat]

What's the situation here? As things stand I can't package charybdis 3.4 within Debian because there's no license exception right now.

It's really too bad that gnutls support was ripped out of Charybdis, especially since this particular regression seem to have been fixed in 3.4 in b1a08d5.

I have opened a separate issue about the license exception, and I guess I'll just close this bug now that gnutls is out.

[kaniini]

@anarcat if you can verify that b1a08d5 fixes the regression, I will revert the commit removing it. I do not have time this week to set up a test lab.

[anarcat]

trying.

[anarcat]

Still an issue with the patch. On the initiating side I get:

18:25:23 [::1] !marcos.orangeseeds.org *** Notice -- ssld error for angela: Read error: Input/output error

on the "receiving" end I get:

18:25:23 [::1] !hades.arpa *** Notice -- ssld helper died - attempting to restart

this on Debian wheezy, so with gnutls 2.12.20.

[anarcat]

Here's the backtrace of the dying ssld helper:

Program received signal SIGSEGV, Segmentation fault.
0xf76c2fc1 in ?? () from /usr/lib/libratbox.so
(gdb) bt
#0  0xf76c2fc1 in ?? () from /usr/lib/libratbox.so
#1  0xf76c08ff in rb_checktimeouts () from /usr/lib/libratbox.so
#2  0xf76c46aa in rb_run_event () from /usr/lib/libratbox.so
#3  0xf76c82c7 in ?? () from /usr/lib/libratbox.so
#4  0xf76c86fc in ?? () from /usr/lib/libratbox.so
#5  0xf76c210f in rb_select () from /usr/lib/libratbox.so
#6  0xf76c4f74 in rb_lib_loop () from /usr/lib/libratbox.so
#7  0x080497c1 in main ()

[anarcat]

Here are debugging symbols for you too:

rb_ssl_timeout (F=F@entry=0xf734ed34, notused=0x0) at gnutls.c:81
81              int ret;
(gdb) bt
#0  rb_ssl_timeout (F=F@entry=0xf734ed34, notused=0x0) at gnutls.c:81
#1  0xf76a38ff in rb_checktimeouts (notused=0x0) at commio.c:328
#2  0xf76a76aa in rb_run_event (ev=ev@entry=0x862f448) at event.c:191
#3  0xf76ab2c7 in rb_read_timerfd (data=0x862f448, F=0xf734ed7c) at epoll.c:450
#4  rb_read_timerfd (F=0xf734ed7c, data=0x862f448) at epoll.c:428
#5  0xf76ab6fc in rb_select_epoll (delay=-1) at epoll.c:199
#6  0xf76a510f in rb_select (timeout=timeout@entry=4294967295) at commio.c:2083
#7  0xf76a7f74 in rb_lib_loop (delay=delay@entry=0) at ratbox_lib.c:228
#8  0x080497c1 in main (argc=1, argv=0xffadbfe4) at ssld.c:1211

Note: it doesn't happen on the first attempt, i need to try to connect twice.

[anarcat]

It also crashes only one way, for some reason: on the other way, ssld doesn't crash, but i still get the I/O error. I guess I must have something different in both environments... In any case, this patch really just doesn't fix it.

[anarcat]

Finally, note that connecting to the daemon using:

gnutls-cli marcos.anarcat.ath.cx -p 6697

... works fine.

[anarcat]

I noticed there was this patch in the ircd-ratbox debian patch tracker about gnutls support, but it doesn't fix the linking issue. I wasn't able to test ratbox at all because I couldn't get ssl working, but I assume they have the same bug.

[anarcat]

Wow. So here's more information, after running tcpdump on that port, I noticed something strange... neither side needs to actually start a TLS connexion, and instead traffic is transmitted in plain text! Take this for example. This is a trace from gnutls-cli 192.168.0.112 -p 6697, which correctly negociates a tls connexion:

anarcat@marcos:charybdis[debian-stable]$ sudo tcpdump -Aa -n port 6697
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:33:18.402373 IP 192.168.0.3.32892 > 192.168.0.112.6697: Flags [S], seq 550476616, win 14600, options [mss 1460,sackOK,TS val 498832358 ecr 0,nop,wscale 10], length 0
E..<..@[email protected].|.) ..H......9............
...........

12:33:18.402538 IP 192.168.0.112.6697 > 192.168.0.3.32892: Flags [S.], seq 939136882, ack 550476617, win 14480, options [mss 1460,sackOK,TS val 580704 ecr 498832358,nop,wscale 10], length 0
E..<..@[email protected].....).|7..r ..I..8.Yd.........
...`.......

12:33:18.402555 IP 192.168.0.3.32892 > 192.168.0.112.6697: Flags [.], ack 1, win 15, options [nop,nop,TS val 498832358 ecr 580704], length 0
E..4..@[email protected].|.) ..I7..s...........
.......`
12:33:18.403778 IP 192.168.0.3.32892 > 192.168.0.112.6697: Flags [P.], seq 1:144, ack 1, win 15, options [nop,nop,TS val 498832358 ecr 580704], length 143
E.....@[email protected].|.) ..I7..s.....y.....
.......`...........Q.\.ov...I>.....q.RE....>[email protected]./.<.A.5.=...
.92.168.0.112......#...
..........
12:33:18.404090 IP 192.168.0.112.6697 > 192.168.0.3.32892: Flags [.], ack 144, win 16, options [nop,nop,TS val 580705 ecr 498832358], length 0
E..4..@[email protected].....).|7..s ........#.....
...a....
12:33:18.436600 IP 192.168.0.112.6697 > 192.168.0.3.32892: Flags [P.], seq 1:958, ack 144, win 16, options [nop,nop,TS val 580713 ecr 498832358], length 957
E.....@[email protected].....).|7..s ..............
...i........Q...M..Q.\.e.}K.....u......
.........m..]Y.#.`=X{..F....F...........U....t.r.d.1.H.%Vp...H%.,.G...+$........|9&f...E..oE.....L......&Uk?....N.k.^..gg.....v.....Dm!C.............h....}.:zM.[.;Z..W.=K..f..}!.Kt]z...X.DxX0.....\Xp|.p..7.....z.!C... $u,.  7Y.....g....6...,.<3;..9..<4..B...2.%}......
....c..o...BI|s.....k.6E.-.[.!..lK.Ox.....,"q..#.P.^k....hZ....~.....K.....eP$.'..s.r...@...+....~9.W...&K.g.7 .J..d...7!....).....66.Ar.?.m.U)..
...........................15u.....
12:33:18.436621 IP 192.168.0.3.32892 > 192.168.0.112.6697: Flags [.], ack 958, win 17, options [nop,nop,TS val 498832366 ecr 580713], length 0
E..4..@[email protected].|.) ...7..0...........
.......i
12:33:18.443507 IP 192.168.0.3.32892 > 192.168.0.112.6697: Flags [P.], seq 144:295, ack 958, win 17, options [nop,nop,TS val 498832368 ecr 580713], length 151
E.....@[email protected].|.) ...7..0...........
.......i.......................ZS...zMO#.|.k.v.uQ_=wJ........"..tnT..N
n..W?5.C.N...W.u^...O....       ......m}t.....=.z.p4.i..s...Eq....|.]..Kc .[.fS....R^~. DL.g\.
12:33:18.484203 IP 192.168.0.112.6697 > 192.168.0.3.32892: Flags [.], ack 295, win 17, options [nop,nop,TS val 580725 ecr 498832368], length 0
E..4..@[email protected].....).|7..0 ..o...........
...u....
12:33:18.484266 IP 192.168.0.3.32892 > 192.168.0.112.6697: Flags [P.], seq 295:466, ack 958, win 17, options [nop,nop,TS val 498832378 ecr 580725], length 171
E.....@[email protected].|.) ..o7..0...........
A\N%.l..DI.....I?d....n...7gv>...*d.).7w..).5..`}_;.o%h......g|
....s..]..A.......8.\.p.....AN:..........*......~..4S.....&A...o.LPu"...n
12:33:18.484805 IP 192.168.0.112.6697 > 192.168.0.3.32892: Flags [.], ack 466, win 18, options [nop,nop,TS val 580725 ecr 498832378], length 0
E..4..@[email protected].....).|7..0 ..............
...u....
12:33:18.486851 IP 192.168.0.112.6697 > 192.168.0.3.32892: Flags [P.], seq 958:964, ack 466, win 18, options [nop,nop,TS val 580725 ecr 498832378], length 6
E..:..@[email protected].....).|7..0 ..............
...u..........
12:33:18.525921 IP 192.168.0.3.32892 > 192.168.0.112.6697: Flags [.], ack 964, win 17, options [nop,nop,TS val 498832389 ecr 580725], length 0
E..4..@[email protected].|.) ...7..6...........
.......u
12:33:18.526276 IP 192.168.0.112.6697 > 192.168.0.3.32892: Flags [P.], seq 964:1342, ack 466, win 18, options [nop,nop,TS val 580735 ecr 498832389], length 378
E.....@[email protected].....).|7..6 ..............
..d..N.$** J(u9WT...Y.6T..aT...m.f...V....d.3....]z.[...p...8d.....a......0.-..H...`..o.$.b>]4...>8J$O.. J..vZ.0z.ly.......#z.[f. .
12:33:18.526370 IP 192.168.0.3.32892 > 192.168.0.112.6697: Flags [.], ack 1342, win 18, options [nop,nop,TS val 498832389 ecr 580735], length 0
E..4..@[email protected].|.) ...7..............
........
12:33:18.527770 IP 192.168.0.3.32892 > 192.168.0.112.6697: Flags [R.], seq 466, ack 1342, win 18, options [nop,nop,TS val 498832389 ecr 580735], length 0
E..4..@[email protected].|.) ...7..............
........

no clear text! Here's a similar connexion, but this time initiated by the charybdis daemon:

anarcat@marcos:charybdis[debian-stable]$ sudo tcpdump -Aa -n port 6697
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:34:29.355378 IP 192.168.0.3.32916 > 192.168.0.112.6697: Flags [S], seq 1026095292, win 14600, options [mss 1460,sackOK,TS val 498850096 ecr 0,nop,wscale 0], length 0
E..<!.@[email protected]...)=(........9............
...0........
12:34:29.355600 IP 192.168.0.112.6697 > 192.168.0.3.32916: Flags [S.], seq 2237658855, ack 1026095293, win 14480, options [mss 1460,sackOK,TS val 598442 ecr 498850096,nop,wscale 10], length 0
E..<..@[email protected].....)..._..=(....8.(..........
.       !....0...

12:34:29.355621 IP 192.168.0.3.32916 > 192.168.0.112.6697: Flags [.], ack 1, win 14600, options [nop,nop,TS val 498850096 ecr 598442], length 0
E..4!.@[email protected]...)=(..._....9........
...0.   !.
12:34:29.356124 IP 192.168.0.3.32916 > 192.168.0.112.6697: Flags [P.], seq 1:183, ack 1, win 14600, options [nop,nop,TS val 498850096 ecr 598442], length 182
E...!.@[email protected]...)=(..._....9........
...0.   !......PASS password TS 6 :43X
CAPAB :QS EX CHW IE KLN KNOCK TB UNKLN CLUSTER ENCAP SERVICES RSFNC SAVE EUID EOPMOD BAN MLOCK
SERVER marcos.orangeseeds.org 1 :charybdis test server

12:34:29.356220 IP 192.168.0.112.6697 > 192.168.0.3.32916: Flags [.], ack 183, win 16, options [nop,nop,TS val 598442 ecr 498850096], length 0
E..4.B@[email protected].....)..._..=(.s...........
.       !....0
12:34:29.356807 IP 192.168.0.112.6697 > 192.168.0.3.32916: Flags [P.], seq 1:148, ack 183, win 16, options [nop,nop,TS val 598442 ecr 498850096], length 147
E....C@.@..)...p.....)..._..=(.s...........
.       !....0.....:hades.arpa NOTICE * :*** Looking up your hostname...
:hades.arpa NOTICE * :*** Checking Ident
:hades.arpa NOTICE * :*** No Ident response

12:34:29.356820 IP 192.168.0.3.32916 > 192.168.0.112.6697: Flags [.], ack 148, win 14600, options [nop,nop,TS val 498850096 ecr 598442], length 0
E..4!.@[email protected]...)=(.s._.{..9........
...0.   !.
12:34:29.357424 IP 192.168.0.112.6697 > 192.168.0.3.32916: Flags [P.], seq 148:211, ack 183, win 16, options [nop,nop,TS val 598442 ecr 498850096], length 63
E..s.D@.@..|...p.....)..._.{=(.s...........
.       !....0....::hades.arpa NOTICE * :*** Couldn't look up your hostname

12:34:29.357437 IP 192.168.0.3.32916 > 192.168.0.112.6697: Flags [.], ack 211, win 14600, options [nop,nop,TS val 498850096 ecr 598442], length 0
E..4!.@[email protected]...)=(.s._....9........
...0.   !.
12:34:31.572017 IP 192.168.0.3.57344 > 216.46.7.99.6697: Flags [P.], seq 3308296258:3308296295, ack 3955622927, win 42, options [nop,nop,TS val 498850650 ecr 1724123289], length 37
E..YC.@[email protected]...).0.B.......*.......
...Zf....... T.7|..w..#A.W.."mx$....=......D.
12:34:31.650725 IP 216.46.7.99.6697 > 192.168.0.3.57344: Flags [P.], seq 1:75, ack 37, win 1622, options [nop,nop,TS val 1724138557 ecr 498850650], length 74
[email protected].....).......0.g...V8......
f.D=...Z.... R.....|.L*K...Mx.....vX..\opQZ...... ..6.N..m...8...7..(CR.G..H../..p
12:34:31.650758 IP 192.168.0.3.57344 > 216.46.7.99.6697: Flags [.], ack 75, win 42, options [nop,nop,TS val 498850670 ecr 1724138557], length 0
E..4C.@[email protected]...).0.g...Y...*.c.....
...nf.D=
12:34:44.358109 IP 192.168.0.112.6697 > 192.168.0.3.32916: Flags [F.], seq 211, ack 183, win 16, options [nop,nop,TS val 602192 ecr 498850096], length 0
E..4.E@[email protected].....)..._..=(.s...../.....
.       0P...0
12:34:44.358274 IP 192.168.0.3.32916 > 192.168.0.112.6697: Flags [F.], seq 183, ack 212, win 14600, options [nop,nop,TS val 498853847 ecr 602192], length 0
E..4!.@[email protected]...)=(.s._....9........
.....   0P
12:34:44.358442 IP 192.168.0.112.6697 > 192.168.0.3.32916: Flags [.], ack 184, win 16, options [nop,nop,TS val 602193 ecr 498853847], length 0
E..4.F@[email protected].....)..._..=(.t....p......
.       0Q....

We can see pretty clearly here that the connection initiated by charybdis doesn't even attempt to setup TLS.

I believe this is the problem we're having here, and would explain why the problem happens only when linking gnutls against gnutls: if a "proper" OpenSSL server jumps in the fray, he will initiate TLS and everything works. Otherwise the ssld crashes (yes, segfaults) because it can't handle clear text (which is a bug, but not the main problem here).

[anarcat]

Also, I found there was another patch to the gnutls code we overlooked: 3d7890b - that patch seems to fix the crash I documented earlier here, so that's good. But the two servers seem to end up in a deadlock where both servers wait for the other to start the handshake... In fact, I have come to the understanding that the bug is on the client side. I have added this patch here to try to make things clearer:

diff --git a/libratbox/src/gnutls.c b/libratbox/src/gnutls.c
index 7d1a879..6c8837e 100644
--- a/libratbox/src/gnutls.c
+++ b/libratbox/src/gnutls.c
@@ -81,22 +81,21 @@ do_ssl_handshake(rb_fde_t *F, PF * callback)
    int ret;
    int flags;

-   ret = gnutls_handshake(SSL_P(F));
+   do {
+       ret = gnutls_handshake(SSL_P(F));
+   }
+   while (ret < 0 && gnutls_error_is_fatal (ret) == 0);
+
    if(ret < 0)
    {
-       if((ret == GNUTLS_E_INTERRUPTED && rb_ignore_errno(errno)) || ret == GNUTLS_E_AGAIN)
-       {
-           if(gnutls_record_get_direction(SSL_P(F)) == 0)
-               flags = RB_SELECT_READ;
-           else
-               flags = RB_SELECT_WRITE;
-           rb_setselect(F, flags, callback, data);
-           return 0;
-       }
+       rb_lib_log("do_ssl_handshake: unable to perform SSL handshake: %s", gnutls_strerror (ret));
+
        F->ssl_errno = ret;
        return -1;
    }
-   return 1;       /* handshake is finished..go about life */
+   else {
+       return 1;       /* handshake is finished..go about life */
+   }
 }

 static void

this patch does two things: it uses the 3.0 style do {} while loop and it treats errors as such and just bails with a proper error instead of trying to patch things up mysteriously.

This yields the following strace, on the server side:

[...]
recvfrom(9, 0x7fde40, 5, 0, 0, 0)       = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(9, 0x7fde40, 5, 0, 0, 0)       = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(9, 0x7fde40, 5, 0, 0, 0)       = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(9, 0x7fde40, 5, 0, 0, 0)       = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(9, 0x7fde40, 5, 0, 0, 0)       = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(9, 0x7fde40, 5, 0, 0, 0)       = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(9, 0x7fde40, 5, 0, 0, 0)       = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(9, 0x7fde40, 5, 0, 0, 0)       = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(9, 0x7fde40, 5, 0, 0, 0)       = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(9, 0x7fde40, 5, 0, 0, 0)       = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(9, 0x7fde40, 5, 0, 0, 0)       = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(9, 0x7fde40, 5, 0, 0, 0)       = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(9, "", 5, 0, NULL, NULL)       = 0
epoll_ctl(4, EPOLL_CTL_DEL, 11, {0, {u32=2616842936, u64=139941241281208}}) = 0
close(11)                               = 0
close(9)                                = 0
epoll_ctl(4, EPOLL_CTL_ADD, 10, {EPOLLIN|EPOLLET, {u32=2616843072, u64=139941241281344}}) = 0
sendmsg(45, {msg_name(0)=NULL, msg_iov(1)=[{"D;\0\0\0Read error: Input/output error\0", 36}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 36
epoll_wait(4, {{EPOLLIN, {u32=2616843480, u64=139941241281752}}, {EPOLLIN, {u32=2616843344, u64=139941241281616}}, {EPOLLIN|EPOLLHUP, {u32=2616843072, u64=139941241281344}}}, 1024, 4294967295) = 3
read(7, "\2\0\0\0\0\0\0\0", 8)          = 8
read(8, "\2\0\0\0\0\0\0\0", 8)          = 8
recvfrom(10, ":marcos.orangeseeds.org NOTICE * :*** Looking up your hostname...\r\n:marcos.orangeseeds.org NOTICE * :*** Checking Ident\r\n:marcos.orangeseeds.org NOTICE * :*** No Ident response\r\n:marcos.orangeseeds.org NOTICE * :*** Couldn't look up your hostname\r\nERROR :Closing Link: 127.0.0.1 (Read error: Input/output error)\r\n", 16384, 0, NULL, NULL) = 313
recvfrom(10, "", 16384, 0, NULL, NULL)  = 0
epoll_ctl(4, EPOLL_CTL_DEL, 10, {0, {u32=2616843072, u64=139941241281344}}) = 0
close(10)                               = 0

Notice two things:

1. the server is trying to get data from the client, but there's nothing there recvfrom(9, 0x7fde40, 5, 0, 0, 0) = -1 EAGAIN
2. once it bails, some data is actually available on the socket, but in clear text! recvfrom(10, ":marcos.orangeseeds.org NOTICE.... but note that this is server data, not from the client, which doesn't seem to ever send anything

[anarcat]

This patch doesn't actually work - first, the configure script needs to be recompiled, but then when it is, it actually fails to check:

checking for GnuTLS... ./configure: line 14315: syntax error near unexpected token `GNUTLS,'
./configure: line 14315: `       PKG_CHECK_MODULES(GNUTLS, gnutls,'

This is because the pkg.m4 include was removed from aclocal in 3fe17b2. I am not quite sure how to fix this.

So basically, I think aclocal needs to be reran in the tree for this to work, and make sure that pkg-config and libtool are installed when this is performed.

[Heartmender]

So basically, I think aclocal needs to be reran in the tree for this to work

Then do so.

[anarcat]

done so.

unfortunately, the idea here was:

@anarcat if you can verify that b1a08d5 fixes the regression, I will revert the commit removing it. I do not have time this week to set up a test lab.

... and I don't think that we can link gnutls servers just yet. :(

oh and for the record, this is followup up on the Debian side in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705369

[anarcat]

A brave soul suggested a patch to fix gnutls support in the Debian BTS, can anyone review it here?

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705369#39

I'll probably end up shipping this in the Debian package to resolve the GnuTLS issues eventually.

[kaniini]

•   if(rb_get_ssl_certfp(F, (uint8_t *)&buf[5]))
  

humm

[anarcat]

Could you be a little more specific?

[anarcat]

Is there any concrete feedback on this patch?

[kaniini]

Please try git master, I did something else instead. It should have the same effect.

[kaniini]

Is there any concrete feedback on the patch in git master? I would like to close this bug if someone could confirm everything is right with the world.

[micah]

In preparation to test this, we've created a development machine and can try it there sometime in the near future.

[kaniini]

okay, please let us know as the main blocker for charybdis-3.5 is gnutls.

[micah]

Hi,

I'm sorry I failed at this - I said months ago that we'd test it, and then never got around to it.

I've set up some time this next wednesday with anarcat to have a look, give the new code a try and provide you with some meaningful feedback. So stay tuned!

[anarcat]

we're working on this now. so far i can report that connecting with gnutls-cli works.

[anarcat]

our test procedure:

• install charybdis using a modified debian package (branch debian-experimental on git://git.debian.org/git/collab-maint/charybdis.git - only patch remaining is #26 at this point, and it's configured with

--enable-epoll --disable-openssl --prefix=/usr --with-confdir=/etc/charybdis \
                --with-program-prefix=charybdis- \
                --libdir=/usr/lib/charybdis \
                --libexecdir=/usr/lib \
                --with-rundir=/var/run \
                --localstatedir=/var/lib \
                --with-logdir=/var/log/charybdis \
                --with-moduledir=/usr/lib/charybdis/modules \
                --with-helpdir=/usr/share/doc/charybdis/help \
        --with-shared-sqlite \
                --enable-ipv6

• setup SSL certs and dh_params and configure them in ircd.conf
• start charybdis with sudo -u charybdis charybdis-ircd -foreground (for some reason, background just crashes silently)
• test local connexion: gnutls-cli --tofu localhost -p 6697 and openssl s_client -connect localhost:6697, check the above if it fails
• do the above on two servers
• from one server, test remote connexion to the other: gnutls-cli --tofu foo.example.com -p 6697
• from that server, setup a connect block and try to connect

[anarcat]

and the tests are successful!

we haven't tried linking against openssl however.

[kaniini]

The certfp regression is resolved any other gnutls issues will be handled on ticket #71.