真正理解git-remote-gcrypt，要从它处理的任务开始：PGP- 加密的 git 遥控器。从软件开发的使用方式看，依赖、接口和异常处理往往比主路径更影响采用是采用前必须回答的问题。短测时我会在隔离分支完成一个可回滚的小任务，并保留安装步骤、接口契约、测试结果和错误信息的结果，方便团队复盘。我会把它列入需要可检查开发流程而非单次演示的工程师的候选清单，而不是仅凭项目介绍直接纳入生产。

================= git-remote-gcrypt

GNU Privacy Guard 加密的 git 远程

：手册部分：1

描述

git-remote-gcrypt is a git remote helper to push and pull from 使用自定义格式使用 GnuPG 加密的存储库。 这个遥控器 帮助程序处理前缀为 gcrypt:: 的 URIs。

支持的后端有 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：远程 ID 是：id：7VigUnLVYVtZx8oir34R
> [更多行..]
> 到 gcrypt::[...]
> * [新分支] master -> master

配置

支持以下“git-config(1)”变量：

remote.<name>.gcrypt-participants .. gcrypt.participants Space-separated list of GPG key identifiers. The remote is encrypted to these participants and only signatures from these are accepted. gpg -k lists all public keys you know.

If this option is not set, we encrypt to your default key and accept
any valid signature. This behavior can also be requested explicitly
by setting participants to ``simple``.

The ``gcrypt-participants`` setting on the remote takes precedence
over the repository variable ``gcrypt.participants``.

remote.<name>.gcrypt-publish-participants .. gcrypt.publish-participants By default, the gpg key ids of the participants are obscured by encrypting using gpg -R. Setting this option to true disables that security measure.

The problem with using ``gpg -R`` is that to decrypt, gpg tries each
available secret key in turn until it finds a usable key.
This can result in unnecessary passphrase prompts.

gcrypt.gpg-args The contents of this setting are passed as arguments to gpg. E.g. --use-agent.

remote.<name>.gcrypt-signingkey .. user.signingkey (The latter from regular git configuration) The key to use for signing. You should set user.signingkey if your default signing key is not part of the participant list. You may use the per-remote version to sign different remotes using different keys.

remote.<name>.gcrypt-rsync-put-flags .. gcrypt.rsync-put-flags Flags to be passed to rsync when uploading to a remote using the rsync:// backend. If the flags are set to a specific remote, the global flags, if also set, will not be applied for that remote.

remote.<name>.gcrypt-require-explicit-force-push .. gcrypt.require-explicit-force-push A longstanding bug is that every git push effectively has a --force.

If this flag is set to ``true``, git-remote-gcrypt will refuse to push,
unless ``--force`` is passed, or refspecs are prefixed with ``+``.

There is a potential solution here: https://bugs.debian.org/877464#32

环境变量

GCRYPT_FULL_REPACK When set (to anything other than the empty string), this environment variable forces a full repack when pushing.

示例

如何为两个参与者设置遥控器::

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

如何使用 git 后端::

# notice that the target git repo must already exist and its
# `next` branch will be overwritten!
git remote add gitcrypt gcrypt::[email protected]:repo#next
git push gitcrypt master

URL 片段（此处为“#next”）指示使用哪个后端分支。

注释

协作 The encryption of the manifest is updated for each push to match the participant configuration. Each pushing user must have the public keys of all collaborators and correct participant config.

依赖关系 rsync, curl and rclone for remotes rsync:, sftp: and rclone: respectively. The main executable requires a POSIX-compliant shell that supports local.

GNU 隐私卫士 Both GPG 1.4 and 2 are supported. You need a personal GPG key. GPG configuration applies to algorithm choices for public-key encryption, symmetric encryption, and signing. See man gpg for more information.

远程 ID The Remote ID is not secret; it only ensures that two repositories signed by the same user can be distinguished. You will see a warning if the Remote ID changes, which should only happen if the remote was re-created.

性能 Using an arbitrary <giturl> or an sftp:// URI requires uploading the entire repository history with each push. This means that pushes of your repository become slower over time, as your git history becomes longer, and it can easily get to the point that continued usage of git-remote-gcrypt is impractical.

Thus, you should use these backends only when you know that your
repository will not ever grow very large, not just that it's not
large now.  This means that these backends are inappropriate for
most repositories, and likely suitable only for unusual cases,
such as small credential stores.  Even then, use `rsync://` if you
can.  Note, however, that `rsync://` won't work with a repository
hosting service like Gitolite, GitHub or GitLab.

rsync URIs The URI format for the rsync backend is rsync://user@host/path, which translates to the rsync location user@host:/path, accessed over ssh. Note that the path is absolute, not relative to the home directory. An earlier non-standard URI format is also supported: rsync://user@host:path, which translates to the rsync location user@host:path

克隆后端 In addition to adding the rclone backend as a remote with URI like gcrypt::rclone://remote:subdir, you must add the remote to the rclone configuration too. This is typically done by executing rclone config. See rclone(1).

The rclone backend is considered experimental and is for early
adoptors only.  You have been warned.

存储库格式 .................

| 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 密钥环获取清单、解密和验证 → (B, L, R) | 如果 R 与之前看到的远程 ID 不匹配，则发出警告 | 对于 L 中的每个 Hi, Ki： | 从服务器获取文件 Hi → P' | 验证 Hash(P') 是否与 Hi 匹配 | 使用 Ki → P 解密 P' 然后用 git 打开 P

清单文件 .............

示例清单文件（为简洁起见，省略号）：：

$ 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 object id and its ref

pack :<hashtype>:<hash> <key> Packfile hash (Hi) and corresponding symmetric key (Ki).

keep :<hashtype>:<hash> <generation> Packfile hash and its repack generation

repo <id> The remote id

extn <name> ... Extension field, preserved but unused.

检测 gcrypt 存储库

要检测 git url 是否是 gcrypt 存储库，请使用：“git-remote-gcrypt --check url” 如果存储库存在并且可以解密，则退出状态为 0；如果存储库存在，则退出状态为 1 使用 gcrypt 但无法解密，如果存储库不是，则为 100 使用 gcrypt 加密（或无法访问）。

请注意，这必须将存储库内容提取到本地 git 中 存储库，与使用 gcrypt 存储库时的操作相同。

已知问题

每个 git 推送实际上都有“--force”。 之前一定要拉 推动。

git-remote-gcrypt can decide to repack the remote without warning, 这意味着您的推送可能会突然花费比 您正在期待，因为您的整个历史记录都必须重新上传。 此推送可能会因链接不良而失败。

git-remote-gcrypt might report a repository as "not found" when the 存储库实际上确实存在，但 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 生成一个手册页 .. vim: ft=rst tw=72 sts=4