-
Notifications
You must be signed in to change notification settings - Fork 24.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
Fix issue with finishing handshake in ssl driver #30580
Conversation
This is fixing an issue that has come up in some builds. In some scenarios I see an assertion failure that we are trying to move to application mode when we are not in handshake mode. What I think is happening is that we are in handshake mode and have received the completed handshake message AND an application message. While reading in handshake mode we switch to application mode. However, there is still data to be consumed so we attempt to continue to read in handshake mode. This leads to us attempting to move to application mode again throwing an assertion. This commit fixes this by immediatly exiting the handshake mode read method if we are not longer in handshake mode. Additionally if we swap modes during a read we attempt to read with the new mode to see if there is data that needs to be handled.
Pinging @elastic/es-security |
This might be the core issue causing this build failure (#30013). |
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 left one comment
@@ -113,7 +113,14 @@ public ByteBuffer getNetworkReadBuffer() { | |||
} | |||
|
|||
public void read(InboundChannelBuffer buffer) throws SSLException { | |||
currentMode.read(buffer); | |||
boolean continueReading = true; | |||
while (continueReading) { |
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.
maybe use do { } while (modePriorToRead != currentMode)
?
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 2. I also had the same thought about using a do while
…ngs-to-true * elastic/master: [DOCS] Restores 7.0.0 release notes and highlights Remove assert statements from field caps documentation. (elastic#30601) Repository GCS plugin new client library (elastic#30168) HLRestClient: Follow-up for put index template api (elastic#30592) Unmute IndexUpgradeIT tests [DOCS] Remove references to changelog and to highlights Side-step pending deletes check (elastic#30571) [DOCS] Remove references to removed changelog Revert "Mute ML upgrade test (elastic#30458)" [ML] Adjust BWC version following backport of elastic#30125 [Docs] Improve section detailing translog usage (elastic#30573) [Tests] Relax allowed delta in extended_stats aggregation (elastic#30569) [ML] Reverse engineer Grok patterns from categorization results (elastic#30125) Update build file due to doc file rename Remove the changelog (elastic#30593) Fix issue with finishing handshake in ssl driver (elastic#30580) Fail if reading from closed KeyStoreWrapper (elastic#30394) Silence IndexUpgradeIT test failures. (elastic#30430)
This is fixing an issue that has come up in some builds. In some
scenarios I see an assertion failure that we are trying to move to
application mode when we are not in handshake mode. What I think is
happening is that we are in handshake mode and have received the
completed handshake message AND an application message. While reading in
handshake mode we switch to application mode. However, there is still
data to be consumed so we attempt to continue to read in handshake mode.
This leads to us attempting to move to application mode again throwing
an assertion.
This commit fixes this by immediatly exiting the handshake mode read
method if we are not longer in handshake mode. Additionally if we swap
modes during a read we attempt to read with the new mode to see if there
is data that needs to be handled.