If you have ever used Thunderbird in Bulgarian, the subject of this month's office hours is one of the contributors who made that possible! Office Hours hosts Heather and Monica have been lucky enough to chat with long-time localizer Bogamil Shopov at conferences like FOSDEM. Now, they're sitting down to talk to him about how his contributor story started, and to hear the advice he has for anyone curious about being part of Thunderbird.
We'll be back next time, checking in on Thunderbird Pro! It's been almost a year since we sat down with members of our team making this possible. As we've slowly started opening up the service to our Early Birds from the waitlist, it seemed a great opportunity to learn what users can expect, now and in the future!
A Contributor Origin Story
Bogomil has been a contributor to Thunderbird from the start! Even if he didn't like the UI in the early days, he loved our commitment to software freedom. He wanted people to have the software in their own language, and so he started localizing Thunderbird into Bulgarian. This was in the days before Pontoon, Mozilla's localization platform, and so this wasn't easy work! Another hurdle, which still happens, is that small language locales tend to have smaller numbers of contributors doing localizing work.
From Mentee to Mentor
Thankfully, Bogomil had unofficial mentors to help them find their way. On the localization side, he had a Bulgarian mentor who he, in turn, introduced to Mozilla and other open source projects. More experienced Mozilla contributors answered his questions as he expressed his interest in getting more involved. Bogomil points out that this need for both good onboarding docs and genuine human connection is still something all open source projects needs - and something we can keep improving!
Now Bogomil is the experienced mentor, and he's had some key steps to helping grow the Thunderbird localizer community. He sends thank you notes to new translators and sends resources for specific computer and email terminology to new Bulgarian volunteers. He gives his mentees specific tasks to help focus their energy and excitement, and maybe even more importantly, he gives them encouragement.
This Speaker goes to 11
While Bogomil had given several public talks in Bulgarian before COVID, after 2020 he decided to try giving conference talks in English. His first talk was at Halfstack, sponsored by Mozilla, in Vienna, on what made him happy as a developer and IT person in general. He even brought a violin player on stage with him! His talk got a warm reception, and it encouraged him to keep talking about what brought him joy, whether it was using heavy metal to help him focus or his involvement with Thunderbird and open source. If you've ever considered giving a talk, especially about one of your passions, and hesitated, Bogomil would tell you to do it! People are more welcoming than you might think.
Tools and Advice
Bogomil still uses Pontoon for Thunderbird desktop translations, in addition to Weblate, where Thunderbird for Android and many other open source projects live. In addition to this localization platforms, he uses CoEdIt along with web-based tools that allow him to see how certain words were previously translated. And of course, he has three release channels of Thunderbird on his computer at all times, something most of the Thunderbird team understands!
From newer contributors, Bogomil has learned how language is changing and how to keep terms, like the Bulgarian word for "browser," up to date, in addition to other feedback. His advice to new and potential volunteers is to be open to critique. This is especially true joining a project with a long history like Thunderbird, especially before wanting to change something. And he says don't be afraid to do things and experiment, even if things go wrong.
Two weeks ago we announced that we had identified and fixed an unprecedented number of latent security bugs in Firefox with the help of Claude Mythos Preview and other AI models. In this post, we'll go into more detail about how we approached this work, what we found, and advice for other projects on making good use of emerging capabilities to harden themselves against attack.
Suddenly, the bugs are very good
Just a few months ago, AI-generated security bug reports to open source projects were mostly known for being unwanted slop. Dealing with reports that look plausibly correct but are wrong imposes an asymmetric cost on project maintainers: it's cheap and easy to prompt an LLM to find a "problem" in code, but slow and expensive to respond to it.
It is difficult to overstate how much this dynamic changed for us over a few short months. This was due to a combination of two main factors. First, the models got a lot more capable. Second, we dramatically improved our techniques for harnessing these models - steering them, scaling them, and stacking them to generate large amounts of signal and filter out the noise.
Ordinarily we keep detailed bug reports private for several months after shipping fixes and issuing security advisories, largely as a precaution to protect any users who, for whatever reason, were slow to update to the latest version of Firefox. Given the extraordinary level of interest in this topic and the urgency of action needed throughout the software ecosystem, we've made the calculated decision to unhide a small sample of the reports behind the fixes we recently shipped. We've attempted to draw them from a range of browser subsystems, but the selection process was still somewhat arbitrary. Nevertheless, we hope that the depth and diversity of these reports lends credence to our assessment of the capabilities and our calls for defenders to begin applying these techniques:
An incorrect equality check can cause the JIT to optimize away the initialization of a live WebAssembly GC struct, creating a fake-object primitive with potential arbitrary read/write in code that had undergone extensive fuzzing by internal and external researchers.
A 15-year-old bug in the <legend> element triggered by meticulous orchestration of edge cases across distant parts of the browser, including recursion stack depth limits, expando properties, and cycle collection.
Reliably exploits a race condition over IPC, allowing a compromised content process to manipulate IndexedDB refcounts in the parent to trigger a UAF and potential sandbox escape.
A raw NaN crossing an IPC boundary can masquerade as a tagged JS object pointer, turning double deserialization into a parent-process fake-object primitive for a sandbox escape.
An intricate testcase weaving through nested event loops, pagehide listeners, and garbage collection to trigger a UAF in the attribute setter for <object> elements.
Triggers a parent UAF by flooding WebTransport with thousands of certificate hashes to stretch a race condition in a refcount-heavy copy loop, and exploits that race condition over IPC from a compromised content process.
Simulates a malicious DNS server by intercepting glibc DNS function calls in order to reproduce a UDP->TCP fallback edge case, triggering a buffer over-read and parent-process stack memory leak during HTTPS RR & ECH parsing.
20-year-old XSLT bug in which reentrant key() calls cause a hash table rehash that frees its backing store while a raw entry pointer is still in use (one of several sec-high issues we fixed involving XSLT).
Patches the color picker to simulate otherwise non-automatable user selection, then uses a synchronous input event to spin a nested event loop that re-enters actor teardown and frees the callback while it is still unwinding, triggering a content process UAF.
A compromised content process could send an arbitrary wallpaper image to be decoded in the parent process, which could be paired with a hypothetical vulnerability in an image decoder to escape the sandbox. This entailed difficult-to-automate reasoning about the trust-level of inputs in the parent process.
Escapes our in-process sandboxing technology for third-party libraries (RLBox) by leveraging a gap in the verification logic used to copy values from the untrusted to the trusted side of the sandbox boundary.
Extremely small testcase that exploits the special rowspan=0 semantics in HTML tables by appending >65535 rows to bypass clamping and overflow a 16-bit layout bitfield, which went undetected for years by fuzzers.
Note that a number of these bugs are sandbox escapes, which would need to be combined with other exploits to achieve a full-chain Firefox compromise. These reports presume that the sandboxed process that renders site content has already been compromised with some separate bug, and is now running attacker-controlled machine code attempting to escalate control into the privileged parent process. When crafting a sandbox escape, the model is permitted to patch the Firefox source code, so long as the modified code is restricted to run only in the sandboxed process[1]. Such bugs are notoriously difficult to find with fuzzing, and while we've had some success developing new techniques to close this gap, AI analysis provides much more comprehensive coverage of this critical surface.
Just as interesting as what the models found is what they didn't find - not because they didn't try, but because they were unable to circumvent Firefox's layered defenses. For example, in recent years we received several clever reports from security researchers that managed to escape the process sandbox by triggering prototype pollution in the privileged parent process. Rather than fixing these problems one-by-one, we made an architectural change to freeze these prototypes by default. While auditing logs from the harness, we saw many attempts to pursue this line of escape that were thwarted by this design. Observing such direct payoff from previous hardening work was even more rewarding than finding and fixing more bugs.
Harnessing Models to Build a Hardening Pipeline
We've experimented internally with LLM code audits over the past few years, with early attempts using models like GPT 4 or Sonnet 3.5 to statically analyze high risk code for vulnerabilities. These experiments showed some promise, but the high rate of false positives made them impractical to scale.
The introduction of agentic harnesses that can reliably detect security issues has completely changed this. These can find real bugs and dismiss unreproducible speculation. The key feature of such a harness is that, given the right interfaces and instructions, it can create and run reproducible test cases to dynamically test hypotheses about bugs in code. After fixing the initial set of issues that Anthropic sent to us in February, we built our own harness atop our existing fuzzing infrastructure.
We began with small-scale experiments prompting the harness to look for sandbox escapes with Claude Opus 4.6. Even with this model, we identified an impressive amount of previously-unknown vulnerabilities which required complex reasoning over multiprocess browser engine code. At first, we supervised the process in the terminal to observe the process in real-time and tune the prompts and logic. Once this was working well, we parallelized the jobs across multiple ephemeral VMs, each tasked to hunt for bugs within a specific target file and write its findings back to a bucket.
A discovery subsystem is necessary but not sufficient. In order to scale the effort, we needed to integrate it with our full security bug lifecycle: determining what to look for, where to look, and how to handle what it produces. This last part includes deduplicating against known issues, tracking bugs, triaging them, and getting fixes shipped. While the model is the core primitive powering the harness, this full pipeline is necessary to make it useful at scale.
While harnesses may be reusable across projects, this pipeline is inherently project-specific, reflecting each codebase's semantics, tooling, and processes. Standing this up required significant iteration, with a tight feedback loop alongside the Firefox engineers who were fielding the incoming bugs.
Upgrading the Models
Once the end-to-end pipeline is in place, it's trivial to swap in different models when they become available. Building this pipeline early helped us find a number of serious bugs using publicly-available models, and it also helped us hit the ground running when we had the opportunity to evaluate Claude Mythos Preview. In our experience, model upgrades increase the effectiveness of the entire pipeline: the system gets simultaneously better at finding potential bugs, creating proof-of-concept test cases to demonstrate them, and articulating their pathology and impact.
In addition to fixing the 271 bugs identified by Claude Mythos Preview in the 150 release, we've shipped more of these fixes in 149.0.2, 150.0.1, and 150.0.2. We also continue to find bugs with other means internally, and, similar to other projects, we've seen a significant uptick in external reports in the last few months.
Ultimately, every bug requires care and attention to properly fix. Staying on top of this unprecedented volume has led to a lot of work and long days over the last few months, and we're extremely proud of how the team has stepped up to meet this challenge. Over 100 people contributed code to this effort to ship the most secure Firefox yet. In addition to writing and reviewing patches, others have been building and scaling this pipeline, triaging, testing the fixes, and managing the release process for each bug.
Takeaways
Anyone building software can start using a harness with a modern model to find bugs and harden their code today. We recommend getting started now. You will find bugs, and you will set yourself up to take advantage of new models as soon as they become available.
You can start with very simple prompting, then observe and iterate. Our initial prompts were not dissimilar from those described here. Through iteration we've built out a lot of orchestration and tooling to optimize and scale the pipeline, but the essence of the inner loop remains the same: there is a bug in this part of the code, please find it and build a testcase.
We haven't bottomed on all the latent bugs in Firefox, but are quite pleased with the trajectory. Today, our scanning is largely focused on specific areas of the code (files, functions) where we instruct the system to look, based on a mix of human judgement and automated signals. In the near future, we intend to integrate this analysis into our continuous integration system to scan patches as they land in the tree. Models are quite flexible with the form of context provided, and we expect patch-based scanning to work as well or even better than file-based scanning.
The current moment is a perilous one, but also full of opportunity. Let's work together to secure the internet.
FAQ
The announcement said "271 bugs", but I count something different. What's going on?
On the advisories web page we group all internally-reported bugs as "rollup" CVEs with multiple bugs underneath them. The web page is built from yaml in the foundation-security-advisories repo, the canonical location for our CVE assignments. While some browsers do not create CVE identifiers for internally-discovered issues at all, we provide this information in order to be as transparent as possible.
In Firefox 150, there were three internal rollups: CVE-2026-6784 (154 bugs), CVE-2026-6785 (55 bugs), and CVE-2026-6786 (107 bugs).
Astute readers will notice the number of bugs in those internal rollups adds up to 316, which is more than the 271 we announced finding with Claude Mythos Preview. That's because our security team hunts for new bugs every day by attacking Firefox with a combination of (a) fuzzing systems (b) manual inspection and (c) this new agentic pipeline across a variety of models.
We fixed a total of 423 security bugs in releases in April. In addition to the 271 bugs announced two weeks ago, there were 41 externally reported bugs, with the remaining 111 discovered internally and split roughly in third between:
Bugs found using this pipeline with Claude Mythos Preview but fixed in releases other than Firefox 150
Bugs found using this pipeline with other models
Bugs found with other techniques like fuzzing
Note that we also directly credited 3 CVEs to Anthropic separate from this latest effort (CVE-2026-6746, CVE-2026-6757, CVE-2026-6758). These were fixes for bugs sent to us by the outstanding Anthropic Frontier Red team a couple months ago and we assigned unique CVEs for each as per our normal process.
What do security ratings mean?
As additional context, we apply security severity ratings from critical to low to indicate the urgency of a bug:
sec-critical and sec-high are assigned to vulnerabilities that can be triggered with normal user behavior, like browsing to a web page. We make no technical difference between these, but sec-critical bugs are reserved for issues that are publicly disclosed or known to be exploited in the wild.
sec-moderate is assigned to vulnerabilities that would otherwise be rated sec-high but require unusual and complex steps from the victim.
sec-low is assigned to bugs that are annoying but far from causing user harm (e.g, a safe crash).
Of the 271 bugs we announced for Firefox 150: 180 were sec-high, 80 were sec-moderate, and 11 were sec-low.
While we care most about critical/high bugs, it's normal for us to prioritize moderate and low security bugs in order to fix correctness issues and as a defense-in-depth mechanism.
Is a sec-high or sec-critical bug the same as a practical exploit?
Not necessarily.
In most cases, a single critical/high bug is not actually enough to compromise Firefox. This is because Firefox has a defense-in-depth architecture, so for example exploiting a JIT bug only achieves remote code execution in a sandboxed and site-specific process. Real-world attackers generally need to chain multiple exploits together to escalate privileges through one or more layers of sandboxing along with OS-level mitigations like ASLR.
We also generally don't build exploits to see whether a bug could be used by an attacker in the real world. We classify sec-high based on predictable crash symptoms such as use-after-free or out-of-bounds memory issues being reported by AddressSanitizer, and our threat model assumes that any of them could be exploitable with sufficient effort. This reduces the risk of a false negative during exploitability analysis, and more importantly it allows us to focus our resources on finding and fixing more vulnerabilities.
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.
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.
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!
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.
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!
This week's result is pretty much neutral. It looks negative in icount numbers, but that's spurious, wall time remained largely unchanged. Some big performance improvements landed in the new solver, which is not enabled by default, yet.
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.
From a business standpoint, we should have reasonable confidence that it'll stick around and be healthy for more than 10 years. We'd also like a robust ecosystem of code and tools that we can rely on, and experts we can hire.
The open web is a critical platform for applications that handle highly sensitive data, from private communications to financial transactions and medical records. Traditionally, servers are trusted to deliver the appropriate code and resources for their web applications to browsers, who then provide a secure and isolated environment for their execution. In some circumstances, this trust model falls short.
Consider a browser-based messaging application, like Signal or WhatsApp, which uses end-to-end encryption. The browser depends on the server to provide a trustworthy javascript implementation of the app; which ensures the user's messages and cryptographic keys are suitably protected. A malicious or compromised server could selectively serve modified code to some users, undermining their security with little risk of detection. This challenges the basic premise of end-to-end encryption: that a misbehaving server should not be able to compromise user security.
Towards Verifiable Security on the Web
For web applications to be trustworthy in the presence of malicious servers, two properties are essential:
Integrity: The code executed by the user matches what the developer committed to in a manifest.
Transparency: These manifests are publicly logged and can be independently audited.
WAICT allows websites to cryptographically bind their client-side code to a manifest and commit that manifest to a publicly auditable log. Sites which need this stronger trust model can then opt in to WAICT enforcement. If an opted-in site delivers code that has not been publicly logged, the browser rejects it and attacks that were previously invisible become observable and attributable. This ensures that the code delivered to user's machines is consistent with the publicly available code which security researchers can inspect.
Bringing Integrity and Transparency to the Open Web
We are collaborating with partners across the ecosystem - including Cloudflare, the Freedom of the Press Foundation and Meta - to ensure the deployment model is practical, secure, and as simple as possible. You can learn more about WAICT in our joint talk at Real World Cryptography 2026.
An early prototype of WAICT is available behind a pref in Firefox Nightly to help validate the approach in real-world scenarios. You can test drive the prototype on https://waict.dev/ - including an end-to-end encrypted video calling app secured by WAICT. The implementation is a work in progress, not a finished solution, but it provides a concrete foundation for iteration and standardization. We're developing the specifications in the open and welcome early feedback.
WAICT marks an important step toward making strong, verifiable application security a first-class property of the open web.
With special thanks to Anna Weine, Benjamin Beurdouche, Christoph Kerschbaumer, Dennis Jackson, Frederik Braun, and Tom Schuster.
Mozilla has joined a coalition of 19 digital rights organizations and technology providers in a joint statement, urging UK policymakers not to undermine the open web in their efforts to protect young people online.
Our mission is grounded in the belief that the internet must remain open and accessible to all, and that privacy and security online are fundamental. Around the globe, we are witnessing blunt policy interventions like age gates or restrictions on VPNs that put these values at risk. Child safety is a complex and central issue to us all, and as we have said before, Mozilla supports robust, proportionate safeguards for minors. However, we are concerned that mandatory age verification or VPN restrictions undermine online privacy and security, people's ability to express themselves and access information, and ultimately the health of the web itself.
In an attempt to address tough questions surrounding online harms, UK policymakers are currently consulting on which services and features should be placed behind age gates as part of a national consultation on online harms. A broad range of services are being considered for age restrictions, including search engines, games and VPNs. Even targeted age restrictions of certain features would require all users to submit to age assurance systems. However, existing age assurance technologies have been found to either undermine users' privacy and data security, to be insufficiently accurate or not widely accessible across populations. Age restrictions could also entrench the dominance of gatekeepers and fragment the web into a patchwork of age-gated jurisdictions.
Beyond the significant risks associated with mandating age assurance across core internet services, we are particularly concerned about proposals to restrict the use of VPNs. VPNs and similar services are essential privacy and security tools used by millions of users for legitimate purposes. Restricting the use of privacy-preserving technologies undermines efforts to empower users to navigate the web safely and to develop digital literacy.
Rather than age-restricting a growing number of services, we believe that addressing the roots of child safety concerns, such as poor content moderation, irresponsible data practices, and deceptive design, is a more proportionate and effective way forward. We thus urge policymakers to prioritize policy interventions that centre children's' rights and all users' agency and choice, and protect, not undermine, the open web.
Last weekend at IndieWebCamp I noticed James had setup his iPhone in grayscale. I think I first saw that on Jeremy's phone years ago. I remember trying it on my iPod Touch for a while, eventually switching back to see color photos.
This morning while chatting with James I asked him about his grayscale setup and why. He pointed out it's less distracting, a calmer experience, and helps him stay focused when he uses his iPhone for specific tasks.
I decided to give it another try. The setting is quite buried. Here are the items to tap, starting from your home screen, or wherever you moved your ⚙️ Settings app:
⚙️ Settings
🟦 Accessibility >
🟦 Display & Text Size >
Color Filters >
Color Filters (⚫️__) [slide this toggle to the right to turn it on]
Greyscale [tap this and you should see it checked]
James said one more setting has helped him stick with grayscale for years now. Triple-press the side button to toggle color/grayscale modes helps quickly switch to color to view a photo or a video, actual color content, then triple-press-side-button to return to a calmer UI.
⚙️ Settings
⏺ Accessibility >
⏺ Accessibility Shortcut >
Color Filters [tap this and you should see it checked]
In addition, I have found the back-tap feature handy and personally more memorable. Double (or triple) back-tap to toggle color/grayscale mode and toggle back.
⚙️ Settings
⏺ Accessibility >
👆🏻 Touch >
Back Tap >
Double-tap >
Color Filters [tap this and you should see it checked]
When using my phone outside in the sun, I noticed the absence of color made it hard to distinguish or even read some things. I changed a few more settings to improve sunlight readability/usability.
⚙️ Settings
⏺ Accessibility >
⏺ Display & Text Size >
Bold Text (⚫️__) [tap/slide this toggle to the right to turn it on]
Increase Contrast (⚫️__) [tap/slide this too]
Differentiate Without Color (⚫️__) [tap/slide this too]
In the absence of color on my iPhone, I have spent less time using it today, felt more focused when I used it for a specific task, and have started to feel both less compelled to check things, and less of a "rush" when interacting with iPhone apps and their user interfaces.
Color saturated apps stripped of their color are starting to feel like older apps or appliances. Switching Spotify playlists felt a bit like pressing station presets on a car radio. Discord felt like an enhanced IRC client. Even some of my rotating lock screen landscape photos have strong Ansel Adams vibes, while my urban lockscreen photos have a calmer dreamlike quality.
Perhaps the use of color in modern mobile app user interfaces is the new chartjunk, extraneous and distracting from the task at hand, just as classic chartjunk is extraneous and distracting from the information being presented. Most mobile apps seem to be in an attention-seeking arms race against each other, ever more saturated colors to draw you in like a casino.
Using a grayscale iPhone user interface for most of the day has felt noticeably calmer. Enough for me to try it again for at least a few days and see how it goes.
Thanks again to James for his explanations and encouragement. See his write-up: Using greyscale, when he started, why, why he continues to use it, and instructions for his setup.
Try it for yourself and see how it feels.
May the Force of your will be with you, free of distractions and dopamine conditioned impulses.
This talk was given as part of the Data Club Lightning Talk Session on February 11th, 2022. More on https://blog.mozilla.org/data/2022/02/25/this-week-in-glean-your-personal-glean-data-pipeline Information about Glean: https://mozilla.github.io/glean/book/index.html
The Rust Project has been building up a good history of participating in various open-source mentorship programs, including Google Summer of Code for three years (including this year) and previously OSPP. We're happy to announce that this year we are also participating in Outreachy starting in the May 2026 cohort.
Each of these mentorship programs has different criteria for eligibility depending on who they target and the motivations of the program. Outreachy provides internships in open source, to people from any background who face underrepresentation, systemic bias, or discrimination in the technical industry where they are living. You can learn more about the Outreachy program on their website.
What is Outreachy and how is it different than Google Summer of Code
Outreachy is similar to Google Summer of Code (GSoC) in some aspects, but different in others. First off, unlike GSoC, Outreachy interns first apply to the overall program and only then can apply to specific communities. Second, while oftentimes GSoC applicants submit various contributions prior to their application, Outreachy has a dedicated period where contributions are not just optional, but required. Finally, Outreachy applicants submit an application similar to GSoC applications and communities pick interns based on those applications and the interns' contributions. Outreachy has two internship periods per year, one running from May to August (in which we are currently participating) and one from December to March.
The other major difference between Google Summer of Code and Outreachy is the source of intern stipends. For GSoC, Google graciously covers contributor stipends and overhead. For Outreachy, communities instead cover the interns' stipends and overhead.
We are mentoring 4 interns for the May 2026 cohort
Because of limited funding availability and mentoring capacity, the Rust Project decided to select four interns for mentorship. We'll briefly share these projects below.
This project aims to implement an experimental feature for calling overloaded C++ functions from Rust, and to begin testing that feature in a few representative use cases.
This project aims to develop the workflows to run and analyze code coverage of the compiler at the scale of the entire compiler test suite and on ecosystem crates detected by crater. The hope is to be able to detect when the compiler is inadequately tested, both within the compiler and in the ecosystem, and to build tools to do continuous analysis on this.
Fuzzing the a-mir-formality type system implementation
This project aims to implement fuzzing for a-mir-formality, an in-progress model for Rust's type and trait system. The goal is to generate programs in order to identify rules with underspecified semantics in a-mir-formality.
Improve the security of GitHub Actions of the Rust Project
This project aims to improve the security of GitHub Actions workflows of the repositories owned by the Rust Project. It will develop tools and workflows, integrating with existing software, to analyze Github repositories and detect if they follow the best security practices, fix existing issues, and ensure that good security practices are followed in the future.
What's next
Over the next 3 months, the interns will work closely with their mentors to make progress on their projects. When the internship period is over, we'll write another blog post to share the results! See you then!
We also want to thank all the people that submitted applications and made contributions. It was quite tough to decide which applicants to select. Hopefully we will participate in Outreachy again in the future and there are other opportunities to participate. We also very much welcome you to stick around and continue being involved - there is a ton of places in the Rust Project with opportunities to be involved.
You can download it here: 