作者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/m.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