Google在Chromium項目中支持使用Rust

Rust 1.66.1 發(fā)布

Rust 1.66.1 修復(fù)了 Cargo 在使用 SSH 克隆依賴項或注冊表索引時不驗證 SSH 主機密鑰的問題。此安全漏洞被跟蹤為CVE-2022-46176[1]。所有包含 1.66.1 之前的 Cargo 的 Rust 版本都容易受到攻擊。

Rust 1.66.0 的補丁文件也可獲得，用于定制工具鏈。

如果您還不能升級到 Rust 1.66.1，官方建議將 Cargo 配置為使用git 命令 而不是其內(nèi)置的 git 支持。這樣，所有 git 網(wǎng)絡(luò)操作都將由git 命令 執(zhí)行，不受此漏洞的影響?？梢酝ㄟ^ Cargo 配置文件來實現(xiàn)：

[net]
git-fetch-with-cli = true

Cargo 安全公告 (CVE-2022-46176)

Rust 官方發(fā)布了Cargo 安全公告 (CVE-2022-46176)[3]，Rust 安全響應(yīng)工作組獲悉，Cargo 在通過 SSH 克隆索引和依賴項時未執(zhí)行 SSH 主機密鑰驗證。攻擊者可利用此漏洞執(zhí)行中間人 (MITM) 攻擊。

“

當 SSH 客戶端與服務(wù)器建立通信時，為了防止 MITM 攻擊，客戶端應(yīng)該檢查它是否已經(jīng)與該服務(wù)器通信過，以及當時服務(wù)器的公鑰是什么。如果自上次連接以來密鑰發(fā)生變化，則必須中止連接，因為可能會發(fā)生 MITM 攻擊。

該漏洞是由 Julia 安全團隊 提交給 Rust 安全團隊。

Rust 1.68 中將更新 Android NDK

原文[4]

Rust 中的 Android 平臺支持將在 Rust 1.68 中實現(xiàn)現(xiàn)代化，因為在 NDK r23 中，Android 切換到對所有架構(gòu)使用 LLVM 的libunwind。展望未來，Android 平臺將以最新的 LTS（長期支持） NDK 為目標，允許 Rust 開發(fā)人員更快地訪問平臺功能。這些更新應(yīng)每年進行一次，并將在發(fā)行說明中公布。

“

Android 中 NDK 工具鏈說明[5]

【辟謠】hyper 存在拒絕服務(wù)漏洞 ？？? Rust 項目易受 DoS 攻擊？？？真相在這里

近日，社區(qū)瘋狂流傳一篇被標題為“Hyper 存在漏洞，Rust項目易受拒絕服務(wù)攻擊”的文章。

當然，這篇文章來自于國外，原文是 JFrog （JFrog是 Rust基金會白金成員）官方博客發(fā)布的名為“使用 Rust 流行的 Hyper 包時注意 DoS”[6]的文章。

其實，JFrog 的人在幾個月之前就聯(lián)系過 Hyper 作者 seanmonstar ，seanmonstar 在 hyper 相關(guān)issues[7]里說到：

“

我知道這篇文章，他們在幾個月前私下聯(lián)系了我，我試圖解釋它與 本質(zhì)上是一樣的Read::read_to_end，但他們覺得聲稱 hyper 易受攻擊的大標題對他們有用。

JFrog 作為 Rust 基金會白金成員之一，起這個標題，到目前為止我是可以理解的，至少這個標題可以呼吁 Rust 開發(fā)者在使用 Hyper 時要注意這個 Dos 風(fēng)險。

但讓人更無語的是，國內(nèi)技術(shù)媒體翻譯到國內(nèi)以后，標題被改的已經(jīng)失去了原文的初衷，扭曲了事實。

首先必須得承認，原文中所說的 hyper 當前最新穩(wěn)定版（v0.14）中`to_bytes`[8]函數(shù)確實存在 Dos 風(fēng)險。但其實，這并不是 hyper 的漏洞。

