After enabling SCRAM password hashing and SSL in ejabberd, XMLRPC ejabberdctl commands were resulting in errors like this:
W(<0.2623.0>:ejabberd_xmlrpc:328) : Error -118
A problem '{error,invalid_account_data}' occurred executing the command user_sessions_info with arguments
It seems that this because ejabberd_commands was using a different authentication check than everything else, which wasn't properly taking account for potential password hashing. (Note I'm not really sure what AccountPassMD5 is doing, but it seems to be different than the ejabberd_auth_internal's SCRAM hasing.)
As explained in Erlang/OTP git log:
eldap: Remove calls to undocumented asn1rt* functions.
We are about to remove the old asn1rt* modules, so we must remove
the calls that eldap make to them. Since the calls are just a
sanity check, we can just remove the calls. Just doing the decode
will do roughly the same tests and generate similar exceptions.
Disable:
- export ciphers - broken by design, 40 and 56 bit encryption
- low encryption ciphers - 56 and 64 bit encryption
- SSLv2 ciphers - some ciphers using MD5 MAC
SSL 2.0 is not used anywhere as it has security problems. Disable it
unconditionally both in server and client mode. This does _not_
disable support for SSL 2.0 compatible client hello which still will
be accepted in the server mode.
Before this change, when request with repeat rid was received any waiting
request was aborted (but only after next request was delivered). With this
change, only request with identical rid are aborted and this is done
immediately
This changes what happens to request received with out of order rid,
previously response to such request was send immediately, and client was
free to submit another request, which triggered item-not-found if it was
delivered before request with missing rid.
This change make us wait for sending response to out of order request until
request with missing rid arrives. It also queues all outgoing data before
that condition is meet.
Badlop