git git在推/拉时加密/解密远程存储库文件

git encrypt/decrypt remote repository files while push/pull

提问by UncleMiF

Is it possible to automatically encrypt files via 'git push' before transferring to a remote repository? And automatically decode them while 'git pull'.

在传输到远程存储库之前，是否可以通过“git push”自动加密文件？并在“git pull”时自动解码它们。

I.e, if I have some remote server with shared access with git repository there, and I don't want our project to be stolen without a permission... Maybe there is some special git-hooks before push and after pull?

即，如果我有一些远程服务器与那里的 git 存储库共享访问权限，并且我不希望我们的项目在未经许可的情况下被盗......也许在推前和拉后有一些特殊的 git-hooks？

采纳答案by VonC

Yes and no.

是和否。

You could try to depend on hook but that supposes they are installed at the remote locations, and that is not always reliable.

您可以尝试依赖 hook，但假设它们安装在远程位置，这并不总是可靠的。

Another way to achieve almost the same effect would be by using a smudge/clean attribute filter driver, but not for a full repo.

实现几乎相同效果的另一种方法是使用smudge/clean 属性过滤器驱动程序，但不适用于完整的 repo。

^{(Source: Pro Git book: Customizing Git - Git Attributes)}

^{（来源：Pro Git 书籍：自定义 Git - Git 属性）}

That way the smudge script is able decode the files, while the clean script would encode them.
Again, that could work for a few sensitive files, not for a full repo.

这样，涂抹脚本就能够解码文件，而干净的脚本会对它们进行编码。
同样，这可能适用于一些敏感文件，而不适用于完整的 repo。

Off course, those scripts would not be in the repository itself, and would be managed/communicated by another way.

当然，这些脚本不会在存储库本身中，而是通过另一种方式进行管理/通信。

As Alkalinepoints out in the comments, that idea does not scale for a repo, as the main git maintainer Junio C. Hamano comments back in 2009:

正如Alkaline在评论中指出的那样，这个想法不能扩展到 repo，正如主要的 git 维护者Junio C. Hamano 在 2009 年评论的那样：

As the sole raison d'etre of diff.textconvis to allow potentially lossy conversion (e.g. msword-to-text) applied to the preimage and postimage pair of contents (that are supposed to be "clean") before giving a textual diff to human consumption.

The above config may appear to work, but if you really want an encrypted repository, you should be using an encrypting filesystem.
That would give an added benefit that the work tree associated with your repository would also be encrypted.

唯一存在的理由diff.textconv是允许在向人类消费提供文本差异之前，将潜在的有损转换（例如，msword-to-text）应用于原图像和后图像内容对（应该是“干净的”）。

上面的配置可能看起来有效，但如果你真的想要一个加密的存储库，你应该使用加密文件系统。
这将带来额外的好处，即与您的存储库关联的工作树也将被加密。

---

---

Even though it does not scale to a full repo, the idea was implemented (3 years later in 2013) with git-crypt, as detailed in Dominic Cerisano's answer.
git-cryptuses a content filter driver(implemented in cpp, with commands.cppsetting up your .gitattributeswith the relevant smudgeand cleanfilter commands).
As any content filter driver, you can then limit the application of git-cryptto the set of files you want, in the same .gitattributesfile:

即使它没有扩展到完整的回购，这个想法还是实现了（3 年后的 2013 年）git-crypt，如Dominic Cerisano的回答中所详述。
git-crypt使用内容过滤器驱动程序（在 cpp 中实现，使用相关和过滤器命令commands.cpp设置您.gitattributes的）。 作为任何内容过滤器驱动程序，您可以将应用程序限制为您想要的文件集，在同一文件中：smudgeclean
git-crypt.gitattributes

secretfile filter=git-crypt diff=git-crypt
*.key filter=git-crypt diff=git-crypt

As mentioned in the README:

如中所述README：

git-cryptrelies on git filters, which were not designed with encryption in mind.

As such, git-cryptis not the best tool for encrypting most or all of the files in a repository.
Where git-cryptreally shines is where most of your repository is public, but you have a few files (perhaps private keys named *.key, or a file with API credentials) which you need to encrypt.

For encrypting an entire repository, consider using a system like git-remote-gcryptinstead.

git-crypt依赖于 git 过滤器，这些过滤器在设计时并没有考虑到加密。

因此，git-crypt它不是加密存储库中大部分或所有文件的最佳工具。
凡git-crypt真正的亮点是大多数存储库中是公开的，但你有几个文件（或许私钥命名*.key，你需要加密，或者API凭证的文件）。

要加密整个存储库，请考虑使用类似的系统git-remote-gcrypt。

(see more at spwhitton/ tech/ code/ git-remote-gcrypt, from Sean Whitton)

（在spwhitton/tech/code/git-remote-gcrypt 中查看更多信息，来自Sean Whitton）

回答by Lluís

You can take a look at this project: https://github.com/shadowhand/git-encrypt

你可以看看这个项目：https: //github.com/shadowhand/git-encrypt

UPDATE: This above project is deprecated and recommends using https://github.com/AGWA/git-crypt

更新：以上项目已弃用，建议使用https://github.com/AGWA/git-crypt

回答by Dominic Cerisano

How to secure public and private remote assets using git-crypt.

