Skip to content

v2.15.0: 컨테이너가 스스로 토큰을 발급할 수 있게 한다 - #34

Closed
gejyn14 wants to merge 3 commits into
mainfrom
feature/v2.15.0-env-credentials
Closed

v2.15.0: 컨테이너가 스스로 토큰을 발급할 수 있게 한다#34
gejyn14 wants to merge 3 commits into
mainfrom
feature/v2.15.0-env-credentials

Conversation

@gejyn14

@gejyn14 gejyn14 commented Jul 20, 2026

Copy link
Copy Markdown
Owner

appkey/secretkey를 키체인 전용으로 둔 것은 의도된 제약이었습니다. 다만 실패 모드가 하나 남아 있었습니다: 키체인이 없는 컨테이너는 스스로 토큰을 발급할 수 없었습니다.

호스트에서 발급한 KIWOOM_TOKEN을 주입받는 것이 유일한 경로였고, 그 토큰이 만료되면 컨테이너는 복구할 방법이 없었습니다. 짧은 CI 작업에는 문제가 없지만 오래 도는 프로세스(MCP 서버 등)에는 치명적입니다.

이 PR은 그 제약을 의도적으로 완화합니다. 리뷰 시 이 결정 자체를 봐 주세요.

무엇

  • KIWOOM_APPKEY / KIWOOM_SECRETKEY (+ _FILE 변형) — 키체인보다 우선하며 모든 프로필에 적용됩니다. KIWOOM_TOKEN·KIWOOM_DOMAIN과 같은 방향입니다.
  • _FILE 변형이 컨테이너 권장 형태입니다: 도커·포드먼 시크릿은 /run/secrets/에 파일로 마운트되고, 값이 docker inspect/proc/<pid>/environ에 남지 않습니다.
  • KIWOOM_TOKEN_STORAGE문서를 쓰기 전에 실제로 돌려보고 찾은 결함입니다. env 자격증명만으로는 부족했습니다: 토큰 발급에는 성공하고도 save_token이 키체인에 쓰려다 KEYCHAIN_UNAVAILABLE(exit 1)로 죽었습니다.
  • auth status / config showappkey_source 추가 — env가 키체인을 조용히 덮으므로 실제 출처를 보고합니다. 값 자체는 노출하지 않습니다.

우선순위

순위 출처
1 KIWOOM_APPKEY / KIWOOM_SECRETKEY
2 KIWOOM_APPKEY_FILE / KIWOOM_SECRETKEY_FILE
3 OS 키체인

NAMENAME_FILE을 동시에 설정하면 어느 쪽이 이겼는지 조용히 달라지는 대신 INVALID_INPUT으로 즉시 실패합니다.

⚠️ 조용한 전환

셸에 KIWOOM_APPKEY를 export해 둔 사용자는 업그레이드 후 키체인 대신 그 값이 쓰입니다. 의도된 우선순위이지만 눈에 띄지 않으므로 appkey_source로 확인할 수 있게 했습니다.

이 저장소에서 실제로 벌어진 일이기도 합니다: 이 변경으로 개발자 셸에 떠 있던 KIWOOM_APPKEY가 즉시 12개 테스트를 깨뜨렸습니다. 종전에는 코드가 그 변수들을 무시했기 때문에 우연히 조용했을 뿐입니다. conftest에서 KIWOOM_*를 초기화해 테스트가 실행하는 사람의 실제 설정을 읽지 않도록 했습니다 — InMemoryKeyring이 OS 키체인을 대신하는 것과 같은 이유입니다.

검증

  • 2018 → 2046개 테스트, ruff 통과
  • 새 테스트를 변경 전 코드(worktree, main)에 대고 돌려 23개 중 20개가 실패하는 것을 확인했습니다 — 통과하는 3개는 기존 동작을 검증하는 것들입니다
  • 컨테이너 전 구간을 키체인 백엔드 없는 상태로 시뮬레이션해 확인했습니다
  • release-checker: Excel 최신(232행 재생성 후 셀 단위 비교), README 예제 147개 유효(샌드박스 HOME + keyring 스텁)

