有加密版本控制系统吗?

Dez*_*zue 44 svn security encryption version-control

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

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

  • 其他所有功能的工作方式与SVN或CVS的功能几乎完全相同.

任何人都可以推荐这样的东西?我做了很多搜索,但我找不到任何东西.

Chr*_*ton 47

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

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

  • 我当时认为增量可以在客户端计算并发送回服务器加密. (8认同)
  • @Mike - 但后来1000转,现在你想要检查当前的情况.服务器必须为您提供原始和1000个增量,并让客户端重新组装它们.听起来像一团糟.并且服务器不知道事情是否一致或搞砸了. (4认同)
  • @Mike:在这种情况下你没有VCS,你有一个远程备份. (2认同)

roo*_*ook 16

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

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

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


Joh*_*don 12

为什么不在加密文件系统上设置repo(subversion,mercurial等),并仅使用ssh进行连接?

  • 如果服务器遭到入侵,你无论如何都会被搞砸. (21认同)
  • 如果数据已加密并且正确备份受损服务器,则不会导致敏感数据丢失. (10认同)
  • 如果服务器遭到破坏,当用户会话通过SSH连接时潜在的攻击者是否能够读取数据?我的印象是数据在RAM中未加密存在. (3认同)
  • 从理论上讲,这就是加密文件系统的功能. (3认同)

Dav*_*ary 10

使用rsyncrypto将文件从明文目录加密到加​​密目录,并使用本地保存的密钥解密加密目录和纯文本目录中的文件.

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

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

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

克里斯桑顿指出,ssh是一个很好的解决方案; rsyncrypto是一个非常不同的解决方案.权衡是:

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


Com*_*ger 5

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

编辑:这是一个原型扩展,使用Tahoe-LAFS作为Mercurial的后端存储.


Cla*_*och 5

SVN内置支持安全传输数据.如果您使用svnserve,则可以使用ssh安全地访问它.或者,您可以使用https通过apache服务器访问它.这在svn文档中有详细说明.