[jdev] Presence subscription handling bugs in various Jabbersoftware

[Stephen Pendleton]

I would think the bug lies at least in client "a" since the client adds "b"
to its roster even though it was not requested. In defense of the client
developer, it is a bit complicated to handle this correctly since the client
would need to "remember"  outstanding subscription requests between runs of
the client software. I doubt many (or any?) clients do this, and just assume
any "subscribed" stanzas received are valid reponses from a previous
subscription request.

However are you also saying that "b" can also correctly see the presence of
"a", or does it just pass on the subscribed stanza the client "a" and not do
anything further? Is client "b" added to the client "a"'s roster on the
server or does client "a" just add it in the GUI - but when the client
restarts the client "b" does not reappear in the roster? If it is added to
the roster on the server, this is a problem with the server implementations.
I would think the server should remember what outstanding subscription
requests there are for every user on the system and reject any unsolicited
subscribed requests that are sent.

-----Original Message-----
From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On Behalf Of
Jacek Konieczny
Sent: Sunday, February 06, 2005 10:12 AM
To: jdev at jabber.org
Subject: [jdev] Presence subscription handling bugs in various
Jabbersoftware


Hello,

Most of us know, that some transports abuse 
<presence type='subscribed'/> stanzas, in a way which is now forbidden by
the XMPP-IM specification. That is done because of a very old bug in
jabberd-1.x based servers, which accept and process this stanza. It is not
good, when anyone is able to add himself to other's roster.

Now, when more and more servers aim at the XMPP compliance I thought such
features and abuses are going to die. Unfortunately it seems that I am
wrong.

Some users of my server complain, that some users of other servers are able
to add themselves to their rosters. It looks like this:

  a - user of my server
  A - my server
  B - the other server
  b - the other user

  They are connected like this:

  a ----(c2s)---- A ------- (s2s) ------ B ------- b
  (any        (ejabberd)              (some      (some
  client)                              server)    client)

  "a" does not have "b" in his roster, then "b" does "something" that
  add it to "a"'s roster by sending <presence type='subscribed'/>
  although "a" have never requested it.

Two such cases where reported to me. In the first case, the server "B" was
jabber.org (jabberd-1.4.x AFAIK), and the client "b" was (most
probably) Psi.

In the second case "B" was WP Jabber (JSM/JSM version 1.1.5 for pthreaded
server (Linux 2.6.x)), and "b" Psi (Psi/0.9.3 (SuSE Linux 9.2 (i586))).

Server "A" is always the same: ejabberd/0.7.5 (unix/linux 2.6.7) Client "a"
doesn't matter.

Please note, that for that scenario to work there must be bugs on both
servers ("A" which should not accept that stanza and "B", which should not
forward it from its client) and a misfeature on the client "b" (I have found
nothing in the XMPP specs that forbids client to send unsolicited <presence
type="subscribed" />). So we have bugs in at least free server
implementations (ejabberd, jabberd 1.4.x and WP Jabber) and annoying (for
users of buggy servers) misfeature of at least one client (I may be wrong
here if it is not the client which generates the "subscribed" stanza). That
doesn't look good, as 
it seems a very big part of global Jabber infrastructure is broken :-(

Or maybe I am wrong and there is only one bug somehere?

I will submit a bug report to the maintainers of the software I use
(ejabberd). And I ask you to check your software, and submit the bugs
reports or fix the bugs too.

Greets,
	Jacek
_______________________________________________
jdev mailing list
jdev at jabber.org
http://mail.jabber.org/mailman/listinfo/jdev