Opened 3 years ago

Closed 3 years ago

Last modified 16 months ago

#15879 closed defect (fixed)

wrong "iq" detected during login

Reported by: arisia Owned by: deryni
Milestone: 2.10.10 Component: XMPP
Version: 2.10.8 Keywords: facebook connect iq
Cc: Stil, xnyhps, darkrain, darkrain42, aphirst, EionRobb, foutrelis, waschk, markdoliner, awildcolin, chaoscommander

Description (last modified by Robby)

After upgrading to 2.10.8 (from 2.10.7), the following problem began occurring. No changes have been made to account settings.

When attempting to connect to Facebook Chat, the connection "times out" - error returned by Pidgin is:

tracy.martin.16940@chat.facebook.com/Pidgin disconnected
Server closed the connection

This occurred the very first time connection was attempted after upgrade.

Applicable excerpt from the log file:

(15:02:05) jabber: Sending (ssl) (tracy.martin.16940@chat.facebook.com/Pdigin): <iq type='set' id='purple21d45b17'><bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'><resource>Pdigin</resource></bind></iq>
(15:02:05) jabber: Recv (ssl)(1): <
(15:02:05) jabber: Recv (ssl)(167): iq from='chat.facebook.com' id='purple21d45b17' type='result'><bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'><jid>-541966685@chat.facebook.com/Pdigin</jid></bind></iq>
(15:02:05) jabber: Got a result iq with id purple21d45b17 from chat.facebook.com instead of expected tracy.martin.16940@chat.facebook.com!
(15:02:05) jabber: Unhandled IQ with id purple21d45b17

As nearly as I can tell from reading the log, the XMPP/Jabber plugin is failing to recognize that the iq that was set is being correctly returned by Facebook.

I do not know if this is an error in the plugin itself, or in the data stream being returned by Facebook.

But no login is possible because the iq isn't being correctly recognized as set, so XMPP never recognizes that a login has occurred.

Downgrading to 2.10.7 as a temporary fix.

Attachments (5)

ichat_connect.zip (1.7 KB) - added by vwal 3 years ago.
Pidgin connect log when connecting to iChat Jabber server.
xmpp-ignore-iq-from.c (4.0 KB) - added by EionRobb 3 years ago.
A hacky plugin that gets facebook and jabber.org xmpp working for me
ichat_connect_debug_working.zip (7.5 KB) - added by vwal 3 years ago.
Connect log to iChat with Pidgin 2.10.7 (working)
debug-pidgin-2_10_7.log (140.9 KB) - added by mynamesthedoctor 3 years ago.
(working)
debug-pidgin-2_10_8.log (354.8 KB) - added by mynamesthedoctor 3 years ago.
(not working)

Download all attachments as: .zip

Change History (49)

comment:1 Changed 3 years ago by Stil

Confirming the bug, I can't use my Facebook account due to same problem

comment:2 Changed 3 years ago by Thomas7C0

Same problem with jabber.org and gmx.de!

Last edited 3 years ago by Thomas7C0 (previous) (diff)

comment:3 Changed 3 years ago by datallah

  • Cc xnyhps darkrain darkrain42 added

It looks like this is a real bug in Pidgin,and not just a facebook server bug. In [93d4bff19574], a security fix was made which changed the behavior so that all stanzas responses' "from" attribute should match the "to" attribute the stanza was sent to.

However, the implementation is not correct - we don't cover case 2 in http://xmpp.org/rfcs/rfc6120.html#stanzas-attributes-from-c2s:

2. When the server generates a stanza on its own behalf for delivery to the client from the server itself, the stanza MUST include a 'from' attribute whose value is the bare JID (i.e., <domainpart>) of the server as agreed upon during stream negotiation (e.g., based on the 'to' attribute of the initial stream header). 
Last edited 3 years ago by datallah (previous) (diff)

comment:4 Changed 3 years ago by Robby

  • Description modified (diff)

comment:5 Changed 3 years ago by datallah

Actually, I take my previous comment back... it looks like this is a bug in the faceboook (and apparently the jabber.org and gmx.de) servers.

