Trusted Publishing을 패키지 신뢰 신호로 보면 안 됨

 (blog.yossarian.net)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Trusted Publishing의 “신뢰”는 패키지를 사람이 믿어도 된다는 뜻이 아니라, CI/CD 같은 외부 머신 신원과 패키지 인덱스 사이의 업로드 인증 관계를 가리킴
  • PyPI의 구현은 OIDC 연합 위에서 동작하며, 장기 API 토큰 대신 짧고 범위가 좁은 게시 자격 증명을 발급해 장기·과권한 자격 증명 노출을 줄임
  • PyPI가 2023년에 공개한 뒤 npm, RubyGems, crates.io, NuGet 등으로 확산됐지만, 데이터 모델 복잡성, OIDC 제공자별 처리, CI/CD 침해 가능성은 남아 있음
  • PyPI는 Trusted Publishing 상태를 프로젝트 페이지의 초록 체크 표시로 강조하지 않고, 파일 상세의 단순 Yes/No 메타데이터로만 보여 안전성 신호로 오해될 여지를 줄임
  • Trusted Publishing과 PyPI attestations는 업로드 인증이나 머신 신원 기반 서명 여부만 말해주며, 별도로 그 신원을 신뢰하기 전에는 패키지 안전성이나 품질을 판단할 수 없음

Trusted Publishing이 다루는 신뢰의 범위

  • Trusted Publishing은 사람에게 패키지를 신뢰하라고 말하는 기능이 아니라, 머신 간 신뢰를 다루는 인증 방식임
  • Trusted Publishing을 사람이 믿을 수 있느냐 없느냐의 문제로 보면 범주가 어긋남
  • 핵심은 CI/CD 워크플로 같은 외부 머신 신원과 패키지 인덱스의 프로젝트 신원 사이에 업로드 인증용 신뢰 관계를 세우는 데 있음

PyPI의 Trusted Publishing 구조

  • “Trusted Publishing”은 PyPI가 OpenID Connect 연합 위의 인증 방식을 설명할 때 쓰는 용어임
  • PyPI는 이를 2023년에 공개했고, 이후 npm, RubyGems, crates.io, NuGet 등도 채택함
  • 출발점은 두 가지 문제임
    • 장기 자격 증명인 인덱스 API 토큰은 안전하게 관리하기 어렵고, 사용자가 최소 권한과 만료 기간을 정하기 어려워 과권한으로 설정되기 쉬움
    • 많은 사용자는 CI/CD 플랫폼에 넣기 위해 자격 증명을 만들며, CI/CD 플랫폼도 OIDC를 통해 특정 머신 신원 제어를 증명하는 메커니즘을 갖고 있음
  • 사용자는 패키지 인덱스에 CI/CD 머신 신원인 Trusted Publisher를 한 번 등록하고, CI/CD가 신원 토큰을 제시하면 인덱스가 이를 검증해 짧고 범위가 좁은 게시 자격 증명을 발급함

장점과 남는 제약

  • 짧고 자체 범위가 정해지는 자격 증명 방식은 PyPI 사용자에게 큰 성공을 거둔 접근으로 평가됨
    • 사용자는 필요 없을 때 자격 증명을 직접 관리하지 않는 방식을 선호함
    • 대형 오픈소스 프로젝트와 기업은 게시 권한이 개인 메인테이너가 아니라 소스 신원에 연결되는 속성을 선호함
  • Trusted Publishing에도 구조적 복잡성은 남아 있음
    • PyPI의 “pending publishers”는 존재하지 않는 프로젝트 문제를 해결하지만, 데이터 모델을 복잡하게 만들고 일반 Trusted Publishing보다 사용자에게 더 혼란스러움
    • OIDC 제공자는 공통 claim 일부 외에 claim set에 다양한 값을 넣을 수 있어, 인덱스는 각 제공자의 고유한 형태를 별도로 처리해야 함
    • 이 때문에 머신 신원은 OIDC IdP 간에 서로 대체 가능하지 않으며, PyPI가 새 Trusted Publishing 제공자를 천천히 추가하는 이유 중 하나가 됨
  • CI/CD 워크플로가 침해되면 공격자가 Trusted Publishing 자격 증명이나 그 씨앗이 되는 OIDC ID 토큰을 유출할 수 있음
    • 장기 자격 증명이 워크플로에 들어 있을 때와 유사하지만, Trusted Publishing 자격 증명은 같은 범위·수명 위험을 갖지 않음
    • PyPI는 pull_request_target처럼 쉽게 악용될 수 있는 트리거에 해당하는 머신 신원에는 토큰 교환을 거부해 CI/CD 침해 위험을 완화함

