aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeLines
...
* 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.
* 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.
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-26 17:12:48 +0000