Fix the NSS init after fork bug, and clean up lies in unix.c

This might look like a simple diff, but those 'lies' made this not very
straightforward.

The NSS bug itself is simple: NSS detects a fork happened after the
initialization, and refuses to work because shared CSPRNG state is bad.
The bug has been around for long time. I've been aware of it for 5
months, which says something about this mess. Trac link:

http://bugs.bitlbee.org/bitlbee/ticket/785

This wasn't a big deal because the main users of NSS (redhat) already
applied a different patch in their packages that workarounded the issue
somewhat accidentally. And this is the ticket for the 'lies' in unix.c:

http://bugs.bitlbee.org/bitlbee/ticket/1159

Basically a conflict with libotr that doesn't happen anymore. Read that
ticket for details on why ignoring those comments is acceptable.

Anyway: yay!

1 files changed, 0 insertions, 9 deletions

diff --git a/unix.c b/unix.c
index 1ea24af9..329b33c3 100644
--- a/unix.c
+++ b/unix.c
@@ -31,7 +31,6 @@
 #include "protocols/nogaim.h"
 #include "help.h"
 #include "ipc.h"
-#include "lib/ssl_client.h"
 #include "md5.h"
 #include "misc.h"
 #include <signal.h>
@@ -81,17 +80,9 @@ int main( int argc, char *argv[] )
 	nogaim_init();
 #endif
 	
- 	/* Ugly Note: libotr and gnutls both use libgcrypt. libgcrypt
- 	   has a process-global config state whose initialization happpens
- 	   twice if libotr and gnutls are used together. libotr installs custom
- 	   memory management functions for libgcrypt while our gnutls module
- 	   uses the defaults. Therefore we initialize OTR after SSL. *sigh* */
- 	ssl_init();
 #ifdef OTR_BI
  	otr_init();
 #endif
-	/* And in case OTR is loaded as a plugin, it'll also get loaded after
-	   this point. */
 	
 	srand( time( NULL ) ^ getpid() );