-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
[release/6.0] Fix compatibility with NTLM authentication to McAfee Web Gateway #66315
Conversation
Tagging subscribers to this area: @dotnet/ncl Issue DetailsBackport of #66305 to release/6.0 /cc @wfurt @filipnavara Customer ImpactTestingRiskIMPORTANT: If this change touches code that ships in a NuGet package, please make certain that you have added any necessary package authoring and gotten it explicitly reviewed.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Thanks for the backport and filling up the servicing template! |
Please check this in or it will miss the 6.0 servicing window. |
We did not do direct checkins for servicing in the past. Did the process changed @mmitche? |
No. I don't mean to direct check-in, just please merge asap. |
merge is commit, right? For example #64252 I did not merge in the past. |
AOT failure is addressed in #66366. |
Looks like runtime-libraries enterprise-linux failed with the same name resolution issue. I actually hit that exact issue a while ago and fixed it by moving from the AzDO Hosted Pool to the 1ES pool: #61001 (comment) It's possible that they got the same restrictions now and that's why it fails. edit: seems it's not consistent, I see some PRs failing in main and some succeeding so might be part of a rollout or something. |
Is it possible there was a yml change that fixed it (eg, to change pools?). Reruns wouldn't pick that up. @wfurt does this pipeline provide coverage of the change here? If so we might want to force a rerun. edit: I see we have coverage of this pipeline in main. I'm going to go ahead and merge this for now. |
The pool change was backported to 6.0 a long time ago with #63014 and I checked it is using the 1ES pool in this PR, so no idea. |
thanks @ericstj. We did not have in-house repro for the issue. The pipeline is somewhat relevant as it provides some guard agains regressions. The main was fixed with #65981. There is still pending issue in core-eng but the changes I made at least make the runtime-libraries enterprise-linux runnable again. |
Terminology is likely leaking from time before we used Git... |
I queued a couple builds to help us understand what's going on with that leg: |
@akoeplinger looks like main does have a different pool name:
vs
@wfurt you made a change here 9174037 |
@ericstj that is expected, servicing branches use the |
Backport of #66305 to release/6.0
/cc @wfurt @filipnavara
Fixes #62136
Customer Impact
This is regression introduced in 6.0 that basically prevents use of HTTP(s) in certain network topologies.
It blocks migration to 6.0 and leaves users broken in cases when the transition was forced.
There are several reports from users who are behind McAfee Web Gateway proxy but it is not 100% if this is only impacted scenario. The users are basically forced to always go through the proxy for security reasons. But since the NTLM implementation has some small differences we fail to authenticate and send out HTTP request. There is no known workaround besides downgrading to 5.0.
#54101 added some extra flags to fix NTLM authentication for macOS but the new setting is not compatible with McAfee WG and had unexpected behavior impact.
Testing
I build custom binary and had two customers to verify it. Our test coverage is weak around enterprise authentication and we don't have McAfee Web Gateway available for testing.
Risk
Risk is moderate. This is finicky area with very low test coverage.
This change basically restores previous flags when connections to HTTP proxy.