“

JFrog 安全研究團隊不斷在流行的開源項目中尋找新的和以前未知的漏洞和安全問題，以幫助改善他們的安全狀況并保護更廣泛的軟件供應(yīng)鏈。作為這項工作的一部分，我們最近發(fā)現(xiàn)并披露了流行的 Rust 項目（例如Axum[9]、Salvo[10]和conduit-hyper[11]）中的多個漏洞，這些漏洞源于相同的根本原因——在使用 Hyper 庫時忘記對 HTTP 請求設(shè)置適當?shù)南拗啤?/p>

這是原文中的開篇，清楚地寫道：“漏洞是屬于一些較為流行的 Rust 項目（例如Axum[12]、Salvo[13]和conduit-hyper[14]），這些漏洞源于相同的根本原因——在使用 Hyper 庫時忘記對 HTTP 請求設(shè)置適當?shù)南拗??！?/p>

是這些 Rust 項目，使用 Hyper 庫時，自己忘記了對 HTTP 請求設(shè)置做適當處理導(dǎo)致的。

而在 Hyper 的文檔中，to_bytes這個函數(shù)的文檔，清清楚楚地寫了注意事項：

“

如果遠程數(shù)據(jù)不受信任，則需要小心。該函數(shù)不執(zhí)行任何長度檢查，惡意方可能會消耗任意數(shù)量的內(nèi)存。檢查Content-Length是一種可能性，但并不嚴格要求必須存在。

文檔里提醒開發(fā)者使用這個函數(shù)需要小心，并且也解釋了為什么在這個函數(shù)內(nèi)部沒有對其做限制。那些 Rust 項目使用了該函數(shù)，引發(fā)了DoS 漏洞，完全是因為沒有看該文檔導(dǎo)致的。換句話說，是使用不當導(dǎo)致的。

所以，結(jié)論是，hyper 并不存在什么 DoS 漏洞。更多細節(jié)可以參考本文。

Pre-RFC : 為了提升供應(yīng)鏈安全建議使用 Sigstore 簽名和驗證 crate

對于任何構(gòu)建和維護開源軟件的公司而言，軟件供應(yīng)鏈安全性越來越重要。許多應(yīng)用程序依賴于第三方依賴項而不知道誰編寫了軟件，這可能為供應(yīng)鏈攻擊敞開大門。因此有人提議使用Sigstore[15]對 crate 進行簽名和驗證，并撰寫了Pre RFC[16]。

使用 Sigstore 可以改善供應(yīng)鏈攻擊向量中 Upload modified package 和 Compromise package repo 攻擊。當前，如果 crates.io 遭到破壞，則無法驗證從 crates.io 中提取的 crates。將 crates.io 和 cargo 與 Sigstore 集成減少了這種妥協(xié)的中斷，因為仍然可以驗證單個箱子，并且不可變?nèi)罩镜拇嬖谟兄趯徲嫼驮u估攻擊的影響。

Sigstore 是由開源安全基金會 (OpenSSF) 運行的一個開源項目，它提供了針對上述問題的解決方案。它提供了一個密鑰管理服務(wù) Fulcio，它與 OpenID Connect 服務(wù)集成以識別作者并生成用于簽名的密鑰。Sigstore 還提供了一個不可篡改的透明日志 Rekor，用于記錄簽名證書以及從 OpenID 令牌中提取的其他信息。以后可以審核這些記錄。

而 Rust 官方安全團隊早已在 9 年前（2014）就注意到了這個問題，并建立了 crate 安全模型的issue[17]討論，并提到將由 Tor 開發(fā)人員和學(xué)者共同開發(fā)的更新框架（TUF）[18]（TUF 是一組特定于軟件分發(fā)系統(tǒng)的已定義攻擊和威脅模型，以及一組巧妙設(shè)計的協(xié)議來抵御它們）集成到 Cargo 中，然而一直沒有落地一個合適的方案。

