src: remove TLSEXT_TYPE_alpn guard #46956
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tniessen
added
c++
bnoordhuis
approved these changes
Mar 5, 2023
panva
approved these changes
Mar 5, 2023
panva
added
author ready
github-actions
bot
removed
the
request-ci
addaleax
added
the
commit-queue
addaleax
approved these changes
Mar 5, 2023
lpinca
approved these changes
Mar 5, 2023
TLSEXT_TYPE_application_layer_protocol_negotiation is always defined in all supported OpenSSL versions. We also use this macro elsewhere without guards, so if it did not exist, compilation would have already failed. Besides that, it makes little sense to provide a TLS 1.3 implementation that does not support ALPN. PR-URL: nodejs#46956 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Filip Skokan <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
tniessen
force-pushed
the
src-remove-alpn-guard
branch
from
07bf616 to
539dcee
Compare
|
Landed in 539dcee, thanks for reviewing. |
tniessen
added a commit
to tniessen/node
that referenced
this pull request
Mar 9, 2023
This constant was likely introduced for feature detection, but it has been pointless for a long time. 1. I am not aware of any possible Node.js build configuration (on any recent/supported release line) that would have crypto.constants but not crypto.constants.ALPN_ENABLED. 2. There is no evidence of this constant being used for feature detection in the ecosystem. In fact, both internal and external type definitions for crypto.constants simply assume that the constant exists. 3. There is no good reason for any modern TLS stack to not support ALPN. It looks like ALPN might have been optional in much earlier versions of OpenSSL, but all recent versions of OpenSSL unconditionally support ALPN as far as I can tell. Refs: nodejs#46956
nodejs-github-bot
pushed a commit
that referenced
this pull request
Mar 13, 2023
This constant was likely introduced for feature detection, but it has been pointless for a long time. 1. I am not aware of any possible Node.js build configuration (on any recent/supported release line) that would have crypto.constants but not crypto.constants.ALPN_ENABLED. 2. There is no evidence of this constant being used for feature detection in the ecosystem. In fact, both internal and external type definitions for crypto.constants simply assume that the constant exists. 3. There is no good reason for any modern TLS stack to not support ALPN. It looks like ALPN might have been optional in much earlier versions of OpenSSL, but all recent versions of OpenSSL unconditionally support ALPN as far as I can tell. Refs: #46956 PR-URL: #47028 Reviewed-By: Filip Skokan <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Matteo Collina <[email protected]>
targos
pushed a commit
that referenced
this pull request
Mar 13, 2023
TLSEXT_TYPE_application_layer_protocol_negotiation is always defined in all supported OpenSSL versions. We also use this macro elsewhere without guards, so if it did not exist, compilation would have already failed. Besides that, it makes little sense to provide a TLS 1.3 implementation that does not support ALPN. PR-URL: #46956 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Filip Skokan <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
targos
pushed a commit
that referenced
this pull request
Mar 14, 2023
TLSEXT_TYPE_application_layer_protocol_negotiation is always defined in all supported OpenSSL versions. We also use this macro elsewhere without guards, so if it did not exist, compilation would have already failed. Besides that, it makes little sense to provide a TLS 1.3 implementation that does not support ALPN. PR-URL: #46956 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Filip Skokan <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
danielleadams
pushed a commit
that referenced
this pull request
Apr 11, 2023
TLSEXT_TYPE_application_layer_protocol_negotiation is always defined in all supported OpenSSL versions. We also use this macro elsewhere without guards, so if it did not exist, compilation would have already failed. Besides that, it makes little sense to provide a TLS 1.3 implementation that does not support ALPN. PR-URL: #46956 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Filip Skokan <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
panva
removed
the
commit-queue
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TLSEXT_TYPE_application_layer_protocol_negotiationis always defined in all supported OpenSSL versions. We also use this macro elsewhere without guards, so if it did not exist, compilation would have already failed.Besides that, it makes little sense to provide a TLS 1.3 implementation that does not support ALPN.