GitLab发现了一个严重的漏洞，可以让任何验证的身份登录其他用户的账户，包括管理员账户。这个漏洞在GitLab8.2版本中被发现，该漏洞提供了一个“冒充”的功能，可以让管理员冒充其他用户登录。
这个漏洞影响到了GitLab8.2.0至8.7.0版本。GitLab工程师Douwe Maan称这个漏洞是他们至今为止他们遇到的最麻烦的漏洞。
除了提供补丁版本的软件，GitLab还揭露了几种方法，可以通过改变web服务器、代理服务器的配置，或是给ruby文件打补丁来进行补丁安装。例如，对于使用Apache web服务器的用户，漏洞修复需要按照以下的规则进行：[code]
Order Deny,Allow
Deny from all
通过notes API提升权限，可以在合并请求、片段以及用户不能访问到的问题提交notes。
通过project webhook API提升权限，可以让通过验证的用户在个人项目中读取删除webhooks。
几个XSS漏洞以及其他可以导致信息泄露的问题。
InfoQ和GitLab工程副总裁Stan Hu进行了对话，了解到更多关于这次漏洞宣布和GitLab对这个问题的解决方法。
你可以简短地介绍一下最近公布的GitLab漏洞所产生的影响吗？
根据我们所了解到的，目前还没有什么公开性的影响。这些漏洞都在代码审查环节被GitLab的员工和安全研究人员所发现。
GitLab经常揭露一些漏洞，并对它们遵循一种开放政策。这本身就是一个很大的加分，但有些人担心GitLab中漏洞的数量很多，并且经常能被发现。你可以就此发表一下评论吗？
GitLab将持续公开安全漏洞问题。我们最优先修复安全方面的问题，每次我们收到漏洞报告的时候我们都试图可以尽快解决它。我们有数以百计的贡献者，无论是工作人员还是志愿者每天都在检查代码。
我们每个月都会发布一个新的版本提供一些新功能，修复一些错误。我们整体代码质量很高，我们尽最大努力来检查每一行代码，并进行完整的测试。我们邀请到一些网站比如说HackerOne的安全研究人员来帮助我们识别出GitLab中潜在的问题。与专有软件不同，开源项目意味着我们需要公开我们的安全问题。
可以介绍一下从首次发现漏洞到补丁发布的整个过程吗？
当我们发现CVE-2016-4340时，我们花了大约一小时进行了内部修复。我们首先给GitLab.com打补丁并迅速在私有仓库中将一些补丁移植到所有受影响的版本中去。通过e-mail和我们的博客，我们会告诉客户和公众安全更新的时间（5月2日23:59
UTC，礼拜一），让大家能准备好进行更新。我们和本地包的维护者共享补丁（例如Debian,、FreeBSD等等），他们都很感谢我们可以事先告知。在5月2日礼拜一，我们发布GitLab包更新，并在博客上详细介绍不能进行更新的用户的解决方案。我们发布CVE
和MITRE的所有细节。我公开揭露了所有与漏洞相关的代码和问题。
软件详情：https://github.com/gitlabhq/gitlabhq/releases
来自:开源中国社区