해당 저장소에 대해 이 문제가 "해결"되었다는 점은 좋은 일입니다. 하지만 근본적인 문제는 여전히 존재합니다. 서명을 어떻게 수행하며, 서명을 검증하기 위한 키의 출처는 무엇입니까?
따라서 이 문제에 대한 제 첫 번째 제안은 git 내장 서명 메커니즘을 활용하는 것입니다. 그러면 Discourse는 설치된 플러그인의 서명자를 추적해야 합니다. 서명자가 변경되면 관리자에게 경고해야 합니다.
이 방식에는 당연히 많은 허점이 있습니다.
서명자의 키를 어디서 가져올까요? plugin.rb와 about.json의 메타데이터를 사용할 수 있습니다. 키 서버(Keyserver)는 좋은 방법이지만… 꽤 복잡합니다. 아니면… meta.discourse.org를 키 서버로 활용하고, 작성자가 공개 키를 등록하도록 하는 것입니다.
가장 최근 커밋만 검증할까요? 충분할 것이며, 도난당한 키에 대해서는 큰 조치를 취하기 어렵습니다.
하지만 키가 도난당했을 경우, 폐기(revocation) 여부를 어떻게 확인합니까? meta가 키를 제공한다면 이 문제를 해결할 수 있습니다.
관리자 UI에는 좋은 방법이지만, docker 컨테이너 내의 플러그인 설치에는 어떻게 적용해야 할까요? 이전에 승인된 서명 키를 shared 디렉터리에 저장하고, 재빌드(rebuild) 과정에 검증 단계를 추가하는 것입니다. 시스템이 중단된 후 클론을 거부하는 상황을 방지하기 위해 빌드 전(pre-build) 체크를 수행하고, 그 사이에 누군가가 저장소를 조작했을 가능성에 대비하여 체크아웃 후(post checkout)에도 체크를 수행하는 것이 좋겠습니다.
그렇다면 서명되지 않은 오래된 저장소는 어떻게 합니까? 그 내용을 검증할 수 없다는 큰 경고 표시와 함께 예/아니오/취소 프롬프트를 표시하는 것입니다.
하지만 관리자로서 제 업무를 더 쉽게 만들어 주세요. 저는 플러그인 개발자로서 여러분의 업무를 더 쉽게 만들고 싶습니다.
현재 업그레이드 과정은 소스 URI에 대한 절대적인 신뢰를 전제로 합니다. 이는 저에게 우려를 불러일으키는데, 소스(GitHub)가 신뢰할 수 없다는 것이 이미 입증되었기 때문입니다. 특히 컨테이너 재빌드 과정의 특정 단계에서는 더욱 그렇습니다. 신뢰 관계에 변화가 있을 때 관리자로서 저에게 경고해 주세요.
저는 관리자로서 플러그인이나 테마 컴포넌트를 추가하기 전에 각각을 철저히 검토했습니다. 그 이후로는 Discourse가 검토를 위한 거의 아무런 지침도 제공하지 않습니다. 오늘 저는 컨테이너를 재빌드해야 했는데, 이는 모든 플러그인을 다시 클론하는 작업을 포함합니다. 릴리스를 고정하기 위해 설정에 고급 변경 사항을 적용하지 않는 한, 저는 사실상 통제력을 잃는 상태입니다.
이것은 제가 충분한 휴식을 취한 소프트웨어 개발자로서 유지보수가 필요한 순간에는 작동할 수 있을지 모릅니다. 하지만 이는 상당한 제약 조건입니다. Discourse가 토론을 위한 훌륭한 플랫폼인 동시에, 기술적으로 안전한 플랫폼이 되도록 해야 합니다. 손상된 플러그인은 심각한 피해를 초래할 수 있습니다. 손상된 테마 컴포넌트 또한 상당한 피해를 줄 수 있습니다.