곁다리

README가 광고하던 "CodeQL 정적 분석"을 제거했습니다 — .github/workflows에 해당 워크플로가 없습니다.

gejyn14 added 3 commits July 21, 2026 00:50
키체인이 없는 컨테이너는 호스트에서 발급한 KIWOOM_TOKEN을 주입받는 것이
유일한 경로였고, 그 토큰이 만료되면 스스로 복구할 수 없었다. appkey/secretkey를
키체인 전용으로 둔 것은 의도된 제약이었지만 이 실패 모드를 남겼다.

- config._env_or_file(): NAME / NAME_FILE 양쪽 지원. 도커·포드먼 시크릿은
  파일로 마운트되므로 _FILE 변형이 컨테이너 권장 형태다. 값은 strip한다
  (시크릿 파일 끝 개행이 그대로 실리면 인증이 실패한다). 둘 다 설정하면
  어느 쪽이 이겼는지 조용히 달라지는 대신 INVALID_INPUT으로 즉시 실패.
- get_appkey/get_secretkey/is_configured: env > 키체인. KIWOOM_TOKEN·
  KIWOOM_DOMAIN과 같은 방향이며 모든 프로필에 적용된다.
- appkey_source(): "env"|"env_file"|"keychain"|None. env가 키체인을 조용히
  덮으므로 auth status/config show가 실제 출처를 보고한다. 값은 노출하지 않는다.
- get_token_storage(): KIWOOM_TOKEN_STORAGE env 지원. 이것이 없으면 env
  자격증명으로 토큰을 발급해도 save_token이 키체인에 쓰려다 죽어서, 자격증명을
  넣어줘도 컨테이너가 토큰을 발급할 수 없었다 (실제로 확인한 뒤 고쳤다).
- conftest: KIWOOM_* 환경변수를 매 테스트 초기화. 이 변경으로 개발자 셸에 떠
  있던 KIWOOM_APPKEY가 즉시 12개 테스트를 깨뜨렸다 — 종전에는 코드가 그
  변수들을 무시했기 때문에 우연히 조용했을 뿐이다.

주의: 셸에 KIWOOM_APPKEY를 export해 둔 사용자는 업그레이드 후 키체인 대신
그 값이 쓰인다. auth status의 appkey_source로 확인할 수 있다.

2018 → 2046 tests.
README의 CodeQL 주장도 함께 제거한다 — .github/workflows에 codeql.yml이 없고
grep 결과도 그 README 한 줄뿐이다. 없는 보안 검사를 광고하는 것은 신뢰를
결정하는 사람에게 정확히 잘못된 정보다 (v2.14.0에서 SECURITY.md를 정리한 것과
같은 이유).
앞 커밋에서 '.github/workflows에 codeql.yml이 없다'는 이유로 지웠는데,
CodeQL은 GitHub의 default setup으로 켜져 있어 워크플로 파일 없이 돈다.
PR #34의 체크에 'CodeQL'과 'Analyze (python)'이 통과로 찍힌다.

워크플로 파일이 없다는 것과 검사가 없다는 것은 다르다 — 파일만 grep하고
결론을 냈다.
@gejyn14

gejyn14 commented Jul 20, 2026

Copy link
Copy Markdown
Owner Author

MCP 구현을 별도 저장소(kiwoom-plugin)로 통합하기로 하여 kiwoom-cli의 MCP 관련 변경을 되돌립니다. env 자격증명(v2.15.0)은 MCP 서버의 컨테이너 자동 발급을 위한 것이었는데, 그 기능을 kiwoom-plugin의 토큰 주입 모델로 대체하면서 더 이상 필요하지 않습니다. 이 브랜치의 커밋은 필요하면 언제든 되살릴 수 있습니다.

@gejyn14 gejyn14 closed this Jul 20, 2026
@gejyn14
gejyn14 deleted the feature/v2.15.0-env-credentials branch July 20, 2026 22:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant