Activity log for bug #1097366

Date Who What changed Old value New value Message
2013-01-08 17:47:04 Richard Hansen bug added bug
2013-01-08 18:11:25 Richard Hansen attachment added debdiff for precise https://bugs.launchpad.net/ubuntu/+source/ejabberd/+bug/1097366/+attachment/3477236/+files/debdiff-precise.patch
2013-01-08 18:11:33 Richard Hansen tags patch
2013-01-08 18:12:23 Richard Hansen attachment added upstream patch https://bugs.launchpad.net/ubuntu/+source/ejabberd/+bug/1097366/+attachment/3477243/+files/ejab-1578.patch
2013-01-08 20:19:18 Ubuntu Foundations Team Bug Bot bug added subscriber Ubuntu Sponsors Team
2013-02-05 16:43:28 Richard Hansen description 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. For example, suppose ejabberd.cnf contains: {hosts, ["foo.example", "bar.example"]}. {fqdn, "xmpp.foo.example"}. and DNS lookups return the following: dig -t SRV _xmpp-client._tcp.foo.example. -> xmpp.foo.example:5222 dig -t SRV _xmpp-client._tcp.bar.example. -> xmpp.bar.example:5222 dig -t A xmpp.foo.example. -> 192.0.2.123 dig -t A xmpp.bar.example. -> 192.0.2.123 then Pidgin clients with *@bar.example Jabber IDs are NOT able to log in. The digest-uri sent by these clients – "xmpp/xmpp.bar.example" – doesn't pass ejabberd's digest-uri checking logic. Pidgin clients with *@foo.example Jabber IDs do work, however. This particular bug has already been fixed upstream: https://github.com/processone/ejabberd/commit/2bf8125abfeec9e1176ea7ab9793b8947f9c09b6 [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 not yet available in an official upstream release. Presumably the patch will be included in ejabberd 2.1.12 when it is released. [Test Case] 1. Put these lines in /etc/ejabberd/ejabberd.cfg: {hosts, ["example.com", "example.net"]}. {fqdn, "example.com"}. 2. Configure DNS with the following example records: _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. The above example records assume the ejabberd server and Pidgin client are both running on the same system (notice the 127.0.0.1). Change as appropriate. 3. Create two ejabberd users: - example@example.com - example@example.net 4. Configure Pidgin with both XMPP accounts With the patch, both accounts can successfully log in. Without the patch, only the example@example.com account can log in because the example@example.net account will fail ejabberd's digest-uri checking logic. [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.
2013-02-05 16:46:55 Richard Hansen 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 not yet available in an official upstream release. Presumably the patch will be included in ejabberd 2.1.12 when it is released. [Test Case] 1. Put these lines in /etc/ejabberd/ejabberd.cfg: {hosts, ["example.com", "example.net"]}. {fqdn, "example.com"}. 2. Configure DNS with the following example records: _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. The above example records assume the ejabberd server and Pidgin client are both running on the same system (notice the 127.0.0.1). Change as appropriate. 3. Create two ejabberd users: - example@example.com - example@example.net 4. Configure Pidgin with both XMPP accounts With the patch, both accounts can successfully log in. Without the patch, only the example@example.com account can log in because the example@example.net account will fail ejabberd's digest-uri checking logic. [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. [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 not yet available in an official upstream release. Presumably the patch will be included in ejabberd 2.1.12 when it is released. This bug is known to affect precise, quantal, and raring. [Test Case] 1. Put these lines in /etc/ejabberd/ejabberd.cfg:     {hosts, ["example.com", "example.net"]}.     {fqdn, "example.com"}. 2. Configure DNS with the following example records:     _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.    The above example records assume the ejabberd server and Pidgin client are both running on the same system (notice the 127.0.0.1). Change as appropriate. 3. Create two ejabberd users:    - example@example.com    - example@example.net 4. Configure Pidgin with both XMPP accounts With the patch, both accounts can successfully log in. Without the patch, only the example@example.com account can log in because the example@example.net account will fail ejabberd's digest-uri checking logic. [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.
2013-02-05 16:47:20 Richard Hansen tags patch patch precise quantal raring
2013-02-05 19:30:15 Mathieu Trudel-Lapierre nominated for series Ubuntu Precise
2013-02-05 19:30:15 Mathieu Trudel-Lapierre bug task added ejabberd (Ubuntu Precise)
2013-02-05 19:30:15 Mathieu Trudel-Lapierre nominated for series Ubuntu Quantal
2013-02-05 19:30:15 Mathieu Trudel-Lapierre bug task added ejabberd (Ubuntu Quantal)
2013-02-05 19:30:15 Mathieu Trudel-Lapierre nominated for series Ubuntu Raring
2013-02-05 19:30:15 Mathieu Trudel-Lapierre bug task added ejabberd (Ubuntu Raring)
2013-02-13 13:19:40 Scott Moser ejabberd (Ubuntu Raring): importance Undecided Medium
2013-02-13 13:19:40 Scott Moser ejabberd (Ubuntu Raring): status New Incomplete
2013-02-14 18:56:42 Sebastien Bacher removed subscriber Ubuntu Sponsors Team
2013-05-05 17:59:03 Launchpad Janitor ejabberd (Ubuntu Precise): status New Confirmed
2013-05-05 17:59:03 Launchpad Janitor ejabberd (Ubuntu Quantal): status New Confirmed
2013-10-25 19:34:14 Richard Hansen 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 not yet available in an official upstream release. Presumably the patch will be included in ejabberd 2.1.12 when it is released. This bug is known to affect precise, quantal, and raring. [Test Case] 1. Put these lines in /etc/ejabberd/ejabberd.cfg:     {hosts, ["example.com", "example.net"]}.     {fqdn, "example.com"}. 2. Configure DNS with the following example records:     _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.    The above example records assume the ejabberd server and Pidgin client are both running on the same system (notice the 127.0.0.1). Change as appropriate. 3. Create two ejabberd users:    - example@example.com    - example@example.net 4. Configure Pidgin with both XMPP accounts With the patch, both accounts can successfully log in. Without the patch, only the example@example.com account can log in because the example@example.net account will fail ejabberd's digest-uri checking logic. [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. [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, and raring. [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@example.com - example@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, "example.com"}. 2. Start Pidgin and enable both accounts. Expected results: Only the example@example.com account can log in; the example@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.
2013-10-25 19:36:00 Richard Hansen 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, and raring. [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@example.com - example@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, "example.com"}. 2. Start Pidgin and enable both accounts. Expected results: Only the example@example.com account can log in; the example@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. [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@example.com        - example@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, "example.com"}.   2. Start Pidgin and enable both accounts.   Expected results: Only the example@example.com account can log in;   the example@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.
2013-10-25 19:36:16 Richard Hansen tags patch precise quantal raring patch precise quantal raring saucy
2013-10-25 19:39:39 Richard Hansen 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@example.com        - example@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, "example.com"}.   2. Start Pidgin and enable both accounts.   Expected results: Only the example@example.com account can log in;   the example@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. [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@example.com        - example@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@example.com account can log in;   the example@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.
2013-10-25 19:41:24 Richard Hansen attachment added ejabberd.cfg for test case 1 https://bugs.launchpad.net/ubuntu/+source/ejabberd/+bug/1097366/+attachment/3891443/+files/ejabberd_case1.cfg
2013-10-25 19:42:16 Richard Hansen attachment added ejabberd.cfg for test case 2 https://bugs.launchpad.net/ubuntu/+source/ejabberd/+bug/1097366/+attachment/3891444/+files/ejabberd_case2.cfg
2013-10-25 19:53:59 Richard Hansen ejabberd (Ubuntu): status Incomplete Confirmed
2013-10-25 19:54:02 Richard Hansen ejabberd (Ubuntu Raring): status Incomplete Confirmed
2013-10-25 19:54:22 Richard Hansen bug added subscriber Ubuntu Sponsors Team
2013-10-25 19:55:03 Richard Hansen bug added subscriber Mathieu Trudel-Lapierre
2013-11-12 16:26:07 Mathieu Trudel-Lapierre nominated for series Ubuntu Saucy
2013-11-12 16:26:07 Mathieu Trudel-Lapierre bug task added ejabberd (Ubuntu Saucy)
2013-11-12 16:26:07 Mathieu Trudel-Lapierre nominated for series Ubuntu Trusty
2013-11-12 16:26:07 Mathieu Trudel-Lapierre bug task added ejabberd (Ubuntu Trusty)
2013-11-12 16:26:18 Mathieu Trudel-Lapierre ejabberd (Ubuntu Saucy): status New Confirmed
2013-11-12 16:26:23 Mathieu Trudel-Lapierre ejabberd (Ubuntu Saucy): importance Undecided Medium
2013-11-12 16:26:26 Mathieu Trudel-Lapierre ejabberd (Ubuntu Quantal): importance Undecided Medium
2013-11-12 16:26:28 Mathieu Trudel-Lapierre ejabberd (Ubuntu Precise): importance Undecided Medium
2013-11-12 16:26:32 Mathieu Trudel-Lapierre ejabberd (Ubuntu Trusty): status Confirmed In Progress
2013-11-12 16:26:35 Mathieu Trudel-Lapierre ejabberd (Ubuntu Trusty): assignee Mathieu Trudel-Lapierre (mathieu-tl)
2013-11-12 16:34:50 Launchpad Janitor branch linked lp:ubuntu/trusty-proposed/ejabberd
2013-11-12 16:53:08 Launchpad Janitor ejabberd (Ubuntu Trusty): status In Progress Fix Released
2013-11-12 17:05:03 Launchpad Janitor branch linked lp:ubuntu/ejabberd
2013-11-15 23:35:32 Brian Murray ejabberd (Ubuntu Precise): status Confirmed In Progress
2013-11-15 23:35:35 Brian Murray ejabberd (Ubuntu Precise): assignee Brian Murray (brian-murray)
2013-11-15 23:35:37 Brian Murray removed subscriber Ubuntu Sponsors Team
2013-11-18 19:20:57 Stéphane Graber ejabberd (Ubuntu Precise): status In Progress Fix Committed
2013-11-18 19:21:02 Stéphane Graber bug added subscriber Ubuntu Stable Release Updates Team
2013-11-18 19:21:04 Stéphane Graber bug added subscriber SRU Verification
2013-11-18 19:21:07 Stéphane Graber tags patch precise quantal raring saucy patch precise quantal raring saucy verification-needed
2013-11-18 19:36:04 Stéphane Graber ejabberd (Ubuntu Saucy): status Confirmed Fix Committed
2013-11-18 19:46:05 Launchpad Janitor branch linked lp:ubuntu/saucy-proposed/ejabberd
2013-11-21 08:15:29 Richard Hansen tags patch precise quantal raring saucy verification-needed patch precise quantal raring saucy verification-done
2013-11-21 17:18:12 Brian Murray tags patch precise quantal raring saucy verification-done patch precise quantal raring saucy verification-done-precise verification-needed
2013-11-26 19:23:37 Launchpad Janitor ejabberd (Ubuntu Precise): status Fix Committed Fix Released
2013-11-26 19:52:22 Launchpad Janitor branch linked lp:ubuntu/precise-updates/ejabberd
2014-11-03 21:01:23 Mathew Hodson tags patch precise quantal raring saucy verification-done-precise verification-needed patch precise quantal raring saucy verification-done-precise verification-needed-saucy
2014-11-03 21:02:19 Mathew Hodson branch linked lp:ubuntu/precise-proposed/ejabberd
2014-11-03 21:02:30 Mathew Hodson branch unlinked lp:ubuntu/precise-updates/ejabberd
2014-12-03 10:02:57 Rolf Leggewie ejabberd (Ubuntu Quantal): status Confirmed Won't Fix
2014-12-05 05:29:17 Rolf Leggewie ejabberd (Ubuntu Raring): status Confirmed Won't Fix
2014-12-05 06:41:58 Rolf Leggewie ejabberd (Ubuntu Saucy): status Fix Committed Won't Fix