[Arawoof06]

What's Changed

getStreams clones the connection builder for each advertised endpoint location, and that clone still carries username/password, token and the OAuth config, so whatever it connects to gets the credentials. Encryption for the clone came from the location scheme alone, meaning a grpc+tcp:// location advertised by the server turned TLS off even for a connection opened with useEncryption=true, and the handshake then went out in cleartext to the advertised host. Since the scheme is server-supplied and useEncryption is the user's stated intent, the scheme should not be able to override it downwards; a non-TLS location is now refused through the per-location exception path that is already there for unreachable locations, so the remaining locations are still tried.

Closes #1232.

[Arawoof06]

gentle ping

[lidavidm]

@Arawoof06 please rebase.

[Arawoof06]

Rebased onto main.

[Arawoof06]

Rebased onto current main. The August CI runs expired waiting for workflow approval and never started, so the new ones need a maintainer to kick them off. Also joined one wrapped line in the test that the updated google-java-format wanted on a single line.

[jbonofre]

Thanks @Arawoof06! Sorry for the wait ...

I rebased the branch, and fixed the conflict with the new hostnameOverride handling in getStreams. I kept both changes, they don't interact: an encrypted connection now refuses a non-TLS location before the override is ever looked at.

The fix looks right to me. useEncryption is what the user asked for, so a location scheme sent by the server should not be able to turn TLS off, and refusing is better than silently upgrading. Because the refusal goes through the existing per-location error handling, the remaining locations are still tried.

This changes behaviour for some deployments, for example TLS clients going through a TLS-terminating proxy to servers that advertise grpc+tcp:// endpoints. Those used to fall back to plaintext and will now fail, so I've added the breaking-change label.