Git 3.0의 SHA-256 기본값, 꼭 필요한 변화일까

출처: Butler's Log (GitButler 블로그), Scott Chacon
원문: https://blog.gitbutler.com/git-3-sha-256
작성자: 팔복소프트-김팔복

한눈에 보기

• Git 3.0부터 git init으로 만드는 새 저장소는 SHA-1 대신 SHA-256 해시를 기본으로 씁니다.
• GitHub 공동창업자이자 『Pro Git』 저자인 Scott Chacon이 이 변경은 비용이 크고 실익이 거의 없다며 공개적으로 반대했습니다.
• 그의 핵심 논리는 Git 해시가 신뢰의 근거가 아니라는 것입니다. 신뢰는 어디서 pull 하느냐로 결정된다고 봅니다.
• SHA-1 저장소와 SHA-256 저장소는 서로 섞을 수 없습니다. 그래서 원격 저장소, submodule, 사내 도구 곳곳에서 호환성 문제가 예상됩니다.
• 원문 기준으로 GitHub는 아직 SHA-256 저장소 push를 받지 않습니다. 저자는 이것이 3.0 출시를 늦추는 주된 이유일 것으로 봅니다.
• 대안으로 SHA-1은 저장 키로 그대로 두고, 서명할 때만 트리 전체를 별도 해시로 계산해 함께 서명하는 방식을 제안했습니다.
• 팔복소프트 결론: 지금 할 일은 마이그레이션이 아니라, 커밋 해시를 40자로 가정한 사내 코드를 점검하는 것입니다.

배경

Git은 파일 내용의 해시를 키로 객체를 저장하는 content-addressable 저장소입니다. 각 커밋은 이전 커밋의 해시를 포함합니다. 그래서 과거 이력 하나를 바꾸면 그 뒤의 해시가 전부 달라집니다. Git은 2005년부터 SHA-1을 써 왔습니다. 그런데 2017년 SHAttered, 2020년 SHA-1 is a Shambles 연구에서 의도적으로 해시 충돌을 만들 수 있다는 것이 공개됐습니다. 이후 Git 프로젝트는 오랫동안 SHA-256 지원을 준비해 왔고, Git 3.0에서 이를 기본값으로 올립니다.

주요 내용

기본값이 바뀌면 현장에서 생기는 일

Chacon이 짚은 실무 문제부터 보겠습니다. 국내 개발자에게 가장 직접적으로 와닿는 부분입니다.

• 원격 저장소와 형식 불일치: 서버에 저장소를 만들 때 SHA-1과 SHA-256 중 하나를 골라야 합니다. 로컬과 형식이 다르면 push가 거부됩니다. 개발자가 자기 Git 버전을 모르면 원인을 찾기도 어렵습니다.
• submodule: 같은 형식끼리만 연결됩니다. 널리 쓰이는 라이브러리는 두 형식을 모두 유지해야 할 수 있습니다.
• 기존 저장소 변환: 모든 객체를 다시 해싱하므로 기존 서명이 깨집니다. 이슈, 메신저, 문서에 남아 있는 커밋 링크도 쓸 수 없게 됩니다. 팀 전체가 동시에 전환하지 않으면 이력이 갈라집니다.
• 40자 가정: 해시 길이가 40자(SHA-1)에서 64자(SHA-256)로 바뀝니다. 길이를 고정해 둔 도구는 모두 수정해야 합니다.
• 재구현 라이브러리: Git 바이너리를 직접 호출하지 않고 자체 구현 라이브러리를 쓰는 도구가 많습니다. 원문에 따르면 이런 라이브러리는 SHA-256을 지원하지 않거나 일부만 지원합니다.
  원문은 Google의 Emily Shaffer가 한 발표도 소개합니다. Google은 사내 전체 기본값을 SHA-1로 고정해 3.0의 변경을 최대한 미루는 방안까지 검토하고 있다고 합니다.

반대 근거: 해시는 신뢰 수단이 아니다

Chacon은 "SHA-1이 깨졌다"는 표현부터 정리합니다. 우연히 충돌이 난다는 뜻이 아닙니다. 돈과 GPU를 투입하면 특정 형태의 두 콘텐츠를 일부러 같은 해시로 만들 수 있다는 뜻입니다.

현실적인 위협은 충돌 공격뿐입니다. 그런데 이 공격은 신뢰받는 저장소에 공격자가 먼저 파일을 넣을 수 있어야 성립합니다. 저자는 그 정도 접근 권한이 있다면 해시를 조작할 필요 없이 그냥 악성 코드를 넣으면 된다고 봅니다. 실제 공격은 대부분 해시가 아니라 공급망에서 일어난다는 것입니다. 예를 들어 지친 메인테이너에게서 패키지 관리 권한을 사들이거나, 소셜 엔지니어링으로 npm 패키지의 쓰기 권한을 얻는 방식입니다. Linus Torvalds도 Git 초기에 같은 입장을 밝혔습니다.

The real security is in distribution.
— Linus Torvalds, 2005년 Git 메일링 리스트

대안: 서명할 때만 두 번째 해시를

제안 내용은 이렇습니다. 객체를 저장하고 찾는 키로는 SHA-1을 계속 씁니다. 대신 커밋이나 태그에 서명할 때 트리 전체를 SHA-256이나 BLAKE3 같은 다른 해시로 따로 계산합니다. 그 값을 헤더로 넣어 함께 서명합니다. 2015년부터 나와 있는 git-evtag가 거의 같은 방식입니다. 저자가 만든 PoC의 측정치는 다음과 같습니다.

이 방식에는 장점이 있습니다. 해시 알고리즘이 다시 약해지면 새 헤더만 추가하면 되므로, 생태계 전체를 다시 옮길 필요가 없습니다. 저자는 NIST의 2030년 SHA-1 퇴출 요구도 충족된다고 주장합니다. 그 요구는 "보호 목적으로 SHA-1을 쓰지 말라"는 것이고, 이 방식에서는 SHA-1이 보호 역할을 하지 않기 때문입니다. 저자가 인정한 한계도 있습니다. 검증되는 것은 서명된 객체뿐이고, 신뢰가 이력 전체로 전파되지는 않습니다.

팔복소프트 관점

먼저 이 글은 공식 발표가 아니라 의견이라는 점을 기억해야 합니다. 반대 논리는 설득력이 있습니다. 하지만 SHA-256 전환은 Git 메일링 리스트에서 수년간 논의한 끝에 나온 결정입니다. 또 저자는 Git 클라이언트(GitButler)를 만드는 회사의 대표라서, 두 형식을 모두 지원해야 하는 부담을 직접 지는 입장입니다. 이 글 때문에 3.0 계획이 바뀔지는 아직 알 수 없습니다.

제안된 대안에도 약점이 있습니다. 보호가 서명된 태그나 커밋에만 적용되므로, 서명을 쓰지 않는 팀에게는 사실상 효과가 없습니다. 국내에는 커밋 서명을 쓰지 않는 팀이 여전히 많습니다.

국내 영향은 GitHub보다 사내 인프라에서 더 크게 나타날 가능성이 높습니다. 금융, 공공, 대기업은 self-managed GitLab, Gitea, Bitbucket Server를 많이 쓰고, 서버 업그레이드는 보통 늦습니다. 반면 개발자 PC의 Git은 Homebrew나 패키지 매니저로 먼저 올라갑니다. 로컬은 SHA-256인데 서버는 이를 지원하지 않는 상황이 충분히 생길 수 있습니다.

지금 당장 해볼 만한 점검은 다음과 같습니다.

• 배포 스크립트, CI 설정, Jira·Slack 연동 봇에서 커밋 해시를 [0-9a-f]{40} 같은 정규식으로 검사하는 코드가 있는지 찾아보세요.
• 커밋 해시를 CHAR(40) 컬럼에 저장하는 DB가 있는지 확인하세요.
• Java 기반 사내 도구나 CI 플러그인이 Git 바이너리 대신 자체 구현 라이브러리를 쓰는지 확인하세요. 쓴다면 해당 라이브러리의 SHA-256 지원 범위를 문서에서 확인해야 합니다.
  아래 명령으로 테스트용 저장소를 미리 만들어 사내 도구를 시험해 볼 수 있습니다.

# 현재 저장소의 해시 형식 확인
git rev-parse --show-object-format
 
# SHA-256 테스트 저장소 생성
git init --object-format=sha256 /tmp/sha256-test

보안 우선순위에 대해서는 저자 의견에 동의합니다. 국내에서도 실제 사고는 의존성 쪽에서 납니다. lockfile 관리, 패키지 출처 검증, 브랜치 보호와 코드 리뷰가 해시 알고리즘보다 훨씬 효과적입니다. 다만 보안 심사에서 SHA-1 사용 여부를 체크리스트로 확인하는 조직이라면 사정이 다릅니다. 저자의 NIST 해석이 감사 현장에서 받아들여질지는 별개 문제이고, 이런 조직은 오히려 SHA-256 전환 압박을 먼저 받을 수 있습니다.

정리

Git 3.0의 기본값 변경은 기존 저장소를 바로 바꾸지는 않습니다. 대신 새로 만드는 저장소부터 두 형식이 섞이는 상황을 만듭니다. 3.0이 실제로 SHA-256을 기본값으로 출시될지, 그리고 GitHub와 사내 Git 서버가 언제 이를 지원할지가 다음으로 지켜볼 지점입니다. 그 전에 할 수 있는 가장 현실적인 준비는 해시 길이를 가정한 코드를 찾아 두는 것입니다.

• Git
• SHA-256
• 버전관리
• 공급망보안
• DevOps