SHA-256 이전의 고정된 Git 객체 ID 가정들을 찾아내는 방법

Git 통합(integration)이 모든 객체 ID가 40자 길이일 것이라고 가정하면서도 건강해 보일 수 있다는 점을 깨닫고 git-sha-ready를 만들었습니다. 이 가정은 SHA-1 저장소에서는 작동합니다. 하지만 SHA-256 저장소는 64개의 16진수 문자를 사용하므로, 검증기(validator)가 실제 커밋을 거부할 수 있고 고정된 슬라이스(fixed slice)는 ID의 일부를 무시할 수 있습니다.

A scan showing two Git object ID findings and a clean result after a repair

제가 만든 작은 테스트 코드는 정확히 40개의 16진수 자릿수를 허용하는 검증기와 slice(0, 40) 호출로 시작합니다. 스캔은 각각의 파일과 줄을 보고합니다. 제가 검증기가 40개 또는 64개의 자릿수를 허용하도록 하고 고정된 슬라이스를 제거하자, 동일한 스캔에서는 아무런 발견 사항도 없습니다. 위의 GIF는 해당 테스트 환경에서 실제 CLI를 기록한 것입니다.

기본 명령어는 Git이 추적하는 텍스트 파일을 읽습니다. 대상 프로젝트를 실행하지는 않습니다. 저는 다섯 가지 유형의 패턴을 찾습니다: 40개 길이의 정규 표현식, 40과의 길이 비교, 고정된 40자 슬라이스, 직접적인 .git/objects 접근, 그리고 20바이트 객체 ID 저장. 각 발견 사항에는 신뢰도 레이블과 간단한 수정 힌트가 있습니다. Git과 관련 없는 체크섬은 확정된 결함으로 처리하기보다는 검토 대상으로 표시됩니다.

또한 명시적인 --probe 모드를 추가했습니다. 이 모드는 추적되는 소스 및 설정 파일을 SHA-256으로 초기화된 임시 저장소에 복사하고, 로컬 커밋을 수행한 다음, 사용자가 제공하는 셸 명령어를 실행합니다. Node 프로젝트의 경우, 필요한 패키지를 설치했는지 확인한 후 git-sha-ready --probe 'npm test'를 사용할 수 있습니다. 이 임시 저장소는 명령이 완료되면 제거됩니다. 저는 이것을 전체 배포 경로 테스트를 대체하는 것이 아니라 로컬 호환성 검사로 간주합니다.

제가 명확히 하고 싶은 한계점들이 있습니다. 이것은 텍스트 패턴 스캐너입니다. 여러 줄에 걸친 코드, 별칭(aliases), 생성된 코드, 그리고 흔하지 않은 철자를 놓칠 수 있습니다. 녹색 스캔 점수는 검사한 파일에서 지원되는 패턴이 없었음을 의미합니다. 이는 SHA-256 호환성을 인증하는 것은 아닙니다. 선택적 프로브는 사용자가 지정한 셸 명령을 실행하므로, 저는 신뢰하는 명령어와만 사용합니다.

이 프로젝트에는 테스트용 더미 데이터(fixture), 테스트 케이스, CI 워크플로우, 그리고 README에 설치 명령어가 포함되어 있습니다. 저는 Git 클라이언트, 빌드 도구, 그리고 릴리스 스크립트의 유지 관리자들로부터 보고서를 받고 싶습니다. 예상되는 동작과 실제 발견 사항을 담은 짧은 예시가 노이즈를 추가하지 않으면서 규칙 개선에 도움이 될 것입니다.