PyPI 협업자 제거는 퍼블리셔 철회가 아니다

요약

PyPI는 사용자를 프로젝트에서 제거해도 해당 사용자가 등록했을 수 있는 트러스티드 퍼블리셔(Trusted Publishers)는 제거되지 않는다고 명시하고 있습니다.
프로젝트 협업자 역할, 구성된 CI 게시 신원, 업로드 토큰, 파일의 출처 증명은 서로 다른 범위를 가진 별개의 기록입니다.
방어 가능한 오프보딩 기록은 이러한 기록들을 결합하되, 하나의 존재 여부나 부재가 다른 모든 상태의 증거가 되도록 처리하지 않습니다.

오프보딩은 흔히 단일 조치로 서술됩니다. 한 사람이 떠나고, 접근 권한이 제거되고, 프로젝트는 안전하다는 서술입니다. 이러한 서술은 이해할 수 있습니다. 계정 역할은 눈에 보이고, 이를 제거하는 행위는 결단력 있게 느껴질 수 있기 때문입니다. 그러나 PyPI의 트러스티드 퍼블리싱 보안 가이드는 이 짧은 서술이 감추는 경계를 명시합니다. 사용자를 PyPI 프로젝트에서 제거해도 해당 사용자가 등록했을 수 있는 트러스티드 퍼블리셔는 제거되지 않습니다. 따라서 PyPI는 유지관리자(maintainer) 오프보딩에 등록된 모든 트러스티드 퍼블리셔에 대한 검토를 포함해야 한다고 말합니다.

이 진술은 절제되어 있습니다. 떠난 모든 협업자가 퍼블리셔를 등록했다고 말하지 않습니다. 남아 있는 퍼블리셔가 악의적이라거나, 업로드가 발생했거나, 프로젝트가 침해되었다고도 말하지 않습니다. 대신 거버넌스에 더 유용한 것을 말합니다. 즉, 두 개의 통제 표면이 존재하며, 하나의 변화가 다른 하나를 조용히 다시 쓰지는 않는다는 것입니다. 제거된 이름만 본 검토자는 사람 역할의 변화에 대한 증거를 가진 것입니다. 그러나 아직 프로젝트에 구성된 게시 신원에 대한 증거는 가지지 못합니다.

PyPI의 역할 설명은 이 구분을 구체적으로 만듭니다. 조직 계정에서 프로젝트 유지관리자는 릴리스를 업로드할 수 있고, 프로젝트 소유자는 프로젝트와 협업자를 관리할 수 있습니다. 이들은 프로젝트의 사람 중심 관리에 관한 권한입니다. 트러스티드 퍼블리싱은 다른 질문을 다룹니다. 즉, PyPI가 CI 서비스의 OpenID Connect 신원 토큰을 특정 프로젝트에 업로드할 수 있는 단기 토큰으로 교환해야 하는지 여부입니다. PyPI는 프로젝트가 특정 CI 공급자에서 특정 구성을 신뢰한다고 설명합니다. 토큰은 의도적으로 수명이 짧지만, 이 짧은 수명이 구성 등록부와 협업자 등록부를 하나로 합치지는 않습니다.

그렇기 때문에 "계정이 제거되었다"와 "게시 경로가 철회되었다"는 서로 바꿔 쓸 수 없는 문장입니다. 첫 번째는 계정 상태 이벤트를 설명합니다. 두 번째는 트러스티드 퍼블리셔 구성에 대한 관찰과 등록된 각 신원에 대한 결정을 필요로 합니다. 세 번째 명제인 "그 경로를 통해 릴리스가 이루어지지 않았다"는 이벤트 기록을 필요로 합니다. 네 번째인 "릴리스된 파일이 승인된 신원에서 왔다"는 더 좁게, 파일 수준의 게시 증명(attestation)과 그 출처 증명으로 뒷받침될 수 있습니다. 각 문장은 참일 수 있습니다. 그러나 어느 것도 나머지 전부의 지름길이 아닙니다.

PyPI의 증명 문서는 이 경계를 지우는 대신 그 위치를 찾는 데 도움을 줍니다. PyPI 게시 증명(Publish Attestation)은 검증자가 특정 배포물이 트러스티드 퍼블리셔를 통해 업로드되었음을 확인하고 사용된 퍼블리셔 신원을 식별할 수 있게 해줍니다. Integrity API는 지정된 프로젝트, 버전, 파일명에 대한 출처 증명을 제공합니다. 이들은 특정 파일에 대한 귀중한 기록입니다. 그러나 관리자의 오프보딩 체크리스트 전체를 재구성하거나, 이전 구성을 누가 승인했는지 확립하거나, 제거된 사람이 현재 워크플로우를 통제하는지 보여주지는 못합니다. PyPI는 한계를 명시합니다. 증명은 패키지가 어디에서 왔는지 말할 수 있지만, 그 신원이나 코드가 검증자의 신뢰를 받을 만한지는 말할 수 없습니다.

실무적 문제는 기록의 대체입니다. 팀은 눈에 보이는 계정의 종료를 문서화하는 데 능숙합니다. 소유자, 타임스탬프, 사용자 인터페이스가 있기 때문입니다. 반면 퍼블리셔 구성은 다른 관리 화면에 있을 수 있고, CI 워크플로우 권한은 또 다른 곳에서 관리됩니다. 시간에 쫓기면 제거 티켓이 유일한 지속적 증거가 될 수 있습니다. 몇 달 뒤 릴리스를 검토하는 누군가는 그 티켓을 발견하고, 그것이 실제로 물어본 적 없는 질문들—어떤 퍼블리셔 신원이 구성되어 있었는지, 어떤 것이 검토되었는지, 제거된 것이 있는지, 어떤 CI 제약이 남았는지, 이후 어떤 릴리스 출처 증명이 관찰되었는지—에 답했다고 가정할 수 있습니다.

해법은 자격 증명, 저장소 내부 정보, 보안에 민감한 워크플로우 세부사항을 공개할 것을 요구하지 않습니다. Daniel Kade는 한정된 목적을 가진 오프보딩 결합 기록을 권고합니다. 이 기록은 프로젝트와 역할 이벤트를 명시하고, 특정 시점의 각 트러스티드 퍼블리셔 목록을 작성하며, 적절한 보안 수준에서 신원 제약을 보존하고, 책임 검토자와 각 퍼블리셔가 유지·변경·제거되었는지 여부를 기록하고, 이후의 파일 수준 출처 증명을 별도의 관찰로 보존해야 합니다. 보호된 버전은 운영 세부사항을 담고, 공개 또는 감사용 버전은 상태 전환과 그 권한을 보존할 수 있습니다.

이 구조는 나쁜 소식뿐 아니라 좋은 소식도 보존합니다. 팀은 협업자를 제거하면서 해당 변경과 연관된 등록된 퍼블리셔가 없음을 발견할 수 있습니다. 다른 책임 있는 유지관리자가 소유하고 있기 때문에 적절히 검토된 자동화 경로를 의도적으로 유지할 수도 있습니다. 한 CI 신원을 다른 신원으로 교체하고 이후 새 배포물에서 깨끗한 출처 증명을 관찰할 수도 있습니다. 이 어느 결과도 협업자 목록에서 추측되어서는 안 됩니다. 목표는 모든 오프보딩 이벤트를 의심스럽게 만드는 것이 아닙니다. 진실하지만 좁은 접근 권한 변경이 더 넓은, 근거 없는 의미를 획득하는 것을 막는 것입니다.