fix(core): protect canonical evidence runtime types - #63
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthrough감사 이벤트와 작업 분석 증거의 런타임 타입 검증을 강화했습니다. 내장 타입 서브클래스를 거부하고, 허용된 타임스탬프를 UTC로 고정합니다. 생성 후 변조와 변환 예외에 대한 회귀 테스트를 추가했습니다. Changes런타임 타입 무결성
Estimated code review effort: 4 (Complex) | ~45 minutes Merge Risk: 🟡 Moderate · up to This change hardens audit and job-analysis evidence validation, but the changed job-analysis file may bypass manifest integrity tracking, and one regression test can accept an incorrect error message. Resolve these release-integrity and test-contract gaps before merge. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
📝 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 |
|
@opencode-agent Please review the current unchanged head against protected |
|
@coderabbitai review Please review exact head |
|
Fresh exact-head evidence update for CodeQL PR remains Draft. No Ready/merge transition is justified while CodeQL lacks the authoritative current-head terminal verdict and the live ruleset still requires one qualifying approval. |
|
Fresh unchanged-head CodeQL canary result on |
|
Fresh owner-path update: central CodeQL has now produced terminal SUCCESS on independent Orgmetra exact head |
|
Central owner checkpoint (Orgmetra source unchanged): The owner is still mutable and unintegrated. Its fresh Security/SAST/Python Security/CodeQL evidence and qualifying independent approval are not terminal, so Orgmetra #63's exact-head CodeQL failure remains authoritative. No attempt-5 rerun or product-source change is justified until normal protected owner integration is verified. |
|
Central owner checkpoint update (2026-09-08 UTC; product head unchanged)
The protected handler also reproduced the multi-language wake race in 34220757095: actions started required run Orgmetra #63 remains |
|
Central owner checkpoint updated without changing Orgmetra head
Orgmetra Foundation, Security, and SAST evidence is preserved, but central owner GREEN plus current-head CodeQL and independent approval remain required. No leaf workaround or source mutation was introduced. |
|
Current upstream evidence chain (2026-09-08): |
|
Upstream delta after the prior checkpoint: |
|
Central owner checkpoint — 2026-09-08 The CodeQL handler repair is now |
|
Central base correction — 2026-09-08
|
|
Central owner checkpoint: product head remains unchanged at |
|
Central-owner checkpoint — 2026-09-09
|
Scope
Canonical shared HRIS-kernel audit/runtime-evidence lane for Orgmetra. It owns shared audit and Job Analysis value integrity; consumer lanes do not copy mutable #63 source.
Current exact head is
d88800a5ca3ca15df332e8def5e25064c46e4005on protecteddevelop@eb9757f8649aaad026a9865508d9aad50c1a7a4f, open · Draft · mechanically mergeable. Draft remains intentional because current-head CodeQL and Strix are terminal RED and independent approval is absent; no predecessor verdict transfers.Retained Job Analysis repairs
The prior runtime hardening remains intact: #211–#214 moved audit/time evidence to exact detached standard-library authority and removed process-local issuance authority. Intervening ordinary-forward Job Analysis commits
74f7f2c444be421deec08557ef46ae8da6aca90a,b846304b7da4d97529461b3db5e4eb1e049da345, and510b50b9faa4fae8c3404752e464fd17ba8124aewere read and adopted rather than treated as a race.#277 owns the Job Analysis nested UUID finding. Test-first
3bb641bd...added executable nested-payload/caller-alias regressions;03ba635e...captures.intonce, requires an exact built-inint, enforces range/nil/max, reconstructs owned UUID values, and stores the detached result.4ab735df...scopes the focused regressions. Foundation34292861193then exposed a real compatibility RED in the old custom-timezone test contract;4ad9363af660f137b4c8c575b68113e7883c8129corrected only that superseded expectation and Foundation34293147207was terminal SUCCESS.#278 audit nested UUID RED -> source repair -> manifest GREEN
Fresh intervening ordinary-forward commits after
4ad9363...implemented the dedicated audit slice already reserved for #278:c423de6205fd22f654d4602cc4eab54295709515adds audit regressions for executable/non-int nested UUID payloads, exact integers outside the 128-bit range, and caller UUID alias mutation after construction.afd47f07408f03048f9cac89ee60e2b03614615fadds_freeze_uuid: capture.intonce, require exact built-inint, range-check before nil/max equality, then reconstruct ownedUUID(int=identity)event/tenant values before tuple storage.afd47f...Foundation run34293586152produced a real RED atValidate foundation pack:audit.pyis part of the deterministic manifest subset, but the branch still carried predecessor SHA/bytes/lines. This was not treated as a reason to revert the security repair.d88800a5ca3ca15df332e8def5e25064c46e4005reseals the existingaudit.pymanifest entry to SHA-256f7e1d56073bdabcd7051f9757c17b9f009d9384a6bad07cf4ef9c936f2ff7876, 12,950 bytes, 314 lines. It does not expand the canonical manifest path set.The earlier CodeRabbit suggestion to add Job Analysis files to
manifest.jsonremains invalid:tests/validate_repository.pyrequires exact set equality and those Job Analysis paths are intentionally outsideREQUIRED. #278 differs becauseaudit.pyis already sealed and therefore its existing inventory entry had to be updated.Exact-head verification
On exact
d88800a5...:34294884750: SUCCESS — the manifest repair and owned 100% statement/branch coverage gate pass.34294884604: SUCCESS.34294884676: SUCCESS.34294885141: SUCCESS.34294884932: SUCCESS.34294883368: SUCCESS.34294884955: SUCCESS.34294884616: FAILURE. Actions consumer102289273879failed enforcement at 00:26:32Z and Python consumer102289273811at 00:26:56Z; only afterward did current-head dispatch102289748560start at 00:27:01Z and complete SUCCESS at 00:27:08Z. This is the central publication/settlement ordering RED already handed to.github#2040; no unchanged-head rerun or leaf workaround is used.34294884985: FAILURE. Admission, trusted materialization, CO sidecar provisioning, Strix installation, andorchestrator/freepreparation all succeeded;Run Strix (quick)emitted artifact10083683583(sha256:0936587636b5689136fb28221d55b84982fa8241950d087cb52818cb2299887f) but terminal evidence is internally inconsistent and the reported HIGH IDOR is not established against the authoritative application boundary.All visible inline review threads are resolved. Fresh review enumeration still has no ruleset-qualifying independent
APPROVED; no self-approval or stale review is transferred.Strix finding verification and owner handoff
The Strix artifact reports HIGH CWE-863 against
JobAnalysisSnapshot.__post_init__, claiming that direct construction with arbitrary tenant/job UUIDs bypasses authorization. Current code does not support that exploit model:JobAnalysisSnapshotis a pure immutable HRIS-kernel evidence value; construction has no persistence side effect and the kernel deliberately does not depend on authenticated application context.services/job-analysis-api/src/orgmetra_job_analysis_api/snapshot.pyauthorizes thejob_analysis_snapshot:<id>resource withauthorize_resource_fields(...), rebuilds the posted tenant against the authorized route tenant, and only then invokes the write port.tasks,ksao_requirements, andtask_ksao_links, which violates the constructor's non-empty evidence invariants.Adding session/auth dependencies to the kernel value object would invert the DDD dependency direction and is therefore rejected. The bounded-context selection gap has been handed to central
.github#695: when kernel Job Analysis changes, Strix should receive the narrow trusted-base job-analysis API authorization/persistence context and require an IDOR to demonstrate a path to an authoritative port. Separately,.github#2026received this artifact as a terminal-evidence consistency canary becauserun.jsonsays completed/success and the narrative says no high-impact vulnerability while SARIF/vulnerability ledger contains one HIGH finding; the gate then misclassifies the terminal run asSTRIX_PROVIDER_UNAVAILABLE.Dependencies and owner boundaries
#64 remains the canonical generic People mutation writer and #65 the purpose-bound authorization/Job Analysis consumer owner. Both consume #63 only after normal protected integration. #163/#165 remain downstream.
docs/product-technical-gap-baseline.mdremains #100 single-writer; this branch does not compete for it.Central CodeQL repair remains
.github#2040, currently open · Ready · mechanically mergeable at exact6706c231ab06a3c91c43fdb5b989cfcd79fff593against protected.github/main@7fd571dbcdbae6acf29d8f4ee704d7ba6297e4db. #63 will not use blind reruns, sleeps, synthetic statuses, predecessor verdicts, or leaf gate weakening while the exact consumer canary reproduces the settlement defect.No force push, destructive rebase, source-copy dependency, no-op retrigger, administrator bypass, gate weakening, self-approval, premature Ready, merge, Close, or release claim is used.