fix(sdk): reject a chunked split naming a KAS with no resolved public key - #3942
fix(sdk): reject a chunked split naming a KAS with no resolved public key#3942dmihalcik-virtru wants to merge 1 commit into
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: ASSERTIVE Plan: Team Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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 |
Benchmark results, click to expandBenchmark authorization.GetDecisions Results:
Benchmark authorization.v2.GetMultiResourceDecision Results:
Benchmark Statistics
Bulk Benchmark Results
TDF3 Benchmark Results:
|
912b24c to
e7d3d2d
Compare
7f0cb1b to
fd974c3
Compare
X-Test Failure Report |
Benchmark results, click to expandBenchmark authorization.GetDecisions Results:
Benchmark authorization.v2.GetMultiResourceDecision Results:
Benchmark Statistics
Bulk Benchmark Results
TDF3 Benchmark Results:
|
Benchmark results, click to expandBenchmark authorization.GetDecisions Results:
Benchmark authorization.v2.GetMultiResourceDecision Results:
Benchmark Statistics
Bulk Benchmark Results
TDF3 Benchmark Results:
|
Benchmark results, click to expandBenchmark authorization.GetDecisions Results:
Benchmark authorization.v2.GetMultiResourceDecision Results:
Benchmark Statistics
Bulk Benchmark Results
TDF3 Benchmark Results:
|
fd974c3 to
ec6e9b8
Compare
Benchmark results, click to expandBenchmark authorization.GetDecisions Results:
Benchmark authorization.v2.GetMultiResourceDecision Results:
Benchmark Statistics
Bulk Benchmark Results
TDF3 Benchmark Results:
|
41aaa77 to
bf79736
Compare
ec6e9b8 to
1fd4e22
Compare
X-Test Failure Report |
… key `buildChunkedKeyAccessObjects` skipped any KAS URL that a split named but `SplitResult.KASPublicKeys` had no entry for. That silently drops the only key access object that would have let that KAS unwrap the share. In an OR-group the TDF still decrypts, just against a smaller set of KAS servers than the policy asked for -- and nothing in the output says so. If every URL on a split is unresolved the share is unrecoverable outright, and the failure surfaces much later as a generic "no valid key access objects generated", or not at all if some other split still produced KAOs. Treats a missing entry the same way an entry with an empty PEM was already treated: `errKasPubKeyMissing`, naming the split and the URL. A splitter that cannot resolve a key it referenced has a bug, and creation time is where it should be reported. Signed-off-by: Dave Mihalcik <dmihalcik@virtru.com>
Benchmark results, click to expandBenchmark authorization.GetDecisions Results:
Benchmark authorization.v2.GetMultiResourceDecision Results:
Benchmark Statistics
Bulk Benchmark Results
TDF3 Benchmark Results:
|
Benchmark results, click to expandBenchmark authorization.GetDecisions Results:
Benchmark authorization.v2.GetMultiResourceDecision Results:
Benchmark Statistics
Bulk Benchmark Results
TDF3 Benchmark Results:
|
bf79736 to
89d49b0
Compare
1fd4e22 to
6b6edef
Compare
X-Test Failure Report |
Benchmark results, click to expandBenchmark authorization.GetDecisions Results:
Benchmark authorization.v2.GetMultiResourceDecision Results:
Benchmark Statistics
Bulk Benchmark Results
TDF3 Benchmark Results:
|
Benchmark results, click to expandBenchmark authorization.GetDecisions Results:
Benchmark authorization.v2.GetMultiResourceDecision Results:
Benchmark Statistics
Bulk Benchmark Results
TDF3 Benchmark Results:
|
|
Proposed Changes
buildChunkedKeyAccessObjectsskipped any KAS URL that a split named butSplitResult.KASPublicKeyshad no entry for. That silently drops the onlykey access object that would have let that KAS unwrap the share. In an
OR-group the TDF still decrypts, just against a smaller set of KAS servers
than the policy asked for -- and nothing in the output says so. If every
URL on a split is unresolved the share is unrecoverable outright, and the
failure surfaces much later as a generic "no valid key access objects
generated", or not at all if some other split still produced KAOs.
Treats a missing entry the same way an entry with an empty PEM was already
treated:
errKasPubKeyMissing, naming the split and the URL. A splitterthat cannot resolve a key it referenced has a bug, and creation time is
where it should be reported.
Checklist
Testing Instructions
The full DSPX-2604 stack — 20 PRs
mainmainmainmainmainmainmaindspx-2604-base-11= #3932 + #3934 + #3935dspx-2604-base-17= #3944 + #3945dspx-2604-base-19= #3947 + #3939Reviewable in parallel right now, since they sit directly on
mainand depend onnothing else: 01, 02, 04, 05, 06, 07, 08.
Why three PRs have a
dspx-2604-base-*base. A GitHub PR takes one base branch,but 11, 17 and 19 each build on more than one parent. The
base-*branches are emptymerge commits that exist only to join those parents so the PR diff shows exactly its
own change and nothing else. They contain no code, have no PR of their own, and go
away once their parents land — retarget the child onto
mainat that point.Wants a cross-SDK xtest run before merge: 15, 17 (and therefore 20). They touch
the KAS wire format.
Red checks you may see are network flakes, not this stack. Four distinct ones hit
this batch and all clear on re-run:
golangci-lint config verifytiming out onhttps://golangci-lint.run/.../golangci.v2.8.jsonschema.json(fails the wholego (<module>)job and fail-fast cancels its siblings), the bats installer getting a 403,Docker Hub timing out on
keycloak/keycloak:26.4, andbufreporting "the serverhosted at that remote is unavailable" while the Java SDK generates sources. The
govulncheckstep also emits##[error]annotations against the go1.25.11 stdlib, butit is
continue-on-error: trueand never fails a job — 01 bumps the toolchain andclears those annotations.