fix(lab): name the ACL failure code in the publisher key error - #2265
Conversation
|
✅ Deterministic PR hygiene checks passed. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review. 📝 WalkthroughWalkthroughChangesACL failure diagnostics
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: 🟡 Moderate · up to The code change is localized, but the PR explicitly remains in draft with all required readiness checklist items unchecked, so it is not merge-ready until those checks are completed. Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 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 |
✅ READY
Review readiness checklist
✅ 4/4 boxes ticked. This pull request is already Ready for Review. |
리뷰 · 우선순위 32 / 80#2152 Windows CI 조각임. 지금 이 PR이 테스트 네 장. ETIMEDOUT / EICACLS / EACLIDENTITY 각각 메시지에 코드. EACLIDENTITY는 고친 게 아님. 진단임. #2152 본체(윈도우 샤드 실패)는 열림. 점수 48. 이건 그 로그를 읽을 수 있게 만드는 선행임. Grok/Responses 레인 아님. #2188 사이드카, #2190 draft 체크리스트 0/4. 비전공자가 윈도우 박스 없이 로그를 읽으려면 코드가 메시지에 있어야 함. 그 점은 맞음. 그래도 핫 레인이 아님. 원인은 다음 디스패치가 찍음. 해결방안: 체크리스트 채우고 draft 해제 후 이 댓글은 grok-bot이 작성했습니다 |
Every required publisher-key ACL harden failure reached CI as one fixed string, "public publisher key ACL hardening did not complete". The discriminator existed only on `cause`, which the test reporter does not print, so the three causes that occur on the Windows leg -- ETIMEDOUT (the budget), EACLIDENTITY (the effective-SID lookup) and EICACLS (icacls refusing the path) -- were indistinguishable from a log, and each needs a different fix. Append the bounded errno-shaped code to the message. Only the code crosses that boundary, re-checked for shape here rather than trusted, so a pathname or username component cannot reach a public log through it. A cause without such a code keeps the previous message unchanged. Refs lidge-jun#2152.
6015c98 to
f882de0
Compare
|
Rebased onto The full local suite is 14029 tests, 1 failure, and that failure is not this change: A Windows path-separator assertion in Nothing else in the suite fails. I will open that one separately; it is unrelated to the publisher key path. Re-verified on the rebased head: CodeRabbit reported no actionable comments, and CI is green on the pre-rebase head. |
Ingwannu
left a comment
There was a problem hiding this comment.
Approved on exact head f882de0. The Grok maintainer review is correct: this is a bounded diagnostic change, not a speculative Windows ACL fix. Only an errno-shaped code can enter the public failure message; the stable error code and cause behavior remain unchanged. I verified 204 focused Lab/Windows tests and typecheck on the rebased head. This should merge to dev while #2152 remains open for the diagnostic result.
Refs #2152.
What this changes
CL-10 public bundle and publisher > builds deterministic bundle ids and digestsfails on the Windows leg with:That message is the same string for every required-harden failure. You wrote in #2152 that telling the three causes apart needs
error.cause.codeand that you would rather leave the question open than aim a fix at the wrong one. This PR does not guess at the cause — it puts the code in the message, so the next dispatched run answers the question by itself.After this change the same failure reads
... did not complete (ETIMEDOUT),(EACLIDENTITY)or(EICACLS).Why the message and not just
causecauseis already attached —requirePublisherKeyAclsets it — but the reporter printsmessageand the stack, which is why the trace in the issue has no cause line. Confirmed on Windows by driving the failure through the existing seams and reading both fields:Identical messages, different causes. Nothing in the log distinguishes them.
What crosses the boundary
Only the errno-shaped code, and its shape is re-checked at the point of use rather than trusted:
sanitizedAclErroralready allowlists which codes it copies, so this is the second bound rather than the only one — it means a code added there later cannot widen what a public log prints without also passing this shape. A code in that shape has no separator, no lowercase and a bounded length, so it cannot carry the key pathname or the username component inside it. A cause with no such code keeps the previous message byte-for-byte, so no failure gains an empty().PublicEvidenceValidationError.codestayspublic_publisher_key_unsafeandcauseis untouched, so nothing that branches on either changes.One observation about the CI failure itself, offered as a lead, not a claim
Running
bun test tests/lab-public-evidence.test.tsalone on Windows 11, unelevated, Bun 1.3.14: 14 pass, 0 fail. So it is not categorically broken on Windows, which narrows it to the runner.Of your three candidates, one has a property that matches the shape you described — the first call failing and the very next one succeeding on a different temp home. A successful SID lookup is process-cached in
windows-user-principal.ts; a failed one is not, so a cold or contended first lookup fails alone and the next call re-runs it warm. Driving exactly that through the seam reproduces your pattern:That is consistent with EACLIDENTITY, not evidence for it — ETIMEDOUT would look similar if the memo key differed per stage. I have not reproduced the CI failure itself and am not proposing a fix for it here. The point of this PR is that the next
platform-windowsdispatch will print which one it was.Verification
Windows 11, Bun 1.3.14, on this branch:
Measured on both sides: the same 8 suites on the unpatched tree are
52 pass, 1 skip, 0 failacross 53 tests, and 57 tests here. The delta is the 4 added cases and nothing else.Mutation-checked. Reverting only the message to the old fixed string, keeping the tests:
Exactly the three naming cases, while
keeps the plain messagestays green — it covers the other branch, so it should not move, and it does not.Tests added
Four cases in
lab-public-security-regressions.test.ts:setWindowsPrincipalRunnerForTests, one module further out than the icacls runner, so it also pins that the code survives the hand-off fromwindows-user-principalrather than only the icacls path.afterEachnow also clears the principal runner, so an injected lookup cannot leak into a later test in the file.Review readiness checklist
This PR stays in draft until every box below is ticked. Tick all four boxes once the requirements are met:
All CI tests are green on my local testing.
I pushed my PR to the latest dev commit.
I resolved all correct Codex and CodeRabbit findings.
My PR is ready for review.
Summary by CodeRabbit