“开源”和“可用源代码”的安全含义是什么？

Question

考虑到围绕电流惨败的TrueCrypt，我受到了来自IT行业当前客户和同行的相当大的批评，因为我一直支持开源模型。这样的批评通常与心血这样的事件之后关于开源模型的优点和失败的对话结合在一起。我试图指出，尽管有许多新闻文章将TrueCrypt贴上开源标签，但在维基百科上发现的来源-可得标签更正确。

与这一区别相关联，我认为拥有可供审查的源代码本质上是安全的，但它不应表明与遵循开放源代码开发模式的项目具有相同的信任级别，包括允许重新分配修改后的工作。虽然我的直觉告诉我，这是一个合理的立场采取，差异是微妙的，我的能力令人信服地沟通是有限的。

除了我的直觉之外，还有更多具体的评估要进行吗？与真正的开源应用程序相比，源代码可用应用程序的相对安全性是否存在可衡量的差异？如果是的话，究竟是什么因素造成了这种情况，这一点是否得到了很好的确定？操作系统开发模型会带来比仅仅发布供评审的代码更安全的代码呢？还是这最终归结为意见？

编辑:具体的软件是否与密码学有关，有什么区别吗？

Answer 1

源代码可用(SA)不同于真正的开放源码(OS)，即没有分叉的权利.这意味着，当SA软件中的安全漏洞被发现后，开发人员拒绝修复它(这并不是出于恶意--可能只是缺乏资源)，用户就没有选择用一个新的团队以新的名称继续项目。

然而，如果发现SA项目中的缺陷并将其公之于众，持续拒绝修复将严重损害SA项目的声誉，并将用户赶出SA项目。

一些OS支持者声称，每个人为OS项目提供补丁的能力都会导致更快的错误修复。然而，这只适用于OS项目的一部分：那些遵循集市发展模式而不是大教堂模式的人。有许多OS项目不接受第三方的非邀约捐款。but修复仍然可以独立提供，这样用户就可以手动应用它，但这是许多管理员和用户回避的维护开销。

因为一个问题而分叉一个项目通常比它的价值更麻烦。我亲眼目睹了几个开源项目的分叉，它们都是叉子两边的一部分。其结果总是损害了两个分支的总体进展，因为开发资源被稀释，基础设施和管理结构不得不重复，用户感到困惑。尽管有任何冲突，试图把一个项目团结在一起通常是有回报的。

Answer 2

可供使用的开源和源代码作为一般类别，在其安全含义上是相同的。关键的好处是能够更快地发现bug/效率低下/漏洞；许多人都能轻松地工作。在实践中，这种好处的价值将根据对项目感兴趣的社区的规模以及查看源代码的人数而有所不同。

关于给出的示例:来自TrueCrypt的消息仅仅表明支持已经停止。至少可以说，提前通知是件好事，但这样的行为并不局限于开源(或可获得的源代码)实体；私营企业一直在停止生产产品。如果他们不经常这样做，例如因为人们付钱给他们提供持续的支持，人们就应该认识到，雇用或以其他方式向开放源码提交人支付继续支持预定停止的产品的费用总是一种可供选择的办法。

持续支持的可用性一直是，而且应该继续是关于特定产品是否适合某一特定任务(开放源码或其他任务)的关键考虑因素。

Answer 3

根据我的经验，这个问题是如此广泛，偏见如此根深蒂固，以至于你可能在浪费时间试图在任何一方争论这个问题。

封闭源项目/组织不会轻易放弃其代码，由独立方进行分析-尽管通常只有在NDA的情况下才会这样做，因此，任何这类分析都可能有很高的样本偏差。然而，这里有一对夫妇：

http://osswatch.jiscinvolve.org/wp/2012/02/28/open-source-matches-proprietary-code-quality/ http://www.uni-bamberg.de/fileadmin/uni/fakultaeten/wiai_lehrstuehle/praktische_informatik/Dateien/Publikationen/ICSOC2013 2013_50_打开_来源_对比_专有_BPEL_Engines.pdf

关于进一步讨论，另见：

http://courses.cs.washington.edu/courses/csep590/05au/whitepaper_转机/开放源码软件%2810%29.pdf http://www.dwheeler.com/secure-class/Secure-Programs-HOWTO/open-source-security.html http://www.onlamp.com/pub/a/security/2004/09/16/open_来源_安全性_myths.html

鉴于有关Truecrypt的事实尚未浮出水面，在争论的任何一方(开源软件并不是RSA、洛克希德-姆尔廷、华盛顿邮报和其他人被黑客攻击的原因)，这几乎不是一个海报孩子。