【熱議】什么場景下使用 C 比 Rust 更好？

https://www.reddit.com/r/rust/comments/108z0m4/when_is_c_better_a_better_choice_than_rust/ 該問題來自于Reddit/r/rust頻道。

一個高贊回答如下：

最大的可移植性。很少有平臺沒有某種C語言工具鏈可用，無論是奇怪的大型機系統(tǒng)、老式工作站，還是一些可愛的嵌入式東西。

合規(guī)性。有大量的規(guī)范有效地要求C語言；MISRA就是一個例子。

工具化。C有大量圍繞它的工具，比如frama-c和其他分析你的代碼的工具，或者compcert編譯器。雖然Rust有很多用于普通情況的工具，但對于更多的小眾事物來說，它很難超越50年以上的生態(tài)系統(tǒng)。

生命力持久。如果出于某種原因，你需要讓你的代碼在50年后仍可運行，那么我認為C是更好的選擇。

上面四點，大部分人同意前三點，但是對于第四點，Rust 社區(qū)有人回復(fù)：“我不明白，為什么 Rust 不能運行 50 年？”。

“C 是過去 50 年的語言，Rust 是未來 50 年的語言”，這句話是 Rust 社區(qū)流行的一句話，現(xiàn)在通過這個帖子的討論看來，大部分人并不認同這句話。這顯然是可以理解的，因為讓 Rust 成為未來 50 年的語言，目前還只是一個美好的愿望，并且 Rust 社區(qū)還在為這個目標努力。但是 C 語言，它已經(jīng)達成了過去 50 年屹立不倒的成就了。

Rust 應(yīng)用實踐

RedoxOS 的 GUI 安裝程序即將推出，用 iced 編寫！

RedoxOS[19]是一個用 Rust 編寫的類 Unix 操作系統(tǒng)，旨在將 Rust 的創(chuàng)新帶到現(xiàn)代微內(nèi)核和全套應(yīng)用程序中。

之前 RedoxOS 的 UI 開發(fā)套件是orbtk[20]，三個月之前，orbtk作者宣布該項目即將落幕，RedoxOS 將換成iced[21]。目前 iced （以及slint[22]）提供與 Redox OS 兼容的渲染器無關(guān)工具包，但它們還支持比 OrbTk 更多的功能。

官宣：支持在 Chromium 項目中使用 Rust

Google 安全博客官宣[23]將在 Chromium 項目中支持 Rust 第三方庫。

目前 Chromium 團隊正在積極地將 Rust 工具鏈集成到其構(gòu)建系統(tǒng)中（實際上這項工作已經(jīng)持續(xù)很久了），在明年（2024？）內(nèi)將 Rust 代碼包含在 Chrome 二進制文件中。

為什么選擇將 Rust 引入 Chromium？

為了提供一種更簡單（無 IPC）和更安全的方式來滿足加快開發(fā)速度（更少的代碼編寫，更少的設(shè)計文檔，更少的安全審查）并提高Chrome的安全性（增加沒有內(nèi)存安全錯誤的代碼行數(shù)，降低代碼的錯誤密度）的需求。

Chromium 將如何支持 Rust 的使用？

目前，Chromium 將只支持單一方向的互操作，即從 C++ 到 Rust。Chromium是用C++編寫的，大部分的框架技術(shù)棧都是C++代碼，通過將互操作限制在一個方向，可以控制依賴樹的形狀。Rust不能依賴C++，所以它不能知道C++的類型和函數(shù)，除非通過依賴注入。

暫時只支持 Rust 第三方庫。第三方庫是作為獨立的組件編寫的，它們不持有關(guān)于Chromium實現(xiàn)的隱含知識。這意味著它們的API更簡單，而且專注于它們的單一任務(wù)。

Chromium中 Rust 和 C++ 之間的互操作

