[Bug 33404] Move caps hash stuff to Wocky

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=33404

Will Thompson <will.thompson at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Status Whiteboard|                            |r-

--- Comment #10 from Will Thompson <will.thompson at collabora.co.uk> 2011-03-10 09:13:14 PST ---
(In reply to comment #9)
> There is a test for testing sorting dataforms and not only are the forms are in
> a different order but the values are jumbled up too. I don't see how a test
> that just jumbles up value ordering would give any more?

Okay, reasonable.

> (In reply to comment #8)
> > Also how does this deal with forms with fields of types other than text-single
> > or text-multi?
> 
> Well, it won't include the field in the hash to SHA. I've included a debug
> message now.

I don't think this is right, I'm afraid. The XEP says:

  • For each field other than FORM_TYPE:
      ‣ Append the value of the "var" attribute, followed by the '<'
        character.
      ‣ Sort values by the XML character data of the <value/> element.
      ‣ For each <value/> element, append the XML character data,
        followed by the '<' character.

If WockyDataForm's API doesn't make this possible without contortions, we
should make it possible, rather than risking incorrectly calculating the hash
(despite having had all the necessary information at some point).

       field = g_hash_table_lookup (dataform->fields, "FORM_TYPE");
-      g_assert (field != NULL);
+
+      if (field == NULL)
+        continue;

I think this is wrong, too. We should fail to calculate the hash in this
case. Arguably parsing the data form should fail if there's no FORM_TYPE
field, but XEP-0004 doesn't actually mandate that that field exist,
afaict.

I think there should be a test for the cases where a form has no
FORM_TYPE, and where the disco reply contains two forms with the same
FORM_TYPE; in both cases, calculating the hash should fail.

We should not cache the supposed hash negatively, though: otherwise,
malicious contacts could trick us into negatively caching a hash that
some other client is using correctly and legitimately. I think it's
reasonable for Gabble to still use the capabilities, though.

>From jdev@:
> Zash: variations of empty fields isn't specified well iirc
> Zash: eg <field><value/></field> vs <field/> vs no field at all

Might be worth testing the first two variants do something sensible.

+  WockyStanza *  stanza = wocky_stanza_build (WOCKY_STANZA_TYPE_IQ,

What's going on ^^ here?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.