-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Restore calls to CreateFatalHandshakeAlertToken on Android #118765
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
Restore calls to CreateFatalHandshakeAlertToken on Android #118765
Conversation
/azp run runtime-extra-platforms |
Azure Pipelines successfully started running 1 pipeline(s). |
Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones |
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.
Pull Request Overview
This PR fixes a regression introduced in PR #117428 that incorrectly assumed Android's SslStream behavior was identical to Linux/OSX regarding custom alert generation. The fix restores proper handshake teardown behavior on Android by setting CanGenerateCustomAlerts = true
and removing an incorrect assertion.
Key changes:
- Restores
CanGenerateCustomAlerts = true
for Android to enable proper handshake teardown - Removes incorrect debug assertion that was causing issues
- Adds explanatory comment about Android's unique handshake requirements
You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.
src/libraries/System.Net.Security/src/System/Net/Security/SslStreamPal.Android.cs
Show resolved
Hide resolved
Affected tests pass now, other CI failures should be unreltaed. |
/ba-g failing test is #118770 and is unrelated |
* Enable smoke tests fixed in #118765 * Fix duplicate include
Fixes #118118
Fixes #117963
Fixes #118350
#117428 Introduced some PAL constants to adjust SslStream behavior with regards to sending custom alerts. The PR assumed that since SslStreamPal.ApplyAlertToken is a no-op (due to no API for creating custom alert being available), the entire SslStream.CreateFatalHandshakeAlertToken would be no-op as well. This was the case on Linux and OSX, but not so on Android.
To avoid a regression in .NET 10, this PR restores the call to CreateFatalHandshakeAlertToken, but ideally, the code should be examined as to why the last call to SslStream.HandshakeInternal is needed (as any internally generated alerts should've been returned as part of the previous call).