Google在Chromium項(xiàng)目中支持使用Rust

Rust 1.66.1 發(fā)布

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

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

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

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

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

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

“

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

該漏洞是由 Julia 安全團(tuán)隊(duì) 提交給 Rust 安全團(tuán)隊(duì)。

Rust 1.68 中將更新 Android NDK

原文[4]

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

“

Android 中 NDK 工具鏈說明[5]

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

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

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

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

“

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

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

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

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

“

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

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

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

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

“

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

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

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

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

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

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

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

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

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

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

一個(gè)高贊回答如下：

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

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

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

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

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

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

Rust 應(yīng)用實(shí)踐

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

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

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

官宣：支持在 Chromium 項(xiàng)目中使用 Rust

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

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

為什么選擇將 Rust 引入 Chromium？

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

Chromium 將如何支持 Rust 的使用？

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

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

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

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

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

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

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

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

Chromium 團(tuán)隊(duì)認(rèn)為：

“

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

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

dora-rs：機(jī)器人中間件項(xiàng)目

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

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

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

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

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

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

官方原文[31]

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

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

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

“

點(diǎn)評(píng)：這次合作比等待 Autosar 直接引入 Rust 的效率高多了。

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

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

生態(tài)看點(diǎn)

flux: Rust 精化類型庫

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

“

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

為什么需要精化類型？

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

flux 通過 Rust 過程宏將精化類型帶到了 Rust 中，它在編譯時(shí)進(jìn)行檢查。

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

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

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

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

再看另一個(gè)示例：

#[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
}

測試代碼的第二個(gè)測試就會(huì)檢查失敗，因?yàn)樗粷M足前置條件。

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

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

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

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

Veryl Playground[41]

Veryl Book[42]

Veryl 的目標(biāo)是 SystemVerilog 的替代品。

“

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

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

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

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

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

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

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

“

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

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

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

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

Datacake是作者嘗試為 lnx 帶來高可用性的成果，分布式共識(shí)算法采用Quickwit[47]開發(fā)的chitchat[48]，它是 scuttlebutt 算法的實(shí)現(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)、模板庫以及可同時(shí)在服務(wù)器端和客戶端運(yùn)行的路由器。特點(diǎn)是，利用細(xì)粒度的反應(yīng)式來構(gòu)建用戶界面。

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

how-u-doin: Rust 的進(jìn)度報(bào)告抽象庫

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

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

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

0.29 版本特性摘要：

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

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

改進(jìn) WebAssembly 支持。引入fyrox-template（一個(gè)生成游戲項(xiàng)目和腳本模板的簡單工具）現(xiàn)在能夠?yàn)橛螒蛏蓡为?dú)版本的 WebAssembly 執(zhí)行器，幾乎可以毫不費(fèi)力地創(chuàng)建游戲的 WebAssembly 版本，并且也支持了一鍵部署 WebAssembly 。

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

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

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

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

使用godbolt.org[55]

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

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

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

原文[56]

Vello[57]是一種用于 2D 圖形的新型 GPU 加速渲染器，其操作在很大程度上依賴于計(jì)算著色器。曾用名為 piet-gpu-hal，因?yàn)橹笆腔?Piet 進(jìn)行渲染，現(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 實(shí)現(xiàn)) 可以看作是圖形渲染領(lǐng)域 的 Rust 事實(shí)性基礎(chǔ)設(shè)施了。

開源 Citadel 協(xié)議

“

值得一提的是，Citadel 協(xié)議在過去五年中，一直由作者單人開發(fā)維護(hù)，并未開源。但是，在最近他看到中國研究人員聲稱使用量子和經(jīng)典計(jì)算機(jī)的混合體破解了低級(jí) RSA 加密——用于全球安全數(shù)據(jù)傳輸?shù)臉?biāo)準(zhǔn)加密方法——令安全界感到驚訝[60]的新聞，感到，開源 Citadel 協(xié)議是必須的了。。

“

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

“

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

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

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

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

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

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

Zenoh 0.7 發(fā)布

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

雙向 TLS 認(rèn)證；

MQTT插件；

S3 存儲(chǔ)后端；

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

safecloset: 跨平臺(tái)安全 TUI 私密信息存儲(chǔ)器

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

“

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