GNOME Bugzilla – Bug 663177
tpf-persona.vala:792: Failed to parse new birthday string 'Sat 01 Jan 2011'
Last modified: 2012-04-30 13:40:52 UTC
Upon viewing a contact with Empathy, the following message is printed to the console: tpf-persona.vala:792: Failed to parse new birthday string 'Sat 01 Jan 2011' Any idea what's going wrong?
Looks like Telepathy's passing an invalid BDAY vCard field to libfolks. BDAY is defined as ISO 8601 in the vCard specification and XEP 0054, so Telepathy is incorrect here. What protocol was the contact on? (i.e. Which Telepathy connection manager was providing the contact information?)
Assuming this comes from Gabble (XMPP), I suspect it's just being passed through from a bad vCard provided by the server. Gabble simply copies the data from the vCard it's provided with without doing any parsing. A debug log, with XMPP stanzas would show what we're getting from the server (search for BDAY). I don't think it's wrong for Tp to pass the data it's given, even if that data would seem to be nonsense, if the data claims to be spec compliant. Someone has to parse it and generate a warning that it's nonsense, and I think it should be the last thing in the chain.
(In reply to comment #2) > I don't think it's wrong for Tp to pass the data it's given, even if that data > would seem to be nonsense, if the data claims to be spec compliant. Someone has > to parse it and generate a warning that it's nonsense, and I think it should be > the last thing in the chain. I disagree. Given that there are lots of applications which use Telepathy (and which should theoretically be doing interesting things with vCard data), I think that making them all implement date parsing code is a bad idea. Quite apart from the security implications of passing them unvalidated data off the network, the code duplication (and potential duplication of translation efforts for the warning strings) would be rather pointless. If the code doesn't land in Gabble, I think it should at least go in tp-glib so that we end up with a single, secure implementation.
Gabble is not going to parse this date correctly, we can't just attempt to parse arbitrary dates, anything not in ISO 8601 is just bad data. GLib already has code to read ISO 8601 dates (and I've asked for #662060 for GDateTime specific support). Security concerns should be referred here IMO. It's worth noting that Telepathy CMs do not contain translated strings, nor is there capability to return such an in the vCard. telepathy-glib also does not contain translated strings. If anything, this would be better in a library like Folks, which lots of clients will use.
(In reply to comment #4) > Gabble is not going to parse this date correctly, we can't just attempt to > parse arbitrary dates, anything not in ISO 8601 is just bad data. > > GLib already has code to read ISO 8601 dates (and I've asked for #662060 for > GDateTime specific support). Security concerns should be referred here IMO. Right. > It's worth noting that Telepathy CMs do not contain translated strings, nor is > there capability to return such an in the vCard. telepathy-glib also does not > contain translated strings. If anything, this would be better in a library like > Folks, which lots of clients will use. I guess it would be fine for a warning string to not be translated, since it's only ever going to end up in .xsession-errors. I still think this warning should go in tp-glib rather than folks.
So, Guillaume went ahead and changed the warning() to a debug() in folks anyway in bug #675155, thus ending the discussion. I still think tp-glib shouldn’t be passing on invalid vCard data, though. *** This bug has been marked as a duplicate of bug 675155 ***
(In reply to comment #6) > So, Guillaume went ahead and changed the warning() to a debug() in folks anyway > in bug #675155, thus ending the discussion. I still think tp-glib shouldn’t be > passing on invalid vCard data, though. I opened https://bugs.freedesktop.org/show_bug.cgi?id=49300 summarising my position about this.