Age | Commit message (Collapse) | Author | Files | Lines |
|
Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
|
|
Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
|
|
Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
|
|
Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
|
|
Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
|
|
Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
|
|
|
|
|
|
|
|
Previously, this test sent new mail notification stanzas from some
random JID.
<http://code.google.com/apis/talk/jep_extensions/gmail.html#notifications>
clearly shows that the notifications come from the user's own JID.
Gabble previously ignored the sender of these notifications, but will
begin respecting them when we update our Wocky snapshot to make it
straightforward to do so.
|
|
Gabble correctly does not process roster pushes from contacts other than
our server. However, it does not send a reply back to the IQ, which is
in violation of XMPP Core.
This patch allows the IQ to fall through to the “no handler” code, which
just sends back a generic IQ error. While we could craft a specific
<forbidden/> error, I don't think it's necessary.
|
|
I previously believed that I had added code to WockyPorter such that, if
someone sent us an IQ with no id='' attribute, it would be silently
dropped rather than being handed up to the application. (This would
technically be valid behaviour; RFC3920 §9.2.3 “IQ Semantics” says that
“The 'id' attribute is REQUIRED for IQ stanzas.”
<http://xmpp.org/rfcs/rfc3920.html#stanzas-semantics-iq>)
I mentioned this to Rob, who was horrified, because Gabble's roster code
specifically handles roster pushes lacking an id='' attribute because
this happens in the wild. I checked, and I had apparently imagined that
I had made the above change to WockyPorter.
This patch adds a regression test to check that Gabble correctly
processes roster pushes without an id='' attribute, and doesn't crash
in the process.
|
|
on server type
Previously, when setting the Overwritten_By_Nickname flag on the
FN/NICKNAME VCard field it was done in the per-process array.
As a result, if you signed on with a Gtalk account, FN will be fiven
said flag. If you then sign on with a non-Google account, the FN field
will already have this flag set so both FN and NICKNAME will have it
set, which is wrong.
This is never a problem the other way round because Gtalk doesn't
support the NICKNAME VCard field.
Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
|
|
For consistency.
Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
|
|
Also, fix the name of the other contact info field flag which was
clearly changed at some point before it became undrafted.
Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
|
|
The supported_fields pointer array is now no longer one per process
because it depends on what kind of connection you're on, but it means
we now always free the pointer array!
Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
|
|
|
|
They've moved to fdo now.
Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
|
|
|
|
|
|
|
|
|
|
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
|
|
|
|
|
|
|
|
|
|
|
|
This is a regression test for the bug fixed in the previous commit.
|
|
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>
|
|
|
|
Fixes: <https://bugs.freedesktop.org//show_bug.cgi?id=11291>
Signed-off-by: Will Thompson <will.thompson@collabora.co.uk>
|
|
|
|
Updates a patch from #11291, thanks to Michael Scherer <misc@mandriva.org> for
the original patch.
|
|
|
|
Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
|
|
This was broken in 4d0d2af917188b.
Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
|
|
Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
|
|
These have occurred to me … I don't think they're that important, but I
thought it worth writing them down.
|
|
|
|
WockyPepService throws this back at me when I get disconnected while
requesting the items for a node.
|
|
This is basically symmetrical, but will make handling explicit PEP
queries to our own JID work more reliably when that's readded next.
|
|
|
|
As discussed on <https://bugs.freedesktop.org/show_bug.cgi?id=27693>,
the point of PEP is that you never have to poll for people's latest
location if you advertise the relevant +notify capability. So we
shouldn't do this in response to calls to GetLocations() or
GetContactAttributes().
Fixing <https://bugs.freedesktop.org/show_bug.cgi?id=31218> will
essentially re-add this code...
|
|
The specification says that the attribute should be “omitted from the
result if the contact's location is not known.” But previously Gabble
would fill in an empty dictionary in this case.
Correcting this simplifies the refcounting on the hash table, which
wasn't obviously right before.
|
|
A blanket assertion on the entire dictionary of dictionaries is much
less useful than a succession of increasingly-specific assertions using
our wrappers which print the arguments on failure.
|
|
|
|
Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
|
|
Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
|
|
|