| Commit message (Collapse) | Author | Age | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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".
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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!
|
|
|
|
|
| |
XEP-0184 section 5.3 says those shouldn't be sent over MUCs, but some
misbehaving clients do anyway, resulting in 'forbidden' errors
|
|
|
|
| |
This is straightforward, like receiving a message with From/To swapped
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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_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.
|
|
|
|
| |
That includes location blocked and incorrect password.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Forgot to change this after b39859e
|
|
|
|
|
|
| |
More prefixes = better. The G stands for "good".
(it also fixes the warning about _BSD_SOURCE being deprecated)
|
|
|
|
|
| |
Found the thing using 100% cpu because of a dead connection that it
didn't want to bury.
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
| |
From coverity.
That g_strdup_printf() was really pointless, slightly ashamed we didn't
notice that in the review of the patch.
|
|
|
|
| |
From coverity.
|
|
|
|
|
|
|
| |
- Look for a status message right inside <presence> (seen with ejabberd
as a result of a s2s connection error)
- Check status codes in a while loop, skipping unknown ones (such as
110, which means "Inform user that presence refers to itself")
|
|
|
|
|
|
|
|
|
|
|
| |
To simplify testing. Also allow passing a -1 as size to use strlen()
Minor behavior change: The jabber_init_iq_auth() branch can no longer
return immediately, which means it will continue through the
ssl_pending() check in jabber_read_callback().
Other than that, the size -1 change, and one indentation level less, the
function body is the same as before.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Which in practice means "don't bother with DIGEST-MD5 most of the time".
It's weak, pointless over TLS, and often breaks with some servers
(hi openfire)
|
|
|
|
| |
Use "account jabber set anonymous on" to have bitlbee try that method
|
| |
|
| |
|
|
|
|
|
|
|
| |
By asking the server for the username.
Storing the username somewhere would have made sense, but this command
isn't going to be used very often, so, whatever.
|
|
|
|
|
|
|
|
| |
Yeah, just the letter s from "https", and a null byte.
Really critical stuff.
You'd have to post a million tweets to even notice this at all.
|
|
|
|
|
| |
Accidentally nuked it while resolving merge conflicts of a different
branch.
|
| |
|
|\ |
|
| |\ |
|
| | |
| | |
| | |
| | |
| | | |
- GMail notifications stuff is now just 'mail_notifications'
- sed -i s/notify_handle/mail_notifications_handle/
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Saves some messing with g_strdup_printf for the callers, and
flags/sent_at weren't used anyway.
Also check if the mail_notifications setting is enabled
|