fidzu : Mozilla

Also known as "you can just put whatever you want in a jitdump you know?"

When you profile JIT code, you have to tell a profiler what on earth is going on in those JIT bytes you wrote out. Otherwise the profiler will shrug and just give you some addresses.

There's a decent and fairly common format called jitdump, which originates in perf but has become used in more places. The basic thrust of the parts we care about is: you have names associated with ranges.

Of course, the basic range you'd expect to name is "function foo() was compiled to bytes 0x1000-0x1400"

Suppose you get that working. You might get a profile that looks like this one.

This profile is pretty useful: You can see from the flame chart what execution tier created the code being executed, you can see code from inline caches etc.

Before I left for Christmas break though, I had a thought: To a first approximation both -optimized- and baseline code generation is fairly 'template' style. That is to say, we emit (relatively) stable chunks of code for either one of our bytecodes, in the case of our baseline compiler, or for one of our intermediate-representation nodes in the case of Ion, our top tier compiler.

What if we looked more closely at that?

Some of our code is already tagged with AutoCreatedBy, and RAII class which pushes a creator string on, and pops it off when it's not used. I went through and added AutoCreatedBy to each of the LIR op's codegen methods (e.g. CodeGenerator::visit*). Then I rigged up our JITDump support so that instead of dumping functions, we dump the function name + whole chain of AutoCreatedBy as the 'function name' for that sequence of instructions generated while the AutoCreatedBy was live.

That gets us this profile

While it doesn't look that different, the key is in how the frames are named. Of course, the vast majority of frames just are the name of the call instruction... that only makes sense. However, you can see some interesting things if you invert the call-tree

For example, we spend 1.9% of the profiled time doing for a single self-hosted function 'visitHasShape', which is basically:

masm.loadObjShapeUnsafe(obj, output);
  masm.cmpPtrSet(Assembler::Equal, output, ImmGCPtr(ins->mir()->shape()),
                 output);

Which is not particularly complicated.

Ok so that proves out the value. What if we just say... hmmm. I actually want to aggregate across all compilation; ignore the function name, just tell me the compilation path here.

Woah. Ok, now we've got something quite different, if really hard to interpret

Even more interesting (easier to interpret) is the inverted call tree:

So across the whole program, we're spending basically 5% of the time doing guardShape. I think that's a super interesting slicing of the data.

Is it actionable? I don't know yet. I haven't opened any bugs really on this yet; a lot of the highlighted code is stuff where it's not clear that there is a faster way to do what's being done, outside of engine architectural innovation.

The reason to write this blog post is basically to share that... man we can slice-and-dice our programs in so many interesting ways. I'm sure there's more to think of. For example, not shown here was an experiment: I added AutoCreatedBy inside a single macro-assembler method set (around barriers) to try and see if I could actually see GC barrier cost (it's low on the benchmarks I checked yo).

So yeah. You can just... put stuff in your JIT dump file.

Edited to Add: I should mention this code is nowhere. Given I don't entirely know how actionable this ends up being, and the code quality is subpar, I haven't even pushed this code. Think of this as an inspiration, not a feature announcement.

08 Jan 2026 9:46pm GMT

The future of intelligence is being set right now, and the path we're on leads somewhere I don't want to go. We're drifting toward a world where intelligence is something you rent - where your ability to reason, create, and decide flows through systems you don't control, can't inspect, and didn't shape. In that world, the landlord can change the terms anytime, and you have no recourse but to accept what you're given.

I think we can do better. Making that happen is now central to what Mozilla is doing.

What we did for the web

Twenty-five years ago, Microsoft Internet Explorer controlled 95% of the browser market, which meant Microsoft controlled how most people experienced the internet and who could build what on what terms. Mozilla was born to change this, and Firefox succeeded beyond what most people thought possible - dropping Internet Explorer's market share to 55% in just a few years and ushering in the Web 2.0 era. The result was a fundamentally different internet. It was faster and richer for everyday users, and for developers it was a launchpad for open standards and open source that decentralized control over the core technologies of the web.

There's a reason the browser is called a "user agent." It was designed to be on your side - blocking ads, protecting your privacy, giving you choices that the sites you visited never would have offered on their own. That was the first fight, and we held the line for the open web even as social networks and mobile platforms became walled gardens.

Now AI is becoming the new intermediary. It's what I've started calling "Layer 8" - the agentic layer that mediates between you and everything else on the internet. These systems will negotiate on our behalf, filter our information, shape our recommendations, and increasingly determine how we interact with the entire digital world.

The question we have to ask is straightforward: Whose side will your new user agent be on?

Why closed systems are winning (for now)

We need to be honest about the current state of play: Closed AI systems are winning today because they are genuinely easier to use. If you're a developer with an idea you want to test, you can have a working prototype in minutes using a single API call to one of the major providers. GPUs, models, hosting, guardrails, monitoring, billing - it all comes bundled together in a package that just works. I understand the appeal firsthand, because I've made the same choice myself on late-night side projects when I just wanted the fastest path from an idea in my head to something I could actually play with.

The open-source AI ecosystem is a different story. It's powerful and advancing rapidly, but it's also deeply fragmented - models live in one repository, tooling in another, and the pieces you need for evaluation, orchestration, guardrails, memory, and data pipelines are scattered across dozens of independent projects with different assumptions and interfaces. Each component is improving at remarkable speed, but they rarely integrate smoothly out of the box, and assembling a production-ready stack requires expertise and time that most teams simply don't have to spare. This is the core challenge we face, and it's important to name it clearly: What we're dealing with isn't a values problem where developers are choosing convenience over principle. It's a developer experience problem. And developer experience problems can be solved.

The ground is already shifting

We've watched this dynamic play out before and the history is instructive. In the early days of the personal computer, open systems were rough, inconsistent, and difficult to use, while closed platforms offered polish and simplicity that made them look inevitable. Openness won anyway - not because users cared about principles, but because open systems unlocked experimentation and scale that closed alternatives couldn't match. The same pattern repeated on the web, where closed portals like AOL and CompuServe dominated the early landscape before open standards outpaced them through sheer flexibility and the compounding benefits of broad participation.

AI has the potential to follow the same path - but only if someone builds it. And several shifts are already reshaping the landscape:

• Small models have gotten remarkably good. 1 to 8 billion parameters, tuned for specific tasks - and they run on hardware that organizations already own;
• The economics are changing too. As enterprises feel the constraints of closed dependencies, self-hosting is starting to look like sound business rather than ideological commitment (companies like Pinterest have attributed millions of dollars in savings to migrating to open-source AI infrastructure);
• Governments want control over their supply chain. Governments are becoming increasingly unwilling to depend on foreign platforms for capabilities they consider strategically important, driving demand for sovereign systems; and,
• Consumer expectations keep rising. People want AI that responds instantly, understands their context, and works across their tools without locking them into a single platform.

The capability gap that once justified the dominance of closed systems is closing fast. What remains is a gap in usability and integration. The lesson I take from history is that openness doesn't win by being more principled than the alternatives. Openness wins when it becomes the better deal - cheaper, more capable, and just as easy to use

Where the cracks are forming

If openness is going to win, it won't happen everywhere at once. It will happen at specific tipping points - places where the defaults haven't yet hardened, where a well-timed push can change what becomes normal. We see four.

The first is developer experience. Developers are the ones who actually build the future - every default they set, every stack they choose, every dependency they adopt shapes what becomes normal for everyone else. Right now, the fastest path runs through closed APIs, and that's where most of the building is happening. But developers don't want to be locked in any more than users do. Give them open tools that work as well as the closed ones, and they'll build the open ecosystem themselves.

The second is data. For a decade, the assumption has been that data is free to scrape - that the web is a commons to be harvested without asking. That norm is breaking, and not a moment too soon. The people and communities who create valuable data deserve a say in how it's used and a share in the value it creates. We're moving toward a world of licensed, provenance-based, permissioned data. The infrastructure for that transition is still being built, which means there's still a chance to build it right.

The third is models. The dominant architecture today favors only the biggest labs, because only they can afford to train massive dense transformers. But the edges are accelerating: small models, mixtures of experts, domain-specific models, multilingual models. As these approaches mature, the ability to create and customize intelligence spreads to communities, companies, and countries that were previously locked out.

The fourth is compute. This remains the choke point. Access to specialized hardware still determines who can train and deploy at scale. More doors need to open - through distributed compute, federated approaches, sovereign clouds, idle GPUs finding productive use.

What an open stack could look like

Today's dominant AI platforms are building vertically integrated stacks: closed applications on top of closed models trained on closed data, running on closed compute. Each layer reinforces the next - data improves models, models improve applications, applications generate more data that only the platform can use. It's a powerful flywheel. If it continues unchallenged, we arrive at an AI era equivalent to AOL, except far more centralized. You don't build on the platform; you build inside it.

There's another path. The sum of Linux, Apache, MySQL, and PHP won because that combination became easier to use than the proprietary alternatives, and because they let developers build things that no commercial platform would have prioritized. The web we have today exists because that stack existed.

We think AI can follow the same pattern. Not one stack controlled by any single party, but many stacks shaped by the communities, countries, and companies that use them:

• Open developer interfaces at the top. SDKs, guardrails, workflows, and orchestration that don't lock you into a single vendor;
• Open data standards underneath. Provenance, consent, and portability built in by default, so you know where your training data came from and who has rights to it;
• An open model ecosystem below that. Smaller, specialized, interchangeable models that you can inspect, tune to your values, and run where you need them; and
• Open compute infrastructure at the foundation. Distributed and federated hardware across cloud and edge, not routed through a handful of hyperscn/lallers.

Pieces of this stack already exist - good ones, built by talented people. The task now is to fill in the gaps, connect what's there, and make the whole thing as easy to use as the closed alternatives. That's the work.

Why open source matters here

If you've followed Mozilla, you know the Manifesto. For almost 20 years, it's guided what we build and how - not as an abstract ideal, but as a tool for making principled decisions every single day. Three of its principles are especially urgent in the age of AI:

• Human agency. In a world of AI agents, it's more important than ever that technology lets people shape their own experiences - and protects privacy where it matters most;
• Decentralization and open source. An open, accessible internet depends on innovation and broad participation in how technology gets created and used. The success of open-source AI, built around transparent community practices, is critical to making this possible; and
• Balancing commercial and public benefit. The direction of AI is being set by commercial players. We need strong public-benefit players to create balance in the overall ecosystem.

Open-source AI is how these principles become real. It's what makes plurality possible - many intelligences shaped by many communities, not one model to rule them all. It's what makes sovereignty possible - owning your infrastructure rather than renting it. And it's what keeps the door open for public-benefit alternatives to exist alongside commercial ones.

What we'll do in 2026

The window to shape these defaults is still open, but it won't stay open forever. Here's where we're putting our effort - not because we have all the answers, but because we think these are the places where openness can still reset the defaults before they harden.

Make open AI easier than closed. Mozilla.ai is building any-suite, a modular framework that integrates the scattered components of the open AI stack - model routing, evaluation, guardrails, memory, orchestration - into something coherent that developers can actually adopt without becoming infrastructure specialists. The goal is concrete: Getting started with open AI should feel as simple as making a single API call.

Shift the economics of data. The Mozilla Data Collective is building a marketplace for data that is properly licensed, clearly sourced, and aligned with the values of the communities it comes from. It gives developers access to high-quality training data while ensuring that the people and institutions who contribute that data have real agency and share in the economic value it creates.

Learn from real deployments. Strategy that isn't grounded in practical experience is just speculation, so we're deepening our engagement with governments and enterprises adopting sovereign, auditable AI systems. These engagements are the feedback loops that tell us where the stack breaks and where openness needs reinforcement.

Invest in the ecosystem. We're not just building; we're backing others who are building too. Mozilla Ventures is investing in open-source AI companies that align with these principles. Mozilla Foundation is funding researchers and projects through targeted grants. We can't do everything ourselves, and we shouldn't try. The goal is to put resources behind the people and teams already doing the work.

Show up for the community. The open-source AI ecosystem is vast, and it's hard to know what's working, what's hype, and where the real momentum is building. We want to be useful here. We're launching a newsletter to track what's actually happening in open AI. We're running meetups and hackathons to bring builders together. We're fielding developer surveys to understand what people actually need. And at MozFest this year, we're adding a dedicated developer track focused on open-source AI. If you're doing important work in this space, we want to help it find the people who need to see it.

Are you in?

Mozilla is one piece of a much larger movement, and we have no interest in trying to own or control it - we just want to help it succeed. There's a growing community of people who believe the open internet is still worth defending and who are working to ensure that AI develops along a different path than the one the largest platforms have laid out. Not everyone in that community uses the same language or builds exactly the same things, but something like a shared purpose is emerging. Mozilla sees itself as part of that effort.

We kept the web open not by asking anyone's permission, but by building something that worked better than the alternatives. We're ready to do that again.

So: Are you in?

If you're a developer building toward an open source AI future, we want to work with you. If you're a researcher, investor, policymaker, or founder aligned with these goals, let's talk. If you're at a company that wants to build with us rather than against us, the door is open. Open alternatives have to exist - that keeps everyone honest.

The future of intelligence is being set now. The question is whether you'll own it, or rent it.

We're launching a newsletter to track what's happening in open-source AI - what's working, what's hype, and where the real momentum is building. Sign up here to follow along as we build.

Read more here about our emerging strategy, and how we're rewiring Mozilla for the era of AI.

The post Owners, not renters: Mozilla's open source AI strategy appeared first on The Mozilla Blog.

08 Jan 2026 7:05pm GMT

While nearly half of all Firefox users have installed an add-on, it's safe to say nearly all Firefox staffers use add-ons. I polled a few of my peers and here are some of our staff favorite add-ons of 2025…

Falling Snow Animated Theme

Enjoy the soothing mood of Falling Snow Animated Theme. This motion-animated dark theme turns Firefox into a calm wintry night as snowflakes cascade around the corners of your browser.

Privacy Badger

The flagship anti-tracking extension from privacy proponents at the Electronic Frontier Foundation, Privacy Badger is built to look for a certain set of actions that indicate a web page is trying to secretly track you.

Zero set up required. Just install Privacy Badger and it will automatically search for third-party cookies, HTML5 local storage "supercookies," canvas fingerprinting, and other sneaky tracking methods.

Adaptive Tab Bar Color

Turn Firefox into an internet chameleon. Adaptive Tab Bar Color changes the colors of Firefox to match whatever website you're visiting.

It's beautifully simple and sublime. No setup required, but you're free to make subtle adjustments to color contrast patterns and assign specific colors for websites.

Rainy Spring Sakura by MaDonna

Created by one of the most prolific theme designers in the Firefox community, MaDonna, we love Rainy Spring Sakura's bucolic mix of calming colors.

It's like instant Zen mode for Firefox.

Return YouTube Dislike

Do you like the Dislike? YouTube removed the thumbs-down display, but fortunately Return YouTube Dislike came along to restore our view into the sometimes brutal truth of audience sentiment.

Other Firefox users seem to agree…

"Does exactly what the name suggests. Can't see myself without this extension. Seriously, bad move on YouTube for removing such a vital tool."

Firefox user OFG

"i have never smashed 5 stars faster."

Firefox user 12918016

<figcaption class="wp-element-caption">Return YouTube Dislike re-enables a beloved feature.</figcaption>

LeechBlock NG

Block time-wasting websites with LeechBlock NG - easily one of our staff-favorite productivity tools.

Lots of customization features help you stay focused and free from websites that have a way of dragging you down. Key features:

• Block entire websites or just portions (e.g. allow YouTube video pages but block the homepage)
• Block websites based on time of day, day of the week, or both
• Time limit customization (e.g. only 1 hour of Reddit per day)

DarkSpaceBlue

Drift through serene outer space as you browse the web. DarkSpaceBlue celebrates the infinite wonder of life among the stars.

LanguageTool - Grammar and Spell Checker

Improve your prose anywhere you write on the web. LanguageTool - Grammar and Spell Checker will make you a better writer in 25+ languages.

Much more than a basic spell checker, this privacy-centric writing aid is packed with great features:

• Offers alternate phrasing for brevity and clarity
• Recognizes common misuses of similar sounding words (e.g. there/their, your/you're)
• Works with all web-based email and social media
• Provides synonyms for overused words

<figcaption class="wp-element-caption">LanguageTool can help with subtle syntax improvements. </figcaption>

Sink It for Reddit!

Imagine a more focused and free feeling Reddit - that's Sink It for Reddit!

Some of our staff-favorite features include:

• Custom content muting (e.g. ad blocking, remove app install and login prompts)
• Color-coded comments
• Streamlined navigation
• Adaptive dark mode

Sushi Nori

Turns out we have quite a few sushi fans at Firefox. We celebrate our love of sushi with the savory theme Sushi Nori.

08 Jan 2026 2:59pm GMT

A Year in Data

As is tradition, we're wrapping up 2025 for Mozilla's localization efforts and offering a sneak peek at what's in store for 2026 (you can find last year's blog post here).

Pontoon's metrics in 2025 show a stable picture for both new sign-ups and monthly active users. While we always hope to see signs of strong growth, this flat trend is a positive achievement when viewed against the challenges surrounding community involvement in Open Source, even beyond Mozilla. Thank you to everyone actively participating on Pontoon, Matrix, and elsewhere for making Mozilla localization such an open and welcoming community.

• 30 projects and 469 locales (+100 compared to 2024) set up in Pontoon.
• 5,019 new user registrations
• 1,190 active users, submitting at least one translation, on average 233 users per month (+5% Year-over-Year)
• 551,378 submitted translations (+18% YoY)
• 472,195 approved translations (+22% YoY)
• 13,002 new strings to translate (-38% YoY).

The number of strings added has decreased significantly overall, but not for Firefox, where the number of new strings was 60% higher than in 2024 (check out the increase of Fluent strings alone). That is not surprising, given the amount of new features (selectable profiles, unified trust panel, backup) and the upcoming settings redesign.

As in 2024, the relentless growth in the number of locales is driven by Common Voice, which now has 422 locales enabled in Pontoon (+33%).

Before we move forward, thank you to all the volunteers who contributed their time, passion, and expertise to Mozilla's localization over the last 12 months - or plan to do so in 2026. There is always space for new contributors!

Pontoon Development

A significant part of the work on Pontoon in 2025 isn't immediately visible to users, but it lays the groundwork for improvements that will start showing up in 2026.

One of the biggest efforts was switching to a new data model to represent all strings across all supported formats. Pontoon currently needs to handle around ten different formats, as transparently as possible for localizers, and this change is a step to reduce complexity and technical debt. As a concrete outcome, we can now support proper pluralization in Android projects, and we landed the first string using this model in Firefox 146. This removes long-standing UX limitations (no more Bookmarks saved: %1$s instead of %1$s bookmarks saved) and allows languages to provide more natural-sounding translations.

In parallel, we continued investing in a unified localization library, moz-l10n, with the goal of having a centralized, well-maintained place to handle parsing and serialization across formats in both JavaScript and Python. This work is essential to keep Pontoon maintainable as we add support for new technologies and workflows.

Pontoon as a project remains very active. In 2025 alone, Pontoon saw more than 200 commits from over 20 contributors, not including work happening in external libraries such as moz-l10n.

Finally, we've been improving API support, another area that is largely invisible to end users. We moved away from GraphQL and migrated to Django REST, and we're actively working toward feature parity with Transvision to better support automation and integrations.

Community

Our main achievement in 2025 was organizing a pilot in-person event in Berlin, reconnecting localizers from around Europe after a long hiatus. Fourteen volunteers from 11 locales spent a weekend together at the Mozilla Berlin office, sharing ideas, discussing challenges, and deepening relationships that had previously existed only online. For many attendees, this was the first time they met fellow contributors they had collaborated with for years, and the energy and motivation that came out of those days clearly showed the value of human connection in sustaining our global community.

This doesn't mean we stopped exploring other ways to connect. For example, throughout the year we continued publishing Contributor Spotlights, showcasing the amazing work of individual volunteers from different parts of the world. These stories highlight not just what our contributors do, but who they are and why they make Mozilla's localization work possible.

Internally, these spotlights have played an important role for advocating on behalf of the community. By bringing real voices and contributions to the forefront, we've helped reinforce the message that investing in people - not just tools - is essential to the long-term health of Mozilla's localization ecosystem.

What's coming in 2026

As we move into the new year, our focus will shift to exploring alternative deployment solutions. Our goal is to make Pontoon faster, more reliable, and better equipped to meet the needs of our users.

This excerpt comes from last year's blog post, and while it took longer than expected, the good news is that we're finally there. On January 6, we moved Pontoon to a new hosting platform. We expect this change to bring better reliability and performance, especially in response to peaks in bot traffic that have previously made Pontoon slow or unresponsive.

In parallel, we "silently" launched the Mozilla Language Portal, a unified hub that reflects Mozilla's unique approach to localization while serving as a central resource for the global translator community. While we still plan to expand its content, the main infrastructure is now in place and publicly available, bringing together searchable translation memories, documentation, blog posts, and other resources to support knowledge-sharing and collaboration.

On the technology side, we plan to extend plural support to iOS projects and continue improving Pontoon's translation memory support. These improvements aim to make it easier to reuse translations across projects and formats, for example by matching strings independently of placeholder syntax differences, and to translate Fluent strings with multiple values.

We also aim to explore improvements in our machine translation options, evaluating how large language models could help with quality assessment or serve as alternative providers for MT suggestions.

Last but not least, we plan to keep investing in our community. While we don't know yet what that will look like in practice, keep an eye on this blog for updates.

If you have any thoughts or ideas about this plan, let us know on Mastodon or Matrix!

Thank you!

As we look toward 2026, we're grateful for the people who make Mozilla's localization possible. Through shared effort and collaboration, we'll continue breaking down barriers and building a web that works for everyone. Thank you for being part of this journey.

07 Jan 2026 1:51pm GMT

To answer that question, we first need to understand how complex, writing or maintaining a web browser is.

A "modern" web browser is :

• a network stack,
• and html+[1] parser,
• and image+[2] decoder,
• a javascript[3] interpreter compiler,
• a User's interface,
• integration with the underlying OS[4],
• And all the other things I'm currently forgetting.

Of course, all the above point are interacting with one another in different ways. In order for "the web" to work, standards are developed and then implemented in the different browsers, rendering engines.

In order to "make" the browser, you need engineers to write and maintain the code, which is probably around 30 Million lines of code[5] for Firefox. Once the code is written, it needs to be compiled [6] and tested [6]. This requires machines that run the operating system the browser ships to (As of this day, mozilla officially ships on Linux, Microslop Windows and MacOS X - community builds for *BSD do exists and are maintained). You need engineers to maintain the compile (build) infrastructure.

Once the engineers that are responsible for the releases [7] have decided what codes and features were mature enough, they start assembling the bits of code and like the engineers, build, test and send the results to the people using said web browser.

When I was employed at Mozilla (the company that makes Firefox) around 900+ engineers were tasked with the above and a few more were working on research and development. These engineers are working 5 days a week, 8 hours per day, that's 1872000 hours of engineering brain power spent every year (It's actually less because I have not taken vacations into account) on making Firefox versions. On top of that, you need to add the cost of building and running the test before a new version reaches the end user.

