[20260805] cryptography 50.0.0 보안 취약점 대응 (GHSA-g6cj-pr64-35w5)

High. pkcs7_decrypt_der/pem/smime 가 RecipientInfo 의 encryptedKey 복호화 실패를 단계별로 다르게(에러 메시지·수행 시간) 알려줘서, 신뢰할 수 없는 EnvelopedData 를 복호화하고 결과를 회신하는 서비스에서 콘텐츠 암호화 키에 대한 Bleichenbacher 오라클이 된다. 49.0.0 취약, 50.0.0 에서 수정 (RFC 3218 — 키 복구 실패 시 기대 길이의 랜덤 키로 대체해 모든 경로를 동일화).

• uv.lock: cryptography 49.0.0 -> 50.0.0. 다른 패키지 버전 변동 없음.
• pyproject.toml: [tool.uv] constraint-dependencies 로 하한선 고정. cryptography 는 직접 import 하지 않고 google-auth 가 끌어오는 전이 의존성이라 dependencies 에 넣으면 안 쓰는 패키지를 직접 의존성으로 선언하게 된다. constraint 로 두면 재-lock 이나 상위 패키지의 버전 하향에도 취약 버전으로 되돌아가지 않는다.

취약 경로 자체는 사용처가 없다(pkcs7/smime grep 0건). cryptography 는 google-auth 의 JWT 서명용으로만 들어와 있어 공격 조건(신뢰할 수 없는 EnvelopedData 자동 복호화 + 결과 회신)에 해당하지 않는다. SBOM 스캐너가 uv.lock 의 버전으로 잡은 건이라 버전 상향으로 해소된다.

검증

• uv sync --frozen 정상, 테스트 596개 전부 통과
• alpine(musl) 빌드 호환: 50.0.0 에 cp311-abi3-musllinux_1_2_{x86_64,aarch64} wheel 존재(cp311-abi3 가 py3.14 커버). 소스 빌드로 떨어지지 않는다.
• Dockerfile 3개(루트/chat/knowledge)가 같은 pyproject.toml + uv.lock 을 쓰므로 이미지·SBOM 모두 이 수정 하나로 커버된다.

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com