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-a11-f003 | 위반 코드 34종 중 22종이 어떤 test에서도 이름으로 확인되지 않는다 | http-client-and-resilience | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | case:analysis-finding-a11-f003 | 2026-09-01 | case-analysis-finding-a11-f003.body.md |
|
|
|
위반 코드 34종 중 22종이 어떤 test에서도 이름으로 확인되지 않는다
프로파일 검증기가 내는 위반 코드는 서른네 종이다. 그중 스물두 종은 어느 테스트에서도 이름으로 참조되지 않는다. 그리고 확인되지 않는 쪽에 사고에서 유래한 가드가 거의 전부 들어 있다.
관계
- 풀 상한 위반 코드는 발화할 수 없다 이 계수에서 참조 0 으로 나온 코드 중 하나다.
- 코드 자체가 옳아도 회귀를 막는 것은 test다 이 사례가 그 규칙의 형태다.
- 커버리지 gate 둘이 나란히 있고 하나는 발화할 수 없다 같은 계열의 검증 지형 사례다.
문제
프로파일 검증기가 위반 코드를 문자열로 낸다. 종류가 서른네 개다.
각 코드가 테스트에서 이름으로 확인되는지 셌다.
결론
열두 종은 한 건 이상 참조된다. 모두 신뢰나 이름 검증이나 평문이나 실험 프로토콜 계열이다.
스물두 종은 0 건이다.
문제는 개수가 아니라 어느 쪽이 비어 있는가다.
확인되지 않는 스물두 종에 사고에서 유래한 가드가 거의 전부 들어 있다.
서버 주소 위조 우회와 기록의 개인정보와 조용한 프로토콜 강등과 아무 일도 하지 않는 설정과 재지향을 조용히 무시하는 경우다.
테스트 두 개가 그룹으로 몇 개를 묶어 확인한다. 하나의 메서드가 세 위반을 한 번에 본다.
나머지 스물두 종은 분기를 지워도 초록으로 남는다.
코드 자체는 현재 옳다. 위험은 회귀다.
판정은 P3 다.
수정은 코드별 최소 경우를 매개변수 테스트 한 벌로 놓는 것이다. 서른네 종이 모두 결정적으로 정렬된 목록을 내므로 그 형태가 자연스럽다.
검증 환경
확인 방식 : 위반 코드 문자열의 테스트 소스 집합 참조 계수 소스 수정 : x
재현 조건
원문은 final/evidence/raw/168 계열에 있다.
- 검증기가 내는 위반 코드 목록을 만든다.
- 저장소의 테스트와 테스트킷 소스 집합에서 각 문자열을 검색한다.
- 참조 건수로 두 무리를 나눈다.
- 참조 0 인 무리에 어떤 성격의 가드가 들어 있는지 본다.
- 그룹으로 확인하는 테스트가 몇 개를 덮는지 확인한다.
본문
ClientProfileValidator가 내는 코드는 34종이다. 저장소 전체의 test/testkit source set에서 그 문자열을 참조하는 파일 수를 세면(168-... §8.4b) 다음과 같다.
| test 참조 | 코드 수 | 예 |
|---|---|---|
| 1건 이상 | 12 | TRUST_ALL_FORBIDDEN(3) · HOSTNAME_VERIFICATION_REQUIRED(2) · PLAINTEXT_*(2) · HTTP3_STABLE_FORBIDDEN(2) … |
| 0건 | 22 | DYNAMIC_TARGET_PROXY_UNSUPPORTED · FULL_URL_RECORDING_FORBIDDEN · BODY_LOGGING_FORBIDDEN · REACTIVE_REDIRECT_UNSUPPORTED · HTTP2_REQUIRED_TRANSPORT_UNSUPPORTED · TLS_PROTOCOL_SET_REQUIRED · DNS_TIMEOUT_UNSUPPORTED · PROXY_CREDENTIAL_UNSUPPORTED · RETRY_POLICY_CONTRADICTS_ATTEMPTS · MISSING_PRODUCTION_SETTING · ALLOWED_HOST_MISMATCH · ALLOWED_PORT_MISMATCH … |
ClientProfileValidator 참조 위치
:::evidence key="analysis-finding-a11-f003" alt="코드베이스에서 ClientProfileValidator 를 검색한 출력 6줄. 이 기록이 세는 참조가 그 출력에 그대로 보인다." caption="ClientProfileValidator 코드베이스 검색 — 6줄 · exit 0" zoom="true" :::
문제는 개수가 아니라 어느 쪽이 비어 있는가다
확인되지 않는 22종에는 §2가 인용한 사고 유래 가드가 거의 전부 들어 있다 — SSRF 우회(DYNAMIC_TARGET_PROXY_UNSUPPORTED), 로그의 PII(FULL_URL_RECORDING_FORBIDDEN·BODY_LOGGING_FORBIDDEN), 조용한 프로토콜 다운그레이드(HTTP2_REQUIRED_TRANSPORT_UNSUPPORTED·TLS_PROTOCOL_SET_REQUIRED), 아무 일도 하지 않는 설정(DNS_TIMEOUT_UNSUPPORTED·PROXY_CREDENTIAL_UNSUPPORTED), 그리고 리다이렉트를 조용히 무시하는 경우(REACTIVE_REDIRECT_UNSUPPORTED).
확인하지 못한 것
각 분기를 실제로 지우고 테스트가 초록으로 남는지 확인하지 않았다. 참조 계수상 그 결과가 나온다.
test 두 개(ClientProfileValidatorTest 106줄)가 그룹으로 몇 개를 묶어 확인하지만(rejectsSimpleFactoryAndUnacknowledgedHttp3AndJdkRoutePool), 나머지 22종은 분기를 지워도 초록으로 남는다. 코드 자체는 현재 옳다 — 위험은 회귀다. P3. 수정은 @ParameterizedTest로 코드별 최소 케이스를 한 벌 놓는 것이고, 34종이 모두 결정적으로 정렬된 목록을 내므로 그 형태가 자연스럽다.