| Commit message (Collapse) | Author | Age | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of always putting users passwords in XML files, allow site
admins to configure a different authentication method to integrate
authentication with other systems.
This doesn't add any authentication backends yet, merely the
scaffolding. Notably:
- Password checking and loading/removing from storage has been
decoupled. A new auth_check_pass function is used to check passwords.
It does check against the configured storage first, but will handle
the authentication backends as well. The XML storage merely signals
that a user's password should be checked using an authentication
backend.
- If unknown-to-bitlbee users identify using an authentication backend,
they are automatically registered.
- If an authentication backend is used, that fact is stored in the XML
file, the password is not. Passwords are also stored unencrypted in
this case, as the password used to encrypt them can change underneath
us.
- configure and Makefile changes for the backend objects
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Used uncrustify, with the configuration file in ./doc/uncrustify.cfg
Commit author set to "Indent <please@skip.me>" so that it's easier to
skip while doing git blame.
|
| |
|
|
|
|
| |
It has been broken for a very long time and nobody cared about it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
release.
Too bad r1000 for BitlBee is going to be this boring. :-( Flexo in #bitlbee
suggested an ASCII cake for r1000, I'll go for this instead:
{{{
+ o + o
+ o + +
o +
o + + +
+ o o + o
-_-_-_-_-_-_-_,------, o
_-_-_-_-_-_-_-| /\_/\
-_-_-_-_-_-_-~|__( ^ .^) + +
_-_-_-_-_-_-_-"" ""
+ o o + o
+ +
o o o o +
o +
+ + o o +
}}}
http://evilzone.org/creative-arts/nyan-cat-ascii/
|
|
|
|
|
| |
this month. :-(
|
| |
|
| |
|
| |
|
|
|
|
|
| |
ways it's not BitlBee and I'm tired of getting libpurple-related bug reports.
|
|
|
|
|
| |
old by now.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
enter the password using the /OPER command (which will not echo to the
screen and/or logs).
It's a fairly ugly hack but the improved password security is worth it
IMHO.
|
| |
|
| |
|
|\
| |
| |
| |
| |
| | |
Not 100% sure about the OpenSSL merge, should double check that but I'm
currently offline.
|
| |
| |
| |
| |
| | |
into the executable.
|
| |
| |
| |
| |
| | |
sense of the word, more in a way that core files don't have to include otr.h.
|
| | |
|
|\ \
| |/
|/|
| |
| | |
and parts I want to/have to redo (because of ui-fix).
|
| |\ |
|
| |\ \ |
|
| |\ \ \ |
|
| |\ \ \ \ |
|
| |\ \ \ \ \ |
|
| |\ \ \ \ \ \ |
|
| | | | | | | | |
|
| |\ \ \ \ \ \ \ |
|
| |\ \ \ \ \ \ \ \ |
|
| | | | | | | | | | |
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
directory. This should fix compatibility with the Skype module (together
with some changes there).
|
|\ \ \ \ \ \ \ \ \ \
| | |_|_|_|_|_|_|_|/
| |/| | | | | | | | |
|
| | |_|_|_|_|_|_|/
| |/| | | | | | | |
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
IPC master.
|
|\ \ \ \ \ \ \ \ \ |
|
| |\| | | | | | | | |
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
build files in there. I need this to properly make Debian package variants
(i.e. libpurple and native).
|
|\ \ \ \ \ \ \ \ \ \
| | |/ / / / / / / /
| |/| | | | | | | | |
|
| |/ / / / / / / /
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
MSN Messenger for everyone.
|