If user1 is able to break my communications with user2 (by fooling my
client with incorrect capabilities) without requiring of my approval I
would call this a security issue.
Yes I know, but personally I dont think its a true security issue, I
would only truely call it a security issue if it allowed a third party
to compromise your machine, which it doesnt, and its very easily
mitigated as I detailed.
issue) is if you are going to create a long lived cache (i.e. on disk or
such like) that before you decide on your definative value to cache
generically (i.e. client/ver) that you use the results from several
different JIDs (e.g. 3 or 5 or something) and compare them, if they are
There could be a problem with filling the cache with incorrect
information about not-released-yet versions of some client. After the
actual release users will be surprised. (Though this issue arises only
if the cache is persistent.)
This issue only arises if developers do not correctly implement CAPS and
dont update the version number when they release the final version (if
the caps info might have changed), this is simply a bug that the
developers would need to deal with, not anything wrong with CAPS.
all the same it should be pretty safe to create a generic cache for that
tuple of client and version, if they dont all agree then you can then
consider those results and potensially poisoned or buggy and cache using
the jid/client/version tuple instead, simple and easy, no need to get
all het up about it.
Looks not 'simple and easy'...
Can you explain why not exactly? As it seems simple and easy enough to me.
Richard
