Skip to content

chore(ci): provision an OpenSSL 3.5 image and hard-assert REST post-quantum key exchange - #1352

Open
torreypayne wants to merge 2 commits into
pqc-validation-testsfrom
pqc-rest-ci
Open

torreypayne wants to merge 2 commits into
pqc-validation-testsfrom
pqc-rest-ci

Conversation

@torreypayne

@torreypayne torreypayne commented Sep 15, 2026 •

Copy link
Copy Markdown
Member

#1351 derives the REST expectation from the host: OpenSSL >= 3.5 must negotiate ML-KEM, older hosts must negotiate X25519. No GitHub-hosted runner can reach the first branch. ubuntu-latest (Ubuntu 24.04) ships OpenSSL 3.0.13, and Ruby's openssl is a binding to whatever libssl the host provides.

So this PR adds a pqc-rest job on ruby:3.2-trixie (OpenSSL 3.5.5), where REST must negotiate ML-KEM. SHOWCASE_REQUIRE_REST_PQC=1 plus a workflow guard step fail the job if the image ever drops below 3.5, instead of it silently reverting to the classical expectation. Once ubuntu-latest moves to 26.04 (rollout from 2026-10-19) this folds back into the matrix; tracked in b/564510736.

Negative controls

Both ways this job could go quietly useless were verified to fail loudly instead:

sabotage result
image regresses to OpenSSL 3.0.18 guard step aborts; run directly, the suite's precondition fails
OpenSSL 3.5.5, client stops offering ML-KEM 2 REST failures, 0 skips, exit 1

The second leaves the gRPC tests green — gRPC vendors its own BoringSSL — so the job discriminates rather than merely being fragile.

Reviewer note

ruby/setup-ruby is intentionally omitted: inside a container: it detects debian-13-x64, treats the job as self-hosted, and stops using prebuilt binaries.


Companion: ruby-core-libraries#73 raises the gapic-common grpc floor.
Design: go/client-libraries:ruby-pqc · Parent: go/cloudsdk-pqc-ruby

@torreypayne
torreypayne force-pushed the pqc-rest-ci branch 2 times, most recently from 5b926f1 to 3c822da Compare September 16, 2026 19:38
@torreypayne
torreypayne added this pull request to stack #1353 September 16, 2026 20:00
@torreypayne
torreypayne force-pushed the pqc-rest-ci branch 2 times, most recently from 168ca63 to 960ac5e Compare September 17, 2026 17:58
@torreypayne
torreypayne removed this pull request from stack #1353 September 21, 2026 17:11
@torreypayne
torreypayne added this pull request to stack #1356 September 21, 2026 17:12
@torreypayne
torreypayne force-pushed the pqc-rest-ci branch 2 times, most recently from 86f5149 to de655fa Compare September 21, 2026 18:00
@torreypayne torreypayne changed the title chore(ci): hard-assert REST post-quantum key exchange on an OpenSSL 3.5 image chore(ci): provision an OpenSSL 3.5 image and hard-assert REST post-quantum key exchange Sep 21, 2026
@torreypayne
torreypayne marked this pull request as ready for review September 21, 2026 20:50
@torreypayne
torreypayne requested a review from a team as a code owner September 21, 2026 20:50
@torreypayne
torreypayne force-pushed the pqc-rest-ci branch 2 times, most recently from e0c2d22 to 78f1700 Compare September 24, 2026 20:49
….5 image

The existing matrix runs on ubuntu-latest, whose system OpenSSL is 3.0.13.
ML-KEM only exists from OpenSSL 3.5, so the REST transport there negotiates
classical X25519 and the conformance assertion stays tolerant. gRPC is
unaffected, since it carries its own BoringSSL inside the grpc gem.

Add a job that re-runs the same showcase suite inside ruby:3.2-trixie,
which provides OpenSSL 3.5.5, with SHOWCASE_REQUIRE_REST_PQC set. That
promotes the tolerant assertion into a hard X25519MLKEM768 requirement and
is what actually proves REST post-quantum key exchange works.

The job asserts the image's OpenSSL is at least 3.5 before running the
suite. Without that check, a future retag of the base image onto an older
OpenSSL would silently drop back to the tolerant path and reintroduce
exactly the false-green this job exists to prevent.

ruby/setup-ruby is deliberately omitted: inside a container it detects
debian-13-x64, treats the job as self-hosted, and will not use prebuilt
binaries. The image's own Ruby is already linked against the OpenSSL we
want.

Once ubuntu-latest advances to Ubuntu 26.04, which ships OpenSSL 3.5.5,
this job collapses into a single environment variable on the matrix above.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants