개발 폴더에서는 잘 되는데 전달한 설치 파일에서는 빠지는 기능이 생길 수 있다. 파일이 없거나 개발용 환경이 우연히 도와줬을 수도 있다. 그래서 북극성의 배포 검수는 소스 시험을 통과했다는 문장에서 끝내지 않고 어떤 설치물에서 나온 실행 파일을 확인했는지까지 따라갔다.
설치 파일의 이름만으로 내용이 같다고 하지 않는다
0.1.110 배포 기록은 설치 파일의 크기와 SHA-256, 실제 NSIS에서 꺼낸 payload72개 비교를 남겼다. 실행 파일이 놓인 build 폴더를 검사한 것과 실제 전달물에서 추출한 바이트를 검사한 것은 구분한다. 같은 버전 이름으로 다른 바이트가 섞이면 이 연결이 끊긴다.
이 해시는 파일의 동일성 근거다. 코드 서명이나 제품 안전성 인증은 아니다. 해당 기록에도 codeSigned와 실제 다른 PC 시험은 False로 남아 있다. 당시 기존 설치판을 바꾸지 않았다는 조건도 있다. 배포 후보를 검사한 결과를 사용자의 설치가 이미 업데이트됐다고 바꾸어 보고하지 않았다.
개발 환경이 도와주는 것을 일부러 줄인다
packaged 시험은 별도 userData와 빈 APPDATA·LOCALAPPDATA를 사용하고 개발 CLI와 Python이 PATH에서 보이지 않게 구성한다. app.isPackaged와 새 자료 폴더, 개인 대화나 설정이 들어오지 않았는지를 본다. 개발 PC의 우연한 경로가 없으면 브라우저 자체가 시작되는지를 묻는 것이다.
이 조건에서 시작했다는 사실이 모든 Python 기능도 외부 설치 없이 된다는 뜻은 아니다. 브라우저 시작과 작업 실행의 의존성이 다르다. 시험에서 지운 환경 변수와 새로 만든 폴더를 명시하면 독자는 무엇을 제거한 조건인지 판단할 수 있다. 깨끗한 조건이라는 추상적인 이름보다 실제 설정이 중요했다.
개발용 능력이 운영 파일에 들어갔는지도 본다
현재 보관된 packaged 시험은 asar 목록에서 개발 전용 폴더를 찾고 main 코드에 인증서 무시나 시험 harness, 고정 디버그 포트가 들어가는지도 검사한다. 테스트가 제어할 수 있게 만든 통로와 배포물의 능력을 혼동하지 않기 위해서다. 시험 실행의 디버그 전송과 설치 파일에 상시 포함된 포트도 다르다.
정규식과 파일 목록 검사는 유용하지만 모든 취약점 분석을 끝낸 것은 아니다. 기록의8개 통과 항목은 그8개 질문에 답한다. 나는 실행 결과 옆에 검사 코드의 질문을 함께 읽었다. 자동 검사 수를 늘리는 것보다 배포물에 대해 실제로 무엇을 물었는지 확인하는 편이 과장을 줄였다.
실제 MCP와 Python 경로는 설치판에서 다시 잇는다
후속 프로젝트 격리 기록에는 소스판과 설치판의 실제 Electron·MCP·Python·UI 각각15개 확인이 따로 있다. 설치판에서도 같은 예약이 대상 탭과 커널을 사용했는지, 기존 공개 탭의 읽기 플러그인이 새 탭 없이 성공했는지를 남긴다. 소스 성공을 그대로 복사한 체크가 아니다.
이 결과에도 소유 fixture와 실제 공개 읽기의 범위가 다르다. 실제 게시나 신규 업로드까지 한 번에 검증했다고 쓰지 않는다. 현재 외부 MCP 문서는 내장 모델 제거 이후의 계약이므로 과거 배포 기록의 내장 기능과 현재 설치판의 능력을 동일시하지 않는다. 버전 사이의 구조 변경도 검증 연결의 일부다.
공유 예제도 압축 전과 추출 뒤를 따로 확인한다
이번 홈페이지의 공유 모듈도 코드 폴더의 시험을 통과한 뒤 ZIP을 만들고 새 폴더에 추출해 같은 시험을 실행한다. 공개 다운로드의 실제 바이트와 해시도 대조한다. 원래 설치판 시험을 모듈의 성공 근거로 빌리지 않고 각 배포물이 자기 근거를 갖게 한다.
이 글을 쓰면서 원래 프로그램을 설치하거나 고객 환경을 바꾸지는 않았다. 과거 배포 영수증과 시험을 대조한 기록이다. 다른 PC 호환성과 서명, 공급망 검토가 남아 있으면 그대로 남긴다. 제작자가 전달하는 것은 실행 파일뿐 아니라 이 파일이 어느 조건에서 확인됐는지 다시 추적할 수 있는 연결이어야 한다.