Rust 크레이트 소유권 정책
소개
이 문서는 Rust 프로젝트가 게시하는 크레이트에 대한 정책을 다룹니다. 이는 RFC 3119를 통해 처음 채택되었습니다.
분류
Rust 프로젝트가 게시하는 Rust 크레이트는 다음 범주 중 하나에 속합니다:
- 의도적 산출물(Intentional artifacts): 이는 어떤 팀(보통 라이브러리 팀)이 의도적으로 릴리스하며, 적극적으로 관리되고, 외부 사용자가 사용하도록 의도되었으며, 의도적으로 공식적인 느낌을 갖는 크레이트입니다. 예시: libc
- 내부 사용: rustc, crates.io, docs.rs 등과 같은 어떤 “내부 클라이언트“가 사용하는 크레이트입니다. 이들의 주된 목적은 외부 사용자가 사용하는 것이 아니지만, 이를 유지 관리하는 팀(일반적으로 해당 내부 클라이언트의 팀)은 크레이트가 더 널리 채택되기를 바랄 수도 있습니다. 이들과 “의도적 산출물” 사이의 경계는 모호할 수 있으며, 궁극적으로는 해당 팀의 목표에 달려 있습니다. 예시: conduit, measureme. 전이 의존성(transitive dependency)으로 나타나도록 의도되었는지 여부에 따라 두 개의 하위 분류가 있습니다.
- 전이적으로 의도됨(Transitively intentional): 이는 의도적 산출물 라이브러리의 의존성으로, 직접 사용되도록 의도되지 않았더라도 사용자의 의존성 트리에 나타나게 됩니다. Rust 프로젝트는 여전히 이러한 크레이트가 마치 “의도적 산출물“인 것처럼 보안 이슈를 처리해야 합니다.
- 전이적으로 의도되지 않음(Not transitively intentional): 이는 배포되는 바이너리, CI 도구, 표준 라이브러리의 의존성이거나, 그 외에 사용자의 의존성 트리에 나타날 것으로 예상되지 않는 것들입니다. Rust 프로젝트는 이러한 크레이트의 보안 이슈를 내부적으로 처리해야 할 수 있지만, 이러한 크레이트의 보안 이슈를 반드시 더 넓은 대중에게 알려야 하는 것은 아닙니다. 이러한 크레이트 중 하나에서 발생한 보안 이슈가 게시된 바이너리(또는 crates.io 등)에 영향을 미치는 경우, 이는 여전히 해당 바이너리 또는 웹사이트의 버그로 처리해야 합니다.
- 실험(Experiment): 이는 어떤 팀이 API 설계(또는 그 밖의 것)를 더 잘 파악하기 위해 사용자들이 사용해 보도록 의도한 실험이었으며, 장기적인 메인테이너십 유지에 대한 약속은 없었습니다. 예시: failure
- 더 이상 사용되지 않음(Deprecated): 이는 과거에는 “의도적 산출물”(또는 실험/내부 사용)이었지만 더는 그렇지 않습니다. 예시: rustc-serialize
- 플레이스홀더: 기능하는 크레이트가 아니며, 공식 도구의 이름 등을 유지하기 위해 사용됩니다. 예시: rustup
- 이관됨: Rust 프로젝트가 소유했을 수 있고 여전히 외부 사용자가 사용하도록 의도되어 있지만, 더 이상 공식적으로 취급되지 않습니다. 이러한 경우 해당 크레이트는 더 이상 Rust 프로젝트가 소유/관리하지 않습니다. 예시: rand
정책
조직 내 모든 크레이트는 crates.io에서 최소 하나의 팀이 소유해야 합니다. 팀들은 이를 위해 rust-lang/foo 팀을 사용해야 합니다. 이관되지 않은 크레이트는 개인 계정을 소유자로 둘 수 없습니다. 크레이트에 팀 소속이 아닌 추가 소유자가 필요한 경우, 해당 팀은 프로젝트 그룹을 만들어야 합니다. 이는 팀(또는 프로젝트 그룹) 소속이 아닌 사용자가 저장소에 대한 메인테이너 접근 권한을 갖는 것을 금지하지는 않으며, 단지 이들이 게시하는 것만 금지한다는 점에 유의하십시오.
현재로서는 크레이트가 팀 하나에 의해서만 소유되는 것은 불가능합니다. 이러한 경우에는 rust-lang-owner 계정(또는 인프라 팀이 결정할 유사한 계정)을 임시방편으로 사용할 수 있습니다. 각 크레이트에 대한 책임 소재를 명확히 하기 위해, 이 계정은 가능한 한 단계적으로 폐지하도록 노력해야 합니다. 자동으로 게시되는 크레이트의 경우, GitHub Actions에서 신뢰된 게시(trusted publishing)를 사용하십시오.
조직 내의 각 크레이트, 그리고 향후 조직에 추가될 모든 크레이트는 위의 분류에 따라 어느 범주에 속하는지 결정해야 합니다. 크레이트를 등록할 때 어떤 범주에 속해야 할지 확신이 서지 않거나 아직 결정을 내리고 싶지 않다면, “실험적(Experimental)“을 선택하십시오.
게시되는 각 크레이트는 README를 포함해야 합니다. 최소한 이 README는 주 소유 팀을 언급해야 합니다. 크레이트는 해당 범주에 따라 README와 문서 루트에 다음 정보도 포함해야 합니다.
의도적 산출물(Intentional artifact)
“의도적 산출물” 크레이트는 자신의 약속(commitment)을 자유롭게 선택할 수 있지만, 그것이 무엇인지 메시지에서 명확히 밝혀야 합니다. 팀에 헌장이 있게 되면, 해당 크레이트 역시 헌장에서 의도적 산출물로 언급되어야 합니다. 의도적 산출물을 폐기(deprecate)하는 것은 가볍게 여겨서는 안 되며 RFC가 필요합니다.
이러한 메시지의 예시는 다음과 같은 텍스트일 수 있습니다.
이 크레이트는 더 넓은 생태계에서 사용하기 위해 Rust [team] 팀이 유지 관리합니다. 이 크레이트는 1.0 이후 버전이며 API에 대해 semver 호환성을 따릅니다.
이러한 크레이트의 보안 이슈는 보안 대응 워킹 그룹(Security Response WG)이 적절한 비중과 신중한 메시지로 처리해야 하며, 프로젝트의 보안 정책에 따라 보고되어야 합니다.
내부 사용(Internal use)
“내부 사용” 크레이트는 readme/문서 상단 근처에 다음 텍스트를 포함해야 합니다.
이 크레이트는 [team]이 유지 관리하며, 주로 [rust project(s)]가 사용하기 위한 것이고 외부 사용을 의도하지 않습니다(전이적 의존성으로서의 사용은 예외). 이 크레이트는 사전 경고 없이 API에 중대한 변경을 가하거나 폐기될 수 있습니다.
“전이적 의존성으로서인 경우를 제외하면“이라는 텍스트는 해당 크레이트가 의도적 산출물 라이브러리의 의존성(“전이적으로 의도적”)인 경우 포함되어야 합니다.
전이적으로 의도적인 라이브러리의 보안 이슈는 의도적 산출물인 것처럼 처리되어야 합니다.
실험(Experiment)
“실험” 크레이트는 자신이 실험임을 언급해야 합니다. 실험 크레이트는 범위가 한정된 방식으로 사용되도록 의도될 수 있으므로, 사용을 의도한다면 무엇을 보장하는지 명확히 밝혀야 합니다.
이러한 메시지의 예시는 다음과 같은 텍스트일 수 있습니다.
이 크레이트는 [thingy]에 관한 실험의 일환으로 [team]이 관리합니다. 저희는 사람들이 자신의 프로젝트에서 이 크레이트를 사용해 보고 [method]를 통해 피드백을 제공하기를 권장하지만, 장기적인 유지 관리는 보장하지 않습니다.
또는, 전혀 사용될 의도가 없는 실험의 경우:
이 크레이트는 [team]이 관리하며 내부 실험입니다. 저희는 안정성이나 장기적인 유지 관리를 보장하지 않으므로, 사용에 따른 위험은 스스로 감수하십시오.
이상적으로는, 피드백 목적으로 게시되는 실험적 크레이트는 실험의 목적, 대략적인 기간, 진행 절차를 정리한 문서를 링크로 제공해야 합니다.
폐기됨
“폐기됨” 크레이트는 readme/문서 상단 근처에 다음 텍스트를 포함해야 합니다:
이 크레이트는 폐기되었으며 사용을 의도하지 않습니다.
자리표시자
“자리표시자” 크레이트는 게시된 readme/문서에 다음 텍스트를 포함해야 합니다:
이 크레이트는 [tool]의 크레이트 이름을 예약하기 위해 존재하는, 기능적으로 비어 있는 크레이트입니다. 사용해서는 안 됩니다.
일반적으로 크레이트 이름을 얀크를 통해 예약하는 것보다 빈 자리표시자 크레이트를 게시하는 편이 더 낫습니다. 그래야 사람들이 해당 크레이트를 사용할 수 없는 이유를 이해하는 데 도움이 되는 readme가 존재하게 됩니다.
이주됨
rust-lang/foo 팀 소유권을 포함하여 공식적으로 보이는 흔적을 제거하는 것 외에 이들에 대해 어떤 조치를 취해야 할지는 불분명합니다. 현재 이러한 크레이트는 하나(rand)뿐입니다.
이들은 대체로 “팀 관리” 크레이트로 간주되어서는 안 됩니다. 이 카테고리는 이주를 최종 상태로 논할 수 있도록 완전성을 위해 이 RFC에 포함되어 있습니다.
전환과 신규 크레이트
팀은 이러한 카테고리 중 어디에든 자유롭게 새 크레이트를 만들 수 있습니다. 다만 “의도적 아티팩트” 크레이트는 반드시 RFC를 동반해야 합니다. 팀 헌장을 갖추는 방향으로 나아감에 따라, 이는 헌장 변경(이는 RFC를 요구하거나 자체 프로세스를 사용할 수 있음)으로 전환될 수 있습니다. 팀은 이러한 크레이트를 생성했을 때 council@rust-lang.org에 알려야 하며, 이를 통해 리더십 위원회가 이러한 크레이트를 추적하고 이 정책이 적용되도록 보장할 수 있습니다.
때때로 크레이트에 대한 팀의 계획이 바뀔 수 있습니다: 실험이 종료되거나, 크레이트가 폐기되어야 하거나, 팀이 더 넓은 사용을 위해 무언가를 릴리스하기로 결정할 수 있습니다.
일반적으로 팀은 이러한 전환이 이루어질 때 council@rust-lang.org에 알려야 합니다.
“의도적 아티팩트“에서 벗어나는 전환은 모두 RFC가 필요합니다.
“의도적 산출물“로의 모든 전환은 이상적으로는 RFC와 함께 이루어져야 하며, 헌장이 있는 경우 팀 헌장의 갱신도 함께 이루어져야 합니다.
이관은 기본적으로 더 이상 절대 발생해서는 안 되지만, 정말로 필요한 경우에는 RFC와 리더십 위원회의 승인이 필요합니다. 팀이 어떤 크레이트에 대한 작업을 중단하고자 한다면, 이를 폐기하고 커뮤니티가 포크하거나 자체적으로 무언가를 만들도록 장려해야 합니다. 저장소는 외부로 이전될 수 있지만, crates.io의 이름은 Rust 프로젝트가 계속 보유하며 새로운 메인테이너 그룹은 새로운 크레이트 이름을 선택해야 합니다.
“전이적으로 의도적인” 크레이트가 폐기되는 경우, 보안 이슈가 계속 처리될 수 있도록 주의를 기울여야 합니다.
나머지 유형들 사이의 전환은, 강한 안정성/유지관리 보장이 없음을 명시적이고 명확하게 밝히고 있으므로 자유롭게 이루어질 수 있습니다.
기존 크레이트에 이를 적용하기
잠재적으로 “공식“인 모든 기존 크레이트에 대해 감사를 수행하여 목록으로 수집하고, 각각의 팀과 카테고리가 무엇이어야 하는지 대략적으로 판단해야 합니다.
이 목록을 확보하면, 팀에 크레이트 목록을 제시하고 분류가 정확한지 확인해 달라고 요청할 수 있습니다. 일부 크레이트의 경우, 팀이 특정 크레이트에 대한 의도를 파악해야 하므로 다소 시간이 걸릴 수 있습니다.
그런 다음 팀과 협력하여 문서에 이러한 변경 사항을 반영합니다. 또한 모든 크레이트가 적절한 rust-lang/teamname GitHub 소유자를 갖도록 하고, 소유자 목록에서 개인 계정을 제거합니다.
광범위한 커뮤니티에서 직접 사용되는 크레이트의 경우, 이를 “의도된 산출물” 이외의 것으로 분류하게 된다면 이러한 “변경“을 커뮤니티에 알리려는 시도가 있어야 합니다. 이러한 크레이트에 대해 공식적인 약속이 이루어진 적은 없었지만, 막연한 공식성의 느낌으로 인해 사람들이 그런 약속이 있었다고 믿게 되었을 수 있으므로, 사람들이 계속해서 오해하지 않도록 최소한 이를 바로잡으려는 시도는 해야 합니다. 이 작업이 필요한지 여부와 그 방법은 각 팀이 개별적으로 판단할 수 있습니다.
이 작업의 상당 부분은 병렬로 진행할 수 있으며, 한꺼번에 이루어질 필요는 없습니다.