DongHyeonkaandClaude Opus 5
b2963105a8
The keycloak project ended with four open questions that design could not
settle. A two-VM lab was built to answer them by measurement, and this is
that material: 26 experiments, 125 raw command outputs, 22 browser captures.
Follows the import procedure in README.md.
source/ the originating repository verbatim — 78 documents, 28 SVGs,
8 manifests, plus .source-revision recording the commit
final/ the SSOT
document.md 729 lines written from the 29 experiment documents, not
concatenated: what was predicted, what was measured, and
where the measurement itself was wrong
evidence/raw 125 outputs, flattened to <experiment>__<file> because
the originals collided (01-baseline.txt appeared three
times) and the audit only globs the top level
evidence/meta one per raw file; command and exitCode are null and the
README says why rather than inventing them
evidence/browser 22 captures
assets/ three diagrams through techviz
.techviz/ their VizSpecs
A separate project rather than an addition to keycloak: the B-layer answers
that project's four questions, but the A, C and D layers are about cluster
failure, SSO and operations, and one document.md should hold one subject.
The four question records there can point here through 관계.
Recorded rather than papered over: only three of the 28 diagrams were
remade. The repository forbids hand-drawn SVG and forbids titles inside the
canvas; all 28 originals carry both, so converting them is redrawing, not
reformatting. They stay in source/ and the gap is written into the document.
verify-pipeline.py passes. audit-records.py reports no issues.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
5.4 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, evidenceCapturedOn, body, assets, evidence, source
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | evidenceCapturedOn | body | assets | evidence | source | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CASE | analysis-finding-a09-f004 | 그러나 R0 경계가 문서에만 있고 compile 경로에서 닫히지 않는다 | file-transfer-and-storage | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | case:analysis-finding-a09-f004 | 2026-09-01 | case-analysis-finding-a09-f004.body.md |
|
|
|
그러나 R0 경계가 문서에만 있고 compile 경로에서 닫히지 않는다
직접 전송 능력이 아직 배선되지 않았다고 README 가 선언한다. 그런데 설정은 그 능력을 계속 받아들이고 런타임은 자격증명을 쥔 서명자를 실제로 만든다. 만들어진 제공자를 꺼내 가는 코드는 없다.
관계
- 두 개의 outbox 중 하나만 조립되어 있다 같은 형태의 미조립 사례다.
- production 판정이 두 개의 리터럴 프로파일 이름에 걸려 있다 같은 리프의 다른 사례이자 반대 사례다.
- 문서가 선언한 경계는 코드가 닫아야 경계다 이 사례가 그 규칙의 형태다.
문제
README 가 직접 업로드와 직접 다중 파트가 아직 배선되지 않았다고 적는다.
그 선언이 코드로도 강제되는지 확인했다.
결론
강제되지 않는다. 네 단계로 확인된다.
첫째, 두 능력은 목적지 요구사항으로 선언할 수 있고 바인딩 컴파일러가 그것을 제공자 능력으로 번역한다.
둘째, 제공자 바인딩의 프로파일 컴파일은 자체 호스팅 구현에 대해서만 이 두 주장을 거부한다. 정확한 판본이 조건부 관리 변형을 기본 지원한다고 주장할 수 없다는 이유다. 클라우드 프로파일에는 대응하는 거부가 없다.
셋째, 그러면 제공자 기여자가 두 스위치 중 하나라도 켜져 있을 때 서명자를 할당하고 직접 전송 제공자와 직접 다중 파트 제공자를 만들어 선택 팩토리에 넣는다.
넷째, 그 둘을 팩토리에서 꺼내 가는 코드가 없다. 전수 검색 결과가 0 이다.
즉 클라우드 바인딩에서 직접 업로드를 요구하는 배포는 시작을 통과하고 서명자를 할당하고 두 제공자를 조립하고, 직접 전송 포트는 여전히 하나도 얻지 못한다.
README 가 말한 미배선은 사실이다. 그 사실을 강제하는 것이 문서뿐이다.
이 리프 안에 정반대의 사례가 있어서 대비가 분명하다.
개발용 제공자는 운영 프로파일에서 컴파일 시점에 거부된다. 자체 호스팅 구현의 능력 과대 주장도 컴파일 시점에 거부된다.
같은 파일이 같은 종류의 자격 없음 판정을 클라우드와 직접 전송 조합에 대해서만 하지 않는다.
판정은 P2 다.
데이터 위험은 없다. 없는 포트는 호출될 수 없다.
위험은 둘이다. 운영자가 켰다고 믿는 기능이 없다는 것과, 아무도 쓰지 않는 서명 자격증명 핸들이 프로세스 수명 동안 살아 있다는 것이다.
수정은 셋 중 하나다. 조정자를 조건부로 조립하거나, 미배선 동안 두 능력 요구를 제공자 종류와 무관하게 컴파일 단계에서 거부하거나, 능력이 켜져도 서명자를 만들지 않도록 조립을 뒤로 미루는 것이다.
검증 환경
확인 방식 : 바인딩 컴파일러와 제공자 기여자 코드 확인, 소비자 전수 검색 소스 수정 : x
재현 조건
원문은 final/evidence/raw/154 계열에 있다.
- README 의 미배선 선언을 읽는다.
- 두 능력이 목적지 요구사항으로 선언 가능한지 확인한다.
- 프로파일 컴파일에서 어느 제공자에 대해 거부가 있는지 확인한다.
- 제공자 기여자가 어떤 조건에서 서명자를 만드는지 확인한다.
- 만들어진 두 제공자를 팩토리에서 꺼내는 코드를 검색한다.
본문
R0 경계가 문서에만 있고 compile 경로에서 닫히지 않는다.
문서에만 있는 R0 경계
:::evidence key="analysis-finding-a09-f004" alt="분석 문서 analysis/09-adapter-outbound-objectstorage.md 에서 이 기록의 근거 절을 그대로 잘라낸 15줄. 코드베이스를 측정한 것이 아니라 원본 판정이 무엇을 적었는지를 보여 준다." caption="analysis/09-adapter-outbound-objectstorage.md 발췌 — 15줄" zoom="true" :::
데이터 위험은 없다
없는 port는 호출될 수 없다. P2.
위험 둘
(a) 운영자가 켰다고 믿는 기능이 없다는 것, (b) 아무도 쓰지 않는 서명 자격증명 핸들이 프로세스 수명 동안 살아 있다는 것.
수정 방향 셋
coordinator를 조건부로 조립하거나, R0인 동안 DIRECT_UPLOAD/DIRECT_MULTIPART 요구를 compile 단계에서 provider 종류와 무관하게 거부하거나, capability가 켜져도 presigner를 만들지 않도록 조립을 뒤로 미루는 것.
확인하지 못한 것
클라우드 바인딩으로 실제로 띄워 서명자가 살아 있는 것을 확인하지 않았다. 조립 조건상 그 결과가 나온다.