feat(xtest): Enables mlkem tests on java-sdk; skips hpqt skew failures#538
Conversation
📝 WalkthroughWalkthroughThe Java CLI wrapper adds a ChangesJava CLI support check
PQC hybrid format skip gating
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Code Review
This pull request adds support for checking the mechanism-mlkem capability in the Java CLI test script. However, a copy-paste error was identified where the script greps for xwing instead of ml-kem or mlkem, which would cause incorrect capability detection.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
…rm skew otdfctl v0.33.0 and older were built against a pre-ocrypto-0.13.0 that produces non-conformant X-Wing and secp+ML-KEM key material. When paired with a platform that has hybrid PQC support enabled (new-format KAS), both key creation and decapsulation fail with opaque errors. Add skip_pqc_hybrid_format_skew() + _otdfctl_semver() to tdfs.py and call the guard in the four hybrid test functions (xwing roundtrip, xwing+ec roundtrip, secpmlkem-3 roundtrip, secpmlkem-5 roundtrip). Pure ML-KEM tests are unaffected.
Two independent sources of format incompatibility exist for hybrid PQC tests (X-Wing and secp+ML-KEM): - otdfctl ≤ 0.33.0: registers hybrid KAS keys in non-conformant format - go encrypt SDK ≤ 0.33.0: produces hybrid KEM ciphertexts in old format Both are built against lib/ocrypto < v0.13.0 which changed the key-material format. Either causes opaque crypto failures when paired with a platform that has hybrid PQC support enabled. Extend skip_pqc_hybrid_format_skew() to accept an encrypt_sdk parameter and check its version (when it is a released go SDK ≤ v0.33.0) in addition to the existing otdfctl version check. Pass encrypt_sdk at all four hybrid test call sites.
The grep command was missing, leaving a dangling pipe into exit. Add the missing grep for 'mlkem:768' to match the help output.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@xtest/tdfs.py`:
- Around line 748-754: Update the version parsing used by the Go SDK safety gate
so _parse_semver handles released version strings with an sdk/ prefix as well as
a leading v. The current check in the encrypt_sdk.version flow can return None
for values like sdk/v0.12.0, which bypasses the cutoff comparison in the gate.
Adjust _parse_semver to normalize the prefix before matching, and keep the
existing call site in the encrypt_sdk / is_released path working without
changing the gate logic.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 24c2d0f0-37be-418d-b5c0-f9f0cbb4c9e1
📒 Files selected for processing (3)
xtest/sdk/java/cli.shxtest/tdfs.pyxtest/test_pqc.py
🚧 Files skipped from review as they are similar to previous changes (1)
- xtest/sdk/java/cli.sh
|



mechanism-mlkem, verifying support via the encryption help output.