The situation is actually case 3 in http://xmpp.org/rfcs/rfc6120.html#stanzas-attributes-from-c2s. The server should be sending these stanzas from the user's bare jid, not from its own bare jid.

comment:6 Changed 3 years ago by deryni

The other relevant bit of spec is http://xmpp.org/rfcs/rfc6120.html#rules-noto-IQ which is what makes this case 3 from datallah's link. These stanzas are "on behalf of the [user's] account" and not "on its own behalf".

comment:7 Changed 3 years ago by deryni

Relevant snippet from jabber.org log:

(20:04:44) jabber: Sending (ssl) (user@jabber.org/resource): <iq type='set' id='purplec5ae5254'><session xmlns='urn:ietf:params:xml:ns:xmpp-session'/></iq>
(20:04:44) jabber: Recv (ssl)(57): <iq from='jabber.org' type='result' id='purplec5ae5254'/>
(20:04:44) jabber: Got a result iq with id purplec5ae5254 from jabber.org instead of expected user@jabber.org!
(20:04:44) jabber: Unhandled IQ with id purplec5ae5254

comment:8 Changed 3 years ago by datallah

  • Summary changed from XMPP/Jabber (Facebook): Wrong "iq" detected during login to wrong "iq" detected during login

comment:9 Changed 3 years ago by datallah

Ticket #15880 has been marked as a duplicate of this ticket.

comment:10 Changed 3 years ago by aphirst

Confirming this again with jabber.org .

Has anyone with detailed knowledge and understanding of this bug gotten in contact with the relevant server administrators? Presumably they need to *know* that their implementations are technically incorrect in order to fix it.

comment:11 Changed 3 years ago by deryni

I've spoken to people connected to the operation of the service. I have a support address I need to send an email to about the issue with the jabber.org software. I've been told that they should respond fairly quickly once I do. When that translates into a deployment on jabber.org I'm uncertain (though hopefully shortly thereafter). I'll update this ticket when I know more.

comment:12 Changed 3 years ago by deryni

The discussion has evolved slightly.

facebook is still incorrect in its response to the bind stanza.

But the decision at this point is that M-Link is following the letter of the spec (in regard to the result from address of the, deprecated, session stanza result).

pidgin, and many other clients, are (following the same letter of the spec standard) technically incorrect in that they send the session stanza to the server without correct addressing (to=server.domain.tld) but the server is responding anyway.

Given that session stanzas are not a part of the current XMPP RFCs this letter of the spec interpretation is being taken as truth.

A plugin was written yesterday which modified the inbound stanzas on-the-fly to allow pidgin to work correctly. I'm going to see if changing that to drop the outgoing session stanza allows pidgin to connect to M-Link correctly (as that would be much simpler). The changes in the plugin for inbound stanzas from facebook are still going to be necessary though.

comment:13 follow-up: Changed 3 years ago by vwal

I'm experiencing this same problem in a corporate environment where the server is iChat (it's a Mac shop). While the problem may according to the RFCs technically lie with the servers, considering the large number of various Jabber installations, not circumventing the issue makes Pidgin unusable in many environments. Like deryni mentions, a plugin may be a good solution since it's external to the core (and hence the core would be in full RFC compliance). I'm looking forward to being able to test it.

comment:14 in reply to: ↑ 13 ; follow-up: Changed 3 years ago by deryni

The issue that triggered the change was a security issue. Not doing what pidgin is now doing has security implications. It is unfortunate that more clients are apparently not checking this in these cases such that servers could get this wrong.

Replying to vwal:

I'm experiencing this same problem in a corporate environment where the server is iChat (it's a Mac shop).

Could you get the debug log output from this problem with iChat? It would help to know if the cases already covered will cover it or whether it has a different manifestation of this issue.

Changed 3 years ago by vwal

Pidgin connect log when connecting to iChat Jabber server.

comment:15 in reply to: ↑ 14 ; follow-up: Changed 3 years ago by vwal

Replying to deryni:

Could you get the debug log output from this problem with iChat? It would help to know if the cases already covered will cover it or whether it has a different manifestation of this issue.