패키지 신뢰 신호가 아닌 이유

  • Trusted Publishing은 인증 방법일 뿐이며, 패키지가 안전한지, 품질이 높은지, 사용할 만한지에 대한 정보를 주지 않음
  • PyPI는 공개 인덱스라 누구나 업로드할 수 있고, 누구나 Trusted Publisher를 사용해 업로드할 수 있음
    • Trusted Publisher로도 악성코드나 취약한 코드를 업로드할 수 있음
    • 이 점에서는 PyPI의 다른 업로드 인증 방법인 API 토큰과 같음
  • PyPI에서 Trusted Publishing은 필수가 아니며 앞으로도 필수가 될 수 없음
    • 사용자에게 Trusted Publishing을 강제하는 것은 엔지니어링상 실현 불가능하고, 기술적·사회적으로도 바람직하지 않음
    • Trusted Publishing은 항상 선택 사항임

PyPI UI가 오해를 줄이는 방식

  • PyPI는 사용자가 Trusted Publishing 상태를 패키지 신뢰 신호로 오해하지 않도록 조심함
  • 프로젝트 페이지에는 Trusted Publishing 상태를 나타내는 초록 체크 표시가 없음
  • 사용자 제어 상태에 대한 초록 체크 표시는 패키지 자체와 같은 출처에서 왔음을 PyPI가 증명할 수 있는 링크에만 사용됨
  • 검증된 URL은 검증 시점에 해당 URL이 PyPI 패키지 소유자의 제어 아래 있었다는 것만 증명하며, URL이나 프로젝트에 대한 추가 안전성을 뜻하지 않음
  • 특정 파일의 Trusted Publishing 상태는 파일 상세에서 단순한 Yes/No 값으로 표시됨
    • 파일 메타데이터 영역은 사용자 신뢰 판단에 중요한 정보처럼 렌더링되지 않음
    • 업로드 클라이언트의 user agent에서 온 JSON blob도 제대로 렌더링하지 않음

attestations와의 구분

  • 이 논점은 PyPI의 attestations와 별개임
  • attestations도 현재 OIDC 머신 신원을 사용하지만, 신뢰 신호는 아님
  • attestation은 머신 신원 위의 서명과 비슷하지만, PyPI에는 누구나 업로드할 수 있으므로 누구나 자신이 제어하는 머신 신원으로 서명할 수 있음
  • Trusted Publisher가 있다고 해서 attestation이 반드시 존재하는 것은 아니며, attestation이 있다고 해서 최종 사용자가 특정 신원을 신뢰해도 된다는 뜻도 아님
  • PyPI의 attestation 신뢰성 모델도 이 점을 문서화하고 있음

함께 보면 좋은 글 β

GN⁺   [-]
Lobste.rs 의견들

  • 좋은 글임. Trusted Publishing과 증명(attestation) 은 서로 다른 장애 모드에 대해 각기 다른 보장을 제공하고, 둘 다 대부분의 사용자가 말하는 신뢰와도 별개임

  • Trusted Publishing이 가능해진 건 지난 15년 동안 많은 오픈소스 프로젝트가 메일링 리스트, Git 저장소, 버그 추적기, 빌드 서버 같은 자체 호스팅에서 중앙화된 포지로 옮겨 갔기 때문임
    이제 중앙화된 포지의 단점이 더 분명해지면서 프로젝트들이 다시 자체 호스팅을 고려하고 있음
    2010년대에는 편의성과 소셜 네트워크 효과가 프로젝트를 중앙화된 포지로 밀어 넣었지만, 이제는 Trusted Publishing을 포함해 프로젝트를 묶어 두는 요인이 훨씬 많아짐
    권위를 불신하라 — 탈중앙화를 촉진하라
    — "The Hacker Ethics", Hackers: Heroes of the Computer Revolution (Steven Levy, 1984)

    • Trusted Publishing에는 종속(lock-in) 이 없음. PyPI가 연동할 수 있는 호스트를 포함해 언제든 다른 인증 방식을 쓸 수 있음
      연합 인증 방식을 종속의 한 형태라고 부르는 데에는 약간의 아이러니가 있음
    • 자체 호스팅은 사실상 항상 소수 취향에 가까웠음. SourceForge의 목적이 바로 그 부담을 대신 떠안는 것이었음
      거의 같은 시기인 25년 전쯤 ASF도 있었지만, ASF에는 거버넌스 부담도 많았음. 그 전에는 GNU 프로젝트가 있었고, 자유 소프트웨어 이념을 더 강조했으며 체계적인 프로젝트 호스팅 서비스에는 덜 집중했음. GNU는 자유 소프트웨어 프로젝트에 어떤 서비스가 필요한지 명확한 개념이 생기기 전부터 있었기 때문임
      1990년대의 자유 소프트웨어 프로젝트는 보통 대학의 시분할 서비스나 친구의 코로케이션 서버에 올라가 있었음. 예를 들면 PuTTY나 ASF 이전의 Apache httpd가 있던 Hyperreal.org 같은 식임
      자체 인프라를 정당화할 만큼 커지는 프로젝트는 드물었고, 저렴한 호스팅도 비교적 최근에야 가능해진 편임
    • 자체 호스팅 Forgejo에서 Trusted Publishing을 못 할 이유가 있나? 있다면 내가 놓치고 있는 것 같음
답변달기