On Mon, Sep 5, 2011 at 5:39 PM, Dave Cridland <[email protected]> wrote: > On Wed Aug 31 06:48:26 2011, Waqas Hussain wrote: >> >> Most protocol attacks are based on unexpected input. Attackers >> wouldn't really care whether the values they send are registered or >> usable in any way, as long as the attack succeeds. I don't think you >> are proposing all caps handling entities ship with a copy of the >> registry and fail on anything not included. > > No, but we could potentially restrict input quite heavily.
Disco extensions remain a sticky point, and I dislike forbidding '/' in identity.name. > Let's say that we add (yet) another attribute to the caps element, > indicating that the "new" restrictions are in place. (These might include > the various restrictions mentioned in this thread). > > Now, when a client sees a caps marked as restricted, it can validate the > disco#info it gets. > > If a client sees two caps strings, one marked as restricted and one not, it > should assume that the caps string is intended to be restricted as proceed > accordingly. That's a fairly interesting idea. More thinking required. > I'm also wondering if it's worth considering optional (and marked) removal > of XEP-0128 in cases where it's not used. > > Of course, it may be simplest just to bite the bullet and switch hash > algorithm - or even change the 'hash' attribute name - because then it'll > get treated as a pre-1.4 caps by the vast majority of entities and > everything will happen right (or at least, no worse than it often does today > anyway). > > I'm gradually leaning toward this, because although it's *quite* violent, > the downside is not impossible. The transition should be smooth. I was initially for fixing the current protocol, and would be for it if we found a good way to do so. > BTW, anyone any idea what happens if you include more than one <c/> in a > presence, in practical terms? I suspect some would pick the first and some the last. That's the two kinds of child-element-scanning logic I've seen in clients. I don't think we can depend on any behavior here. Also, see last discussion about getting rid of order attribute in privacy lists :) >> I know Miranda and Tkabber send software version. Probably many >> others. Can we gather stats on jabber.org for this? > > M-Link cannot capture that data, except by capturing all traffic (which is > inadvisable). Sad. I'd hoped there would be a way to dump the PEP caps table. > I would re-iterate that we still have no burning building. We're getting > closer, though. I don't disagree. That's why I never really pushed for getting this resolved instantly. It's an annoyance, but not a burning building at the moment. > Dave. -- Waqas Hussain