The current browsing landscape looks dark, there are currently 3 choices for rendering engines, KHTML based browsers, blink based ones and gecko based ones. 90+% of the market is dominated by KHTML/blink based browsers. Blink is a fork of KHTML. This leads to less standard work, if the major engine implements a feature and others need to play catchup to stay relevant, this has happened in the 2000s with IE dominating the browser landscape[8], making it difficult to use macOS 9 or X (I'm not even mentioning Linux here :)). This also leads to most web developers using Chrome and once in a while testing with Firefox or even Safari. But if there's a little glitch, they can still ship because of market shares.

Firefox was started back in 1998, when embedding software was not really a thing with all the platform that were to be supported. Firefox is very hard to embed (eg use as a softwrae library and add stuff on top). I know that for a fact because both Camino and Thunderbird are embeding gecko.

In the last few years, Mozilla has been itching the people I connect to, who are very privacy focus and do not see with a good eye what Mozilla does with Firefox. I believe that Mozilla does this in order to stay relevant to normal users. It needs to stay relevant for at least two things :

1. Keep the web standards open, so anyone can implement a web browser / web services.
2. to have enough traffic to be able to pay all the engineers working on gecko.

Now that, I've explained a few important things, let's answer the question "Are mozilla's fork any good?"

I am biased as I've worked for the company before. But how can a few people, even if they are good and have plenty of free time, be able to cope with what maintaining a fork requires :

• following security patches and porting said patches.
• following development and maintain their branch with changes coming all over the place
• how do they test?

If you are comfortable with that, then using a fork because Mozilla is pushing stuff you don't want is probably doable. If not, you can always kill those features you don't like using some `about:config` magic.

Now, I've set a tone above that foresees a dark future for open web technologies. What Can you do to keep the web open and with some privacy focus?

1. Keep using Mozilla Nightly
2. Give servo a try

[1] HTML is interpreted code, that's why it needs to be parsed and then rendered.

[2] In order to draw and image or a photo on a screen, you need to be able to encode it or decode it. Many file formats are available.

[3] Is a computer language that transforms HTML into something that can interact with the person using the web browser. See https://developer.mozilla.org/en-US/docs/Glossary/JavaScript

[4] Operating systems need to the very least know which program to open files with. The OS landscape has changed a lot over the last 25 years. These days you need to support 3 major OS, while in the 2000s you had more systems, IRIX for example. You still have some portions of the Mozilla code base that support these long dead systems.

[5]https://math.answers.com/math-and-arithmetic/How_many_lines_of_code_in_mozillafirefox

[6] Testing implies, testing the code and also having engineers or users using the unfinished product to see that it doesn't regress. Testing Mozilla, is explained at https://ehsanakhgari.org/wp-content/uploads/talks/test-mozilla/

[7] Read a release equals a version. Version 1.5 is a release, as is version 3.0.1.

[8] https://en.wikipedia.org/wiki/Browser_wars

07 Jan 2026 1:26pm GMT

VStarcam is an important brand of cameras based on the PPPP protocol. Unlike the LookCam cameras I looked into earlier, these are often being positioned as security cameras. And they in fact do a few things better like… well, like having a mostly working authentication mechanism. In order to access the camera one has to know its administrator password.

So much for the theory. When I looked into the firmware of the cameras I discovered a surprising development: over the past years this protection has been systematically undermined. Various mechanisms have been added that leak the access password, and in several cases these cannot be explained as accidents. The overall tendency is clear: for some reason VStarcam really wants to have access to their customer's passwords.

A reminder: "P2P" functionality based on the PPPP protocol means that these cameras will always communicate with and be accessible from the internet, even when located on a home network behind NAT. Short of installing a custom firmware this can only addressed by configuring the network firewall to deny internet access.

How to recognize affected cameras

Not every VStarcam camera has "VStarcam" printed on the side. I have seen reports of VStarcam cameras being sold under the brand names Besder, MVPower, AOMG, OUSKI, and there are probably more.

Most cameras should be recognizable by the app used to manage them. Any camera managed by one of these apps should be a VStarcam camera: Eye4, EyeCloud, FEC Smart Home, HOTKam, O-KAM Pro, PnPCam, VeePai, VeeRecon, Veesky, VKAM, VsCam, VStarcam Ultra.

Downloading the firmware

VStarcam cameras have a mechanism to deliver firmware updates (LookCam cameras prove that this shouldn't be taken for granted). The app managing the camera will request update information from an address like http://api4.eye4.cn:808/firmware/1.2.3.4/EN where 1.2.3.4 is the firmware version. If a firmware update is available the response will contain a download server and a download path. The app sends these to the device which then downloads and installs the updated firmware.

Both requests are performed over plain HTTP and this is already the first issue. If an attacker can produce a manipulated response either on the network that the app or the device are connected to they will be able to install a malicious update on the camera. The former is particularly problematic, as the camera owner may connect to an open WiFi or similarly untrusted networks while being out.

The last part of a firmware version is a build number which is ignored for the update requests. The first part is a vendor ID where only a few options seem relevant (I checked 10, 48 and 66). The rest of the version number can be easily enumerated. Many firmware branches don't have an active update, and when they do some updates won't download because the servers in question appear no longer operational. Still, I found 380 updates this way.

I managed to unpack all but one of these updates. Firmware version 10.1.110.2 wasn't for a camera but rather some device with an HDMI connector and without any P2P functionality - probably a Network Video Recorder (NVR). Firmware version 10.121.160.42 wasn't using PPPP but something called NHEP2P and an entirely different application-level protocol. Ten updates weren't updating the camera application but only the base system. This left 367 firmware versions for this investigation.

Caveats of this survey

I do not own any VStarcam hardware, nor would it be feasible to investigate hundreds of different firmware versions with real hardware. The results of this article are based solely on reverse engineering, emulation, and automated analysis via running Ghidra in headless mode. While I can easily emulate a PPPP server, doing the same for the VStarcam cloud infrastructure isn't possible, I simply don't know how it behaves. Similarly, the firmware's interaction with hardware had to be left out of the emulation. While I'm still quite confident in my results, these limitations could introduce errors.

More importantly, there are only so many firmware versions that I checked manually. Most of them were checked automatically, and I typically only looked at a few lines of decompiled code that my scripts extracted. There is potential for false negatives here, I expect that there are more issues with VStarcam firmware than what's listed here.

VStarcam's authentication approach

When an app communicates with a camera, it sends commands like GET /check_user.cgi?loginuse=admin&loginpas=888888&user=admin&pwd=888888. Despite the looks of it, these aren't HTTP requests passed on to a web server. Instead, the firmware handles these in function P2pCgiParamFunction which doesn't even attempt to parse the request. The processing code looks for substrings like check_user.cgi to identify the command (yes, you better don't set check_user.cgi as your access password). Parameter extraction works via similar substring matching.

It's worth noting that these cameras have a very peculiar authentication system which VStarcam calls "dual authentication." Here is how the Eye4 application describes it:

The dual authentication mechanism is a measure to upgrade the whole system security

1. The device will double check the identity of the visitor and does not support the old version of app.
2. Considering the security risk of possible leakage, the plaintext password mode of the device was turned off and ciphertext access was used.
3. After the device is added for the first time, it will not be allowed to be added for a second time, and it will be shared by the person who has added it.

I'm not saying that this description is utter bullshit but there is a considerable mismatch with the reality that I can observe. The VStarcam firmware cannot accept anything other than plaintext passwords. Newer firmware versions employ obfuscation on the PPPP-level but this hardly deserves the name "ciphertext".

What I can see is: once a device is enrolled into dual authentication, the authentication is handled by function GetUserPri_doubleVerify rather than GetUserPri. There isn't a big difference between the two, both will try the credentials from the loginuse/loginpas parameters and fall back to the user/pwd credentials pair. Function GetUserPri_doubleVerify merely checks a different password.

From the applications I get the impression that the dual authentication password is automatically generated and probably not even shared with the user but stored in their cloud account. This is an improvement over the regular password that defaults to 888888 and allowed these cameras to be enrolled into a botnet. But it's still a plaintext password used for authentication.

There is a second aspect to dual authentication. When dual authentication is used, the app is supposed to make a second authentication call to eye4_authentication.cgi. The loginAccount and loginToken parameters here appear to belong to the user's cloud account, apparently meant to make sure that only the right user can access a device.

Yet in many firmware versions I've seen the eye4_authentication.cgi request always succeeds. The function meant to perform a web request is simply hardcoded to return the success code 200. Other firmware versions actually make a request to https://verification.eye4.cn, yet this server also seems to produce a 200 response regardless of what parameters I try. It seems that VStarcam never made this feature work the way they intended it.

None of this stopped VStarcam from boasting on their website merely a year ago:

You can certainly count on anything saying "financial grade encryption" being bullshit. I have no idea where AES comes into the picture here, I haven't seen it being used anywhere. Maybe it's their way of saying "we use TLS when connecting to our cloud infrastructure."

Endpoint protection

A reasonable approach to authentication is: authentication is required before any requests unrelated to authentication can be made. This is not the approach taken by VStarcam firmware. Instead, some firmware versions decide for each endpoint individually whether authentication is necessary. Other versions put a bunch of endpoints outside of the code enforcing authentication.

The calls explicitly excluded from authentication differ by firmware version but are for example: get_online_log.cgi, show_prodhwfg.cgi, ircut_test.cgi, clear_log.cgi, alexa_ctrl.cgi, server_auth.cgi. For most of these it isn't obvious why they should be accessible to unauthenticated users. But get_online_log.cgi caught my attention in particular.

Unauthenticated log access

So a request like GET /get_online_log.cgi?enable=1 can be sent to a camera without any authentication. This isn't a request that any of the VStarcam apps seem to support, what does it do?

Despite the name this isn't a download request, it rather sets a flag for the current connection. The logic behind this involves many moving parts including a Linux kernel module but the essence is this: whenever the application logs something via LogSystem_WriteLog function, the application won't merely print that to stderr and write it to the log file on the SD card but also send it to any connection that has this flag set.

What does the application log? Lots and lots of stuff. On average, VStarcam firmware has around 1500 such logging calls. For example, it could log security tokens:

LogSystem_WriteLog("qiniu.c", "upload_qiniu", 497, 0,
                   "upload_qiniu*** filename = %s, fileid = %s, uptoken = %s\n", …);
LogSystem_WriteLog("pushservice.c", "parsePushServerRequest_cjson", 5281, 1,
                   "address=%s token =%s master= %d timestamp = %d", …);
LogSystem_WriteLog("queue.c", "CloudUp_Manage_Pth", 347, 2,
                   "token=%s", …);

It could log cloud server responses:

LogSystem_WriteLog("pushservice.c", "curlPostMqttAuthCb", 4407, 3,
                   "\n\nrspBuf = %s\n", …);
LogSystem_WriteLog("post/postFileToCloud.c", "curl_post_file_cb", 74, 0,
                   "\n\nrspBuf = %s\n", …);
LogSystem_WriteLog("pushserver.c", "curl_Eye4Authentication_write_data_cb", 2822, 0,
                   "rspBuf = %s", …);

And of course it will log the requests coming in via PPPP:

LogSystem_WriteLog("vstcp2pcmd.c", "P2pCgiParamFunction", 633, 0,
                   "sit %d, pcmd: %s", …);

Reminder: these requests contain the authentication password as parameter. So an attacker can connect to a vulnerable device, request logs and wait for the legitimate device owner to connect. Once they do their password will show up in the logs - voila, the attacker has access now.

VStarcam appears to be at least somewhat aware of this issue because some firmware versions contain code "censoring" password parameters prior to logging:

memcpy(pcmd, request, sizeof(pcmd));
char* pos = strstr(pcmd, "loginuse");
if (pos)
  *pos = 0;
LogSystem_WriteLog("vstcp2pcmd.c", "P2pCgiParamFunction", 633, 0,
                   "sit %d, pcmd: %s", sit, pcmd);

But that's only the beginning of the story of course.

Explicit password leaking via logs

In addition to the logging calls where the password leaks as a (possibly unintended) side-effect, some logging calls are specifically designed to write the device password to the log. For example, the function GetUserPri meant to handle authentication when dual authentication isn't enabled will often do something like this on a failed login attempt:

LogSystem_WriteLog("sysparamapp.c", "GetUserPri", 177, 0,
                   "loginuse=%s&loginpas=%s&user=admin&pwd=888888&", gUser, gPassword);

These aren't the parameters of a received login attempt but rather what the parameters should look like for the request to succeed. And if the attacker enabled log access for their connection they will get the device credentials handed on a silver platter - without even having to wait for the device owner to connect.

If dual authentication is enabled, function GetUserPri_doubleVerify often contains a similar call:

LogSystem_WriteLog("web.c", "GetUserPri_doubleVerify", 536, 0,
                   "pri[%d] system OwnerPwd[%s] app Pwd[%s]",
                   pri, gOwnerPassword, gAppPassword);

Log uploading

What got me confused at first were the firmware versions that would log the "correct" password on failed authentication attempts but lacked the capability for unauthenticated log access. When I looked closer I found the function DoSendLogToNodeServer. The firmware receives a "node configuration" from a server which includes a "push IP" and the corresponding port number. It then opens a persistent TCP connection to that address (unencrypted of course), so that DoSendLogToNodeServer can send messages to it.

Despite the name this function doesn't upload all of the application logs. There are only three to four DoSendLogToNodeServer calls in the firmware versions I looked at, and two are invariably found in function P2pCgiParamFunction, in code running on first failed authentication attempt:

sprintf(buffer,"password error [doublePwd][%s], [PassWd][%s]", gOwnerPassword, gPassword);
DoSendLogToNodeServer(request);
DoSendLogToNodeServer(buffer);

This is sending both the failed authentication request and the correct passwords to a VStarcam server. So while the password isn't being leaked here to everybody who knows how to ask, it's still being leaked to VStarcam themselves. And anybody who is eavesdropping on the device's traffic of course.

A few firmware versions have log upload functionality in a function called startUploadLogToServer, here really all logging output is being uploaded to the server. This one isn't called unconditionally however but rather enabled by the setLogUploadEnable.cgi endpoint. An endpoint which, you guessed it, can be accessed without authentication. But at least these firmware versions don't seem to have any explicit password logging, only the "regular" logging of requests.

Password-leaking backdoor

With some considerable effort all of the above could be explained as debugging functionality which was mistakenly shipped to production. VStarcam wouldn't be the first company to fail realizing that functionality labeled "for debugging purposes only" will still be abused if released with the production build of their software. But I found yet another password leak which can only be described as a backdoor.

At some point VStarcam introduced a second version of their get_online_log.cgi API. When that second version is requested the device will respond with something like:

result=0;
index=12345678;
str=abababababab;

The result=0 part is typical and indicates that authentication (or lack thereof in this case) was successful. The other two values are unusual, and eventually I decided to check what they were about. Turned out, str is a hex-encoded version of the device password after it was XOR'ed with a random byte. And index is an obfuscated representation of that byte.

I can only explain it like this: somebody at VStarcam thought that leaking passwords via log output was too obvious, people might notice. So they decided to expose the device password in a more subtle way, one that only they knew how to decode (unless somebody notices this functionality and spends two minutes studying it in the firmware).

Mind you, even though this is clearly a backdoor I'm still not ruling out incompetence. Maybe VStarcam made a large enough mess with their dual authentication that their customer support needs to recover device access on a regular basis. However, they do have device reset functionality that should normally be used for this scenario.

In the end, for their customers it doesn't matter what the intention was. The result is a device that cannot be trusted with protecting access. For a security camera this is an unforgivable flaw.

Establishing a timeline

Now we are coming to the tough questions. Why do some firmware versions have this backdoor functionality while others don't? When was this introduced? In what order? What is the current state of affairs?

You might think that after compiling the data on 367 firmware versions the answers would be obvious. But the data is so inconsistent that any conclusions are really difficult. Thing is, we aren't dealing with a single evolving codebase here. We aren't even dealing with two codebases or a dozen of them. 367 firmware versions are 367 different codebases. These codebases are related, they share some code here and there, but they are all being developed independently.

I've seen this development model before. What VStarcam appears to be doing is: for every new camera model they take some existing firmware and fork it. They adjust that firmware for the new hardware, they probably add new features as well. None of this work makes it into the original firmware unless it is explicitly backported. And since VStarcam is maintaining hundreds of firmware variants, the older ones are usually only receiving maintenance changes if any at all.

To make this mess complete, VStarcam's firmware version numbers don't make any sense at all. And I don't mean the fact that VStarcam releases the same camera under 30 different model names, so there is no chance of figuring out the model to firmware version mapping. It's also the firmware version numbers themselves.

As I've already mentioned, the last part of the firmware version is the build number, increased with each release. The first part is the vendor ID: firmware versions starting with 48 are VStarcam's global releases whereas 66 is reserved for their Russian distributor (or rather was I think). Current VStarcam firmware is usually released with vendor ID 10 however, standing for… who knows, VeePai maybe? This leaves the two version parts in between, and I couldn't find any logic here whatsoever. Like, firmware versions sharing the third part of the version number would sometimes be closely related, but only sometimes. At the same time the second part of the version number is supposed to represent the camera model, but that's clearly not always correct either.

I ended up extracting all the logging calls from all the firmware versions and using that data to calculate a distance between every firmware version pair. I then fed this data into GraphViz and asked it to arrange the graph for me. It gave me the VStarcam spiral galaxy:

Click the image above to see the larger and slightly interactive version (it shows additional information when the mouse pointer is at a graph node). The green nodes are the ones that don't allow access to device logs. Yellow are the ones providing unauthenticated log access, always logging incoming requests including their password parameters. The orange ones have additional logging that exposes the correct password on failed authentication attempts - or they call DoSendLogToNodeServer function to send the correct password to a VStarcam server. The red ones have the backdoor in the get_online_log.cgi API leaking passwords. Finally pink are the ones which pretend to improve things by censoring parameters of logged requests - yet all of these without exception leak the password via the backdoor in the get_online_log.cgi API.

Note: Firmware version 10.165.19.37 isn't present in the graph because it is somehow based on an entirely different codebase with no relation to the others. It would be red in the graph however, as the backdoor has been implemented here as well.

Not only does this graph show the firmware versions as clusters, it's also possible to approximately identify the direction of time for each cluster. Let's add cluster names and time arrows to the image:

Of course this isn't a perfect representation of the original data, and I wasn't sure whether it could be trusted. Are these clusters real or merely an artifact produced by the graph algorithm? I verified things manually and could confirm that the clusters are in fact distinctly different on the technical level, particularly when considering updates format:

• Clusters A and B represent firmware for ARM processors. I'm unsure what caused the gap between the two clusters but cluster A contains firmware from years 2019 and 2020, cluster B on the other hand is mostly years 2021 and 2022. Development pretty much stopped here, the only exception being the four red firmware versions which are recent. Updates use the "classic" ZIP format here.
• Cluster C covers years 2019 to 2022. Quite remarkably, in these years the firmware from this cluster moved from ARM processors and LiteOS to MIPS processors and Linux. The original updates based on VStarcam Pack System were replaced by the VeePai-branded ZIP format and later by Ingenic updates with LZO compression. All that happened without introducing significant changes to the code but rather via incremental development.
• Cluster D contains firmware for the MIPS processors from years 2022 and 2023. Updates are using the VeePai-branded ZIP format.
• Cluster E formed around 2023, there is still some development being done here. It uses MIPS processors like cluster D, yet the update format is different (what I called VeePai updates in my previous blog post).
• Cluster F has seen continuous development since approximately 2022, this is firmware based on Ingenic's MIPS hardware and the most active branch of VStarcam development. Originally the VeePai-branded ZIP format was used for updates, this was later transitioned to Ingenic updates with LZO compression and finally to the same format with jzlcma compression.

With the firmware versions ordered like this I could finally make some conclusions about the introduction of the problematic features:

• Unauthenticated logs access via the get_online_log.cgi API was introduced in cluster B around 2022.
• Logging the correct password on failed attempts was introduced independently in cluster C. In fact, some firmware versions had this in 2020 already.
• In 2021 cluster C also added the innovation that was DoSendLogToNodeServer function, sending the correct password to a VStarcam server on first failed login attempt.
• Unauthenticated logs access and logging the correct password appear to have been combined in cluster D in 2023.
• Cluster E initially also adopted the approach of exposing log access and logging device password on failed attempts, adding the sending of the correct password to a VStarcam server to the mix. However, starting in 2024 firmware versions with the get_online_log.cgi backdoor start popping up here, and these have all other password leaks removed. These even censor passwords in logged request parameters. Either there were security considerations at play or the other ways to expose the password were considered unnecessary at this point and too obvious.
• Cluster F also introduced logging device password on failed attempts around 2023. This cluster appears to be the origin of the get_online_log.cgi backdoor, it was introduced here around 2024. Unlike with cluster E this backdoor didn't replace the existing password leaks here but only complemented them. In fact, while cluster F was initially "censoring" parameters so that logged requests wouldn't leak passwords, this measure appears to have been dropped later in 2024. Current cluster F firmware tends to have all the issues described in this post simultaneously. Whatever security considerations may have driven the changes in cluster E, the people in charge of cluster F clearly disagreed.

The impact

So, how bad is it? Knowing the access password allows access to the camera's main functionality: audio and video recordings. But these cameras have been known for vulnerabilities allowing execution of arbitrary commands. Also, newer cameras have an API that will start a telnet server with hardcoded and widely known administrator credentials (older cameras had this telnet server start by default). So we have to assume that a compromised camera could become part of a botnet or be used as a starting point for attacks against a network.

But this requires accessing the camera first, and most VStarcam cameras won't be exposed to the internet directly. They will only be reachable via the PPPP protocol. And for that the attackers would need to know the device ID. How would they get it?

There is a number of ways, most of which I've already discussed before. For example, anybody who was briefly connected to your network could have collected device IDs of your cameras. The script to do that won't currently work with newer VStarcam cameras because these obfuscate the traffic on the PPPP level but the necessary adjustments aren't exactly complicated.

PPPP networks still support "supernodes," devices that help route traffic. Back in 2019 Paul Marrapese abused that functionality to register a rogue supernode and collect device IDs en masse. There is no indication that this trick stopped working, and the VStarcam networks are likely susceptible as well.

Users also tend to leak their device IDs themselves. They will post screenshots or videos of the app's user interface. On the first glance this is less problematic with the O-KAM Pro app because this one will display only a vendor-specific device ID (looks similar to a PPPP device ID but has seven digits and only four letters in the verification code). That is, until you notice that the app uses a public web API to translate vendor-specific device IDs into PPPP device IDs.

Anybody who can intercept some PPPP traffic can extract the device IDs from it. Even when VStarcam networks obfuscate the traffic rather than using plaintext transmission - the static keys are well known, removing the obfuscation isn't hard.

And finally, simply guessing device IDs is still possible. With only 5 million possible verification codes for each device IDs and servers not implementing rate limiting, bruteforce attacks are quite realistic.

Let's not forget the elephant in the room however: VStarcam themselves know all the device IDs of course. Not just that, they know which devices are active and where. With a password they can access the cameras of interest to them (or their government) anytime.

Coordinated disclosure attempt

Given the intentional nature of these issues, I was unsure how to deal with this. I mean, what's the point of reporting vulnerabilities to VStarcam that they are clearly aware of? In the end I decided to give them a chance to address the issues before they become public knowledge.

However, all I found was VStarcam boasting about their ISO 27001:2022 compliance. My understanding is that this requires them to have a dedicated person responsible for vulnerability management, but they are not obliged to list any security contact that can be reached from outside the company - and so they don't. I ended up emailing all company addresses I could find, asking whether there is any way to report security issues to them.

I haven't received any response, an experience that in my understanding other people already made with VStarcam. So I went with my initial publication schedule rather than waiting 90 days as I would normally do.

Recommendations

Whatever motives VStarcam had to backdoor their cameras, the consequence for the customers is: these cameras cannot be trusted. Their access protection should be considered compromised. Even with firmware versions shown as green on my map, there is no guarantee that I haven't missed something or that these will still be green after the next update.

If you want to keep using a VStarcam camera, the only safe way to do it is disconnecting it from the internet. They don't have to be disconnected physically, internet routers will often have a way to prohibit internet traffic to and from particular devices. My router for example has this feature under parental control.

Of course this will mean that you will only be able to control your camera while connected to the same network. It might be possible to explicitly configure port forwarding for the camera's RTSP port, allowing you to access at least the video stream from outside. Just make sure that your RTSP password isn't known to VStarcam.

07 Jan 2026 1:01pm GMT

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.

Updates from Rust Community

Official

• This Development-cycle in Cargo: 1.93
• Project goals update - December 2025

Newsletters

• This Month in Rust OSDev: December 2025
• The Embedded Rustacean Issue #62

Project/Tooling Updates

• Danube Messaging v0.6 - Introduces Schema Registry
• Releasing Fjall 3.0: log-structured key-value storage engine

Observations/Thoughts

• 1160 PRs to improve Rust in 2025
• [series] Who Owns the Memory? Part 3: How Big Is your Type?
• Even Safer Rust with Miri
• [uv] OnceMap: Rust Pattern for Running Concurrent Work Exactly Once
• Rust At Scale: Scaleway's Big Bet To Become THE European Hyperscaler

Rust Walkthroughs

• Introduction to SIMD programming in pure Rust
• Stop Forwarding Errors, Start Designing Them
• Designing APIs for the Pit of Success
• Rusty CDK, an Infrastructure as Code Experiment
• Ergonomic Async trait objects in Rust
• [video] Unlocking Cargo. Towards conncurrent cargo builds and cross workspace caching
• [audio] Netstack.FM episode 21 - GraphQL and Rust with Tom Houlé
• That mockingbird won't sing: a mock API server in Rust
• [ES] GoF Design Patterns in Rust: Necessary or Optional?
• [video] Tock, an embedded OS in Rust, overview and demo (3 videos in playlist)

Research

• How Safe is the Rust Ecosystem? A Deep Dive into crates.io

Crate of the Week

This week's crate is kameo, an asynchronous actor framework with clear, trait-based abstractions for actors and typed messages.

Thanks to edgimar for the suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.

If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

• No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs.

Let us know if you would like your feature to be tracked as a part of this list.

Call for Participation; projects and speakers

CFP - Projects

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon!

CFP - Events

Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.

• RustWeek 2026 | CFP closes 2026-01-18 | Utrecht, The Netherlands | 2026-05-19 - 2026-05-20
• RustConf 2026 | CFP closes 2026-02-16 | Montreal, Quebec, Canada | 2026-09-08 - 2026-09-10

If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon!

Updates from the Rust Project

341 pull requests were merged in the last week

Compiler

• make inliner cycle detection a fallible process
• remove Span from segments of AttrPath

Library

• oneshot Channel
• add VecDeque::splice
• add specialization for deque1.prepend(deque2.drain(range)) (VecDeque::prepend and extend_front)
• avoid index check in char::to_lowercase and char::to_uppercase
• make specialization of Vec::extend and VecDeque::extend_front work for vec::IntoIter with any Allocator, not just Global
• implement TryFrom<char> for usize
• improve alloc Vec::retain_mut performance

Cargo

• feat(report): add cargo report rebuilds
• feat(test-support): Use test name for dir when running tests
• fix(log): add dependencies field to UnitRegistered
• any build scripts can now use cargo::metadata=KEY=VALUE
• implement fine grain locking for build-dir
• refactor: migrate some cases to expect/reason

Clippy

• manual_div_ceil: Added check for variant x.next_multiple_of(y) / y
• transmuting_null: Check single expression const blocks and blocks
• do not make suggestion machine-applicable if it may change semantics
• fix bool_assert_comparison suggests wrongly for macros
• fix implicit_saturating_sub suggests wrongly on untyped int literal
• fix multiple_inherent_impl false negatives for generic impl blocks
• fix needless_for_each false negative when for_each is in the expr of a block
• fix new_without_default misses where clause in new
• fix redundant_pattern_matching misses ) in suggestion span
• fix cmp_owned wrongly unmangled macros
• move multiple_bound_locations to style

Rust-Analyzer

• add useless prefix try_into_ for suggest_name
• allow finding references from doc comments
• add #[rust_analyzer::macro_style()] attribute to control macro completion brace style
• add location links for generic parameter type hints
• fix incorrect dyn hint in impl Trait for
• fix source text
• don't fire non_camel_case_types lint for structs/enums marked with repr(C)
• have an upvars_mentioned() query that only computes what upvars a closure captures
• suppress false positive missing assoc item diag on specialization
• implement Span::line() and Span::column() for proc-macro server
• migrate move_arm_cond_to_match_guard assist to use SyntaxEditor
• compress token trees for best memory usage
• only compute lang items for #![feature(lang_items)] crates
• re-use scratch allocations for try_evaluate_obligations
• pre-allocate intern storages with 64kb of data / 1024 elements
• proc-macro-srv: support file and local_file via bidirectional callbacks

Rust Compiler Performance Triage

Not many PRs were merged, as it was still mostly a holiday week. #149681 caused small regressions across the board, this is pending investigation.

Triage done by @kobzol. Revision range: 112a2742..7c04f5d2

Summary:

2 Regressions, 0 Improvements, 7 Mixed; 4 of them in rollups 51 artifact comparisons made in total

Full report here.

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week: * build-std: context

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

Tracking Issues & PRs

Rust

• refactor: remove Ord bound from BinaryHeap::new etc
• regression: "the parameter type T may not live long enough" in offset_of!
• Tracking Issue for peekable_next_if_map

Compiler Team (MCPs only)

• Lint unsupported, target-specifc codegen flags

No Items entered Final Comment Period this week for Cargo, Rust RFCs, Leadership Council, Language Team, Language Reference or Unsafe Code Guidelines.

Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.

New and Updated RFCs

• RFC: Trait Implementation Privacy with permits

Upcoming Events

Rusty Events between 2026-01-07 - 2026-02-04 🦀

Virtual

• 2026-01-07 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-01-07 | Virtual (Indianapolis, IN, US) | Indy Rust
  • Indy.rs - with Social Distancing
• 2026-01-08 | Virtual (Charlottesville, VA, US) | Charlottesville Rust Meetup
  • Meet, swap, and learn!
• 2026-01-08 | Virtual (Nürnberg, DE) | Rust Nuremberg
  • Rust Nürnberg online
• 2026-01-13 | Virtual | libp2p Events
  • rust-libp2p Open Maintainers Call
• 2026-01-13 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Second Tuesday
• 2026-01-13 | Virtual (Tel Aviv-yafo, IL) | Code Mavens 🦀 - 🐍 - 🐪
  • Live Open Source Rust project contribution
• 2026-01-15 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • Janurary, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-01-15 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-01-18 | Virtual (Tel Aviv-yafo, IL) | Code Mavens 🦀 - 🐍 - 🐪
  • Live Open Source Rust project contribution
• 2026-01-20 | Virtual (Washington, DC, US) | Rust DC
  • Mid-month Rustful
• 2026-01-21 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-01-21 | Virtual (Vancouver, BC, CA) | Vancouver Rust
  • Stack Safety
• 2026-01-27 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Fourth Tuesday
• 2026-01-28 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-01-29 | Virtual (Amsterdam, NL) | Bevy Game Development
  • Bevy Meetup #12
• 2026-01-29 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-01-29 | Virtual (Charlottesville, VA, US) | Charlottesville Rust Meetup
  • Tock OS Part #2 - Rusty processes, memory limits, and basic capsules
• 2026-02-04 | Virtual (Indianapolis, IN, US) | Indy Rust
  • Indy.rs - with Social Distancing

Asia

• 2026-01-07 | Tel Aviv-yafo, IL | Rust 🦀 TLV
  • In person Rust January 2026 at AWS in Tel Aviv
• 2026-01-08 | Seoul, KR | Seoul Rust (Programming Language) Meetup
  • Seoul Rust Meetup
• 2026-01-17 | Delhi, IN | Rust Delhi
  • Rust Delhi Meetup #12

Europe

• 2026-01-07 | Amsterdam, NL | Rust Developers Amsterdam Group
  • Meetup @ Instruqt
• 2026-01-08 | Geneva, CH | Post Tenebras Lab
  • Rust Meetup Geneva
• 2026-01-14 | Girona, ES | Rust Girona
  • Rust Girona Hack & Learn 01 2026
• 2026-01-14 | Reading, UK | Reading Rust Workshop
  • Reading Rust Meetup
• 2026-01-16 | Edinburgh, UK | Rust and Friends
  • Rust and Friends (daytime coffee)
• 2026-01-20 | Leipzig, SN, DE | Rust - Modern Systems Programming in Leipzig
  • Topic TBD
• 2026-01-20 | Paris, FR | Rust Paris
  • Rust meetup #82
• 2026-01-21 | Cambridge, UK | Cambridge Rust Meetup
  • Monthly Rust Meetup
• 2026-01-26 | Augsburg, DE | Rust Meetup Augsburg
  • Rust Meetup #17
• 2026-01-28 | Dortmund, DE | Rust Dortmund
  • Rust Dortmund Meetup - January 2026
• 2026-02-04 | Oxford, UK | Oxford ACCU/Rust Meetup.
  • Paul Grenyer: Beyond the Code: Designing Services That Stand the Test of Time

North America

• 2026-01-08 | Lehi, UT, US | Utah Rust
  • Bringing the data lake to the browser with WASM
• 2026-01-08 | Mountain View, CA, US | Hacker Dojo
  • RUST MEETUP at HACKER DOJO
• 2026-01-08 | Portland, OR, US | PDXRust
  • Toasty: An Easy-to-use Object-Relational Mapping for Rust
• 2026-01-08 | San Diego, CA, US | San Diego Rust
  • San Diego Rust January Meetup - Back in person!
• 2026-01-10 | Boston, MA, US | Boston Rust Meetup
  • Central Cambridge Rust Lunch, Jan 10
• 2026-01-13 | New York, NY, US | Rust NYC
  • Rust NYC Panel: AI Coding Agents in Rust: What Works, What Breaks
• 2026-01-14 | Chicago, IL, US | Chicago Rust Meetup
  • Rust Happy Hour
• 2026-01-15 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
  • Janurary, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-01-17 | Boston, MA, US | Boston Rust Meetup
  • Boston Common Rust Lunch, Jan 17
• 2026-01-17 | Herndon, VA, US | NoVaLUG
  • Monthly Meeting - Make Brian Lunduke Angry, Program in Rust
• 2026-01-20 | San Francisco, CA, US | San Francisco Rust Study Group
  • Rust Hacking in Person
• 2026-01-21 | Austin, TX, US | Rust ATX
  • Rust Lunch - Fareground
• 2026-01-22 | Boston, MA, US | Boston Rust Meetup
  • Evening Boston Rust Meetup with Jiff, January 22
• 2026-01-22 | Mountain View, CA, US | Hacker Dojo
  • RUST MEETUP at HACKER DOJO
• 2026-01-24 | Boston, MA, US | Boston Rust Meetup
  • Davis Square Rust Lunch, Jan 24
• 2026-01-28 | Los Angeles, CA, US | Rust Los Angeles
  • Rust Los Angeles: Building Git-LFS Replacements in Rust
• 2026-01-29 | Atlanta, GA, US | Rust Atlanta
  • Rust-Atl
• 2026-01-29 | Nashville, TN, US | Music City Rust Developers
  • Rust Programming 101
• 2026-01-31 | Boston, MA, US | Boston Rust Meetup
  • Northeastern Rust Lunch, Jan 31

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

I find it amazing that by using Rust and Miri I am using tools that are on the edge of fundamental research in Programming Languages. Actual practically usable tools that anyone can use, not arcane code experiments passed around between academics.

- ZiCog on rust-users

Thanks to Kyllingene for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by:

• nellshamrell
• llogiq
• ericseppanen
• extrawurst
• U007D
• mariannegoldin
• bdillo
• opeolluwa
• bnchi
• KannanPalani57
• tzilist

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

07 Jan 2026 5:00am GMT

It's common, in a Unix shell, to pause a foreground process with Ctrl+Z. However, today I needed to pause a _background_ process.

tl;dr: SIGTSTP and SIGCONT

The context was a queue processor spinning too fast, and preventing us from dequeuing unwanted messages.

Unsurprisingly, there are standard POSIX signals to pause and resume a target PID.

So we just need to grab the PID, and kill away.

$ kill -TSTP ${PID}
[... do what's needed ...]
$ kill -TCONT ${PID}

The post Pausing a background process first appeared on Narf.

06 Jan 2026 12:48am GMT

A small pet-peeve with fetching the latest main on jujutsu is that I like to move all my WIP patches to the new one. That's also nice because jj doesn't make me fix the conflicts immediately!

The solution from a co-worker (kudos to skippyhammond!) is to query all immediate decendants of the previous main after the fetch.

jj git fetch
# assuming 'z' is the rev-id of the previous main.
jj rebase -s "mutable()&z+" -d main

I haven't learnt how to make aliases accept params with it yet, so this will have to do for now.

Update: After a bit of searching, it seems that today this is only possible by wrapping it in a shell script. Based on the examples in the jj documentation an alias would look like this:

[aliases]
# Update all revs to the latest main; point to the previous one.
hoist = ["util", "exec", "--", "bash", "-c", """
set -euo pipefail
jj rebase -s "mutable()&$1+" -d "main"
""", ""]

05 Jan 2026 11:10pm GMT

My first article on the PPPP protocol already said everything there was to say about PPPP "encryption":

• Keys are static and usually trivial to extract from the app.
• No matter how long the original key, it is mapped to an effective key that's merely four bytes long.
• The "encryption" is extremely susceptible to known-plaintext attacks, usually allowing reconstruction of the effective key from a single encrypted packet.

So this thing is completely broken, why look any further? There is at least one situation where you don't know the app being used so you cannot extract the key and you don't have any traffic to analyze either. It's when you are trying to scan your local network for potential hidden cameras.

This script will currently only work for cameras using plaintext communication. Other cameras expect a properly encrypted "LAN search" packet and will ignore everything else. How can this be solved without listing all possible keys in the script? By sending all possible ciphertexts of course!

TL;DR: What would be completely ridiculous with any reasonable protocol turned out to be quite possible with PPPP. There are at most 157,092 ways in which a "LAN search" packet can be encrypted. I've opened a pull request to have the PPPP device detection script adjusted.

Note: Cryptanalysis isn't my topic, I am by no means an expert here. These issues are simply too obvious.

Mapping keys to effective keys

The key which is specified as part of the app's "init string" is not being used for encryption directly. Nor is it being fed into any of the established key stretching algorithms. Instead, a key represented by the byte sequence $b_1,b_2,\dots ,b_n$ is mapped to four bytes $k_1,k_2,k_3,k_4$ that become the effective key. These bytes are calculated as follows ($\lfloor x\rfloor$ means rounding down, $\otimes$ stands for the bitwise XOR operation):

In theory, a 4 byte long effective key means ${256}^4=\mathrm{4,294,967,296}$ possible values. But that would only be the case if these bytes were independent of each other.

Redundancies within the effective key

Of course the bytes of the effective key are not independent. This is most obvious with $k_2$ which is completely determined by $k_1$:

This means that we can ignore $k_2$, bringing the number of possible effective keys down to ${256}^3=\mathrm{16,777,216}$.

Now let's have a look at the relationship between $k_1$ and $k_4$. Addition and bitwise XOR operations are very similar, the latter merely ignores carry. This difference affects all the bits of the result but the lowest one, no carry to be considered here. This means that the lowest bits of $k_1$ and $k_4$ are always identical. So $k_4$ has only 128 possible values for any value of $k_1$, bringing the total number of effective keys down to $256\cdot 256\cdot 128=\mathrm{8,388,608}$.

And that's how far we can get considering only redundancies. It can be shown that a key can be constructed resulting in any combination of $k_1$ and $k_3$ values. Similarly, it can be shown that any combination of $k_1$ and $k_4$ is possible as long as the lowest bit is identical.

ASCII to the rescue

But the keys we are dealing with here aren't arbitrary bytes. These aren't limited to alphanumeric characters, some keys also contain punctuation, but they are all invariably limited to the ASCII range. And that means that the highest bit is never set in any of the $b_i$ values.

Which in turn means that the highest bit is never set in $k_4$ due to the nature of the bitwise XOR operation. We can once again rule out half of the effective keys, for any given value of $k_1$ there are only 64 possible values of $k_4$. We now have $256\cdot 256\cdot 64=\mathrm{4,194,304}$ possible effective keys.

How large is n?

Now let's have a thorough look at how $k_3$ relates to $k_1$, ignoring the modulo operation at first. We are taking one third of each byte, rounding it down and summing that up. What if we were to sum up first and round down at the end, how would that relate? Well, it definitely cannot be smaller than rounding down in each step, so we have an upper bound here.

How much smaller can the left side get? Each time we round down this removes at most two thirds, and we do this $n$ times. So altogether these rounding operations reduce the result by at most $n\cdot 2÷3$. This gives us a lower bound:

If $n$ is arbitrary these bounds don't help us at all. But $n$ isn't arbitrary, the keys used for PPPP encryption tend to be fairly short. Let's say that we are dealing with keys of length 16 at most which is a safe bet. If we know the sum of the bytes these bounds allow us to narrow down $k_3$ to $\lceil 16\cdot 2÷3\rceil =11$ possible values.

But we don't know the sum of bytes. What we have is $k_1$ which is that sum modulo 256, and the sum is actually $i\cdot 256+k_1$ where $i$ is some nonnegative integer. How large can $i$ get? Remembering that we are dealing with ASCII keys, each byte has at most the value 127. And we have at most 16 bytes. So the sum of bytes cannot be higher than $127\cdot 16=2032$ (or 7F0 in hexadecimal). Consequently, $i$ is 7 at most.

Let's write down the bounds for $k_3$ now:

We have to consider this for eight possible values of $i$. Wait, do we really?

Once we move into modulo 256 space again, the $i\cdot 256÷3$ part of our bounds (which is the only part dependent on $i$) will assume the same value after every three $i$ values. So only three values of $i$ are really relevant, say 0, 1 and 2. Meaning that for each value of $k_1$ we have $3\cdot 11=33$ possible values for $k_3$.

This gives us $256\cdot 33\cdot 64=\mathrm{540,672}$ as the number of possible effective keys. My experiments with random keys indicate that this should be pretty much as far down as it goes. There may still be more edge conditions rendering some effective keys impossible, but if these exist their impact is insignificant.

Not all effective keys are equally likely however, the $k_3$ values at the outer edges of the possible range are very unlikely. So one could prioritize the keys by probability - if the total number weren't already low enough to render this exercise moot.

How many ciphertexts is that?

We have the four byte plaintext F1 30 00 00 and we have 540,672 possible effective keys. How many ciphertexts does this translate to? With any reasonable encryption scheme the answer would be: slightly less than 540,672 due to a few unlikely collisions which could occur here.

But PPPP doesn't use a reasonable encryption scheme. With merely four bytes of plaintext there is a significant chance that PPPP will only use part of the effective key for encryption, resulting in identical ciphertexts for every key sharing that part. I didn't bother analyzing this possibility mathematically, my script simply generated all possible ciphertexts. So the exact answer is: 540,672 effective keys produce 157,092 ciphertexts.

And that's why you should leave cryptography to experts.

Understanding the response

Now let's say we send 157,092 encrypted requests. An encrypted response comes back. How do we decrypt it without knowing which of the requests was accepted?

All PPPP packets start with the magic byte F1, so the first byte of our response's plaintext must be F1 as well. The "encryption" scheme used by PPPP allows translating that knowledge directly into the value of $k_1$. Now one could probably (definitely) guess more plaintext parts and with some clever tricks deduce the rest of the effective key. But there are only $33\cdot 64=\mathrm{2,112}$ possible effective keys for each value of $k_1$ anyway. It's much easier to simply try out all 2,112 possibilities and see which one results in a response that makes sense.

The response here is 24 bytes large, making ambiguous decryptions less likely. Still, my experiments show that in approximately 4% of the cases closely related keys will produce valid but different decryption results. So you will get two or more similar device IDs and any one of them could be correct. I don't think that this ambiguity can be resolved without further communication with the device, but at least with my changes the script reliably detects when a PPPP device is present on the network.

05 Jan 2026 3:50pm GMT

The Rust project is currently working towards a slate of 41 project goals, with 13 of them designated as Flagship Goals. This post provides selected updates on our progress towards these goals (or, in some cases, lack thereof). The full details for any particular goal are available in its associated tracking issue on the rust-project-goals repository.

Flagship goals

"Beyond the `&`"

pub trait CanonicalReborrow: HasPlace {
    type Output<'a, P: Projection<Source = Self::Target>>: HasPlace<Target = P::Target>
    where
        Self: PlaceBorrow<'a, P, Self::Output<'a, P>>;
}

@<<Self as CanonicalReborrow>::Output<'_, projection_from_place_expr!($place_expr)>> $place_expr

pub unsafe trait PlaceWrapper<P: Projection<Source = Self::Target>>: HasPlace {
    type WrappedProjection: Projection<Source = Self>;

    fn wrap_projection(p: P) -> Self::WrappedProjection;
}

impl<T, P: Projection<Source = T>> PlaceWrapper<P> for MaybeUninit<T> {
    type WrappedProjection = TransparentProjection<P, MaybeUninit<T>, MaybeUninit<P::Target>>;

    fn wrap_projection(p: P) -> Self::WrappedProjection {
        TransparentProjection(p, PhantomData, PhantomData)
    }
}

pub struct TransparentProjection<P, Src, Tgt>(P, PhantomData<Src>, PhantomData<Tgt>);

impl<P: Projection, Src, Tgt> Projection for TransparentProjection<P, Src, Tgt> {
    type Source = Src;
    type Target = Tgt;

    fn offset(&self) -> usize {
        self.0.offset()
    }
}

// Note: not Clone or Copy
#[derive(Reborrow)]
struct MyMutMarker<'a>(...);

// ...

let marker: MyMarkerMut = MyMutMarker::new();
some_call(marker);
some_call(marker);

return some_call(marker.reborrow());

trait CoerceShared<Target: Copy> {}

"Flexible, fast(er) compilation"

Production-ready cranelift backend (rust-lang/rust-project-goals#397)

Progress
Point of contact	Folkert de Vries
Champions	compiler (bjorn3)
Task owners	bjorn3, Folkert de Vries, [Trifecta Tech Foundation]

1 detailed update available.

Comment by @folkertdev posted on 2025-12-01:

We did not receive the funding we needed to work on this goal, so no progress has been made.

Overall I think the improvements we felt comfortable promising are on the low side. Overall the amount of time spent in codegen for realistic changes to real code bases was smaller than expected, meaning that the improvements that cranelift can deliver for the end-user experience are smaller.

We still believe larger gains can be made with more effort, but did not feel confident in promising hard numbers.

So for now, let's close this.

Relink don't Rebuild (rust-lang/rust-project-goals#400)

Progress
Point of contact	Jane Lusby
Champions	cargo (Weihang Lo), compiler (Oliver Scherer)
Task owners	@dropbear32, @osiewicz

No detailed updates available.

"Higher-level Rust"

"Unblocking dormant traits"

Goals looking for help

Other goal updates

Add a team charter for rustdoc team (rust-lang/rust-project-goals#387)

Progress
Point of contact	Guillaume Gomez
Champions	rustdoc (Guillaume Gomez)

No detailed updates available.

#![feature(const_default, const_trait_impl, min_generic_const_args)]

trait Trait {
    #[type_const]
    const ASSOC: usize;
}

fn mk_array<T: const Default + Trait>() -> [T; T::ASSOC] {
    [const { T::default() }; _]
}

#![feature(adt_const_params, min_generic_const_args)]

fn foo<const N: Option<u32>>() {}

trait Trait {
    #[type_const]
    const ASSOC: usize;
}

fn bar<T: Trait, const N: u32>() {
    // the initializer of `_0` is a `N` which is a legal const argument
    // so this is ok.
    foo::<{ Some::<u32> { 0: N } }>();

    // this is allowed as mgca supports uses of assoc consts in the
    // type system. ie `<T as Trait>::ASSOC` is a legal const argument
    foo::<{ Some::<u32> { 0: <T as Trait>::ASSOC } }>();

    // this on the other hand is not allowed as `N + 1` is not a legal
    // const argument
    foo::<{ Some::<u32> { 0: N + 1 } }>(); // ERROR
}

// This program has DB
let x = String::new();
let xaddr = &raw const x;
let y = x; // Move out of x and de-initialize it.
let yaddr = &raw const y;
x = String::new(); // assuming this does not change the address of x
// x and y are both live here. Therefore, they can't have the same address.
assume(xaddr != yaddr);
drop(x);
drop(y);

// This program has UB
let x = String::new();
let xaddr = &raw const x;
let y = x; // Move out of x and de-initialize it.
let yaddr = &raw const y;
// So far, there has been no constraint that would force the addresses to be different.
// Therefore we can demonically choose them to be the same. Therefore, this is UB.
assume(xaddr != yaddr);
// If the addresses are the same, this next line triggers NB. But actually this next
// line is unreachable in that case because we already got UB above...
x = String::new();
// x and y are both live here.
drop(x);
drop(y);

[unstable]
build-analysis = true

[build.analysis]
enabled = true

Run more tests for GCC backend in the Rust's CI (rust-lang/rust-project-goals#402)

Progress
Point of contact	Guillaume Gomez
Champions	compiler (Wesley Wiser), infra (Marco Ieni)
Task owners	Guillaume Gomez

No detailed updates available.

05 Jan 2026 12:00am GMT

Got this one from another colleague as well but it seems like most folks use some version of this daily that it might be good to have this built-in.

Before I can jj git push my current bookmark to my remote, I need to update where my (tracked) bookmark is, to the latest change:

@  ptuqwsty git@jonalmeida.com 2026-01-05 16:00:22 451384bf <-- move 'main' here.
│  TIL: Update remote bookmark to the latest revision
◆  xoqwkuvu git@jonalmeida.com 2025-12-30 19:50:51 main git_head() 9ad7ce11
│  TIL: Preserve image scale with ImageMagick
~

A quick one-liner jj tug does that for me:

@  ptuqwsty git@jonalmeida.com 2026-01-05 16:03:54 main* 6e7173b4
│  TIL: Update remote bookmark to the latest revision
◆  xoqwkuvu git@jonalmeida.com 2025-12-30 19:50:51 main@origin git_head() 9ad7ce11
│  TIL: Preserve image scale with ImageMagick
~

The alias is quite straight-forward:

[aliases]
# Update your bookmarks to your latest rev.
tug = ["bookmark", "move", "--from", "heads(::@ & bookmarks())", "--to", "@"]

05 Jan 2026 12:00am GMT

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.

Updates from Rust Community

Project/Tooling Updates

• reqwest v0.13 - rustls by default
• rama 0.3.0-alpha.4 is released - modular service framework to move and transform network packets
• Ratatui 0.30.0 is released! - a Rust library for cooking up terminal user interfaces

Observations/Thoughts

• Four Years of Rust: An Odyssey of Failures, Achievements, and Hard Lessons
• Simple Bidirectional Type Inference
• serde's borrowing can be treacherous
• Garbage collection in Rust got a little better
• [audio] Netstack.FM episode 20 - Netstack.FM New Year Special, 2025 Wrap-Up

Rust Walkthroughs

• Why is calling my asm function from Rust slower than calling it from C?
• Rust Errors Without Dependencies
• [video] Building your first APP using the new Hotaru Web Framework!

Miscellaneous

• [audio] 2025 Holiday Special - Rust in Production Podcast
• Investigating and fixing a nasty clone bug

Crate of the Week

This week's crate is wgsl-bindgen, a binding generator for WGSL, the WebGPU shading language, to be used with wgpu.

Thanks to Artem Borisovskiy for the suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.

If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

Rustup

• Rustup 1.29.0 beta: Call for Testing!

• Testing steps: See "How to Test" section from above link.

• No calls for testing were issued this week by Rust, Cargo or Rust language RFCs.

Let us know if you would like your feature to be tracked as a part of this list.

Call for Participation; projects and speakers

CFP - Projects

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

• Spindalis - Create an AST parser
• Spindalis - Add procedural macro for definite integral
• Spindalis - Add a function and macro that can expand polynomials
• Spindalis - Add display trait to functions in spindalis core

If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon!

CFP - Events

Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.

• RustWeek 2026 | CFP closes 2026-01-18 | Utrecht, The Netherlands | 2026-05-19 - 2026-05-20
• RustConf 2026 | CFP closes 2026-02-16 | Montreal, Quebec, Canada | 2026-09-08 - 2026-09-10

If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon!

Updates from the Rust Project

297 pull requests were merged in the last week

Compiler

• recursive delegation improvements
• miri: fix ICE for particular data race situations
• miri: show a warning when combing native-lib mode and many-seeds
• miri: tree Borrows: improve protector end access child skipping

Library

• add MaybeDangling to core
• alloc: specialize String::extend for slices of str
• implement Duration::div_duration_{floor,ceil}
• implement flatten for Option<&Option<T>> and Option<&mut Option<T>>
• optimized implementation for uN::{gather,scatter}_bits
• rewrite String::replace_range
• stabilize lazy_get

Cargo

• index: Stabilize pubtime
• report: new command cargo report sessions
• report: support --manifest-path in cargo report timings
• resolver: List features when no close match
• toml: TOML 1.1 parse support
• vendor: recursively filter git files in subdirectories
• vendor: unpack from local-registry cache path
• build-rs: Reduce from 'build' to 'check' where possible
• experiment: render timing pipeline in SVG
• patch: Display where the patch was defined in patch-related error messages

Rustdoc

• if line number setting is disabled, do not make line numbers take space
• fix copy code example with line numbers
• fix duplicate Re-exports sections
• fix incorrect type filter name in help popup

Clippy

• fix assertions_on_constants false positive when there is non-constant value in the condition expr
• fix double_parens false positive on macro repetition patterns
• fix obfuscated_if_else wrongly unmangled macros
• fix result_large_err false negative on closures
• preserve explicit lifetime information when removing mut
• various fixes for handling of macros

Rust-Analyzer

• add bidirectional messaging proc-macro-srv prototype
• add macro segment completion
• implement configuration to change sub command for test, bench and doctest
• provide a setting to disable showing rename conflicts
• stabilize type mismatch diagnostic 🎉
• indent for convert_to_guarded_return
• fix LSP configuration request handling
• fix parsing of format_args!("...", keyword=...)
• fix type inference when hovering on _
• reenable fixpoint variance
• do not really expand builtin derives, instead treat them specifically
• pre-allocate some buffers in parsing
• reduce channel lock contention for drop-threads
• prompt the user in VSCode to add the rust-anaylzer componenet to the toolchain file

Rust Compiler Performance Triage

Not a lot of changes this week. Overall result is positive, largely thanks to #142881, which makes computing an expensive data structure for JumpThreading MIR optimization lazy.

Triage done by @panstromek. Revision range: e1212ea7..112a2742

Summary:

2 Regressions, 0 Improvements, 3 Mixed; 1 of them in rollups 37 artifact comparisons made in total

Full report here

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week: * No RFCs were approved this week.

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

Tracking Issues & PRs

Compiler Team (MCPs only)

• Proposal for a dedicated test suite for the parallel frontend
• Promote tier 3 riscv32 ESP-IDF targets to tier 2
• Proposal for Adapt Stack Protector for Rust
• Give integer literals a sign instead of relying on negation expressions
• Also enable ICE file dumps on stable
• New Tier-3 target proposal: loongarch64-linux-android

No Items entered Final Comment Period this week for Cargo, Rust, Rust RFCs, Leadership Council, Language Team, Language Reference or Unsafe Code Guidelines.

Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.

New and Updated RFCs

• Thin pointers with inline metadata

Tracking Issues & PRs

New and Updated RFCs

Upcoming Events

Rusty Events between 2025-12-31 - 2026-01-28 🦀

Virtual

• 2026-01-03 | Virtual (Kampala, UG) | Rust Circle Meetup
  • Rust Circle Meetup
• 2026-01-07 | Virtual (Indianapolis, IN, US) | Indy Rust
  • Indy.rs - with Social Distancing
• 2026-01-08 | Virtual (Charlottesville, VA, US) | Charlottesville Rust Meetup
  • Meet, swap, and learn!
• 2026-01-08 | Virtual (Nürnberg, DE) | Rust Nuremberg
  • Rust Nürnberg online
• 2026-01-13 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Second Tuesday
• 2026-01-13 | Virtual | libp2p Events
  • rust-libp2p Open Maintainers Call
• 2026-01-13 | Virtual (Tel Aviv-yafo, IL) | Code Mavens 🦀 - 🐍 - 🐪
  • Live Open Source Rust project contribution
• 2026-01-14 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-01-15 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-01-20 | Virtual (Washington, DC, US) | Rust DC
  • Mid-month Rustful
• 2026-01-21 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-01-21 | Virtual (Vancouver, BC, CA) | Vancouver Rust
  • Stack Safety
• 2026-01-27 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Fourth Tuesday
• 2026-01-28 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session

Asia

• 2026-01-07 | Tel Aviv-yafo, IL | Rust 🦀 TLV
  • In person Rust January 2026 at AWS in Tel Aviv
• 2026-01-08 | Seoul, KR | Seoul Rust (Programming Language) Meetup
  • Seoul Rust Meetup
• 2026-01-17 | Delhi, IN | Rust Delhi
  • Rust Delhi Meetup #12

Europe

• 2026-01-07 | Amsterdam, NL | Rust Developers Amsterdam Group
  • Meetup @ Instruqt
• 2026-01-07 | Girona, ES | Rust Girona
  • Rust Girona Hack & Learn 01 2026
• 2026-01-08 | Geneva, CH | Post Tenebras Lab
  • Rust Meetup Geneva
• 2026-01-14 | Reading, UK | Reading Rust Workshop
  • Reading Rust Meetup
• 2026-01-20 | Leipzig, SN, DE | Rust - Modern Systems Programming in Leipzig
  • Topic TBD
• 2026-01-20 | Paris, FR | Rust Paris
  • Rust meetup #82

North America

• 2026-01-01 | Saint Louis, MO, US | STL Rust
  • Cancelled
• 2026-01-03 | Boston, MA, US | Boston Rust Meetup
  • Allston Rust Lunch, Jan 3
• 2026-01-08 | Lehi, UT, US | Utah Rust
  • Bringing the data lake to the browser with WASM
• 2026-01-08 | Mountain View, CA, US | Hacker Dojo
  • RUST MEETUP at HACKER DOJO
• 2026-01-10 | Boston, MA, US | Boston Rust Meetup
  • Central Cambridge Rust Lunch, Jan 10
• 2026-01-13 | New York, NY, US | Rust NYC
  • Rust NYC Panel: AI Coding Agents in Rust: What Works, What Breaks
• 2026-01-13 | Spokane, WA, US | Spokane Rust
  • .NET Conference 2025 Spokane
• 2026-01-15 | Seattle, WA, US | Seattle Rust User Group
  • Janurary, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-01-17 | Boston, MA, US | Boston Rust Meetup
  • Boston Common Rust Lunch, Jan 17
• 2026-01-17 | Herndon, VA, US | NoVaLUG
  • Monthly Meeting - Make Brian Lunduke Angry, Program in Rust
• 2026-01-20 | San Francisco, CA, US | San Francisco Rust Study Group
  • Rust Hacking in Person
• 2026-01-21 | Austin, TX, US | Rust ATX
  • Rust Lunch - Fareground
• 2026-01-22 | Boston, MA, US | Boston Rust Meetup
  • Evening Boston Rust Meetup with Jiff, January 22
• 2026-01-24 | Boston, MA, US | Boston Rust Meetup
  • Davis Square Rust Lunch, Jan 24
• 2026-01-28 | Los Angeles, CA, US | Rust Los Angeles
  • Rust Los Angeles: Building Git-LFS Replacements in Rust

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

what even is time?!?

- Ralf Jung on his blog

Thanks to llogiq for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by:

• nellshamrell
• llogiq
• ericseppanen
• extrawurst
• U007D
• mariannegoldin
• bdillo
• opeolluwa
• bnchi
• KannanPalani57
• tzilist

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

31 Dec 2025 5:00am GMT

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.

Updates from Rust Community

Official

• What do people love about Rust?
• Please submit 2026 Project goal proposals
• December 2025 Project Director Update
• Program management update - End of 2025
• Rustup 1.29.0 beta: Call for Testing!

Newsletters

• The Embedded Rustacean Issue #61
• Scientific Computing in Rust #13 (December 2025)

Project/Tooling Updates

• What's "new" in Miri (and also, there's a Miri paper!)
• cargo-coupling: Visualizing Coupling in Rust Projects
• Announcing Asterinas 0.17.0
• Tuitar - A portable guitar training tool & DIY kit
• Gitoxide in December
• Announcing GotaTun, the future of WireGuard at Mullvad VPN
• wgpu v28.0.0 - Mesh Shaders, Immediates, and More!
• rustc_codegen_gcc: Progress Report #39

Observations/Thoughts

• Syntactic musings on the fallibility effect
• Rust's Block Pattern
• [audio] Netstack.FM episode 19 - Firezone and Zero-Trust Network Security with Thomas Eizinger

Rust Walkthroughs

• Rust Unit Testing: Basic HTTP Server
• Async Rust Bluetooth Plumbing: Where the Throughput Goes
• [series] Part 2: Tensor Operations, Building an LLM from Scratch in Rust

Crate of the Week

This week's crate is arcshift, an Arc replacement for read-heavy workloads that supports lock-free atomic replacement.

Thanks to rustkins for the suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.

If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

• No calls for testing were issued this week by Rust, Cargo, Rust language RFCs or Rustup.

Let us know if you would like your feature to be tracked as a part of this list.

Call for Participation; projects and speakers

CFP - Projects

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

No Calls for participation were submitted this week.

If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon!

CFP - Events

Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.

• RustWeek 2026 | CFP closes 2026-01-18 | Utrecht, The Netherlands | 2026-05-19 - 2026-05-20
• RustConf 2026 | CFP closes 2026-02-16 | Montreal, Quebec, Canada | 2026-09-08 - 2026-09-10

If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon!

Updates from the Rust Project

475 pull requests were merged in the last week

Compiler

• add target_feature = "gc" for Wasm
• better closure requirement propagation
• correctly encode doc attribute metadata
• don't treat asserts as a call in cross-crate inlining
• improve filenames encoding and misc
• make closure capturing have consistent and correct behaviour around patterns
• support recursive delegation

Library

• add try_as_dyn and try_as_dyn_mut
• add const default for OnceCell and OnceLock
• expand str_as_str to more types
• make const BorrowMut require const Borrow and make const Fn require const FnMut
• hashbrown: add hash_map::{OccupiedEntry::into_entry, VacantEntryRef::insert_entry_with_key}, make EntryRef use ToOwned again
• hashbrown: add hash_table::OccupiedEntry::replace_entry_with to mirror HashMap API
• hashbrown: add hash_table::UnsafeIter, iter() method to various iterators

Rustdoc

• Add missing close tags in extern crate reexports
• Fix invalid handling of field followed by negated macro call
• generate macro expansion for rust compiler crates docs
• handle macro expansions in types

Clippy

• transmuting_null: Check const integer casts
• allow multiline suggestions in map-unwrap-or
• do not attempt to use nth with non-usize argument
• don't emit collapsible_else_if lint when all arms contain only if {} else {} expressions
• fix cmp_null missing parens in the example
• fix empty_enum_variants_with_brackets misses removing brackets in patterns
• fix if_then_some_else_none suggests wrongly when then ends with comment
• fix needless_type_cast suggesting invalid code for non-literal initializers
• fix println_empty_string suggestion caused error
• fix use_self false positive on type in const generics
• fix an incorrect error message regarding the size of usize and isize in cast_precision_loss
• move collapsible_else_if to pedantic
• new lint - same_length_and_capacity

Rust-Analyzer

• add 'Use of AI tools' section to CONTRIBUTING.md
• add BreakExpr completion suggest
• add an lsp extension to get failed obligations for a given function
• add default varname for TryEnum postfix completion
• add guess braces doc T![] for T_
• add ide-assist: add_explicit_method_call_deref
• complete reference &T → &&T
• introduce crate_attrs field in rust-project.json
• pretty print attributes up to cfg(false)
• fix applicable on non naked if for move_guard assist
• fix guess renamed macro braces
• fix indent for convert_iter_for_each_to_for
• fix indent for merge_nested_if
• fix match arm nested body invalid expected type
• fix nested if-let for merge_nested_if
• fix flycheck generations not being synced for multiple workspaces
• more perf improvements, made possible after non-Salsa interneds
• non-Salsa-interned solver types - with GC for them
• remove conflicting advice
• support undotted-self for this param closure

Rust Compiler Performance Triage

Very quiet week, with essentially no change in performance.

Triage done by @simulacrum. Revision range: 21ff67df..e1212ea7

1 Regression, 1 Improvement, 3 Mixed; 2 of them in rollups 36 artifact comparisons made in total

Full report here

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week: * No RFCs were approved this week.

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

Tracking Issues & PRs

Rust

• Explicitly export core and std macros
• Stabilize 29 RISC-V target features (riscv_ratified_v2)

Cargo

• feat(toml): TOML 1.1 parse support

Compiler Team (MCPs only)

• Allow combining --help -C help -Z help -W help in one invocation

Leadership Council

• Raise travel grant limit to $100,000 for 2026
• Fund program management program for 2026
• Raise automatic travel grant to $2000

No Items entered Final Comment Period this week for Rust RFCs, Language Team, Language Reference or Unsafe Code Guidelines.

Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.

New and Updated RFCs

• Thin pointers with inline metadata

Upcoming Events

Rusty Events between 2025-12-24 - 2026-01-21 🦀

Virtual

• 2025-12-30 | Virtual (Tel Aviv-yafo, IL) | Code Mavens 🦀 - 🐍 - 🐪
  • Live Open Source Rust project contribution
• 2026-01-03 | Virtual (Kampala, UG) | Rust Circle Meetup
  • Rust Circle Meetup
• 2026-01-07 | Virtual (Indianapolis, IN, US) | Indy Rust
  • Indy.rs - with Social Distancing
• 2026-01-08 | Virtual (Charlottesville, VA, US) | Charlottesville Rust Meetup
  • Meet, swap, and learn!
• 2026-01-08 | Virtual (Nürnberg, DE) | Rust Nuremberg
  • Rust Nürnberg online
• 2026-01-13 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Second Tuesday
• 2026-01-13 | Virtual | libp2p Events
  • rust-libp2p Open Maintainers Call
• 2026-01-15 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-01-20 | Virtual (Washington, DC, US) | Rust DC
  • Mid-month Rustful
• 2026-01-21 | Virtual (Vancouver, BC, CA) | Vancouver Rust
  • Stack Safety

Asia

• 2026-01-07 | Tel Aviv-yafo, IL | Rust 🦀 TLV
  • In person Rust January 2026 at AWS in Tel Aviv

Europe

• 2026-01-07 | Amsterdam, NL | Rust Developers Amsterdam Group
  • Meetup @ Instruqt
• 2026-01-07 | Girona, ES | Rust Girona
  • Rust Girona Hack & Learn 01 2026
• 2026-01-08 | Geneva, CH | Post Tenebras Lab
  • Rust Meetup Geneva
• 2026-01-14 | Reading, UK | Reading Rust Workshop
  • Reading Rust Meetup
• 2026-01-20 | Leipzig, SN, DE | Rust - Modern Systems Programming in Leipzig
  • Topic TBD
• 2026-01-20 | Paris, FR | Rust Paris
  • Rust meetup #82

North America

• 2025-12-27 | Boston, MA, US | Boston Rust Meetup
  • Lechmere Rust Lunch, Dec 27
• 2026-01-03 | Boston, MA, US | Boston Rust Meetup
  • Allston Rust Lunch, Jan 3
• 2026-01-08 | Mountain View, CA, US | Hacker Dojo
  • RUST MEETUP at HACKER DOJO
• 2026-01-10 | Boston, MA, US | Boston Rust Meetup
  • Central Cambridge Rust Lunch, Jan 10
• 2026-01-15 | Seattle, WA, US | Seattle Rust User Group
  • Janurary, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-01-17 | Boston, MA, US | Boston Rust Meetup
  • Boston Common Rust Lunch, Jan 17
• 2026-01-20 | San Francisco, CA, US | San Francisco Rust Study Group
  • Rust Hacking in Person
• 2026-01-21 | Austin, TX, US | Rust ATX
  • Rust Lunch - Fareground

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

they should just rename unsafe to C so people can shut up

- /u/thisismyfavoritename on /r/rust

Thanks to Brian Kung for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by:

• nellshamrell
• llogiq
• ericseppanen
• extrawurst
• U007D
• mariannegoldin
• bdillo
• opeolluwa
• bnchi
• KannanPalani57
• tzilist

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

24 Dec 2025 5:00am GMT

I have been writing code for a long time, long enough to be suspicious of tools that claim to fundamentally change how I work. And yet, here we are.

The latest iterations of Claude Code are genuinely impressive. Not in a flashy demo way, but in the quiet, dangerous way where you suddenly realize you have delegated large parts of your thinking to it. This post is about that experience, how Claude helped me build rustnn, what worked remarkably well, and where I had to consciously pull myself back.

Claude as a serious coding partner

For rustnn, I leaned heavily on Claude Code. The quality of the generated Rust was consistently high. Beyond producing correct syntax, it reasoned about what the code was supposed to do. It was context-aware in a way that made iterative design feel natural. I could ask for refactors, architectural changes, or alternative approaches, and get answers that actually respected the existing codebase and long-running tests.

This mirrors what many developers have been reporting toward the end of 2025. Claude Code's agent-oriented design and large-context reasoning make it particularly strong for repository-wide work: multi-file refactors, non-trivial debugging sessions, and architectural changes that need to fit an existing mental model. Compared to Codex-style systems, which still shine for fast edits and local completions, Claude tends to perform better when the task requires sustained reasoning and understanding of project-wide constraints.

Anthropic's recent Claude releases have reinforced that positioning. Improvements in long-context handling, reasoning depth, and agentic workflows make it easier to treat Claude as something closer to a collaborator than an autocomplete engine.

The turning point for me was when I stopped treating Claude like a chat bot and started treating it like a constrained agent.

That is where CLAUDE.md comes in.

Tuning CLAUDE.md

I stumbled upon an excellent LangChain article on how to turn Claude Code into a domain-specific coding agent.

It clicked immediately. Instead of repeatedly explaining the same constraints, goals, and conventions, I encoded them once. Rust style rules. Project intent. Explicit boundaries. How to react to test failures.

The effect was immediate. Output quality improved, and the amount of back-and-forth dropped significantly. Claude stopped proposing things that were clearly out of scope and started behaving like someone who had actually read and understood the project.

For rustnn, I went one step further and anchored development around WPT conformance tests. That gave both Claude and me a shared, objective target. Tests either pass or they do not. No bikeshedding.

Tweaking CLAUDE.md quickly revealed itself as a never-ending process. There are plenty of articles describing different approaches, and none of them are definitive. The current direction seems to be layering information across multiple files, structuring project documentation so it is optimized for agent consumption while remaining readable for humans, and doing so without duplicating the same knowledge in multiple places.

That balance turns out to be just as important as the model itself.

The slippery slope

There is a trap though, and it is a subtle one.

Once Claude is good enough, you start routing everything through it.

• Re-running tests.
• Interpreting obvious build errors.
• Copying and pasting logs that you already understand.

It feels efficient, but it is not free. Each interaction has a cost, and when you are in a tight edit-build-test loop, those costs add up fast. Worse, you start outsourcing mechanical thinking that you should probably still be doing yourself.

I definitely fell into that trap.

Reducing costs

The solution, for me, was to drastically reduce how much I talk to Claude, and to stop using its prompt environment as a catch-all interface to the project.

Claude became an extra terminal. One I open for very specific tasks, then close. It is not a substitute for my own brain, nor for the normal edit-build-test loop.

Reducing the context window is also critical. A concrete example is Python tracebacks. They are verbose, repetitive, and largely machine-generated noise. Sending full tracebacks back to the model is almost always wasteful.

That is why I added a hook to rewrite them on the fly into a compact form.

The idea is simple: keep the signal, drop the boilerplate. Same information, far fewer tokens. In practice, this not only lowers costs, it often produces better answers because the model is no longer drowning in irrelevant frames and runtime noise. On Python-heavy codebases, this change alone reduced my usage costs by roughly 20%.

Pre-compacting inputs turned out to be one of the most effective cost-control strategies I have found so far, especially when combined with a more deliberate, intentional way of interacting with the model.

Memory across sessions actually matters

Another pain point is session amnesia. You carefully explain design decisions, trade-offs, and long-term goals, only to repeat them again tomorrow.

A well-crafted CLAUDE.md mitigates part of this problem. It works well for static knowledge: coding style, project constraints, architectural boundaries, and things that rarely change. It gives Claude a stable baseline and avoids a lot of repetitive explanations.

But it does not capture evolving context.

It does not remember why a specific workaround exists, which approach you rejected last week, or what subtle behavior a particular test exposed yesterday. As soon as the session ends, that knowledge is gone, and you are back to re-teaching the same mental model.

This is where cross-session, cross-project memory becomes interesting.

I am currently experimenting with claude-mem

The idea is simple but powerful: maintain a centralized, persistent memory that is automatically updated based on interactions. Instead of manually curating context, relevant facts, decisions, and preferences are summarized and carried forward. Over time, this builds a lightweight but durable understanding of how you work and how your projects evolve.

Compared to CLAUDE.md, this kind of memory is dynamic rather than declarative. It captures intent, not just rules. It also scales across projects, which matters when you jump between repositories that share design philosophy, tooling, or constraints.

It is still early, and it is not magic. You need to be careful about what gets remembered and how summaries are formed. But the direction feels right. Persistent memory reduces cognitive reset costs, shortens warm-up time, and makes the interaction feel less like starting over and more like continuing a conversation you paused yesterday.

That difference adds up.

Final thoughts

Claude Code is good. Very good. Good enough that you need discipline to use it well.

With a tuned CLAUDE.md, clear test-driven goals like WPT conformance, and some tooling to reduce noise and cost, it becomes a powerful accelerator. Without that discipline, it is easy to overuse it and slowly burn budget on things you already know how to do.

I do not think this replaces engineering skill. If anything, it amplifies both good and bad habits. The trick is to make sure it is amplifying the right ones.

References

• My Claude tools
• How to Turn Claude Code into a Domain-Specific Coding Agent
• OpenAI Codex vs GitHub Copilot vs Claude
• Anthropic bolsters AI model Claude's coding and agentic abilities with Opus 4.5
• claude-mem

*The title is a deliberate reference to "All your base are belong to us." The grammar is broken on purpose. It is a joke, but also a reminder that when tools like Claude get this good, it is easy to give them more control than you intended

20 Dec 2025 12:00am GMT

Welcome to the blog series "Behind the Manifesto," where we unpack core issues that are critical to Mozilla's mission. The Mozilla Manifesto represents our commitment to advancing an open, global internet that gives people meaningful choice in their online experiences, promotes transparency and innovation and protects the public interest over private walled gardens. This blog series digs deeper on our vision for the web and the people who use it and how these goals are advanced in policymaking and technology.

In 2025, global tech policy raced to keep up with technological change and opportunity. In the midst of this evolution, Mozilla sought to ensure that solutions remained centered on openness, competition and user agency.

From AI Agents and the future of the open web to watershed antitrust cases, competition debates surged. Efforts to drive leadership and innovation in AI led governments across the globe to evaluate priorities. Perennial privacy and security questions remained on the radar, with US states intensifying efforts to pass laws and the EU working to streamline rules on AI, cybersecurity and data. Debates amongst industry, civil society and policymakers reflected the intensity of these moments.

Just as we have for over 20 years, Mozilla showed up to build, convene, debate and advocate. It's clear that more than ever, there must be urgency to truly put people first. Below are a selection of some key moments we're reflecting on, as we head into 2026.

FEBRUARY 2025

Mozilla Participates in Paris AI Action Summit as Part of the Steering Committee

Mozilla participated in the Paris AI Action Summit as Part of the Steering Committee with an 'action packed' schedule that included appearances on panels, a live recording of the podcast "Computer Says Maybe" and a reception to reflect on discussions and thank all the officials and researchers who had worked so hard to make the Summit a success.

Additionally, Mozilla and other partners, including Hugging Face, Microsoft and OpenAI, launched Robust Open Online Safety Tools (ROOST) at the Paris AI Action Summit. The entity is designed to create open source foundations for safer and more responsible AI development, ensuring that safety and transparency remain central to innovation.

The launch of ROOST happened at exactly the right time and in the right place. The Paris AI Action Summit provided a global backdrop for launching work that will ultimately help make AI safety a field that everyone can shape and improve.

Mozilla Event: AI & Competition featuring the President of the German Competition Authority
On February 12, we hosted a public event in Berlin on AI & competition, in partnership with German daily newspaper Tagesspiegel. Addressing the real risk of market concentration at various elements of the AI stack, the President of the German competition authority (Bundeskartellamt), Andreas Mundt, delivered a keynote address setting out his analysis of competition in AI and the role of his authority in ensuring contestable markets as technology rapidly evolves.

MARCH 2025

America's AI Action Plan

In March, Mozilla responded to the White House's request for information on AI policy, urging policymakers to ensure that AI remained open, competitive and accountable. The comments also warned that concentrated control by a few tech giants threatened innovation and public trust, and called for stronger support of open source AI, public AI infrastructure, transparent energy use and workforce development. Mozilla underscored these frameworks are essential to building an AI ecosystem that serves the public interest rather than purely corporate bottom lines.

Mozilla Mornings: Promoting a privacy-preserving online ads ecosystem

The same month, we also hosted a special edition of Mozilla Mornings focused on the future of online advertising and the role Privacy-Enhancing Technologies (PETs) can play in reshaping it. The conversation came at a critical moment in Europe, amidst discussions on updating privacy legislation while enforcing existing rules.

The session brought together policymakers, technologists, and civil-society experts to examine how Europe can move toward a fairer and more privacy-respecting advertising ecosystem. Speakers explored the limitations of today's surveillance-driven model and outlined how PETs and Privacy-Preserving Technologies (PPTs) could offer a viable alternative that protects users while sustaining the economic foundations of the open web. The event underscored Mozilla's commitment to advancing privacy-respecting technologies and ensuring that both policy and technical design converge toward a healthier online advertising ecosystem.

MAY 2025

CPDP: The Evolution of PETs in Digital Ads

At the Brussels 2025 International CPDP Conference, Mozilla organized and participated in a panel titled "The Evolution of PETs in Digital Ads: Genuine Privacy Innovation or Market Power Play?" The discussion explored how Privacy-Enhancing Technologies (PETs) - tools designed to minimize data collection and protect user privacy - are reshaping the digital advertising landscape. Panelists debated how to encourage genuine privacy innovation without reinforcing existing power structures, and how regulations like the GDPR and the Digital Markets Act (DMA) can help ensure PETs foster transparency and competition.

Competition in Focus: U.S. vs Google

The U.S. v. Google remedies trial was a defining moment - not just for 2025, but for the future of browser and search competition. While the remedies phase was about creating competition in the search market, some of the proposed remedies risked weakening independent browsers like Firefox, the very players that make real choice possible.

In early May, Mozilla's CFO, Eric Muhlheim, testified to this very point. Muhlheim's testimony, and Mozilla's amicus brief in the case, spoke to the vital role of small, independent browsers in driving competition and innovation across the web and warned about the risks of harming their ability to select the search default that best serves their users. Ensuring a competitive search ecosystem while avoiding harm to browser competition remains an important issue in 2026.

JUNE 2025

Open by Design: How Nations Can Compete in the Age of AI

The choices governments make today, about who gets to build, access and benefit from AI, will shape economic competitiveness, national security and digital rights for decades. In June, Mozilla supported a new report by the UK think tank Demos, exploring how and why embracing openness in key AI resources can spur innovation and adoption. Enabling safer, more transparent development and boosting digital sovereignty is a recipe, if there ever was one, for 'winning' at AI.

EU Digital Summit: Advocating for Open and Secure Digital Ecosystems

Digital competitiveness depends on open, secure, and interoperable ecosystems that foster innovation while respecting users' rights. We spoke at the 2025 European Digital Summit-a flagship forum bringing together policymakers, regulators, industry leaders, and civil society-and argued that openness and security reinforce each other, that smart regulation has the potential to lower entry barriers and curb gatekeeping power, and that innovation does not require sacrificing privacy when incentives are aligned toward rights-respecting designs. The takeaway was clear: enforcing interoperability, safeguarding pro-competition rules, and embedding privacy-by-design incentives are essential to a resilient, innovative, and trustworthy open web.

JULY 2025

Joint Letter to the UK Secretary of State on DMCCA

When choice disappears, innovation stalls. In July, Mozilla sent an open letter to UK Ministers and the Competition & Markets Authority to urge faster implementation of the UK Digital Markets, Competition & Consumers Act (DMCCA). As an organisation that exists to create an internet that is open and accessible to all, Mozilla has long supported competitive digital markets. Since the EU Digital Markets Act took effect in 2024, users have begun to benefit from genuine choice for the first time, with interventions like browser choice screens offering people browser choice. The result? People are choosing independent alternatives to gatekeepers defaults: Firefox daily active users on iOS rose by 150% across the EU. The UK's DMCCA could be similarly revolutionary for UK consumers and the many challenger businesses taking on market dominance.

SEPTEMBER 2025

Digital Bootcamp: Bringing Internet Architecture to the Heart of EU Policymaking

In September, Mozilla officially launched its Digital Bootcamp initiative, developed in partnership with Cloudflare, Proton and CENTR, to strengthen policymakers' understanding of how the internet actually works and why this technical foundation is essential for effective regulation. We delivered interactive sessions across EU institutions, including a workshop for Members of the European Parliament, the European Commission, and representatives of the EU member states.

Across these workshops, we demystified the layered architecture of the internet, explained how a single website request moves through the stack, and clarified which regulatory obligations apply at each layer. By bridging the gap between engineering and policymaking, Digital Bootcamp is helping ensure EU digital laws remain grounded in technical reality, supporting evidence-based decisions that protect innovation, security and the long-term health of the open web.

OCTOBER 2025

Mozilla Meetup: The Future of Competition

On October 8, Mozilla hosted a Meetup on Competition in Washington, D.C., bringing together leading voices in tech policy - including Alissa Cooper (Knight-Georgetown Institute), Amba Kak (AI Now Institute), Luke Hogg (Foundation for American Innovation) and Kush Amlani (Mozilla) - to discuss the future of browser competition, antitrust enforcement and AI's growing influence on the digital landscape. Moderated by Bloomberg's Leah Nylen, the event reinforced our ongoing efforts to establish a more open and competitive internet, highlighting how policy decisions in these areas directly shape user choice, innovation, and the long-term health of the open web.

Global Encryption Day

On October 21, Mozilla marked Global Encryption Day by reaffirming our commitment to strong encryption as a cornerstone of online privacy, security, and trust. For years, Mozilla has played an active role in shaping the broader policy debate on encryption by consistently pushing back against efforts to weaken it and working with partners around the world to safeguard the technology that helps to keep people secure online - from joining the Global Encryption Coalition Steering Committee, to challenging U.S. legislation like the EARN IT Act and leading multi-year efforts in the EU to address encryption risks in the eIDAS Regulation.

California's Opt Me Out Act: A Continuation of the Fight For Privacy

The passage of California's Opt Me Out Act (AB 566) marked a major step forward in Mozilla's ongoing effort to strengthen digital privacy and give users control of their personal data. For years, Mozilla has spoken in support of Global Privacy Control (GPC) - a tool already integrated into Firefox - as a model for privacy-by-design solutions that can be both effective and user-friendly.

NOVEMBER 2025

Mozilla Submits Recommendations on the Digital Fairness Act

In November, Mozilla submitted its response to the European Commission's consultation on the Digital Fairness Act (DFA), framing it as a key opportunity to modernise consumer protection for AI-driven and highly personalised digital services. Mozilla argued that effective safeguards must tackle both interface design and underlying system choices, prohibit harmful design practices, and set clear fairness standards for personalization and advertising. A well-designed DFA can complement existing EU laws, strengthen user autonomy, provide legal certainty for innovators, and support a more competitive digital ecosystem built on genuine user choice.

Mozilla hosts AI breakfast in UK Parliament

Mozilla President, Mark Surman, hosted MPs and Peers for a breakfast in Parliament to discuss how policymakers can nurture AI that supports public good. As AI policy moves from principle to implementation, the breakfast offered insight into the models, trade-offs and opportunities that will define the next phase of the UK's AI strategy.

DECEMBER 2025

Mozilla Joins Tech Leaders at US House AI Caucus Briefing

Internet Works, an association of "Middle Tech" companies, organized a briefing with the Congressional AI Caucus. The goal was to provide members of congress and their staff a better understanding of the Middle Tech ecosystem and how smaller companies are adopting and scaling AI technologies. Mozilla spoke on the panel, lending valued technical expertise and setting out how we're thinking about keeping the web open for innovation, competition and user choice with this new technology stack.

eIDAS2 Regulation: Defending Web Security and Trust

In December, the EU published the final implementing rules for eIDAS2, closing a multi-year fight over proposals that would have required browsers to automatically trust government-mandated website certificates-putting encryption, user trust, and the open web at risk. Through sustained advocacy and deep technical engagement, Mozilla helped secure clear legal safeguards preserving independent browser root programs and strong TLS security. We also ensured that the final standards respect existing security norms and reflect how the web actually works. With all rules now published, users can continue to rely on browsers to verify websites independently with strict security requirements, governments are prevented from weakening web encryption by default, and a dangerous global precedent for state-controlled trust on the internet has been avoided.

This blog is part of a larger series. Be sure to follow Jenn Taylor Hodges on LinkedIn for further insights into Mozilla's policy priorities.

The post Behind the Manifesto: Moments that Mattered in our Fight for the Open Web (2025) appeared first on Open Policy & Advocacy.

19 Dec 2025 3:23pm GMT