오픈 소스 VPN 클라이언트: 코드가 증명하는 것과 증명하지 못하는 것
공개 저장소는 소스 코드에 대한 증거이며, 설치한 빌드나 그 뒤의 서버에 대한 증거가 아닙니다. 릴리스를 맞춰 보고, 그다음 검토 범위를 넓히십시오.
소스가 공개되었고 라이선스도 깨끗하지만, 연결은 여전히 처음부터 끝까지 검증할 수 없습니다. 그 간극은 흔한 일이며 스캔들이 아닙니다. 코드를 공개하면 초대받지 않은 사람들이 한 구성 요소를 검사할 수 있게 되는데, 이것은 실재적이고 드문 속성입니다. 그렇다고 해서 설치한 바이너리가 그 코드에서 나왔다고 볼 수는 없습니다, 제공자가 반대편에서 운영하는 무엇이든 검토되었다고 볼 수도 없습니다.
구성 요소와 제품을 분리하십시오
오픈 소스라는 표시를 붙일 수 있는 것은 네 가지이며, 넷 모두 열려 있는 경우는 드뭅니다. 사람들이 말하는 것은 클라이언트 애플리케이션입니다. 그 아래의 프로토콜 구현은 다른 산출물이며, 때로는 라이브러리이고 때로는 트리 안의 코드입니다. 서버 소프트웨어가 세 번째이고, 제공자 자신의 기반 시설, 계정 포털, 지원 도구가 네 번째입니다. 각각은 독립적으로 열리거나 닫힐 수 있습니다.
따라서 "우리 앱은 오픈 소스입니다" 같은 말은 첫 항목을 서술하고 나머지는 답하지 않은 채 둡니다. 이는 거짓말이라기보다 범주의 미끄러짐이며, 유용한 질문은 어느 저장소의 어느 태그가 당신이 의존하는 구성 요소에 해당하는가입니다.
이 구분은 동일한 열린 클라이언트를 가진 두 제품이 왜 매우 다른 보증을 내놓을 수 있는지도 설명합니다. 클라이언트는 당신이 확인할 수 있는 부분이고, 운영자의 행동은 다른 수단으로 평가해야 하는 부분입니다.
설치된 빌드를 공개된 태그와 맞추십시오
저장소는 의도의 기록이고, 디스크의 바이너리는 실제로 실행되는 것입니다. 그 간극을 닫는 일은 기계적인 작업이며, 다운로드 페이지가 광고한 것이 아니라 정확히 무엇이 설치되었는지를 확인하는 데서 시작합니다.
| Component | What inspection can show | What it leaves untouched |
|---|---|---|
| Client source | How profiles, packets and optional telemetry are handled | Whether the shipped binary matches that source |
| Build output | Whether a declared build reproduces a matching artefact | Whether the source is correct or the toolchain is clean |
| Server software | What the implementation is capable of logging | What the operator actually configures and retains |
| Account and support systems | Almost nothing, unless they are separately published | Everything about how those systems treat your data |
패키지 메타데이터는 버전과 출처를 알려 주므로 오래되었거나 바뀐 패키지라는 단순한 경우를 배제합니다. 그러나 그 패키지가 어떻게 컴파일되었는지는 알려 주지 않으며, 바로 그 질문에 답하기 위해 재현 가능한 빌드가 존재합니다. 재현 가능한 빌드 는 독립된 당사자가 같은 소스에서 다시 빌드하고 출력을 바이트 단위로 비교할 수 있게 하여, 불일치가 의심이 아니라 증거가 되게 합니다.
완벽한 일치조차 사람들이 기대하는 만큼 증명하지 못합니다. 그것은 산출물이 소스와 빌드 조리법에 해당함을 보여 줄 뿐, 소스에 결함이 없다거나 사용한 도구 체인이 신뢰할 만했다는 것을 보여 주지 않습니다. 둘 다 알아 둘 가치가 있지만 서로 다른 주장입니다.
dpkg -S /usr/bin/wg
apt-cache policy wireguard-tools
sha256sum /usr/bin/wg증상은 보통 어디에서 시작되는가
이 글을 읽게 만드는 불만은 드물게 "코드가 닫혀 있다"입니다. 보통은 구체적인 관찰입니다. 예상치 못한 곳으로 통신하는 클라이언트, 릴리스 노트와 다른 버전, 또는 터널에 필요 이상을 요구하는 지원 절차이며, 이 각각은 다른 구성 요소를 가리킵니다.
클라이언트의 예상치 못한 네트워크 트래픽은 클라이언트 소스 코드의 문제이며, 연결을 여는 코드 경로를 읽으면 답할 수 있습니다. 버전 불일치는 패키징의 문제입니다. 신분 증명서를 요구하는 지원 절차는 계정 시스템의 문제이며, 어떤 클라이언트 감사도 그것을 해결하지 못합니다.
구성 요소를 명명하면 막연한 불신이 구체적인 확인으로 바뀝니다. 구체적인 확인에는 답할 수 있고, 논쟁할 수 있고, 끝낼 수 있습니다. 대안은 다음 단계가 없는 영구적인 의심입니다.
검토가 닿지 못하는 것, 그리고 대신 해야 할 일
제공자 서버의 보존은 클라이언트의 손이 닿지 않습니다. 결제 포털, 사기 검사 업체, 첨부 파일을 보관하는 지원 데스크의 행동도 마찬가지입니다. 클라이언트 검토를 "우리는 서비스를 감사했다"까지 늘리면 증거가 뒷받침하지 않는 주장이 됩니다.
운영자가 보존과 요청에 관해 공개하는 내용을 읽고 날짜를 적어 두며, 그것을 측정이 아니라 이해관계자의 진술로 다루십시오. 그것은 더 약한 형태의 증거이며, 차이를 분명히 말하는 편이 다시 이야기할 때 격상시키는 것보다 유용합니다.
그다음 가진 것을 여러 입력 가운데 하나로 사용하십시오: 설치된 릴리스의 정체성, 소프트웨어가 유지 관리되는지, 클라이언트가 어떻게 구성되었는지, 운영자가 자기 시스템에 관해 무엇이라고 말하는지. 열린 코드는 그 평가를 한 지점에서 강화합니다. 나머지를 대체하지는 않습니다.
감사 주장은 항상 그 구성 요소와 버전을 밝혀야 합니다. 어떤 저장소와 어떤 빌드를 조사했는지 말할 수 없는 보고서는 제품이 아니라 의도를 서술하는 것입니다.