버전 이름도 같고 압축을 푼 뒤의 파일도 같은데 체크섬만 다르다면, 어느 쪽을 공식 배포본으로 믿어야 할까. 내용 비교만으로는 답이 나오지 않는다. 배포 파일은 안에 든 문서뿐 아니라 그것을 포장한 바이트까지 검증 대상이기 때문이다.
최근 변경 기록에는 Windows용 기술 다이어그램 뷰어의 공식 ZIP 배포 패키지를 재현 가능하게 만드는 수정이 한 건 포함됐다. 여기서 재현 가능하다는 말은 같은 소스와 같은 빌드 조건으로 다시 만들었을 때 결과 파일의 바이트가 일치한다는 뜻이다.
압축 파일에는 본문 외의 값도 붙는다. 파일 순서, 수정 시각, 경로 표기, 권한, 압축 방식이 달라지면 압축을 풀어 본 내용은 같아도 ZIP의 해시는 바뀔 수 있다. 운영체제가 달라질 때 패키징 절차를 따로 확인해야 하는 이유다.
바이트가 안정되면 체크섬을 배포본의 신분증으로 쓸 수 있다. 캐시는 이미 받은 파일과 새 파일을 구분하고, 서명 검사는 배포 이후의 변경을 찾으며, 버전 비교는 소스 변경과 빌드 환경의 흔들림을 떼어 볼 수 있다. 반대로 빌드할 때마다 해시가 바뀌면 이 세 검사는 불필요한 의심부터 처리해야 한다.
이번 기록만으로 구체적인 결함 원인까지 알 수는 없다. 수정 시각을 고정했는지, 정렬 순서를 바꿨는지, 압축 도구 설정을 손봤는지는 구현 차이를 확인하기 전에는 미정이다. 확인된 범위는 Windows에서 공식 ZIP의 재현성을 고치는 변경이 들어왔다는 사실이다.
압축 해제 후의 동일성은 내용 검사에 답한다. 재현 가능한 ZIP은 누가 다시 만들어도 같은 배포본이라고 확인할 수 있게 한다. 둘 사이의 거리는 파일 몇 개가 아니라 검증 가능한 제작 과정 하나다.