Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#19175 - [qca] kopete and psi not able to connect to jabber/xmpp (openfire)

Attached to Project: Arch Linux
Opened by lazx (lazx888) - Monday, 19 April 2010, 17:37 GMT
Last edited by Andrea Scarpino (BaSh) - Tuesday, 06 November 2012, 21:58 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Pierre Schmitz (Pierre)
Andrea Scarpino (BaSh)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 8
Private No

Details

Description:

Both Kopete and psi depend on qca - neither clients are able to connect to openfire xmpp server. Connection to gtalk is working. Connecting with pidgin to openfire is working.

Error message:
Unknown signature value: 795

Additional info:
kdenetwork-kopete 4.4.2-2
psi 0.14-3
qca 2.0.2-2
qca-ossl 2.0.0-3
qca-gnupg 2.0.0-1
ca-certificates 20090814-3

Steps to reproduce:
1) If I remember correctly, the problem started to occur upon upgrade of ca-certificates/qca-ossl... But I have downgraded both, and get a complaint in kopete and psi about having not tls support.
2) Connect to openfire with client that uses qca.
This task depends upon

Closed by  Andrea Scarpino (BaSh)
Tuesday, 06 November 2012, 21:58 GMT
Reason for closing:  None
Comment by Pierre Schmitz (Pierre) - Monday, 19 April 2010, 18:05 GMT
I am actually running an openfire server and connect via psi without any problems. It might be a certificate problem.
Comment by Andrea Scarpino (BaSh) - Monday, 19 April 2010, 18:09 GMT
I am using my gmail account with kopete. No issues here.
Comment by Dmytro Bagrii (dimich) - Wednesday, 05 May 2010, 12:05 GMT
Similiar situation:

<quote>
$ psi
qca-gnupg: disabling keyring monitoring due to buggy Qt version
Unknown signature value: 795
Unknown signature value: 795
Unknown signature value: 795
</quote>

Three jabber accuounts work (including talk.google.com), but one (internal corporative, based on ejabberd) doesn't work. It tryes to connect several minutes and then sometimes displays error dialog without any useful message.

$ pacman -Q psi qt qca qca-gnupg qca-ossl
psi 0.14-3
qt 4.6.2-4
qca 2.0.2-2
qca-gnupg 2.0.0-1
qca-ossl 2.0.0-3
Comment by Andrea Scarpino (BaSh) - Wednesday, 09 June 2010, 16:22 GMT
  • Field changed: Summary (QCA broken? - Kopete and psi not able to connect to jabber/xmpp (openfire) → [qca] kopete and psi not able to connect to jabber/xmpp (openfire))
  • Field changed: Status (Assigned → Waiting on Response)
status of this?
Comment by James Pike (jpike) - Sunday, 15 August 2010, 07:39 GMT
Well it doesn't work for me and many others.
Comment by James Pike (jpike) - Sunday, 15 August 2010, 09:35 GMT
Do not close this bug. It is still affecting me and at least 3 other users on IRC. Just because you can't reproduce it, doesn't mean it isn't a bug.

Kopete on gentoo works fine with my work's intranet Openfire server, and Arch's doesn't. I am not some newbie or clueless user who doesn't know what they are doing, leave this bug open so that when I find a solution other people can find it in the same place if you aren't willing to do anything about it.
Comment by lazx (lazx888) - Wednesday, 18 August 2010, 21:02 GMT
Some more information, as this is still a problem for me (have been using pidgin for a few months now).

Here are some observations when connecting to my _openfire_ xmpp server:

Case 1 - Jabber id domain different than server domain (custom server (override default server information)) + SSL

Jabber id: user@gmail.com
Server: mydomain.org port: 5222

Result:
- "Unknown signature value: 795"
- Kopete DOES NOT prompt me to accept self signed certificate.


Case 2 - Jabber id domain equal to server domain + SSL

Jabber id: user@mydomain.org
Server: default settings

Result:
- No complaint about "Unknown signature value: 795"
- Kopete DOES prompt to accept self signed certificate.
- Kopete asks for password, fails to sign on, prompts again to accept self signed certificate, fails to sign on, asks for password, repeat.


Case 3 - NO SSL

Jabber id: user@mydomain.org
Server: default settings

Result:
- "Unknown signature value: 795"
- Kopete DOES prompt to accept self signed certificate... even though ssl has been unchecked (And openfire has "Optional - Clients may connect to the server using secured connections" enabled)
- Kopete asks for password, fails to sign on, prompts again to accept self signed certificate, fails to sign on, asks for password, repeat.




