• 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월 재개됨

• 일부 프로젝트가 이미 게시된 릴리스에 새 Python 버전 지원 파일을 추가하고 있어 초기 논의가 중단됨

적용 결정과 향후 API

• PyCon US 2026 Packaging Summit에서는 새 Python 버전을 지원할 때
  다음 버전으로 올리도록 요구해도 수용 가능하다는 대략적인 합의가 형성됨
• 조사 데이터와 합의를 바탕으로 Warehouse 패치가 추진됐으며,
  2026년 7월 8일 병합됨
• 현재 제한은 아직 안정적인 인터페이스로 간주할 수 없음
• “더 이상 새 파일을 받지 않는 릴리스”의 정의가 확정되지 않았고, 상태를 확인할 API도 없음
• PEP 694가
  Upload 2.0 API와 Staged Previews를 표준화한 뒤 릴리스를 open

또는 closed

로 다루는 의미 체계가 마련될 예정임

댓글과 토론