Self-tests fail againt krb5 1.18.2 #220
Comments
|
This is the debug out of one the failed tests: debugkdc log: |
|
For Fedora, I believe this is just waiting for krb5-1.18.2-10.fc32 to land in stable. But that's a downstream issue and I don't know why it would affect AltLinux. |
|
I've rechecked F32 with |
|
@frozencemetery, hi, any news? |
|
No, I've been working on higher priority things. Any word from the Alt Linux maintainers on why this update breaks? |
|
This is not related to distro, but krb5-1.18.2. These errors are reproduced in CI of #219 |
|
@iv-m, @mastersin, could you check, please? |
|
Perhaps qualify_shortname="" would help.. |
Unfortunately, No, it's not. #220 (comment) |
|
Obviously, this is somehow related to DNS. |
|
Same failure for me when trying to build nixos packages against either krb5 1.18 or 1.18.2. |
|
It was pointed out(bisecting) that the breaking these tests commit is krb5/krb5@03ecb09 @greghudson, can you advise something, please? |
|
I believe this test case is trying something similar to the following operation in upstream krb5: except with host/master instead of "user". The client says to the KDC, "I am host/master as proved by my header TGT. Here is a request to myself, with S4U2Self padata requesting a ticket client of host/master". The KDC obliges, issuing a host/master -> host/master ticket. An old KDC that didn't implement S4U2Self would issue the same ticket, because the S4U2Self request is (unusually) asking for the same ticket client as the one the KDC would have used normally. At gc_via_tkt.c:258 we check for this kind of response and (incorrectly, in this case) deduce that the KDC does not support S4U2Self. This check is described in [MS-SFU] 3.1.5.1.2, although that section now also suggests checking the padata in the response. The test used to pass because the answer used to be served from cache. By an accident of the earlier tests, there used to be an entry for server This is a weird S4U2Self edge case and seems like a confused test case. It does point to a bug in upstream, although not necessarily a super important one on its own merits. The failure is not related to DNS. |
Interesting, that's new; but it'll only work for PA_S4U_X509_USER as there is no returned padata with PA_FOR_USER. |
|
Oh, I see. [MS-SFU] isn't suggesting the padata check as a way to detect if the KDC supports S4U2Self, but as a way to detect if it specifically supports the more secure variant (PA_S4U_X509_USER). |
|
I filed https://krbdev.mit.edu/rt/Ticket/Display.html?id=8958 for the upstream issue. |
I'm in favor of option 4. Options 2 and 5 might not work if the requested name gets canonicalized, although this doesn't currently happen with Windows (or MIT) KDC but it could in theory according to this very section in MS-SFU. |
|
Although canonicalization would require PA_S4U_X509_USER, which should be covered by option 4 anyway. |
Option 4 is "Detect the edge case before making the request, and return an error". Did you mean option 3, "Suppress the check if PA_S4U_X509_USER padata is present in the reply"? |
|
Yes sorry, by option 4 i meant 3 (and by 5 i meant 4). |
|
@greghudson, thank you for the clear explanation! |
These tests relied on rickety behavior and caching. Redo them to actually test impersonation. Fixes problems with krb5 >= 1.18.2. Resolves: pythongssapi#220 Signed-off-by: Robbie Harwood <[email protected]>
These tests relied on rickety behavior and caching. Redo them to actually test impersonation. Fixes problems with krb5 >= 1.18.2. Resolves: pythongssapi#220 Signed-off-by: Robbie Harwood <[email protected]>
These tests relied on rickety behavior and caching. Redo them to actually test impersonation. Fixes problems with krb5 >= 1.18.2. Resolves: pythongssapi#220 Signed-off-by: Robbie Harwood <[email protected]>
These tests relied on rickety behavior and caching. Redo them to actually test impersonation. Fixes problems with krb5 >= 1.18.2. Resolves: pythongssapi#220 Signed-off-by: Robbie Harwood <[email protected]>
What went wrong?
MIT krb5 1.18.2 recently landed on ALTLinux. This break python-gssapi self-tests.
As I see the same happens on F32:
https://github.com/pythongssapi/python-gssapi/pull/219/checks?check_run_id=864476020
build log
The text was updated successfully, but these errors were encountered: