将SVN项目直接签出到生产站点会有多大的安全风险?

只要服务器禁止从Web访问所有.svn目录,就没有。

我不一定要对涉及的安全风险发表评论,但它可能会使您陷入一种未经审查/未完全测试的代码最终进入生产环境的境地。如果您考虑使用SVN作为将源代码分发到不同环境(开发、测试、生产等)的方法,我建议您采用以下方法:

有一部分树保持稳定(很可能是树枝),并使之成为某个人的责任,作为门守卫的分支。所有对“稳定”的承诺都必须通过它们,它们将负责确保没有验证什么都不会进入。如果没有人愿意这么做很长时间,这个职位可以每周或每月轮换一次。

此外,如果您只想定期从Subversion到Production执行临时转储,那么可以使用“svn export”命令。

最后,我猜这是Web开发,如果您只需要签出来设置生产环境的话。如果是这种情况,请确保运行Web服务器的用户对存储Subversion元数据的“.svn”目录没有读取权限。

我根本不认为这是一种安全风险或坏做法。它非常方便,当然,我可能会在未来的项目中做一些事情。

例如,Capistrano(一个Rails自动部署解决方案)是围绕将代码从SVN签出到生产服务器而构建的。

有些愚蠢的事情你可以做,这可能使它成为一个坏的做法,但他们都很容易缓解。例如:

1. 在没有密码保护的情况下将您的SVN repo公开到Web上-不要这样做!

2. 使用HTTP而不是HTTPS公开您的SVN repo,这样嗅探您的流量的人就可以获得您的密码——同样,不要这样做!只需通过https运行。

3. 使用具有SVN读/写访问权限的帐户签出代码。就我个人而言,我不会担心这最后一步,就好像它们会危害到您的生产服务器一样,您有更大的问题,您可以轻松地回滚它们可能试图提交给SVN的任何更改。如果你非常偏执,你可以做一个只读的SVN帐户用于生产结帐。

4. 将主干签出到生产环境-这只是在使用不稳定的主干运行时出现的一个问题,您只需签出稳定的分支/标记即可进行部署。

已经有了一些很好的答案。但让我试着以某种方式量化风险。

假设 2个月前 ,特洛伊木马的风险很小,可以接受。沿着来 Kaminsky's DNS 攻击和preto特洛伊木马的风险刚刚从理论上的主动攻击上升到“脚本孩子”领域的某个东西。这是因为大多数公共Subversion项目要么使用HTTP,要么使用HTTPS,它们不使用具有完整证书链的证书。然后,对手所需要做的就是毒害DNS并用自己的特洛伊木马克隆SVN服务器。

好吧,如果您要签出的代码是基线化的(稳定的),我认为这不是什么问题。

但您当然应该标记代码,以便稍后知道您在那里放置了什么。

可能比从测试服务器复制更安全,至少您确信您得到了所有文件的正确版本,并且复制了所有文件。

如果我们谈论的是应用程序稳定性(或代码),那么在部署期间总是存在风险。

但除此之外,如果您可以使用HTTPS而不是HTTP,那么安全风险是什么?或者甚至使用ssh网关。

我会这样做:

假设:

• 单个根文件夹下的项目 ( 投影仪 )
• 所有受版本控制的文件

步骤

1确保“新”生产版本有标签
2签出或将该标记导出到文件夹中 投影仪 新的
3停止服务
4重命名 投影仪 老& lt;& lt; 投影仪 & lt; 投影仪 新的
5重新启动服务
6如果您需要后退,请反向执行步骤4。

推理

这是为了使实际的实现和回退步骤尽可能基本。你 能够 只需使用svn开关,但任何后退的问题都可能导致系统损坏。

显然,这是最简单的可能情况——没有数据迁移,没有未版本化的配置文件,等等;但是我认为关键在于构建一个复制树,然后交换,给您一个干净、清晰的切换和回退。

我不一定喜欢将存储库直接签出到部署中的想法。具体来说,是否需要将每个文件(如测试用例)部署到生产环境中?另外,在将来的某个时候,您是否会有任何生成的代码?最好有一个构建系统来构建要部署的分发。

但是,为了代替任何这些决定,请确保记下要同步的存储库的修订版。通过这种方式,同步是可复制的,如果在生产中出现无法复制的错误,您可以将本地存储库同步回与生产一致的状态。

我发现使用SVN非常方便和可靠。我们的策略是保持主干的稳定,并对分支进行非关键性的更改,这些更改稍后在发布日期前不久合并到主干中。

它使发布变得像对较小/不太复杂的项目执行“SVN UP”一样简单。简化部署使非开发人员(sysadmin、随叫随到的支持等)更容易在相关开发人员不可用时快速恢复有问题的更改。如果新版本出现问题,只需回滚到最后一个已知的稳定版本。

我唯一真正关心的是SVN元数据的可见性。确保已将Web服务器设置为拒绝访问.svn目录(以及其中包含的所有文件)。您可以使用SVN导出,或者删除SVN元数据作为发布过程的一部分:查找。-名称.svn-print0 xargs-0 rm-rf

你不想要的是有人浏览www.example.com/.svn/entries,它会显示你的源代码库、用户名和文件。如果你做了一些愚蠢的事情,比如“passwords.conf”,这对用户来说是很糟糕的(取决于服务器配置),当然,这并不是SVN的错。正如其他答案中提到的,您也不想使用HTTP。

简而言之,只要元数据和SVN存储库是安全的,那么我看不到任何缺点,只有好处。