| Commit message (Collapse) | Author | Age | Lines |
|
|
|
|
|
|
|
|
|
|
| |
Unlike json_parser_load_from_data(), g_strndup() will not handle signed
sizes that are negative. This causes the size to overflow to a really
large value, and in turn lead to a segmentation fault.
The solution is simple: calculate the size of the data when the given
size is negative.
This bug was introduced by 0121bae.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Older glib versions didn't consider "$" to be a valid expression, and
threw this error:
Root node followed by invalid character '
(That's supposed to be '%c' with a \0)
Since this is possibly the simplest expression to parse, a g_strcmp0()
can do the job.
Thanks to advcomp2019 for reporting this bug and finding a test case
where this issue is reproducible every time (receiving events of people
joining or leaving in a groupchat)
Also thanks to EionRobb who realized what the bug was three hours ago
(and I didn't listen because I thought the previous bug was the same)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Older json-glib versions had a bug[1] in which the length parameter was
ignored and this error happened if the input was not null-terminated:
JSON data must be UTF-8 encoded
Since these versions are expected to still be around in some distros,
this commit makes a copy with g_strndup() to ensure that it's always
null terminated.
Thanks to advcomp2019 for reporting this bug and finding a test case
where this issue is reproducible every time (receiving events of people
joining or leaving in a groupchat)
[1]: https://bugzilla.gnome.org/show_bug.cgi?id=727755
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Changes made:
- Build and install bitlbee from /tmp
- Disabled the building of the bitlbee documentation
- Moved all build commands to travis.yml (more informative)
- Moved all Travis related scripts to a hidden directory
- Moved the bitlbee build commands to a script
- Only deploy the master branch (excluding pull requests)
- Removed redundant parameters from the bitlbee configure command
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Any call to fb_mqtt_write() can result in an error writing to the
socket, which means fb_mqtt_close() can be called and the mqtt object is
invalidated.
Trying to write priv->tev = 0 at that point is a small invalid write,
but not enough to make it crash. The real problem is fb_mqtt_timeout(),
which adds a 90 second delay after which it *does* crash, often when a
different account already finished logging.
The fix here takes advantage of the cleanup done by fb_mqtt_close() - by
adding the timeout before that call, it will find a nonzero priv->tev
and remove it.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was the only line that assigned anything to priv->wev, and it was
behind an (incorrect) condition that checked if it's nonzero.
That would have replaced priv->wev if the condition was ever true, but
since it wasn't, the only result is potentially delayed writes
(for example, filling the write buffer and only writing the rest a
minute later when pinging the server)
The new condition also checks the return value of fb_mqtt_cb_write(),
which is true if it should continue writing, or false otherwise.
|
|
|
|
|
|
|
|
| |
See https://github.com/travis-ci/travis-ci/issues/1975
Since the addon doesn't handle the job matrix very well, I copied one of
the suggestions from that thread, which does pretty much the same as the
addon but in a place we can control.
|
| |
|
|
|
|
|
|
| |
Control channels never have a room setting, so joining to &facebook and
trying to fbjoin a channel would result in a null pointer dereference in
the next line (FB_ID_TO_STR)
|
|
|
|
|
|
|
|
|
|
|
|
| |
This feature is not yet in any stable bitlbee release, but it's designed
to be backwards compatible:
- Run time: Detects if the "self_messages" global setting exists.
- Build time: sets OPT_SELFMESSAGE to 0 if it doesn't exist.
In other words, if this is built against a bitlbee version that supports
this feature, it will still run in anything 3.4+, and only display these
messages in the newer ones.
|
|
|
|
| |
By not swapping uid with oid, since the latter is always 0.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This adds a setting, group_chat_open, which if set to true, will allow
the plugin to open added channels upon an incoming message.
This also addresses:
- Improper message printing for root commands
- The fbchats command not joining existing channels
|
|
|
|
|
|
|
| |
The thread list is not being properly freed, as elements are left in
the internal list. This ends up causing double frees.
This fixes more than one use of the fbchats command segfaulting.
|
|
|
|
|
|
|
| |
Currently, as soon as a user is invited to a group chat, they are added
to the group chat. In order to ensure the user is actually added, the
plugin should wait for an already handled group chat event for the user
being added.
|
| |
|
|
|
|
| |
And fix s/--libdir/--with-plugindir/
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This resolves:
- extended-description-is-empty
- missing-build-dependency-for-dh-addon
- non-empty-dependency_libs-in-la-file
|
| |
|
|
|
|
|
|
|
|
| |
It was assumed there was always a leading "NULL" byte prepended to each
message. This is not the case, the NULL byte is actually a variable
integer, which is the size for a Thrift string. In order to navigate
directly the JSON data, just read the data as a thrift string in order
to obtain the offset of the JSON data.
|
|
|
|
|
| |
The thrift string functions were not correctly adjusting for compact
and non-compact strings, it was just assumed as one or the other.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Simpler and more verbose version of my other patch which silently
created a new queue - this will show up as a reconnection and should
make it obvious if an infinite loop happens. jgeboski's idea, not mine.
|
|
|
|
|
| |
Just for debugging purposes with users who don't run this with debug
enabled.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was mqtt->rbuf->len previously, the length of the bytearray, which
doesn't make a lot of sense - it resulted in reading 2, 4, 8, 16, 32
bytes and when it reached a high enough number, ssl_read would either:
1. Stop because the socket buffer got empty (the main reason it kinda
worked most of the time), or
2. Continue reading into the next packet
And continuing to read means not just a desync but also that remz - rize
(remaining bytes - read bytes) is negative, or more precisely, a huge
number, since remz is unsigned.
So it gets stuck reading ~2**64 bytes into that buffer, thinking it's a
neverending packet, and that means not getting pongs. So it timeouts.
The fix is trivial - just make it read exactly the amount of bytes it
needs to read (remz), never more than that.
|
| |
|
| |
|
|
|
|
| |
This adds the autogen.sh script to the distribution tarball.
|
|
|
|
|
|
|
|
| |
Fixes issues such as losing messages that include a quote character.
Only escapes the minimum needed to work - control characters,
backslashes and quotes. UTF-8 chars are still valid json, so they are
sent as-is.
|