So there is obviously some conflict between certificates (maybe only self signed ones, as connection to Gtalk (jabber/ssl) works fine....? I'll look into getting my certificate signed and report back).

Pidgin and kopete on opensuse are working.

Kopete on arch linux/kde 4.5 (testing) is not working.


Is there any more information that I can try to provide to finally axe this bug...?

Thanks guys.
Comment by Steven Noonan (neunon) - Saturday, 18 September 2010, 06:46 GMT
Hello from afar. I thought I'd share a solution I discovered for this problem while trying to figure out what broke Psi on my Gentoo install.

This bug report led me to the solution: https://support.process-one.net/browse/EJAB-877

See the attached patch for qca-ossl. Reading through EJAB-877, it looked like adding SSL_OP_NO_TICKET to the SSL context would resolve the issue, but for whatever reason, this didn't work for me. I'm not sure why. For the heck of it, I then tried changing the SSL method from SSLv23_server_method() to SSLv3_server_method(), which seems to have fixed the problem. I'm able to connect to SSLv3 servers as well as TLSv1 servers. I don't know what the OpenSSL-internal difference is between SSLv23_server_method() and SSLv3_server_method(), besides the obvious fact that one permits SSLv2, SSLv3, and TLSv1, while the other permits only SSLv3 and TLSv1. Perhaps this has something to do with SSLv2 being thrown out of OpenSSL 1.x? Anyway. See if the above fixes the issue for you folks. It's a starting point, anyway.
Comment by lazx (lazx888) - Sunday, 26 September 2010, 17:22 GMT
Hi Steven, thanks for your efforts into fixing this bug. Your patch did not work for my problem of kopete (kdenetwork-kopete 4.5.1-1) connecting to openfire (openfire 3.6.4-2). Error: Unknown signature value: 795. Which client/protocol are you using?

At least one report of this patch working with some unspecified client/protocol: https://bugs.kde.org/show_bug.cgi?id=221533

Oddly enough, Psi (which also depends on qca/qca-ossl) works fine with patched and unpatched qca-ossl (2.0.0-3).

Comment by Steven Noonan (neunon) - Sunday, 26 September 2010, 19:08 GMT
Hi there. In my case I was originally using Psi with an unpatched qca-ossl. It failed if the openfire server was set to accept TLS connections only, but with my patch applied, it connected fine.

The "unknown signature value" errors aren't fatal, by the way. They're printed whenever the CSR (not applicable), CRL, or certificate has a signature method that qca-ossl isn't aware of. What _really_ matters is that OpenSSL is aware of it.

Looking up 795, it seems that qca-ossl didn't understand what a DSA with SHA384 signature is:
tycho@mjollnir /usr/include/openssl $ grep 795 *
obj_mac.h:#define NID_ecdsa_with_SHA384 795

But whatever, like I said, it's not a fatal error.

You should probably add some debug printouts to find the real critical error. Chances are that SSL_get_error() returns SSL_ERROR_SSL at some point during the Connect, Accept or Handshake stages, and you need to know what the exact error was. Try the attached patch and see what Kopete prints to stderr then.
Comment by Steven Noonan (neunon) - Sunday, 26 September 2010, 22:37 GMT
Slightly more verbose version of the above qca-ossl-debug.patch file. Instead of just printing the reason, print the full error summary.

Let me know what you get out of Kopete with this.
Comment by lazx (lazx888) - Sunday, 26 September 2010, 23:35 GMT
SSL_get_error returned 2. which is SSL_ERROR_WANT_READ

Have played around with the setup of the ssl context with no success. Ideas?
Comment by Steven Noonan (neunon) - Sunday, 26 September 2010, 23:49 GMT
What? SSL_ERROR_WANT_READ is covered by an if condition before the printouts. It's supposed to return TryAgain if that happens. Are you sure you applied the patch correctly?
Comment by lazx (lazx888) - Monday, 27 September 2010, 03:11 GMT
Indeed. Forgot to mention doConnect() was failing at the first condition... so I commented this out and your debugging code then printed out the error. qca-ossl-fix.patch and the second qca-ossl-debug.patch have both been applied.

Do you have any experience with this error? Thanks Steven.
Comment by Steven Noonan (neunon) - Monday, 27 September 2010, 04:24 GMT
Failing at the SSL_ERROR_WANT_READ condition? In what way? That condition _should not_ be commented out. It's _supposed_ to 'return TryAgain;'

Leave both patches applied but don't make any of your own changes (if something breaks, let me know what it is), then watch the stderr output from Kopete/Psi.
Comment by lazx (lazx888) - Monday, 27 September 2010, 06:33 GMT
SSL_ERROR_WANT_READ is the error that keeps doConnect() returning TryAgain. Kopete (+ patched qca-ossl) does not progress any further (ie to doHandshake()).

Both Kopete and Psi return the same output with your patched qca-ossl: "Unknown signature value: 795". Psi connects, kopete does not.

With some small changes (only print statements), maybe some more interesting output:

Kopete output (fails to connect):
Unknown signature value: 795
doConnect: SSL_get_error returned 2.
Unknown signature value: 795
doConnect: SSL_get_error returned 2.
Unknown signature value: 795
doConnect: SSL_get_error returned 2.
Unknown signature value: 795
doConnect: SSL_get_error returned 2.

Psi's output (connects fine):
Unknown signature value: 795
doConnect: SSL_get_error returned 2.
doConnect: SSL_get_error returned 2.
doConnect: SSL_get_error returned 2.
in doHandshake
Comment by Steven Noonan (neunon) - Monday, 27 September 2010, 06:50 GMT
Aha, that _is_ interesting.

May I ask what the address is of the Jabber server you're using? I'd like to see if I can debug it locally.
Comment by Steven Noonan (neunon) - Monday, 27 September 2010, 06:52 GMT
On second thought, the behaviour Kopete exhibits is very strange. Are your Psi and Kopete linked to the same qca-ossl?
Comment by lazx (lazx888) - Monday, 27 September 2010, 18:50 GMT
Both clients are using the same qca-ossl. Will be in contact with you shortly with account details. Thanks.
Comment by Steven Noonan (neunon) - Thursday, 30 September 2010, 22:48 GMT
I think the attached patch for OpenSSL fixes the issue on all clients (I had this problem occur with Gajim too). The issue has been languishing on the OpenSSL bug tracker for several months: http://rt.openssl.org/Ticket/Display.html?id=2240&user=guest&pass=guest
Comment by Jeppe Toustrup (Tenzer) - Wednesday, 13 October 2010, 11:45 GMT
I can confirm that the patch named "qca-ossl-fix.patch" works. I have rebuild qca-ossl with the following PKGBUILD file, and Kopete now works with my OpenFire server: http://pastie.org/1217911
Comment by Steven Noonan (neunon) - Wednesday, 13 October 2010, 14:09 GMT
Jeppe, could you try the t1_lib.c.patch on OpenSSL? I believe it fixes the root issue instead of working around it (qca-ossl-fix.patch is poorly named, as it's a workaround rather than a fix).
Comment by Jeppe Toustrup (Tenzer) - Wednesday, 13 October 2010, 15:25 GMT
I have rebuild the openssl package now with the patch, and it works. I reinstalled qca-ossl from the repository first, and confirmed that I was not able to connect to the Jabber server prior to testing this out.
Comment by Steven Noonan (neunon) - Wednesday, 13 October 2010, 15:32 GMT
Awesome to hear that. I recommend sending a "hey, your patch on issue 2240 worked for me, please put it in mainline" to the guy who made the patch (see the above rt.openssl.org link for the author, etc)
Comment by James Pike (jpike) - Wednesday, 13 October 2010, 18:41 GMT
I rebuilt openssl with the t1_lib.c.patch and still can't connect to openfire with kopete.
Comment by Steven Noonan (neunon) - Wednesday, 13 October 2010, 18:52 GMT
James, can you give the debug output with only the t1_lib.c.patch and qca-ossl-debug.patch (without the qca-ossl-fix.patch)? It'd be ideal to know what behaviour it's exhibiting.

(And I think I need to add a debug printout for what protocol and cipher are being used. We need to pinpoint the differences here in everyone's case.)
Comment by James Pike (jpike) - Wednesday, 20 October 2010, 13:45 GMT
I'll get onto it now.
Comment by James Pike (jpike) - Wednesday, 20 October 2010, 13:57 GMT
Output:

Unknown signature value: 795
Unknown signature value: 795

etc.

I rebuilt openssl with the patch then qca-ossl with the qca-ossl-debug.patch. Can upload the PKGBUILD sources I modified to the AUR if anyone wants them.

I started kopete on the command line like this:

kopete

Did I miss something? I was expecting more output.
Comment by Steven Noonan (neunon) - Wednesday, 20 October 2010, 14:10 GMT
James:

The output there doesn't make sense if the SSL/TLS negotiation failed, and the qca-ossl-debug.patch has been applied. The qca-ossl-debug.patch prints out detailed error messages if something blows up during the negotiation process. Are you sure you applied the patch and ran kopete with that version of qca-ossl?
Comment by James Pike (jpike) - Wednesday, 20 October 2010, 14:20 GMT
Okay just tried it with t1_lib.c.patch, qca-ossl-debug.patch and qca-ossl-fix.patch.

Same behaviour.
Comment by James Pike (jpike) - Wednesday, 20 October 2010, 14:23 GMT
Using correct qca-ossl yes:

% strings /usr/lib/qt/plugins/crypto/libqca-ossl.so | grep "SSL_get_error"

gives:

SSL_get_error
SSL_get_error returned %d.

Comment by James Pike (jpike) - Wednesday, 20 October 2010, 14:36 GMT
openssl PKGBUILD: http://pastie.org/1235526
qca-ossl PKGBUILD: http://pastie.org/1235530
Comment by Steven Noonan (neunon) - Wednesday, 20 October 2010, 15:18 GMT
Interesting.

How is Kopete behaving? Does it say SSL/TLS negotiation failed? I ask because it should have printed out an error if it didn't negotiate properly. It's entirely possible you're hitting a different bug altogether.
Comment by James Pike (jpike) - Wednesday, 20 October 2010, 15:49 GMT
No dialogue from kopete. My account just never connects. Worked in gentoo.. switched to same version of kopete in arch and it has never worked since.

I tried applying gentoo qca-ossl/openssl patches but with no help.
Comment by Steven Noonan (neunon) - Wednesday, 20 October 2010, 17:18 GMT
Hmm, let's figure out if it's a qca-ossl/openssl or kopete issue. Can you try Psi, just for kicks?
Comment by James Pike (jpike) - Thursday, 21 October 2010, 15:47 GMT
Psi works fine.

I still get "Unknown signature value: 795" but it connects anyway.
Comment by Steven Noonan (neunon) - Thursday, 21 October 2010, 16:54 GMT
Yes, the "Unknown signature value" isn't relevant. It just means qca-ossl doesn't recognize the algorithm being used, but what matters is that OpenSSL itself recognizes the algorithm.

If Psi works, it's a Kopete thing. Now we just need to discover why. Is Kopete statically linked to qca-ossl or OpenSSL, perhaps?
Comment by James Pike (jpike) - Thursday, 21 October 2010, 17:42 GMT
When I ldd psi I can see it dynamically links against libqca whereas kopete doesn't.

That would mean the qca-ossl-debug patch would have no effect until recompiling kopete. In addition since kopete uses ssl through qca-ossl it wouldn't pick up the openssl fix.

Then again kopete might dlopen libqca at runtime.. I'm not sure.

I could nm for common symbols but I'm recompiling kopete right now.
Comment by James Pike (jpike) - Thursday, 21 October 2010, 17:50 GMT
Recompiled kopete against qca-ossl-debug + openssl patched.. no difference.
Comment by Steven Noonan (neunon) - Thursday, 21 October 2010, 20:44 GMT
I just tried locally on a fresh Arch install. Both Kopete and Psi work fine for me with the t1_lib.c.patch applied to OpenSSL. I don't know what to tell you.
Comment by lazx (lazx888) - Friday, 26 November 2010, 00:19 GMT
I switched my jabber/xmpp port from 5222 to 5223 and am now able to connect
Comment by Aliaksandr Stelmachonak (ava1ar) - Tuesday, 30 November 2010, 16:03 GMT
People who experiencing problems with GTalk in Kopete - do you have option "Allow plain-text password authentication" checked in Google Talk account settings? If no, check it and verify it helps. It helped for me (Arch Linux x64_86, testing enabled).
Comment by leonid shatalin (leonder) - Friday, 25 February 2011, 19:23 GMT
I just save it here ;)
With this package (instead openssl from repository) psi-plus and kopete works normally
Comment by Mateusz Krasowski (Fall6) - Friday, 11 March 2011, 06:55 GMT
A little summary for those who still cannot get kopete and PSI connecting:

1. t1_lib.c.patch cannot be applied to the newest openssl. As I looked at code it seems to be applited little other way. -> No patching needed.
2. qca-ossl-fix.patch, which in fact looks like a workaround WORKS, but...
* to get PSI working: as long as PSI is dynamically linked to libqca, you just have to install patched version of this package and you're done.
* to get kopete working: after installing patched qca-ossl, you have to recompile kopete (in fact, whole kdenetwork which kopete is part of).

Hope that helps someone.
Comment by Allan McRae (Allan) - Saturday, 28 April 2012, 15:27 GMT
Status?
Comment by Tim (timi0tree) - Sunday, 06 May 2012, 10:09 GMT
Connecting to an openfire jabber server with kopete stopped working after kde update to 4.8.3.
Comment by Allan McRae (Allan) - Saturday, 14 July 2012, 05:49 GMT
So this can be closed?
Comment by Raphael Groner (k0Do) - Tuesday, 28 August 2012, 18:47 GMT
I use psi-plus from AUR and see this message in cli, too.

Loading...