如何使用git-crypt保护公共和私有远程资产。

• Transparent to all git clients and services (eg. GitHub, BitBucket, etc).
• Linux, OSX and Windows support.
• Asset levelencryption (see VonC's answer).
• AES-256cipher.
  
  

• 对所有 git 客户端和服务（例如 GitHub、BitBucket 等）透明。
• 支持 Linux、OSX 和 Windows。
• 资产级加密（参见VonC 的回答）。
• AES-256密码。
  
  

Createyour 256 bit private key (RETAIN AND PROTECT THIS KEY)

创建您的 256 位私钥（保留并保护此密钥）

sudo apt install git-crypt 
mkdir key; cd key;
git init; git-crypt init
git-crypt export-key ~/crypt.key

Pusha file called .gitattributesto each repo's root directory.
It should contain one asset pattern per file, directory or type you wish to encrypt:

将调用的文件推.gitattributes送到每个 repo 的根目录。
它应该为每个要加密的文件、目录或类型包含一个资产模式：

docs/doc.txt  filter=git-crypt diff=git-crypt
js/**         filter=git-crypt diff=git-crypt
*.java        filter=git-crypt diff=git-crypt
src/cpp/*.h   filter=git-crypt diff=git-crypt

Encryptassets in each repo:

加密每个 repo 中的资产：

cd repo-root-directory
git-crypt unlock ~/crypt.key
git-crypt status -f
Push (from command line or git client)

Continueyour git workflow as usual.

像往常一样继续你的 git 工作流程。

• Run git-crypt unlock ~/crypt.keyonceon any new clones of these secured repos.
• You may wish to purge old unencrypted commit histories on all branches and tags.
• If you use a git client, it must fully support git filters and diffs.
  
  
  

• 在这些安全存储库的任何新克隆上运行git-crypt unlock ~/crypt.key一次。
• 您可能希望清除所有分支和标签上旧的未加密提交历史记录。
• 如果您使用 git 客户端，它必须完全支持 git 过滤器和差异。
  
  
  

回答by user2851586

There are two ways to do this.

有两种方法可以做到这一点。

One is to use a project like git-crypt, http://www.agwa.name/projects/git-crypt/which adds in fiters to pull and push process, or set up the filters manually as described here https://gist.github.com/shadowhand/873637

一种是使用像 git-crypt 这样的项目， http://www.agwa.name/projects/git-crypt/ 它添加了过滤器来拉取和推送过程，或者按照这里的描述手动设置过滤器 https:// gist.github.com/shadowhand/873637

Another way if you are working in a linux environment, is to use ecryptfs. For this scenario, in base of your project directory you could, for example, create two directories

如果您在 linux 环境中工作，另一种方法是使用 ecryptfs。对于这种情况，例如，您可以在项目目录的基础上创建两个目录

project/encrypted_src

project/src

Then from the root of the project directory you would mount using the command

然后从项目目录的根目录使用命令挂载

sudo mount -t ecryptfs encrypted_src src

entering a pass-phrase and accepting the defaults when prompted. At this point, files placed in src/ will be encrypted into encrypted_src/ on the fly. When you are finished just

输入密码短语并在提示时接受默认值。此时，放置在 src/ 中的文件将被动态加密到 encrypted_src/ 中。当你完成时

sudo umount src

and only the encrypted files remain. Essentially files are committed and pushed from encrypted_src/ and edited in src. As long as everyone uses the same pass-phrase (or mounts with the same key) the repo can be shared among developers. Also you can get fancier. You can encrypt file names as well as just file contents, or encrypt different folders in a repo with different pass-phrases or keys. The last feature is nice if you have configuration files with sensitive access information that individual groups (dev, test, production) will want to maintain privately.

并且只保留加密文件。基本上文件是从 encrypted_src/ 提交和推送的，并在 src 中编辑。只要每个人都使用相同的密码（或使用相同的密钥挂载），就可以在开发人员之间共享存储库。你也可以变得更漂亮。您可以加密文件名以及文件内容，或者使用不同的密码短语或密钥加密存储库中的不同文件夹。如果您的配置文件包含个人组（开发、测试、生产）想要私下维护的敏感访问信息，那么最后一个功能非常有用。

That said, though, be aware that once you start encrypting stuff. You loose a lot of the advantages of source control like being able to see diffs between various commits. If you have a project of any size the ability to review commits will be invaluable. If you expect bugs, at some point or another, the ability to analyse and find their point of introduction by back tracking through commit history will also be invaluable. So secure your server first and then use encryption only where in makes sense to protect sensitive info in source control. Just my 2 cents.

尽管如此，请注意，一旦您开始加密内容。您失去了源代码控制的许多优点，例如能够查看各种提交之间的差异。如果你有一个任何规模的项目，提交的能力将是无价的。如果您期望在某个时间点出现错误，通过提交历史回溯来分析和找到它们的引入点的能力也将是无价的。因此，首先保护您的服务器，然后仅在对保护源代码控制中的敏感信息有意义的地方使用加密。只有我的 2 美分。

回答by Jeff Burdges

There are Tahoe-LAFS hooks provided by git-annex, which admittedly might be more complicated than you need.

git-annex提供了 Tahoe-LAFS 钩子，诚然，它可能比您需要的更复杂。