有加密版本控制系统吗？

Question

我正在寻找加密版本控制系统。基本上我想

• 在发送到服务器之前，将所有文件加密本地。服务器永远不应接收任何未加密的文件或数据。

• 其他所有功能的工作方式与SVN或CVS今天的工作方式基本相同。

任何人都可以推荐这样的东西吗？我做了很多搜索，但我找不到任何东西。

Answer 1

您应该加密数据管道（ssl / ssh），并保护对服务器的访问。加密数据将迫使SVN将所有内容视为二进制文件。它不能做任何差异，所以它不能存储增量。这违背了基于三角洲的方法的目的 您的存储库将变得非常快，非常快。如果您上传一个100kb的文件，然后再更改1个字节并再次签入，那么再执行8次（总共10转），存储库将存储10 * 100kb，而不是100kb + 9个小增量（让我们称之为101kb）。

更新：@TheRook解释说可以使用加密存储库进行增量。所以有可能这样做。但是，我最初的建议是：它不值得麻烦，你最好加密ssl / ssh管道并保护服务器。即“最佳实践”。

Answer 2

可以创建密文的版本控制系统。使用诸如RC4-drop1024或AES-OFB模式的流密码是理想的。只要每个修订使用相同的键+ iv。这意味着每次都会生成相同的PRNG流，然后与代码进行异或。如果任何单个字节不同，那么您将不匹配，并且密码文本将自动合并。

也可以使用ECB模式的分组密码，其中最小的不匹配大小为1个块，因此使用小块是理想的。另一方面，CBC模式可以为每个修订产生广泛不同的密文，因此是不可取的。

我认识到这不是很安全，OFB和ECB模式通常不应该使用，因为它们比CBC模式弱。 IV的牺牲也是不希望的。此外，还不清楚正在捍卫什么样的攻击。使用像SVN + HTTPS这样的东西很常见也很安全。我的帖子只是声明可以有效地做到这一点。

Answer 3

为什么不在加密文件系统上设置repo（subversion，mercurial等），并仅使用ssh进行连接？

Answer 4

Use rsyncrypto将文件从明文目录加密到加​​密目录，并使用您保存在本地的密钥解密加密目录和纯文本目录中的文件。

使用您喜欢的版本控制系统（或任何其他版本控制系统 - svn，git，mercurial等）在您的加密目录和远程主机之间进行同步。

您现在可以从Sourceforge下载的rsyncrypto实现不仅可以处理字节更改，还可以处理插入和删除。 它实现了一种非常类似于“The Rook”提到的方法的方法。

纯文本文件中的单字节插入，删除和更改通常会导致rsyncrypto在该文件的加密版本中的相应点周围生成几K个完全不同的加密文本。

Chris Thornton指出ssh是一个好的解决方案; rsyncrypto是一个非常不同的解决方案。权衡是：

• 使用rsyncrypto需要为每个“微不足道的”更改传输几个K而不是使用ssh（或在未加密的系统上）传输的半个K.所以ssh稍微快一点，并且需要比rsyncrypto稍微少一点的“diff”存储空间。
• 使用ssh和标准VCS要求服务器（至少暂时）拥有密钥并解密文件。使用rsyncrypto，所有加密密钥都不会离开本地计算机。所以rsyncrypto稍微安全一些。

Answer 5

您可以使用Tahoe-LAFS网格来存储文件。由于Tahoe被设计为分布式文件系统，而不是版本控制系统，因此您可能需要在文件系统之上使用另一种版本控制方案。

编辑：这是使用Tahoe-LAFS as the backend storage for Mercurial的原型扩展。

Answer 6

SVN内置支持安全传输数据。如果您使用svnserve，则可以使用ssh安全地访问它。或者，您可以使用https通过apache服务器访问它。详情见svn documentation。

Answer 7

你有什么具体的防范措施？

使用Subversion ssh或https进行repo访问。在客户端上使用加密的文件系统。

Answer 8

看看GIT。它支持可能完成这项工作的各种钩子。请参阅git encrypt/decrypt remote repository files while push/pull。

Answer 9

你有没有想过使用Duplicity？它就像rdiff-backup（增量备份）但加密了？不是真正的版本控制 - 但也许你想要所有酷炫的差异，但不想与其他人合作。 或者，只需从本地Truecrypt存档推送/拉出并将其同步到远程位置即可。 rsync.net对两者都有很好的描述 - http://www.rsync.net/resources/howto/duplicity.html http://www.rsync.net/products/encrypted.html - 显然Truecrypt容器仍然很好。

Answer 10

变体A

使用分布式VCS并通过加密链接直接在不同客户端之间传输更改。在这种情况下，没有可攻击的中央服务器。

例如，使用mercurial，您可以使用内部Web服务器，并通过VPN连接客户端。或者，您可以捆绑更改集并使用加密邮件进行分发。

变体B

您可以通过网络导出加密的硬盘分区并将其安装在客户端，并在客户端运行VCS。但这种方法存在很多问题，例如：

• 当两个不同的客户端同时尝试访问VCS时可能会丢失数据
• 必须保护链接本身免受欺诈性写访问（当通过NFS共享分区时，很可能以任何人都可以写入共享分区的配置结束，所以即使其他人无法读取内容，很容易破坏内容的一个漏洞）

变体B可能还有其他问题，所以忘记变体B.

变体C

与Jaeger写的@Commodore一样，在AFS之类的加密感知网络文件系统之上使用VCS。

Answer 11

与上面的一些评论类似，一个有用的解决方法可能是在本地加密和压缩整个存储库并将其与远程框同步。例如。使用git时，整个存储库存储在项目目录中的目录“.git”中。

• zip /加密整个项目目录
• 将其上传到服务器（不确定单独处理.git是否足够）
• 在继续处理项目之前，请先下载此存档
• 解密/解压缩并与git（本地）同步

这可以通过更简单的shell行脚本来完成。

pro：您可以使用任何适当的加密以及支持本地存储库的每个VCS。

缺点：当几个人想要上传他们的代码库（合并情况）时，显然缺少一些VCS功能 - 尽管也许这可以通过避免远程覆盖和本地合并来解决（介绍锁定，这是噩梦开始的地方）

然而，这个解决方案是一个黑客，而不是一个合适的解决方案。

Answer 12

Source safe将数据存储在加密文件中。等等，我把它拿回来。他们被混淆了。除了混淆的前门之外，没有其他安全措施。

来吧，这是星期一。

Answer 13

根据我的理解，这是无法做到的，因为在SVN和其他版本控制系统中，服务器需要访问明文才能执行版本控制。