迄今為止，大多數(shù)成功的C/C++和Rust互操作故事都是圍繞著通過單一(Narrow)的API（如QUIC或藍牙的庫，Linux驅(qū)動程序）或通過明顯的隔離組件（如IDL，IPC）進行互操作。Chrome是建立在基礎(chǔ)的但真正廣泛的C++ API上的，在高層次上，團隊發(fā)現(xiàn)，由于C++和Rust遵循不同的規(guī)則，事情很容易出岔子。例如，Rust通過靜態(tài)分析來保證時間上的內(nèi)存安全，靜態(tài)分析依賴于兩個輸入：生命期（推斷的或明確寫入的）和獨占的可變性。后者與Chromium的大部分C++的編寫方式不兼容，在整個系統(tǒng)中持有冗余的可變指針，以及提供多條路徑來到達可變指針的指針。這在Chrome瀏覽器進程中尤其如此，它包含了一個巨大的（可變）指針互連系統(tǒng)。如果這些C++指針也以復(fù)雜或長期的方式被用作 Rust的引用，這就要求C++作者理解Rust的別名規(guī)則，并防止違反這些規(guī)則的可能性。

總之，如果沒有額外的互操作工具支持：

跨語言傳遞指針/引用是有風(fēng)險的

語言之間單一(Narrow)的接口對于正確編寫代碼來說是至關(guān)重要的

Google 目前正在投入Crubit[24]項目，這是一個關(guān)于如何提高C++和Rust之間互操作的保真度，并將每種語言的要求表達或封裝給對方的實驗。

Chromium 團隊認為：

“

Rust生態(tài)系統(tǒng)是非常重要的，特別是對于像Chromium這樣以安全為重點的開源項目。這個生態(tài)系統(tǒng)是巨大的（crates.io上有96k+的crates），并且在不斷增長，包括谷歌在內(nèi)的整個系統(tǒng)開發(fā)行業(yè)都在投資。Chrome瀏覽器在很大程度上依賴于第三方代碼，而我們需要跟上第三方投資的步伐。我們必須支持將Rust納入Chromium項目，這一點至關(guān)重要。我們將遵循上述策略來建立規(guī)范，并通過第三方程序保持一定程度的API審查，同時我們展望未來的互操作支持，推動Rust和C++之間可能和合理的操作的界限。

內(nèi)存不安全是整個行業(yè)當前面臨的問題，而利用 Rust 是在這一領(lǐng)域推進戰(zhàn)略的一個部分。

dora-rs：機器人中間件項目

dora[25]是一個基于 Rust 的機器人框架，目標是成為一個低延遲、可組合和分布式的面向 SDV 和 無人駕駛的數(shù)據(jù)流計算平臺。，旨在比當前機器人應(yīng)用標準 ROS/ROS 2 好 10 倍，成為 ROS/ROS2/Autosar 的替代者。

Rust-os Blog的作者 Philip Opperman是 dora 主力開發(fā)者之一 。

dora 通信層暫時依賴于eclipse-zenoh/zenoh[26]，關(guān)于zenoh 的介紹可以參考文章開源產(chǎn)品 | eclipse zenoh 助力霧計算和邊緣計算[27]。dora-rs 的通信層正在被重新設(shè)計[28]，目標是將數(shù)據(jù)面的控制和傳輸技術(shù)分離，比如算子都在一臺機器部署的時候，就會用共享內(nèi)存，這樣延時很低。

更多文檔參考：https://dora-rs.github.io/dora/[29]，并且還配套有基于dora的自動駕駛入門套件dora-drives[30]。

雖然是早期項目，但發(fā)展不錯，目前正在加入開放原子基金會的過程中，并且在 2023 年春季會基于 dora 開展國際智能駕駛大賽（Openatom Carsmos全球開源自動駕駛算法大賽）。

BlackBerry 和 Elektrobit 通過支持 Rust 編程語言加強汽車安全路線圖

官方原文[31]

BlackBerry 是將 Rust 語言集成到 BlackBerry QNX 微內(nèi)核實時操作系統(tǒng)中，Elektrobit 與 BlackBerry QNX 在 Rust 項目上密切合作，貢獻代碼，確保代碼質(zhì)量，處理項目管理以及與 Rust 社區(qū)的互動。Elektrobit 公司是AUTOSAR專家，深耕汽車軟件行業(yè)，和 BlackBerry QNX 是很多年合作伙伴。

BlackBerry QNX 已在全球范圍內(nèi)獲得超過 2.15 億輛汽車的信賴，并在全球范圍內(nèi)部署在商用車、重型機械和其他市場等一系列行業(yè)的嵌入式系統(tǒng)中。其產(chǎn)品已通過多項行業(yè)安全標準的預(yù)認證，包括 ISO 26262、IEC 61508 和 IEC 62304，該公司還獲得德國萊茵 TüV 獨立審計師的認可，成為全球首個通過 ASIL D 安全認證的商業(yè)管理程序。

Rust 可與 BlackBerry 經(jīng)過安全認證的 BlackBerry QNX 產(chǎn)品組合集成，有能力塑造關(guān)鍵任務(wù)軟件和軟件定義車輛的未來

“

點評：這次合作比等待 Autosar 直接引入 Rust 的效率高多了。

aquatic_udp 性能改進，達到每秒響應(yīng)高達 225 萬次

aquatic[32]當前已經(jīng)完成了新一輪開放 UDP BitTorrent tracker 實施的基準測試。aquatic_udp的結(jié)果非常好，在 8 個 CPU 內(nèi)核上運行時實現(xiàn)了opentracker[33]的兩倍吞吐量，達到每秒響應(yīng)高達 225 萬次。

生態(tài)看點

flux: Rust 精化類型庫

flux[34]是最新發(fā)布的一個 Rust 精化類型（Refinement Types）庫。

“

精化類型 (refinement types) 在普通類型的基礎(chǔ)上添加了對變量取值范圍的約束，從而可以用于保證程序不存在除零、數(shù)組越界等錯誤，甚至完全驗證程序的功能正確性。精化類型的工作機制可以簡單描述為：標注函數(shù)的輸入和輸出滿足的條件（前置條件和后置條件），經(jīng)過驗證條件生成，使用 SMT 求解器半自動地驗證正確性。精化類型可以看作依賴類型的一個子集，對于依賴和謂詞的使用有一些約束以保證類型檢查的可判定性。詳情可以參考華為編程語言Lab - 精化類型簡介[35]。

為什么需要精化類型？

Rust 擁有強大的類型系統(tǒng)，可以在編譯期捕捉很多常見的錯誤，以此來保證程序的正確性、內(nèi)存安全性和并發(fā)安全性。然而，類型系統(tǒng)并不能捕捉全部的錯誤，還有一些常見的錯誤是類型系統(tǒng)無法捕捉的。例如，除零錯誤、數(shù)組越界、程序執(zhí)行結(jié)果的正確性（類型系統(tǒng)可以保證返回值類型正確，但無法保證具體的值是否滿足要求，比如返回的數(shù)組是否滿足指定排序）。精化類型解決的主要是程序運行時的正確性問題。

flux 通過 Rust 過程宏將精化類型帶到了 Rust 中，它在編譯時進行檢查。

#[flux::sig(fn()->i32[10])]
pubfnmk_ten()->i32{
5+4
}

上述代碼，使用#[flux::sig(fn() -> i32[10])]標注的mk_ten函數(shù)，意味著它輸出的值（后置條件）應(yīng)該是 10 。

但是在編譯時，flux 就會發(fā)現(xiàn)問題，告訴你當前函數(shù)執(zhí)行結(jié)果不滿足后置條件：

error[FLUX]:postconditionmightnothold
-->src/basics.rs5
|
7|5+4
|^^^^^

再看另一個示例：

#[flux::sig(fn(b:bool[true]))]
pubfnassert(b:bool){
if!b{panic!("assertionfailed")}
}

