feat(xtest): sync upstream/main (DPoP + PQ/T) and add feature conformance to Pages

[arkavo-com]

What

Brings main level with opentdf/tests@main (14 upstream commits) plus the fork's community additions, and wires the newly pulled DPoP and post-quantum KEM suites into the community CI + GitHub Pages report.

Upstream sync (merge of upstream/main)

• DPoP: chore(xtest): DPoP nonce-challenge test coverage and CLI/CI hardening opentdf/tests#529 (nonce-challenge coverage, CLI/CI hardening), fix(xtest): detect java dpop support via supports subcommand opentdf/tests#558 (java dpop detection via supports)
• PQ/T (ML-KEM): fix(xtest): Add secp256r1-mlkem768 mechanism to java cli opentdf/tests#531 (secp256r1-mlkem768 java CLI), fix(xtest): use head-built otdfctl for admin key ops so PQ/T tests run on branch refs opentdf/tests#534 (head-built otdfctl for PQ/T on branch refs), feat(xtest): Enables mlkem tests on java-sdk; skips hpqt skew failures opentdf/tests#538/fix(xtest): Removes support for not-yet-ready java-sdk mlkem feature opentdf/tests#540 (java mlkem enable/remove), feat(xtest): Xtest for web-sdk mlkem functionality opentdf/tests#551 (web-sdk mlkem xtests)
• CI fixes: fix(xtest): pin start-up-with-containers to opentdf/platform#3750 opentdf/tests#559/chore(xtest): re-pin opentdf/platform test actions to main opentdf/tests#563 re-pin start-up-with-containers to 6dd5f64 (fix(ci): always generate opentdf.yaml even when PQC keys are absent opentdf/platform#3750), OTDFCTL_HEADS plumbing, dpop-challenge workflow input

Community additions on top

• Pages report (xtest/reporting/generate_site.py): new Feature conformance section — test_dpop.py/test_pqc.py results (classified by junit classname) counted per participating SDK and rendered between the interop and capability matrices; excluded from Base TDF matrix/scorecards; summary.json gains a features array. Dormant lanes show as all-skipped until an SDK claims the feature.
• community-xtest.yml:
  • Re-pinned start-up-with-containers → 6dd5f64 and added dpop-challenge-enabled via new workflow_dispatch input dpop-challenge.
  • Ubuntu stage-1 jobs start a km1 key-management KAS (upstream km-check + start-additional-kas recipe) so test_pqc.py fixtures work.
  • Dormant feature lanes: test_dpop.py + test_pqc.py for python/rust (ubuntu), test_dpop.py for swift (macOS — native platform has no km1). Lanes skip until an SDK's cli.sh supports claims the feature, then light up automatically.
  • OTDFCTL_HEADS passed to all pytest steps (head-built otdfctl for admin key ops; PQ/T hybrid-format skew skip for otdfctl ≤ 0.33).
• docs/community-conformance.md: documents the feature lanes and the new report section.

Merge notes

• Includes merges of upstream/main and origin/main into this branch, so the PR is cleanly mergeable; merging it brings main to upstream + community additions.
• xtest/pyproject.toml conflicts resolved to cryptography>=49.0.0 (upstream) keeping defusedxml (fork); uv.lock regenerated.

Validation

• ruff check + ruff format --check clean; pyright clean on the report generator.
• Site generator smoke-tested with synthetic junit/supports fixtures (feature rows render, summary.json verified).
• Workflow YAML parses; step-id/output references verified; no duplicate step ids.

After merge, the Pages site will show DPoP and PQ/T rows once the next Community X-Test run completes on main.

[gitar-bot]

💡 Bug: resolve.py silently collapses ambiguous multi-tag SHA matches

The old _resolve_against code raised a ResolveError ("SHA points to multiple tags, unable to differentiate") when a SHA matched several refs and none fell into a preferred bucket (e.g. two release tags on the same commit, no branch). The new min(matching_tags, key=_ref_specificity) (resolve.py:261) always returns a winner — _ref_specificity maps unmatched refs to 4, so ties are broken silently by ls-remote output order instead of surfacing an error. This is fine for the common branch/PR/merge-queue cases the new tests cover, but a genuinely ambiguous case (e.g. two tags with no head ref) now resolves to an essentially arbitrary tag instead of failing loudly, and no test exercises that path anymore.

Keep the deterministic tie-break for the common cases, but still flag true ambiguity (multiple refs with the same, lowest, tag-or-lower specificity) as an error.:

sha, ref = min(matching_tags, key=lambda st: _ref_specificity(st[1]))
best = _ref_specificity(ref)
if best >= 3 and sum(1 for _, r in matching_tags if _ref_specificity(r) == best) > 1:
    return {
        "sdk": sdk,
        "alias": version,
        "err": (
            f"SHA {version} points to multiple tags, unable to differentiate: "
            f"{', '.join(r for _, r in matching_tags)}"
        ),
    }
