[문제 1]

GitHub의 비밀 키 스캐닝(Secret Scanning) 기능이 push를 차단한 상황이다.

[github 공식 문서 - 차단된 푸시 해결]
https://docs.github.com/ko/code-security/secret-scanning/working-with-secret-scanning-and-push-protection/working-with-push-protection-from-the-command-line#resolving-a-blocked-push

[해결 1]

일단 2가지 방식이 있는데,
앞선 글에서 대용량 파일 제거 시 사용했던 git filter-repo를 이용하는 방식,
그리고 git history 관리를 위해 통상 사용하는 git rebase -i 방식이다.

두 방식을 비교해 보면 아래와 같다.

github 공식 문서에서 제공해준 방식은 rebase(리베이스) 방식이고,

현재 필자의 상황은 시크릿 키가 특정 커밋 내역에만 일부 포함되어 있는 상태로, 1~2개의 소수 커밋만 다루면 되기 때문에, 정밀하게 커밋을 제어할 수 있는 해당 rebase 방식으로 진행해보려고 한다.

0. rebase(리베이스)란?

브랜치의 커밋 이력을 다시 쓰는 도구이다.

특히 git rebase -i는 대화형(Interactive Rebase)으로, 과거 커밋 내용을 수정/삭제/병합 할 수 있다.

1. 커밋 목록 불러오기

강제로 git push 했을 때, 오류 메세지에 시크릿 키가 어떤 커밋에 포함되어 있는 지를 함께 알려주었으므로, 링크로 첨부한 'github 공식 문서 - 분기의 이전 커밋이 도입한 비밀 제거' 중 4번째 단계부터 시작해보겠다.

명령어는 다음과 같다. < COMMIT-ID >는 본인 것을 입력하면 된다.

git rebase -i 30ef1bd23ffc6c774b14cd946578d876b893984f~1

그럼 생각보다 끔찍한 화면이 뜨는데.. 첨부한 이미지는 전체 내역의 10%도 채 안되는 길이다.. 고작 하나 입력했는데 수많은 커밋이 뜬 것..

확실히 조금만 개수가 많아져도 그냥 git filter-repo 사용하는 게 정신 건강에 이롭지 않으려나.. 싶다.

아무튼 커밋 목록이 pick으로 쭉 나열된 편집기 화면이 뜬다.

2. 민감 정보(시크릿 키)가 포함된 커밋만 바꾸기

'github 공식 문서 - 분기의 이전 커밋이 도입한 비밀 제거' 중 5번째 단계이다.

편집기의 수많은 pick 들 중 본인이 리베이스 명령어에 입력한 커밋 번호를 찾아서 해당 부분을 edit으로 수정해줘야 한다.

예를 들어, 필자의 경우 git rebase -i 30ef1bd~1을 입력했으니, 30ef1bd번 커밋을 찾아서 수정할거다.

pick -> edit

pick 30ef1bd S11P12A609-421 chore: 포팅 매뉴얼 업로드 필자의 경우 이 커밋 부분을 찾아서 edit 30ef1bd S11P12A609-421 chore: 포팅 매뉴얼 업로드 으로 수정해준다.

수정하면, esc -> :wq -> enter 저장 후 편집기 종료!

💡 TIP!

1. 편집기에서 텍스트 입력이 안된다면?

알파벳 i를 눌러서 편집(INSERT) 모드로 전환 후 수정

2. 편집기에서 헤매다가 뭔가 잘못 누른 것 같으면?

esc -> :q! -> enter 로 편집기를 빠져나온 뒤, git rebase --abort 명령어를 통해 리베이스 작업을 완전히 취소하고, 시작 전 상태로 원복 가능!

그럼 위와 같이 Git이 멈추고, 민감 정보가 포함된 파일을 수정할 수 있는 상태가 된다.

3. 민감 정보 삭제

이제 'github 공식 문서 - 분기의 이전 커밋이 도입한 비밀 제거' 중 7번째 단계

필자가 수정해야 할 파일은 exec/README.md 이다.
그 중에서도 40, 41, 392, 393, 914, 915번 줄에 민감 정보(시크릿 키)가 포함되어 있음을 최초 오류 시점에 git이 알려주었기 때문에, 아래 명령어로 VS code를 실행해서 해당 부분을 수정해준다.

code exec/README.md

필자는 해당 AWS 서버 기간이 끝나서 사용할 일이 없기 때문에, 그냥 간략하게 기존 시크릿 키를 REDACTED라는 단어(민감한 부분 삭제)로 교체해 줄 것이다.

수정 후 저장하고 VS code 닫으면 된다.

4. 커밋 찍기

이제 마지막! 'github 공식 문서 - 분기의 이전 커밋이 도입한 비밀 제거' 중 8-11번째 단계

위 순서대로 진행하면 되는데, 필자는 수정한 파일만 git add 했다.

git add exec/README.md

