Update google.golang.org/grpc to 1.68.0#49712
Merged
espadolini merged 4 commits intomasterfrom Dec 3, 2024
Merged
Conversation
espadolini
added
the
no-changelog
github-actions
Bot
requested review from
hugoShaka,
marcoandredinis and
tigrato
|
This pull request is automatically being deployed by Amplify Hosting (learn more). |
codingllama
reviewed
Dec 3, 2024
Contributor
codingllama
left a comment
codingllama
left a comment
There was a problem hiding this comment.
Thanks, Edoardo.
No testing changes needed? I vaguely remember something breaking.
The credentials.NewTLS call will add the h2 NextProto if missing, but in some tests we create a tls.Config and use it to connect to the test server directly, so it's cleaner to just create the tls.Config with the correct NextProto in the first place.
codingllama
reviewed
Dec 3, 2024
| // this would be done by the grpc TransportCredential in the client | ||
| clientTLSConf := test.clientTLSConf | ||
| if !slices.Contains(clientTLSConf.NextProtos, "h2") { | ||
| clientTLSConf = clientTLSConf.Clone() |
Contributor
There was a problem hiding this comment.
Do we need the Clone call?
Contributor
Author
There was a problem hiding this comment.
Seems rude not to?
codingllama
approved these changes
Dec 3, 2024
public-teleport-github-review-bot
Bot
removed request for
hugoShaka,
marcoandredinis and
rosstimothy
carloscastrojumo
pushed a commit
to carloscastrojumo/teleport
that referenced
this pull request
Feb 19, 2025
* Update google.golang.org/grpc to 1.68.0 * Fix TestTransportCredentials_ServerHandshake * Fix TestStart The credentials.NewTLS call will add the h2 NextProto if missing, but in some tests we create a tls.Config and use it to connect to the test server directly, so it's cleaner to just create the tls.Config with the correct NextProto in the first place. * Tweaks to address review comments
This was referenced Apr 23, 2025
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Starting from grpc-go 1.67, TLS transport credentials (on both server and client side) enforce the use of ALPN - however, the initial concern that led us to not upgrade to 1.67 immediately, i.e. the fact that we often use custom ALPN values, is not a problem here: as long as client and server negotiate some ALPN, the connection will still succeed even with the transport credentials implementation in grpc-go; moreover, starting from 1.68.0, grpc-go will actually correctly apply its modifications to the
tls.Configs in use even when making use ofGetConfigForClient(even though all of our uses of configs withGetConfigForClientshould already be settingNextProtoscorrectly).The
goversion in the API module is bumped from 1.22.0 to 1.22.7 to accomodate grpc-go's new minimum version.