【问题标题】:Deploying a Mercurial Repository to Production - Security Concerns and Tips将 Mercurial 存储库部署到生产环境 - 安全问题和提示
【发布时间】:2011-04-21 12:36:42
【问题描述】:

在我的研究中,我发现一些关于部署在线 PHP 应用程序同时将其“.hg”文件夹或“.svn”文件夹留在生产服务器上的问题。不幸的是,我无法找到一个明确的解释来解释为什么这是一个问题。我想更好地了解这种安全风险。

在我看来,您不希望这些文件夹可见,就像您希望显示 PHP 文件的内容一样。解决方案不是将 Web 服务器配置为不提供“.hg”目录吗?安全问题是否比这更深?我真的不知道。非常感谢您的帮助!

如果有帮助,我想在服务器的生产存储库上保留版本控制的原因如下:

  • 从 Staging 进行更快的部署(相对于每次部署执行新副本)
  • 轻松快速的回滚功能
  • 能够验证生产是否保持不变(通过hg st

欢迎使用替代品。

谢谢!

【问题讨论】:

    标签: php web-applications deployment mercurial security


    【解决方案1】:

    确实,如果可以依赖默认不提供.svn / .hg 目录,那将没有问题。事实上,某人(新蜜蜂/新开发/在糟糕的一天经历过)进行了一些改变,破坏了这些设置,并且“没有出错”并没有注意到保护已经消失。瞧,您的源代码向世界开放,甚至可能存储密码和秘密。并不是说设置得当会出问题,而是稍加修饰,容易掩盖的改动,他们可能会出问题,所以为什么不小心谨慎呢?

    在严格控制的发布过程中,我发现export 某些分支/标签到某些文件夹更容易,并且切换到已通过测试的较新分支/标签只是将文档根从 /path/project/release-123 更改为/path/project/release-124(让切换回release-123 变得同样简单,甚至可能更快,可能需要在那里)。如果您的发布过程包含更多的小更改和错误修复,那么使用导出确实会很痛苦,但在我看来,增加的安全性是值得的。

    在开发服务器上,所有内容都已在 (VPN-)IP 或证书上进行过滤,因此我使用带有版本控制目录的“最新和最好的”主干版本进行检查,没有任何问题。

    编辑:

    Both 如今,Mercurial 和 Subversion 都将数据保存在顶层的单个 .hg/.svn 目录中。由于通常会在大多数文件文档根目录之外(并且文档根目录可能是更下方的子目录)的情况下进行结帐,所以这很好。只需确保您的版本控制目录在文档根目录内的网络服务器可访问的文件夹中,您可以保留签出而不是导出那里没有太多问题。

    【讨论】:

      【解决方案2】:

      我喜欢让我的 DocumentRoot 成为我的 mercurial 存储库的克隆。事实上,您甚至可以使用这样的钩子配置该 repo 以自动更新推送:

      [hooks]
      changegroup = hg update
      

      这意味着您可以hg push 到您服务器上的存储库,您将自动更新站点结帐。很多人都在这样做。

      【讨论】:

      • 听起来很有趣,尽管它并没有真正回答问题。
      • 这不是一个真正的问题。他说为什么不,我说做吧。
      • 使用相同的方法,您可以使用“hg 存档”(导出)更改组挂钩。
      • 绝对正确。更新的优点是不会重新创建未更改的文件,但存档可以保证您干净地结帐。
      【解决方案3】:

      除了差异文件被意外提供给客户端的风险之外,我没有看到任何其他安全问题。

      考虑到您限制对 .svn、.hg 或其他文件的访问。您在那里拥有这些文件夹的事实导致您必须不断地对它们实施限制,这是有风险的。人为错误确实会发生。

      问候,阿林

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2020-05-16
        • 2011-08-27
        • 1970-01-01
        • 2013-06-24
        • 2012-08-03
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多