Skip to content

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

Draft
torreypayne wants to merge 1 commit into
pqc-validation-testsfrom
pqc-rest-ci
Draft

torreypayne wants to merge 1 commit into
pqc-validation-testsfrom
pqc-rest-ci

Conversation

@torreypayne

@torreypayne torreypayne commented Sep 15, 2026

Copy link
Copy Markdown
Member

Adds a pqc-rest CI job that hard-asserts REST post-quantum key exchange (X25519MLKEM768) on an image that actually provides OpenSSL >= 3.5.

Layer 2 of the two-layer REST strategy: Layer 1 (#1351) asserts against a tolerant {X25519MLKEM768, X25519} allowlist on every host; this job removes the tolerance, running ruby:3.2-trixie (OpenSSL 3.5.5) with SHOWCASE_REQUIRE_REST_PQC=1.

Why a container rather than the stock runner

Ruby's openssl is a default gem binding to whatever libssl the host provides. ML-KEM needs OpenSSL >= 3.5; ubuntu-latest ships 3.0.13. No gemspec constraint, PPA, or backport fixes that, and ruby/setup-ruby links the runner's system libssl, so it cannot help either. Ruby is the only Cloud SDK language with this problem — Java ships Conscrypt, C++ vendors BoringSSL, Node bundles OpenSSL. ubuntu-26.04 (3.5.5) was rejected as public preview with no GA date.

Reviewer notes

  • The OpenSSL pre-check is a hard gate, not a log line. If a future base image regresses below 3.5, the job fails loudly instead of silently relaxing onto Layer 1's tolerant path, which would stay green while proving nothing.
  • ruby/setup-ruby is intentionally omitted. Inside a container: it detects debian-13-x64, classifies the job as self-hosted, and stops using prebuilts. The container's own Ruby is what we want anyway.

Green, zero skips, on OpenSSL 3.0.18 / 3.5.5 / 3.6.3. zizmor adds no new finding class.


Sits on #1330 (fork-hosted, so GitHub excludes it from the stack) · Companion: ruby-core-libraries#73 raises the gapic-common grpc floor.
Design: go/client-libraries:ruby-pqc · Parent: go/cloudsdk-pqc-ruby

….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.

1 participant