Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Psi and Kopete fail to connect to Openfire. Where to patch?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
miket
Guru
Guru


Joined: 28 Apr 2007
Posts: 483
Location: Gainesville, FL, USA

PostPosted: Fri Jun 22, 2012 5:54 am    Post subject: Psi and Kopete fail to connect to Openfire. Where to patch? Reply with quote

Here's one of those odd uncomfortable issues that leaves me with no good solution.

They upgraded the Jabberd at work to Openfire 3.7.1. It promptly broke my favorite Jabber client on my Gentoo laptop, Psi 0.14. (Funny, an older version of Psi on a Windows XP machine was unaffected). Psi on the laptop would go a couple of minutes before timing out with a popup saying it failed to connect.

I went around on Google and found a bunch of posts dating as far back as 2009 complaining how an upgraded Openfire broke Psi 0.14. The most recent I item I saw was from last month. Yes, this problem has been on the KDE bugzilla for several months now, so the upstream has been notified. What I found in that bug report was a reference to an Arch Linux bug where someone made a two-line patch to qca-ossl. The problem, he said, was in the QCA library, not in Psi or Kopete. (Kopete also uses QCA and is affected.) So, with the happy ability that Gentoo gives to patch the package and yet still stay completely under the control of the package manager, I untarred the qca-ossl-2.0.0_beta3 tarball, applied the Gentoo patch from the qca-ossl-2.0.0-beta3-r2 ebuild, did my quickie edit, made a new diff and put it in my overlay, and re-emerged the package. Psi started working without a hitch.

