PyPI, 릴리스 14일 후 새 파일 업로드 거부

PyPI는 토큰이나 배포 워크플로가 탈취돼도 안정된 기존 릴리스가 오염되지 않도록, 게시 후 14일이 지난 릴리스의 새 파일 업로드를 차단함 현재까지 실제 악용 사례는 확인되지 않았지만, 공격자가 가능성을 몰랐다는 점 외에는 공격을 막을 기술적 장벽이 없었음 상위 15,000개 패키지를 조사한 결과, 릴리스 14일 후 Python 3.14용 cp314 휠을 추가한 프로젝트는 56개에 그쳤음 기존 릴리스에 새 Python 버전 지원을 추가하던 프로젝트는 이제 다음 버전을 배포해야 하며, PyCon US 2026 Packaging Summit에서도 이를 수용 가능한 방안으로 판단함 아직 릴리스의 개방·폐쇄 상태를 정의하거나 확인할 API가 없으므로 이 동작에 의존하면 안 되며, 향후 PEP 694의 Upload 2.0 API와 Staged Previews가 관련 의미 체계를 정립할 예정임 오래된 릴리스를 닫는 이유 PyPI의 변경은 오래되고 안정된 릴리스에 새 파일을 올리는 경로를 차단함 프로젝트의 게시 토큰이나 워크플로가 침해되더라도 기존 릴리스 일부만 악성 파일로 교체되는 상황을 방지함 릴리스 안에 침해된 파일과 그렇지 않은 파일이 섞이는 불명확한 상태를 막고, PyPI 관리자의 정리 작업도 줄임 논의는 PEP 740 Digital Attestations 작업 중이던 2024년 1월 시작됐고, 2026년 3월 재개됨 계기는 LiteLLM과 Telnyx 공급망 침해였으며, 두 프로젝트가 사용한 Trivy GitHub Action의 변경 가능한 참조(mutable reference)가 원인이었음 일부 프로젝트가 이미 게시된 릴리스에 새 Python 버전 지원 파일을 추가하고 있어 초기 논의가 중단됨 변경의 영향을 파악하기 위해 PyPI 데이터베이스에서 오래된 릴리스에 파일을 추가한 프로젝트를 경과 일수별로 조사함 상위 15,000개 패키지의 cp314 휠을 별도로 확인한 결과, 14일 이후 Python 3.14 호환 휠을 게시한 프로젝트는 56개였음 적용 결정과 향후 API PyCon US 2026 Packaging Summit에서는 새 Python 버전을 지원할 때 다음 버전으로 올리도록 요구해도 수용 가능하다는 대략적인 합의가 형성됨 조사 데이터와 합의를 바탕으로 Warehouse 패치가 추진됐으며, 2026년 7월 8일 병합됨 현재 제한은 아직 안정적인 인터페이스로 간주할 수 없음 “더 이상 새 파일을 받지 ...