git-remote-gcrypt

GNU Privacy Guard로 암호화된 git remote

:Manual section: 1

설명

git-remote-gcrypt는 GnuPG로 암호화된 저장소를 사용자 정의 형식으로 푸시 및 풀하기 위한 git remote 헬퍼입니다. 이 remote 헬퍼는 gcrypt::로 시작하는 URI를 처리합니다.

지원되는 백엔드는 local, rsync:// 및 sftp://이며, 저장소는 파일 집합으로 저장되거나, 대신 <giturl>을 사용할 수 있습니다. gcrypt는 git 저장소에 동일한 표현을 저장하며, 임의의 git 전송을 통해 브리지됩니다. 가능하다면 local 또는 rsync://를 선호하세요. 자세한 내용은 아래 "성능"을 참조하십시오.

또한 초기 채택자만을 위한 실험적인 rclone:// 백엔드도 있습니다 (경고했습니다).

목표는 일반적인 신뢰할 수 없는 파일 호스트나 서비스를 사용하여 기밀성 있고 인증된 git 저장소 및 협업을 제공하는 것입니다.

설치 ....

• GNU/Linux 배포판의 패키지 관리자 사용 -- Debian, Ubuntu, Fedora, Arch 및 일부 소규모 배포판에 패키지가 있는 것으로 알려져 있습니다.
• 다른 시스템에서는 제공된 install.sh 스크립트를 실행하세요.

빠른 시작 ..........

암호화된 원격 저장소를 생성하려면 푸시합니다::

git remote add cryptremote gcrypt::rsync://example.com/repo
git push cryptremote master
> gcrypt: 새 저장소 설정 중
> gcrypt: Remote ID는 :id:7VigUnLVYVtZx8oir34R 입니다
> [ 추가 라인.. ]
> To gcrypt::[...]
> * [new branch]      master -> master

설정

다음 git-config(1) 변수가 지원됩니다:

remote.<name>.gcrypt-participants .. gcrypt.participants 공백으로 구분된 GPG 키 식별자 목록. 원격 저장소는 이러한 참가자에게 암호화되며, 이들의 서명만 허용됩니다. gpg -k는 알고 있는 모든 공개 키를 나열합니다.

이 옵션이 설정되지 않은 경우, 기본 키로 암호화하고 유효한 서명을 모두 허용합니다. 이 동작은 참가자를 ``simple``로 설정하여 명시적으로 요청할 수도 있습니다.

remote의 ``gcrypt-participants`` 설정은 저장소 변수 ``gcrypt.participants``보다 우선합니다.

remote.<name>.gcrypt-publish-participants .. gcrypt.publish-participants 기본적으로 참가자의 gpg 키 ID는 gpg -R을 사용하여 암호화됨으로써 숨겨집니다. 이 옵션을 true로 설정하면 해당 보안 조치가 비활성화됩니다.

``gpg -R``을 사용할 때의 문제점은 복호화할 때 gpg가 사용 가능한 키를 찾을 때까지 각 비밀 키를 차례로 시도한다는 것입니다. 이로 인해 불필요한 암호 프롬프트가 발생할 수 있습니다.

gcrypt.gpg-args 이 설정의 내용은 gpg에 인수로 전달됩니다. 예: --use-agent.

remote.<name>.gcrypt-signingkey .. user.signingkey (후자는 일반 git 설정에서 가져옴) 서명에 사용할 키입니다. 기본 서명 키가 참가자 목록에 없는 경우 user.signingkey를 설정해야 합니다. 다른 키로 다른 원격 저장소에 서명하기 위해 remote별 버전을 사용할 수 있습니다.

remote.<name>.gcrypt-rsync-put-flags .. gcrypt.rsync-put-flags rsync:// 백엔드를 사용하여 원격 저장소에 업로드할 때 rsync에 전달할 플래그입니다. 특정 원격 저장소에 플래그가 설정된 경우, 전역 플래그가 설정되어 있어도 해당 원격 저장소에는 적용되지 않습니다.

remote.<name>.gcrypt-require-explicit-force-push .. gcrypt.require-explicit-force-push 오랜 버그로 인해 모든 git push가 사실상 --force가 적용됩니다.

