© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
35a32c5
(Get the code!)
I've reproduced this locally by sending a malformed SHA1C value via an msn_object avatar. It's not as trivial to reproduce using the telepathy/papyon framework since SHA1C values are normally ignored in all cases, but still processed. Yes, you read that correctly.
Going along with upstream's methodology that the checksum is redundant and all that is necessary is the data (for which the hash is properly compared and handled), I've written a patch to silently ignore malformed checksums and log a warning when doing so. Other than that, I guess we'll have to wait for upstream to decide how they want to properly handle this field, since as of now it's just a waste of clock cycles as far as I can tell.
My patch right now only addresses the base 64 decoding issue in SHA1C parsing that everyone seems to be having, and there is more to take care of as far as DoSing with unexpected data goes. For example, a ParseError is raised when there is no xml data, but that again crashes the conversation. KeyErrors are raised when certain attributes are missing from the xml, which too crash the conversation.
For upstream see bug #24138.