git-remote-gcrypt

GNU Privacy Guardで暗号化されたgitリモート

:Manual section: 1

説明

git-remote-gcryptは、GnuPGで暗号化されたリポジトリをカスタム形式でプッシュおよびプルするためのgitリモートヘルパーです。このリモートヘルパーは、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: Setting up new repository
> gcrypt: Remote ID is :id:7VigUnLVYVtZx8oir34R
> [ more lines .. ]
> To gcrypt::[...]
> * [new branch]      master -> master

設定

以下の git-config(1) 変数がサポートされています:

remote.<name>.gcrypt-participants .. gcrypt.participants スペース区切りのGPG鍵識別子のリスト。リモートはこれらの参加者に対して暗号化され、これらの署名のみが受け入れられます。 gpg -k は、知っているすべての公開鍵を一覧表示します。

このオプションが設定されていない場合、デフォルト鍵で暗号化し、有効な署名をすべて受け入れます。この動作は、参加者を ``simple`` に設定することで明示的に要求することもできます。

リモートの ``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.<name>.gcrypt-rsync-put-flags .. gcrypt.rsync-put-flags rsync:// バックエンドを使用してリモートにアップロードする際に rsync に渡されるフラグ。特定のリモートにフラグが設定されている場合、グローバルフラグ（設定されていても）はそのリモートには適用されません。

remote.<name>.gcrypt-require-explicit-force-push .. gcrypt.require-explicit-force-push 長年のバグとして、すべてのgitプッシュが事実上 --force になっています。

このフラグが ``true`` に設定されている場合、git-remote-gcryptは、``--force`` が渡されるか、refspecが ``+`` でプレフィックスされない限り、プッシュを拒否します。

潜在的な解決策についてはこちら: https://bugs.debian.org/877464#32

環境変数

GCRYPT_FULL_REPACK 設定されている場合（空文字列以外の値）、この環境変数はプッシュ時に完全な再パックを強制します。

例

2人の参加者向けにリモートを設定する方法::

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:、sftp:、rclone: にはそれぞれ rsync、curl、rclone が必要です。メインの実行可能ファイルには、local をサポートするPOSIX準拠のシェルが必要です。

GNU Privacy Guard GPG 1.4 と 2 の両方がサポートされています。個人用のGPG鍵が必要です。GPGの設定は、公開鍵暗号、対称暗号、署名のアルゴリズム選択に適用されます。詳細については man gpg を参照してください。

リモートID リモートIDは秘密ではありません。同じユーザーによって署名された2つのリポジトリを区別できるようにするためのものです。リモート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バックエンド gcrypt::rclone://remote:subdir のようなURIでリモートとしてrcloneバックエンドを追加することに加えて、rclone設定にもリモートを追加する必要があります。これは通常、rclone config を実行することで行われます。rclone(1)を参照してください。

rcloneバックエンドは実験的とみなされており、早期導入者のみを対象としています。注意が必要です。

リポジトリ形式 .................

| EncSign(X): GPG鍵所有者に署名＆暗号化 | Encrypt(K,X): 対称鍵アルゴリズムを使用して暗号化 | Hash(X): SHA-2/256 | | B: ブランチリスト | L: 各パックファイルのハッシュ（Hi）と鍵（Ki）のリスト | R: リモートID | | リポジトリの書き込み: | | 各パックファイル P を Encrypt(Ki, P) → P' としてファイル名 Hi に保存 | ここで Ki は新しいランダム文字列、Hash(P') → Hi | マニフェストに EncSign(B || L || R) を保存 | | リポジトリの読み取り: | | マニフェストを取得し、GPGキーリングで復号＆検証 → | が以前に見たリモート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> パックファイルのハッシュとその再パック世代

repo <id> リモートID

extn <name> ... 拡張フィールド。保存されるが使用されない。

gcryptリポジトリの検出

git URLがgcryptリポジトリかどうかを検出するには: git-remote-gcrypt --check url を使用します。終了ステータスは、リポジトリが存在し復号できる場合は0、リポジトリがgcryptを使用しているが復号できない場合は1、リポジトリがgcryptで暗号化されていない（またはアクセスできない）場合は100です。

これは、gcryptリポジトリを使用する場合と同様に、リポジトリの内容をローカルのgitリポジトリにフェッチすることに注意してください。

既知の問題

すべてのgitプッシュが事実上 --force になります。プッシュする前に必ずプルしてください。

git-remote-gcryptは警告なしにリモートの再パックを決定することがあり、その場合、全履歴を再アップロードする必要があるため、プッシュが予想よりも大幅に長くかかる可能性があります。このプッシュは、接続状態が悪いと失敗する可能性があります。

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