이 플래그가 ``true``로 설정되면, ``--force``가 전달되거나 refspec 앞에 ``+``가 붙지 않는 한 git-remote-gcrypt는 푸시를 거부합니다.

잠재적 해결 방법은 다음과 같습니다: https://bugs.debian.org/877464#32

환경 변수

GCRYPT_FULL_REPACK 이 환경 변수가 설정되면 (빈 문자열이 아닌 값으로), 푸시 시 전체 repack을 강제합니다.

예제

두 명의 참가자를 위한 원격 저장소 설정 방법::

git remote add cryptremote gcrypt::rsync://example.com/repo
git config remote.cryptremote.gcrypt-participants "KEY1 KEY2"
git push cryptremote master

git 백엔드 사용 방법::

# 대상 git 저장소가 이미 존재해야 하며, 해당 저장소의
# `next` 브랜치가 덮어쓰여집니다!
git remote add gitcrypt gcrypt::[email protected]:repo#next
git push gitcrypt master

URL 조각 (여기서는 #next)은 사용할 백엔드 브랜치를 나타냅니다.

참고 사항

협업 매니페스트의 암호화는 참가자 설정과 일치하도록 각 푸시 시 업데이트됩니다. 푸시하는 각 사용자는 모든 협업자의 공개 키와 올바른 참가자 설정을 가지고 있어야 합니다.

의존성 rsync, curl 및 rclone은 각각 rsync:, sftp: 및 rclone: 원격 저장소에 필요합니다. 주요 실행 파일은 local을 지원하는 POSIX 호환 셸이 필요합니다.

GNU Privacy Guard GPG 1.4 및 2가 모두 지원됩니다. 개인 GPG 키가 필요합니다. GPG 구성은 공개 키 암호화, 대칭 암호화 및 서명에 대한 알고리즘 선택에 적용됩니다. 자세한 내용은 man gpg를 참조하십시오.

Remote ID Remote ID는 비밀이 아닙니다. 동일한 사용자가 서명한 두 저장소를 구별하는 데만 사용됩니다. Remote ID가 변경되면 경고가 표시되며, 이는 원격 저장소가 다시 생성된 경우에만 발생해야 합니다.

성능 임의의 <giturl> 또는 sftp:// URI를 사용하면 각 푸시 시 전체 저장소 기록을 업로드해야 합니다. 즉, git 기록이 길어짐에 따라 푸시가 느려지며, git-remote-gcrypt를 계속 사용하는 것이 비현실적인 지점에 쉽게 도달할 수 있습니다.

따라서 저장소가 매우 커지지 않을 것임을 알고 있는 경우에만 이러한 백엔드를 사용해야 하며, 단지 현재 크지 않다는 이유만으로는 안 됩니다. 이는 이러한 백엔드가 대부분의 저장소에 적합하지 않으며, 소규모 자격 증명 저장소와 같은 특수한 경우에만 적합할 수 있음을 의미합니다. 그런 경우에도 가능하면 `rsync://`를 사용하십시오. 단, `rsync://`는 Gitolite, GitHub 또는 GitLab과 같은 저장소 호스팅 서비스에서는 작동하지 않습니다.

rsync URI rsync 백엔드의 URI 형식은 rsync://user@host/path이며, SSH를 통해 액세스하는 rsync 위치 user@host:/path로 변환됩니다. 경로는 홈 디렉터리를 기준으로 한 상대 경로가 아닌 절대 경로입니다. 이전의 비표준 URI 형식도 지원됩니다: rsync://user@host:path는 rsync 위치 user@host:path로 변환됩니다.

rclone 백엔드 URI가 gcrypt::rclone://remote:subdir인 rclone 백엔드를 원격 저장소로 추가하는 것 외에도, rclone 설정에 원격 저장소를 추가해야 합니다. 이는 일반적으로 rclone config를 실행하여 수행됩니다. rclone(1)을 참조하십시오.

rclone 백엔드는 실험적인 것으로 간주되며 초기 채택자만을 위한 것입니다. 경고했습니다.

저장소 형식 ...........

| EncSign(X): 서명 및 GPG 키 보유자에게 암호화 | Encrypt(K,X): 대칭 키 알고리즘을 사용하여 암호화 | Hash(X): SHA-2/256 | | B: 브랜치 목록 | L: 각 팩 파일의 해시(Hi) 및 키(Ki) 목록 | R: Remote ID | | 저장소 쓰기: | | 각 팩 파일 P를 Encrypt(Ki, P) → P'로 저장, 파일 이름 Hi | 여기서 Ki는 임의의 새 문자열이고 Hash(P') → Hi | 매니페스트에 EncSign(B || L || R) 저장 | | 저장소 읽기: | | 매니페스트를 가져와 GPG 키링을 사용하여 복호화 및 확인 → | 이 이전에 본 Remote ID와 일치하지 않으면 경고 | 의 각 에 대해: | 서버에서 파일 가져오기 → | 가 와 일치하는지 확인 | 를 사용하여 복호화 → 그런 다음 git으로 열기

