| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Hopefully we will never have another 0.8 release.
|
|
|
|
|
|
Previously, Gabble would erroneously process google:jingleinfo updates
sent by anybody, rather than only paying attention to those sent by the
user's server. This may theoretically allow an attacker to trick Gabble
into relaying streamed media through a server of the attacker's
choosing, enabling them to intercept, obstruct or modify the user's
audio and video calls.
This patch addresses this flaw, following the same pattern as the
corresponding check in the roster code.
Note that even without this flaw, no security guarantees on media in
calls can be provided in the presence of malicious network admins or
insecure networks: an attacker who can eavesdrop the network traffic
still has the ability to intercept the content of the call, as the media
is transmitted unencrypted.
Fixes: <https://bugs.freedesktop.org/show_bug.cgi?id=34048>
Signed-off-by: Will Thompson <will.thompson@collabora.co.uk>
Reviewed-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
|
|
Previously we did not accept any non-ASCII domains, which meant we
dropped perfectly valid messages from perfectly valid contacts. :o
This patch accepts any non-ASCII characters in domains. This is still
not right — for instance, spaces in domains are properly rejected, but
non-breaking spaces are improperly accepted — but it's better than no
validation at all (which was my previous attempt at fixing this) and
avoids us dropping messages.
(Taken from cba01d1 in Wocky, without the test case that commit added.)
|
|
|
|
|
|
|
|
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
|
|
Unblocking is actually not tested anywhere, so this serves as a simple
smoke-test for that, as well as testing that unblock followed by
remove-from-stored works when the latter is queued.
|
|
|
|
We want to ensure that clients which don't understand the 'deny' list
can remove contacts from other lists without accidentally unblocking
them. The only problematic case is 'stored': currently, the XMPP-level
response to removing someone from 'stored' is sending a roster update
removing them from the roster entirely. Since their blocked-ness is
stored on the roster, ...
So instead, when we would like to remove a blocked contact from the
roster, we instead cancel inbound and/or outbound subscriptions. This
has the effect of the server changing their subscription to 'none', at
which point they disappear from 'stored' (because on Google Talk we
hide subscription='none', ask≠'subscribe' contacts from stored).
There are two code paths for editing the roster, depending on whether we
have an edit in flight or not. The latter case is reasonably
straightforward. For the former case, we can be applying multiple edits
at once, so this patch moves the modification of the Google Roster state
to before the modification of the subscription state, to ensure that
queued modifications to the contact's blocked-ness have been processed
before we consider whether to handle removal specially.
Fixes fd.o#20597 (Blocked contacts get removed if they are removed from
stored)
|
|
|
|
|
|
This matches the functions to add and remove contacts from the roster
entirely, and will help avoid code duplication shortly...
|
|
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
|
|
|
|
It seems that the server doesn't send you the queue's contents when you
disable it, so we have to explicitly flush it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fix fdo #27694
|
|
Since this is a stable branch, we're unlikely to fix uses of deprecated
functions, so we shouldn't warn about them.
Reviewed-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
|
|
There's no group change reason that corresponds exactly to the room
being full, but Busy seems like a reasonable approximation. It's
certainly better than None.
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
|
|
|
|
|
|
|
|
|
|
|
|
tp_g_hash_table_update
Features have to be copied as well as hash table assume their are owning them.
Should fix fdo #27131.
|
|
|
|
It has been deprecated.
|
|
|
|
We forgot it for some reason.
|
|
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
|
|
|
|
and detectable
Our implementation only works for Linux so far, so we need to be able to
avoid advertising credential-passing on e.g. Darwin.
|
|
credentials-passing
That assumption will now fail on non-Linux.
|
|
Backport of commit 5a7757ca53b83ee6904354f02a4caa0ade0a11eb from 0.9.x.
|
|
|
|
|
|
Not only did two different C source files hardcode that Gabble is a PC,
but so did the test suite. This is why the tests passed when I only
changed one of the hardcoded C strings; I don't know why I thought they
passed when I fixed that, but... they didn't. :)
|
|
|
|
|
|
|
|
Previously, if you compiled with --enable-is-a-phone, Gabble would still
use "pc" when calculating its own hash. Bzzt.
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
|
|
In the HTTP response for a Google relay session there is a
'magic_cookie' value which contains a binary 'magic' string. This
string, contained in the entire response, was being sent to the
debug log. If Empathy's debug window was open, this would cause
that string to be sent over DBus. Since the string wasn't valid
UTF-8, DBus dropped Gabble from the session bus. This patch escapes
the binary data in that output.
|
