有没有encryption的版本控制系统？
我正在寻找一个encryption的版本控制系统。 基本上我想
-
在发送到服务器之前先将所有文件在本地encryption。 服务器不应该接收任何未encryption的文件或数据。
-
每个其他function应该像SVN或CVS今天一样工作。
任何人都可以推荐这样的东西？ 我做了很多search，但我找不到任何东西。
您应该encryption数据pipe道（ssl / ssh），并保护对服务器的访问。 encryption数据将强制SVN将所有内容视为二进制文件。 它不能做任何差异，所以它不能存储增量。 这打破了基于三angular洲的方法的目的。
你的仓库会变得非常快速。 如果你上传一个100kb的文件，然后改变1个字节并再次签入，再做8次（共10转），版本库将存储10 * 100kb，而不是100kb + 9个小的delta（我们称之为101kb）。
更新：@ TheRook解释说，有可能做encryption存储库的增量。 所以有可能做到这一点。 不过，我最初的build议是：这不值得冒昧，而且最好用encryptionssl / sshpipe道和保护服务器。 即“最佳做法”。
可以创build密文的版本控制系统。 使用诸如RC4-drop1024或AES-OFB模式的stream密码将是理想的。 只要每个版本使用相同的密钥+ iv。 这将意味着每次都会生成相同的PRNGstream，然后与代码异或。 如果任何单个字节不同，那么你有一个不匹配的地方，密文自己将被正常合并。
也可以使用ECB模式下的分组密码，其中最小的不匹配将是1个块，所以使用小块是理想的。 另一方面，CBC模式可以为每个修订产生广泛不同的密文，因此是不希望的。
我认识到这不是很安全，OFB和ECB模式通常不应该被使用，因为它们比CBC模式弱。 IV的牺牲也是不可取的。 更进一步，还不清楚是什么攻击被捍卫。 在哪里使用像SVN + HTTPS是非常普遍的，也是安全的。 我的文章只是说，有效地做到这一点是可能的。
为什么不在encryption的文件系统上设置你的repo（subversion，mercurial，无论），只使用ssh连接？
使用rsyncrypto将文件从您的明文目录encryption到您的encryption目录，并使用您保存在本地的密钥对您的encryption目录和明文目录中的文件进行解密。
使用您最喜欢的版本控制系统（或任何其他版本控制系统 – svn，git，mercurial，无论）在您的encryption目录和远程主机之间进行同步。
您现在可以从Sourceforge下载的rsyncrypto实现不仅能处理字节的变化，还能处理插入和删除操作。 它实施的方法与“The Rook”提到的方法非常相似。
纯文本文件中的单字节插入，删除和更改通常会导致rsyncrypto在该文件的encryption版本的相应点周围形成几个完全不同的encryption文本。
克里斯·桑顿指出，SSH是一个很好的解决scheme; rsyncrypto是一个非常不同的解决scheme。 权衡是：
- 使用rsyncrypto需要为每个“微不足道的”更改传送几个K，而不是使用ssh（或未encryption的系统）所需的半个K。 所以ssh稍微快一点，比rsyncrypto需要稍微less一些“diff”存储。
- 使用ssh和标准VCS要求服务器（至less暂时）拥有密钥并解密文件。 使用rsyncrypto，所有encryption密钥都不会离开本地计算机。 所以rsyncrypto稍微安全一些。
SVN内置了对安全传输数据的支持。 如果您使用svnserve，那么您可以使用ssh安全地访问它。 或者，您可以使用https通过Apache服务器访问它。 这在svn文档中有详细介绍 。
您可以使用Tahoe-LAFS网格来存储您的文件。 由于Tahoedevise为分布式文件系统，而不是版本系统，因此您可能需要在文件系统之上使用另一个版本控制scheme。
编辑：这是一个使用Tahoe-LAFS作为Mercurial的后端存储的原型扩展。
你想要防范什么？
使用Subversion ssh或https进行回购访问。 在客户端上使用encryption的文件系统。
看看GIT。 它支持可能做这个工作的各种各样的钩子。 请参阅git在推/拉时encryption/解密远程存储库文件 。
你有没有想过使用Duplicity？ 这就像rdiff备份（三angular洲备份），但encryption？ 不是真正的版本控制 – 但也许你想要所有的酷比较东西，但不想与其他人一起工作。 或者，只需从本地Truecrypt归档文件中进行推/拉，然后将其rsync同步到远程位置。 rsync.net有一个很好的描述 – http://www.rsync.net/resources/howto/duplicity.html http://www.rsync.net/products/encrypted.html – 显然Truecrypt容器仍然rsync好。
变体A
使用分布式VCS并通过encryption链接在不同客户端之间直接进行传输更改。 在这种情况下是没有可攻击的中央服务器。
例如，mercurial可以使用内部Web服务器，并通过VPN连接客户端。 或者，您可以捆绑更改集并使用encryption的邮件分发它们。
变式B
您可以通过networking导出encryption的硬盘驱动器分区，并将其挂载到客户端，然后在客户端运行VCS。 但是这种方法有很多问题，比如：
- 当两个不同的客户端同时尝试访问VCS时可能会丢失数据
- 链接本身必须防止欺骗性的写入访问（当通过NFS共享分区时，很可能以任何人都可以写入共享分区的configuration结束，所以即使当别人无法读取内容时，有容易破坏内容的洞）
变体B可能还有其他问题，所以忘记变体B.
变体C
就像@Commodore Jaeger所写的，在AFS等encryption感知networking文件系统之上使用VCS。
与上面的一些注释类似，一个有用的解决方法可能是在本地encryption和压缩整个存储库，并将其与远程框同步 。 例如，当使用git时，整个存储库都存储在项目目录中的“.git”目录中。
- zip /encryption整个项目目录
- 将其上传到服务器（不确定是否仅仅处理.git就足够了）
- 在继续工作之前，请先下载这个档案
- 解密/解压缩并与git同步（本地）
这可以通过一个简单的shell行脚本来完成。
亲：您可以使用适当的encryption以及支持本地存储库的每个VCS。
缺点：当几个人想要上传他们的代码库（合并情况）时，显然缺乏一些VCSfunction – 虽然也许可以通过避免远程覆盖和本地合并（这引入locking，这是恶梦开始的地方）
不过，这个解决scheme是一个黑客，而不是一个合适的解决scheme。
源安全地将数据存储在encryption文件中。 等等，我把它收回。 他们混淆了。 除了混淆之外，没有别的安全措施。
来吧，这是星期一。
根据我的理解，这是无法完成的，因为在SVN和其他版本系统中，服务器需要访问明文才能执行版本控制。
