안전 모드(safe-mode)를 사용하여 다른 Discourse 배포판에서 어떤 변경 사항을 적용했는지 파악할 수도 있습니다:
Purism은 몇 개의 테마 스크립트(안전 모드가 모든 테마를 차단한다고 생각하기에, 실제로는 공식 Discourse의 일부일 수도 있음)와 HTML 파일 내부에 포함된(외부 JS 파일이 아닌) const DELAY_TARGET=2e3,POLLING_INTERVAL=50,splashS로 시작하는 내부 JavaScript 조각 하나만 가지고 있습니다.
Exercism은 나중에 코어에 추가된 것으로 보이는 discourse-spoiler-alert 플러그인과 Purism과 정확히 동일한 내부 JS를 가지고 있습니다.
FSF Member 포럼은 다른 두 곳과 정확히 동일한 내부 JS만 가지고 있습니다.
Discourse Meta(이 포럼)는 많은 JS 차이가 있는 것으로 보입니다.
discourse-activity-pub
discourse-customer-flair-plugin (이 플러그인의 라이선스를 어디에서도 찾을 수 없었습니다)
discourse-deprecation-collector
discourse-doc-categories
discourse-new-features-feeds (이것도 라이선스를 찾을 수 없었습니다)
소스 맵에 대한 링크조차 없는 스크립트를 포함한 많은 스크립트들
따라서 제 작은 표본(3개)에 기반하더라도, 대부분의 서드파티 배포판은 메인라인 Discourse에 매우 가까운 것으로 보입니다. 하지만 이번에는 이 배포판이 대부분의 배포판에 포함되지 않을 플러그인들을 포함하고 있는 것처럼 보입니다. 모든 플러그인의 라이선스가 있는 소스 코드를 어디서 찾을 수 있는지 아시나요? 메인 저장소에 있을까요? 메인 저장소에서 일부 이름을 grep으로 검색해 보았지만 찾을 수 없었으며, 제가 놓친 것일 수도 있습니다.
예를 들어 "discourse-new-features-feeds"를 포럼 전체에서 검색해 보았지만 아무것도 찾지 못했습니다. 일부 확장 기능은 플러그인 디렉터리, GitHub, 또는 이 포럼에서 찾을 수 있었지만, discourse-new-features-feeds와 discourse-customer-flair-plugin의 경우에는 아무것도 찾을 수 없었습니다. 모든 플러그인 스크립트를 확인하지는 않았기 때문에 제가 찾지 못한 것이 더 있을 수 있습니다.
이들이 엔터프라이즈 고객이며 Discourse에 포럼을 특별히 커스터마이즈해 달라고 요청했을 수도 있습니다.
또한, 클라이언트 측 커스터마이즈를 확인하기 위해 안전 모드를 사용하려고 한다면, 오히려 그 기능이 비활성화되지 않을까요? 이런 사이트에서는 애초에 어떻게 활성화할 수 있을까요?
호기심에, 여기의 전체적인 논거가 정확히 무엇인지 궁금합니다. 여러분이 제기하는 우려사항들을 고려할 때, 인터넷 서핑을 아예 할 수 없는 것이 맞나요?
여러분은 "라이선스"에 대해 말씀하고 있습니다. 하지만 특정 포럼을 단순한 사용자로 사용하는 라이선스와, 실제로 포럼 소프트웨어를 실행(=다른 사람이 그걸로 포럼을 세팅하고 싶을 때)하는 라이선스는 다릅니다. 왜 사용자가 후자에 신경 써야 할까요? 지키고 싶은 어떤 원칙 때문일까요? 재배포되지 않는 모든 커스터마이징은 "독점적"일 것이라고 추측합니다. 이는 이 경계가 어디서 시작되고 어디서 끝나는지에 대한 질문을 불러일으킵니다.
자바스크립트가 브라우저에서 실행할 수 있는 것에 대해 경계할 수 있습니다(그 위험성과 가능성은 자주 논쟁의 대상이 됩니다. 제한적이어야 한다는 것이 일반적입니다). 하지만 Discourse가 자바스크립트 없이 실행될 수 있는지, 적어도 올바르게 실행될 수 있는지는 확실하지 않습니다. 직접 시도해 볼 수 있습니다. 예를 들어, 이를 위한 인기 있는 “NoScript” 브라우저 확장 프로그램이 있습니다.
여전히 그 추론에 대해 궁금합니다: 잠재적인 악성 코드에 관한 것인가요? 이 경우, 포럼이 수정되지 않은 버전을 실행한다고 말하는 라이선스를 보면 더 마음이 놓인다는 것은 저에게는 큰 의미가 없어 보입니다. 아니면 무엇이 문제인가요?
일반적으로 저는 비자유 소프트웨어(nonfree software) 실행을 피하고 싶습니다. 주요 이유는 제 컴퓨터에서 실행되는 소프트웨어에 대해 제가 통제권을 가져야 한다고 생각하기 때문이며, 추가적인 이유는 수정이 불법일 수 있는 버그라는 개념을 좋아하지 않기 때문입니다. 또한, 제 소프트웨어를 제3자의 감독이나 책임 소재가 없는 수백 개의 서로 다른 독립적인 웹사이트에서 다운로드하는 것보다 소수의 신뢰할 수 있는 저장소(repository)에서 받는 것이 좋다고 생각합니다. 따라서 제가 신뢰하는 저장소에서 제가 사용하는 소프트웨어를 패키징할 자유가 있는 것이 저에게는 중요합니다(다만, 현재 기술 수준에서는 웹사이트가 제공하는 JS의 경우 이는 매우 비현실적입니다).
다른 사람들의 컴퓨터에서 실행되는 소프트웨어에 대해 제가 통제권을 가져야 한다고 생각하지는 않습니다. 서버 운영자가 그 통제권을 가져야 한다고 생각하며, 여러 사용자가 소프트웨어를 완전히 통제하는 것은 합리적이지 않다고 보기 때문입니다.
아니요, 신뢰할 수 없는 당사자로부터 임의의 코드를 자동으로 다운로드하고 실행하는 프로그램을 사용하지 않거나, 그러한 프로그램이 그렇게 하지 않도록 수정하는 경우(예: 웹 브라우저에 LibreJS를 설치하는 것)에는 인터넷에서 비자유 소프트웨어 실행을 피하는 것은 비교적 쉽습니다.
제가 알기로는, 포럼의 대부분의 기능을 사용하려면 포럼 소프트웨어를 실행해야 하지만, 게시물 읽기는 소프트웨어 실행 없이도 가능합니다. 계정을 등록하고 주제를 게시하려면 포럼 소프트웨어를 실행해야 하는 것 같습니다. 대부분의 사람들이 이를 인지하지 못하는 이유는 대부분의 브라우저가 사용자가 알지 못한 채 웹사이트가 전송하는 모든 소프트웨어를 다운로드하고 실행하기 때문입니다.
포럼 소프트웨어의 일부는 서버에서 실행되며, Discourse 인스턴스는 해당 소프트웨어를 반드시 배포하지 않을 수 있습니다. 이는 제가 서버 측에 인스턴스가 추가한 비자유 소프트웨어를 반드시 받지 않을 수도 있다는 것을 의미하므로, 저는 이를 수행하는 인스턴스를 피하려 하지 않습니다.
정의에 대한 aside
제 견해에 따르면, 배포되지 않는 소프트웨어는 단일한 “소유자”(저자)를 가지고 있기 때문에 "독점적(proprietary)"이지만, 동시에 모든 사용자(단 한 명인 저자)가 원하는 것을 할 수 있기 때문에 "자유(free)"이기도 합니다. 음, 서버와 상호작용하는 사람들을 그 서버의 소프트웨어 "사용자"라고 할 수 있으니, “사용자” 대신 다른 단어를 사용해야 할지도 모르겠습니다. 하지만 대체로 어떤 단어를 써야 할지 확신이 서지 않습니다. 누군가에게 전화를 걸면, 저는 기술적으로 전화 네트워크나 다른 사람의 휴대폰에서 실행되는 소프트웨어의 "사용자"가 되는 것일지도 모릅니다.
네, 저는 NoScript를 설치해 두었고, 클라이언트 측 Discourse 소프트웨어를 차단하면 당연히 Discourse는 그것을 실행할 수 없습니다. 왜냐하면 제가 브라우저가 스크립트를 실행하는 것을 막았기 때문입니다. 제 컴퓨터에서 실행되지 않는 서버 측 소프트웨어는 NoScript에 의해 실행이 차단되지 않습니다. 이 상태에서, Discourse 서버 소프트웨어가 제공하는 주제와 댓글은 볼 수 있지만, 등록과 게시를 하려면 클라이언트 측 JavaScript 소프트웨어를 사용해야 하는 것 같습니다.
멀웨어에 관해 말하자면, 자유 소프트웨어 프로그램이 멀웨어라면 누군가는 그것이 멀웨어가 아니도록 수정하여 대신 사용할 수 있도록 그 수정된 버전을 배포할 수 있습니다. 사이트에서 제공하는 JavaScript의 경우 현재 이는 다소 비현실적입니다. 이상적으로는 소프트웨어가 자유 소프트웨어임을 직접 명시하는 라이선스가 있어야 하므로, 소프트웨어가 수정되었더라도 여전히 자유 소프트웨어로 사용하는 것이 합법적이어야 합니다. 현재로서는 제가 사용하는 배포판이 사용하는 소프트웨어의 버전(예: Discourse 서버 소프트웨어를 수정하여 특정 커밋이 사용되고 있다고 주장하는 경우 실제로는 다른 커밋인 경우 등)에 대해 "거짓말"을 하지 않는다고 신뢰해야 합니다.
아마도 이 답변이 다소 길어졌을 수 있지만, 핵심은 제가 소프트웨어 자유를 중시하므로 제 컴퓨터에서 비자유 소프트웨어를 실행하는 것을 피하고 싶다는 것입니다.
이 경우 "그들"은 Discourse Meta를 가리킵니다. Discourse(회사)의 일부가 아닌가요?
네, 제가 말하고자 한 것은 이렇습니다: 안전 모드를 사용하면 수정 사항에서 스크립트를 비활성화할 수 있고, 그런 다음 두 경우 모두에서 브라우저로 전송되는 소프트웨어를 비교할 수 있습니다. 차이는 수정 사항과 테마입니다.
안전 모드는 /safe-mode(예: http://meta.discourse.com/safe-mode)로 이동하여那里的 옵션을 선택함으로써 활성화할 수 있습니다. 그 페이지는 JavaScript를 필요로 하지 않으므로, NoScript, LibreJS, Haketilo와 같은 확장 프로그램을 사용하여 JS를 차단하거나 Firefox 기반 브라우저의 설정에서 javascript.enabled를 false로 설정하는 동안에도 안전 모드를 활성화할 수 있습니다.
이 시점에서, 안전 모드로 무엇이 제거되었는지 확인하기 위해 두 페이지의 스크립트 태그를 비교할 수 있습니다. 저는 다음과 같은 스크립트를 사용했습니다:
script-diff.js
// SPDX-FileCopyrightText: 2024 Jacob K
//
// SPDX-License-Identifier: CC0-1.0
// 스크립트가 더 많은 페이지에서
const scriptSrcArr = [];
for (script of document.scripts) {
if (script.src) {
scriptSrcArr.push(script.src);
} else {
scriptSrcArr.push(script.textContent);
}
}
console.log(scriptSrcArr)
// 스크립트가 더 적은 페이지에서 (첫 번째 페이지에서 배열을 마우스 오른쪽 버튼으로 클릭하고 "Copy Object"를 클릭해야 합니다)
scriptSrcArr = PASTE_OBJECT_FROM_OTHER_PAGE_HERE
for (script of document.scripts) {
if (!scriptSrcArr.includes(script.src)) {
console.info(script)
}
}
// 첫 번째 페이지의 스크립트가 두 번째 페이지의 스크립트의 초집합(superset)이라고 가정합니다
@Jagster (Discourse의 제안에 따라, 편집을 통한 답변을 시도합니다. 멋진 제안 기능입니다!)
이것은 제가 meta.discourse.org를 통해 배포되는 Discourse가 비자유 소프트웨어(nonfree software)라는 생각을 하게 만들었습니다. 이는 "Discourse 코드베이스 전체가 공개되어 있으며 대중에게 자유롭게 이용 가능합니다"라는 주장과 “Discourse는 100% 무료인 오픈소스 포럼 소프트웨어입니다.”(두 주장 모두 www.discourse.org에서 발췌)라는 주장이 오해의 소지가 있다는 것을 의미합니다. 소프트웨어가 플러그인과 동일한 것이 아니기 때문에 기술적으로는 사실일 수 있지만요. 마치 제가 비자유 소프트웨어를 실행하도록 속은 것 같은 기분이 듭니다
아마도 그 주장은 기존 인스턴스에 가입하려는 사람들이 아니라, Discourse 인스턴스를 호스팅하려는 사람들을 위해 의도된 것일 것입니다.
그런 기분을 정말 자주 느끼실 것 같습니다. 이모지를 쓰지 않은 이유는, 이것이 단순히 인터넷과 그 안의 앱이 작동하는 방식에 대한 진술이기 때문입니다.
방금 커스터마이징이 나쁘다고 말씀하셨고, 베이스가 오픈 소스라면 모든 추가 기능(add-ons)도 무료여야 한다고 하셨죠. 글쎄요, WordPress가 그렇게 했을 수도 있지만, wordpress.com은 확실히 그렇지 않을 겁니다. 하지만 제 워드프레스 사이트를 방문하시면 많은 커스텀 작업이 이루어져 있음을 보실 수 있습니다. 일부는 독점적(propietary)이고, 일부는 오픈 소스이며, 일부는 커스텀이고, 일부는 제가 직접 만든 것입니다. 그리고 이 현실에서 두 가지 일이 일어날 수 있습니다:
커스텀 작업의 모든 코드가 공개될 것입니다.
유효한 라이선스가 있는지 여부에 대해 나나 다른 방문자에게 알릴 것입니다.
하지만 Discourse, WordPress, Moodle 등이 일부 추가 기능이 무료가 아닌 경우에도 왜 무료가 아닌가 하는 점을 이해하기가 어렵습니다. 그 생각 뒤에 있는 논리를 이해할 수 없습니다.
자신의 Discourse 사이트 관리자는 자신의 포럼을 자유롭게 커스터마이징할 수 있는 권한이 있습니다. 플러그인, 테마, TC(Theme Component)는 반드시 오픈소스일 필요가 없습니다. Discourse도 이에 대해 문제 삼지 않습니다. 왜냐하면 공개 저장소 대신 비공개 저장소를 사용하여 이러한 커스터마이징을 연결할 수 있는 방법이 존재하기 때문입니다.
따라서 플러그인도 마찬가지이며, 매우 매우 매우 드문 경우(아마 거의 없을지도 모릅니다!)를 제외하고는 이러한 커스터마이징이 유료인 경우는 없습니다. [1] 따라서 아무것도 '비자유’하지 않습니다: 모든 것이 자유롭습니다.
제 핵심은, 오픈소스 소프트웨어는 자유롭다는 것입니다. 플러그인은 무료입니다 - 사용하는 것은 여러분의 선택입니다. 테마, TC 등도 마찬가지입니다. 하지만 오픈소스가 아닌 것은 유료일 수 있으나, 관리자들이 선택하여 무료로 사용 가능하게 한 것입니다. 만약 여러분이 비공개 소스 커스터마이징을 최대한 잘 복사하여 스스로 사용하길 원한다면, 아무도 이를 막을 수 없습니다.
Discourse는 무료이며, 공개된 커스터마이징 [2]은 무료이고, 비공개 커스터마이징도 사용하는 것은 무료입니다 (적어도 상당한 부분에서 그렇습니다. 하지만
. 소스 코드 자체를 소유자에게 지불하는 것은 별개의 문제입니다.
결론적으로, 여러분이 직접 플러그인/테마/TC를 만들어 배포하지 않는 한, 항상 무료로 커스터마이징을 설치할 수 있습니다. 아무도 이를 막지 않습니다.
이 말이 무례하거나 간결하게 들리거나, 같은 내용을 반복하며 빙빙 도는 것 같다면 죄송합니다.
그것은 반드시 사실이 아닙니다. 다시 강조하지만, 이것은 가격의 무료가 아니라 자유(liberty)의 무료에 관한 것입니다. FSF(자유 소프트웨어 재단)의 정의에 따라 자유 소프트웨어로 보기에는 라이선스가 너무 제한적인 오픈소스 프로젝트들이 있습니다. 예를 들어 MongoDB와 ElasticSearch가 그렇습니다.
자유 소프트웨어를 실행한다고 해서 그것에 대한 통제권을 가진다는 것을 의미하지는 않습니다.
그러므로 '신뢰(trusted)'와 '자유(free)'를 혼동하고 있는 것 같습니다. 서버 관리자가 Discourse를 빌드할 때, 빌드 프로세스는 NPM에서 다양한 종류의 패키지를 다운로드합니다. 그것들을 항상 신뢰할 수 있을까요? (역사를 통해 이것이 사실이 아님을 배웠습니다 - 예시 및 또 다른 예시).
당신은 "추측(guess)"하고 있습니다 서버 관리자는 커밋 해시를 변경하지 않고도 수정을 가할 수 있습니다. 그리고 플러그인도 자바스크립트 코드를 주입할 수 있습니다.
부드럽게 말하고 싶지만, 그것은 사실이 아닙니다.
이것은 무료/비무료 또는 오픈소스/클로즈드소스에 관한 것이 아니라, 신뢰에 관한 것입니다.
Discourse 인스턴스를 방문하면 당신은 다음에 대해 신뢰를 해야 합니다.
서버 관리자(들)
Discourse GitHub 조직에서 커밋 접근 권한을 가진 모든 사람
플러그인 저장소에서 커밋 접근 권한을 가진 모든 사람
GitHub의 모든 사람
전체 NPM 소프트웨어 체인
사용 중인 모든 NPM 저장소에 커밋 접근 권한을 가진 모든 사람
브라우저 소프트웨어에 대한 통제를 가진 모든 사람
SSL 인증서와 신뢰 체인을 공급한 회사
최소 몇천 명은 될까요?
플러그인과 테마 컴포넌트는 별도의 저장소에서 찾을 수 있습니다.
모든 플러그인이 오픈소스는 아닙니다(예: discourse-customer-flair-plugin은 AFAIK(제 지식 범위 내에서) 오픈소스가 아닙니다). 그래서 그렇습니다. 결국 Meta 사용을 중단해야 합니다 물론 농담입니다. 제 지점은 모든 것이 오픈소스나 리브레일 필요 없이도 충분한 신뢰가 있을 수 있다는 것입니다.
제 이해가 맞다면, 이 모든 것은 주로 자바스크립트와 관련이 있습니다. 그리고 각 Discourse 인스턴스가 제공하는 브라우저 안에서 자바스크립트로 실행되는 것에 관한 것입니다. 또한 대부분 "신뢰"와 실행되는 코드를 파악할 수 있는 능력(코드를 살펴볼 수 있는 것)에 관한 것이죠. 맞습니까?
이것은 제 능력 범위를 훨씬 넘어선 문제이지만, 이것에 대해 "통제"할 수 있습니까? 모든 사용자에게 영향을 미치는 변경 사항을 포함하는 커밋을 제출하는 경우가 아니라면, 여기서 스스로 "수정"할 수 있다고 생각하지 않습니다. 왜냐하면 컴퓨터에서 실행되는 것으로 언급하는 "소프트웨어"는 매번 서버에서 브라우저로 제공되기 때문입니다.
각 포럼이 가능한 모든 수정 사항을 포함하여 자체 오픈소스 코드를 게시한다고 해도, 그들이 실제로 항상 그 코드를 실행하고 있는지 확신할 수 있습니까? 한 번 다운로드해서 확인하고 내 쪽에서 컴파일하는 식으로 처리할 수 있는 것이 아니기 때문입니다.
실제로 원하시는 것은 다음 중 하나일 것입니다:
자바스크립트 없음 (Discourse는 자바스크립트에 크게 의존하므로 이 부분은 불가능합니다) 또는
컴퓨터에 실제로 설치된 독립적인 오픈소스 클라이언트. 후자의 경우, 이것이 Discourse에서 가능한 것이라면 자바스크립트를 사용하지 않아야 합니다. (이 부분은 제가 잘 모르겠습니다.) 그렇게 해야 클라이언트를 수정하고 원하는 통제를 가질 수 있습니다.
이것이 공정한 이해일까요?
(P.S. 제 능력 범위도 넘어가는 문제이지만, 기억이 정확하다면 Discourse 코드의 100%가 오픈소스는 아닙니다. 지금 중요한 것은 서버 측의 모든 것이 아니라, 내 쪽에서 실행되는 것뿐입니다.)
이전에 작성한 글에서 이 배포판이 자유 소프트웨어일 것이라고 생각했던 또 다른 이유는 Discourse의 소개 페이지에 "Discourse의 버전은 단 하나뿐입니다 – 멋진 오픈 소스 버전."라고 되어 있기 때문입니다. 플러그인이 Discourse의 일부가 아니므로 기술적으로는 사실이지만, 제게는 오해의 소리가 있는 것처럼 느껴졌습니다.
Discourse는 제3자 배포판에 대한 통제가 없을 수 있지만, 소개 페이지에서 말하는 것을 고려할 때 Discourse가 호스팅하는 Discourse 인스턴스가 자유 소프트웨어일 것이라고 기대했을 것입니다. 또한 파생 작품이 자유 소프트웨어여야 하는 것을 효과적으로 요구하는 라이선스와/또는 프레임워크가 있을 것이라고도 기대했을 수 있습니다. Discourse가 GPL이므로 그런 것이 일종의 존재는 하지만, 플러그인은 포함되지 않는 것 같습니다.
소프트웨어나 서비스에 돈을 받는 것은 괜찮다고 생각합니다. 보통 "자유 소프트웨어"의 "자유"는 "libre"를 의미하며, 소프트웨어를 얻은 후 원하는 대로(복사, 수정 등) 할 수 있음을 의미합니다. 반드시 “gratis”(무료) 즉, 비용이 0원이라는 뜻은 아닙니다.
엄밀히 말하면, 나를 막을 사람은 없지만 그것은 불법이며, 이는 나쁘다고 생각합니다. 개인 사용이라면 가능할 수 있지만, 일반적으로 공개 소프트웨어 저장소와 앱 스토어는 불법적으로 복제된 코드를 포함하기를 원하지 않으며, 제가 소프트웨어를 사용하게 하고 싶은 일부 사람들은 불법적으로 복제된 코드를 실행하는 것에 불편함을 느낄 수 있습니다. 제가 올바른 접근 방식을 가지고 있는지 확신이 없습니다. 저작권을 완전히 무시해야 할 수도 있지만, 불법적이고 비자유 소프트웨어를 피할 수 있는 상황에서 그것은 최선의 선택이 아닌 것 같습니다.
이 말은 무슨 뜻인가요? 소프트웨어가 자유라는 것은 제가 그것을 수정할 수 있다는 것을 의미하므로, 저는 그것이 무엇을 하는지에 대한 통제가 있다고 생각합니다.
자유는 신뢰와 같지 않다고 생각합니다. “신뢰할 수 없는” 대신 "임의의"라고 말해야 했을 수도 있지만, 제 논점은 대부분의 브라우저가 웹 페이지가 주는 코드를 실행한다는 것입니다. 그리고 저는 이전에 방문해 본 적 없는 웹사이트를 자주 방문하므로, 제가 방문하는 많은 웹사이트가 “신뢰할 수 없는” 것입니다. 이러한 웹사이트들에 대해, 제가 비자유 소프트웨어를 보내지 않을 것이라고 믿을 이유는 없습니다.
NPM에 대해서는, 임의의 웹사이트보다 더 신뢰할 수 있다고 생각하지만, 제 apt 또는 guix 저장소만큼은 아닐 수 있습니다. 물론, 신뢰는 1차원이 아닙니다. NPM에 있다는 이유만으로 새로운 패키지를 신뢰하지는 않지만, NPM에서 JQuery를 다운로드할 때 그것이 실제로 JQuery일 것이라고는 신뢰합니다. NPM은 공격자가 JQuery를 교체할 수 있는 실수를 할 수 있지만, NPM은 사이트에서 서빙되는 JavaScript(예: 게시 전 자동/수동 검토, 게시 후 크라우드소싱 검토, 미니어화/오브스커라이즈된 스크립트가 소스 코드와 일치하는지 자동 확인, 런타임에 임의의 코드를 다운로드하고 실행하는 것에 대한 규칙)에서는 현실적으로 불가능할 수 있는 조치를 취하여 멀웨어를 피할 수 있습니다. 중요하게는, NPM에서 멀웨어가 발견되면 그것을 보고하여 제거할 수 있는 제3자(NPM, 소프트웨어 개발자가 아닌)가 있습니다. 사이트에서 서빙되는 JavaScript에는 그런 경우가 없습니다 - 그것을 제거할 수 있는 유일한 주체는 사이트 운영자입니다.
그렇다면 서버 관리자가 수정을 하고 나열된 커밋 해시를 변경하지 않았다면, 나열된 커밋 해시가 불일치한다는 뜻인가요? 소프트웨어를 업데이트하면 커밋 해시가 자동으로 변경된다고 생각했고, 나열된 커밋 해시가 자동으로 업데이트될 것이라고 (잘못) 가정했습니다.
그러면 Discourse를 사용하면서 비자유 소프트웨어를 피하는 유일한 방법은 Discourse 클라이언트를 브라우저 확장 프로그램이나 Haketilo 패키지로 패키징하는 것인가요?
제 원래 질문이 소프트웨어 자유에 관한 것이지 신뢰에 관한 것이 아닌 것을 고려할 때, 그것이 무슨 뜻인지 확신이 없습니다.
제가 나열한 모든 사람을 신뢰해야 한다고 동의하지 않습니다.
서버 관리자를 신뢰할 필요가 없는 경우가 있습니다. 예를 들어, Discourse 클라이언트를 GitHub에서 가져와서 해당 서버와 함께 사용할 수 있도록 패키징하는 경우, 그들이 서빙하는 소프트웨어를 실행하지 않기 때문입니다.
많은 경우, 소프트웨어를 공동으로 개발하는 사람들은 서로의 커밋 중 일부를 읽을 수 있으므로, 모든 저자를 개별적으로 신뢰할 필요가 없습니다.
그러면 Discourse Meta 클라이언트가 독점 소프트웨어라는 뜻인가요? 다만, safe mode를 사용하여 플러그인 JS를 비활성화할 수는 있습니다.
그럴 수도 있지만, 비자유 소프트웨어를 피하고 싶다면 그것은 매우 도움이 되지 않습니다.
@NateDhaliwal
Discourse git 저장소의 라이선스를 읽었지만, (CLA 때문에) 그 저장소 외부의 Discourse 파생 작품에는 반드시 적용되지 않습니다. 배포된 소프트웨어 중 어느 것이 libre인지 명시하는 고지를 모든 Discourse 배포판에서 보고 싶습니다. 그것은 심지어 (제 생각에) GPL의 정신에도 부합합니다: “그들이 그들의 권리를 알도록 이 조항들을 보여줘야 합니다.”
네, 가능합니다. Haketilo나 GreaseMonkey와 같은 브라우저 확장 프로그램이나 프록시를 통해 JavaScript를 실행할 수 있지만, 소프트웨어가 매우 자주 업데이트되는 경우(데이터가 JavaScript 소프트웨어에 내장된 소프트웨어의 경우와 같이)에는 매우 비실용적일 수 있습니다. Haketilo도 “module” 타입과 같은 일부 종류의 스크립트를 지원하지 않습니다.
네, 전반적으로 당신의 이해가 정확하다고 생각합니다. 다만 JavaScript를 브라우저 확장 프로그램이나 Haketilo 또는 GreaseMonkey를 위해 패키징하면, JavaScript를 사용하더라도 독립적으로 설치된 클라이언트가 되는 효과를 가질 것입니다.
CDCK나 우리(저는 디스코스를 호스팅하는 회사의 공동 창업자입니다)가 호스팅하는 모든 디스코스 인스턴스는 호스팅 환경에 특화된 일부 기능을 제공하기 위해 하나 이상의 비공개 소스 플러그인을 실행하고 있습니다.
저는 전통적인 의미의 배포판(여기에는 GitHub 저장소가 있고 원하는 대로 하세요)과 더 현대적인 의미의 배포판(여기에는 웹사이트가 있고 브라우저에 JavaScript를 푸시합니다) 사이에 많은 혼란이 있다고 생각합니다. 또한, 디스코스 https://github.com/discourse/discourse와 사이트 관리자가 추가한 1차 및 3차 플러그인과 테마 컴포넌트가 모두 포함된 디스코스 사이의 혼란도 있습니다.
이것은 커밋 해시이므로, 저장소에서 가져온 후 커밋하기 전에 수정이 이루어진다면 이미 그런 상황이 됩니다. 이는 악의적인 행위일 필요가 없으며, 보안 패치가 적용될 때도(일반적으로 공개 브랜치에 커밋하기 전에 수행됨) 발생하게 됩니다. 일반적으로 보안 패치는 클라이언트 사이드가 아니지만, 일부 업데이트된 클라이언트 사이드 코드를 도입할 수 있습니다.
네 - 적어도 이론적으로는 그렇습니다. 이를 우회하는 것이 얼마나 어려운지(고의로든 실수로든)는 확실하지 않습니다.
동의합니다. "Discourse"라는 단어가 실제로 무엇을 가리키는지 혼란스러워하는 것 같습니다.
아, 알겠습니다. 그러면 정말로 이를 구별할 좋은 방법이 없을 것 같네요.
좋은 지적입니다. 누군가가 이러한 결함을 숨기려고 시도할 수 있습니다. 하지만 모든 업스트림 코드 수정자를 개별적으로 신뢰하는 것보다는 3자 코드를 감사하는 것이 이 문제를 완화하는 것이 더 쉬워 보이지만, 아마도 두 접근법 모두 완전히 실행하기는 현실적이지 않을 것입니다.
서버 관리자는 커밋 해시를 변경하지 않고도 수정을 가할 수 있습니다. 그리고 플러그인도 자바스크립트 코드를 주입할 수 있습니다.
물론 농담입니다. 제 지점은 모든 것이 오픈소스나 리브레일 필요 없이도 충분한 신뢰가 있을 수 있다는 것입니다.
)