Sure. The sanitized log is attached (ichat_connect.zip).

comment:16 in reply to: ↑ 15 ; follow-up: Changed 3 years ago by deryni

Replying to vwal:

Sure. The sanitized log is attached (ichat_connect.zip).

So this is yet another version of the problem. How exciting.

Would it be possible for you to reinstall 2.10.7 and get the debug log output from a successful connection?

This attempt stops at the first error of this sort but given where that happens I expect that there will be more so it would probably be a good idea to try to cover all of them the first time instead of needing a few rounds back and forth.

comment:17 in reply to: ↑ 16 Changed 3 years ago by vwal

Replying to deryni:

Would it be possible for you to reinstall 2.10.7 and get the debug log output from a successful connection?

Sure.. except I don't have the 2.10.7 installer with me at the office (have a copy on an offline backup at home). If the 2.10.7 installer is available for download somewhere, I can get the output right away (tried to look around on pidgin.im site and in the repo, but couldn't locate the previous installer..).

Changed 3 years ago by EionRobb

A hacky plugin that gets facebook and jabber.org xmpp working for me

Changed 3 years ago by vwal

Connect log to iChat with Pidgin 2.10.7 (working)

comment:18 Changed 3 years ago by vwal

Added an attachment: a connect log to iChat XMPP server with Pidgin 2.10.7, where the connection is formed properly.

comment:19 Changed 3 years ago by xnyhps

I've emailed the jdev and security mailing lists at jabber.org. See http://mail.jabber.org/pipermail/jdev/2014-January/089824.html.

Seeing the observed behavior from these broken servers, I think it would be a valid workaround for libpurple to consider iqs from:

  • The bare domain JID
  • The full JID of Pidgin

to be legal when expecting an iq reply with either the user's bare JID or no 'to'. As far as I can tell, that should have no security implications and would fix the problems we've seen so far.

comment:20 follow-up: Changed 3 years ago by datallah

Ticket #15886 has been marked as a duplicate of this ticket.

comment:21 in reply to: ↑ 20 Changed 3 years ago by mynamesthedoctor

In release 2.10.8 of Pidgin, (no 3rd party plug-ins) XMMP chat is also broken for Star Trek Online, Champions Online, and Neverwinter chat channels (these MMO games are run by Cryptic Studios / Perfect World Entertainment).

See: ​http://sto-forum.perfectworld.com/showthread.php?t=159864 to see what I'm talking about. It's not possible to sign into the game XMMP service, as well as the related chat channels connected to the game with Pidgin 2.10.8 at all. Yet the same thing works fine in Pidgin 2.10.7. Changes in 2.10.8 seem to have caused the problem. This problem only exists in 2.10.8 but not in previous releases of Pidgin.

I attached debug logs for this from 2.10.7 (working) as well as 2.10.8 (not working)

Last edited 3 years ago by mynamesthedoctor (previous) (diff)

Changed 3 years ago by mynamesthedoctor

(working)

Changed 3 years ago by mynamesthedoctor

(not working)

comment:22 Changed 3 years ago by Robby

Ticket #15889 has been marked as a duplicate of this ticket.

comment:23 Changed 3 years ago by EionRobb

Ticket #15890 has been marked as a duplicate of this ticket.

comment:24 Changed 3 years ago by deryni

pidgin seems to process further stanzas from the server in that Cryptic Studios output. I'm a little confused about that and about what exactly is causing it to give up. I assume that it probably is the iq error that this ticket is about but the behaviour here is just a bit different (maybe that's just timing I don't know or the fact that their server seems to send us roster sets earlier than I would have expected).

This instance is the broken server case (incorrect from address on the <bind> stanza) which is the problem facebook has. I don't see a ping result in the 2.10.7 log from that server but seeing one would be helpful (as facebook gets those wrong also and I wonder if Cryptic Studio's server does also).

Can someone with an account on that site/their server kindly report to them that their server is broken and ask them to please fix it?

comment:25 Changed 3 years ago by vwal

