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

> Clean Markdown view of GeekNews topic #31238. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=31238](https://news.hada.io/topic?id=31238)
- GeekNews Markdown: [https://news.hada.io/topic/31238.md](https://news.hada.io/topic/31238.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-07-08T17:01:35+09:00
- Updated: 2026-07-08T17:01:35+09:00
- Original source: [blog.yossarian.net](https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing)
- Points: 1
- Comments: 1

## Topic Body

- **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](https://docs.pypi.org/trusted-publishers/)은 사람에게 패키지를 신뢰하라고 말하는 기능이 아니라, **머신 간 신뢰**를 다루는 인증 방식임
- Trusted Publishing을 사람이 믿을 수 있느냐 없느냐의 문제로 보면 범주가 어긋남
- 핵심은 CI/CD 워크플로 같은 외부 머신 신원과 패키지 인덱스의 프로젝트 신원 사이에 업로드 인증용 신뢰 관계를 세우는 데 있음

### PyPI의 Trusted Publishing 구조
- “Trusted Publishing”은 [PyPI](https://pypi.org/)가 [OpenID Connect](https://openid.net/developers/how-connect-works/) 연합 위의 인증 방식을 설명할 때 쓰는 용어임
- PyPI는 이를 2023년에 공개했고, 이후 [npm](https://docs.npmjs.com/trusted-publishers), [RubyGems](https://guides.rubygems.org/trusted-publishing/), [crates.io](https://crates.io/docs/trusted-publishing), [NuGet](https://learn.microsoft.com/en-us/nuget/nuget-org/trusted-publishing) 등도 채택함
- 출발점은 두 가지 문제임
  - **장기 자격 증명**인 인덱스 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](https://docs.pypi.org/attestations/)와 별개임
- attestations도 현재 OIDC 머신 신원을 사용하지만, **신뢰 신호**는 아님
- attestation은 머신 신원 위의 서명과 비슷하지만, PyPI에는 누구나 업로드할 수 있으므로 누구나 자신이 제어하는 머신 신원으로 서명할 수 있음
- Trusted Publisher가 있다고 해서 attestation이 반드시 존재하는 것은 아니며, attestation이 있다고 해서 최종 사용자가 특정 신원을 신뢰해도 된다는 뜻도 아님
- PyPI의 attestation 신뢰성 모델도 이 점을 [문서화](https://docs.pypi.org/attestations/security-model/#trustworthiness)하고 있음

## Comments



### Comment 61433

- Author: neo
- Created: 2026-07-08T17:01:37+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/8d9pgd/you_shouldn_t_trust_trusted_publishing) 
- 좋은 글임. **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](https://www.chiark.greenend.org.uk/~sgtatham/putty/)나 ASF 이전의 Apache httpd가 있던 [Hyperreal.org](https://en.wikipedia.org/wiki/Hyperreal.org) 같은 식임  
    자체 인프라를 정당화할 만큼 커지는 프로젝트는 드물었고, 저렴한 호스팅도 비교적 최근에야 가능해진 편임
  - **자체 호스팅 Forgejo**에서 Trusted Publishing을 못 할 이유가 있나? 있다면 내가 놓치고 있는 것 같음