Git 3.0이 SHA-256을 기본으로 — GitHub 공동창업자 "비용이 큰 실수"

Git 3.0에서 새 저장소의 객체 해시가 SHA-1에서 SHA-256으로 바뀔 예정입니다. 지금도 git init --object-format=sha256으로 써볼 수 있습니다. 이 결정에 대해 Scott Chacon — Pro Git 저자, GitHub 공동창업자, 현재 GitButler 개발 — 이 10월 2일 반대 글을 썼습니다.

그의 주장

위협은 이론적이다. SHA-1은 수학적으로 "깨졌다" — 충돌 공격이 이론상 가능합니다. 그러나 실용적 공격은 아니고, "합리적인 코드베이스에서 우연한 내용 충돌은 수학적으로 거의 불가능"합니다. 실제 코드 침해는 npm 메인테이너 계정 탈취 같은 소셜 엔지니어링으로 일어나지 해시 충돌로 일어나지 않습니다. 그는 2005년 Linus Torvalds의 말을 인용합니다 — "진짜 보안은 배포에 있다." 신뢰는 저장소의 출처에서 오지 해시 알고리즘에서 오지 않는다는 것입니다.

비용은 현실적이다.

• 저장소 형식 분열 — SHA-1 저장소와 SHA-256 저장소는 호환되지 않음
• 라이브러리·도구가 새 형식을 아직 다 지원하지 않음
• 변환하면 기존 서명이 깨짐
• 커밋 메시지, 이슈, 문서, 링크에 적힌 해시 참조가 전부 무효
• 40자 해시를 가정한 도구들의 연쇄 고장

대안 제안

SHA-1을 그대로 두고, 서명하는 객체에 SHA-256 체크섬 헤더를 추가하자는 것입니다. 하위 호환을 깨지 않으면서 강한 보장이 필요한 프로젝트는 그 체크섬을 검증하면 됩니다. 그는 개념증명으로 Chromium 35GB 트리를 5초에 처리했다고 밝혔습니다.

사실과 의견

사실: Git 3.0의 SHA-256 기본 전환 계획, 두 형식의 비호환, SHA-1 충돌의 이론적 가능성. 의견: 비용이 이득보다 크다는 판단, 그리고 대안의 충분성. Git 메인테이너 쪽의 반론은 이 글에 없습니다. SHA-1 전환은 Git 커뮤니티에서 여러 해 논의된 것이라 찬성 쪽 논거도 분명히 있습니다(해시 충돌 방어 sha1dc에 영구히 의존하는 문제, 암호학적 위생 등).

실무에서 할 일

Git 3.0 시점은 아직 정해지지 않았습니다. 지금 할 수 있는 건 하나 — 자기 팀의 도구 중 커밋 해시가 40자라고 가정한 것이 있는지 보는 것입니다. CI 스크립트, 배포 태깅, 해시를 파싱하는 봇. SHA-256은 64자입니다. git init --object-format=sha256으로 테스트 저장소를 만들어 파이프라인을 한 번 태워보면 어디가 깨지는지 바로 나옵니다. 전환이 오든 안 오든 그 가정은 없애두는 게 낫습니다.