aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeLines
* BitlBee 3.4.2 - release date fixed.3.4.2Wilmer van der Gaast2016-03-19-1/+1
|
* Prepare 3.4.2 release notesdequis2016-03-12-2/+66
|
* jabber: return XT_ABORT after failed IQ auth attemptsdequis2016-03-12-2/+2
|
* twitter.c: Squelch an unused variable warningDennis Kaarsemaker2016-02-26-1/+1
| | | | 9456255 made the variable 's' unused but failed to remove it.
* Fix a double free when calling proxy_disconnect() inside phb->func()dequis2016-02-18-8/+23
| | | | | | | | | | | | | | | | Fixes trac ticket #1248 proxy_connected() calls phb->func(), then tries to do phb_free() directly afterwards, but that might have been freed by a proxy_disconnect() call during the execution of that callback. This one happened to several different people because some AIM server broke recently. This commit fixes it by implementing a phb_connected() function that removes the PHB from the hash table before calling phb->func(), which ensures that any proxy_disconnect() calls just close the fd and nothing else.
* Change twitter url length to 23 instead of 22Vegard Langås2016-02-09-6/+1
|
* Send away-notify after join/part from IRC channelShane Synan2016-02-04-6/+6
| | | | | | | Move irc_send_away_notify below bee_irc_channel_update to delay sending the updated away-notify status until after any nicks have joined/quit. Otherwise, some IRC clients will drop the status messages as they go to nicks that the client doesn't know about.
* Check global account away setting in WHO repliesShane Synan2016-01-31-2/+7
| | | | | | | | When sending WHO reply, check if irc_user is the account user and if so set away status according to global account away configuration. Otherwise, reply according to irc_user flags. Fixes global away status not being shown in IRC clients when WHO polling is enabled. Fixes: https://bugs.bitlbee.org/ticket/1247
* root_commands: Fix use-after-free after doing "transfer reject"dequis2016-01-26-1/+3
| | | | | | Not a big deal because as far as I can see not much happens between the g_slist_remove() in dcc_close() and accessing files->next. I'd expect that pointer to remain null after being freed most of the time.
* jabber: Mark messages from other resources as OPT_SELFMESSAGE toodequis2016-01-24-1/+3
| | | | | | | The jabber_buddy used for messages sent from other resources connected to the same groupchat has a different ext_jid and it's a different object than jc->me, so doing a string comparison against acc->user is needed.
* purple: Also show 'title' and 'primary' messages for input requestsdequis2016-01-21-1/+12
| | | | It was showing 'secondary' only before.
* Revert "hipchat: Implement their own variant of self-messages [...]"dequis2016-01-21-19/+1
| | | | | | | This reverts commit d11ccbf6ea94264bde8b0f525c4bbedf50de0174. After thinking about this long enough I've decided this is a bad idea, and better wait for the hipchat server to support carbons.
* 'help set self_messages': link to wiki pagedequis2015-12-30-0/+4
|
* msn: Fix ADL/RML (add/remove from list) throwing server errorsdequis2015-12-30-1/+3
|
* msn: Don't truncate passwords to 16 chars anymore.dequis2015-12-30-5/+1
| | | | This was needed back in 2010, but now it's not.
* purple: Show self-messages for private messages onlydequis2015-12-27-24/+25
| | | | | | | | | | Those are purple_conversation_write with PURPLE_MESSAGE_SEND flag set, received through the write_conv UI op. write_chat and write_im still receive and filter PURPLE_MESSAGE_SEND. In the case of write_chat it *could* show some of those, but it seems there's no decent way to tell echoes apart from remote self-messages. So just keep those hidden for now.
* purple: document original names of uiops next to themdequis2015-12-26-64/+64
|
* oscar: Add prefixes to all functions that may conflict with purpledequis2015-12-18-0/+98
| | | | | | | | When people build with ./configure --purple=1 --oscar=1, the native oscar is compiled statically, which should take priority, but sometimes purple's oscar is used instead and bad things happen, most of it being due to calling bitlbee's native aim_callhandler instead of the function with the same name of libpurple's liboscar.so.
* ini: Null check file parameter before passing it to open()dequis2015-12-17-2/+2
| | | | | The test suite does this. It's harmless in practice but open() is declared as nonnull. Thanks to clang's ubsan.
* hipchat: Implement their own variant of self-messages (not working yet)dequis2015-12-16-1/+19
| | | | | | | | | | | | Reuses part of the carbons code, but it's not like it at all. To be able to receive these messages at all, a different cap node whitelisted by them is required. I could have used one of the official clients, but let's try to get things done the right way. This will start working once they make that change in their servers, right now this is still in their ticket backlog. I'm merging this now because it's harmless and nice to have as part of the upcoming release.
* jabber: Add message processing hints to OTR messages (XEP-0334/0364)dequis2015-12-15-0/+22
| | | | | This prevents them from being stored or copied to other clients when carbons are enabled.
* Remove nonexistent forward declarationesainane2015-12-11-1/+0
| | | | | | imcb_find_buddy is mentioned only in nogaim.h, and is never defined anywhere. This is misleading for plugin authors, who were probably looking for (the actually implemented) imcb_buddy_by_handle instead.
* Revert "imc_away_send_update: Fix leak of away_states linked list"dequis2015-12-09-6/+1
| | | | | | | | | This reverts commit ed431c389887080dc4fa45e30d051ce733f4ce57. I'm going to let this leak. Turns out only purple allocates an empty list for every time this is called. Other protocols have statics, and they always return the same thing, can't free those. Whatever. The purple leak was insignificant, just more scratching of itches.
* proxy: fix validation of the proxytype valuedequis2015-12-09-1/+1
| | | | | | Coverity says it could be an out of bounds read, but the value is set internally, so not really. Still, good point about the condition being wrong.
* purple: fix crash when doing 'chat with' with skypewebdequis2015-12-06-1/+1
| | | | | | | | | | | It was passing the wrong data to the callback - it was supposed to pass the data of the PurpleMenuItem but it passed the PurpleMenuItem itself. Probably also applies to other protocols too. It worked fine with jabber, which i'm guessing is what this code was tested with originally. It still whines about the null return value saying "(Possible) failure" but, eh, whatever.
* IRCv3 userhost-in-names capabilitydequis2015-12-05-2/+13
| | | | Easiest part of ircv3.2
* irc_send_names: refactor to use GString instead of the stackdequis2015-12-05-10/+17
| | | | | | | Because modifying this code was making me REALLY uncomfortable. This still only allocates memory once. Needing to extend the string would be a bug in the length checks, but at least that's harmless now.
* imc_away_send_update: Fix leak of away_states linked listdequis2015-12-05-1/+6
|
* If imc_away_state_find() fails, try again finding "away"dequis2015-12-05-1/+2
| | | | | | | | | | | | | | | | | | | Fixes trac ticket 1175, https://bugs.bitlbee.org/bitlbee/ticket/1175 "Setting away with libpurple fails silently except for a few values" Turns out the fallback was the first item of the list, which for libpurple's jabber is "Feeling" (what?) and seems to be a no-op in practice. With this commit the fallbacks are in this order: 1. Try to find whatever the user wrote in the away setting. 2. If that fails, find "away" in the away states. 3. If that fails, use the first away state. This might not fix it in some rare cases where the prpl doesn't have an away state equivalent to away. But hopefully the old fallback works for those, jabber was the weird one here.
* Remove facebook XMPP code, show error pointing at the new plugindequis2015-12-04-49/+14
| | | | | | | | | | | | | | Facebook's oauth has been broken for months, and in the last few days they broke plain logins too, so I just added an error message that says this when you do "account on": Facebook's XMPP service is gone. Try this instead: https://wiki.bitlbee.org/HowtoFacebookMQTT Also nuked all the oauth related code, except some parts of lib/oauth2.c which seemed generic enough to maybe help in the future with other not-really-compliant not-really-implementations of the not-really-oauth2 not-really-spec
* purple: assume HTML for all protocols, fixes random <> for somedequis2015-12-01-3/+1
| | | | | | | | Purple's IRC, for example, doesn't have the PURPLE_CONNECTION_HTML flag, but still sends html for format codes. Note that using IRC through libpurple through bitlbee is still a terrible idea. Use ZNC instead.
* purple: Implement PurpleNotifyUiOps.notify_messagedequis2015-12-01-1/+22
| | | | | | | | | | | | | | | | | | Which has no connection context. Luckily local_bee exists, and libpurple only supports only one irc user per process. This sucks. And yesterday I was naively thinking (again) that local_bee might not be needed, that maybe we can do things properly. Of course it only took a look at that one reverted commit (56985aa) to remember that life is unfair, and that, under Moloch, everyone is irresistably incentivized to ignore the things that unite us in favor of forever picking at the things that divide us in exactly the way that is most likely to make them more divisive. That being said, I think all these hacks are going to look nicer once I sandbox the whole thing in a separate process with one IM account per process, as opposed to one irc use per process. Then we'll be able to rely on global state exclusively, which is saner.
* Add 'log' UI function, to avoid direct calls to irc_rootmsg from nogaimdequis2015-12-01-3/+17
| | | | | Just a trivial wrapper over irc_rootmsg(), but will help me to slightly reduce the ugliness of an unavoidably ugly hack for libpurple.
* purple/ft: remove prplcb_xfer_dbg entries with mismatching signaturesdequis2015-12-01-7/+2
| | | | More fixing warnings.
* purple: avoid warnings in the PURPLE_INPUT_* enum checksdequis2015-11-30-5/+2
| | | | Also turn them into asserts because that's what it really does.
* msn: remove suggestion to use the official client, which is deaddequis2015-11-29-2/+1
| | | | I mean sure you could use messenger reviver but..
* set_eval_channel_type: skip the channel free/init if nothing is changeddequis2015-11-28-0/+5
| | | | | | | Fixes trac ticket 1108: https://bugs.bitlbee.org/bitlbee/ticket/1108 I would have ignored that ticket (it's about some sort of legacy migration) but the fix sounds like a sane thing to do
* msn: Send VER/CVR/USR together in the first request for faster logindequis2015-11-28-4/+10
|
* msn: Buffer writes a bit to send several commands with a single requestdequis2015-11-28-2/+27
| | | | | | | | Just a 1msec timeout, so that it will run in the next main loop iteration. The official clients send the first few commands in the same request, which reduces roundtrips during login. This commit doesn't do that.
* bee_irc_user_new: Use str_reject_chars to sanitize both user and hostdequis2015-11-27-3/+3
| | | | | | | Fixes trac ticket 1195: https://bugs.bitlbee.org/bitlbee/ticket/1195 I had no idea how to reproduce that bug until I tried with libpurple. The built-in jabber never had this problem.
* misc.c: Add a str_reject_chars function, use it in otr_filter_colorsdequis2015-11-27-8/+20
|
* irc: Send numeric error when failing to join a channeldequis2015-11-26-1/+10
| | | | | | | | | | | | | This fixes issues like getting a blank window with a channel that the irc client thinks the user is in but bitlbee doesn't. The error is sent either by returning NULL in the chat_join prpl function, or by calling imcb_chat_free() before the user is added to the channel. This wasn't possible before since purple returned NULL in its chat_join, which resulted in other bugs too. Since that's fixed, I can finally apply this, which has been in my stash for a very long while.
* purple: fix a bunch of small leaksdequis2015-11-25-0/+11
| | | | | Most of them related to channel joins, one of them related to my recent certificate pool path fix.
* purple: fix /join #channel, which joined a different channeldequis2015-11-25-4/+12
| | | | | | | | | | | | | | | | | | | | When joining named channels, purple_chat_join() returned NULL instead of a struct groupchat, which was actually created in the conversation created callback (prplcb_conv_new()). If the name of this channel turned out to be different to the joined one, this meant having one empty window in the irc client, and another one for the other channel. The fix is to return a mostly-empty struct groupchat immediately, and pick it up later when the PurpleConversation is created using bee_chat_by_title(). If that fails, fall back to creating a new one. This bug also meant there was no proper way to report a join failure. Future commits will address that, this one just makes that easier. Thanks to Etan Reisner (deryni) for enlightening me while i was trying to figure out how to fix this.
* help: free strings added by help_add_mem()dequis2015-11-25-1/+3
| | | | | Not really a leak, but I want valgrind to be happy because valgrind is nice to me. I love you valgrind <3
* jabber: Reply unknown IQs with service-unavailable insteaddequis2015-11-25-4/+6
| | | | | | | | | | | It was sending 'feature-not-implemented' for <query> with unknown xmlns (which makes sense, but the RFC says that's wrong. idk.) and nothing at all for IQs that don't have query/ping/time elements or an xmlns attribute. Both get service-unavailable now. Addresses the rest of trac ticket 533: https://bugs.bitlbee.org/bitlbee/ticket/533
* jabber: Fix detection of away state in choose_priority()dequis2015-11-24-1/+1
| | | | | | | | | | | | Thanks to this clang warning: comparison of array 'jd->away_state->code' not equal to a null pointer is always true [-Wtautological-pointer-compare] Although... given how ->code is offset 0, that might have worked sometimes if jd->away_state is null, assuming a compiler that doesn't hate humanity. Sadly, that is not something we can safely assume. I bet gcc saw this and thought "let's optimize your poor soul away".
* Show a nicer message when a protocol is disabled in account adddequis2015-11-23-12/+20
| | | | | | | | | | | | This adds the disabled protocols' prpl structs to a different linked list, only used for this lookup. They were previously marked as leaking by valgrind, so, whatever. I can't free them, since some protocols memdup() it after attempting to register. I think disabling the protocols from bitlbee.conf is just stupid and provides no real benefits, but someone will complain if i get rid of it. So this just improves the error message to make it less confusing when someone accidentally uncomments that crap.
* hipchat: 'chat add hipchat "channel name"' now tries to guess the JIDdequis2015-11-23-0/+87
| | | | | | | | | | | It's basically prepending the organization id, appending the default MUC host from the success packet, and generating a slug based on the name for the middle part, which is replacing a few characters with underscores and doing a unicode aware lowercasing. Includes tests, which are useless other than validating the initial implementation with the test vectors that i already tested manually. Guaranteed to detect zero breakages in the future. Good test code.
* jabber_chat_join_failed: add a null check before freeing the chatdequis2015-11-23-1/+4
| | | | | | Had this one in a stash, i think it's about trying to join a channel with an invalid JID and getting an error with a different JID back, so doing jabber_chat_by_jid() doesn't find it.
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-26 16:05:27 +0000