Rejecting a buddy request on jabber actually accepts it

[anonymous]

Hi,

I tried to reject a buddy request, but got added to a list anyway:

13:38 <@root> jabber(me@…) - New request: The user someone@… wants to add you to his/her buddy list.
13:38 <@root> You can use the yes/no commands to accept/reject this request.
13:48 <@me> no
13:48 <@root> jabber(me@…) - Rejected: The user someone@… wants to add you to his/her buddy list.
13:48 <@root> jabber(me@…) - someone@… just accepted your authorization request
13:48 -!- someone [someone@…] has joined &bitlbee

This isn't supposed to work like this, is it?

[anonymous]

I just encountered this as well with 3.0.4-bzr855-1 on Debian. Not pasting the output since it's exactly the same as the original submitter's.

[wilmer]

Hrmm. The "just accepted your auth request" message is misleading, on GTalk I get that one pretty often without adding anyone. GTalk has somewhat odd contact list behaviour, I think it often automatically adds contacts as you send them e-mails, etc.

Not sure if that's related though. I'd have to check in xmlconsole what BitlBee sends when you use the "no" command. I'm pretty sure it's doing the right thing..

[wilmer]

I've heard more reports of this now. I'mm still convinced this is GTalk behaving oddly, but it's definitely fishy...

[tom]

I can confirm this happens consistently. And it definitely gives the person the ability to message you because as soon as I get that "accepted your request" message, the bot starts sending messages. I've found that simply doing nothing when presented with the yes/no works, though.

[Wilmer van der Gaast <wilmer@…>]

Indeed, so I'm wondering if I should just do nothing when the user says no. The only problem then is that you'll keep getting the question.

[Tom Knight <tomk@…>]

Same thing is happening here. Last time it happened I blocked the user from GTalk but now if I log in to Gmail the person who has requested to be added in BitlBee isn't there to block. And if I try to block from BitlBee it says "Command `block' not supported by this protocol".

So I'll have to go with ignoring the requests for now.

[siberion@…]

Bump.

This still happens in 3.0.5.

Recently, a bunch of bots (presumably), which I most certainly have not had email contact with (not even as a passive receiver, I checked my spam folder), attempted to add me and I observed the same behaviour as described above.

[synergism@…]

Just for the record, the correct command is 'remove', not 'block'. And you can find people who aren't online on your buddy list with 'blist all'. The bug still exists in and was identified on irc:

08:17 < pesco> protocols/jabber/jabber_util.c:jabber_buddy_ask_no
08:18 < pesco> wow
08:18 < pesco> it's a simple typo
08:18 < pesco> presence_send_request( bla->ic, bla->handle, "subscribed" );
08:18 < pesco> should say "unsubscribed"

[anonymous]

Sorry, I wasn't exactly clear about when to 'remove'. You can say 'no'. The bug causes the person to be added to your list. Then you use 'remove' immediately. That's my workaround.

[pesco]

This is simply what looks like a copy-and-paste mistake in ​protocols/jabber/jabber_util.c. When the user answers no, bitlbee actually sends "yes". This is the handler for the "no" answer as of r1010:

static void jabber_buddy_ask_no( void *data )
{
        struct jabber_buddy_ask_data *bla = data;
        
        presence_send_request( bla->ic, bla->handle, "subscribed" );
        
        g_free( bla->handle );
        g_free( bla );
}

That should say "unsubscribed", cf. ​the RFC. Er...

--- protocols/jabber/jabber_util.c      2011-12-26 18:56:10 +0000
+++ protocols/jabber/jabber_util.c      2014-02-13 12:39:43 +0000
@@ -288,7 +288,7 @@
 {
        struct jabber_buddy_ask_data *bla = data;
 
-       presence_send_request( bla->ic, bla->handle, "subscribed" );
+       presence_send_request( bla->ic, bla->handle, "unsubscribed" );
 
        g_free( bla->handle );
        g_free( bla );

Fun fact, I couldn't resist looking: This bug has been in since jabber presence auth was ​first implemented. (It applies only to Jabber, not other IM networks.)

[wilmer]

YEp, it has been. I consider myself shamed, especially since I *think* when this was first reported I blamed gtalk for not implementing authorisation properly.

Which in hindsight, I shouldn't have done so quickly, though OTOH on OSCAR this is how things worked as a "no" would just be visible to the spammer as a sign of life on the account.

[dx]

Yeah, uh, #1112.

Don't tell the people at ticket #887 (reported two years ago, same issue as this one) that the fix was so trivial, they are going to be mad.

*cough*.

[dx]

Patch from ticket #1112 applied in r1012!