這次flux設(shè)置的是前置條件，即，assert 函數(shù)的參數(shù)必須輸入 true，不能是 false。

fntest(){
assert(2+2==4);
assert(2+2==5);//failstotypecheck
}

測試代碼的第二個測試就會檢查失敗，因為它不滿足前置條件。

值得說明的是，F(xiàn)lux 利用Rust的所有權(quán)機制[36]來跟蹤共享（&T）和可變（&mut T）引用的屬性，另外還增加了一個強（&strg T）引用 --&mut的一個特例 -- 來支持類型本身被調(diào)用改變的情況。

flux 還提供了很多功能，更多詳情可以參考flux 官方介紹文章[37]。官方也提供了在線體驗 flux 的網(wǎng)站[38]。flux 作者來自 UC San Diego 大學(xué)，他也發(fā)布了相關(guān)論文Flux: Liquid Types for Rust[39]。

Veryl: 現(xiàn)代硬件描述語言

veryl[40]是 Rust 實現(xiàn)的現(xiàn)代硬件描述語言，目前正處于語言設(shè)計的探索階段。

Veryl Playground[41]

Veryl Book[42]

Veryl 的目標是 SystemVerilog 的替代品。

“

SystemVerilog是一種硬件描述和驗證語言（HDVL），它基于IEEE1364-2001 Verilog硬件描述語言（HDL），并對其進行了擴展，包括擴充了C語言數(shù)據(jù)類型、結(jié)構(gòu)、壓縮和非壓縮數(shù)組、 接口、斷言等等，這些都使得SystemVerilog在一個更高的抽象層次上提高了設(shè)計建模的能力。SystemVerilog由Accellera開發(fā)，它主要定位在芯片的實現(xiàn)和驗證流程上，并為系統(tǒng)級的設(shè)計流程提供了強大的連接能力。

Veryl 遵循以下設(shè)計原則：

Veryl 具有基于 SystemVerilog / Rust 的簡化語法?！昂喕庇袃蓚€含義：一個用于解析器，另一個用于人類。SystemVerilog 的語法非常復(fù)雜（參見 IEEE Std 1800-2017 Annex A）。這導(dǎo)致 SystemVerilog 工具實現(xiàn)困難。

能轉(zhuǎn)譯到 SystemVerilog。Veryl 將具有與 SystemVerilog 幾乎所有相同的語義。所以轉(zhuǎn)譯后的代碼將是人類可讀的 SystemVerilog。此外，Veryl 與 SystemVerilog 具有互操作性。Veryl可以在代碼中使用SystemVerilog的module/interface/struct/enum，反之亦然。

現(xiàn)代編程語言默認具有 linter、格式化程序和語言服務(wù)器等開發(fā)支持工具。從開發(fā)之初，Veryl 也會擁有它們。

h3o : h3 地理空間索引系統(tǒng)的 Rust 實現(xiàn)

h3o[43]是對 Uber 開源的 h3 地理空間索引系統(tǒng)的純 Rust 實現(xiàn)，100%覆蓋 h3 4.0 API。目標是，在Rust項目中更容易集成，特別是在針對 WASM的時候，并且能提供更安全更快的API。

“

H3[44]是一個針對地球的空間劃分和空間索引系統(tǒng)。由 Uber 在 2018年初正式開源。h3 將全球劃分為不同分辨率的六邊形的蜂窩小區(qū)，通過 Uber 公司 H3 Core Libary API 可以將經(jīng)緯度坐標轉(zhuǎn)移映射到六邊形小區(qū)，從而實現(xiàn)了衛(wèi)星通信路由區(qū)。

h3o 的由911個測試案例組成的基準套件已經(jīng)被開發(fā)出來了，涵蓋了整個公共API，并將h3o的性能與H3參考實現(xiàn)（通過h3ron-sys crate，預(yù)計沒有開銷）進行比較，h3o更快。

datacake ：構(gòu)建最終一致的分布式數(shù)據(jù)系統(tǒng)

