| Summary: | wocky tests were not updated for SCRAM-SHA-1 support | ||
|---|---|---|---|
| Product: | Wocky | Reporter: | diane |
| Component: | General | Assignee: | Telepathy bugs list <telepathy-bugs> |
| Status: | NEW --- | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | git master | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Update tests to expect SCRAM-SHA-1 as the default test mechansim.
SCRAM-SHA-1 returns BADPROT for a bad password match |
||
Created attachment 124883 [details] [review] Update tests to expect SCRAM-SHA-1 as the default test mechansim. This doesn't fix the problems with some SASL test failures. Also I wonder if there should be tests to handle how auth negotiation proceeds if SCRAM-SHA-1 isn't available. Created attachment 124899 [details] [review] SCRAM-SHA-1 returns BADPROT for a bad password match I went looking for the error message: sasl error (-5): SASL(-5): bad protocol / cancel: StoredKey mismatch and found it here: http://sources.debian.net/src/cyrus-sasl2/2.1.26.dfsg1-15/plugins/scram.c/#L1346 My solution was to catch the SASL_BADPROT case and treat it as an invalid password. Though BADPROT can happen for other reasons that are not currently being tested. (Like sending challenge responses too early) With the these two patches I don't seem to be getting authentication errors now. Strangely, I cannot reproduce this issue. All unit tests pass for me, both with libsasl2 support enabled and disabled Made a chroot and found the difference. I had kerberos setup and when I have libsasl2-modules-gssapi-mit installed I get the sasl test failure. (In reply to diane from comment #4) > Made a chroot and found the difference. > > I had kerberos setup and when I have libsasl2-modules-gssapi-mit installed I > get the sasl test failure. Also that implies my patch is wrong, and the right thing is to figure out how to pick which SASL digest mechanism to use, Also it might be good to try testing SCRAM-SHA-1 if its available as it is considered better than DIGEST-MD5 |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
A number of wocky-connector-tests fail because the digest method used by wocky is SCRAM-SHA-1, and the tests assume DIGEST-MD5. for example: /connector/tls+auth/insecure/no-tlsplain/tls/digest: ** wocky-connector-test:ERROR:wocky-connector-test.c:3577:run_test: assertion failed (test->result.mech == test->result.used_mech): ("DIGEST-MD5" == "SCRAM-SHA-1") FAIL In addition with SCRAM-SHA-1 enabled there are also errors like this: /connector/problem/sasl/bad-pass: sasl error (-5): SASL(-5): bad protocol / cancel: StoredKey mismatch ** ERROR:wocky-test-sasl-auth-server.c:504:check_sasl_return: code should not be reached FAIL Removing this block from wocky-auth-registry.c if (wocky_auth_registry_has_mechanism (mechanisms, WOCKY_AUTH_MECH_SASL_SCRAM_SHA_1)) { if (out_handler != NULL) { /* XXX: check for username and password here? */ DEBUG ("Choosing SCRAM-SHA-1 as auth mechanism"); *out_handler = WOCKY_AUTH_HANDLER (wocky_sasl_scram_new ( server, username, password)); } return TRUE; } allows both the DIGEST-MD5 and SASL bad user tests to pass. Obviously changing the wocky-connector-tests.c to assuming SCRAM-SHA-1 makes the non-sasl tests pass. I'm currently stumped for how SASL is going wrong.