매니페스트 파일 ..............

예제 매니페스트 파일 (간결성을 위해 생략 부호 사용)::

$ gpg -d 91bd0c092128cf2e60e1a608c31e92caf1f9c1595f83f2890ef17c0e4881aa0a
542051c7cd152644e4995bda63cc3ddffd635958 refs/heads/next
3c9e76484c7596eff70b21cbe58408b2774bedad refs/heads/master
pack :SHA256:f2ad50316...cd4ba67092dc4 z8YoAnFpMlW...3PkI2mND49P1qm
pack :SHA256:a6e17bb4c...426492f379584 82+k2cbiUn7...dgXfyX6wXGpvVa
keep :SHA256:f2ad50316...cd4ba67092dc4 1
repo :id:OYiSleGirtLubEVqJpFF

각 항목은 개행까지 확장되며, 다음 중 하나와 일치합니다:

<sha-1> <gitref> Git 객체 ID 및 해당 ref

pack :<hashtype>:<hash> <key> 팩 파일 해시 (Hi) 및 해당 대칭 키 (Ki).

keep :<hashtype>:<hash> <generation> 팩 파일 해시 및 repack 세대

repo <id> 원격 ID

extn <name> ... 확장 필드, 보존되지만 사용되지 않음.

gcrypt 저장소 감지

git URL이 gcrypt 저장소인지 감지하려면: git-remote-gcrypt --check url 저장소가 존재하고 해독 가능하면 종료 상태 0, 저장소가 gcrypt를 사용하지만 해독할 수 없으면 1, 저장소가 gcrypt로 암호화되지 않았거나 액세스할 수 없으면 100을 반환합니다.

이렇게 하려면 gcrypt 저장소를 사용할 때와 마찬가지로 로컬 git 저장소로 저장소 내용을 가져와야 합니다.

알려진 문제

모든 git push가 사실상 --force가 적용됩니다. 푸시하기 전에 반드시 풀하세요.

git-remote-gcrypt는 경고 없이 원격 저장소를 repack하기로 결정할 수 있으며, 이는 전체 기록을 다시 업로드해야 하므로 예상보다 훨씬 오래 걸릴 수 있습니다. 이러한 푸시는 연결이 좋지 않으면 실패할 수 있습니다.

git-remote-gcrypt는 저장소가 실제로 존재하지만 인증, 포트 또는 네트워크 연결 문제가 있는 경우 "찾을 수 없음"으로 보고할 수 있습니다.

참고

git-remote-helpers(1), gpg(1)

크레딧

git-remote-gcrypt의 원저자는 GitHub 사용자 bluss입니다.

2013년과 2014년의 사실상의 유지보수자는 Joey Hess였습니다.

2016년부터 현재 유지보수자는 Sean Whitton [email protected]입니다.

라이선스

이 문서와 git-remote-gcrypt는 동일한 조건, GPL-3 (또는 2+)로 라이선스가 부여됩니다. 자세한 내용은 git-remote-gcrypt 파일을 참조하십시오.

.. 이 문서는 rst2man을 사용하여 man 페이지를 생성합니다. .. vim: ft=rst tw=72 sts=4