return _classify_sha_match(sdk, version, sha, ref, infix)

_{Was this helpful? React with 👍 / 👎}

[gitar-bot]

💡 Edge Case: go cli.sh dpop/dpop_nonce_challenge probe relies on an unverified otdfctl JSON field

xtest/sdk/go/cli.sh:118-123 detects DPoP/nonce-challenge support via otdfctl --version --json | jq -e '.supported_features | index($f)', replacing the previous help encrypt | grep --dpop probe. Unlike the java CLI change in the same PR, which delegates to an actual supports subcommand baked into the jar, this assumes the go otdfctl --version --json output has gained a supported_features array — if that field doesn't exist on some otdfctl versions in rotation (e.g. older releases resolved via OTDFCTL_HEADS pinning elsewhere in this PR), jq -e on a missing key returns null/exit 1, so the probe just reports "unsupported" rather than erroring, but this could silently mask real support or misreport across otdfctl version skew without a fallback to the old help-text grep.

Fall back to help-text detection if supported_features is absent, so version skew doesn't just report 'unsupported' with no diagnostic.:

dpop | dpop_nonce_challenge)
  set -o pipefail
  if "${cmd[@]}" --version --json 2>/dev/null | jq -e --arg f "$2" '.supported_features // [] | index($f)' >/dev/null 2>&1; then
    exit 0
  fi
  "${cmd[@]}" help encrypt | grep -iE -- '--dpop'
  exit $?
  ;;

_{Was this helpful? React with 👍 / 👎}

[gitar-bot]

Note

Automatic reviews are paused because of a high rate of recent commits on your team. You can still comment "Gitar review" to run one anytime, and automatic reviews resume on their own by August 1.
Learn more

Code Review 👍 Approved with suggestions 0 resolved / 2 findings

Integrates upstream DPoP and PQ/T feature suites into the community CI and Pages report. Note that SHA resolution for ambiguous tags is currently silent and the Go CLI DPoP probe relies on an unverified JSON field.

💡 Bug: resolve.py silently collapses ambiguous multi-tag SHA matches

📄 otdf-sdk-mgr/src/otdf_sdk_mgr/resolve.py:56-70 📄 otdf-sdk-mgr/src/otdf_sdk_mgr/resolve.py:257-262

The old _resolve_against code raised a ResolveError ("SHA points to multiple tags, unable to differentiate") when a SHA matched several refs and none fell into a preferred bucket (e.g. two release tags on the same commit, no branch). The new min(matching_tags, key=_ref_specificity) (resolve.py:261) always returns a winner — _ref_specificity maps unmatched refs to 4, so ties are broken silently by ls-remote output order instead of surfacing an error. This is fine for the common branch/PR/merge-queue cases the new tests cover, but a genuinely ambiguous case (e.g. two tags with no head ref) now resolves to an essentially arbitrary tag instead of failing loudly, and no test exercises that path anymore.

Keep the deterministic tie-break for the common cases, but still flag true ambiguity (multiple refs with the same, lowest, tag-or-lower specificity) as an error.

sha, ref = min(matching_tags, key=lambda st: _ref_specificity(st[1]))
best = _ref_specificity(ref)
if best >= 3 and sum(1 for _, r in matching_tags if _ref_specificity(r) == best) > 1:
    return {
        "sdk": sdk,
        "alias": version,
        "err": (
            f"SHA {version} points to multiple tags, unable to differentiate: "
            f"{', '.join(r for _, r in matching_tags)}"
        ),
    }
return _classify_sha_match(sdk, version, sha, ref, infix)

💡 Edge Case: go cli.sh dpop/dpop_nonce_challenge probe relies on an unverified otdfctl JSON field

📄 xtest/sdk/go/cli.sh:118-123

xtest/sdk/go/cli.sh:118-123 detects DPoP/nonce-challenge support via otdfctl --version --json | jq -e '.supported_features | index($f)', replacing the previous help encrypt | grep --dpop probe. Unlike the java CLI change in the same PR, which delegates to an actual supports subcommand baked into the jar, this assumes the go otdfctl --version --json output has gained a supported_features array — if that field doesn't exist on some otdfctl versions in rotation (e.g. older releases resolved via OTDFCTL_HEADS pinning elsewhere in this PR), jq -e on a missing key returns null/exit 1, so the probe just reports "unsupported" rather than erroring, but this could silently mask real support or misreport across otdfctl version skew without a fallback to the old help-text grep.

Fall back to help-text detection if supported_features is absent, so version skew doesn't just report 'unsupported' with no diagnostic.