This is the whole patch from Arch Linux with line numbers that reflect the existing Gentoo patch:
Code:
@@ -5275,7 +5294,7 @@
        bool priv_startClient()
        {
                //serv = false;
-               method = SSLv23_client_method();
+               method = SSLv3_client_method();
                if(!init())
                        return false;
                mode = Connect;
@@ -5285,7 +5304,7 @@
        bool priv_startServer()
        {
                //serv = true;
-               method = SSLv23_server_method();
+               method = SSLv3_server_method();
                if(!init())
                        return false;
                mode = Accept;


Huge patch, isn't it? :)

So now the problem. The bug report has gone to the upstream (listed as delta.affinix.com, but it's kde.org that maintains it), but it just sits. I don't know that it is the correct thing to do. The patch works great in my setup, but I don't know if it is appropriate for everyone. This makes it so that I think I should not file a Gentoo bug over this, yet because other people could benefit from from the fix I don't want to let it lie. What's the best thing to do?
Back to top
View user's profile Send private message
webfishrune
n00b
n00b


Joined: 29 Apr 2007
Posts: 24

PostPosted: Fri Oct 12, 2012 10:59 am    Post subject: Re: Psi and Kopete fail to connect to Openfire. Where to pa Reply with quote

miket wrote:
Here's one of those odd uncomfortable issues that leaves me with no good solution.

They upgraded the Jabberd at work to Openfire 3.7.1. It promptly broke my favorite Jabber client on my Gentoo laptop, Psi 0.14. (Funny, an older version of Psi on a Windows XP machine was unaffected). Psi on the laptop would go a couple of minutes before timing out with a popup saying it failed to connect.


Hi Miket,

All I can say is that I am having a very similar problem; TLS does not work for PSI or for Kopete and it appears to be an issue with QCA.

I will try your patch. However, since upstream seem unresponsive I feel that adding the patch to the ebuild in ~arch would be appropriate.

Regards

rune
Back to top
View user's profile Send private message
miket
Guru
Guru


Joined: 28 Apr 2007
Posts: 483
Location: Gainesville, FL, USA

PostPosted: Sat Oct 13, 2012 5:31 am    Post subject: Reply with quote

Wow, I had forgotten about it! I have lots of things to figure out. As happens often enough, I find a problem, figure out or find a fix, edit the ebuild in an overlay, and go on with what I was doing. I see that the world has advanced since the time I made the post: Psi is up to version 0.15 at the upstream. I might get around to making an ebuild for that.

And even though the last change to qca-ossl in the repository was made only 8 weeks ago (you can see the revision history here), they haven't released a new version in years.

The code in question was introduced in 2005. Back then, people were concerned about maintaining compatiblity across SSL versions. Version 1 was known to be too flawed to be useful, but otherwise things were in flux. Two functions from the OpenSSL package, SSLv23_server_method and SSLv23_client_method, were seen as a nice thing to have. From the man page at the time: "A client will send out SSLv2 client hello messages and will indicate that it also understands SSLv3 and TLSv1. A server will understand SSLv2, SSLv3, and TLSv1 client hello messages. This is the best choice when compatibility is a concern."

Nowadays, if you look for man page for the OpenSSL API, you find no mention of those two functions. With good reason: SSL v2 was also shown to be so bad that they shifted away from the name SSL altogether--now it is Transport Layer Security.

Openfire sees that SSLv2 hello and and says to itself "this client is too old to bother with". At least it is doing that. What happens if you go to a different Jabber server which sees the v2 hello and, instead of asking the client to upgrade to TLS, chooses not insist on a secure algorithm? We are being poorly served by the current state of qca-ossl. If they made the change that I outlined, they'd lose compatiblity for any outliers still stuck on SSLv2, but they'd greatly improve the security for everyone else.



Now to make it so you can apply the patch and test.

I think there may be a better way for me to have set up the patch in my overlay, but I chose to leave the ebuild itself untouched and modify the patch file rather than make a second one. Here are the quickie steps so you can try it out yourself.

First (assuming you haven't tried making your own overlay), you can get things set up for it very easily. If you don't already have an overlay directory, make one and tell your /etc/make.conf about it. I usually use /var/lib/local_overlay; other people do it other ways. This is the line that goes in /etc/make.conf (but be sure to use your own pathname):
Code:
PORTDIR_OVERLAY=/var/lib/local-overlay/

If you've got layman installed, be sure to put this line ABOVE the line that sources layman's make.conf. (If you already had a PORTDIR_OVERLAY= line in /etc/make.conf, you already have a local overlay--use that one!)

Now to make and populate the local ebuild directories. This will take care of that:
Code:
cd [your-overlay-directory]
mkdir -p app-crypt/qca-ossl/files
cd app-crypt/qca-ossl
cp /usr/portage/app-crypt/qca-ossl/qca-ossl-2.0.0_beta3-r2.ebuild .


Grab my altered version of the patch from the following code block and paste it into the file files/qca-ossl-openssl-1.0.0.patch
Code:
diff -r 07e9dbbce2c4 CMakeLists.txt
--- a/CMakeLists.txt    Fri Jun 22 00:33:31 2012 -0400
+++ b/CMakeLists.txt    Fri Jun 22 00:34:55 2012 -0400
@@ -1,5 +1,12 @@
 # QCA OSSL
 
+INCLUDE(CheckFunctionExists)
+SET(CMAKE_REQUIRED_LIBRARIES ${OPENSSL_LIBRARIES})
+CHECK_FUNCTION_EXISTS(EVP_md2 HAVE_OPENSSL_MD2)
+IF (HAVE_OPENSSL_MD2)
+  ADD_DEFINITIONS(-DHAVE_OPENSSL_MD2)
+ENDIF (HAVE_OPENSSL_MD2)
+
 SET(QCA_OSSL_SOURCES qca-ossl.cpp)
 
 MY_AUTOMOC( QCA_OSSL_SOURCES )
diff -r 07e9dbbce2c4 qca-ossl.cpp
--- a/qca-ossl.cpp      Fri Jun 22 00:33:31 2012 -0400
+++ b/qca-ossl.cpp      Fri Jun 22 00:34:55 2012 -0400
@@ -42,6 +42,15 @@
 #define OSSL_097
 #endif
 
+#if defined(OPENSSL_VERSION_NUMBER) && OPENSSL_VERSION_NUMBER >= 0x10000000L
+// OpenSSL 1.0.0 makes a few changes that aren't very C++ friendly...
+// Among other things, CHECKED_PTR_OF returns a void*, but is used in
+// contexts requiring STACK pointers.
+#undef CHECKED_PTR_OF
+#define CHECKED_PTR_OF(type, p) \
+                   ((_STACK*) (1 ? p : (type*)0))
+#endif
+
 using namespace QCA;
 
 namespace opensslQCAPlugin {
@@ -1771,8 +1780,10 @@
                        md = EVP_sha1();
                else if(alg == EMSA3_MD5)
                        md = EVP_md5();
+#ifdef HAVE_OPENSSL_MD2
                else if(alg == EMSA3_MD2)
                        md = EVP_md2();
+#endif
                else if(alg == EMSA3_RIPEMD160)
                        md = EVP_ripemd160();
                else if(alg == EMSA3_Raw)
@@ -1789,8 +1800,10 @@
                        md = EVP_sha1();
                else if(alg == EMSA3_MD5)
                        md = EVP_md5();
+#ifdef HAVE_OPENSSL_MD2
                else if(alg == EMSA3_MD2)
                        md = EVP_md2();
+#endif
                else if(alg == EMSA3_RIPEMD160)
                        md = EVP_ripemd160();
                else if(alg == EMSA3_Raw)
@@ -3385,9 +3398,11 @@
                case NID_md5WithRSAEncryption:
                    p.sigalgo = QCA::EMSA3_MD5;
                    break;
+#ifdef HAVE_OPENSSL_MD2
                case NID_md2WithRSAEncryption:
                    p.sigalgo = QCA::EMSA3_MD2;
                    break;
+#endif
                case NID_ripemd160WithRSA:
                    p.sigalgo = QCA::EMSA3_RIPEMD160;
                    break;
@@ -3871,9 +3886,11 @@
                case NID_md5WithRSAEncryption:
                    p.sigalgo = QCA::EMSA3_MD5;
                    break;
+#ifdef HAVE_OPENSSL_MD2
                case NID_md2WithRSAEncryption:
                    p.sigalgo = QCA::EMSA3_MD2;
                    break;
+#endif
                case NID_ripemd160WithRSA:
                    p.sigalgo = QCA::EMSA3_RIPEMD160;
                    break;
@@ -4061,9 +4078,11 @@
                case NID_md5WithRSAEncryption:
                    p.sigalgo = QCA::EMSA3_MD5;
                    break;
+#ifdef HAVE_OPENSSL_MD2
                case NID_md2WithRSAEncryption:
                    p.sigalgo = QCA::EMSA3_MD2;
                    break;
+#endif
                case NID_ripemd160WithRSA:
                    p.sigalgo = QCA::EMSA3_RIPEMD160;
                    break;
@@ -5275,7 +5294,7 @@
        bool priv_startClient()
        {
                //serv = false;
-               method = SSLv23_client_method();
+               method = SSLv3_client_method();
                if(!init())
                        return false;
                mode = Connect;
@@ -5285,7 +5304,7 @@
        bool priv_startServer()
        {
                //serv = true;
-               method = SSLv23_server_method();
+               method = SSLv3_server_method();
                if(!init())
                        return false;
                mode = Accept;
@@ -6582,7 +6601,9 @@
        list += "sha1";
        list += "sha0";
        list += "ripemd160";
+#ifdef HAVE_OPENSSL_MD2
        list += "md2";
+#endif
        list += "md4";
        list += "md5";
 #ifdef SHA224_DIGEST_LENGTH
@@ -6597,9 +6618,11 @@
 #ifdef SHA512_DIGEST_LENGTH
        list += "sha512";
 #endif
+/*
 #ifdef OBJ_whirlpool
        list += "whirlpool";
 #endif
+*/
        return list;
 }
 
@@ -6757,7 +6780,9 @@
                list += all_hash_types();
                list += all_mac_types();
                list += all_cipher_types();
+#ifdef HAVE_OPENSSL_MD2
                list += "pbkdf1(md2)";
+#endif
                list += "pbkdf1(sha1)";
                list += "pbkdf2(sha1)";
                list += "pkey";
@@ -6788,8 +6813,10 @@
                        return new opensslHashContext( EVP_sha(), this, type);
                else if ( type == "ripemd160" )
                        return new opensslHashContext( EVP_ripemd160(), this, type);
+#ifdef HAVE_OPENSSL_MD2
                else if ( type == "md2" )
                        return new opensslHashContext( EVP_md2(), this, type);
+#endif
                else if ( type == "md4" )
                        return new opensslHashContext( EVP_md4(), this, type);
                else if ( type == "md5" )
@@ -6810,14 +6837,18 @@
                else if ( type == "sha512" )
                        return new opensslHashContext( EVP_sha512(), this, type);
 #endif
+/*
 #ifdef OBJ_whirlpool
                else if ( type == "whirlpool" )
                        return new opensslHashContext( EVP_whirlpool(), this, type);
 #endif
+*/
                else if ( type == "pbkdf1(sha1)" )
                        return new opensslPbkdf1Context( EVP_sha1(), this, type );
+#ifdef HAVE_OPENSSL_MD2
                else if ( type == "pbkdf1(md2)" )
                        return new opensslPbkdf1Context( EVP_md2(), this, type );
+#endif
                else if ( type == "pbkdf2(sha1)" )
                        return new opensslPbkdf2Context( this, type );
                else if ( type == "hmac(md5)" )


This inelegantly mingles my patch with the existing Gentoo patch to the file (those existing patches look a lot like patches that the upstream made to the QCA repository but hasn't released). You should also take a quick look to be sure I'm not introducing any trojans into your system: do a diff between the patch in Portage (at /usr/portage/app-crypt/qca-ossl/files/qca-ossl-openssl-1.0.0.patch) with the file you just copied from me. Apart from 16 lines of noise from the changing timestamps of the diffs, you should see those same lines I quoted in my message from last June.

Now you need to give these files the stamp of approval they need before portage will work with them. Still in the app-crypt/qca-ossl/ directory, run this command:
Code:
ebuild qca-ossl-openssl-1.0.0.patch manifest


Now emerge qca-ossl again and try making connections with Psi and Kopete and let me know how it came out. If it works for you, it'll be time for me to get busy. I'll do it on two fronts: make a proper second patch file for the package and submit my revised ebuild to bugs.gentoo.org, and then make a patch for the SVN version of qca-ossl and submit *that* patch to bugs.kde.org.

I'll be looking for your reply.
Back to top
View user's profile Send private message
webfishrune
n00b
n00b


Joined: 29 Apr 2007
Posts: 24

PostPosted: Sat Oct 13, 2012 9:44 pm    Post subject: Reply with quote

miket wrote:

The code in question was introduced in 2005. Back then, people were concerned about maintaining compatiblity across SSL versions. Version 1 was known to be too flawed to be useful, but otherwise things were in flux. Two functions from the OpenSSL package, SSLv23_server_method and SSLv23_client_method, were seen as a nice thing to have. From the man page at the time: "A client will send out SSLv2 client hello messages and will indicate that it also understands SSLv3 and TLSv1. A server will understand SSLv2, SSLv3, and TLSv1 client hello messages. This is the best choice when compatibility is a concern."


<snip>

Thanks for your detailed reply.

I have actually taken the information in your first post and produced my own patch using the same method you did. Unfortunately, it does not fix my issues.

I run my own jabber server using jabberd2. I cannot connect to this server at all using either STARTTLS or a dedicated SSL port. Well, I say I cannot connect, the Jabber server logs show a connection but nothing happens after that. The client just hangs in the "connecting" state. I see exactly the same issue with both PSI and Kopete. I have just tested with pidgin and I can connect fine.


rune
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum