aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeLines
...
* Show ./configure args in bitlbee -V, config.h and Makefile.settingsdequis2015-11-21-2/+9
|
* jabber: Implement carbons (XEP-0280)dequis2015-11-21-8/+106
| | | | | | | | | | | | | | "Message carbons" (XEP-0280) is a server feature to get copies of outgoing messages sent from other clients connected to the same account. It's not widely supported by most public XMPP servers (easier if you host your own), but this will probably change in the next few years. This is enabled by default if the server supports it. It can also be disabled with the "carbons" account setting. Loosely based on a patch by kormat from trac ticket 1021. (Thanks!) I moved stuff around, simplified things, fixed a few bugs, and used the new self-messages feature.
* IRCv3 cap-3.2/sasl-3.2 capabilities (just send sasl mechanism list)dequis2015-11-20-3/+7
| | | | | | Nothing else needed, i think. No need for multiline replies, cap-notify, sasl reauthentication just works, and the authentication layer is always available.
* IRCv3 away-notify capabilitydequis2015-11-20-0/+33
| | | | | | | | | | | Neat lightweight notifications of the awayness of contacts. In practice, this means weechat/hexchat users can see away people in their nick list and change show_users to 'online,special,away' to avoid the mode spam completely. These are also sent on online/offline changes, since offline_user_quits can be turned off, and you'd need something when they come back.
* irc_send_whois: Refactor out a get_status_message() functiondequis2015-11-15-10/+35
| | | | Because i'm going to use it elsewhere.
* Nuke imcb_clean_handle(), which was merging handles accidentallydequis2015-11-09-30/+4
| | | | | | | | | | | | | | | | Well, just deprecated and turned into a no-op. It was only used for jabber anonymous MUCs, but this is something the IRC layer must take care of. It stripped all whitespace, control and non-ascii characters, breaking utf8 nicks support and accidentally merging contacts whose cleaned-up handles were the same string. For example, you could have two users with nicks ' ' and ' ' (one and two spaces respectively) and imcb_clean_handle() would just merge them into a single handle, '', which makes them look like a single irc user. The same thing happens with nicks that are entirely made of utf8. Thanks to schoppenhauer from #bitlbee for reporting this and preparing a test case channel!
* IRCv3 extended-join capabilitydequis2015-11-08-1/+7
| | | | | | Not very useful for the account features (and i won't implement account-notify), but it has a real name field, and it's *really* easy to implement.
* Update twitter's "help set mode" to mention that DMs are now fetcheddequis2015-11-08-1/+1
|
* otr_filter_colors: Also remove \x02 (irc bold)dequis2015-11-07-1/+1
|
* Do not use NOTICE for OTR messages for a given userMischa S2015-11-07-2/+2
| | | | Because they are very very easily lost. Changing to PRIVMSG
* sighandler_crash: Mark irc socket as blocking before writingdequis2015-11-03-0/+1
| | | | | Just to ensure the whole thing gets written, since this can't be async for obvious reasons.
* Remove some dust from the old (very old) doc/READMEdequis2015-10-30-38/+12
| | | | | | | | | | There were some mentions about some password obfuscation method that probably hasn't been used in a decade. And some portability issues that are probably not relevant anymore. Also: "The MD5 algorithm code is licensed under the Aladdin license". No, it's not. I don't think it was before I removed it in favor of glib's GChecksum, either.
* A bunch of completely arbitrary changes to the READMEdequis2015-10-30-15/+25
|
* tests: Define a stub sighandler_shutdown_setup() to allow linkingdequis2015-10-30-0/+5
| | | | | | I'm sure that some day the tests will be useful, not just an annoyance. Some day.
* Avoid propagating shutdown signal to all subprocessesdequis2015-10-30-9/+31
| | | | | | | | | | | | | | | | | | | | This was a sort-of-regression with 7233f68 While this behavior might seem desirable in some cases, multi-user installs like public servers would rather not kill children while upgrading. Turns out that pipes are inherited by forks, and writing in one side means there might be more than one listener that calls bitlbee_shutdown(). If the parent gets it, the children will get it too. If a child gets it, the parent and the other children get it too. This adds a sighandler_shutdown_setup() function that closes any previously existing pipes and disconnects the events from them, to create a new one. This is called again after forking each child process. While I'm sure this fixes the issue, I still don't understand why it *didn't* kill the forked processes in some cases. Worrying.
* jabber: Don't reply XEP-0184 receipts sent over MUCsdequis2015-10-30-7/+8
| | | | | XEP-0184 section 5.3 says those shouldn't be sent over MUCs, but some misbehaving clients do anyway, resulting in 'forbidden' errors
* ipc: Fix strict aliasing warningsdequis2015-10-30-2/+2
| | | | | | | | | | | Turned out to be as simple as just using memcpy. As with all strict aliasing warnings, these only appeared when compiling with optimization, and might have caused Bad Things™ This page is cool: http://dbp-consulting.com/tutorials/StrictAliasing.html
* log: Refactor log_link() to be less redundant.dequis2015-10-30-37/+15
| | | | | "I didn't feel like messing with pointer to function pointers", said the comment. Well, I do, comment. It wasn't a big deal either.
* MSN: self message supportdequis2015-10-30-13/+34
| | | | This is straightforward, like receiving a message with From/To swapped
* jabber: Self message handling (echo removal) in MUCsdequis2015-10-30-11/+16
| | | | | | | | | | | | | | | | | | | | | XMPP MUCs always echo own messages, and send messages from other clients. So, we must display everything except the messages we just sent. This implementation uses the jabber stanza cache to add an ID to the message and attach it to a callback which always returns XT_ABORT. This way, if we do get the echo, the message packet handler can call jabber_cache_handle_packet(), and if it returns XT_ABORT, it can skip that particular message. Every other message that looks like it comes from our own JID and wasn't handled by the cache will be displayed, with the OPT_SELFMESSAGE flag Stanza cache entries expire after some time, so it's not a problem if the server doesn't echo messages for some reason. I actually wrote this forever ago, for hipchat, but it works the same way for standard XMPP MUCs.
* IRC self-message support (messages sent by yourself from other clients)dequis2015-10-30-19/+98
| | | | | | | | | | | | | | | | | | | | | | This adds an OPT_SELFMESSAGE flag that can be passed to imcb_buddy_msg() or imcb_chat_msg() to indicate that the protocol knows that the message being sent is a self message. This needs to be explicit since the old behavior is to silently drop these messages, which also removed server echoes. This commit doesn't break API/ABI, the flags parameters that were added are all internal (between protocols and UI code) On the irc protocol side, the situation isn't very nice, since some clients put these messages in the wrong window. Irssi, hexchat and mirc get this wrong. Irssi 0.8.18 has a fix for it, and the others have scripts to patch it. But meanwhile, there's a "self_messages" global setting that lets users disable this, or get them as normal messages / notices with a "->" prefix, which loosely imitates the workaround used by the ZNC "privmsg_prefix" module.
* Use proxy_disconnect() in http, ssl, jabber, oscardequis2015-10-26-8/+10
| | | | | | | | | | Twitter and MSN are all HTTP/SSL, so they don't need it either. The out of tree facebook and steam plugins are also covered by the HTTP/SSL changes. Yahoo is written in a weird way and doesn't seem to need it (it seems it doesn't immediately stop connections when you tell it to logout)
* Add proxy_disconnect() to interrupt possibly pending connectionsdequis2015-10-26-1/+40
| | | | | | | | | | | Fixes trac ticket 1198, https://bugs.bitlbee.org/bitlbee/ticket/1198 This function can be used as a safe drop-in replacement to closesocket() If a proxy connection is pending (connected callback still not called), it looks up the PHB in a hash table indexed by fd. If it is there, it closes, frees the phb and avoids further calls to the callback. If it is not in there, it just does closesocket()
* proxy: Turn phb_close() into phb_free(), use it for all g_free(phb)dequis2015-10-26-35/+40
| | | | More cleanup.
* proxy: Use an array of function pointers for proxy_connect_*dequis2015-10-25-10/+15
| | | | Just cleanup.
* purple: Fix certificate cache dir after changing user dirdequis2015-10-25-0/+6
| | | | | | | | | | | | | | | | This fixes the issue with getting asked to accept certificates that are perfectly valid, every time. The directory is normally created by x509_tls_peers_init(), a few calls below purple_core_init(), which is at module initialization time, way before we have an irc username to fix the user directory. So it creates the wrong directory first, and now we have to fix it manually. And apparently not being able to save cached certificates somehow means they aren't trusted. For some reason. < krisfremen> "for some reason" < dx> idklol
* Update 'help set show_users' to mention special and the new defaultdequis2015-10-25-4/+5
| | | | It was added a while ago.
* check_jabber_util: adapt to new behavior of GET_BUDDY_EXACTdequis2015-10-22-1/+1
| | | | | | | I can't believe the tests did something! Returning the bare jabber_buddy when asking for GET_BUDDY_EXACT is now acceptable, since the google talk typing commit.
* socks4a proxy support (like socks4 with remote DNS)dequis2015-10-21-7/+35
| | | | | | | | | Fixes trac ticket 995 https://bugs.bitlbee.org/bitlbee/ticket/995 This is slightly pointless for the suggested use case (tor), since with socks5 we already send a hostname instead of an IP address. Either way, it was easy to implement, so I hope it helps.
* jabber: set BEE_USER_NOOTR flag to _xmlconsoledequis2015-10-21-8/+16
| | | | | | | Fixes trac ticket 1111, https://bugs.bitlbee.org/bitlbee/ticket/1111 One of the most annoying issues. You're trying to debug stuff and it just crashes even harder than without the debug enabled.
* Add a per-user version of OPT_NOOTR, BEE_USER_NOOTRdequis2015-10-21-2/+5
|
* yahoo: call callback on connect error to fix memleakdequis2015-10-21-0/+1
| | | | | | Passing NULL as the "fd" and 0 as the error. The callback is yahoo_connected() in libyahoo2.c, and with those parameters all it does is freeing the data parameter.
* yahoo: Fix handling of proxy connection failuresdequis2015-10-21-1/+9
| | | | | | | | | | | | | | | Fixes trac ticket 135, https://bugs.bitlbee.org/bitlbee/ticket/135 The ticket mentions 100% cpu usage when failing to connect to a socks proxy. It also provides a patch that just checks source == -1 and disconnects cleanly instead of trying to continue logging in. This commit is pretty much the same thing, adapted to the API we're currently using, since the original patch was for bitlbee 1.0.1 and it looks like the old api was terrible back then. That ticket was almost 10 years old. The yahoo code didn't change a lot in that time.
* jabber: Fix XEP85 detection (typing) between two bitlbee usersdequis2015-10-21-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes trac ticket 1143: https://bugs.bitlbee.org/bitlbee/ticket/1143 The "correct" way to discover XEP85 support is to send a discovery query. We take a more conservative approach: if the irc client claims to support typing (by sending CTCP TYPING at least once), we send an <active> tag along with next chat message, and set JBFLAG_PROBED_XEP85. The logic for that stuff is in jabber_buddy_msg(). That's all neat and clever and actually works fine. What was broken was the detection side. Whenever a <composing>, <active> or <pause> is received, the buddy is marked as supporting XEP85. However the <active> tag had an additional check: /* No need to send a "stopped typing" signal when there's a message. */ else if (xt_find_node(node->children, "active") && (body == NULL)) { It skipped the tag completely if it had a message too. This was changed to move the body == NULL condition inside, so that the flag is set. Took me longer to write this message than the diff itself. But even longer to actually decide to debug this behavior. I'm the one who submitted that ticket, one year and a half ago. Yep.
* jabber: Fix outgoing google talk typing notificationsdequis2015-10-21-4/+7
| | | | | | | | | | | Since bare JIDs from typing notifications are now accepted, the other buddy objects never get the flag JBFLAG_DOES_XEP85 set. This fixes it by checking both the buddy with resource and the bare one, with the implication that if the bare JID has that flag, all other resources get typing notifications. Follow up to the previous commit, splitting since they are actually unrelated fixes, although this one is a consequence of the previous one.
* jabber: Fix incoming google talk typing notificationsdequis2015-10-21-1/+5
| | | | | | | | | | | | | | | | | | | | | | | jabber_buddy_by_jid() does the following: head = g_hash_table_lookup(jd->buddies, jid); bud = (head && head->next) ? head->next : head; 'head' has the one without resource, 'bud' has the first resource. So if a resource is available, it uses it and ignores the head. When asked for a bare JID (with no resource) and GET_BUDDY_EXACT, it shouldn't do this, but it should return the head. In other words, the problem was a message in this format: <message from="username@gmail.com" ...> Instead of <message from="username@gmail.com/resource" ...> This only deals with incoming typing notifications. See next commit.
* msn: Don't reconnect on wsse:FailedAuthentication errorsdequis2015-10-14-1/+7
| | | | That includes location blocked and incorrect password.
* msn: Better error messages on 'location blocked'dequis2015-10-14-0/+5
| | | | | | | This is what the 'howtofixmsn' wiki page addressed, which has a very generic name because it's one of the first msn issues that appeared when we thought it was dying. Since it's just a security measure, it still appears when people log in from unusual locations.
* otr: fix trailing whitespace issues with 'otr forget key'dequis2015-10-13-0/+3
| | | | Fixes trac ticket 1089, https://bugs.bitlbee.org/bitlbee/ticket/1089
* skype: create groupchat as soon as a message is receiveddequis2015-10-13-34/+32
| | | | | | | | | | | | | | | | | | Before this commit, the bee_chat_by_title() call just failed when receiving a message in a groupchat we didn't know about, which is probably something skype broke in their api at some point. I'm fixing this since apparently the only way to access p2p based chats is through the official skype desktop client (they won't be supported through msnp24 or skypeweb. It's broken in mobile clients already), so this plugin is probably the best way to access those. This breaks the 'msg' test - now all chats are groupchats and there's no way to tell them apart. However, in reality, private messages aren't delivered at all over the api, or at least I never managed to get them working. Probably if you talk with someone who has a very old patched skype client.
* skype tests: adjust channel length limit to fix tests...dequis2015-10-13-15/+15
| | | | | | | | | | | | | | The diff might look confusing - it's just removing the last hex digit of each channel name in the groupchat tests. This broke in several ways over the years. I know because i've been bisecting the last few hours and found lots of different issues. All of them except this one were fixed already This one is probably a side effect of the new irc channel name generation code that includes the # as part of the string and reuses the nick code. Or maybe not exactly that, but something similar. I'm not going to bisect any further, had enough for today.
* skype: fix tests to expect NOTICE * instead of NOTICE AUTHdequis2015-10-13-21/+21
| | | | Forgot to change this after b39859e
* skype: use g_vsnprintf() instead of vsnprintf()dequis2015-10-13-2/+1
| | | | | | More prefixes = better. The G stands for "good". (it also fixes the warning about _BSD_SOURCE being deprecated)
* skype: use ssl_sockerr_again() instead of sockerr_again()dequis2015-10-13-1/+1
| | | | | Found the thing using 100% cpu because of a dead connection that it didn't want to bury.
* twitter: Fix some nitpicky issues reported by coveritydequis2015-10-08-21/+24
| | | | | | Mostly minor rare leaks that happen in error conditions, and one dereference before null check in twitter_logout (the null check is probably the wrong one there, but it doesn't hurt to keep it)
* irc_sasl_plain_parse: fix size of the parts arraydequis2015-10-08-1/+1
| | | | | | | | Oddly enough it doesn't break. Maybe it overwrites the 'decoded' pointer when it doesn't need it anymore? Fun stuff. Also the version of gcc (5.2) i'm using doesn't complain about array bounds, clang does, and the older gcc (4.6) in travis does too.
* Fix use-after-free when leaving invited (temporary) channelsdequis2015-10-08-2/+5
| | | | | | | | | Trac ticket 1229, https://bugs.bitlbee.org/bitlbee/ticket/1229 This one is complicated. See the trac ticket for details. Relevant commits: cc20520 6963230 664bac3 - second one fixed the same issue, third one reverted it, this one takes a different approach.
* The SASL PLAIN RFC says that the first part can be emptydequis2015-10-08-2/+2
| | | | | | | | | | | | | | | | | So use the second part as the username, and only require it to be equal to the first part if that one is present. ABNF from the spec: message = [authzid] UTF8NUL authcid UTF8NUL passwd Note brackets. Authzid (authorization identity) is meant for impersonation, which we don't support. The actual login username is defined by authcid (authentication identity) Thanks grawity for pointing this out.
* IRCv3 SASL capability + PLAIN methoddequis2015-10-08-0/+143
| | | | | | | | | | | | | | | | | | | | | Only plain, no other methods. We don't have built-in SSL to implement EXTERNAL (certfp) and nothing else is worth implementing. The actual authentication is pretty much like sending a server password (when the server's authmode isn't closed), which means it happens in cmd_identify, but this code also calls storage_check_pass() to send the required success/failure replies. SASL doesn't give us much benefit other than standards compliance, but some clients might appreciate it. And having a fifth way to do the same thing doesn't hurt! Now we have: - identify in &bitlbee - identify to nickserv (alias for root) - 'nickserv' and 'ns' irc commands - server password - sasl plain
* irc_send_who: move the iu->flags check after iu has a value...dequis2015-10-08-3/+3
| | | | | | Moving this was suggested during the review of the multi-prefix patch as ordering the sets of status_prefix... and it seemed reasonable to me. Thanks valgrind.
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-27 02:36:08 +0000