Open mgorny opened 1 year ago
Is this with the new paramiko 3.2?
yep, since paramiko 3.2
Is this with the new paramiko 3.2?
Yes, since 162213fa1a4551bd955134c97ca5276a5f29e907 to be more precise.
Is this with the new paramiko 3.2?
Yes, since 162213f to be more precise.
:+1:, I've forwarded to bitprophet for his action.
Yea this is an oversight in the test shuffling (though I'd thought I made the support path loader backwards compatible, maybe it's not in use in this sub-suite at all...). Should be a quick fix.
Note that GSSAPI almost certainly doesn't work at all under the new experimental APIs in this release, but this breakage is orthogonal as the gssapi test suites didn't get updated to look at those anyways.
That was it, those suites were hardcoding the paths, I just updated them to use the helper. I don't have kerberos kit locally so can't actually run the tests - please let us know how they look now @mgorny !
Well, for a start I've accidentally tested with Python 3.12 and noticed another problem:
FAILED tests/test_kex_gss.py::GSSKexTest::test_gsskex_and_auth - AttributeError: 'GSSKexTest' object has no attribute 'assert_'. Did you mean: 'assertIn'?
IIRC assert_
was deprecated long ago for assertTrue
.
On Python 3.11, that one test is fixed while the two other fail with:
FAILED tests/test_ssh_gss.py::GSSAuthTest::test_auth_trickledown - paramiko.ssh_exception.SSHException: encountered RSA key, expected OPENSSH key
FAILED tests/test_ssh_gss.py::GSSAuthTest::test_gss_auth - paramiko.ssh_exception.AuthenticationException: Authentication failed: transport shut down or saw EOF
FWICS these two are broken since 7700c7e033652ed98c0c385b0da936f12b35aabf.
A lot of the tests are still incredibly old even by vanilla unittest standards; I've been updating things as I go to be pytest style asserts (not a fan of junit-style asserts and we are using pytest to run tests nowadays) so that's my recommendation here too.
Not entirely sure what's up with those other two errors though. I'd entertain a patch if you figure it out though. Thanks for poking the GSSAPI stuff! (I'd also be curious how you're getting gssapi running locally enough to execute the tests; I'm in a bad middle area where I cannot prove GSSAPI works, but also don't really want to just rip its support back out again...something we can run in our CI stack might be ideal)
To be honest, I'm not doing anything special — I just happen to have gssapi
, k5test
and pyasn1
installed.
Notes to self: I tried getting gssapi
on my dev env (NixOS 22.05) but even with krb5.dev
installed (ie krb5-config
exists, works) I can't seem to install gssapi
1.8.x or 1.7.x. Similar-ish symptoms to this issue which implies krb5-config is still emitting incorrect parameters or something (wouldn't surprise me on NixOS which is a bit special).
Also! I had totally forgotten we do have gssapi support in our CI. It's just commented out because it's broken 😢 Sadly, I just re-checked and it is still (slightly) broken. But it's there, and if fixed (and, if not part of that breakage, also fixed re: mgorny's findings) I'd be fine merging a PR to uncomment it in CI again.
Unfortunately, as was recognized in this issue, krb5-config is too limited to take the multiple outputs nixpkgs provides, into account. I therefore went and submitted a PR to gssapi to take pkg-config information into account, if any exists.
PTAL https://github.com/pythongssapi/python-gssapi/pull/320.
I guess they weren't updated when the key was moved into
_support/
.