datacake[45]是Lnx[46]（基于rust tantivy 搜索引擎實現(xiàn)的類似 ElasticSearch 的工具） 項目下的一個新項目，用于構(gòu)建最終一致的分布式數(shù)據(jù)系統(tǒng)。

Datacake是作者嘗試為 lnx 帶來高可用性的成果，分布式共識算法采用Quickwit[47]開發(fā)的chitchat[48]，它是 scuttlebutt 算法的實現(xiàn)。

leptos: 全棧同構(gòu)的 Rust Web 反應(yīng)式（reactivity）框架

leptos[49]是提供了構(gòu)建現(xiàn)代 Web 應(yīng)用程序所需的大部分內(nèi)容：反應(yīng)式系統(tǒng)、模板庫以及可同時在服務(wù)器端和客戶端運行的路由器。特點是，利用細粒度的反應(yīng)式來構(gòu)建用戶界面。

目前僅發(fā)布了 0.1，可以關(guān)注。

how-u-doin: Rust 的進度報告抽象庫

how-u-doin[50]的架構(gòu)類似于log庫，log為日志輸出提供了一個抽象的接口（基于 faced 設(shè)計模式），而howudoin則為進度（progress）報告提供抽象接口。該接口用于將進度的消費和顯示分離。

Fyrox 游戲引擎發(fā)布 0.29 版本

Fyrox[51]是 Rust 實現(xiàn)的游戲引擎，支持 3D 和 2D 游戲，目前發(fā)布了 0.29 版本。

0.29 版本特性摘要：

重新設(shè)計的動畫系統(tǒng)。長期以來，引擎中的動畫系統(tǒng)只能對場景節(jié)點的位置、旋轉(zhuǎn)和縮放進行動畫處理?，F(xiàn)在它發(fā)生了變化——您可以使用反射為幾乎任何數(shù)字屬性設(shè)置動畫。

新的動畫編輯器。感興趣可以參考動畫編輯器介紹[52]

改進 WebAssembly 支持。引入fyrox-template（一個生成游戲項目和腳本模板的簡單工具）現(xiàn)在能夠為游戲生成單獨版本的 WebAssembly 執(zhí)行器，幾乎可以毫不費力地創(chuàng)建游戲的 WebAssembly 版本，并且也支持了一鍵部署 WebAssembly 。

還有很多重大特性更新，感興趣的朋友可以參考 fyrox 更多新特性介紹[53]。

cargo-show-asm 發(fā)布 0.2.10 版本

cargo-show-asm[54]是一個快速查看 rustc 生成的 asm 匯編指令的工具。

查看 Rust 項目生成 asm 匯編指令的方式之前有兩種方式：

使用godbolt.org[55]

通過cargo rustc -- --emit asm生成

現(xiàn)在又多了一種更方便的工具 cargo-show-asm ，它不僅支持多種平臺，還支持顯示Intel/A&T兩種不同的匯編格式，可以展示llvm-ir，rustc MIR，wasm等多種指令，同時還實現(xiàn)了bash/zsh的自動補全、彩色輸出等功能，是一個非常不錯的命令行工具。

Vello : 2D 圖形的新型 GPU 加速渲染器改用wgpu

原文[56]

Vello[57]是一種用于 2D 圖形的新型 GPU 加速渲染器，其操作在很大程度上依賴于計算著色器。曾用名為 piet-gpu-hal，因為之前是基于 Piet 進行渲染，現(xiàn)在改名為 Vello 已經(jīng)依賴于`wgpu`[58]了。

Vello 作者 Raphlinus 是 GUI 領(lǐng)域資深開發(fā)者。引導(dǎo)開發(fā)過 Xi-Editor 和druid[59]。既然他決定將 Vello 大幅重寫改用 wgpu，那基本上wgpu(WebGPU API 的 Rust 實現(xiàn)) 可以看作是圖形渲染領(lǐng)域 的 Rust 事實性基礎(chǔ)設(shè)施了。

