#riir — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #riir, aggregated by home.social.
-
🦀 How (and why) we rewrote our production C++ frontend infrastructure in Rust
While memory-safe languages like Rust offer real benefits, serious cryptographic implementations inevitably rely on unsafe code, assembly, and low-level control, eroding those guarantees. At that point, the added abstraction often increases complexity without meaningfully reducing risk.
-
🦀 How (and why) we rewrote our production C++ frontend infrastructure in Rust
While memory-safe languages like Rust offer real benefits, serious cryptographic implementations inevitably rely on unsafe code, assembly, and low-level control, eroding those guarantees. At that point, the added abstraction often increases complexity without meaningfully reducing risk.
-
🦀 How (and why) we rewrote our production C++ frontend infrastructure in Rust
While memory-safe languages like Rust offer real benefits, serious cryptographic implementations inevitably rely on unsafe code, assembly, and low-level control, eroding those guarantees. At that point, the added abstraction often increases complexity without meaningfully reducing risk.
-
🦀 How (and why) we rewrote our production C++ frontend infrastructure in Rust
While memory-safe languages like Rust offer real benefits, serious cryptographic implementations inevitably rely on unsafe code, assembly, and low-level control, eroding those guarantees. At that point, the added abstraction often increases complexity without meaningfully reducing risk.
-
🦀 How (and why) we rewrote our production C++ frontend infrastructure in Rust
While memory-safe languages like Rust offer real benefits, serious cryptographic implementations inevitably rely on unsafe code, assembly, and low-level control, eroding those guarantees. At that point, the added abstraction often increases complexity without meaningfully reducing risk.
-
Feeling a lot a sense that the first builds need to maximalize adaptability, refactorability. Only after digging in for a bit & building does what we are actually going reveal itself. Optimize for that velocity! Then go back & Rewrite It In Rust! #riir #🦀 On port-ability: bsky.app/profile/jaun...
RE: https://bsky.app/profile/did:plc:zjbq26wybii5ojoypkso2mso/post/3mjur7xzzts2j -
Should i #RIIR 20yo a strange attractor renderer as a project to teach myself rust?
-
Should i #RIIR 20yo a strange attractor renderer as a project to teach myself rust?
-
Should i #RIIR 20yo a strange attractor renderer as a project to teach myself rust?
-
🦀 Ladybird ❤️ Vibecoding ❤️ Rust
https://ladybird.org/posts/adopting-rust/ -
🦀 Ladybird ❤️ Vibecoding ❤️ Rust
https://ladybird.org/posts/adopting-rust/ -
🦀 Ladybird ❤️ Vibecoding ❤️ Rust
https://ladybird.org/posts/adopting-rust/ -
🦀 Ladybird ❤️ Vibecoding ❤️ Rust
https://ladybird.org/posts/adopting-rust/ -
🦀 Ladybird ❤️ Vibecoding ❤️ Rust
https://ladybird.org/posts/adopting-rust/ -
🦀 Iron Wolf: wolf3D in Rust
-
🦀 Iron Wolf: wolf3D in Rust
-
🦀 Iron Wolf: wolf3D in Rust
-
🦀 Iron Wolf: wolf3D in Rust
-
🦀 Iron Wolf: wolf3D in Rust
-
I've recently been rewriting my substitution-tiling transducers code in #RustLang, replacing the old Sage code.
One reason is that Sage is harder to run these days. It vanished from Ubuntu some time between 22.04 and 24.04 and hasn't (yet?) come back.
Another reason was that reimplementing all my algorithms from scratch was a valuable exercise in making sure I understood them, when I wrote them up for my arXiv preprint. (Which I'm hoping to produce an improved edition of at some point, filling in some gaps.)
But the third reason is shown in these pictures. The hexagonal one is straight from one of my blog posts, showing the centre of one of the 6-way 'singular' instances of the Spectre tiling. It takes my Sage code 2 minutes in total to generate that SVG.
The second image is the result of the Rust version of the code working for the same 2 minutes. The hexagon marked in the middle shows the boundary of what the Sage code had calculated. Much faster!
-
I've recently been rewriting my substitution-tiling transducers code in #RustLang, replacing the old Sage code.
One reason is that Sage is harder to run these days. It vanished from Ubuntu some time between 22.04 and 24.04 and hasn't (yet?) come back.
Another reason was that reimplementing all my algorithms from scratch was a valuable exercise in making sure I understood them, when I wrote them up for my arXiv preprint. (Which I'm hoping to produce an improved edition of at some point, filling in some gaps.)
But the third reason is shown in these pictures. The hexagonal one is straight from one of my blog posts, showing the centre of one of the 6-way 'singular' instances of the Spectre tiling. It takes my Sage code 2 minutes in total to generate that SVG.
The second image is the result of the Rust version of the code working for the same 2 minutes. The hexagon marked in the middle shows the boundary of what the Sage code had calculated. Much faster!
-
I've recently been rewriting my substitution-tiling transducers code in #RustLang, replacing the old Sage code.
One reason is that Sage is harder to run these days. It vanished from Ubuntu some time between 22.04 and 24.04 and hasn't (yet?) come back.
Another reason was that reimplementing all my algorithms from scratch was a valuable exercise in making sure I understood them, when I wrote them up for my arXiv preprint. (Which I'm hoping to produce an improved edition of at some point, filling in some gaps.)
But the third reason is shown in these pictures. The hexagonal one is straight from one of my blog posts, showing the centre of one of the 6-way 'singular' instances of the Spectre tiling. It takes my Sage code 2 minutes in total to generate that SVG.
The second image is the result of the Rust version of the code working for the same 2 minutes. The hexagon marked in the middle shows the boundary of what the Sage code had calculated. Much faster!
-
I've recently been rewriting my substitution-tiling transducers code in #RustLang, replacing the old Sage code.
One reason is that Sage is harder to run these days. It vanished from Ubuntu some time between 22.04 and 24.04 and hasn't (yet?) come back.
Another reason was that reimplementing all my algorithms from scratch was a valuable exercise in making sure I understood them, when I wrote them up for my arXiv preprint. (Which I'm hoping to produce an improved edition of at some point, filling in some gaps.)
But the third reason is shown in these pictures. The hexagonal one is straight from one of my blog posts, showing the centre of one of the 6-way 'singular' instances of the Spectre tiling. It takes my Sage code 2 minutes in total to generate that SVG.
The second image is the result of the Rust version of the code working for the same 2 minutes. The hexagon marked in the middle shows the boundary of what the Sage code had calculated. Much faster!
-
I've recently been rewriting my substitution-tiling transducers code in #RustLang, replacing the old Sage code.
One reason is that Sage is harder to run these days. It vanished from Ubuntu some time between 22.04 and 24.04 and hasn't (yet?) come back.
Another reason was that reimplementing all my algorithms from scratch was a valuable exercise in making sure I understood them, when I wrote them up for my arXiv preprint. (Which I'm hoping to produce an improved edition of at some point, filling in some gaps.)
But the third reason is shown in these pictures. The hexagonal one is straight from one of my blog posts, showing the centre of one of the 6-way 'singular' instances of the Spectre tiling. It takes my Sage code 2 minutes in total to generate that SVG.
The second image is the result of the Rust version of the code working for the same 2 minutes. The hexagon marked in the middle shows the boundary of what the Sage code had calculated. Much faster!
-
A port on #localhost open only to one process. Can #linux #network namespaces help me?
Let's find out.
The idea is to MitM between my IMAP server and Claws Mail. The proxy would ignore the password and instead use #TLS with a client #certificate to authenticate me (mTLS style).
This way, there's one less #password to store in RAM and accidentally exfiltrate.
As much as I like the Claws UI, it's crashy and I don't trust its #security a lot. #RiiR anyone :P?
-
A port on #localhost open only to one process. Can #linux #network namespaces help me?
Let's find out.
The idea is to MitM between my IMAP server and Claws Mail. The proxy would ignore the password and instead use #TLS with a client #certificate to authenticate me (mTLS style).
This way, there's one less #password to store in RAM and accidentally exfiltrate.
As much as I like the Claws UI, it's crashy and I don't trust its #security a lot. #RiiR anyone :P?
-
A port on #localhost open only to one process. Can #linux #network namespaces help me?
Let's find out.
The idea is to MitM between my IMAP server and Claws Mail. The proxy would ignore the password and instead use #TLS with a client #certificate to authenticate me (mTLS style).
This way, there's one less #password to store in RAM and accidentally exfiltrate.
As much as I like the Claws UI, it's crashy and I don't trust its #security a lot. #RiiR anyone :P?
-
A port on #localhost open only to one process. Can #linux #network namespaces help me?
Let's find out.
The idea is to MitM between my IMAP server and Claws Mail. The proxy would ignore the password and instead use #TLS with a client #certificate to authenticate me (mTLS style).
This way, there's one less #password to store in RAM and accidentally exfiltrate.
As much as I like the Claws UI, it's crashy and I don't trust its #security a lot. #RiiR anyone :P?
-
A port on #localhost open only to one process. Can #linux #network namespaces help me?
Let's find out.
The idea is to MitM between my IMAP server and Claws Mail. The proxy would ignore the password and instead use #TLS with a client #certificate to authenticate me (mTLS style).
This way, there's one less #password to store in RAM and accidentally exfiltrate.
As much as I like the Claws UI, it's crashy and I don't trust its #security a lot. #RiiR anyone :P?
-
CPython core developers are considering introducing Rust to the codebase. A lot of them are in favor, including Guido.
“Rust will initially only be allowed for writing optional extension modules, but eventually will become a required dependency of CPython and allowed to be used throughout the CPython code base.”
https://discuss.python.org/t/pre-pep-rust-for-cpython/104906
-
CPython core developers are considering introducing Rust to the codebase. A lot of them are in favor, including Guido.
“Rust will initially only be allowed for writing optional extension modules, but eventually will become a required dependency of CPython and allowed to be used throughout the CPython code base.”
https://discuss.python.org/t/pre-pep-rust-for-cpython/104906
-
CPython core developers are considering introducing Rust to the codebase. A lot of them are in favor, including Guido.
“Rust will initially only be allowed for writing optional extension modules, but eventually will become a required dependency of CPython and allowed to be used throughout the CPython code base.”
https://discuss.python.org/t/pre-pep-rust-for-cpython/104906
-
CPython core developers are considering introducing Rust to the codebase. A lot of them are in favor, including Guido.
“Rust will initially only be allowed for writing optional extension modules, but eventually will become a required dependency of CPython and allowed to be used throughout the CPython code base.”
https://discuss.python.org/t/pre-pep-rust-for-cpython/104906
-
CPython core developers are considering introducing Rust to the codebase. A lot of them are in favor, including Guido.
“Rust will initially only be allowed for writing optional extension modules, but eventually will become a required dependency of CPython and allowed to be used throughout the CPython code base.”
https://discuss.python.org/t/pre-pep-rust-for-cpython/104906
-
Android team at Google posted another update of their use of Rust as a replacement for C and C++.
Switching to Rust for writing performance sensitive and low level code allowed them to reduce memory safety vulnerabilities from ~70% to below 20% of total vulnerabilities for the first time.
Notable quotes:
"We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code. But the biggest surprise was Rust's impact on software delivery. With Rust changes having a 4x lower rollback rate and spending 25% less time in code review, the safer path is now also the faster one."
"For medium and large changes, the rollback rate of Rust changes in Android is ~4x lower than C++. This low rollback rate doesn't just indicate stability; it actively improves overall development throughput. Rollbacks are highly disruptive to productivity, introducing organizational friction and mobilizing resources far beyond the developer who submitted the faulty change. Rollbacks necessitate rework and more code reviews, can also lead to build respins, postmortems, and blockage of other teams. Resulting postmortems often introduce new safeguards that add even more development overhead."
"In a self-reported survey from 2022, Google software engineers reported that Rust is both easier to review and more likely to be correct. The hard data on rollback rates and review times validates those impressions."
"With roughly 5 million lines of Rust in the Android platform and one potential memory safety vulnerability found (and fixed pre-release), our estimated vulnerability density for Rust is 0.2 vuln per 1 million lines (MLOC)."
"Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Our Rust code is currently tracking at a density orders of magnitude lower: a more than 1000x reduction."
Do read the whole blog post. It's very informative.
https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html
-
Android team at Google posted another update of their use of Rust as a replacement for C and C++.
Switching to Rust for writing performance sensitive and low level code allowed them to reduce memory safety vulnerabilities from ~70% to below 20% of total vulnerabilities for the first time.
Notable quotes:
"We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code. But the biggest surprise was Rust's impact on software delivery. With Rust changes having a 4x lower rollback rate and spending 25% less time in code review, the safer path is now also the faster one."
"For medium and large changes, the rollback rate of Rust changes in Android is ~4x lower than C++. This low rollback rate doesn't just indicate stability; it actively improves overall development throughput. Rollbacks are highly disruptive to productivity, introducing organizational friction and mobilizing resources far beyond the developer who submitted the faulty change. Rollbacks necessitate rework and more code reviews, can also lead to build respins, postmortems, and blockage of other teams. Resulting postmortems often introduce new safeguards that add even more development overhead."
"In a self-reported survey from 2022, Google software engineers reported that Rust is both easier to review and more likely to be correct. The hard data on rollback rates and review times validates those impressions."
"With roughly 5 million lines of Rust in the Android platform and one potential memory safety vulnerability found (and fixed pre-release), our estimated vulnerability density for Rust is 0.2 vuln per 1 million lines (MLOC)."
"Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Our Rust code is currently tracking at a density orders of magnitude lower: a more than 1000x reduction."
Do read the whole blog post. It's very informative.
https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html
-
Android team at Google posted another update of their use of Rust as a replacement for C and C++.
Switching to Rust for writing performance sensitive and low level code allowed them to reduce memory safety vulnerabilities from ~70% to below 20% of total vulnerabilities for the first time.
Notable quotes:
"We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code. But the biggest surprise was Rust's impact on software delivery. With Rust changes having a 4x lower rollback rate and spending 25% less time in code review, the safer path is now also the faster one."
"For medium and large changes, the rollback rate of Rust changes in Android is ~4x lower than C++. This low rollback rate doesn't just indicate stability; it actively improves overall development throughput. Rollbacks are highly disruptive to productivity, introducing organizational friction and mobilizing resources far beyond the developer who submitted the faulty change. Rollbacks necessitate rework and more code reviews, can also lead to build respins, postmortems, and blockage of other teams. Resulting postmortems often introduce new safeguards that add even more development overhead."
"In a self-reported survey from 2022, Google software engineers reported that Rust is both easier to review and more likely to be correct. The hard data on rollback rates and review times validates those impressions."
"With roughly 5 million lines of Rust in the Android platform and one potential memory safety vulnerability found (and fixed pre-release), our estimated vulnerability density for Rust is 0.2 vuln per 1 million lines (MLOC)."
"Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Our Rust code is currently tracking at a density orders of magnitude lower: a more than 1000x reduction."
Do read the whole blog post. It's very informative.
https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html
