[Bug] Presence probe for local user leaks information.

Hi,

in my opinion there is a bug (at least an inconsistency) in presence probes code for local users in OF.

I am using my custom integration scenario. I populate users' rosters via userservice plugin.

Let's have a following setting:

• OpenFire server 3.9.3.
• Two local users, Alice, Eve.
• User Alice has empty roster.
• User Eve has 1 item in roster, Alice, presence type=BOTH.
• PrivacyLists are empty (not used here).
  

When presence session is created for Eve (she sends initial presence), she receives Alice's presence state from the OF even if she is not allowed to. Any subsequent Alice's status updates are not routed to Eve (what is correct), but initial status probe is performed and succeeds.

RFC 6121 specifies behavior for presence probes in section "4.3.2.  Server Processing of Inbound Presence Probe".

In particular: "If the contact account does not exist or the user's bare JID is

       in the contact's roster with a subscription state other than

       "From", "From + Pending Out", or "Both" (as explained under

       Appendix A), then the contact's server SHOULD return a presence

       stanza of type "unsubscribed" in response to the presence probe".

So in order to be consistent in both local and remote user scenarios, OF (in my opinion) should follow this RFC specification and Eve should not be able to obtain presence information of Alice.

In my opinion, problem is here:

• PresenceUpdateHandler.initSession(), line calling presenceManager.probePresence(session.getAddress(), item.getJid());
• PresenceManagerImpl.probePresence(JID prober, JID probee). In local case (server.isLocal(probee)) it does not perform check of the probee's roster and hapilly provides presence information to prober. Although routine for handling presence probe packets, PresenceManagerImpl.handleProbe(Presence packet), performs aforementioned roster check.

My suggestion how to fix this is to call PresenceManagerImpl.canProbePresence(JID prober, String probee) inside PresenceManagerImpl.probePresence and check if the probe should be permitted.

Temporary workaround is to use PrivacyLists and whitelist presence updates only for users in probee's roster, block everything not in the whitelist.

Thanks for considering my suggestion.