Rust

Going public today is CVE-2025-62518, or better known by the name given by the security researchers involved: TARmageddon. The TARmageddon vulnerability affects the popular async-tar Rust library and its various forks like tokio-tar. In turn TARmageddon impacts the uv Python package manager and other users of this library.

Edera made public today their discovery of a critical boundary-parsing bug in the async-tar Rust library and downstream forks like tokio-tar. TARmageddon is rated as a "high" severity bug and can lead to remote code execution through file overwriting attacks.

I'm happy to have finally fixed the issue we had with LTO (link-time optimization) and with cross-language LTO!

https://crates.io/search?q=fnmatch

https://crates.io/crates/fnmatch-regex at version v0.2.1, repository: https://gitlab.com/ppentchev/fnmatch-regex-rs

https://crates.io/crates/fnmatch-regex2 at version v0.4.0, repository: https://gitlab.com/brmmm3/fnmatch-regex2-rs (DO NOT SIGN IN, UNTIL WE KNOW ITS SAFE)

I was looking through some crates and noticed there is "fnmatch-regex2", just below "fnmatch-regex". The second one is newer; 4 months ago updated, compared to the original 12 months ago updated. And it has more recent downloads and a "higher version number".

My first thought was, this either adds new functionality, or the old one is abandoned maybe? Looking in readme and documentation, I could not find anything that describes the differences. Looking at the source code on Gitlab, the first crate just shows it normally to me, but the second wants me to log in. My alarm glocks go on. Even the changelog for both are identical at version 0.2.1 (the original crate 1) without any word about changes, but the crate repository shows it should be at version v0.4.0.

I would like to know what you guys think about it. I can't even audit the code right now, even if its the same Gitlab instance on gitlab.com. Should this be reported? Or am I just paranoid?

EDIT:

After asking in Discord, someone said I can view the source code in Docs.rs: https://docs.rs/crate/fnmatch-regex2/0.4.0/source/ . This is much better, but I am still cautious. I still don't know what the actual changes are and would need to dive into the code and compare to find out. Which is not really something I expect to do from a trustful library.

Hey all, I've been contemplating what approach I should take in my app, think along the lines of mapping with lots of UI elements but also a 2D portal/window for showing the map etc.

I want it to be cross platform so thought I'd go with Egui and look at implementing the "game" parts to that. But as I thought more about it, maybe it would be more beneficial to use Bevy and rely on its UI framework.

Thoughts? Maybe Bevy would be easier, but might be too much of a hit on performance because its not a game that I'm making. Egui might be more difficult to add the game stuff, but more performant and not running a full game engine.

I'm really conflicted. It would be good to be able to turn off/disable the game part of it to reduce load if it isn't needed at the time

I'm impressed with how many great tools have been created in a short period of time. The Rust community really pulled together and made sure that there are Rust alternatives to as many tools out there as possible.

Thank you so much, and keep up with great work!

Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @thisweekinrust.bsky.social on Bluesky or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR.

Want TWIR in your inbox? Subscribe here.

There was recently this article about Linus Torvalds' issues with rustfmt, which prompted others to voice their agreement with his sentiment online.

Yesterday someone pointed out how rustfmt is effectively unmaintained with basically no activity on the repository for months.

The contributors graph shows a similar story - there is essentially no development happening on rustfmt, it seems.

cross-posted from: https://programming.dev/post/38555081

I've just finished up version 1.2.2 for Auditorium - a fast local music player powered by Ratatui.

Since my last update, I've added a few new fun features:

• Optional MPRIS support to allow global access to the underlying music player (pause, play, seek, view album art, and more from your desktop environment!)
• Album/track sorting based on track number metadata
• Switched from FfProbe to ID3 crate for huge load time decreases
• Optional cover art display
• Made lots of efficiency tweaks to take down CPU usage to < 2% while still running at 60 fps (fast TUI is a good TUI)

Lots of things I still would like to add (and a few issues already underway), so I hope to find time to improve more when I can.

Cheers

Awful Rustdocs is a CLI tool that generates or improves Rustdoc comments by harvesting symbols via rust_ast.nu, enriching each item with ast-grep context (callers, intra-body calls, qualified paths), and prompting your LLM to produce concise, high-quality docs.

You don't need hundreds of prompts and agents if you're smart about your context.

I'm running it on all my Rust projects right now using the Systems Programming Qwen 3 4B finetune I created, and it saves me an incredible amount of time by creating docs that are almost always good enough to publish straight off but act more as a draft for me. It cuts down on a lot of repetitive typing and lets me get back to doing what I love (writing code).

It requires Nushell, but you should probably already be using that, and if this is how you find out about Nushell, then even better, make the jump; it's worth it.

I'm happy to announce the release of diesel-async 0.7. This release makes diesel-async compatible with the recent Diesel 2.3 release. It also contains an easier way to execute migrations and improved ergonomics for using pipelined queries with the PostgreSQL connection type.

I'm happy to answer questions about this release.

cross-posted from: https://programming.dev/post/38340328

Hey all, just wondering if there are blogs or podcasts out there that cover common design patterns in Rust. I'm a Java dev and have tried a few times to get into Rust, but it feels like I'm solving problems in a way that aren't the most optimal for Rust because I'm still in that Java mindset.

Anyway I'm working on an XMPP client and my current challenge is working to implement some sort of event/listener system where I can trigger functions when I receive certain XMPP message types.

I put together a simple XML parser to deserialize (haven't done serialisation yet) messages which I can then determine the type of message it is. I was thinking maybe an event driven setup might work best here but not sure where to start in a Rust idiomatic way.

The idea would be we receive a Proceed message for TLS negotiation, this would trigger the tls_upgrade function which itself will send messages and need to react to the response as part of the negotiation step. But, again I'm not sure this would even be the best approach.

What I'm doing now is calling the tls_upgrade function which will do its own handling of sending a negotiation message, then looping on read_line on the stream hoping that the next message is the next needed message in the negotiation process.

So some advice on common patterns used in Rust in blog form or even podcasts would be a good learning resource.

Cheers.

A cloudflare dev answered some questions in the reddit thread: https://www.reddit.com/r/rust/s/1Dm0KmhgzQ