Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python 개선 제안 한국어 번역

PEP 759 – 외부 휠 호스팅

Author:
Barry Warsaw <barry at python.org>, Emma Harper Smith <emma at python.org>
PEP-Delegate:
Donald Stufft <donald at python.org>
Discussions-To:
Discourse thread
Status:
Withdrawn
Type:
Standards Track
Topic:
Packaging
Created:
01-Oct-2024
Post-History:
10-Oct-2024, 31-Jan-2025
Resolution:
31-Jan-2025
Table of Contents

번역·라이선스 안내

이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain or CC0-1.0, whichever is more permissive 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판

초록

이 PEP는 pypi.org에서 호스팅되는 프로젝트가 PyPI 이외의 외부 사이트에서 휠 아티팩트를 안전하게 호스팅할 수 있도록 하는 메커니즘을 제안합니다. 이 PEP는 프로젝트, 패키지 또는 해당 메타데이터의 외부 호스팅을 명시적으로 제안하지 않습니다. 이러한 기능은 독립 패키지 색인을 외부에서 호스팅하는 방식으로 이미 제공됩니다. 이 PEP는 특정 릴리스된 휠 아티팩트의 다운로드 URL을 프로젝트가 사용자 지정할 수 있는 메커니즘만 제공하므로, pip 및 uv와 같은 일반적인 설치 도구가 이미 구현한 의존성 해결 기능은 변경할 필요가 없습니다.

이 PEP는 이 맥락에서 “안전”하다는 것이 무엇을 의미하는지와 함께, .rim 파일이라는 새로운 패키지 업로드 파일 형식을 정의합니다. 또한 .rim파일이 HTML 및 JSON 형식 모두에서 패키지의 Simple Repository API에 대해 반환되는 메타데이터에 어떤 영향을 미치는지, 그리고 기존 휠을 .rim파일로 쉽게 변환하는 방법을 정의합니다.

PEP 철회

이 PEP는 2025-01-31에 작성자들에 의해 철회되었습니다. 논의 스레드의 여론을 저희가 해석한 바에 따르면, 이 PEP가 해결하려는 문제는 타당하지만 대부분의 사람은 다른 접근 방식을 선호합니다. 구체적으로 저희가 파악한 바로는 대부분의 사용자가 여러 색인을 지정하는 기능, 해당 색인들이 상호 운용되는 방식, 그리고 해당 색인에 대한 우선순위 및 신뢰 주장에 대해 더 많은 제어권을 선호합니다. 예를 들어 PEP 766과 같은 해결책이 더 나은 방향을 제시할 수 있습니다. 기존의 임시방편(예: PyPI 한도 증액 요청과 “wheel-stub” 접근법)은 이상적이지는 않더라도 그동안 충분합니다. 작성자들은 건설적인 논의에 기여한 모든 분께, 특히 공개적으로나 비공개적으로 이 PEP에 대한 지지를 표명해 주신 분들께 감사드리고자 합니다.

근거

