| Commit message (Collapse) | Author | Age | Lines |
|
|
|
|
|
|
| |
This constant is always available and meant to be used with
getnameinfo().
This fixes the build on Debian GNU/kFreeBSD.
|
|
|
|
|
|
|
|
| |
Just comparing the body of the last sent message. This isn't foolproof
and sending several messages quickly can make it fail, but it's less
annoying than before. The correct solution is still to fix the server.
In the case of slack I still recommend using the irc gateway instead.
|
|
|
|
| |
Nothing interesting.
|
|
|
|
| |
Also applies to hipchat.
|
|
|
|
|
|
|
|
|
| |
Fixes crashes when a topic is unset and strip_html is set to always.
Turns out that the strip_html() function does a strcpy at the end which
may write a single null byte over the null byte of the empty string, and
if it's not in writable memory, that blows up.
Thanks to iamthemcmaster / mcm for pointing this out
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes trac ticket 1265 - see the comments on that ticket for reasons on
why personal tokens and not the usual oauth flow. TL;DR hipchat doesn't
allow third party apps to own oauth client secrets. Instead, those are
generated when the "addon" is "installed" which requires a flow that is
either impossible or too awkward to use in bitlbee.
So, after giving up on the right way and telling the users to manage
tokens the ugly way, what's left to do is easy, just a few tweaks in the
sasl blob and short-circuit most of the actual oauth stuff. I didn't
even bother changing the service struct from google. It's not used.
This also updates the gtalk SASL X-OAUTH2 code to use GStrings instead of
juggling with malloc/strlen/strcpy, and simplifies a bit the way
GStrings are used in the equivalent SASL PLAIN code.
|
|
|
|
|
| |
As far as I can see this isn't remotely exploitable (and if it were it
would be just DoS of the child process), but i'm still looking into it
|
|
|
|
|
|
|
|
| |
This will make bitlbee tell the user about the requirement for oauth
when the server actually announces support for oauth. If the server does
not announce oauth support bitlbee will tell the user it doesn't support
any of the schemes provided by the server.
These messages were reversed before.
|
|
|
|
|
|
|
| |
These only reflect on what arch/cpu bitlbee was built, not on which
it is running. This makes the Debian package unreproducible.
See e.g.
https://tests.reproducible-builds.org/rb-pkg/testing/i386/bitlbee.html
|
|
|
|
|
|
|
|
|
| |
Basically the same thing as github PR #55, which fixes trac bug 415,
but this one conditionalized that behavior and uses the API introduced a
few commits ago.
I didn't think too much about the setting name and i'm open to changing
it to anything else
|
| |
|
| |
|
|
|
|
|
|
| |
So if someone has several connections with several clients to a chat,
they won't appear as leaving from the chat until they leave from the
last client.
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This prevents them from being stored or copied to other clients when
carbons are enabled.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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".
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
|
|
| |
- Add gmail_notifications_limit hidden setting, set to 5 by default.
- Don't show "snippets" in email notifications. Not very useful and they
make the whole thing seem too spammy
- Show sender name instead of your own email
- Default values for empty subject / sender
|
| |
|
|
|
|
|
|
|
|
| |
- Improve handling of "unknown 'from'"
- Try a bit harder to detect the source of the message, and fall back to
messages sent from a fake temporary user.
- Fix receiving topic when it was set by someone who left the room.
- Add jabber_get_bare_jid() utility function
|
|
|
|
|
| |
When user set's away lower xmpp presence priority by 5 as most clients do, new
priority won't go below zero though.
|
|
|
|
|
|
|
|
|
|
| |
CID 18634: 'Logically dead code' in jabber_get_info
CID 18638: 'Dereference after null check' in oauth2_access_token_done
CID 18691: 'Copy into fixed size buffer' in bee_irc_user_new
CID 20274: Leak in bee_irc_chat_invite
CID 20297, CID 20283: Leaks in crypt_main
Some the base64 leaks there weren't detected, needs modeling.
|
|
|
|
|
|
|
|
| |
This is enough to log in with their usernames, make 'chat add' based
groupchat joins slightly more smooth, and see mention names as nicks.
All the MUC list stuff is left out intentionally since that's not as
stable as I wish.
|