DongHyeonkaandClaude Fable 5.1
b25357c48a
- analysis/·source-index·state.json 을 final/document.md 제2부·제3부로 접었다. SSOT 는 하나다 - 파일럿 — commit-ambiguity-as-a-result 를 새 기준으로 재선별. 후보 14 → 글감 5 (PROMOTE 5 · MERGE_INTO 3 · KEEP_IN_SSOT 4 · 보류 2). 기록 5건을 다시 썼고 그림 1개를 techviz 로 만들었다 - 재선별이 잡은 것: 제1부 §6.2·§11.1 이 자기 §13.2 와 어긋나 있었다(레인을 안 돌렸다 vs 돌렸다) — 정정. 이미 답이 나와 있던 Question 을 HEAD 재실행 질문으로 다시 세웠다. Concept 이 인용한 코드가 SSOT 에 없어 뺐다 - candidateScope·sourceRepository 기록. 나머지 43개 주제는 재선별 대기(PENDING 905) Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
70 lines
3.6 KiB
Markdown
70 lines
3.6 KiB
Markdown
---
|
|
kind: CONCEPT
|
|
slug: messaging-admin-api-c03
|
|
title: 서명 대상 객체가 존재한다는 것이 4-eyes 통과를 뜻한다
|
|
topic: schema-and-wire-models
|
|
project: clean-architecture-backend-template
|
|
status: 게시 전
|
|
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
|
|
rootTreeNode: concept:messaging-admin-api-c03
|
|
evidenceCapturedOn: 2026-09-01
|
|
assets:
|
|
- key: messaging-admin-api-c03
|
|
file: ../../../final/evidence/rendered/messaging-admin-api-c03.svg
|
|
- key: messaging-admin-api-c03-diagram
|
|
file: ../../../final/assets/diagrams/messaging-admin-api-c03.svg
|
|
evidence:
|
|
- ../../../final/evidence/raw/messaging-admin-api-c03.txt
|
|
source:
|
|
- 원본 분석 절은 final/document.md#a19-messaging-admin-api#L185 이다.
|
|
module: messaging-admin-api
|
|
---
|
|
|
|
# 서명 대상 객체가 존재한다는 것이 4-eyes 통과를 뜻한다
|
|
|
|
8개 필드. 그중 requestedBy 가 생성자에서 4-eyes 를 강제한다.
|
|
|
|
## 본문
|
|
|
|
<!-- body:start -->
|
|
|
|
`ApprovalGrant` 는 8개 필드다. 그중 `requestedBy` 가 생성자에서 4-eyes 를 강제한다. "우회할 수 없는 자리에 표현했다" — 검사기가 아니라 **record 생성자**에 두었으므로, 서명 대상 객체가 존재하는 것 자체가 4-eyes 통과를 뜻한다.
|
|
|
|
## canonicalForm 이 길이 접두 인코딩인 것
|
|
|
|
버전 접두 `"v1"` 이 앞에 있어 형식 교체 여지를 남긴 것도 의도적으로 보인다. 이 규칙이 계획 다이제스트 쪽에는 적용되지 않았다 — §12.3(b).
|
|
|
|
## 승인 검증이 도는 순서
|
|
|
|
:::evidence key="messaging-admin-api-c03-diagram" alt="다이제스트 대조에서 윈도우로 일치가 건너가고 윈도우에서 서명 파싱으로 기간 안이 건너가고 서명 파싱에서 HMAC 으로 형식 통과가 건너간다" caption="승인 검증이 도는 순서" zoom="false"
|
|
:::
|
|
|
|
**다이제스트 대조 → 윈도우 → 16진 파싱 → HMAC**. 다이제스트를 먼저 보는 이유가 주석에 있다.
|
|
|
|
## ApprovedReplayPlan 참조 위치
|
|
|
|
:::evidence key="messaging-admin-api-c03" alt="코드베이스에서 ApprovedReplayPlan 를 검색한 출력 11줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="ApprovedReplayPlan 코드베이스 검색 — 11줄 · exit 0" zoom="true"
|
|
:::
|
|
|
|
## 검증하는 쪽은 반드시 서명할 수도 있다
|
|
|
|
`sign(...)` 이 같은 클래스에 public 으로 있고, javadoc 이 그 위험을 스스로 명시한다. 이 문장과 대칭키 선택이 만드는 구조적 결과가 §17 의 한 항목이다.
|
|
|
|
## javadoc 이 세지 않는 두 검사
|
|
|
|
실제 분기는 여섯이다. 5번에는 별도 인라인 주석이 있어 의도된 검사임이 분명하다. "검사는 있는데 클래스 javadoc 이 세지 않는" 두 항목이, 동시에 **어떤 테스트에도 도달하지 않는** 두 항목이다(`EVD-303`, §12.1).
|
|
|
|
## dry run 을 항상 허용하는 근거
|
|
|
|
"the way to make operators plan before they act is to make planning free". 이것은 보안 완화가 아니라 행동 설계다.
|
|
|
|
## 토폴로지를 두 번 보는 이유
|
|
|
|
`ApprovedReplayPlan` 생성자(`:19-52`)와 `requireExecutable(now, currentTopologyVersion)`(`:54-85`)이 토폴로지를 **두 번** 본다. 승인이 서명된 토폴로지와 계획이 계산된 토폴로지가 다를 수 있으므로 둘 다 현재와 대조한다.
|
|
|
|
## 진행처럼 보이는 루프
|
|
|
|
`ApprovedRedrivePlan` 은 같은 네 검사에 더해 `loopAcknowledged` 를 별도 필드로 갖고, `requireExecutable` 의 마지막 분기가 그것을 강제한다. "진행처럼 보이는 루프" 는 이 리프에서 반복되는 관점이다 — 대시보드에서 옳아 보이는 실패를 타입으로 막는다.
|
|
|
|
<!-- body:end -->
|