Python 패키지 색인(호스팅 주소: https://pypi.org)은 업로드 아티팩트 파일 크기(100 MiB)와 전체 프로젝트 크기(10 GiB)에 기본 제한을 적용합니다. 대부분의 프로젝트는 수년간 파일을 업로드하면서 프로젝트 수명 동안 이러한 한도 내에 여유 있게 들어맞을 수 있습니다. 일부 프로젝트는 이러한 한도에 도달했으며, 파일 크기와 프로젝트 크기 모두에 대한 예외를 승인받아 버전 고정 등을 통해 소비자가 여전히 사용하고 있을 가능성이 있는 파일을 제거하는 것과 같은 더 과감한 조치를 취하지 않고도 새 릴리스를 계속 업로드할 수 있었습니다.

이와 관련된 해결 방법으로는 “wheel stub” 접근법이 있으며, 이는 그러한 제한을 피할 수 있는 외부 제3자 패키지 색인과 PyPI 사이에 간접적인 연결을 제공합니다. 휠 스텁은 source distributions(일명 “sdist”)으로, 소스 코드를 바이너리 휠로 변환하는 대신 기존의 외부 호스팅 휠을 다운로드하고 설치할 URL을 계산하는 일부 로직을 수행하는 PEP 517 빌드 백엔드를 사용합니다. 이 접근법은 작동하지만, 이 정보를 pip나 기타 유사한 도구에 제시할 방법이 없으므로 PyPI, sdist 및 외부 호스팅 휠 사이의 연결을 불분명하게 만듭니다.

역사적 맥락

2013년에 PEP 438은 PyPI에서 릴리스 파일 호스팅의 여러 측면을 수정하기 위한 “하위 호환 가능한 2단계 전환 프로세스”를 제안했습니다. 이 PEP가 설명하듯이, PyPI는 원래 아티팩트 파일 호스팅은 허용하지 않고 프로젝트 및 릴리스 등록만 지원했습니다. 따라서 대부분의 프로젝트는 릴리스 파일 아티팩트를 다른 곳에서 호스팅했습니다. 이후 아티팩트 호스팅이 추가되었지만, 외부에서 호스팅되는 파일과 PyPI에서 호스팅되는 파일이 혼재하면서 사용성 및 잠재적인 보안과 관련된 다양한 문제가 발생했습니다. PEP 438은 PyPI 우선 호스팅을 장려하면서 외부 호스팅을 허용하기 위한 여러 기능을 제공하려는 시도였습니다.

PEP 438은 서로 다른 세 가지 “호스팅 모드”, 호스팅 위치를 나타내기 위한 간단한 HTML 색인 페이지의 rel 메타데이터, 그리고 PyPI와 설치 도구에 영향을 미치는 2단계 전환 계획으로 구성되어 복잡했습니다. PEP 438은 결국 2015년에 PEP 470에 의해 철회되었으며, PEP 438이 성공했음을 인정합니다…

더 많은 사람이 PyPI의 저장소 기능을 사용하게 했으며, PyPI를 구동하는 전 세계 CDN이 많은 사람에게 속도 향상을 제공한다는 점에서 이는 전적으로 좋은 일이었습니다[…]

외부 호스팅 대신 PEP 470은 완전한 패키지 색인 및 아티팩트 호스팅을 제공하는 명시적인 여러 저장소의 사용을 장려했으며, pip install --extra-index-url과 같은 설치 도구 지원을 통해 이를 활성화하여 pip가 패키지 설치 해결을 위해 여러 저장소를 사실상 하나의 전역 저장소로 취급할 수 있도록 했습니다. 이것이 수년간 공인된 관행이었기 때문에 모든 Python 패키지 설치 도구는 종속성 해결을 위해 여러 패키지 색인을 조회할 수 있도록 지원합니다.

여러 패키지 색인의 문제점

그렇다면 이 PEP는 왜 더 제한적인 형태의 외부 호스팅을 허용할 것을 제안하며, 이 제안은 PEP 470에 문서화된 문제를 어떻게 피합니까?

여러 패키지 색인을 통합할 때 발생하는 잘 알려진 문제 중 하나는 종속성 혼동 공격이며, 패키지 종속성과 선호 버전을 해결하는 데 pip install이 사용하는 알고리즘 때문에 Python은 특히 취약할 수 있습니다. uv 도구는 추가 색인 전략 옵션을 지원하여 이를 해결하며, 사용자는 예를 들어 pip 호환 전략과 이러한 종속성 혼동 공격을 방지하는 더 제한적인 전략 중에서 선택할 수 있습니다.

PEP 708은 종속성 혼동 공격에 관한 추가 배경 정보를 제공하며, 이를 방지하기 위해 다른 접근 방식을 취합니다. PEP 708의 핵심은 저장소 소유자가 프로젝트가 서로 다른 저장소에 걸쳐 추적된다는 것을 나타낼 수 있도록 하는 것이며, 이를 통해 설치 도구는 여러 저장소를 결합했을 때 전역 패키지 네임스페이스를 어떻게 처리할지 결정할 수 있습니다. PEP 708은 PEP 708에 명시된 몇 가지 필수 조건을 충족하는 것을 전제로 잠정적으로 수락되었으며, 그중 일부는 향후가 불확실할 수 있습니다. PEP 708 자체가 말하듯이, 이것만으로 종속성 혼동 공격이 해결되지는 않지만 설치 도구에 이러한 공격을 최소화하는 데 도움이 될 충분한 정보를 제공하는 한 가지 방법입니다.

완전히 독립적인 패키지 색인을 구축하는 타당한 사용 사례가 여전히 존재할 수 있지만(예를 들어 완전히 구체화된 변형 제안이 수락될 때까지 GPU에 대한 더 풍부한 플랫폼 지원을 제공하는 경우), 이 PEP는 다른 더 단순한 접근 방식을 취하며 기존의 패키지 색인 협력 사양, 제안된 사양 또는 승인된 사양을 대체하지 않습니다.

이 PEP는 PyPI의 핵심 목적도 보존하며, PyPI가 모든 Python 패키지를 위한 전통적이고 정식인 중앙 집중식 색인으로 남을 수 있도록 합니다.

PyPI 제한 사항 해결

이 제안은 또한 PyPI가 부과하는 크기 제한 문제를 해결하며, PyPI에는 기본 아티팩트 크기 제한이 100 MiB이고 기본 전체 프로젝트 크기 제한이 10 GiB입니다. 다양한 플랫폼용 바이너리 확장 모듈을 포함하는 패키지의 경우에도 대부분의 패키지와 아티팩트는 이러한 제한에 쉽게 맞습니다. 규모가 작지만 중요한 일부 패키지는 이러한 제한을 정기적으로 초과하므로 PyPI에 exception request support tickets을 제출해야 합니다. 이러한 예외에 대한 해결을 받는 일이 반드시 어려운 것은 아니지만, 해결에 시간이 걸릴 수 있는 특별한 절차이며 이러한 예외를 승인하는 기준도 잘 문서화되어 있지 않습니다.

운영 복잡성 감소

전체 패키지 색인을 설정하고 유지 관리하는 일은 시간과 리소스가 많이 드는 복잡한 운영 솔루션이 될 수 있습니다. 이러한 색인의 주된 목적이 단지 파일 크기 제한을 피하는 것이라면 이는 특히 그렇습니다. 외부 색인 접근 방식은 외부 색인의 프로젝트를 사용하는 소비자에게도 까다로운 사용자 경험을 부과하며, --external-index-url과 같은 CLI 옵션의 작동 방식과 이러한 플래그의 보안 영향을 이해하도록 요구합니다. 대형 휠 패키지의 생산자와 소비자 모두에게는 HTTP GET보다 복잡한 API 없이 개별 파일을 제공할 수 있는 간단한 웹 서버를 설정하고 유지 관리하는 편이 훨씬 더 쉽습니다. 이러한 인터페이스는 쉽게 캐시하거나 CDN 뒤에 배치할 수도 있습니다. 간단한 HTTP 서버는 보안 목적의 감사도 훨씬 쉽고, 프록시하기도 쉬우며, 일반적으로 실행·지원·유지 관리에 훨씬 적은 리소스를 사용합니다. Amazon S3와 같은 서비스도 외부 휠을 호스팅하는 데 사용할 수 있습니다.

이 PEP는 이러한 운영상의 단순성을 중시하는 접근 방식을 제안합니다.

사양

“RIM”(즉, .rim) 또는 “Remote Installable Metadata” 파일이라고 하는 새로운 유형의 업로드 가능한 파일을 정의합니다. 이 이름은 타이어를 제거한 바퀴의 이미지를 떠올리게 하며, .rim 파일이 .whl 파일에서 쉽게 파생된다는 점을 강조합니다. .whl을 .rim으로 변환하는 과정은 아래에 설명되어 있습니다. 파일 이름 형식은 wheel 파일 이름 형식 사양과 정확히 일치하지만, RIM 파일은 접미사 .rim을 사용합니다. 이는 .whl 파일을 구별하는 데 사용되는 모든 태그가 서로 다른 .rim 파일도 구별하며, 따라서 현재 .whl 파일과 정확히 동일하게 의존성 해결 단계에서 사용할 수 있음을 의미합니다. 이러한 점에서 .whl 파일과 .rim 파일은 서로 바꾸어 사용할 수 있습니다.

.rim 파일의 내용은 .whl 파일과 거의 동일하지만, .rim 파일에는 휠의 .dist-info 디렉터리만 포함되어야 MUST합니다. .rim zip 파일에는 다른 최상위 파일이나 디렉터리를 허용하지 않습니다. .dist-info 디렉터리는 .whl 파일의 .dist-info 디렉터리에서 allowed된 항목에 더해 단일 추가 파일 하나를 반드시 포함해야 합니다. 해당 파일의 이름은 EXTERNAL-HOSTING.json입니다.

이는 다음 키를 포함하는 JSON 파일입니다.

version
이는 파일 형식 버전이며, 이 PEP에서는 1.0이어야 MUST합니다.
owner
이 외부 호스팅 파일의 PyPI 조직 소유자를 명시해야 MUST하며, 그 이유는 아래의 자세한 설명에서 설명합니다.
uri
이는 외부 사이트에서 호스팅되는 실제 .whl 파일의 위치를 나타내는 단일 URL입니다. 이 URL은 https 스킴을 사용해야 MUST합니다.
size
이는 원격 호스트에 있는 실제 .whl 파일의 바이트 단위 크기를 나타내는 정수 값입니다.
hashes
이는 PEP 694에 설명된 형식의 딕셔너리로, 해당 PEP에서 제안된 것과 동일한 제약 조건에 따라 실제 .whl 파일의 PEP 694을 모두 기록하는 데 사용됩니다. 이러한 해시는 PyPI에 업로드된 후 변경할 수 없으므로, 외부에서 호스팅되는 휠이 손상되거나 변조되지 않았음을 검증하는 중요한 수단으로 사용됩니다.

RIM 파일의 효과

.rim 파일의 유일한 효과는 simple repository API의 HTML 및 JSON 인터페이스에서 휠 아티팩트의 다운로드 URL을 변경하는 것입니다. 패키지 릴리스의 HTML 페이지에서 href 속성은 #<hashname>=<hashvalue> 프래그먼트를 포함하여 uri 키의 값이어야 MUST합니다. 이 해시 프래그먼트는 .dist-info/RECORD 파일에서 PEP 376에서 유래한 signed wheel file format에 설명된 형식과 정확히 동일한 형식이어야 MUST합니다. 여기에도 해시 알고리즘과 인코딩을 선택하는 데 정확히 동일한 규칙을 사용합니다.

마찬가지로 JSON response에서 다운로드 파일을 가리키는 url 키는 uri 키의 값이어야 하며, 위에서 제공한 hashes 딕셔너리의 값으로 채운 hashes 딕셔너리를 포함해야 MUST합니다.

그 밖의 모든 측면에서, 호환되는 패키지 색인은 아래에 설명된 일부 사소한 예외를 제외하고 .rim 파일을 .whl 파일과 동일하게 취급해야 합니다. 예를 들어, .rim 파일은 모든 .whl 파일과 동일한 의미 체계(즉, 삭제는 영구적임)에 따라 삭제할 수 있으며 (PEP 592), 철회할 수도 있습니다. .rim이 삭제된 경우, 색인은 일치하는 .whl 또는 .rim 파일의 업로드를 허용해서는 MUST NOT합니다.

가용성 순서

외부에서 호스팅되는 휠은 해당 .rim 파일이 PyPI에 업로드되기 전에 사용할 수 있어야 MUST합니다. 그렇지 않으면 게시 경쟁 조건이 발생하지만, PEP 694 스테이징 릴리스에 업로드되는 .rim 파일에는 이 요구 사항을 완화할 수 MAY있습니다.

휠은 RIM을 재정의할 수 있습니다.

색인은 동일한 파일 이름 태그를 가진 일치하는 .whl 파일이 이미 존재하는 경우 .rim 파일을 반드시 거부해야 합니다. 그러나 일치하는 .rim 파일이 존재하고 해당 .rim 파일이 삭제되거나 철회되지 않은 경우, 색인은 .whl 파일을 허용할 수 있습니다. 이를 통해 업로더는 외부에서 호스팅되는 휠 파일을 색인에서 호스팅되는 휠 파일로 교체할 수 있지만, 그 반대는 금지됩니다. 기본적으로 휠은 패키지 메타데이터가 포함된 동일한 패키지 색인에서 호스팅되므로, 기존 휠 파일을 업로드한 후 “다운그레이드”하는 것은 허용되지 않습니다. .whl이 .rim을 교체하는 경우, 색인은 자체 호스팅 파일 서비스를 사용하여 패키지의 다운로드 URL을 반드시 제공해야 합니다. 재정의하는 .whl 파일을 업로드할 때 패키지 색인은 기존 .rim 파일의 해시를 반드시 검증해야 하며, 해시가 일치하지 않으면 재정의 업로드를 반드시 거부해야 합니다.

PyPI API 버전 상향은 필요하지 않습니다.

변경 사항은 하위 호환성이 충분하므로 PyPI repository version의 버전 상향은 필요하지 않을 가능성이 높습니다. .rim 파일은 본질적으로 업로드 API만 변경하므로, 패키지 확인자와 패키지 설치 도구는 지금까지 지원해 온 API로 계속 작동할 수 있습니다.

외부 호스팅 복원력

PEP 438이 PEP 470에서 철회되도록 이끈 주요 우려 중 하나는 외부 색인이 사라졌을 때 사용자가 혼란을 겪을 가능성이었습니다. PEP 470에서 인용합니다.

이러한 혼란은 프로젝트의 최종 사용자가 프로젝트가 PyPI에서 호스팅되는지 아니면 외부 서비스에 의존하는지 알지 못하는 데서 비롯됩니다. 이는 PyPI는 정상적으로 작동하지만 외부 서비스는 중단되었을 때 자주 나타납니다. 사람들은 PyPI와 다른 프로젝트는 작동하지만, 유독 이 특정 프로젝트만 작동하지 않는 것을 보게 됩니다. 그들은 이 문제를 해결하려면 누구에게 연락해야 하는지 또는 어떤 복구 절차를 밟아야 하는지 모르는 경우가 많습니다.

외부 휠 호스팅 서비스가 중단되는 문제를 이 PEP가 직접 해결하지는 않지만, PyPI 관리자가 짊어질 수 있는 부담을 크게 줄이기 위한 여러 보호 장치가 마련되어 있습니다.

따라서 이 PEP는 다음을 제안합니다.

  • 외부 휠 호스팅은 organization accounts가 소유한 패키지에만 허용됩니다. 외부 호스팅은 조직 전체에 적용되는 설정입니다.
  • 조직 계정은 외부에서 휠을 호스팅할 수 있는 권한을 자동으로 얻지 못하며, 이 기능은 PyPI 관리자가 재량에 따라 명시적으로 활성화해야 합니다. 이는 일반적인 요청이 아니므로, 처리 부담이 PEP 541 해결, 계정 복구 요청 또는 파일/프로젝트 크기 증가 요청만큼 크지는 않을 것으로 예상합니다. 외부 호스팅 요청은 해당 요청들과 동일한 방식, 즉 PyPI GitHub support tracker 를 통해 처리됩니다.
  • 외부 휠 호스팅을 요청하는 조직 계정은 자체 지원 연락처 URI를 반드시 등록해야 하며, 이는 연락처 이메일 주소를 위한 mailto URI이거나 조직의 지원 추적기 URL이어야 합니다. 이러한 연락처 URI는 외부 휠 파일 호스팅을 이용하지 않는 조직에는 선택 사항입니다.

이는 EXTERNAL-HOSTING.json 파일의 owner 키와 결합하여 설치 도구가 모든 다운로드 오류를 PyPI 지원 관리자에게서 명확히 돌려 조직의 지원 관리자에게 직접 전달할 수 있도록 합니다.

이 조직 지원 URL을 저장하고 검색하는 정확한 방식은 별도로 정의되지만, 예를 들어 패키지 foo가 `https://foo.example.com <https://foo.example.com>`__ 에서 휠 파일을 외부 호스팅하며 해당 호스트에 연결할 수 없게 되었다고 합시다. 설치 도구가 패키지 foo의 휠을 다운로드하여 설치하려고 하면 다운로드 단계가 실패합니다. 그러면 설치 도구는 PyPI에 조회하여 최종 사용자에게 유용한 오류 메시지를 제공할 수 있습니다.

  • 설치 도구는 .rim 파일을 다운로드하고 .rim zip 파일 내부의 EXTERNAL-HOSTING.json 파일에서 owner 키를 읽습니다.
  • 설치 도구는 외부에서 호스팅되는 휠을 소유한 조직의 지원 URI를 PyPI에 조회합니다.
  • 그러면 다음과 같은 안내성 오류 메시지가 표시됩니다:
    외부에서 호스팅되는 휠 파일 foo-....whl을 다운로드할 수 없습니다. 도움이 필요하면 support@foo.example.com으로 문의하십시오. 이 문제를 PyPI 관리자에게 신고하지 마십시오.

휠 디스마운팅

기존 .whl 파일에서 .rim 파일을 생성하는 작업은 일반적으로 매우 쉽습니다. 추가 명령줄 옵션을 사용하는 PEP 518 빌드 백엔드로 이를 효율적으로 수행하거나, .whl 파일을 입력으로 받아 연결된 .rim 파일을 생성하는 별도 도구를 사용할 수 있습니다. 비유를 완성하자면, .whl을 .rim으로 변환하는 작업을 “dismounting”이라고 합니다. 이러한 도구가 수행할 단계는 다음과 같습니다:

  • 원본 .whl 파일, 패키지의 조직 소유자, .whl 파일을 호스팅할 URL 및 다운로드 문제를 신고할 지원 URI를 입력으로 받아들이십시오. 실제로 이러한 정보는 pyproject.toml 파일에 기록할 수 있지만, 해당 사양은 이 PEP의 범위에 포함되지 않습니다.
  • .whl을 압축 해제하고 .rim zip 아카이브를 생성하십시오.
  • .whl에서 .dist-info 디렉터리를 루트로 하지 않는 경로는 .rim 파일에서 제외하십시오.
  • 원본 .whl 파일의 해시를 계산하십시오.
  • 위에서 설명한 JSON 키와 값을 포함하는 EXTERNAL-HOSTING.json 파일을 .rim 아카이브에 추가하십시오.

도구 변경 사항

이론적으로 설치 도구는 변경할 필요가 없습니다. 다운로드하여 설치할 휠을 식별한 후 PyPI의 Simple API가 반환하는 다운로드 URL을 조회하기만 하기 때문입니다. 하지만 실제로는 pip 및 uv와 같은 도구가 다운로드를 허용할 호스트 목록을 제한할 수 있으며, 여기에는 PyPI 자체의 pythonhosted.org 도메인과 같은 호스트가 포함될 수 있습니다.

이 경우 이러한 도구는 해당 제한을 완화해야 하지만, 구체적인 정책은 설치 도구 자체에 맡깁니다. .rim 파일을 다운로드하여 EXTERNAL-HOSTING.json 메타데이터를 검증하거나, 체크섬이 일치하는 모든 휠의 외부 다운로드를 단순히 신뢰하는 등 여러 접근 방식을 구현할 수 있습니다. 또한 다운로드를 신뢰하기 전에 PyPI에 프로젝트의 조직 소유자와 지원 URI를 조회할 수도 있습니다. 외부에서 호스팅되는 휠 파일을 발견하면 사용자에게 경고하거나 추가 다운로드 호스트를 활성화하는 명령줄 옵션을 사용하도록 요구할 수 있습니다. 이러한 검증 정책 중 하나를 구성 파일에서 선택할 수 있습니다.

설치 도구는 외부에서 호스팅되는 휠을 다운로드할 수 없을 때, 예를 들어 호스트에 연결할 수 없을 때 더 나은 오류 메시지도 제공해야 할 것입니다. 위에서 설명한 것처럼 이러한 도구는 PyPI에서 충분한 메타데이터를 조회하여 사용자를 패키지의 외부 호스팅 지원 이메일 또는 이슈 트래커로 안내하는 명확하고 구별되는 오류 메시지를 제공할 수 있습니다.

외부 호스팅 서비스에 대한 제약 사항

다음 제약 사항은 신뢰할 수 있고 호환 가능한 외부 휠 호스팅 서비스를 제공합니다:

  • 외부 휠은 Mozilla의 루트 인증서 저장소가 서명한 인증서를 사용하여 HTTPS를 통해 반드시 제공되어야 합니다. 이를 통해 pip 및 uv와의 호환성이 보장됩니다. 이 문서를 작성하는 시점에 Python 3.10 이상에서 pip 24.2는 제3자가 제공하는 certifi Python 패키지가 제공하는 Mozilla 저장소와 함께 시스템 인증서 저장소를 사용합니다. uv는 webpki-roots 크레이트가 제공하는 Mozilla 저장소를 사용하지만, --native-tls 플래그가 지정되지 않는 한 시스템 저장소는 사용하지 않습니다 [1]. PyPI 관리자는 향후 이 요구 사항을 변경할 수 있지만, 널리 사용되는 설치 도구와의 호환성은 저하되지 않습니다.
  • 외부 휠 호스트는 PyPI와 마찬가지로 콘텐츠 전송 네트워크(CDN)를 사용해야 합니다.
  • 외부 휠 호스트는 호스팅하는 모든 휠에 대해 안정적인 URL을 반드시 유지해야 합니다.
  • 외부에서 호스팅되는 휠은 해당 .rim 파일이 먼저 PyPI에서 삭제되지 않는 한 외부 휠 호스트에서 제거해서는 안 되며, yanked 릴리스의 외부 휠을 제거해서는 안 됩니다.
  • 외부 휠 호스트는 HTTP range requests를 지원해야 합니다.
  • 외부 휠 호스트는 HTTP/2프로토콜을 지원하는 것이 좋습니다.

보안

이 제안서에 설명된 다음과 같은 여러 요소가 외부에서 호스팅되는 휠과 관련된 보안 우려를 완화해야 합니다.

  • 휠 파일의 체크섬은 .rim 파일에 포함되어야 하며, 업로드된 후에는 변경할 수 없습니다. PyPI에 저장된 체크섬은 변경할 수 없고 필수이므로, 소유 조직이 호스팅 도메인에 대한 통제권을 잃더라도 외부 휠 파일을 위조할 수 없습니다.
  • 외부에서 호스팅되는 휠은 HTTPS를 통해 제공되어야 합니다.
  • 외부에서 호스팅되는 휠을 제공하려면 조직이 PyPI 관리자들의 승인을 받아야 합니다.

사용자가 PyPI에서 호스팅되는 프로젝트에서 악성 코드나 취약점을 식별한 경우, 이제 PyPI에서 이 malware reporting facilities를 사용하여 이를 신고할 수 있으며, 이는 이 blog post에도 설명되어 있습니다. 동일한 절차를 사용하여 외부에서 호스팅되는 휠의 보안 문제를 신고할 수 있으며, 동일한 해결 절차를 사용해야 합니다. 또한 외부 호스팅이 활성화된 조직은 지원 연락처 URI를 제공해야 하므로, 경우에 따라 해당 URI를 사용하여 호스팅 조직에 보안 문제를 신고할 수 있습니다. 이러한 조직 신고는 악성 코드에는 적합하지 않지만, 외부에서 호스팅되는 휠의 보안 취약점을 신고하는 데는 실제로 매우 유용한 방법이 될 수 있습니다.

거부된 아이디어

여러 아이디어가 검토되었으나 거부되었습니다.

  • 외부에서 호스팅되는 휠 파일에 해시 외에 또는 해시 대신 디지털 서명을 요구하는 방안입니다. 체크섬 요구 사항만으로도 PyPI의 휠 메타데이터가 다운로드한 휠과 정확히 일치하는지 검증하기에 충분하므로, 이를 불필요하다고 판단합니다. 키 관리에 추가되는 복잡성이 그러한 디지털 서명이 제공할 수 있는 어떠한 추가 이점보다 큽니다.
  • .rim 파일 업로드 시 해시를 검증하는 방안입니다. PyPI는 업로드를 수락하기 전에 업로드된 .rim 파일의 해시가 외부에서 호스팅되는 휠과 일치하는지 검증할 수도 있지만, 그러려면 외부 휠을 다운로드하여 체크섬을 계산해야 하며, 이는 외부 .whl 파일을 다운로드하고 검증할 때까지 .rim 파일의 업로드를 수락할 수 없다는 의미이기도 합니다. 이로 인해 PyPI의 대역폭 사용량이 증가하고 업로드 요청이 느려지지만, PEP 694 초안 업로드가 이러한 우려를 완화할 가능성이 있습니다. 그래도 그 이점은 추가되는 복잡성을 감수할 만큼 크지 않을 가능성이 높습니다.
  • 색인이 다운로드 URL을 주기적으로 검증하는 방안입니다. PyPI는 예를 들어 HTTP HEAD 요청을 통해 외부 휠 호스트 또는 외부 .whl 파일 자체가 여전히 사용 가능한지 주기적으로 확인할 수 있습니다. 이는 지나친 조치일 가능성이 높으며, 응답에 파일의 체크섬도 제공하지 않는다면 [2], 추가적인 이점이 크지 않을 수 있습니다.
  • 이 PEP를 통해 조직이 대체 다운로드 호스트를 제공하여 기본 호스트가 중단될 경우 보조 호스트를 사용할 수 있도록 할 수 있습니다. DNS 기반 복제가 훨씬 더 우수하고 잘 알려진 기법이며, 어쨌든 복원력도 더 높을 가능성이 크다고 생각합니다.
  • .rim 파일 교체입니다. a) .rim 파일이 삭제되거나 yanked되지 않았고, b) 체크섬이 일치하는 한 .whl 파일이 기존 .rim 파일을 대체하는 것은 허용되지만, .whl 파일을 .rim 파일로 대체하는 것은 허용하지 않으며, .rim 파일이 기존 .rim 파일을 덮어쓰는 것도 허용하지 않습니다. 후자의 방법은 외부에서 호스팅되는 .whl의 호스팅 URL을 변경하는 기법이 될 수 있지만, 이는 좋은 생각이 아니라고 판단합니다. 위에서 설명한 것처럼 외부 호스트 URL을 “수정”하는 다른 방법이 있으며, 기존 .rim 파일을 대량으로 다시 업로드하도록 장려하고 싶지 않습니다.

각주