-
-
Notifications
You must be signed in to change notification settings - Fork 6.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Out of memory is returned from command line for gssapi auth with missing krb5 ticket #3726
Comments
It was changed in #1975 Following diff fixed that but I am not sure whether it is right solution
Just test323 failed for me but it seems to be unrelated to spnego or gssapi |
Ref: https://github.com/curl/curl/blob/curl-7_64_1/lib/vauth/spnego_gssapi.c#L150-L174 It's returned OOM there for a long time, not sure why it's different now. |
The call to That is why prior to my changes it switched to basic as negotiate was never getting initiated in your case.
Or this can be seen as intended behaviour, as curl is set to use negotiate (only) in this case? Besides: curl/lib/vauth/spnego_gssapi.c Line 124 in 6c60355
There is no real "out of memory", just an error from the negotiate API. |
This bug is triggered by 6c60355. I agree that |
Maybe I don't fully understand the problem, but is this really a bug? --negotiate is not documented to fall back to Basic in https://curl.haxx.se/docs/manpage.html#--negotiate. |
I also cannot understand why curl should fall back to basic if it is directed to use negotiate authentication. |
I am not sure what you are talking about. In which version does |
I assume before #1975: 7.64.0 How does this behave with e.g. NTLM? Is there also a fallback to basic? I have never tried this. |
Sorry, I somehow missed this expectation from the original report. It sounds incorrect to me and I do not think that You can see that the expected verbose output from the original report, which I believe was captured by an unaffected version of curl, does not contain any @lslebodn Could you please clarify your expectations? |
curl never "falls back" to another authentication method. It picks one and goes with that. If that fails to work/authenticate, it returns error. (I would suggest anything else is a bug.) |
It worked in
Which is the same as with --basic
I tried to use
|
Anyway, returning
I am fine if you do not want to support that and it "worked" just by a change in older version. |
What about |
I cannot see any difference between
and
They all behave the same as with
As I already mention; I am fine with implement fall-back myself in the test. |
I think the only bug here is the As stated in the docs, "...and use the most secure one the remote site claims to support" |
I am trying to explain you that it is not the same. There is no
True, except with
The question is whether curl should send the request without authentication or not. This behavior has been consistent at least since |
So if |
@dhoelzl Nope. |
Thanks, that was the little tidbit I had totally missed/forgot... |
This change that curl fails on GSSAPI requires to start "if-ing" our test code that worked before for all Fedora and RHEL releases we test, with or without Kerberos authentication. Please consider at least providing a backward compatible solution, so we do not need to start workarounding the introduced behavior change. |
Someone will have to do something... |
…mory; return CURLE_RECV_ERROR in case of other errors
…mory; return CURLE_RECV_ERROR in case of other errors
There is pull request #3849 to change curl's behavior to be compatible with previous releases up to 7.64.0: If |
Great so let's do that. Is there any reason why we shouldn't? |
Pushing now. Thanks for review! |
I left a comment on the change itself. The fix is incomplete:
|
@nicowilliams What exactly do you mean by causes failure? curl will not authenticate you with |
@kdudka I mean that if
At the very least the error and verbose messages are not very useful. The HTTP response code was In our case we're using TLS (via HTTPS) to authenticate the server using PKIX certificates, and we want HTTP/Negotiate for authenticating the user to the service when feasible -- if a service has no Kerberos credentials, then we want curl to continue. Perhaps we ought to be using |
@kdudka also, perhaps you should only treat |
@nicowilliams I agree that the behavior of |
I did this
Ensure there is not any valid krb5 ticket
Try to use gssapi authentication for some site.
It will obviously fail but it should continue with basic auth
I expected the following
curl/libcurl version
operating system
The text was updated successfully, but these errors were encountered: