PyPI, 릴리스 파일 업로드 14일 제한으로 보안 강화

PyPI가 릴리스 후 14일이 지난 파일 업로드를 거부하는 새로운 보안 정책을 도입함

이는 프로젝트 토큰 탈취 시 릴리스 파일 변조(Release Poisoning)를 방지하기 위함임

일부 프로젝트의 기존 워크플로우에 영향을 줄 수 있으나, 커뮤니티는 새 버전 출시로 대응하는 것에 동의함

릴리스 변조(Release Poisoning) 방지 메커니즘

이번 변경은 릴리스 파일의 불변성(Immutability)을 강화하여, 프로젝트의 게시 토큰(Publishing Token)이나 워크플로우가 침해당했을 경우 악성 코드가 삽입되는 릴리스 변조(Release Poisoning) 공격을 원천 차단하는 데 목적이 있음. 아직 실제 악용 사례는 없으나, 잠재적 위협에 선제적으로 대응하기 위한 조치로 분석됨. 향후 업로드 2.0 API(Upload 2.0 API) 및 스테이지드 프리뷰(Staged Previews) 표준화와 함께 구체적인 의미론이 정의될 예정임.

기존 워크플로우와의 충돌 및 해결 방안

과거에는 안정적인 ABI(Stable ABI) 부재로 인해 새 Python 버전 지원을 위해 기존 릴리스에 파일을 추가하는 경우가 있었음. 이번 정책으로 인해 이러한 워크플로우는 다음 버전으로 마이그레이션(Bump to the next version)해야 함. PyPI 데이터 분석 결과, 15,000개 패키지 중 56개만이 14일 이후 3.14 호환 휠(wheel)을 게시하여 영향은 제한적일 것으로 보임. 패키징 서밋(Packaging Summit)에서는 이러한 변경이 수용 가능하다는 공감대가 형성되었음.

릴리스의 가변성(Mutability)에 대한 근본적 의문

커뮤니티에서는 PyPI 릴리스가 본질적으로 가변적(Mutable)이라는 사실 자체에 놀라움을 표하고 있음. 이는 다른 언어 패키지 매니저(npm 등)에서도 흔치 않은 동작으로, 보안 위험뿐만 아니라 동일 버전 내에서도 예측 불가능한 패키지 상태 변화를 야기할 수 있다는 지적이 있음. 이번 변경은 이러한 근본적인 문제점을 해결하려는 시도로 해석됨.

향후 API 표준화 및 '닫힌 릴리스' 개념

현재는 '파일 업로드를 중단하는 릴리스'에 대한 명확한 의미론이나 API가 부재함. 향후 PEP 694를 통해 표준화될 업로드 2.0 API는 '열린(Open)' 릴리스와 '닫힌(Closed)' 릴리스 상태를 구분하는 명확한 API 시맨틱스(API Semantics)를 제공할 예정임. 이를 통해 릴리스 상태 관리가 더욱 투명해질 것으로 기대됨.