Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Rust 크레이트 소유권 정책

소개

이 문서는 Rust 프로젝트가 게시하는 크레이트에 관한 정책을 다룹니다. 이 정책은 처음에 RFC 3119를 통해 채택되었습니다.

분류

Rust 프로젝트가 게시하는 Rust 크레이트는 다음 분류 중 하나에 속합니다.

  • 의도된 산출물: 어떤 팀(대개 라이브러리 팀)이 의도적으로 릴리스하고, 활발히 유지보수되며, 외부 사용자가 사용하도록 의도되었고, 의도적으로 공식적인 성격을 띠는 크레이트입니다. 예: libc
  • 내부용: rustc, crates.io, docs.rs 등 어떤 “내부 클라이언트“가 사용하는 크레이트입니다. 주된 목적은 외부 사용자가 사용하는 것이 아니지만, 이를 유지보수하는 팀(대개 해당 내부 클라이언트의 팀)은 크레이트가 더 널리 채택되기를 바랄 수도 있습니다. 이 분류와 “의도된 산출물” 사이의 경계는 모호할 수 있으며, 결국 팀의 목표에 따라 달라집니다. 예: conduit, measureme. 전이 의존성으로 나타나도록 의도되었는지에 따라 두 가지 하위 분류가 있습니다.
    • 전이적으로 의도됨: 의도된 산출물 라이브러리의 의존성으로, 직접 사용하도록 의도되지 않았더라도 사용자의 의존성 트리에 나타납니다. Rust 프로젝트는 여전히 이러한 크레이트의 보안 이슈를 “의도된 산출물“인 것처럼 처리해야 합니다.
    • 전이적으로 의도되지 않음: 배포되는 바이너리, CI 도구, 표준 라이브러리의 의존성이거나, 그 밖에 사용자의 의존성 트리에 나타날 것으로 예상되지 않는 크레이트입니다. Rust 프로젝트는 이러한 크레이트의 보안 이슈를 내부적으로 처리해야 할 수 있지만, 이러한 크레이트의 보안 이슈를 반드시 일반 대중에게 알릴 필요는 없습니다. 이러한 크레이트 중 하나의 보안 이슈가 게시된 바이너리(또는 crates.io 등)에 영향을 미친다면, 이는 여전히 해당 바이너리나 웹사이트의 버그로 처리해야 합니다.
  • 실험: 장기적인 유지보수 약속 없이, 사용자가 가져다 써 봄으로써 API 설계(또는 그 밖의 무엇이든)에 더 나은 정보를 제공하도록 의도된 팀의 실험이었던 크레이트입니다. 예: failure
  • 지원 중단: 한때 “의도된 산출물”(또는 실험/내부용)이었지만 더 이상 그렇지 않은 크레이트입니다. 예: rustc-serialize
  • 자리 표시자: 실제로 기능하는 크레이트가 아니며, 공식 도구의 이름 등을 확보해 두기 위해 사용됩니다. 예: rustup
  • 이관됨: Rust 프로젝트가 소유했을 수 있고 여전히 외부 사용자가 사용하도록 의도되었지만, 더 이상 공식적인 것으로 의도되지 않은 크레이트입니다. 이러한 경우 해당 크레이트는 더 이상 Rust 프로젝트가 소유하거나 관리하지 않습니다. 예: rand

정책

조직 내의 모든 크레이트는 crates.io에서 최소 한 개 이상의 팀이 소유해야 합니다. 팀은 이를 위해 rust-lang/foo 팀을 사용해야 합니다. 이관되지 않은 크레이트는 개인 계정을 소유자로 둘 수 없습니다. 크레이트에 팀에 속하지 않은 추가 소유자가 필요하다면, 팀은 프로젝트 그룹을 만들어야 합니다. 이는 팀(또는 프로젝트 그룹)에 속하지 않은 사용자가 저장소에 대한 메인테이너 권한을 갖는 것을 금지하지 않으며, 단지 그들이 게시하는 것만 금지한다는 점에 유의하십시오.

현재는 크레이트를 팀만 소유하도록 할 수 없습니다. 이런 경우에는 rust-lang-owner 계정(또는 인프라 팀이 정하는 비슷한 계정)을 임시방편으로 사용할 수 있습니다. 각 크레이트의 책임자가 누구인지 분명히 하려면 이 계정은 가능한 한 단계적으로 없애 나가야 합니다. 자동으로 게시되는 크레이트에는 GitHub Actions의 신뢰할 수 있는 게시(trusted publishing)를 사용하십시오.

조직의 모든 크레이트와 앞으로 조직에 추가될 모든 크레이트는 위 분류에 따라 자신이 어느 범주에 속하는지 정해야 합니다. 크레이트를 등록할 때 어느 범주로 해야 할지 확실하지 않거나 아직 결정하고 싶지 않다면 “실험(Experimental)“을 선택하십시오.

