git在推/拉时加密/解密远程存储库文件 [英] git encrypt/decrypt remote repository files while push/pull

问题描述

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

即使我有一些具有git存储库的共享访问的远程服务器，我也不希望我们的项目被盗未经许可...
也许在推和拉之前有一些特殊的git-hook？

解决方案

是的和否。

你可以尝试依靠钩子，但是假设它们安装在远程位置，并不总是可靠的。

实现几乎相同效果的另一种方法是使用 ：自定义Git - Git属性）

这样，smudge脚本可以解码文件，而clean脚本会对它们进行编码。

再次，这可能适用于几个敏感文件，不是一个完整的回购。

当然，这些脚本不会在存储库本身，并以其他方式进行管理/传播。

由于碱性指出在评论中，这个想法不会为repo扩大，作为主要的git维护者 Junio C. Hamano在2009年回顾：

由于 diff.textconv 的唯一存在理由是允许潜在的有损
转换（例如，msword到文本）应用于preimage和postimage
对内容（应该是干净），然后给一个文本
diff给人消费。

上述配置可能会起作用，但如果您真的想要加密存储库，则应该使用加密文件系统。

这将给出额外的好处，与您的存储库关联的工作树
也将被加密。

---

即使它没有扩展到完整的回购，这个想法是在 git-crypt ，详见 Dominic Cerisano 的回答。

git-crypt 使用内容过滤器驱动程序（在cpp中实现，使用 commands.cpp 将 .gitattributes 与相关的 smudge 和清理过滤器命令）。

作为任何内容过滤器驱动程序，您可以将 git-crypt 的应用程序限制为您需要的文件集，位于相同的 .gitattributes 文件中：

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

作为 README ：

git-crypt 依赖于git过滤器，它不是设计加密
的。

因此， git-crypt 不是加密大部分或
的最佳工具存储库中的文件。

其中 git-crypt 真正闪耀是大部分存储库是公开的，但您有几个文件（也许是私钥命名为 *。key 或具有API凭据的文件）。

对于加密整个存储库，请考虑使用系统，如 git-remote-gcrypt 。




Is it possible to automatically encrypt files via 'git push' before transferring to a remote repository? And automatically decode them while '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?

解决方案

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.

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

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

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.

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

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

As the sole raison d'etre of diff.textconv is 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.

---

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-crypt uses a content filter driver (implemented in cpp, with commands.cpp setting up your .gitattributes with the relevant smudge and clean filter commands).
As any content filter driver, you can then limit the application of git-crypt to the set of files you want, in the same .gitattributes file:

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

As mentioned in the README:

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

As such, git-crypt is not the best tool for encrypting most or all of the files in a repository.
Where git-crypt really 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-gcrypt instead.

这篇关于git在推/拉时加密/解密远程存储库文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！