| Commit message (Collapse) | Author | Age | Lines |
|---|
| |
|
|
|
|
|
|
| |
warn_unused_result on write() is particularly annoying. You can't just
add (void) to ignore it due to gcc bug 66425.
I replaced some of those with fwrite() and used a variable marked with
the G_GNUC_UNUSED attribute for the writes from signal handlers.
|
| |
|
|
|
|
|
| |
The room names in 'chat list' were missing the server part.
Jabber is the only prpl which implements this method as far as I can
see, and it's needed to get the full name.
|
| | |
|
| |
|
|
|
| |
Some structs still have xml in their name but meh, at least that's not
visible to the user.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Turns out he already implemented pretty much the same thing in the
parson branch... last year.
The differences between the two approaches are subtle (there aren't too
many ways to do this, some lines are the exact same thing) but I decided
I like his version better, so this mostly reverts a handful of my
changes while keeping others. The main advantage of his approach is that
no fake protocols are registered, no actual prpl functions are called,
and the missing prpl is a singleton constant.
New things compared to the implementation in the other branch:
- The explain_unknown_protocol() function.
- Fixed named chatrooms throwing a warning and losing the "account"
setting when saving. See changes in irc_im.c
- Fixed the "server" setting dropping when saving. See account.c
Differences with my previous implementation:
- Accounts with missing protocols don't autoconnect
- 'account list' marks them as "(missing!)"
|
| |
|
|
| |
Which is -Werror'd in debian builds
|
| | |
|
| |
|
|
|
|
| |
RIP
The previous commit already handled the part of telling users.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of failing to load the config, a fake prpl is created to load
the account, keep its settings, and refuse to log in with a helpful
error message.
Also added a new explain_unknown_protocol() function which returns text
which attempts to explain why a protocol is missing, handling several
typical cases, including the future removal of several dead libpurple
plugins.
That message is shown when logging in to a loaded account with a missing
protocol and when adding a new one with 'account add', with the
difference that the latter doesn't leave a placeholder fake account.
|
| |
|
|
|
|
| |
This adds a prpl_options_t enum with flags, which mostly just brings
OPT_PROTO_{NO_PASSWORD,PASSWORD_OPTIONAL} from libpurple as
PRPL_OPT_{NO_PASSWORD,PASSWORD_OPTIONAL}
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This means cancelling transfers on logout to avoid crashes, keeping
track of timeouts, reffing and unreffing the xfers, listening to the
callbacks from UI and purple more carefully and using the correct
functions to free the correct things at the correct moments.
Originally intended to fix a crash triggered when the dcc stall timeout
kicks in after the account is offline, which is apparently very frequent
with telegram (it sends file transfers while fetching history, and
randomly disconnects a while later).
Trying to fix that meant opening a can of worms, but after three days of
work on this bug I'm pretty sure I've finished dealing with the
resulting mess and tested all the typical edge cases.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Because our purple module is all about hacks, adding more can't hurt.
There's a string comparison for "Enter a Conference Server". It's
gettexted in the source but in practice it isn't affected by locale
(bitlbee disables localization).
Worst case, if this stops working, it will open an input request like it
did before this commit. It also does that in purple's jabber if you
don't provide a server parameter.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Which happens when moving from non-purple to purple.
Fixes trac ticket 1269
Since "oscar" doesn't exist in purple, the old code called
register_protocol() to associate oscar with prpl-aim, which meant that
aim accounts migrated seamlessly to purple but icq accounts broke
silently, throwing incorrect password errors.
Now the oscar protocol is special-cased to return prpl-aim or prpl-icq
depending on the first character of the username, which is the same
thing the built-in oscar protocol does.
|
| | |
|
| |
|
|
| |
Also applies to hipchat.
|
| |
|
|
|
| |
I found myself copypasting this to jabber. Might as well make it part of
the API.
|
| |
|
|
|
|
|
|
|
| |
bee_chat_list_finish is still available as a deprecated function but it
will be removed before the next stable release
It has never been part of any release, just keeping it for a while for
the sake of being polite to the users of the discord plugin who may be
using the experimental chat list branch.
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two issues here:
1. SIPE called in_progress(FALSE) immediately (which decreases refcount),
before purple_roomlist_get_list() could return (which would normally
increase refcount). The first refcount decrease steals it from the prpl,
and bad things happen.
Added an initialized flag to only do that decrease after it was
increased first. This is similar to how pidgin sets a 'dialog' attribute
after the purple_roomlist_get_list() call, and skips the unref if it's
not set.
2. The code assumed that NULL return value means room listing not
supported. That's not quite true, so now it checks in the prpl info to
see if roomlist_get_list is defined.
Also, made purple_roomlist_data more private.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The outermost entities object only contains the url of the compat tweet,
the one linking to /i/web/status/[...]
The inner entities object, inside the "extended_tweet", is the one that
contains the quoted tweet url that we're supposed to replace.
But expand_entities() assumed that the quoted_status object would be
next to entities, which doesn't apply in the case of extended tweets.
So now it gets an extra parameter to look for entities.
|
| |
|
|
|
|
|
| |
Like funyahoo++, which has online and offline statuses, but bitlbee's
purple filters those out, resulting in an empty list, and boom.
It's ugly enough that I think I'll add a workaround to the plugin too.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Follow up to a3019499665384a3dcbbc11016d256e6d4dcd26c (which actually
made things worse than before for this particular case - found it by
bisecting)
This affected skypeweb and hangouts, maybe others.
Sometimes serv_join_chat() results in a call chain like this
(outermost frame first)
1. purple_chat_join
2. serv_join_chat
3. (the join_chat function of the prpl)
4. serv_got_joined_chat
5. purple_conversation_new
6. prplcb_conv_new
The last one tries to find a struct groupchat by name (that's the code
from the referenced commit). If it doesn't exist, it creates a new one.
This usually isn't an issue because the 4th step is done asynchronously,
and a groupchat is created at the end of purple_chat_join. If it's not,
you end up with two groupchats, which can lead to other nasty issues.
This moves the creation of the groupchat right before serv_join_chat().
That way, it always exists even if the conversation is created
immediately.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Twitter streams send newlines to indicate that they are alive. The
twitter_http_stream() function processes those and sets the ponged
flag so that the whole connection doesn't timeout.
That function is used to handle both user stream and filter stream.
If the user stream is dead (not sending whitespace) but the filter
stream isn't, the latter keeps the connection alive while the main
twitter channel is completely dead.
This commit only sets the ponged flag for the user stream. This has
the side effect of not detecting if the filter stream dies - but that
didn't work before, anyway. In the future the whole stream connection
management should be revamped - for example stream disconnections
shouldn't take the whole account down, especially not filter streams.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Documentation over here:
https://dev.twitter.com/overview/api/upcoming-changes-to-tweets
This is already live in twitter, can be tested by including an
attachment from twitter web and then fill 140 characters.
Should be sanely backwards compatible with twitter clones - i'd expect
them to ignore the tweet_mode=extended parameter in REST queries, and
just not deliver extended_tweet objects / full_text strings at all.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several protocols can provide a list of existing chatrooms that a user
is able join. This is crucial for the usage of several protocols, most
notably Purple and Facebook.
Plugins wishing to support this extended functionality must implement
the new prpl->chat_list() function. This implemented function will in
most cases send a remote request for the list of chatrooms. Once the
list of chatrooms is obtained, a bee_chat_info_t GSList must be created
and assigned to the im_connection->chatlist field. Then a call to the
bee_chat_list_finish() is needed to display the list to the user.
The chat list is maintained entirely by the plugin, so it is important
to ensure all pointers related to the chat list remain valid until the
chat list is set to NULL. This list is used internally by bitlbee to
calculate indexes, which then allows the user to join a chat with an
index, rather than some random identifier. It also important to ensure
the list is properly freed whenever it is updated, or when the account
is disconnect via the prpl->logout() function.
On the user interface side of things, the 'chat list' subcommand was
recommissioned. For a user to list the existing chat rooms:
chat list <account id>
Afterwards a user can join a chatroom in the list with its index. This
extends the functionality of the 'chat add' subcommand by adding in
support for the exclamation point operator to denote an index.
chat add <account id> !<index> [channel]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Fixes trac ticket 1254
Kinda dirty but better than keeping it broken.
|
| |
|
|
|
| |
This only happens if the user has used / forced daemon mode (for
example, when debugging with BITLBEE_DEBUG=1)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows adding bitlbee-specific purple plugins in a directory
controlled by the user who starts bitlbee (as it can be defined in
bitlbee.conf, PluginDir).
Pidgin and finch have something similar allowing users to place plugins
in ~/.purple/plugins:
path = g_build_filename(purple_user_dir(), "plugins", NULL);
The direct equivalent would be to use our config dir, but i'd rather not
put executable modules there.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
This will allow a user to type "like" in Twitter channels,
reflecting recent changes to Twitter itself. Note that the
API hasn't changed.
|
| |
|
|
|
|
| |
Plugins which use autotools will install a .la file along with the .so
file. Both of these files are loadable as plugins, so the plugin ends
up being loaded twice. To prevent this, only load the .so module.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As of now, bitlbee will load any plugin regardless of the ABI it was
built against. This is really problematic when structures or symbols
are changed within bitlbee. This often leads to the plugin not loading
or the plugin acting in an undefined way. Typically a simple rebuild of
the plugin will resolve such issues, but many users have no idea that
this is required after they have updated bitlbee.
Furthermore, it is often times impossible to determine the version of
a plugin, without relying on the package manager of the system. This is
quite a problem when users are reporting bugs for external plugins, and
they have no idea what version of the plugin they are running. This is
also an opportunity to provide additional metadata for each plugin that
can then be displayed to the user.
Solving these issues is done by adding a new required function to each
plugin. The init_plugin_info() function must now be implemented along
with the init_plugin() function. This function then returns a static
structure, which retains all of the metadata for the plugin. Then this
is used by bitlbee to check the ABI version and provide information to
the user.
The introduction of the new function is required as bitlbee needs to
obtain the ABI version before calling init_plugin().
The boiler-plate implementation of init_plugin_info():
#ifdef BITLBEE_ABI_VERSION_CODE
struct plugin_info *init_plugin_info(void)
{
static struct plugin_info info = {
BITLBEE_ABI_VERSION_CODE, /* Required */
"plugin-name", /* Required */
"1.3.3.7", /* Required */
"A short description of the plugin", /* Optional */
"First Last <alias@domain.tld>", /* Optional */
"http://www.domain.tld" /* Optional */
};
return &info;
}
#endif
The example wraps the function declaration in an if block for backwards
compatibility with older bitlbee versions.
Displaying the plugin metadata is done via the newly added "plugins"
command, which simply dumps formatted data to the root channel.
|
| |
|
|
|
|
| |
Fixes trac ticket 1255, which points out that a strip_html() call down
there may modify the passed string, and some purple plugins may pass
read-only string data to it.
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
The previous one seemed to imply a "file not found" error, which is
misleading.
|
| |
|
|
|
|
|
| |
Just freeing the list on logout and when removing items from them.
Also remove the "checking mutes" debug which is disproportionately noisy
compared to the rest of the protocol.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| | |
Twitter doesn't error if you mute the same user multiple times.
Also, correct signedness of the stringified user ids. bitlbee keeps them as
unsigned even if the json library uses signed for integers...
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
| |
In certain situations, e.g. when working with pregenerated
configurations, it is useful to be able lock down accounts so they
cannot be deleted and authentication information (user, password,
server) cannot be changed.
We mark such sensitive settings with ACC_SET_LOCKABLE and will refuse to
change them if the account is locked by setting the ACC_FLAG_LOCKED
flag.
This flag is stored in the xml files as account attribute locked="true".
|
| |
|
|
|
|
|
|
|
| |
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
|
| | |
|