Wonder if the Cryptic Studios server works with other common XMPP clients? Apparently it did work with Piding 2.10.7. If majority of the clients work with a server that is non-compliance with the RFCs, then the problem could be considered 'generally accepted', and choosing not to support it drives users elsewhere. Maybe a "compatibility" plugin could address this type issues (Cryptic Studios, and the general issue addressed by this ticket)?

Of course, optimally the broken servers would be brought into compliance, but the servers tend to have more clout than the clients.

comment:26 Changed 3 years ago by deryni

The hacky plugin attached to this ticket does exactly that sort of workaround. The comment (and email) by xnyhps indicates a workaround that leaves the security change intact but attempts to be maximally compatible.

It is a shame that, pidgin included, so few clients were checking this stuff correctly in the past and that servers got away with being broken for so long but fixing them is always better than working around them. Especially working around breakage as extensive as that which facebook exhibits.

That being said if xnyhps's suggestion is considered reasonably and secure it is likely that it will be implemented to cover these cases.

comment:27 Changed 3 years ago by vwal

Ignite Realtime's Openfire seems to be working ok, as does, of course, Google Talk, so it is just a handful of servers that pose the problem. Unfortunately Apple (iChat) and Facebook are on the bad list, so they're quite significant players, and as such probably don't move terribly fast even if they acknowledge the issue and agree to fix it.

comment:28 Changed 3 years ago by deryni

