failed to parse supported auth schemes: The operation identifier is not valid.

[GeorgeTTD]

Otherwise, to report a bug, please fill out the reproduction steps
(below) and delete these introductory paragraphs. Thanks!

Reproduction steps

Hello I am trying to connect to a private GitHub repo using a PAT token as described in these two issues.

#libgit2/libgit2sharp#2048
#libgit2/pygit2#1225

Expected behaviour

Authenticated access

Actual behaviour

failed to parse supported auth schemes: The operation identifier is not valid.

Version of libgit2 (release number or SHA1)

not 100% sure but using latest stable nuget release of .net native binaries.

Operating system(s) tested

Windows

It seems from investigations on the pygit2 issue that it is related too WinHTTP however I am not sure what any of this does.

[ethomson]

I really need a repro case here. Even if it's .NET code that speaks to LibGit2Sharp.

[GeorgeTTD]

Hi @ethomson,

there is a repro case on this issue in the python flavour of this lib

same with this LibGit2Sharp issue

Seems to be issue only affecting windows as far as I am aware, may be wrong on that though.

[lrm29]

@ethomson We've had some reports of this error (on Windows) which were a bit baffling, so I sent them a quickly patched DLL to print out the headers of the request (would be nice to hook that up to git_trace like already done on linux). They use a proxy and are using a GitHub organisation, and I see that one of the linked issues to this seems to have this setup too.

They sent back (with some redactions for their details):

HTTP/1.1 401 Unauthorized
Date: Fri, 08 Mar 2024 09:02:35 GMT
Content-Length: 21
Content-Type: text/plain; charset=UTF-8
Server: GitHub-Babel/3.0
WWW-Authenticate: Basic realm="GitHub" enterprise_hint="mygroup" domain_hint="myhint"
Content-Security-Policy: default-src 'none'; sandbox
X-Frame-Options: DENY
X-GitHub-Request-Id: <some id>

I'm suspecting at the moment that WinHttpQueryAuthSchemes is rejecting the www-authenticate header due to the enterprise_hint/domain_hint parameters. This is not an API I'm familiar with at all unfortunately.

Note that this is different to other ways this can be hit, which so far I've seen when using an expired token on a GitLab server that didn't return a www-authenticate header (shrug!). GitHub doesn't have that problem though (get a 403 if the token permissions are insufficient or eventually the error "too many redirects or authentication replays" for an expired token - I know we should stop before that...).

If you can think of anything I could try here let me know.

[ethomson]

Innnnnteresting. I'm really interested in getting rid of WinHTTP so that we have a single HTTP transport stack.

Does the version of libgit2 you're using support USE_HTTPS=Schannel?

If you give them a build with USE_HTTPS=Schannel then it will use our HTTP stack but with the built-in Windows crypto APIs (hopefully exactly like WinHTTP drives them).

[lrm29]

In newer releases of our product, yes, but not the product version they're currently using. I'll get them the latest release of our product plus a patched libgit2 DLL to use schannel.

I can attempt to switch over to schannel for our product - I think we have enough servers to test it against and we could reach out to users I know with more interesting setups than just public GitHub.

Edit: Slight shame it's a compile time option. Does it affect the ABI? If an existing customer found a problem with the schannel implementation could I give them the libgit2 compiled with WinHTTP as a workaround?

[ethomson]

I bet that I can backport schannel to an older version if it's a need for you. The API surface for the HTTPS stack hasn't changed that much, I don't think.

No affect on the API or ABI. But it is a compile time option. I mean, it could be a runtime configurable option — I'd have to give it a little thought if this was something that was super valuable to you.

[lrm29]

I saw the pull request for schannel - as the plan is to switch to that as the default I don't think a runtime option to switch between implementations would be that useful. We can work with users that hit edge cases to resolve them as needed. I'll update this thread with the results of using schannel. I think back porting won't be necessary and most affected users could just upgrade our product. Or if it is useful for us it's something I should attempt rather than you waste time on given there have been few complaints. I'm curious if there is any way around this using the WinHTTP APIs though. Not use it and parse www-authenticate another way? Probably not worth going down that route.

…

-------- Original Message --------

On 13 Mar 2024, 15:15, Edward Thomson wrote: I bet that I can backport schannel to an older version if it's a need for you. The API surface for the HTTPS stack hasn't changed that much, I don't think. No affect on the API or ABI. But it is a compile time option. I mean, it could be a runtime configurable option — I'd have to give it a little thought if this was something that was super valuable to you. — Reply to this email directly, [view it on GitHub](#6624 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAC4LIBV3I3OWDVNIZPWTHLYYBUSRAVCNFSM6AAAAAA3T3RS3OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJUGYZTOMZXGE). You are receiving this because you commented.Message ID: ***@***.***>

[lrm29]

Innnnnteresting. I'm really interested in getting rid of WinHTTP so that we have a single HTTP transport stack.

Does the version of libgit2 you're using support USE_HTTPS=Schannel?

If you give them a build with USE_HTTPS=Schannel then it will use our HTTP stack but with the built-in Windows crypto APIs (hopefully exactly like WinHTTP drives them).

Good news, I gave the customer libgit2 built with Schannel and it worked for them. I'm going to switch over to it soon. Perhaps you can close this issue - solution is to switch to Schannel?