What is your stance on keeping backwards compatibility a) in general, and b) in this case?
Well, a) is always nice to have.
In this particular case we are dealing with a security sensitive aspect. As the Security Warning in RFC 6121 § 2.1.6 states
Security Warning: Traditionally, a roster push included no ‘from’
address, with the result that all roster pushes were sent
implicitly from the bare JID of the account itself. However, this
specification allows entities other than the user’s server to
maintain roster information, which means that a roster push might
include a ‘from’ address other than the bare JID of the user’s
account. Therefore, the client MUST check the ‘from’ address to
verify that the sender of the roster push is authorized to update
the roster. If the client receives a roster push from an
unauthorized entity, it MUST NOT process the pushed data; in
addition, the client can either return a stanza error of <service-
unavailable/> error or refuse to return a stanza error at all (the
latter behavior overrides a MUST-level requirement from
[XMPP-CORE] for the purpose of preventing a presence leak).
So you only want to accept roster pushes from authorized entities. In most XMPP setups, this is the client’s server, although it was so designed that your roster could be hosted by a different entity (I’m not aware of any implementation of this).
Funny enough, this Security Warning contradicts RFC 6121 § 2.1.6 2.
A receiving client MUST ignore the stanza unless it has no ‘from’
attribute (i.e., implicitly from the bare JID of the user’s
account) or it has a ‘from’ attribute whose value matches the
user’s bare JID user@domainpart.
I could however image that we add a whitelist mechanism to Smack’s roster API, where authorized entities can be configured.
I’m not sure how helpful this whitelist API would be for Cisco’s Jabber server, which, if I understood correctly, sends roster pushes from the full JID of the current account. This means that you would need to whitelist that full JID always after resource binding. Appears to be a little cumbersome.
In the end, the only correct solution is to fix Cisco Jabber server.