test: add post-quantum cryptography conformance tests for showcase - #1351
Draft
torreypayne wants to merge 1 commit into
Draft
torreypayne wants to merge 1 commit into
torreypayne wants to merge 1 commit into
Conversation
This was referenced Sep 15, 2026
torreypayne
force-pushed
the
pqc-validation-tests
branch
2 times, most recently
from
September 16, 2026 19:38
4330712 to
a03c2b9
Compare
torreypayne
added this pull request to stack #1353
September 16, 2026 20:00
torreypayne
force-pushed
the
pqc-validation-tests
branch
from
September 16, 2026 20:26
a03c2b9 to
063fb1e
Compare
torreypayne
force-pushed
the
pqc-validation-tests
branch
from
September 16, 2026 20:40
063fb1e to
bc07fca
Compare
Adds a dedicated suite that proves the generated Ruby clients negotiate X25519MLKEM768 with the Showcase server over both transports. Assertions read the TLS metadata that Showcase reflects onto every response (x-showcase-tls-group and x-showcase-tls-client-supported-groups) rather than inspecting CRuby's internal OpenSSL structures, whose layout is not stable across Ruby releases or platforms. Covered scenarios: - gRPC and REST negotiate the hybrid post-quantum group and advertise it in their ClientHello. - Both transports degrade cleanly to classical X25519 when the server offers only classical groups. These also assert the client still advertised X25519MLKEM768: without that, the test would pass just as happily against a client that had lost post-quantum support altogether. The classical-only case needs a second Showcase process, since --tls-groups applies to a whole server. That auxiliary process mints a certificate authority of its own, so the test points SSL_CERT_FILE at the new CA for the duration of the block and builds explicit gRPC credentials from it. REST cannot be held to post-quantum key exchange unconditionally. It delegates to the host's OpenSSL, and ML-KEM only exists from OpenSSL 3.5 onward, while GitHub Actions ubuntu-latest ships 3.0.13. Skipping on older hosts would leave the REST transport unexercised in CI entirely, which is a permanently green check that verifies nothing. Instead the negotiated group must be present (proving the connection was genuinely TLS), must be either X25519MLKEM768 or classical X25519, and must be a group the client actually offered. Setting SHOWCASE_REQUIRE_REST_PQC=1 promotes this into a strict post-quantum assertion. Group membership is tested against the split supported-groups list rather than the raw header value, because "X25519" is a substring of "X25519MLKEM768" and a string containment check could therefore never fail. This mirrors the merged conformance test in gax-php. Ruby and PHP are the only Cloud SDK languages whose REST transport binds to the system OpenSSL instead of a vendored TLS stack, so they are the only two that cannot hard-assert post-quantum key exchange on a stock runner.
torreypayne
force-pushed
the
pqc-validation-tests
branch
from
September 17, 2026 17:20
bc07fca to
8279a21
Compare
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
1 participant
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.
Adds
shared/test/showcase/pqc_test.rb, proving Ruby clients negotiateX25519MLKEM768against Showcase over both transports.Ruby never performs the key exchange itself — gRPC delegates to BoringSSL vendored in the
grpcgem, REST to system OpenSSL. The suite therefore asserts on what the server observed, via thex-showcase-tls-groupandx-showcase-tls-client-supported-groupsmetadata Showcase reflects onto every response. Python, Node, Java, C#, and C++ assert the same way.Two scenarios per transport: default negotiation, and fallback against a classical-only server.
Reviewer notes
grpc >= 1.83up front. Nothing here pinsgrpc— it resolves throughgapic-common, so PQC holds only because bundler picks the newest match. Without the check a downgrade reads as a protocol bug. ruby-core-libraries#73 raises that floor.X25519MLKEM768. Otherwise the test would pass against a client that had lost PQC entirely. For REST that half is gated onSHOWCASE_REQUIRE_REST_PQC, since below OpenSSL 3.5 there is no PQC group to withhold.skipwould mean REST is never exercised at all. It runs against a{X25519MLKEM768, X25519}allowlist; chore(ci): hard-assert REST post-quantum key exchange on an OpenSSL 3.5 image #1352 tightens that on a 3.5 image.normalize_headersfails loudly when TLS metadata is absent, so plaintext cannot silently no-op the suite.Green, zero skips across OpenSSL 3.0.18 / 3.5.5 / 3.6.3 and Ruby 3.2 / 4.0.
Sits on #1330 (fork-hosted, so excluded from the stack).
Design: go/client-libraries:ruby-pqc · Parent: go/cloudsdk-pqc-ruby