게시되는 모든 크레이트에는 README가 있어야 합니다. 이 README에는 최소한 주 소유 팀이 명시되어야 합니다. 크레이트는 범주에 따라 README와 문서 루트에 다음 정보도 포함해야 합니다.

의도된 산출물

“의도된 산출물” 크레이트는 무엇을 약속할지 스스로 정할 수 있지만, 그 약속이 무엇인지 안내 문구에서 명확히 밝혀야 합니다. 팀에 헌장이 있거나 생기게 되면, 해당 크레이트는 헌장에도 의도된 산출물로 명시되어야 합니다. 의도된 산출물의 지원 중단은 가볍게 여겨서는 안 되며 RFC가 필요합니다.

이러한 안내 문구의 예시는 다음과 같습니다.

이 크레이트는 더 넓은 생태계에서 사용할 수 있도록 Rust [team] 팀이 유지 관리합니다. 이 크레이트는 1.0 이후 버전이며, API에 대해 semver 호환성을 따릅니다.

이러한 크레이트의 보안 이슈는 보안 대응 워킹 그룹(Security Response WG)이 사안의 무게에 맞게 신중한 안내와 함께 처리해야 하며, 프로젝트의 보안 정책에 따라 보고되어야 합니다.

내부 사용

“내부 사용” 크레이트는 readme/문서의 윗부분에 다음 문구를 포함해야 합니다.

이 크레이트는 [team] 팀이 유지 관리하며, 주로 [rust project(s)] Rust 프로젝트에서 사용하기 위한 것으로 외부 사용(전이 의존성으로 사용하는 경우는 제외)을 의도하지 않습니다. 이 크레이트는 사전 경고 없이 API에 주요 변경을 가하거나 지원 중단될 수 있습니다.

크레이트가 의도적 산출물 라이브러리의 의존성인 경우(“전이적 의도”) “전이 의존성으로 사용하는 경우는 제외” 문구를 포함해야 합니다.

전이적으로 의도된 라이브러리의 보안 이슈는 의도된 산출물과 동일하게 처리해야 합니다.

실험

“실험” 크레이트는 실험임을 명시해야 합니다. 실험 크레이트는 제한된 범위에서 사용되도록 의도될 수 있으므로, 사용을 의도한 경우라면 무엇을 보장하는지 분명히 밝혀야 합니다.

이러한 안내 문구의 예시는 다음과 같습니다.

이 크레이트는 [thingy]에 관한 실험의 일환으로 [team]이 유지 관리합니다. 여러분의 프로젝트에서 이 크레이트를 사용해 보고 [method]를 통해 피드백을 주시기 바랍니다. 다만 장기적인 유지 관리는 보장하지 않습니다.

또는 사용을 전혀 의도하지 않은 실험의 경우는 다음과 같습니다.

이 크레이트는 [team]이 유지 관리하는 내부 실험입니다. 안정성이나 장기적인 유지 관리는 보장하지 않으므로, 사용에 따른 위험은 사용자가 부담합니다.

피드백을 받기 위해 게시하는 실험 크레이트에는 실험의 목적, 대략적인 기간, 진행 절차를 정리한 문서가 있어 이를 링크할 수 있는 것이 가장 좋습니다.

폐기됨

“폐기됨” 크레이트는 readme/문서 상단 가까이에 다음 문구를 포함해야 합니다.

이 크레이트는 폐기되었으며 사용하도록 의도된 것이 아닙니다.

자리 표시자

“자리 표시자” 크레이트는 게시된 readme/문서에 다음 문구를 포함해야 합니다.

이 크레이트는 [tool]의 크레이트 이름을 확보해 두기 위해 존재하는, 기능상 비어 있는 크레이트입니다. 사용해서는 안 됩니다.

일반적으로 yank로 크레이트 이름을 확보해 두는 것보다 비어 있는 자리 표시자 크레이트를 게시하는 편이 낫습니다. 그래야 해당 크레이트를 사용할 수 없는 이유를 사람들이 이해하는 데 도움이 되는 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 소유자가 지정되어 있는지 확인하고, 소유자 목록에서 개인 계정을 제거합니다.

더 넓은 커뮤니티에서 직접 많이 사용하는 크레이트를 결국 “의도된 산출물” 외의 범주로 분류하게 된다면, 이 “변경“을 커뮤니티에 알리려는 노력이 있어야 합니다. 이러한 크레이트에 대해 공식적인 약속이 있었던 것은 아니지만, 막연히 공식적이라는 인상 때문에 사람들이 그런 약속이 있었다고 믿었을 수 있으므로, 사람들이 계속 오해하지 않도록 적어도 이를 바로잡으려는 시도는 해야 합니다. 이 작업이 필요한지 여부와 그 방법은 각 팀이 판단할 수 있습니다.

이 작업의 상당 부분은 병렬로 진행할 수 있으며, 한꺼번에 이루어질 필요는 없습니다.