“安全”这个热词：应避免使用还是该更直接了当？
思考一下，如何在你的开源项目中真正定义安全性吧。科技行业以创造“热词”而小有名气，当然，其他行业也是如此。譬如，“故事驱动”和“轻规则”是当下流行的桌游概念，“解构”的汉堡和墨西哥卷饼在高级餐厅颇受欢迎。然而，技术热词的问题在于，它们可能直接影响你的生活。当某人标榜应用程序“安全”，以此来吸引你使用他们的产品，产品实际上是在暗示一种承诺：“安全”的含义就是它是安全的，它值得你的使用与信任。但问题是，“安全”这个词可能指的是许多事情，技术行业常将它用作一个过于泛化的术语，以至于它逐渐失去了实际含义。由于“安全”一词可能含义丰富，也可能一无是处，使用它就需要慎之又慎。事实上，最好是尽量避免使用这个词，取而代之的是，诉诸你真正要表达的东西。当 “安全” 意味着加密有时候，“安全” 会被作为 加密 的非常不明确的简短表述。在这种情况下，“安全” 指的是，对于外部观察者想要窃听你的数据，要经过一定的困难。避免这样表述：“本网站稳如磐石且安全无忧。”听起来很棒？你可能会想象一个拥有多重二次验证、零知识证明数据存储以及坚决的匿名策略的网站。你可以这么说：“本网站承诺有 99% 的在线时间，并且其流量都通过 SSL 进行加密和验证。”这样一来，承诺的含义变得清晰了，同时也明确了实现 “安全” 的方法（即使用 SSL）以及 “安全“ 的作用范围是什么。注意，这里并未对隐私或匿名做出任何明确的承诺。当 “安全” 意味着访问限制有时，“安全” 这个词是指应用程序或设备的访问权限。如果没有明确的解释，“安全” 可能涵盖从无效的“隐蔽即安全”模式，到简单的 htaccess 密码，直到生物识别扫描器等各种概念。避免这样表述：“我们已经为你防护好了系统。”你可以这么说：“我们的系统采用了二步验证法。”当 “安全” 意味着数据存储“安全” 这个词也可以指你的数据在服务器或设备上的储存方法。避免这样表述：“这个设备在数据存储上考虑了安全因素。”你可以这么说：“这个设备利用全盘加密技术来保护你的数据。”当提到远程存储时，“安全” 可能更多指的是谁可以访问存储数据。避免这样表述：“你的数据是安全的。”你可以这么说：“你的数据经过 PGP 加密，仅你持有私钥。”当 “安全” 意味着隐私今天，“隐私” 一词几乎和 “安全” 一样宽泛且模糊。一方面，“安全” 似乎必然就涉及 “隐私”，然而，这仅在 '安全' 有明确定义时才成立。是因为设有密码阻止外人进入所以称之为私有吗？还是因为数据已加密且仅你拥有密钥所以归为私有？又或者，由于存储你数据的厂商除了 IP 地址外对你一无所知，这才算是私有？光是口头声明 “隐私”，就像未经说明就声明 “安全” 一样，是不够的。避免这样表述：“你的数据在我们这里是安全的。”你可以这么说：“你的数据经 PGP 加密，且只有你拥有私钥。我们不需要你的任何个人信息，唯一能识别你的只有你的 IP 地址。”一些网站会声明 IP 地址在日志中保留期限，及非经法律授权绝不向执法部门交出用户数据等诸多承诺。虽然这些并不属于技术 “安全” 的范畴，但它们全都涉及的是信任度，你不能将这些看作是技术规格。明确所说科技是个复杂的话题，极易引发混淆。沟通是至关重要的，虽然有时候简拼和专有名词在某些场合可能管用，但通常来说，讲明白总是比较好的。当你对你的项目的 “安全” 感到自豪，不要只用模糊的词语进行简述。向其他人明确你具体做了什么来保护你的用户，同时也要明确你认为哪些事物已超出你的考量范围，并要经常进行这样的沟通。“安全” 是个好特点，但它的涵盖面过广，所以请勿畏于夸赞自己在某个具体方向上的特别之处。（题图：MJ/b8cc54ee-5556-4106-b9fa-b08539452aa7）via: https://opensource.com/article/22/9/security-buzzword-alternatives作者：Seth Kenlon 选题：lkxed 译者：ChatGPT 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
如何在 C 语言中安全地读取用户输入
getline() 提供了一种更灵活的方法，可以在不破坏系统的情况下将用户数据读入程序。在 C 语言中读取字符串是一件非常危险的事情。当读取用户输入时，程序员可能会尝试使用 C 标准库中的 gets 函数。它的用法非常简单：char *gets(char *string); gets() 从标准输入读取数据，然后将结果存储在一个字符串变量中。它会返回一个指向字符串的指针，如果没有读取到内容，返回 NULL 值。举一个简单的例子，我们可能会问用户一个问题，然后将结果读入字符串中：#include <stdio.h> #include <string.h> int main() { char city[10]; // 例如 "Chicago" // 这种方法很糟糕 .. 不要使用 gets puts("Where do you live?"); gets(city); printf("<%s> is length %ld\n", city, strlen(city)); return 0; } 输入一个相对较短的值就可以：Where do you live? Chicago <Chicago> is length 7 然而，gets() 函数非常简单，它会天真地读取数据，直到它认为用户完成为止。但是它不会检查字符串是否足够容纳用户的输入。输入一个非常长的值会导致 gets() 存储的数据超出字符串变量长度，从而导致覆盖其他部分内存。Where do you live? Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch <Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch> is length 58 Segmentation fault (core dumped) 最好的情况是，覆盖部分只会破坏程序。最坏的情况是，这会引入一个严重的安全漏洞，恶意用户可以通过你的程序将任意数据插入计算机的内存中。这就是为什么在程序中使用 gets() 函数是危险的。使用 gets()，你无法控制程序尝试从用户读取多少数据，这通常会导致缓冲区溢出。安全的方法fgets() 函数历来是安全读取字符串的推荐方法。此版本的 gets() 提供了一个安全检查，通过仅读取作为函数参数传递的特定数量的字符：char *fgets(char *string, int size, FILE *stream); fgets() 函数会从文件指针读取数据，然后将数据存储到字符串变量中，但最多只能达到 size 指定的长度。我们可以更新示例程序来测试这一点，使用 fgets() 而不是 gets()：#include <stdio.h> #include <string.h> int main() { char city[10]; // 例如 "Chicago" puts("Where do you live?"); // fgets 虽好但是并不完美 fgets(city, 10, stdin); printf("<%s> is length %ld\n", city, strlen(city)); return 0; } 如果编译运行，你可以在提示符后输入任意长的城市名称。但是，程序只会读取 size = 10 数据存储到字符串变量中。因为 C 语言在字符串末尾会添加一个空（\0）字符，这意味着 fgets() 只会读取 9 个字符到字符串中。Where do you live? Minneapolis <Minneapol> is length 9 虽然这肯定比 fgets() 读取用户输入更安全，但代价是如果用户输入过长，它会“切断”用户输入。新的安全方法更灵活的解决方案是，如果用户输入的数据比变量可能容纳的数据多，则允许字符串读取函数为字符串分配更多内存。根据需要调整字符串变量大小，确保程序始终有足够的空间来存储用户输入。getline() 函数正是这样。它从输入流读取输入，例如键盘或文件，然后将数据存储在字符串变量中。但与 fgets() 和 gets() 不同，getline() 使用 realloc() 调整字符串大小，确保有足够的内存来存储完整输入。ssize_t getline(char **pstring, size_t *size, FILE *stream); getline() 实际上是一个名为 getdelim() 的类似函数的装饰器，它会读取数据一直到特殊分隔符停止。本例中，getline() 使用换行符（\n）作为分隔符，因为当从键盘或文件读取用户输入时，数据行由换行符分隔。结果证明这是一种更安全的方法读取任意数据，一次一行。要使用 getline()，首先定义一个字符串指针并将其设置为 NULL ，表示还没有预留内存，再定义一个 size_t 类型的“字符串大小” 的变量，并给它一个零值。当你调用 getline() 时，你需要传入字符串和字符串大小变量的指针，以及从何处读取数据。对于示例程序，我们可以从标准输入中读取：#include <stdio.h> #include <stdlib.h> #include <string.h> int main() { char *string = NULL; size_t size = 0; ssize_t chars_read; // 使用 getline 读取长字符串 puts("Enter a really long string:"); chars_read = getline(&string, &size, stdin); printf("getline returned %ld\n", chars_read); // 检查错误 if (chars_read < 0) { puts("couldn't read the input"); free(string); return 1; } // 打印字符串 printf("<%s> is length %ld\n", string, strlen(string)); // 释放字符串使用的内存 free(string); return 0; } 使用 getline() 读取数据时，它将根据需要自动为字符串变量重新分配内存。当函数读取一行的所有数据时，它通过指针更新字符串的大小，并返回读取的字符数，包括分隔符。Enter a really long string: Supercalifragilisticexpialidocious getline returned 35 <Supercalifragilisticexpialidocious > is length 35 注意，字符串包含分隔符。对于 getline()，分隔符是换行符，这就是为什么输出中有换行符的原因。 如果你不想在字符串值中使用分隔符，可以使用另一个函数将字符串中的分隔符更改为空字符。通过 getline()，程序员可以安全地避免 C 编程的一个常见陷阱：你永远无法知道用户可能会输入哪些数据。这就是为什么使用 gets() 不安全，而 fgets() 又太笨拙的原因。相反，getline() 提供了一种更灵活的方法，可以在不破坏系统的情况下将用户数据读入程序。（题图：MJ/4b23132f-8916-42ae-b2da-06fd2812bea8）via: https://opensource.com/article/22/5/safely-read-user-input-getline作者：Jim Hall 选题：lkxed 译者：MjSeven 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
硬核观察 #1020 日本表示版权不适用于 AI 训练
日本表示版权不适用于 AI 训练日本政府最近重申，它不会对用于人工智能培训的数据实施版权。该政策允许人工智能使用任何数据，“无论它是出于非营利还是商业目的，无论它是复制以外的行为，还是从非法网站或其他地方获得的内容”。日本政府认为版权方面的担忧，特别是与动漫和其他视觉媒体有关的担忧，阻碍了该国在人工智能技术方面的进步。消息来源：Technomancers老王点评：关于 AI 和版权，这确实是一个值得思考的领域。如果 AI 只能使用公共数据训练，显然会影响 AI 的结果。现在非英语的训练语料显然要比英语语料少得多，日本的这个做法值得参考。荷兰政府网站必须强制遵守 security.txt 标准荷兰国家政府数字信任中心宣布，荷兰政府网站从 5 月 25 日开始必须强制遵守 security.txt 标准。Web 服务器上的 security.txt 包含了联系信息，允许道德黑客在服务器上发现漏洞之后可以立即联络合适的人去修复，从而减少网络犯罪分子利用漏洞的机会。目前有逾 8.8 万个荷兰域名有 security.txt 文件。消息来源：Postsen老王点评：这种行业规范确实需要国家来推动才好。Reddit 也准备对 API 收费，杀死第三方客户端继 Twitter 之后，Reddit 最近修改了 API 政策，计划对 API 访问收费。开发者发现 Reddit 给出了一份无法接受的报价，5000 万次请求 1.2 万美元，这意味着第三方客户端除了关闭别无选择。当然，Reddit 认为相比 Twitter 的 5000 万推文 4.2 万美元 API 定价要合理的多。和 Twitter 的情况类似，第三方客户端一大优势也是不展示 Reddit 的广告。消息来源：Reddit老王点评：只是计较于第三方客户端占据了本应展示的广告量，却忘记了第三方客户端给生态带来的好处。回音在 ChatGPT 杜撰 了 6 个案例之后，美国得州的一位法官禁止递交 AI 撰写的材料，除非其正确性经过了人类验证。并要求律师递交保证书，证明其递交的文件是人类撰写或经过了人类的审核。
硬核观察 #1001 微软正在研究使 Linux 脚本更安全
微软正在研究使 Linux 脚本更安全在本周的 Linux 安全峰会上，systemd 的创建者 Lennart Poettering 发表了演讲，他在过去的一年中被微软雇佣，他和微软的其它工程师们正在努力提高 Linux 的安全性。微软的工程师发表的演讲介绍了他们如何在 Linux 系统上控制脚本执行的新方法。从新的 open() 标志到新的内核系统调用，他们正在努力让 Linux 系统管理员对未来在 Linux 系统上执行的脚本有更大的控制。消息来源：Phoronix老王点评：这有点讽刺，但事实就是这样。观点：只有云计算供应商才能做好安全工作有专家认为，“旧的论点认为，云计算的利润率最终会使企业内部的 IT 基础设施看起来是更便宜的选择，但却没有预见到一个时代，即安全变得如此困难，只有云计算供应商才能把它做好。”在安全问题上，云计算供应商有一个关键的优势：他们控制、编写和构建了大部分的软件和硬件堆栈。云计算供应商在网络安全方面拥有令人羡慕的记录，这要归功于谷歌之类的云计算供应商的持续补丁等严格的安全实践。消息来源：eSecurity Planet老王点评：虽然云计算供应商也动不动就出些大事故，但一般而言，云计算供应商的安全实践能力要超过普通的 IT 公司。裁员时拥有开源和 Linux 技能比较安全Linux 基金会的调查显示，虽然科技行业进行了几轮裁员，但“开源是与这些趋势反周期的”。事实上，更多的组织计划增加他们的技术人员水平而不是减少。对技术人才的需求仍然强劲，特别是在快速发展的领域，它们都严重依赖开源和 Linux 技术。Linux 基金会发现高级技术职位的裁员幅度最大，新的招聘主要集中在开发人员和 IT 经理。此外，Linux 基金会的研究显示，提高技能（91%）和认证（77%）比大学教育（58%）更重要。消息来源：ZDNet老王点评：也就是说，懂技术还是比较有保障一些。
硬核观察 #970 AI 生成了 “活” 在虚拟世界的 25 个虚拟人
AI 生成了 “活” 在虚拟世界的 25 个虚拟人据最近发表的一篇论文，研究人员利用 ChatGPT 生成了 25 个 “活” 在类似《虚拟人生》游戏里的角色，运用大语言模型存储、合成和应用相关记忆去生成可信行为。观察者可以在这个网页游戏中观察这些角色，查看他们的文字记忆和其他信息。这些角色计划他们的日子、分享新闻、形成关系，并协调团体活动。他们相互沟通，产生了研究人员所描述的“涌现”行为。比如说他们会组成团体参与“市长竞选”，也会组织聚会，并有一些人因为种种原因而没到场。消息来源：The Register老王点评：这些生活在沙盒游戏中的角色，应该并不知道自己只是一个 AI 驱动的角色，或许有一天他们会怀疑。而我们，已经开始怀疑了？谷歌免费推出保障开源软件服务大约一年前，谷歌宣布了其保障开源软件服务，这项服务通过定期扫描和分析一些世界上最流行的软件库的漏洞，帮助开发者防御供应链安全攻击。现在谷歌免费推出了该服务，支持超过 1000 个 Java 和 Python 软件包。谷歌承诺，它将不断保持这些库的更新（不创建分叉），扫描漏洞并修复，然后贡献给上游。谷歌说，在首次推出 250 个 Java 库的服务时，它发现并修复了这些库的 48% 的新 CVE 漏洞。消息来源：Tech Crunch老王点评：这件事上，谷歌功莫大焉！DDoS 攻击转向利用 VPS 以提高威力Cloudflare 称，较新的一代僵尸网络逐渐放弃了建立由单独的弱小物联网设备组成的大群的战术，现在正转向利用泄露的 API 凭证或已知的漏洞奴役脆弱和配置错误的 VPS 服务器。这种方法有助于威胁者更容易、更迅速地建立高性能僵尸网络，其强度可达基于物联网的僵尸网络的 5000 倍。消息来源：Bleeping Computer老王点评：蜂群战术换成了僵尸大军，就问你怕不怕。
德国法院裁定 Youtube-DL 的托管商败诉德国法院已经命令托管服务商 Uberspace 将开源的 YouTube-DL 软件的网站下线。该裁决是由索尼、华纳和环球公司去年提起的版权侵权诉讼的结果，他们称，“YouTube-DL 的服务使用户可以在不付费的情况下翻录流媒体和下载受版权保护的音乐。”。Uberspace 将对判决提出上诉，他们认为，“该命令实际上相当于对 YouTube-DL 的全面禁止，没有考虑到该软件的潜在合法用途。”与此同时，Youtube-DL 的代码仍然可以在 GitHub 上找到。需要提及的是，原始版本的 YouTube-DL 在 GitHub 上的最后一个发布版本是 2021 年底发布的。而一些复刻版本还在继续活跃。消息来源：Torrent Freak老王点评：不知道下一步这个压力是否就会转移到 GitHub，比如不允许发布构建版本。斯坦福大学发布人工智能状况报告虽然现在人工智能发展之快，让任何与人工智能有关的报告一发布就面临过期的风险，但是我们仍然能从这份 386 页的 报告 中得到一些有用的信息：在过去的十年里，人工智能的发展已经从学术界主导翻转到了工业界主导，而且这没有改变的迹象。在传统基准上测试模型正变得困难，这里可能需要一种新的模式。人工智能训练和使用的能源占用正在变得相当大，但我们还没有看到它如何在其他地方增加效率。与人工智能相关的技能和工作岗位正在增加，但没有你想象的那么快。政策制定者们正在努力编写一个明确的人工智能法案，如果有的话，这是一个愚蠢的差事。投资已经暂时停滞，但这是在过去十年的天文数字般的增长之后。超过 70% 的中国、沙特和印度受访者认为人工智能的好处多于坏处。美国人呢？35%。消息来源：Tech Crunch老王点评：你看出来这些结论哪些不正确或不太正确吗？采用通用密码的车库门设备一个市场领先的车库门控制器充满了严重的安全和隐私漏洞。这些设备都采用了相同的容易找到的通用密码来与服务器进行通信，它也会广播未加密的电子邮件地址、设备 ID 以及开关门等信息。估计有超过 4 万台设备受到影响，这些设备位于住宅和商业地产中。任何有一定技术背景的人都可以在设备厂商的服务器上搜索到指定的电子邮件地址、设备 ID 或名称，然后向相关控制器发出指令。消息来源：Ars Technica老王点评：虽然我没车库，但是我依然惊讶于现在还有这样对安全毫无意识的厂家。
开源安全基金会（OpenSSF）正式 成立于 2020 年 8 月 3 日。本文将讨论 OpenSSF 创立的初衷，它成立之初六个月内的成就，以及它未来的愿景。（LCTT 校注：原文发表于 2 年前， 但时至今日仍然有一些值得了解的信息。）全世界都在推行开源软件（OSS）理念，所以开源软件的安全也至关重要。为了提升开源软件的安全性，业界已经做了大量工作，并取得了一些成果。这些成果包括：Linux 基金会的 核心基础设施计划 Core Infrastructure Initiative （CII）、GitHub 安全实验室的 开源安全联盟 Open Source Security Coalition （OSSC）和由谷歌以及其他公司创立的 联合开源软件计划 Joint Open Source Software Initiative （JOSSI）。显然，如果这些成果合为一体，软件行业将发展得更加顺利。这三项成果在 2020 年合并为“旨在促进开源软件安全性的、由各行业巨头主导的跨行业联盟”。OpenSSF 的确受益于这种“跨行业联盟”；它有几十个成员，（按字母顺序）包括 Canonical、 GitHub、谷歌、IBM、英特尔、微软和红帽。联盟的理事会成员还包括安全社区个人代表，这些个人代表是那些不能以企业名义作为联盟成员的个人。该联盟也创造了一些便于人们合作的组织结构：建立一些活跃的工作组，这种工作组确定（并公布）它存在的价值，其中的成员应当就该组织的技术愿景形成一致意见。但是这并不重要，除非它们有实际成果。当时虽然处于早期，它们也确实取得了一些成果。它们发布了：安全软件开发基础课程：在 edX 平台上有 3 门免费课程，旨在教授软件开发人员软件安全方面的知识。这些课程注重实际操作，任何开发人员都可以较轻松地学习，而不是那些需要耗费大量资源的理论或案例。开发人员也可以付费参加测试，从而获得认证，表明自己掌握了这些课程地内容。安全评分卡：为开源项目自动生成“安全分数”，帮助用户进行信任、风险和安全方面的决策。关键性分数：基于一些参数，为开源项目自动生成关键性分数。临界分数可以让人们对世界上最重要的开源项目有更好的理解。安全度量仪表盘：这是较早时候发布的成果，它结合安全评分卡、CII 最佳实践和其他数据来源，提供与 OSS 项目有关的安全和支持信息的仪表盘。OpenSSF CVE 基准测试：基准测试由超过 200 个历史上的 JavaScript/TypeScript 漏洞（CVE）的脆弱代码和元数据组成。这将帮助安全团队评估市场上的各种安全工具，使他们能够用真实的代码库（而不是合成的测试代码）确定误报和漏报率。OWASP 安全知识框架：与 OWASP 的合作成果，它是一个知识库，包含了带检查清单的项目和使用多种编程语言的最佳代码样例。它还提供针对开发者如何使用特定的语言编写安全代码的培训材料，以及用于实际操作的安全实验室。2020 年自由/开源软件贡献者调查报告：OpenSSF 和 LISH 发布了一份报告，其中详细说明了对开源软件贡献者的调查结果，并以此为依据，研究和确定提高 OSS 安全性和可持续性的方法。一共调查了 1200 名受访者。现有的 CII 最佳实践徽章 项目已经与 OpenSSF 合并，将继续升级。现在项目有很多中文译者，翻译为斯瓦希里语的工作也在进行中，项目也进行了很多小改进，详细阐明获得徽章的要求。2020 年 11 月举行的 OpenSSF 大会讨论了 OpenSSF 正在进行中的工作。最近，OpenSSF 有这些工作组：漏洞披露安全工具安全最佳实践对开源项目安全漏洞的识别（重点关注指标仪表盘）对关键项目的保障数字身份认证除了持续更新已发布的项目，未来可能的工作还包括：为减少重复工作，在多种技术指标中确定哪些是重复和关联的安全需求。这就是作为领导者与 OWASP 协作开发，也称为 通用需求枚举 Common Requirements Enumeration （CRE）。CRE 旨在使用一种公共主题标识符，将标准和指南的各个部分联系起来，这种公共主题标识符的作用是令标准和方案制定者高效工作，令标准使用者能搜索到需要的信息，从而使双方对网络安全有相同的理解。建一个网站，提供对安全度量仪表盘的免安装访问。再次强调，这将会提供各种来源（包括安全计分卡和 CII 最佳实践）的数据的简单展示。开发对关键 OSS 项目的识别功能。哈佛大学和 LF 已经做过一些识别关键 OSS 项目的工作。未来一年内，他们会改进方法，添加新的数据来源，从而更好地进行鉴别工作。资助一些关键的 OSS 项目，提高它们的安全性。预期将关注那些财力不足的项目，帮助这些项目提升整体性能。识别和实现已改进和简化的技术，用于数字签名的提交和对身份的校验。跟所有的 Linux 基金会项目一样，OpenSSF 的工作是由其成员决定的。如果你对大家所依赖的 OSS 安全有兴趣，你可以访问 OpenSSF 网站并以某种方式加入它们。参与的最好方式是出席工作组会议——会议每隔一周就举行，而且非常随意。通过合作，我们可以有所作为。欲了解更多信息，可以访问：https://openssf.org作者：David A. Wheeler Linux 基金会开源供应链安全总监本文 首次发表于 Linux 基金会网站。via: https://www.linux.com/news/open-source-security-foundation-openssf-reflection-and-future/作者：The Linux Foundation 选题：lujun9972 译者：cool-summer-021 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
作为一个偏爱 在桌面电脑上使用 Linux，并鼓励使用开源软件的人，你可能期待就标题中提出的问题得到一个响亮的肯定回答。然而，我并不打算仅限于讨论开源软件的优点。让我们一起探索更多观点！在本文，我计划分享我关于开源软件是否安全的思考，以及哪些事情与开源软件的安全性相关。为什么你需要关注开源软件是否安全？不论你是使用 Linux 系统还是使用其他类型的操作系统，你都会在某种程度上（直接地/间接地）被开源软件所包围。举个例子，大多数专有软件工具依赖于某种形式的开源库来保证其正常工作。此外，各种规模的公司（包括谷歌、微软和 Facebook）依赖开源软件或者以某种途径向开源社区贡献资源是有原因的。因此，开源软件的安全性是有必要了解的。有关开源软件安全性的迷思虽然有多种理由证明开源软件在安全性方面的缺陷，然而其中一些实际毫无意义。任何人都可以查看并恶意利用开源软件代码是的，开源软件代码对于任何人都是可访问的。但是你可以查看代码并不意味着你可以利用它。不现实。即使任何人都可以复刻（或者拷贝）该软件，原始软件也不能轻易地被修改使用。通常，项目维护人员（或者维护团队）管理代码仓库，并且接受来自贡献者的提交。开源软件代码在接受之前会被审查。没有人可以就这样劫持代码。不论是开源软件还是闭源软件，攻击者都需要付出努力来利用软件中的代码漏洞或者添加恶意代码。没有专职团队，安全性无从谈起很多人相信如果开源软件没有专职人员或者专职团队，维护软件安全性是困难的。恰恰相反，由于各种各样类型的贡献者的加入与离开，开源软件获得了来自更大范围的开发者的更多关注。他们可能比由专有软件所聘用的少数开发者更能够发现安全问题。一些来自 Mozilla 等同类公司的项目拥有自己的专职团队来高效处理安全问题。同样的，大部分成功的开源项目拥有大量的资源用于保障安全性。因此，开源软件的生态系统是安全性的组合包。即使没有专职团队，开源项目也可以得到来自各类贡献者的帮助，他们中的一些很大程度上是有利可图的，这有助于他们投入更多的精力。开源软件是安全的，以下是原因既然我们已经澄清了这些有关开源软件安全性的迷思，让我重点展示一下开源软件是如何处理安全问题的。换句话说，开源软件在安全性上的优势。请不要忘记，开源软件的优势也是 Linux 比 Windows 更好 的一些原因。更多的眼晴关注开源软件代码不像专有软件，（对开源软件的）代码访问并不局限于少数几个开发者。一些开源项目甚至可能拥有数以万记的开发者可以查看代码、审查它们并标记和修复其中的安全性问题。相比闭源软件，这给予了开源项目拥有快速识别问题并尽快修复它们的能力的优势。不仅仅限于拥有更多的开发者，企业通常也会参与他们所使用的开源项目。当他们这样做的时候，他们也会查阅代码并审查它们。这提供了另一条外部审查的途径，而这可能有助于提升开源软件的安全性。反之，就闭源软件而言，数量有限的开发者可能并不能找出所有种类的安全问题。而且他们可能需要花费更长的时间来一一修复发现的问题。社区决定安全问题的优先级闭源软件的开发者可能在处理什么问题和什么时候解决问题等方面有某些限制或者优先等级。而如果是开源项目，贡献者社区可以自行决定优先级，并自行安排他们想解决的问题以及决定合适修复问题。你不需要依赖于供应商的决定或者按照他们的指示来解决一个安全问题。着手处理和修复安全问题的决策在开源软件项目中更加透明和灵活。因此，它可以被证明是更有效的，并为你带来以下三个益处：透明度不依赖供应商更快的安全更新开源软件不是防弹的，以下是原因虽然在某些情况下，开源软件可能在安全性上具有优势，然而仍有一些因素影响它。承认这些问题的存在是很重要的，据此，企业或者个人可以就开源软件的安全情况做出更好的决定。并无足够的眼睛来审查代码和不确定性即使开源软件代码可以被全世界的开发者自由访问，项目没有足够的贡献者/开发者彻底审查开源代码的可能性仍然存在。既如此，我们不能对开源软件的同行审查抱有极高的信心，因为它恰好缺失了这一点。开源软件可能“声称”拥有最高的安全性因为它们是开源的。在没有足够的开发者致力于该项目时，这是一种误导。同样，我们也无从得知有多少开发者在查看/检查代码，也不知道代码的检查进行到什么程度了。举例而言， 心脏出血漏洞 Heartbleed 是在一个被广泛使用的项目（OpenSSL）中引入了 2 年以后才被发现的。软件责任与问责对于个人用户这可能并不重要，但是开源项目通常并无任何保证。因此，如果一家公司使用它，它们必须自行承担任何由该软件使用造成的数据丢失与损坏。这告诉你，没有什么是 100% 安全和没有漏洞的。无论有多少眼睛聚焦在代码上或者贡献者的技术多么精湛，总会存在某种形式的风险，无论是安全风险还是数据丢失。这告诉我们一个现实：开源软件并非防弹的。开源软件有其更高安全性的优势，但是...就安全性而言没有什么优胜者。不论是闭源还是开源，当涉及安全问题时都适用同一套原则。有很多外部因素可以影响软件安全性，而其中很多因素并不依赖于源代码。必须以某种形式监控代码，以保证安全。是的，开源道路提供了闭源软件所不具备的优势，但是这并不意味着开源软件是防弹的。你对开源软件安全状况有何思考？你又是否认为开源软件比专有软件解决方案更好呢？提前感谢你在下面的评论中提出的宝贵意见。via: https://news.itsfoss.com/open-source-software-security/作者：Ankush Das 选题：lujun9972 译者：CanYellow 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
硬核观察 #851 华为开发者的补丁将一个内核函数的速度提升了 715 倍
华为开发者的补丁将一个内核函数的速度提升了 715 倍正在开发中的 Linux 6.2 合并了华为开发者雷镇的一个补丁，将 kallsyms_lookup_name() 的查找速度提高了 715 倍。该函数用于根据名字查找一个符号的地址，能用于查找内核符号表中的任何符号。新的改进将算法复杂度从 O(n) 改进为 O(log(n))，极大地提升了查找速度，只是要多耗费一些内存。Linux 内核社区将此补丁评价为“Linux 的圣诞节礼物”。消息来源：phoronix老王点评：可喜可贺！顺便说一句，在 Linux 6.1 LTS 中，华为再次以内核补丁数排名第一。X.org 紧急发布补丁，WayLand 也没逃开这六个漏洞与 X.Org 服务器扩展中的安全问题有关，是围绕堆栈溢出、使用后释放、越界访问等类似问题，可能导致本地提权和远程代码执行。X.Org 服务器连夜发布了相关补丁。依赖于 X.Org 服务器核心部分的 XWayland 也同样受影响，随之发布了新的补丁。消息来源：Phoronix老王点评：老化的代码，可能存在很多潜在的漏洞。但是 Wayland 依然受影响是我没想到的。谷歌发布开源软件安全漏洞扫描器谷歌宣布推出 OSV-Scanner，这是一个免费的漏洞扫描器，可以在整个软件供应链中自动发现和修补漏洞。它声称这是最大的社区可编辑的开源漏洞数据库。OSV-Scanner 使开发者能够自动将代码和依赖关系与已知的漏洞列表相匹配，并确定是否有补丁或更新。去年，谷歌推出了开源漏洞（OSV）模式和 OSV.dev 漏洞数据库服务。消息来源：Venture Beat老王点评：开源软件漏洞管理是一个重要的、正在发展的市场，谷歌的这些服务瞄准的就是这个市场。
林纳斯定律 Linus's Law 即“ 只要有足够多的眼睛关注，任何漏洞都无处隐藏 given enough eyeballs, all bugs are shallow ”。那么林纳斯定律是如何应用于开源软件安全的呢？这篇文章讨论 Linux 对开源软件安全的影响。开源软件的一个常被赞扬的优点是它的代码能够被任何人审查（安全专家通常称之为“代码审计”）。然而，如果你真的去问很多开源软件用户他们上一次检查代码是什么时候。你大概只能收获他们茫然的眼神或者是喃喃的低语。此外，对于一些相当大型的开源应用，有效地审查每一行代码也是困难的。根据上述这些稍显不安的事实，我们不得不思考：如果没有人察看这些代码，它是开源还是闭源真的有关系吗？你应该相信开源吗？计算机爱好者倾向于作出认为开源软件比其他软件更加安全的传统假设。我们通常不会讨论这意味者什么：比较的基础是什么（比什么“更”安全？），或者上述结论是如何得到的。这是一个危险的陈述，因为它表明只要你将一些东西称之为“开源”，它就自动如魔法般地继承了更高的安全性。这不是开源，事实上，这正是开源安全非常反对的。除非你已经亲自审计并理解了软件代码，否则就不应该假定一个应用程序是安全的。一但你做到了这一点，就可以给予它 终极信任 ultimate trust 。终极信任 不是对计算机而言的，而是对你本人而言的，至少在这一应用程序被渗透攻击之前，你信任它是因为你选择了相信它是安全的。使用者本人是唯一可以对软件代码给予终极信任的人，因此任何人想要获得这样的享受都必须亲自审查代码。相信其他人的话是不管用的。在你已经亲自审计并理解了软件代码之前，你对一个应用程序给予的最大信任度是一个范围，可以是从 根本不信任 到 相当信任 之间。然而我们并没有一个关于信任程度的标准对照表，这是一个你必须亲自做出的个人选择。如果你已经从非常信任的人那里听说了一款应用程序是安全的，那么你可能会更信任这个软件，而不是信任那些你没有得到信任建议的东西。然而，因为无法审计专有（闭源）软件代码，你不可能给予它 终极信任。林纳斯定律现实很骨感，并不是每个人都是程序员，同时也不是每个程序员都有时间检查数以万计的代码行。因此如果你没有亲自审查代码，你就只能选择（一定程度上）相信那些 亲自 审查了代码的人。那么，有哪些人会审查代码呢？林纳斯定律声称 只要有足够的眼睛关注，任何漏洞都无处隐藏，然而我们并不知道多少双眼睛是“足够”的。请不要低估这一数量，应用程序往往经过了远超你想象数量的人员审查。原始开发人员以及后续开发人员显然清楚他们自己写下的代码，不过开源软件往往都是团队成果，开源时间越长，阅读了代码的开发人员越多。新加入的开发人员也必须回顾项目代码的核心部分，因为他们必须学习基础代码以加入新的功能。同时，为了使开源软件能够在 Linux 发行版上可用，负责开源软件打包分发的开发人员会加入多个项目。有时一个应用程序可能会在不熟悉项目代码的情况下打包，但是大多数时候，开源软件打包人员都是熟悉所打包的项目代码的。这不仅仅是因为他们不想在他们不信任的软件上签名，还由于他们可能不得不修改代码来使得程序能够正确编译。漏洞报告人员和漏洞修复人员一般也是熟悉代码库的，因为他们需要尝试解决小到运行异常，大到程序崩溃的问题。当然，一些漏洞报告人员不是通过亲自审查项目代码，而是通过关注明显未按预期工作的现象，无意中揭示了代码漏洞。系统管理员通常都是通晓用户依赖的重要应用软件的代码的。最后，还有一些安全研究人员，他们专门深入代码内部以揭露潜在的漏洞。信任与透明很多人先入为主的认为大型软件的审计是基本不可能的，因为它由数以万计的代码行组成。不要被软件运行所需的代码量欺骗了。我们不需要真的阅读数以万计的代码行。代码是高度结构化的，可被利用的代码漏洞仅仅只是其中的一行，不过它通常影响软件的全部功能。当然，也有例外。有时仅仅一个系统调用或者链接一个有缺陷的库文件就可能引入一系列漏洞。幸运的是，多亏安全研究人员以及漏洞数据库所扮演的积极角色，这些错误相对而言是容易发现的。一些人指着错误追踪系统，比如 通用漏洞披露 Common Vulnerabilities and Exposures （CVE）网站，并推断开源软件显而易见是不安全的。毕竟已经向公众公开了大量的安全风险，涉及许多开源项目。但是不要被数据欺骗了。只是因为我们看不到现闭源软件的漏洞，并不意味着闭源软件中不存在漏洞。事实上，已经有很多针对闭源软件的漏洞攻击提出了，闭源软件也是存在漏洞的。区别在于开发者（以及用户）可以查看开源软件的 所有的漏洞 从而降低漏洞的影响。这是扩大对开源软件信任的系统机制的一部分，却正是闭源软件软件所缺少的。对于任何代码而言，可能永远没有“足够的眼睛”来发现漏洞，但是开发社区越壮大、越多样化，越有机会发现和修复代码中的缺陷。信任与人在开源社区中，参与同一项目的众多开发者已经发现“不安全”的漏洞，却保持沉默的的可能性是微乎其微的，因为人们很少同意以这样的方式合谋。我们已经看到了在应对 COVID-19 的过程中，人类的行为是如何不一致了，在这里也一样：我们都发现了漏洞（病毒）。我们知晓如何避免它传播（待在家里）。然而病毒还是在持续传播，因为总是有一个或者多个人偏离了消减疫情的计划。开源软件中的漏洞也一样，如果有人发现了漏洞总会公之于众（当然，我们说的是“假如”能够发现）。然而就专有软件而言，有很大可能参与项目的众多开发者即使注意到不安全的漏洞却仍然保持沉默，因为专有模式依赖于薪水。如果一个开发者将漏洞泄漏出来，他可能只是伤害了该专有软件的声誉，进而降低软件的销售额；或者，在更糟糕的情况下，他可能因此而丢了工作。开发人员拿着薪水秘密地研究软件，往往不会谈论其缺陷。如果你曾经是一名开发者，你可能曾经签署过 NDA （LCTT 译注： 保密协议 Non-Disclosure Agreement ），也被培训过商业秘密的重要性，等等不一而足。专有软件鼓励在面对严重的秘密缺陷时保持沉默，更多时候甚至是强制要求沉默。信任与软件不要信任未经你审计的软件。如果你必须相信未经你审计的软件，那么选择相信已经面向那些更有可能将软件缺陷公之于众的开发者公开代码的软件。开源软件并没有比专有软件继承更高的安全性，但是修复它的系统得到了更好的规划、实施和人员配置。via: https://opensource.com/article/21/2/open-source-security作者：Seth Kenlon 选题：lujun9972 译者：CanYellow 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出