ejabberd appears to be fine as does, I'm assuming, prosody. I don't know about tigase or the jabberd:s (but I'd like to be hopeful).

Unfortunately some of the players least likely to update at all (let alone in a short timeframe) are the ones that are most broken.

comment:29 Changed 3 years ago by mynamesthedoctor

Thank you. I have notified Cryptic Studios / Perfect World Entertainment that their XMMP server is broken and in non-compliance and pointed them at this ticket. See this post and this post on their forums.

Update: I also contacted their Community Manager, Brandon Feltzer via Twitter and he replied with this. I opened incident number 140130-002092 via their support site and reported it there as well and requested it be forwarded to the person or persons responsible for their XMMP server.

Last edited 3 years ago by mynamesthedoctor (previous) (diff)

comment:30 follow-up: Changed 3 years ago by MarkDoliner

  • Cc markdoliner added
  • Milestone set to 2.10.9
  • Resolution set to fixed
  • Status changed from new to closed

I believe I fixed this in b8e2a5fbffd3.

I basically did what xnyhps suggested in comment 19 (though I reached that conclusion on my own without having read this ticket, so that's good that we basically came to the same conclusion).

I'll give people some time to test the fix and we'll hopefully release Pidgin 2.10.9 within the next 4 days.

comment:31 in reply to: ↑ 30 Changed 3 years ago by waschk

Replying to MarkDoliner: I can confirm that I can connect to the jabber.org server with Mark's fix applied to pidgin 2.10.8.

comment:32 Changed 3 years ago by datallah

Ticket #15908 has been marked as a duplicate of this ticket.

comment:33 Changed 3 years ago by mynamesthedoctor

I confirm this is fixed (in 2.10.9) and now allows sign-in to Cryptic Studios / Perfect World Entertainment games again and the XMMP chat rooms work again with Pidgin 2.10.9

comment:34 Changed 3 years ago by vwal

Pidgin 2.10.9 is also confirmed to fix the login problem with Apple iChat server.

comment:35 Changed 3 years ago by xnyhps

ThurahT in #pidgin showed a log with a case that is not properly handled right now:

A vCard query to yourself (initiated by retrieving info on yourself, so with an explicit 'to') is replied by a reply with no 'from'. This is legal, but libpurple doesn't allow it currently.

This patch should fix that:

diff -r df5ea49543fd libpurple/protocols/jabber/iq.c
--- a/libpurple/protocols/jabber/iq.c	Mon Feb 10 17:27:36 2014 +0100
+++ b/libpurple/protocols/jabber/iq.c	Mon Feb 10 18:14:15 2014 +0100
@@ -290,10 +290,12 @@
  * be a valid match if any of the following is true:
  * - Request 'to' matches reply 'from' (including the case where
  *   neither are set).
- * - Request 'to' was empty and reply 'from' is server JID.
+ * - Request 'to' was my bare JID and reply 'from' is empty.
  * - Request 'to' was empty and reply 'from' is my JID. The spec says
  *   we should only allow bare JID, but we also allow full JID for
  *   compatibility with some servers.
+ * - Request 'to' was empty and reply 'from' is server JID. Not
+ *   allowed by any spec, but for compatibility with some servers.
  *
  * These rules should allow valid IQ replies while preventing spoofed
  * ones.
@@ -311,6 +313,11 @@
 		return TRUE;
 	}

+	if (!from && purple_strequal(to->node, js->user->node)
+			&& purple_strequal(to->domain, js->user->domain)) {
+		return TRUE;
+	}
+
 	if (!to && purple_strequal(from->domain, js->user->domain)) {
 		/* Request 'to' is empty and reply 'from' domain matches our domain */

I made some minor changes to the documentation too, to document this case and emphasize that replies to your own bare JID shouldn't come from the server itself.

comment:36 Changed 3 years ago by Robby

Has xnyhps’ patch been considered?

comment:37 Changed 2 years ago by MarkDoliner

Patch looks good to me. I committed it. I changed the comment slightly... The new check also allows 'to' to be a full JID (not just a bare JID). That seemed fine to me.

comment:38 Changed 2 years ago by Mark Doliner <mark@…>

  • Milestone changed from 2.10.9 to 2.10.10

(In [c6926e608dc4]):
Allow incoming IQ stanzas with an empty 'from' if they're in response to an outgoing stanza to our bare or full JID. Patch from Thijs Alkemade from https://developer.pidgin.im/ticket/15879

Fixes #15879

comment:39 follow-up: Changed 17 months ago by awildcolin

I started encountering this issue late yesterday night/early this morning:

(09:50:13) dnssrv: querying SRV record for chat.facebook.com: _xmpp-client._tcp.chat.facebook.com
(09:50:13) dnssrv: found 1 SRV entries
(09:50:13) dnsquery: Performing DNS lookup for chat.facebook.com
(09:50:13) dnsquery: IP resolved for chat.facebook.com
(09:50:13) proxy: Attempting connection to 173.252.122.5
(09:50:13) proxy: Connecting to chat.facebook.com:5222 with no proxy
(09:50:13) proxy: Connection in progress
(09:50:13) proxy: Connecting to chat.facebook.com:5222.
(09:50:13) proxy: Connected to chat.facebook.com:5222.
(09:50:13) jabber: Sending (<redacted>@chat.facebook.com/Laptop): <?xml version='1.0' ?>
(09:50:13) jabber: Sending (<redacted>@chat.facebook.com/Laptop): <stream:stream to='chat.facebook.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
(09:50:13) jabber: Recv (389): <?xml version='1.0' ?><stream:stream from='chat.facebook.com' id='1' version='1.0' xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' xml:lang='en'><stream:features><starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/><mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><mechanism>X-FACEBOOK-PLATFORM</mechanism><mechanism>PLAIN</mechanism></mechanisms></stream:features>
(09:50:13) jabber: Sending (<redacted>@chat.facebook.com/Laptop): <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
(09:50:13) jabber: Recv (50): <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
(09:50:13) nss: SSL version 3.3 using 128-bit AES with 160-bit SHA1 MAC
Server Auth: 2048-bit RSA, Key Exchange: 256-bit ECDHE, Compression: NULL
Cipher Suite Name: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
(09:50:13) nss: subject=CN=chat.facebook.com,O="Facebook, Inc.",L=Menlo Park,ST=CA,C=US issuer=CN=DigiCert High Assurance CA-3,OU=www.digicert.com,O=DigiCert Inc,C=US
(09:50:13) nss: subject=CN=DigiCert High Assurance CA-3,OU=www.digicert.com,O=DigiCert Inc,C=US issuer=CN=DigiCert High Assurance EV Root CA,OU=www.digicert.com,O=DigiCert Inc,C=US
(09:50:13) nss: partial certificate chain
(09:50:13) certificate/x509/tls_cached: Starting verify for chat.facebook.com
(09:50:13) certificate/x509/tls_cached: Checking for cached cert...
(09:50:13) certificate/x509/tls_cached: ...Found cached cert
(09:50:13) nss/x509: Loading certificate from C:\Path\To\.purple\certificates\x509\tls_peers\chat.facebook.com
(09:50:13) certificate/x509/tls_cached: Peer cert matched cached
(09:50:13) nss/x509: Exporting certificate to C:\Path\To\.purple\certificates\x509\tls_peers\chat.facebook.com
(09:50:13) util: Writing file C:\Path\To\.purple\certificates\x509\tls_peers\chat.facebook.com
(09:50:13) nss: Trusting CN=chat.facebook.com,O="Facebook, Inc.",L=Menlo Park,ST=CA,C=US
(09:50:13) certificate: Successfully verified certificate for chat.facebook.com
(09:50:13) jabber: Sending (ssl) (<redacted>@chat.facebook.com/Laptop): <stream:stream to='chat.facebook.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
(09:50:13) jabber: Recv (ssl)(338): <?xml version='1.0' ?><stream:stream from='chat.facebook.com' id='1' version='1.0' xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' xml:lang='en'><stream:features><mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><mechanism>X-FACEBOOK-PLATFORM</mechanism><mechanism>PLAIN</mechanism></mechanisms></stream:features>
(09:50:13) sasl: Mechs found: X-FACEBOOK-PLATFORM PLAIN
(09:50:13) jabber: Sending (ssl) (<redacted>@chat.facebook.com/Laptop): <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='PLAIN' xmlns:ga='http://www.google.com/talk/protocol/auth' ga:client-uses-full-bind-result='true'>password removed</auth>
(09:50:14) jabber: Recv (ssl)(51): <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
(09:50:14) jabber: Sending (ssl) (<redacted>@chat.facebook.com/Laptop): <stream:stream to='chat.facebook.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
(09:50:14) jabber: Recv (ssl)(304): <?xml version='1.0' ?><stream:stream from='chat.facebook.com' id='1' version='1.0' xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' xml:lang='en'><stream:features><bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/><session xmlns='urn:ietf:params:xml:ns:xmpp-session'/></stream:features>
(09:50:14) jabber: Sending (ssl) (<redacted>@chat.facebook.com/Laptop): <iq type='set' id='purple9afc51af'><bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'><resource>Laptop</resource></bind></iq>
(09:50:14) jabber: Recv (ssl)(179): <iq from='-1373340099@chat.facebook.com' id='purple9afc51af' type='result'><bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'><jid><redacted>@chat.facebook.com/Laptop</jid></bind></iq>
(09:50:14) jabber: Got a result iq with id purple9afc51af from -1373340099@chat.facebook.com instead of expected <redacted>@chat.facebook.com!
(09:50:14) jabber: Unhandled IQ with id purple9afc51af

Running 2.10.11 on Windows 7. Should I file a new ticket since this has been closed or can resume investigating this issue here?

comment:40 in reply to: ↑ 39 Changed 17 months ago by datallah

Replying to awildcolin:

I started encountering this issue late yesterday night/early this morning:

This is a completely different issue - facebook has broken (looks like intentionally since they've planned to remove it for some time) their XMPP interface.

comment:41 Changed 17 months ago by dipal

Facing same issue from Ubuntu 14.04 (Pidgin 2.10.9) from yesterday. Are we getting a patch for this one ?

*asking because the ticket status is still closed.

comment:42 Changed 17 months ago by Robby

dipal, in the comment before yours datallah explained why this ticket is closed.

comment:43 Changed 17 months ago by mmcco

comment:44 Changed 16 months ago by chaoscommander

Running 2.10.11 on Gentoo Linux and the bug is still present. What happened to the fix? Wasn't it implemented or doesn't it work? My use case is different: I'm trying to use an XMPP Transport (for the record: spectrum2) and it returns my roster without "from" entry which is legal as described above. Pidgin receives the whole roster according to the debug window but refuses to display it / let me login.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!