-
Notifications
You must be signed in to change notification settings - Fork 30k
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
Pass node 18.x branch tests when compiled against shared openssl 3.2 #52482
Labels
openssl
Issues and PRs related to the OpenSSL dependency.
Comments
Regarding quictls/quictls#14 since it's the only non-trivial issue besides anything quic-related, it might be worth the help :) |
Is it only an issue with 18.x? |
Absolutely not, I was just focused on that version :) |
targos
added
openssl
Issues and PRs related to the OpenSSL dependency.
shared_lib
Issues and PRs related to use of Node.js as a shared library.
and removed
shared_lib
Issues and PRs related to use of Node.js as a shared library.
labels
Apr 13, 2024
nodejs-github-bot
pushed a commit
that referenced
this issue
Sep 25, 2024
Refs: #53382 TLS spec seems to indicate there should should be a response sent when TLS handshake fails. See https://datatracker.ietf.org/doc/html/rfc8446#page-85 When compiled with OpenSSL32 we see the the following response '15 03 03 00 02 02 16' which decodes as a fatal (0x02) TLS error alert number 22 (0x16). which corresponds to TLS1_AD_RECORD_OVERFLOW which matches the error we see if NODE_DEBUG is turned on once you get through the define aliases. If there is a response from the server the test used to hang because the end event will not be emitted until after the response is consumed. This PR fixes the test so it consumes the response. Some earlier OpenSSL versions did not seem to send a response but the error handling seems to have been re-written/improved in OpenSSL32. Signed-off-by: Michael Dawson <midawson@redhat.com> PR-URL: #55089 Refs: #52482 Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Jithil P Ponnan <jithil@outlook.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
aduh95
pushed a commit
to aduh95/node
that referenced
this issue
Sep 25, 2024
Refs: nodejs#53382 TLS spec seems to indicate there should should be a response sent when TLS handshake fails. See https://datatracker.ietf.org/doc/html/rfc8446#page-85 When compiled with OpenSSL32 we see the the following response '15 03 03 00 02 02 16' which decodes as a fatal (0x02) TLS error alert number 22 (0x16). which corresponds to TLS1_AD_RECORD_OVERFLOW which matches the error we see if NODE_DEBUG is turned on once you get through the define aliases. If there is a response from the server the test used to hang because the end event will not be emitted until after the response is consumed. This PR fixes the test so it consumes the response. Some earlier OpenSSL versions did not seem to send a response but the error handling seems to have been re-written/improved in OpenSSL32. Signed-off-by: Michael Dawson <midawson@redhat.com> PR-URL: nodejs#55089 Refs: nodejs#52482 Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Jithil P Ponnan <jithil@outlook.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
richardlau
pushed a commit
to aduh95/node
that referenced
this issue
Sep 27, 2024
Refs: nodejs#53382 TLS spec seems to indicate there should should be a response sent when TLS handshake fails. See https://datatracker.ietf.org/doc/html/rfc8446#page-85 When compiled with OpenSSL32 we see the the following response '15 03 03 00 02 02 16' which decodes as a fatal (0x02) TLS error alert number 22 (0x16). which corresponds to TLS1_AD_RECORD_OVERFLOW which matches the error we see if NODE_DEBUG is turned on once you get through the define aliases. If there is a response from the server the test used to hang because the end event will not be emitted until after the response is consumed. This PR fixes the test so it consumes the response. Some earlier OpenSSL versions did not seem to send a response but the error handling seems to have been re-written/improved in OpenSSL32. Signed-off-by: Michael Dawson <midawson@redhat.com> PR-URL: nodejs#55089 Refs: nodejs#52482 Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Jithil P Ponnan <jithil@outlook.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
With #55101 merged, I think we can close this issue as completed :) |
targos
pushed a commit
that referenced
this issue
Oct 4, 2024
Refs: #53382 TLS spec seems to indicate there should should be a response sent when TLS handshake fails. See https://datatracker.ietf.org/doc/html/rfc8446#page-85 When compiled with OpenSSL32 we see the the following response '15 03 03 00 02 02 16' which decodes as a fatal (0x02) TLS error alert number 22 (0x16). which corresponds to TLS1_AD_RECORD_OVERFLOW which matches the error we see if NODE_DEBUG is turned on once you get through the define aliases. If there is a response from the server the test used to hang because the end event will not be emitted until after the response is consumed. This PR fixes the test so it consumes the response. Some earlier OpenSSL versions did not seem to send a response but the error handling seems to have been re-written/improved in OpenSSL32. Signed-off-by: Michael Dawson <midawson@redhat.com> PR-URL: #55089 Refs: #52482 Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Jithil P Ponnan <jithil@outlook.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
louwers
pushed a commit
to louwers/node
that referenced
this issue
Nov 2, 2024
Refs: nodejs#53382 TLS spec seems to indicate there should should be a response sent when TLS handshake fails. See https://datatracker.ietf.org/doc/html/rfc8446#page-85 When compiled with OpenSSL32 we see the the following response '15 03 03 00 02 02 16' which decodes as a fatal (0x02) TLS error alert number 22 (0x16). which corresponds to TLS1_AD_RECORD_OVERFLOW which matches the error we see if NODE_DEBUG is turned on once you get through the define aliases. If there is a response from the server the test used to hang because the end event will not be emitted until after the response is consumed. This PR fixes the test so it consumes the response. Some earlier OpenSSL versions did not seem to send a response but the error handling seems to have been re-written/improved in OpenSSL32. Signed-off-by: Michael Dawson <midawson@redhat.com> PR-URL: nodejs#55089 Refs: nodejs#52482 Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Jithil P Ponnan <jithil@outlook.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
marco-ippolito
pushed a commit
that referenced
this issue
Nov 16, 2024
Refs: #53382 TLS spec seems to indicate there should should be a response sent when TLS handshake fails. See https://datatracker.ietf.org/doc/html/rfc8446#page-85 When compiled with OpenSSL32 we see the the following response '15 03 03 00 02 02 16' which decodes as a fatal (0x02) TLS error alert number 22 (0x16). which corresponds to TLS1_AD_RECORD_OVERFLOW which matches the error we see if NODE_DEBUG is turned on once you get through the define aliases. If there is a response from the server the test used to hang because the end event will not be emitted until after the response is consumed. This PR fixes the test so it consumes the response. Some earlier OpenSSL versions did not seem to send a response but the error handling seems to have been re-written/improved in OpenSSL32. Signed-off-by: Michael Dawson <midawson@redhat.com> PR-URL: #55089 Refs: #52482 Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Jithil P Ponnan <jithil@outlook.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
marco-ippolito
pushed a commit
that referenced
this issue
Nov 17, 2024
Refs: #53382 TLS spec seems to indicate there should should be a response sent when TLS handshake fails. See https://datatracker.ietf.org/doc/html/rfc8446#page-85 When compiled with OpenSSL32 we see the the following response '15 03 03 00 02 02 16' which decodes as a fatal (0x02) TLS error alert number 22 (0x16). which corresponds to TLS1_AD_RECORD_OVERFLOW which matches the error we see if NODE_DEBUG is turned on once you get through the define aliases. If there is a response from the server the test used to hang because the end event will not be emitted until after the response is consumed. This PR fixes the test so it consumes the response. Some earlier OpenSSL versions did not seem to send a response but the error handling seems to have been re-written/improved in OpenSSL32. Signed-off-by: Michael Dawson <midawson@redhat.com> PR-URL: #55089 Refs: #52482 Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Jithil P Ponnan <jithil@outlook.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
tpoisseau
pushed a commit
to tpoisseau/node
that referenced
this issue
Nov 21, 2024
Refs: nodejs#53382 TLS spec seems to indicate there should should be a response sent when TLS handshake fails. See https://datatracker.ietf.org/doc/html/rfc8446#page-85 When compiled with OpenSSL32 we see the the following response '15 03 03 00 02 02 16' which decodes as a fatal (0x02) TLS error alert number 22 (0x16). which corresponds to TLS1_AD_RECORD_OVERFLOW which matches the error we see if NODE_DEBUG is turned on once you get through the define aliases. If there is a response from the server the test used to hang because the end event will not be emitted until after the response is consumed. This PR fixes the test so it consumes the response. Some earlier OpenSSL versions did not seem to send a response but the error handling seems to have been re-written/improved in OpenSSL32. Signed-off-by: Michael Dawson <midawson@redhat.com> PR-URL: nodejs#55089 Refs: nodejs#52482 Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Jithil P Ponnan <jithil@outlook.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Version
18.20.1
Platform
linux debian/trixie
Subsystem
No response
What steps will reproduce the bug?
Compile node against shared openssl 3.2.1 on debian/trixie, run tests.
How often does it reproduce? Is there a required condition?
Always reproduce.
What is the expected behavior? Why is that the expected behavior?
Tests pass or fail in an expected way :)
What do you see instead?
One test hangs:
test/parallel/test-tls-junk-closes-server.js
to be compared with the same setup but shared openssl 3.0:
Additional information
The fact openssl 3.2 continues to provide (probably garbarge) data is reminiscent of "marvin" issue.
The text was updated successfully, but these errors were encountered: