作者freexq (快乐蕃茄)
看板C_and_CPP
标题[讨论] 网路新闻分享
时间Wed Nov 20 19:28:52 2024
文章来源:
https://reurl.cc/aZr7ql
美国政府呼吁弃用 C/C++，软体开发界将迎来巨变？
近日，美国网路安全和基础设施安全局 (CISA) 和联邦调查局 (FBI) 再次
发出呼吁，敦促软体开发商放弃使用 C 和 C++ 等「记忆体不安全」的程式
语言，转而采用更安全的替代方案，以降低国家安全、经济安全和公共健康
的风险。
这一呼吁并非空穴来风。CISA 早在 2024 年初就与五眼联盟的其他成员
（包括 FBI、澳洲网路安全中心和加拿大网路安全中心）联合发表了一份报告，
分析了 172 个关键开源专案。报告指出，超过一半的专案使用了记忆体不安全
的语言编写程式码，占总程式码量的 55%。
记忆体安全漏洞：挥之不去的梦魇
CISA 强调，记忆体安全漏洞占所有安全漏洞的 70%。由於 C 和 C++ 等语言
要求开发人员手动管理记忆体的使用和分配，任何疏忽都可能导致缓冲区溢位、
释放後使用等严重漏洞，让攻击者有机可乘，控制软体、系统甚至窃取资料。
为了解决这个问题，CISA 建议开发人员改用 Rust、Java、C#、Go、Python
和 Swift 等记忆体安全的程式语言。这些语言内建了记忆体保护机制，可以
有效防止常见的记忆体相关错误，从程式码层面提升安全性。
理想很丰满，现实很骨感
尽管 CISA 的建议立意良善，但要让开发者放弃 C/C++ 并非易事。
首先，将现有的大型程式码库转换为新的程式语言需要耗费大量时间和资源，
而且必须仔细规划才能确保功能不受影响。对於许多企业来说，这无疑是一项
巨大的挑战。
其次，记忆体安全的语言在效能方面可能不如 C/C++。C/C++ 之所以经久不衰
，正是因为它们能够编写出执行速度最快的程式。在速度和安全之间，许多开发
者和企业仍然会优先考虑速度。
此外，企业还需要额外投资，更换现有的开发工具、除错器和测试框架，
以支援新的程式语言，并将新程式与旧程式码和程式库整合。
CISA 的最後通牒：2026 年前提交迁移路线图
尽管困难重重，CISA 仍然坚持要求企业在 2026 年 1 月 1 日前提交迁移
现有程式码库的路线图，并强调从长远来看，减少漏洞和提高安全性所带来
的收益将超过初始投资。
然而，在追求短期利润最大化的现代商业环境下，企业是否愿意买单，
仍是一个未知数。
Linux 之父 Linus Torvalds 的态度：谨慎支持
就连 Linux 的创造者 Linus Torvalds 也对此持保留态度。虽然他
支持在 Linux 核心程式码中引入 Rust 语言，但也坦言 Rust 和 C
之间的争论已经演变成「宗教战争」，许多经验丰富的 C 语言开发者
抵触学习 Rust。
未来展望：记忆体安全语言的崛起之路
尽管面临重重阻力，但记忆体安全语言的发展是大势所趋。随着技术的
进步和安全意识的提高，相信会有越来越多的开发者和企业选择更安全
的程式语言。
然而，这个转变过程注定是漫长而痛苦的。在 2020 年代，C/C++ 仍然
会是软体开发的主力军。或许在 2030 年代，我们才能真正见证记忆体
安全语言的全面崛起。
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 36.233.195.218 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/C_and_CPP/M.1732102135.A.08B.html
1F：→ freexq: C和C++可以直接管理记忆体似乎是两面刃，好处是执行速度快 11/20 19:38
2F：→ freexq: 坏处是一但出错，会造成记忆体安全漏洞，被骇客利用 11/20 19:45
3F：→ freexq: 在文章最後一段，2020年代C/C++仍然是软体开发主力军 11/20 19:48
4F：→ freexq: 2030年代，记忆体安全语言将会全面崛起 11/20 19:49
5F：→ freexq: 这表示再5年，C/C++会被全面取代掉吗? 11/20 19:52
6F：→ freexq: 旧的已完成的程式码不要说，开发新程式将不再采用C/C++吗? 11/20 19:56
7F：→ CP64: 稍微看了一下CISA发布的东西 它只要求一些元件需要这样做 11/21 03:43
8F：→ CP64: 如暴露在网路中的或加密相关的敏感功能的元件 11/21 03:45
9F：→ CP64: *现有的程式中的这些元件需要发布迁移路线图 11/21 03:46
10F：→ CP64: 不过照过往换东西的速度我觉得讲到时候全面取代是有点太快 11/21 03:48
11F：→ CP64: 我相信不符合以上条件的东西还是会很多是继续用C/C++ 11/21 03:49
12F：→ freexq: 温水煮青蛙，照文章来看美国政府呼吁不要用的根本理由 11/21 19:04
13F：→ freexq: 就是 C/C++ 是「记忆体不安全」的程式语言 11/21 19:09
14F：推 bizer: 记忆体不安全我只当你程式有bug,那个程式没bug？ 11/21 19:21
15F：→ freexq: 加上连Linux和Windows的核心都可以用另一个语言Rust来写 11/21 19:23
16F：→ freexq: C/C++传统优势领域不再... 11/21 19:28
17F：→ freexq: 慢慢的以後你的老板会要求你用别的程式语言来完成工作 11/21 19:31
18F：→ freexq: 你个人或公司在外面接的案子，也会指定你不要用C/C++ 11/21 19:35
19F：→ freexq: 就如同文章所説的，使用其他的程式语言，达到他们的目的 11/21 19:44
20F：→ freexq: 根本上去解决程式容易出错的机制 11/21 19:45
※ 编辑: freexq (36.233.195.218 台湾), 11/21/2024 19:47:29
※ 编辑: freexq (36.233.195.218 台湾), 11/21/2024 19:53:37
※ 编辑: freexq (36.233.195.218 台湾), 11/21/2024 19:56:26
21F：推 wulouise: 这篇很久了吧 .... 11/21 21:24
22F：推 Killercat: 我以为Linus会顺便troll一下C++ XDD 11/23 01:59
23F：推 kdjf: 安全的需求不是在每个领域都那麽有价值... 11/23 09:14
24F：→ logravis: 不行吧～python老弟不懂，但好像没有pointer 11/23 12:56
25F：→ jpjpjp: 愈改愈烂。C那麽好用也能被硬拗成这样。 01/06 12:28
26F：推 expiate: curl不是才放弃rust，这样还有搞头吗？ 01/13 03:54
27F：推 if4: 打从一开始学习程式语言，就提到结构性的重要，尤其是C&C++ 02/06 01:32
28F：→ if4: 这期间也有提到记忆体的管理。结构性的好处让程式码可读性高 02/06 01:32
29F：→ if4: 记忆体的管理让程式码安全性提高，但是以前的做法是让我们在 02/06 01:32
30F：→ if4: 研发程式的时候谨慎小心，别出纰漏。但看了这个新闻之後，才 02/06 01:32
31F：→ if4: 惊觉主管机关要我们换另外一种语言，这个问题从编译器本身做 02/06 01:32
32F：→ if4: 改良不行吗？换另外一种语言就是说把编译器换掉，这其中又有 02/06 01:32
33F：→ if4: 何差别呢？ 02/06 01:32
34F：推 nthank: 我觉得很困难。现实就是最强最资深的这些人都不愿意放弃 02/06 14:10
35F：→ nthank: 自己熟悉的语言。 02/06 14:10
36F：→ lycantrope: 换zig 02/06 16:23
37F：推 johnjohnlin: 就是强才不愿意放弃吧，损失多少开发效率 02/08 09:35
38F：推 hare1039: 外行人领导内行哦 02/14 09:28
39F：→ hare1039: 去除C & C++ 根本不可能 02/14 09:28
40F：→ Lipraxde: 编译器本身做改良还是受限於程式语言的语法，语法本身 02/14 16:21
41F：→ Lipraxde: 存取记忆体就没保证安全性了，替代方案可以用 lint、va 02/14 16:21
42F：→ Lipraxde: lgrind 等工具，但比较像是在打补丁 02/14 16:21
43F：→ if4: 请问 Windows 这系列 OS 是用 C/C++ 写的吗？ 02/14 23:14
44F：推 if4: 因为想到以後可能 Windows OS 重写就有很高的不确定性 那DOS? 02/15 03:12
45F：→ if4: 不过安全性高的话 就不用经常安全性更新了 也算好消息 Orz 02/15 03:15
46F：推 wulouise: 现实就是重写不合效益，单写mmodule rust效果差很多 02/15 19:04