Git 3.0의 SHA-256 기본 전환은 값비싼 실수라는 주장

모든 저장소는 SHA1이거나 SHA256인데, 전체를 재해싱하면 해결됨. 각자 독립적으로 할 수 있고, 대부분 git 3.0을 필수 버전으로 두고 새 저장소를 받아갈 것 같음. 커밋 서명은 역참조해야 하는데 git 3에 하위 호환 참조가 있겠지?

잠깐, 전체 재해싱이라니 히스토리를 전부 재작성한다는 거임? 나는 해시로 커밋을 참조하는 걸 다루는데, Yocto 프로젝트마다 그런 참조가 수천 개는 있음.

'새 포맷으로 전부 다시 쓰고, 새 포맷에서 데이터가 손실되니까 옛 포맷도 영원히 유지한다'는 마이그레이션임.

이메일이나 Slack, 버그 트래커에 커밋 해시 참조해둔 거 있지? CI/CD 캐시 판단이나 보안 스캔에 쓰이는 곳은 더 심함. 재해싱하면 그 외부 참조가 전부 깨지는데, 옛 해시에서 새 해시로 조회하는 지원이 없음.

작은 git/jj 포지를 운영하는데 이미 이 문제로 고통스러움. GitHub는 어떻게 감당할지 상상이 안 감.

SHA256 in git은 IPv6가 될 조짐임. 하위 호환 안 되는 방식으로 구현됐고, 이점은 모호하고, 따라와야 할 도구는 많은데 움직임이 안 보임.

이점이 모호하다는 건 IPv6에는 전혀 해당 안 되는 말임.

IPv6와 다른 건 네트워크 효과임. 일부 호스트가 IPv4만 있으면 완전한 연결을 위해 IPv4가 필요하고, 다들 IPv4를 갖고 있으면 당장 옮길 이유가 없음. Git은 저장소별로 독립적으로 업데이트되니까 그 효과가 없고, Python 2에서 3 마이그레이션에 가깝다고 봄.

Y2K FUD 같음. SHA-256을 기본으로 안 하면 아무도 안 바꾸고, SHA-1이 10년 뒤 깨지면 그날 다 같이 바꿔야 하는데 GitHub는 SHA-256을 구현 안 해뒀을 거임. git 3.0 쓰고 안 되면 config로 SHA-1로 되돌리면 됨. 환경변수 하나 추가하는 일임.

그렇게 할 수 있는 건 맞는데 기본값이 문제임. 사람들이 그냥 실행하면 도구, 라이브러리, 서버와 호환 안 되는 저장소를 갖게 됨. 옵션인 것과 기본값인 건 완전히 다름.

분산 버전 관리에서 '너'가 누구냐는 게 문제임. 지금 프로젝트와 상호작용하는 사람뿐 아니라 앞으로 상호작용하길 바라는 모든 사람임. 개인 머신에서 brew update 한 번 하는 비용이 아니라, 거의 무한한 인구를 이 마이그레이션에 커밋하는 비용을 따져야 함.

한 사람이 고치기는 쉽지만 git 생태계 전체는 어려움. GitHub, 대형 사내 저장소, CI/CD, 서브모듈 쓰는 프로젝트가 다 엮여 있음.

Y2K는 FUD가 아니었음. 실제였고 날짜 문제는 앞으로도 예약돼 있음.

SHA-1이 10년 뒤 깨져서 하루아침에 다 바꿔야 한다는 시나리오는, 글쓴이가 말하는 대로 실제로는 안 일어남. 해시가 '깨진' 게 실무에서 문제가 되지 않고, 진짜 공급망 보안은 파일 해시와 무관함.

이미 깨진 건 맞지만 git 충돌을 만드는 건 저장소 메타데이터 때문에 훨씬 어려움. PDF 같은 건 같은 해시로 쉽게 만들 수 있어도 git에서 유용하게 쓰기는 어려움. 그래도 더 강한 해시로 옮기는 건 좋은 생각임. 마이그레이션이 어렵다고 안 할 일은 아님.

SHA-1과 SHA-256 모드를 훨씬 호환되게 만들면 안 되나. SHA-256 객체가 SHA-1 객체를 참조할 수 있게 하되, 그 객체가 충돌 쌍이면 진짜 문제임. 리눅스가 옮긴다면 두 날짜를 정해서 그 사이에 제출할 객체 해시 목록을 확정하고, 이후엔 목록에 없는 SHA-1 객체를 안 받으면 새 충돌을 못 넣음.

Emily의 발표가 해시 혼용 문제를 잘 정리해놨음. youtu.be/eJJp0RE7cd4

날짜가 커밋 안에 들어 있음. 커밋 날짜가 진짜인지 아는 유일한 방법이 해시임. SHA-1 해시를 마음대로 위조할 수 있으면 torvalds/linux와 같은 SHA-1을 가진 저장소를 만들 수 있고, 깊은 히스토리 비교 없이는 못 알아챔. SHA-1 커밋이 하나라도 있는 저장소는 전부 SHA-1인 저장소만큼 약하다고 봄.