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>
113 lines
5.4 KiB
Markdown
113 lines
5.4 KiB
Markdown
---
|
|
kind: CASE
|
|
slug: analysis-finding-a09-f004
|
|
title: 그러나 R0 경계가 문서에만 있고 compile 경로에서 닫히지 않는다
|
|
topic: file-transfer-and-storage
|
|
project: clean-architecture-backend-template
|
|
status: 게시 전
|
|
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
|
|
rootTreeNode: case:analysis-finding-a09-f004
|
|
evidenceCapturedOn: 2026-09-01
|
|
body: case-analysis-finding-a09-f004.body.md
|
|
assets:
|
|
- key: analysis-finding-a09-f004
|
|
file: ../../../final/evidence/rendered/analysis-finding-a09-f004.svg
|
|
evidence:
|
|
- ../../../final/evidence/raw/analysis-finding-a09-f004.txt
|
|
source:
|
|
- 원본 분석 절은 analysis/09-adapter-outbound-objectstorage.md#L485 이다.
|
|
---
|
|
|
|
# 그러나 R0 경계가 문서에만 있고 compile 경로에서 닫히지 않는다
|
|
|
|
직접 전송 능력이 아직 배선되지 않았다고 README 가 선언한다. 그런데 설정은 그 능력을 계속 받아들이고 런타임은 자격증명을 쥔 서명자를 실제로 만든다. 만들어진 제공자를 꺼내 가는 코드는 없다.
|
|
|
|
## 관계
|
|
|
|
- **두 개의 outbox 중 하나만 조립되어 있다**
|
|
같은 형태의 미조립 사례다.
|
|
- **production 판정이 두 개의 리터럴 프로파일 이름에 걸려 있다**
|
|
같은 리프의 다른 사례이자 반대 사례다.
|
|
- **문서가 선언한 경계는 코드가 닫아야 경계다**
|
|
이 사례가 그 규칙의 형태다.
|
|
|
|
## 문제
|
|
|
|
README 가 직접 업로드와 직접 다중 파트가 아직 배선되지 않았다고 적는다.
|
|
|
|
그 선언이 코드로도 강제되는지 확인했다.
|
|
|
|
## 결론
|
|
|
|
강제되지 않는다. 네 단계로 확인된다.
|
|
|
|
첫째, 두 능력은 목적지 요구사항으로 선언할 수 있고 바인딩 컴파일러가 그것을 제공자 능력으로 번역한다.
|
|
|
|
둘째, 제공자 바인딩의 프로파일 컴파일은 자체 호스팅 구현에 대해서만 이 두 주장을 거부한다. 정확한 판본이 조건부 관리 변형을 기본 지원한다고 주장할 수 없다는 이유다. 클라우드 프로파일에는 대응하는 거부가 없다.
|
|
|
|
셋째, 그러면 제공자 기여자가 두 스위치 중 하나라도 켜져 있을 때 서명자를 할당하고 직접 전송 제공자와 직접 다중 파트 제공자를 만들어 선택 팩토리에 넣는다.
|
|
|
|
넷째, 그 둘을 팩토리에서 꺼내 가는 코드가 없다. 전수 검색 결과가 0 이다.
|
|
|
|
즉 클라우드 바인딩에서 직접 업로드를 요구하는 배포는 시작을 통과하고 서명자를 할당하고 두 제공자를 조립하고, 직접 전송 포트는 여전히 하나도 얻지 못한다.
|
|
|
|
README 가 말한 미배선은 사실이다. 그 사실을 강제하는 것이 문서뿐이다.
|
|
|
|
이 리프 안에 정반대의 사례가 있어서 대비가 분명하다.
|
|
|
|
개발용 제공자는 운영 프로파일에서 컴파일 시점에 거부된다. 자체 호스팅 구현의 능력 과대 주장도 컴파일 시점에 거부된다.
|
|
|
|
같은 파일이 같은 종류의 자격 없음 판정을 클라우드와 직접 전송 조합에 대해서만 하지 않는다.
|
|
|
|
판정은 P2 다.
|
|
|
|
데이터 위험은 없다. 없는 포트는 호출될 수 없다.
|
|
|
|
위험은 둘이다. 운영자가 켰다고 믿는 기능이 없다는 것과, 아무도 쓰지 않는 서명 자격증명 핸들이 프로세스 수명 동안 살아 있다는 것이다.
|
|
|
|
수정은 셋 중 하나다. 조정자를 조건부로 조립하거나, 미배선 동안 두 능력 요구를 제공자 종류와 무관하게 컴파일 단계에서 거부하거나, 능력이 켜져도 서명자를 만들지 않도록 조립을 뒤로 미루는 것이다.
|
|
|
|
## 검증 환경
|
|
|
|
확인 방식 : 바인딩 컴파일러와 제공자 기여자 코드 확인, 소비자 전수 검색
|
|
소스 수정 : x
|
|
|
|
## 재현 조건
|
|
|
|
원문은 final/evidence/raw/154 계열에 있다.
|
|
|
|
1. README 의 미배선 선언을 읽는다.
|
|
2. 두 능력이 목적지 요구사항으로 선언 가능한지 확인한다.
|
|
3. 프로파일 컴파일에서 어느 제공자에 대해 거부가 있는지 확인한다.
|
|
4. 제공자 기여자가 어떤 조건에서 서명자를 만드는지 확인한다.
|
|
5. 만들어진 두 제공자를 팩토리에서 꺼내는 코드를 검색한다.
|
|
|
|
## 본문
|
|
|
|
<!-- body:start -->
|
|
|
|
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를 만들지 않도록 조립을 뒤로 미루는 것.
|
|
|
|
## 확인하지 못한 것
|
|
|
|
클라우드 바인딩으로 실제로 띄워 서명자가 살아 있는 것을 확인하지 않았다. 조립 조건상 그 결과가 나온다.
|
|
|
|
<!-- body:end -->
|