GPG 키를 사용하여 Git 제출 서명 - 섹션 1
8255 단어 devopssecuritytechnologygit
이 글은 최초로 2021년 2월 24일(수요일) cloudwithchris.com에 발표되었다.
한동안 GPG 키를 사용하여 GitHub에서 제출한 것이 진실이고 나에게서 왔다는 것을 증명하기 위해 GTHut 제출에 서명해 왔다.지난 몇 주 동안 나는 몇 명의 동료들로부터 깨우침을 받았다. (아드리안과 졸리, 당신이 이 글을 읽었다면 영광스러울 것이다.) 나는 나의 유비키를 찾아서 나의 관건적인 서명 활동에 사용하고 싶다.이미 여러 편의 이 화제에 관한 블로그 글/견본(예를 들어 here, here과 here)이 있지만 나는 많은 장애에 부딪혔다.
이 블로그의 목적은 일련의 문장의 첫 번째 편으로서 GPG가 무엇인지, 왜 그것이 당신에게 가치가 있는지, 그리고 그것을 어떻게 사용하는지 연구하는 것이다.그리고 이를 더욱 추진하고 유비키즈를 제2의 검증 요소로 어떻게 사용하는지, 그리고 이런 방법의 장점을 보여줄 것이다.나는 절대로 세계의 암호학 전문가도 아니고 그 중의 일부 주제의 전문가도 아니다. 그러나 나는 자손 후손을 위해 나의 이해를 기록하고 싶다. 왜냐하면 나는 장래에 불가피하게 이 과정을 반복/회고해야 하기 때문이다.나는 이것이 너에게 유용하길 바란다.
우선 GPG란 무엇입니까?때로는 GnuPG 또는 GNU 프라이버시 보호라고도 불린다. (만약 당신이 알고 싶다면, GNU 프로젝트는 1980년대에 설립된 자유 소프트웨어 프로젝트로, 최초의 목표는 운영체제의 모든 부분을 무료로 하는 것이다. 나의 연구에 따르면, GNU 프로젝트와 GNU 허가증 사이에는 구별이 있지만, 우리는 이 시리즈에서 이 점을 토론하지 않을 것이다. (이것은 나의 호기심이다.)
GnuPG 사이트에 따르면 GPG에 대한 설명은 다음과 같다-
"GnuPG는 RFC4880(PGP라고도 함)이 정의한 OpenPGP 표준의 완전한 무료 구현입니다..GnuPG는 데이터와 통신을 암호화하고 서명할 수 있도록 합니다.그것은 일반적인 키 관리 시스템과 각종 공공 키 디렉터리의 접근 모듈을 갖추고 있다.GPG라고도 하는 GnuPG는 명령행 도구로 다른 응용 프로그램과 통합하기 쉬운 기능을 갖추고 있다.대량의 프런트엔드 응용 프로그램과 라이브러리를 사용할 수 있습니다.GnuPG는 S/MIME 및 Secure Shell(ssh)도 지원합니다."
이제 우리는 안전과 암호학의 세계로 들어갔다.이러한 장면을 상상해 보세요. 사용자에게 메시지를 보내고 싶지만, 수신자는 메시지가 진정으로 당신에게 온 것인지 확인하기를 원합니다.또는, 발송자로서, 당신은 수신자가 그것을 볼 수 있기만을 바랄 뿐, 어떤 도청자 (앨리스, 밥, 이브) 에게 압수되지 않기를 바랄 뿐이다.GPG는 고객이 이 문제를 해결할 수 있도록 설계되었습니다.
그렇다면 Git 장면에서 왜 중요한 것일까?이 점에서, 나는 당신이 적어도 Git의 기본 원리를 이해한다고 가정합니다.Git는 빠른 입문/복습으로 분포식 버전 제어 시스템이다.제출마다 이름과 이메일 주소를 포함한 관련 메타데이터가 있습니다.이 메타데이터는 권위 있는 원본으로 연결되지 않았고, 어떤 방식으로도 검증되지 않았다.이 장면에 대해 우리는 {Alice, Bob, Eve}@contoso가 있다고 가정한다.com, 그들은 본문 앞에서 소개한 적이 있다.Git에서 다른 사용자를 속이는 것은 매우 쉽다.역사를 다시 쓸 수도 있다. (비록 당신이 무엇을 하고 있는지 모르지만, 나는 당신에게 어떤 실시간 환경에서도 시도해 보라고 건의하지 않는다.)
지금, 이런 배경에서.다른 사용자를 모방하거나 역사를 다시 쓰는 것이 얼마나 쉬운지 예를 들어 봅시다.
우선, 우리는 계속해서 새로운 디렉터리를 만들 것이다.탐색하여
git init을 사용하여 Git 저장소를 초기화합니다.그런 다음 새로 초기화된 Git 저장소로 이동하여 다음 로컬 구성을 설정합니다.
git config --local user.email "[email protected]"
git config --local user.name "Alice"
그런 다음 Alice에서 myfile이라는 파일을 생성합니다.다음 내용이 포함된 php:
<?php
echo "Hello World";
?>
이것은 버전 제어가 이 파일이 존재하는 것을 알고 있지만 Git에서 정식으로 식별/버전 제어를 받지 못했다는 것을 의미한다.우리는 먼저 파일을 무대에 오르는 환경에 추가한 다음에 버전 제어에 제출해야 한다.
git add myfile.php
git commit -m "My Hello World Sample"
이제 앨리스가 달라진 걸 볼 수 있어!적어도 그것은 앨리스가 한 것 같다.당신은 우리가 언제든지 로그인하거나 인증하거나 우리가 누구인지 검증하는 것을 기억합니까?이제 앨리스의 진정한 약속이라고 가정해 봅시다.환경을 바꿔서 밥이 되자.
git config --local user.email "[email protected]"
git config --local user.name "Bob"
이제 Bob에서 다음 명령을 실행합니다-
git add myfile.php
git commit -m "Adjust to Hello Contoso"
git log 명령을 사용하면 두 사용자가 변경된 것을 볼 수 있습니다.앨리스와 밥.마찬가지로, 이 변경 사항들은 두 사용자가 진행한 것 같다.다시 한 번 기억해 주십시오. 우리는 우리가 앨리스나 밥이라는 것을 증명할 필요가 없습니다.
마지막 장면, 이브 기억나?이브는 이 프로젝트에 관심이 많아서, 이 위대한 일을 앨리스에게 돌리고, 밥을 사진에서 삭제하고 싶었다.
Git 제출 역사를 다시 쓰는 함수를 실행할 때는 각별히 조심해야 한다.만약 원본 코드를 다른 사용자가 접근할 수 있는 저장소 (예를 들어Azure DevOps,GitHub 등) 에 통합했다면, 원격 저장소는 역사를 다시 쓰는 것을 받아들이지 않을 수도 있고, 만약 정말 이렇게 한다면 많은 고통을 초래할 수도 있습니다.네가 네가 한 일의 결과를 철저히 이해하지 않으면, 나는 네가 어떤 생활 환경에서도 이렇게 하는 것을 건의하지 않을 것이다.이 방면에 관한 많은 지침/문장이 본문의 범위를 넘어섰다.
이제 건강 경고는 지나갔으니 계속합시다...Eve는 다음 스크립트를 계속 실행합니다.이 스크립트는
git-filter-branch 명령을 사용하여 모든 제출을 구 전자메일과 새 전자메일로 바꾸고 이름을 바꿉니다.스크립트에서if문장과 일치하는 제출은 변경됩니다.git filter-branch --env-filter '
OLD_EMAIL="[email protected]"
NEW_NAME="Alice"
NEW_EMAIL="[email protected]"
if [ "$GIT_COMMITTER_EMAIL" = "$OLD_EMAIL" ]
then
export GIT_COMMITTER_NAME="$NEW_NAME"
export GIT_COMMITTER_EMAIL="$NEW_EMAIL"
fi
if [ "$GIT_AUTHOR_EMAIL" = "$OLD_EMAIL" ]
then
export GIT_AUTHOR_NAME="$NEW_NAME"
export GIT_AUTHOR_EMAIL="$NEW_EMAIL"
fi
' --tag-name-filter cat -- --branches --tags
질문 보셨어요?우리는 이 약속들의 진실성을 보장할 수 없다.그 사람들은 앨리스, 밥 아니면 이브인가?모든 범죄 행위가 가짜일 수 있습니까?만약 어떤 서명한 약속이 없다면, 우리는 자신이 없다.이것이 바로 GPG 키가 이 특정 장면에서 차지하는 가치이다.제출한 변경 사항이 사용자 메타데이터(예를 들어 전자 우편 주소)와 일치하는 키로 서명되었음을 보여줄 수 있습니다.
또 다른 가능한 상황이 있다.오픈소스에 참여할 계획이라면 개발자 원산지 인증서(DCO)가 필요할 수도 있습니다.i, e. 어떤 형식의 검증을 통해 변경 사항을 확인했습니다. (다른 곳에서 이 코드를 훔치거나 중복 사용하지 않는 프로토콜을 제출할 권리가 있습니다.)마찬가지로 GPG 서명은 사용자의 신뢰성을 증명하는 데 매우 중요합니다.
GPG 키는 비대칭 키 쌍과 같은 일반적인 보안 원칙을 기반으로 하기 때문에 다른 사용자와 공유할 수 있는 공개 키를 얻을 수 있지만, 그 중에서 서명/암호화할 수 있는 개인 키를 얻을 수 있습니다.나는 GPG가 다른 장면을 처리할 수 있다고 믿지만 이것은 우리가 중점적으로 주목할 주요 장면이다.어떤 암호학 토론과 마찬가지로 키를 안전하게 관리해야 한다. (권한이 부여되지 않은 접근 권한을 얻는 사람은 없지만 키가 분실된 경우 백업을 할 수도 있다.)우리는 잠시 후의 블로그 글에서 일부 모델을 연구할 것입니다. 그러면 모든 계란을 한 바구니에 넣지 않을 뿐만 아니라, 개인적인 목적으로 서로 다른 하위 키를 사용할 수 있습니다. (이를 최소한의 특권 원칙으로 간주할 것입니다. 다른 작업/서비스에 접근할 수 있는 슈퍼 키가 아니라.)
그럼 평가를 해 봅시다.지금까지 다 알고 있었어-
내가 언급한 바와 같이, 이것은 일련의 블로그 문장이 될 것이다.나는 한 게시물에 너무 많은 투자를 하고 싶지 않다. 너무 빨리 사람을 어찌할 바를 모르게 한다.그래서 이것은 이 문제를 둘러싼 최초의 배경이며, 왜 당신이 이 문제를 연구하고 싶어 하는지를 연구하는 것이다.나는 이것이 유용하길 바란다.이 시리즈의 다음 글은 제출에 사용할 GPG 키를 계속 생성하고 생성하는 방법을 연구할 것입니다. (이 예에서는 YubiKey를 사용하지 않습니다.)
Reference
이 문제에 관하여(GPG 키를 사용하여 Git 제출 서명 - 섹션 1), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/cloudwithchris/using-gpg-keys-to-sign-git-commits-part-1-8mi텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
좋은 웹페이지 즐겨찾기
