我是一名系统管理员，负责支持一个开发团队，我们的 Subversion 存储库受与单点登录解决方案绑定的 HTTP 基本身份验证保护。我们还与其他一些团队和子公司共享基础设施。开发人员需要一个可以用来自动写入 SVN 的帐户（例如，自动签入一些生成的脚本，或自动将整个版本发布到目录中），方法是将帐户密码存储在脚本中或使用 SSH 进行无密码登录。
我的一位 IT 同事认为这是一个非常糟糕的想法，我倾向于同意他的观点，这似乎存在非常高的安全风险，无论是恶意的，还是编写糟糕的脚本失控并破坏存储库。然而，越来越多的人、其他团队和子团队不断要求这样做，当我尝试做一些自己的研究时，我找不到任何支持材料来帮助我说服他们，这让我怀疑我是否错了，事情并没有我想象的那么糟糕。
我对这些自动化脚本对我们的存储库构成的潜在安全威胁的看法是否正确？我是否遗漏了其他替代方案或保护措施？如果没有，有人可以指出任何可能帮助我表达观点的支持材料吗？
[编辑] 我忘了提到我们还使用 Jenkins 进行持续集成：http://en.wikipedia.org/wiki/Jenkins_%28software%29
答案1
嗯，允许这些类型的提交的安全风险完全取决于您的存储库的敏感度级别。
由于您正在进行持续集成，因此错误的提交肯定会让您陷入困境……尽管显然有机制可以回滚错误的更改，就像可以手动回滚错误的提交一样快。最终，接受这种风险是一项业务决策。
这取决于脚本的作用，但你肯定可以采取一些降低风险的措施；
- 确保所有自动提交都不是处理开发者的正常账户。你不想那些密码已保存。
- 如果可能的话，您能否限制自动提交的用户仅提交特定文件或目录树？
- 再次，如果可能的话，考虑一个预提交钩子，对来自自动化任务的提交进行一些健全性检查（如果发生任何删除操作或者超过 50 行代码更改，是否阻止提交？） - 这可能会捕获并防止让您担心的那种破坏性提交。
另一方面，如果您的开发人员只是为了避免输入svn commit并实际输入合适的提交消息而这样做，那么绝对应该拒绝他们。