| Commit message (Collapse) | Author | Age | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Just a trivial wrapper over irc_rootmsg(), but will help me to slightly
reduce the ugliness of an unavoidably ugly hack for libpurple.
|
|
|
|
| |
More fixing warnings.
|
|
|
|
| |
Also turn them into asserts because that's what it really does.
|
|
|
|
| |
I mean sure you could use messenger reviver but..
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Most of them related to channel joins, one of them related to my recent
certificate pool path fix.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Not really a leak, but I want valgrind to be happy because valgrind is
nice to me. I love you valgrind <3
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Nothing else needed, i think. No need for multiline replies, cap-notify,
sasl reauthentication just works, and the authentication layer is always
available.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Because i'm going to use it elsewhere.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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!
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
Because they are very very easily lost. Changing to PRIVMSG
|
|
|
|
|
| |
Just to ensure the whole thing gets written, since this can't be async
for obvious reasons.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
I'm sure that some day the tests will be useful, not just an annoyance.
Some day.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
XEP-0184 section 5.3 says those shouldn't be sent over MUCs, but some
misbehaving clients do anyway, resulting in 'forbidden' errors
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
"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.
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
| |
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()
|
|
|
|
| |
More cleanup.
|
|
|
|
| |
Just cleanup.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
It was added a while ago.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|