Bug 24398

Summary:	Don't trust id attribute on incoming <message/>s
Product:	Telepathy	Reporter:	Will Thompson <will>
Component:	gabble	Assignee:	Telepathy bugs list <telepathy-bugs>
Status:	RESOLVED FIXED	QA Contact:	Telepathy bugs list <telepathy-bugs>
Severity:	normal
Priority:	medium
Version:	unspecified
Hardware:	Other
OS:	All
URL:	http://git.collabora.co.uk/?p=user/wjt/telepathy-gabble-wjt.git;a=shortlog;h=refs/heads/message-tokens
Whiteboard:
i915 platform:		i915 features:

Description Will Thompson 2009-10-08 10:22:16 UTC

Gabble makes unique IDs for messages it sends (using libuuid if available, or a good-enough approximation if not), and uses them as the id attribute. This lets a UI reliably match up failing delivery reports to the original message, if it wants to: the message id is exposed as the 'message-token' header field on the Messages interface.

We currently expose the 'id' attribute on incoming messages as message-token too, but we should not: we cannot guarantee that the other client produces globally-unique ids. Notably, Google Talk uses incrementing integers...

Comment 1 Will Thompson 2009-10-09 03:54:10 UTC

Fixed in my message-tokens branch.

Comment 2 Simon McVittie 2009-10-12 04:45:25 UTC

Sad face, but ++.

I wrongly thought that UUIDs were RECOMMENDED as ids, in which case we could have probably got away with the following hack: if the id has the syntax of a UUID, assume that it is one.

However, no particular statement is made about the use of UUIDs for id in the RFC (I was confused by the deferred XEP-0201, which says clients MUST use UUIDs for thread IDs).

Comment 3 Simon McVittie 2009-10-16 07:54:14 UTC

Fixed in 0.8.6, fixed-but-not-released in 0.9.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.