開源 Citadel 協(xié)議

“

值得一提的是，Citadel 協(xié)議在過去五年中，一直由作者單人開發(fā)維護，并未開源。但是，在最近他看到中國研究人員聲稱使用量子和經(jīng)典計算機的混合體破解了低級 RSA 加密——用于全球安全數(shù)據(jù)傳輸?shù)臉藴始用芊椒ā畎踩绺械襟@訝[60]的新聞，感到，開源 Citadel 協(xié)議是必須的了。。

“

來自中國鄭州數(shù)學(xué)工程與先進計算國家重點實驗室研究人員的新預(yù)印本論文引起了人們的關(guān)注。它提出了一種不同的算法，可以用低級量子計算機破解 2048 位 RSA。該團隊表示，他們使用基于 10 量子位量子計算機的混合系統(tǒng)破解了 48 位 RSA，如果他們能夠訪問至少具有 372 量子位的量子計算機，則可以對 2048 位做同樣的事情。這項工作反映了對混合量子/經(jīng)典解決方案的更大推動，其中包括日本理研研究所將量子計算機連接到自己的超級計算機 Fugaku的工作。

“

中國科學(xué)家真的用量子計算機破解了RSA加密嗎？科學(xué)家們表示，他們的方法可用于使用 372 量子位量子計算機來破解高級 2048 位 RSA 加密，這將具有重大的安全隱患。

Citadel[61]協(xié)議是一種用 Rust 編寫的高性能異步信號類協(xié)議，它通過使用多層棘輪、多層加密、后量子密鑰交換、可配置的真正完美前向保密（每個數(shù)據(jù)包都有一個通過重新加密的唯一加密密鑰）或盡力而為模式、文件傳輸加密、內(nèi)置 NAT 遍歷（無 libp2p）、可配置的憑據(jù)身份驗證（通過 argon-2id）、設(shè)備相關(guān)身份驗證或無密碼身份驗證等特征。

Citadel 協(xié)議建立在底層傳輸協(xié)議之上。TCP、TLS 或 QUIC 均可用于傳輸（混合加密的默認 TLS）。Citadel 協(xié)議用于在網(wǎng)絡(luò)中的節(jié)點之間進行通信。

網(wǎng)絡(luò)拓撲包含一個全局可訪問的中央節(jié)點，默認情況下，該節(jié)點用于對等點發(fā)現(xiàn)和 NAT 遍歷（該節(jié)點可以賦予它應(yīng)用程序邏輯，但不是必需的）。對等點連接到這個中央服務(wù)器，并且在注冊和連接后，能夠在彼此之間甚至中央服務(wù)器之間傳遞消息。

由于使用 UDP 更容易執(zhí)行 NAT 遍歷，因此 QUIC 協(xié)議用于 P2P 連接，因為這是免費的。對于客戶端到服務(wù)器的連接，服務(wù)器可以選擇使用 TCP、TLS 或 QUIC 作為底層協(xié)議。

使用 Citadel SDK，Rust 開發(fā)人員可以輕松創(chuàng)建適用于客戶端到服務(wù)器和 p2p 應(yīng)用程序的超安全后量子應(yīng)用程序。

Zenoh 0.7 發(fā)布

代號為 Charmander 的Eclipse Zenoh 0.7[62]版本發(fā)布。引入了一些期待已久的功能：

雙向 TLS 認證；

MQTT插件；

S3 存儲后端；

更多詳情參考Zenoh 官方介紹[63]。

safecloset: 跨平臺安全 TUI 私密信息存儲器

safecloset[64]將您的秘密保存在受密碼保護的文件中。SafeCloset旨在方便并避免常見的弱點，如外部編輯或?qū)懭氪疟P的臨時文件。

“

警告：SafeCloset未經(jīng)獨立審計，絕對不能提供任何保證。如果你丟失了存儲在 SafeCloset 中的秘密，作者表示他也無能為力。