그리고 아래와 같이 커밋을 찍으면, 하단에 보이듯 편집기가 하나 뜬다.
커밋 메시지를 변경하고 싶다면 변경하고, 유지할 거면 그대로 편집기 닫아주면 된다. Author는 소중한 우리 팀원이므로(시크릿..) 가려두었다.

git commit --amend

이어서 계속 rebase(리베이스) 진행해주면 되는데.. 충돌이 발생했다 ! ㅠ

git rebase --continue

---

[문제 2]

리베이스(rebase) 과정 중 커밋 하나 (fc9cc8e... chore: Update Contribution)에서 병합 충돌(conflict)이 났다.

[해결 2]

1. 일단 충돌된 파일을 연다.

code README.md

2. 충돌된 부분 수정 후 저장하고 닫는다.

열어보니 별 충돌도 아니더라~ 소중한 팀원 정보 다시 시크릿 처리..

3. 커밋 찍고 다시 리베이스(rebase) 진행

git add README.md

git rebase --continue

해당 과정에서 나는 충돌 하나 더 있었고.. ^^
암튼 파일 하나 더 수정 후 최종 리베이스 성공! ㅠ bb

---

[문제 3]

이제 문제의 커밋 두개 중 하나는 처리했으니, 다시 한 번 강제 push 해보면 남은 한개만 오류에 뜨겠지? 하고 일단 push 해봤다.

git push --force origin main

그러나 오류는 그대로 였다.. 왜?

응~ main 브랜치가 문제인데, develop 브랜치에서 했어..^^

main 브랜치 이동해서 처음부터 다시 노가다 뛰어야 하는 건가..

[해결 3]

그런데 불행 중 다행으로, 우리 프로젝트는 main보다 develop 브랜치가 앞서 있어서, 아예 develop 브랜치를 강제로 main에 덮어 써도 되는 상황이었다.

main 브랜치를 완전히 develop 브랜치와 히스토리 통일해 버리는 방법!

⚠️ 싹 갈아엎어 씌워지는 방법이니 조심할 것.

main 브랜치 이동해서 강제 push 진행

명령어는 다음과 같다.

git checkout main
git reset --hard develop
git push --force

역시 한 번에 되는 건 없죠.

main 브랜치가 github 원격 브랜치(origin)의 main 브랜치와 연결되지 않은 상태라는 오류가 떴다.

제시해준 명령어로 다시 해봅니다..

git push --set-upstream origin main

---

[문제 4]

다시 Push 해 보았으나, 역시.. 시크릿 키를 다 지우지 않아서 그런지 오류가 다시 떴다.

그런데.. blob 단위로 검출된 민감 정보요..?

Blob ?

Git은 커밋(Commit) 뿐만 아니라, 내부적으로 저장하는 모든 파일을 blob 객체(Binary Large Object) 형태로 관리한다.

즉, 커밋을 rebase로 수정하거나 파일을 삭제하더라도,
해당 파일의 blob이 다른 커밋이나 히스토리에 여전히 남아 있으면, Github의 Secret Scanning 검사 대상이 된다.

따라서 이 경우, 단순 rebase로는 처리 불가 하다.

제일 처음에 정리해두었던 완전 제거 방식 git filter-repo를 이용해, 해당 민감 정보 파일이 담긴 blob 자체를 git 기록에서 완전히 제거해 주어야 한다.

[해결 4]

1. blob ID 포함된 파일 찾기

오류 메세지에서 알려준 Blob ID 308ba8ff76e96a33cfc55303b4a7c0de2d8e566f가 포함된 파일을 찾는다.

명령어는 아래와 같다. (본인의 Blob ID를 입력할 것)

git rev-list --objects --all | grep 308ba8ff76e96a33cfc55303b4a7c0de2d8e566f

역시나.. 앞선 문제의 커밋 두개 중 나머지 하나. 제거하지 않았던 부분이다.

어떻게 그게 하필 또 Blob 이었댄다.

—— Amazon AWS Access Key ID ——————————————————————————
remote:        locations:
remote:          - commit: 76ff8ad503db81a811d3311929a07299eda9c7f0
remote:            path: imnotdurnk_backend/src/main/resources/application-secrete.yml:12
remote:
—— Amazon AWS Secret Access Key ——————————————————————
remote:        locations:
remote:          - commit: 76ff8ad503db81a811d3311929a07299eda9c7f0
remote:            path: imnotdurnk_backend/src/main/resources/application-secrete.yml:13

2. 해당 파일 전체 히스토리에서 삭제

혹시 모르니 해당 파일 따로 백업해두고, 삭제를 진행했다.

git filter-repo --force --invert-paths --path imnotdurnk_backend/src/main/resources/application-secrete.yml

3. 원격(Origin)저장소 재 연결 후 push

명령어

git remote add origin https://github.com/hi-react/S11P12A609.git
git push --force origin main

최최최..종 성공.. 고생했수다..

💡 오늘의 교훈 : 대용량 파일(*.apk 등) 올리지 마라. 비밀 키(application-secret.yml 등) 제발 .gitignore 제발요 제발