Hacker News인프라 · 데브옵스

Git 3.0의 SHA-256 전환, 생태계 대혼란만 남길 것

원제 Git 3.0's upcoming SHA-256 default will be a costly mistake

156 포인트댓글 176
Key Point

전 산업의 개발자와 기업이 준비하지 못한 Git 3.0의 SHA-256 기본값 전환이 실제로는 불필요한 문제를 만들 수 있으며, 생태계 단편화와 도구 호환성 문제를 야기할 것이기 때문이다.

핵심 요약

  • Git 3.0은 기본 해시 알고리즘을 SHA-1에서 SHA-256으로 변경할 예정이며, 이는 전 산업에 막대한 비용과 혼란을 초래할 것이라고 GitButler 공동창립자 Scott Chacon이 주장한다.
  • SHA-1은 수학적으로 '준-깨졌다'고 여겨지지만, 실제로는 충돌이 발생하지 않았으며 200년 동안 우발적 충돌은 사실상 불가능하다.
  • SHA-1 충돌 공격은 이론적으로는 가능하지만, 실제 공격자들은 GPU 집약적인 해시 충돌 생성보다 소셜 엔지니어링으로 유지보수자 접근권을 얻거나 npm 패키지를 장악하는 방식을 훨씬 선호한다.
  • Git의 진정한 보안은 '어디에서 코드를 가져오는가'에 있으며, 해시 알고리즘이 아닌 배포 신뢰에 기반한다는 것이 Linus Torvalds의 원래 주장이다.
  • SHA-256 전환 후 git init으로 생성된 신규 저장소는 GitHub 등 플랫폼에 푸시할 수 없으며, 개발자는 생성 시 올바른 버전을 선택해야 하는 어려움에 직면한다.
  • 라이브러리 서브모듈은 같은 해시 타입 프로젝트에서만 사용 가능하므로 SHA-1과 SHA-256 두 버전을 유지해야 하며, 기존 프로젝트 전환 시 모든 서명이 무효화된다.
  • 해시 값이 40자에서 64자로 늘어나면서 내부 도구·스크립트·링크·이메일의 SHA-1 해시 참조가 모두 깨지고 리다이렉트 또는 업데이트가 필요하다.
  • Python 같은 대다수 Git 라이브러리는 SHA-256 완전 지원이 없어서, Git 바이너리를 fork-exec하지 않는 모든 스크립트와 도구에 광범위한 호환성 문제가 생긴다.
  • 대안으로 Chacon은 SHA-1으로 콘텐츠를 검색하되, 서명 시 독립적으로 SHA-256 해시를 생성해 객체 헤더에 삽입하는 방식을 제안한다.
  • 이 접근법은 2015년부터 존재하는 git-evtag 같은 도구로 이미 구현됐으며, 해시 알고리즘이 손상될 때마다 전체 생태계 마이그레이션 없이 새로운 검증 방식을 추가할 수 있다.
  • Chromium(35GB, 210만 개 파일) 같은 최악의 경우도 5초, Linux 커널은 257ms, Git 프로젝트는 17ms에 독립 체크섬 생성이 가능하므로 성능 문제는 없다.
  • NIST의 2030년 SHA-1 규제는 '암호화 보호 적용'을 금지하는 것이지 SHA-1 존재 자체를 금지하는 것이 아니므로, 모든 서명이 SHA-256을 커버하면 규정 충족이 가능하다.
AI 요약 안내

AI가 한국어로 정리한 내용입니다. 정확한 정보는 원문을 확인해 주세요.

요약 원칙 ↗