dpop | dpop_nonce_challenge)
  set -o pipefail
  if "${cmd[@]}" --version --json 2>/dev/null | jq -e --arg f "$2" '.supported_features // [] | index($f)' >/dev/null 2>&1; then
    exit 0
  fi
  "${cmd[@]}" help encrypt | grep -iE -- '--dpop'
  exit $?
  ;;

🤖 Prompt for agents

Code Review: Integrates upstream DPoP and PQ/T feature suites into the community CI and Pages report. Note that SHA resolution for ambiguous tags is currently silent and the Go CLI DPoP probe relies on an unverified JSON field.

1. 💡 Bug: resolve.py silently collapses ambiguous multi-tag SHA matches
   Files: otdf-sdk-mgr/src/otdf_sdk_mgr/resolve.py:56-70, otdf-sdk-mgr/src/otdf_sdk_mgr/resolve.py:257-262

   The old `_resolve_against` code raised a `ResolveError` ("SHA points to multiple tags, unable to differentiate") when a SHA matched several refs and none fell into a preferred bucket (e.g. two release tags on the same commit, no branch). The new `min(matching_tags, key=_ref_specificity)` (resolve.py:261) always returns a winner — `_ref_specificity` maps unmatched refs to 4, so ties are broken silently by `ls-remote` output order instead of surfacing an error. This is fine for the common branch/PR/merge-queue cases the new tests cover, but a genuinely ambiguous case (e.g. two tags with no head ref) now resolves to an essentially arbitrary tag instead of failing loudly, and no test exercises that path anymore.

   Fix (Keep the deterministic tie-break for the common cases, but still flag true ambiguity (multiple refs with the same, lowest, tag-or-lower specificity) as an error.):
   sha, ref = min(matching_tags, key=lambda st: _ref_specificity(st[1]))
   best = _ref_specificity(ref)
   if best >= 3 and sum(1 for _, r in matching_tags if _ref_specificity(r) == best) > 1:
       return {
           "sdk": sdk,
           "alias": version,
           "err": (
               f"SHA {version} points to multiple tags, unable to differentiate: "
               f"{', '.join(r for _, r in matching_tags)}"
           ),
       }
   return _classify_sha_match(sdk, version, sha, ref, infix)

2. 💡 Edge Case: go cli.sh dpop/dpop_nonce_challenge probe relies on an unverified otdfctl JSON field
   Files: xtest/sdk/go/cli.sh:118-123

   `xtest/sdk/go/cli.sh:118-123` detects DPoP/nonce-challenge support via `otdfctl --version --json | jq -e '.supported_features | index($f)'`, replacing the previous `help encrypt | grep --dpop` probe. Unlike the java CLI change in the same PR, which delegates to an actual `supports` subcommand baked into the jar, this assumes the go `otdfctl --version --json` output has gained a `supported_features` array — if that field doesn't exist on some otdfctl versions in rotation (e.g. older releases resolved via OTDFCTL_HEADS pinning elsewhere in this PR), `jq -e` on a missing key returns `null`/exit 1, so the probe just reports "unsupported" rather than erroring, but this could silently mask real support or misreport across otdfctl version skew without a fallback to the old help-text grep.

   Fix (Fall back to help-text detection if supported_features is absent, so version skew doesn't just report 'unsupported' with no diagnostic.):
   dpop | dpop_nonce_challenge)
     set -o pipefail
     if "${cmd[@]}" --version --json 2>/dev/null | jq -e --arg f "$2" '.supported_features // [] | index($f)' >/dev/null 2>&1; then
       exit 0
     fi
     "${cmd[@]}" help encrypt | grep -iE -- '--dpop'
     exit $?
     ;;

_{Was this helpful? React with 👍 / 👎 | Gitar}

[github-actions]

X-Test Results

✅ java@v0.17.1-main
✅ java@main-v0.20.0
✅ go@v0.35.0-main
✅ js@main-v0.20.0
✅ go@main-main
✅ go@main-v0.20.0
✅ java@main-main
✅ js@main-main
✅ js@v0.4.0-main
✅ java@v0.17.1-v0.20.0
✅ go@v0.35.0-v0.20.0
✅ js@v0.4.0-v0.20.0

[github-actions]

X-Test Failure Report

[github-actions]

X-Test Failure Report

[github-actions]

X-Test Results

✅ java@main-main
✅ java@main-v0.20.0
✅ java@v0.17.1-main
✅ js@main-main
✅ go@v0.35.0-main
✅ js@main-v0.20.0
✅ go@main-v0.20.0
✅ js@v0.4.0-main
✅ java@v0.17.1-v0.20.0
✅ go@v0.35.0-v0.20.0
✅ go@main-main
✅ js@v0.4.0-v0.20.0