[Bug 1097366] Re: Pidgin client digest-uri checks fail with multiple virtual hosts
Richard Hansen
1097366 at bugs.launchpad.net
Fri Oct 25 21:00:19 UTC 2013
My PPA (<https://launchpad.net/~a7x/+archive/bug1097366>) now has
patched ejabberd packages for precise, quantal, raring, saucy, and
trusty. They should finish building in a few hours.
--
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1097366
Title:
Pidgin client digest-uri checks fail with multiple virtual hosts
Status in “ejabberd” package in Ubuntu:
Confirmed
Status in “ejabberd” source package in Precise:
Confirmed
Status in “ejabberd” source package in Quantal:
Confirmed
Status in “ejabberd” source package in Raring:
Confirmed
Bug description:
[Impact]
Bug #1048634 fixes some Pidgin digest-uri check failures, but not all.
There is another bug where Pidgin users won't be able to log in if
there are multiple virtual hosts and the hostnames in the SRV records
for the two XMPP hosts are different.
This particular bug has already been fixed upstream:
https://github.com/processone/ejabberd/commit/2bf8125abfeec9e1176ea7ab9793b8947f9c09b6
as part of this upstream bug report:
https://support.process-one.net/browse/EJAB-1578
The upstream commit is available in ejabberd 2.1.12 and later.
This bug is known to affect precise, quantal, raring, and saucy.
[Test Case]
The fix to this bug involves changes to the ejabberd configuration
file, so a single test case can't be used to both demonstrate the
broken behavior of an unpatched ejabberd and the proper behavior of a
patched ejabberd. Thus, this section describes two cases:
* A test case to verify the broken behavior of an unpatched version
of ejabberd.
* A test case to verify the proper behavior of a patched version of
ejabberd.
These test cases make the following assumptions:
* The instance of ejabberd will provide service to both
example.com and example.net.
* The ejabberd server and Pidgin client are both running on the same
system.
* You have the ability to configure DNS records for the
example.com. and example.net. zones (perhaps by running a DNS
resolver, the Pidgin client, and the ejabberd server on the same
system and configuring /etc/resolv.conf on that system to use
127.0.0.1).
The test cases can be trivially modified to suit different
circumstances.
These are the settings common to both test cases:
1. Set the 'hosts' setting in /etc/ejabberd/ejabberd.cfg:
{hosts, ["example.com", "example.net"]}.
2. Add the following records to DNS:
_xmpp-server._tcp.example.com. 86400 IN SRV 0 0 5269 xmpp.example.com.
_xmpp-client._tcp.example.com. 86400 IN SRV 0 0 5222 xmpp.example.com.
xmpp.example.com. 86400 IN A 127.0.0.1
_xmpp-server._tcp.example.net. 86400 IN SRV 0 0 5269 xmpp.example.net.
_xmpp-client._tcp.example.net. 86400 IN SRV 0 0 5222 xmpp.example.net.
xmpp.example.net. 86400 IN CNAME xmpp.example.com.
Notice the 127.0.0.1 in the above records. The use of this IP
address means that the Pidgin client must be running on the same
system as the ejabberd server (as mentioned in the assumptions
above). Feel free to change the IP address to something more
convenient if desired.
3. Create two ejabberd users:
- example at example.com
- example at example.net
4. Configure Pidgin with both XMPP accounts
Case 1: Without the patch applied:
1. Set the 'fqdn' setting in /etc/ejabberd/ejabberd.cfg:
{fqdn, "xmpp.example.com"}.
2. Start Pidgin and enable both accounts.
Expected results: Only the example at example.com account can log in;
the example at example.net account fails ejabberd's digest-uri checking
logic.
Case 2: With the patch applied:
1. Set the 'fqdn' setting in /etc/ejabberd/ejabberd.cfg:
{fqdn, ["xmpp.example.com", "xmpp.example.net"]}.
Note: This extended list-based syntax is not supported unless
the patch is applied. If this syntax is used on an unpatched
ejabberd server, no Pidgin users will be able to log in.
2. Start Pidgin and enable both accounts.
Expected results: Both accounts can successfully log in.
[Regression Potential]
This change extends the syntax of the ejabberd config file. Existing
configuration files should remain compatible, but if there was a
regression, it might manifest itself as an inability to correctly
parse previously-valid configuration files.
The change also affects the digest-uri checking logic. A regression
may result in users being unable to log in or overly permissive
checks.
The patch has been in the upstream repository since 2012-06-27, and I
have been running it locally for almost as long without any problems.
No subsequent changes to the affected region of code have been made
upstream since this patch.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ejabberd/+bug/1097366/+subscriptions
More information about the Ubuntu-sponsors
mailing list