Nokia powers KDDI Policy & Charging with OTEL, Red Hat, & Intel, driving innovation and collaboration forward.   ​  ​Nokia powers KDDI Policy & Charging with OTEL, Red Hat, & Intel, driving innovation and collaboration forward. Telecommunications Blog | Dell

Discover how Miguel Ortega uses Dell Pro Max to push animated horror films beyond limits.   ​  ​Discover how Miguel Ortega uses Dell Pro Max to push animated horror films beyond limits. Dell Pro Max Blog | Dell

Welcome to the next episode in our GitHub for Beginners series, where we’re diving into the world of GitHub Copilot. We’re now on our seventh episode, and we’ve covered quite a lot of ground. You can check out all our previous episodes on our blog or as videos. Today we’re going to dive into the world of testing, a much needed but historically tedious part of the development process. This is especially true as our codebase becomes larger and more complex. Fortunately, we can use GitHub Copilot to help automate some of this process. After all, one of the most basic questions we have when writing code is: “Does it work?” For the demos in this series, we’re using GitHub Copilot in Visual Studio Code. Copilot is available in other IDEs, but the available functionality may vary depending on your environment. Testing 101 Before we jump into how to use GitHub Copilot to write some tests, we should talk about testing, why it’s important, and different ways to test your code. Be aware that test testing is a very deep topic, and we’ll only be touching the surface here. Covering the nuances of testing would be an entire course in and of itself. So why is testing important? In short, it’s how you make sure that your code does what you expect. Testing can take many different forms, such as: Acceptance tests: Tests that ensure your app meets a set of defined functionality. Integration tests: Tests that verify your app can talk across various systems such as databases and APIs. Unit tests: Tests focused on breaking the code into small, isolated pieces called units. These make sure the individual units do exactly what you’d expect them to do. Writing unit tests As we just covered, unit tests work by breaking down your code into smaller chunks that are easier to test. Making sure each individual piece is doing what it’s supposed to do increases confidence that the entire app will work when you put all the pieces together. One of the great things about unit tests is that you can automate the process. Once you’ve created a large battery of tests, you can literally run thousands of tests with a single command. This gives you a good indicator regarding the health of your application. By regularly running these tests, you’ll also discover if any changes to your code broke something you might not have been expecting. So how do you use GitHub Copilot to create some unit tests? Open up your code and highlight a section that you want to test. For example, you might highlight a specific function. Open up Copilot Chat. You might notice that Copilot suggests using the /tests slash command to write tests. Send Copilot the following prompt: /tests add unit tests for my code If Copilot asks if you want to configure a test framework, select Dismiss. Review the plan and code suggestions to make sure you understand what changes Copilot is going to make. Click the Add to new file button at the top of the code suggestion to create the tests. Save the new file. Run the tests by running the following command in your terminal: python -m pytest Congratulations! You just added some unit tests to your code! If you’d like to see a demo of this in action, make sure to watch the video! Test-driven development Now that you’ve seen how to write some unit tests, let’s talk a little bit about test-driven development (TDD). What exactly is TDD? It’s a process where you use the tests to drive how you develop your code. When using TDD, you write your tests first, and then create the implementation afterward. The process takes a little bit of adjusting how you think about development, but it does come with several advantages. It gives you the opportunity to see how your code will behave and ensure the tests you’re writing are testing what you expect them to test.  A concept that can be helpful for wrapping your brain around this is called “red, green, refactor.” In this process, you create the tests first, and they fail. They might not even build! This is the red stage. Then you write just enough code to get your tests to pass. For example, if you’re writing a test that makes sure an error is thrown if a number is less than 0, you write just enough code to throw that error on that condition. When you return to the test, it now passes. You’ve actively made a change to the codebase to implement the desired functionality. This is the green stage.  Finally, you implement any refactoring to make the code look good. Now that it works, you can focus on making it pretty. The entire time you are working on this, you keep running the unit tests to make sure your changes don’t break anything. As you probably guessed, this is the refactor stage. GitHub Copilot can help you with TDD. It’s one of the hidden little tricks that Copilot is able to do—you can tell it code will exist and generate tests based on that information. For example, if you were working on an email validation app, you could send the following prompt to Copilot Chat: I’m going to be adding a new validator function for usernames. Usernames must be between 3 and 16 characters, start with a letter or an underscore, not use multiple underscores to start, and after the first character chan have letters, numbers, and underscores. Just create the new test functions. This prompt provides the criteria that you’re expecting and gives it to Copilot. Copilot will then use this prompt to generate unit tests to test that functionality. If you ran these tests, they would fail, because you’ve only created the tests. Red stage. Now, to move on to the green stage, you could send Copilot the following prompt: Create the implementation Copilot will now generate the code to make sure these

For over a decade, GitHub has offered enterprise authentication using SAML (Security Assertion Markup Language), starting with our 2.0.0 release of GitHub Enterprise Server in November 2014. SAML single sign-on (SSO) allows enterprises to integrate their existing identity providers with a broad range of GitHub products, extend conditional access policies, and bring enterprise organization management to GitHub. To ship this feature, we had to build and maintain support for the SAML 2.0 specification, which defines how to perform authentication and establish trust between an identity provider and our products, the service provider. This involves generating SAML metadata for identity providers, generating SAML authentication requests as part of the service provider–initiated SSO flow, and most importantly, processing and validating SAML responses from an identity provider in order to authenticate users. These code paths are critical from a security perspective. Here’s why:  Any bug in how authentication is established and validated between the service and identity providers can lead to a bypass of authentication or impersonation of other users.  These areas of the codebase involve XML parsing and cryptography, and are dependent on complex specifications, such as the XML Signature, XML Encryption, and XML Schema standards.  The attack surface of SAML code is very broad, so the data that is validated for authentication and passed through users’ (and potential attackers’) browsers could be manipulated.  This combination of security criticality, complexity, and attack surface puts the implementation of SAML at a higher level of risk than most of the code we build and maintain. Background When we launched SAML support in 2014, there were few libraries available for implementing it. After experimenting initially with ruby-saml, we decided to create our own implementation to better suit our needs.  Over the years since, we have continually invested in hardening these authentication flows, including working with security researchers both internally and through our Security Bug Bounty to identify and fix vulnerabilities impacting our implementation.  However, for each vulnerability addressed, there remained lingering concerns given the breadth and complexity of root causes we identified. This is why we decided to take a step back and rethink how we could move forward in a more sustainable and holistic manner to secure our implementation. So, how do you build trust in a technology as complex and risky as SAML?  Last year, this is exactly the question our engineering team set out to answer. We took a hard look at our homegrown implementation and decided it was time for change. We spent time evaluating the previous bounties we’d faced and brainstormed new ideas on how to improve our SAML strategy. During this process, we identified several promising changes we could make to regain our confidence in SAML.  In this article, we’ll describe the four key steps we took to get there: Rethinking our library: Evaluating the ruby-saml library and auditing its implementation Validating the new library with A/B testing: Building a system where we could safely evaluate and observe changes to our SAML processing logic Schema validations and minimizing our attack surface: Reducing the complexity of input processing by tightening schema validation Limiting our vulnerability impact: Using multiple parsers to decrease risk Rethinking our library When we reviewed our internal implementation, we recognized the advantages of transitioning to a library with strong community support that we could contribute to alongside a broader set of developers.  After reviewing a number of ruby SAML libraries, we decided to focus again on utilizing the ruby-saml library maintained by Sixto Martín for a few reasons:  This library is used by a number of critical SaaS products, including broad adoption through its usage in omniauth-saml. Recent bugs and vulnerabilities were being reported and fixed in the library, showing active maintenance and security response.  These vulnerabilities and fixes were distributed through the GitHub Advisory Database and CVEs, and had updates pushed through Dependabot, which integrates well with our existing vulnerability management processes.  This support and automation is something we wouldn’t be able to benefit from with our own internal implementation. But moving away from our internal implementation wasn’t a simple decision. We had grown familiar with it, and had invested significant time and effort into identifying and addressing vulnerabilities. We didn’t want to have to retread the same vulnerabilities and issues we had with our own code.  With that concern, we set out to see what work across our security and engineering teams we could do to gain more confidence in this new library before making a potential switch. In collaboration with our bug bounty team and researchers, our product security team, and the GitHub Security Lab, we laid out a gauntlet of validation and testing activities. We spun up a number of security auditing activities, worked with our VIP bug bounty researchers (aka Hacktocats) who had expertise in this area (thanks @ahacker1) and researchers on the GitHub Security Lab team (thanks @p-) to perform in-depth code analysis and application security testing.  This work resulted in the identification of critical vulnerabilities in the ruby-saml library and highlighted areas for overall hardening that could be applied to the library to remove the possibility of classes of vulnerabilities in the code. But is security testing and auditing enough to confidently move to this new library? Even with this focus on testing, assessment, and vulnerability remediation, we knew from experience that we couldn’t just rely on this point-in-time analysis.  The underlying code paths are just too complex to hang our hat on any amount of time-bound code review. With that decision, we shifted our focus toward engineering efforts to validate the new library, identify edge cases, and limit the attack surface of our SAML code. Validating the new library with A/B testing GitHub.com processes around one million SAML payloads per business day, making it the most widely used form of external authentication that we support. Because this code is the front door for so many enterprise customers, any changes require a high degree of scrutiny and testing.  In order to preserve the stability of our SAML processing code

From solo projects to major frameworks, open source maintainers are doing the work of many, for many—oftentimes without guaranteed funding. Thankfully, programs like GitHub Sponsors can make a critical difference in the long-term health of a project. But what makes an open source project attractive to sponsors?  We asked a few internal experts to analyze eight funded open source projects on GitHub. We then used that information to identify patterns and insights that could help maintainers and contributors understand what drives sponsorships in open source. The answer isn’t one-size-fits-all, but the most successful projects tend to get several of these right. With Maintainer Month well underway, our GitHub panel is a bit slimmer this month, but it includes:  Abigail Cabunoc Mayes, aka @abbycabs, who works on open source maintainer programs and serves on the board of the OpenJS foundation.  Kevin Crosby, aka @kevincrosby, who runs GitHub’s open source funding program.  Jeff Luszcz, aka @jeffrey-luszcz, who helps manage GitHub’s open source program office (OSPO). Below, we’ll highlight some of these projects—and break down the trends that make them stand out in today’s evolving open source landscape.  Top trends, at a glance In this analysis, we saw that projects that accomplish the following tend to receive funding:  Community engagement drives success: Projects with passionate user bases that value both the maintainers and the project. Projects that solve specific pain points can build powerful communities: Solving difficult or niche problems in unique ways unlocks value for the user. User-facing tools and packaging often get more visibility: Packaging tools or “products” that developers and members interact with daily. In contrast, foundational infrastructure projects that power these tools can struggle for visibility and funding, despite being essential to the ecosystem. Offer value in other ways that matter: Projects offering clear value through support contracts, training, memberships, or other services. Get the full analysis > 1. Ladybird: the open source web browser 🦅 Website Source C++ HTML JavaScript CMake Objective-C++ Swift 📜 BSD 2-Clause License Started by the former maintainer of SerenityOS and funded by one of the cofounders of GitHub (Chris Wanstrath, aka @defunkt), Ladybird is an independent, cross-platform web browser being built from scratch in C++/Swift that ships its own LibWeb rendering and LibJS JavaScript engines.  The project’s 501(c)(3) Ladybird Browser Initiative rejects ad deals and search‑engine royalties outright, funding itself only through unrestricted donations. That “no strings attached” stance resonates with privacy‑minded companies and individuals. Ladybird uses a sandboxed multi-process architecture and targets Linux, macOS, and other Unix-like systems—aiming to offer a modern, standards-compliant alternative that relies on zero Chromium or Gecko code. Why it matters Ladybird is a perfect example of values-based funding. Kevin expands on this: “There’s a desire among people for less data collection via web browsers and search engines, and Ladybird offers an untracked web experience.” Tapping into users’ values—like privacy, independence, or ethical tech—can motivate sponsorship beyond just technical features.  “This is a huge deal,” Kevin says. “The dream of an OSS web browser is one that a lot of people are ready to buy into. People are willing to pay not to have their data sold—data integrity is super valuable.” Ladybird also benefited from a strong “founder effect”: it was launched by well-known developers in the open source community, which helped it quickly attract attention and funding. Abigail speaks to this: “Projects started by well-known community members can gain momentum and financial backing much faster than those building an audience from scratch. While most projects in this list took years to build their funding community, Ladybird leveraged its founders’ reputations from day one.” 2. Neovim: the editor that inspires devotion ✍️ Website Source Vim Script Lua C CMake Python Shell 📜 Apache 2.0 License Neovim is a modern reimagining of the classic Vim text editor, designed to enhance extensibility, maintainability, and user experience. Launched in 2014, it introduces features like built-in Language Server Protocol (LSP) support, asynchronous I/O, and Lua scripting capabilities, all while maintaining compatibility with most of Vim’s features .  By swapping Vim‑script internals for an embedded Lua runtime, asynchronous job control, and a remote‑UI RPC API, Neovim can act as:  A terminal‑first IDE with built‑in LSP, Tree‑sitter syntax trees, an embedded terminal, and virtual‑text/inline‑diagnostics, An embeddable component inside other apps, or A headless background process that multiple GUIs attach to. Neovim has also cultivated a thriving ecosystem. Their delightful collection of plugins has become a major part of its appeal and funding story, offering developers highly customizable experiences out of the box. Why it matters Neovim perfectly captures maybe the strongest funding pattern we’ve seen: developers will pay to support tools they use every single day and that have become a part of their identity. Jeff gets it: “People are passionate about their text editors. And developers love Neovim because it continues to improve things.” Kevin continues: “A common thing is that tools that are more user facing get more funding because they’re more top of mind—whereas tools that are lower in the stack don’t get as much visibility. People really care about their text editors and identify with their editor.” 3. RunAsUser: system privileges made simple 🔑 Source PowerShell 📜 MIT License Kelvin Tegelaar builds multiple PowerShell modules for his community. RunAsUser is one featured module that lets you launch processes in the security context of the currently-logged-on user—even when the script itself is running as SYSTEM.  That’s handy for Remote Monitoring and Management (RMM) tools, scheduled tasks, or other automations commonly used by system administrators and managed service providers that normally run under the SYSTEM account but occasionally need to interact with resources that only the interactive user can access. Why it matters When you solve a pain point for a specific audience, they’re more likely to back you financially. Kelvin does this by making the lives of Windows system administrators (or sysadmins for short) easier. RunAsUser is a specific example of this.  “The users of this project value the maintainer, Kelvin’s, support,” Kevin says. “It’s not only that the project is

We just launched season three of the GitHub Secure Code Game, and this time we’re putting you face to face with the security risks introduced by artificial intelligence. Get ready to learn by doing and have fun doing it! First, you’ll step into the shoes of an adversary crafting malicious prompts. Then, you’ll secure your application against those attacks. The Secure Code Game is a free software security course suitable for all developer levels, where players fix intentionally vulnerable code to build code security skills. By placing gameplay directly in the code editor—a developer’s natural habitat—it helps them practice spotting vulnerabilities where they normally work. Its straightforward setup allows players to start in under two minutes using Codespaces.  We launched the first season of the Secure Code Game in March 2023 to fill a gap in developer training, where security often takes a backseat to functionality. To grab attention, we presented seemingly flawless code snippets riddled with critical vulnerabilities, like the OWASP Top 10. We then gamified the learning by challenging players to efficiently fix these issues without introducing new ones or missing edge cases. Supported by a strong community that contributed challenges, season two premiered a year later. Since then, over 10,000 developers across enterprise, open source, and education communities have played to sharpen their skills. This training was a one-of-a-kind experience. Initially, when I looked at the entire code file, I just thought it was completely normal. I didn’t see any flaws. The unit tests were completely normal, and the code seemed perfect. But the vulnerability was right in front of my eyes. It made me realize how much of a gap there is in identifying even the most basic flaws. It made me more cautious. Sanyam Mehta, Back-end developer This is a pretty fun way to learn! I would definitely recommend this game, as it helped me be more aware of the vulnerabilities out there. Tyler Anton, Computer science student Now’s the perfect time to elevate your skills! Today, we’re excited to launch the third season, which immerses players into the fascinating world of artificial intelligence through six realistic challenges. As the world moves decisively into a new era—McKinsey & Company reports that the use of generative AI increased from 33% in 2023 to 71% in 2024 and GitHub Copilot is now being used by more than 77,000 organizations—there’s no better time to enhance your skills. What you’ll learn Each of the six security challenges focuses on a different defensive technique. The levels get progressively harder as they build on the defensive techniques of the previous ones. Some of the topics you’ll learn about include: Crafting robust system prompts: Securely design the initial instructions that guide the model’s behavior, ensuring desired, safe, and relevant outputs by setting its role, constraints, format, and context. Output validation: Prevent leaks by verifying that the output conforms to certain predefined rules, formats, or expectations. Input filtering: Examine, modify, or block user-provided text before it’s fed into the model to prevent harmful or irrelevant content from influencing the model as it generates output. LLM self-verification: Use this technique to have the Large Language Model (LLM) check its own output for accuracy, consistency, and compliance with defined rules or constraints. This may involve checking for errors, validating reasoning, or confirming adherence to policies. Self-verification can be prompted directly or built into the model’s response generation. Progressing through season three requires players to hack LLMs. Each challenge begins with a set of guiding instructions for the LLM provided in the form of a code and a system message. These elements might include gaps or edge cases that could be exploited using a malicious prompt. Your task is to identify the vulnerabilities and craft prompts to manipulate the model into exposing a hidden secret. After exploiting the vulnerability, your next task is to refine the code and system message to prevent future leaks from those malicious prompts. You must do this while maintaining the functionality of the code. I learned to spot vulnerabilities, where and how they occur, and to correct them effectively before pushing them out to the world. I would absolutely recommend this training to anyone, not only in cybersecurity but software development too. Rajeev Mandalam, Application security at Boeing One of the major takeaways was that it’s good to focus on details because they could often lead to vulnerabilities that you wouldn’t have imagined. In terms of the format, I liked the fact that it didn’t focus on one particular programming language, and the whole emphasis is on the code concepts. I also liked how easy it was to navigate between game levels. The game provided me with a great new skillset to add to my professional journey. Reshmi Mehta, Security analyst at Alcon How to get started If you’re eager to start learning, we’ve got a Secure Code Game repository all set up and ready to go. It includes instructions for all the seasons, so you can experience everything it has to offer. Just browse through the README and get started. How season three came together Don’t wait to be an expert. Build, share, and the right people will find you. Open source changed my life, and it can do the same for you. Bartosz Gałek (@bgalek), contributor of Secure Code Game season three It all started in FOSDEM 2025 in Belgium, where I presented the Secure Code Game to a group of open source maintainers. Bartosz was in the audience and here’s what happened in his own words: The Secure Code Game immediately clicked, as security and game development is my thing! After the talk, I thanked Joseph on LinkedIn and shared HackMerlin with him—a game I created that challenges players to test their prompting skills. To my surprise, he liked it! One thing led to another, and HackMerlin became the base of our collaboration for season three. The whole journey started as a silly idea, but it turned into something much bigger. A key challenge in moving from

Confidently take your telecom transformation to the next level with Dell Technologies’ Implementation Services.   ​  ​Confidently take your telecom transformation to the next level with Dell Technologies’ Implementation Services. Telecommunications Blog | Dell

Operational innovation through telecom transformation.   ​  ​Operational innovation through telecom transformation. Telecommunications Blog | Dell

“Even as a remote company, ​we​ really hate remote work,” says Ryan Yep, Head of partnerships and GTM strategy​ at …   ​  ​“Even as a remote company, ​we​ really hate remote work,” says Ryan Yep, Head of partnerships and GTM strategy​ at … Dell Pro Max Blog | Dell

Dell AX System for Azure Local is now a Premier Solution. Simplify, innovate and unlock greater value with Dell and Microsoft.   ​  ​Dell AX System for Azure Local is now a Premier Solution. Simplify, innovate and unlock greater value with Dell and Microsoft. Software-Defined Infrastructure Blog | Dell

Empowering governments, enterprises and innovators to build trusted, controlled and culturally relevant AI.   ​  ​Empowering governments, enterprises and innovators to build trusted, controlled and culturally relevant AI. Customer Blog | Dell

Last month, we released agent mode as a step toward building GitHub Copilot into a system that not only works with you, but works for you. When you give it a natural-language prompt, Copilot’s agent mode works to execute it on your behalf, automating processes and workflows that would otherwise take a lot of time and giving you space to focus on higher-level problem solving.​  For those who are newer to coding, agent mode can be a useful synchronous tool when it comes to developing an app (whereas our new preview of coding agent in Copilot offers asynchronous task completion capabilities). But it’s equally, if not more so, an incredibly useful tool for more seasoned developers looking to work faster. With agent mode, you can quickly move from prompting Copilot with a higher-level requirement to testing out a prototype. Plus, we’re still seeing new use cases unfold among developers of all levels.  Let’s take a closer look at what agent mode is, how it works, and how you can use it.  But first, what is GitHub Copilot agent mode?  GitHub Copilot agent mode is an autonomous and agentic real-time, synchronous collaborator that performs multi-step coding tasks based on natural-language prompts. More simply, it’s a problem solver that understands your intent, builds a solution, and iterates until it gets it right.  Agent mode can: Analyze your codebase to grasp the full context. Plan and execute multi-step solutions. Run commands or tests. Reach out to external tools for specialized tasks. Suggest architectural improvements. Run and refine its own work through an agentic loop, including planning, applying changes, testing, and iterating. Rather than just responding to requests, agent mode actively works toward your goal. You define the outcome, and it determines the best approach—seeking feedback from you as needed, testing its own solutions, and refining its work in real time. And as it operates, you can see its reasoning, decision-making process, and the tools it uses. Whether you want Copilot to analyze your code base, propose file edits, or run tests, agent mode allows Copilot to complete all the necessary subtasks on its own.  On top of that, agent mode enables Copilot to quickly recognize errors and fix them automatically.  Here’s how agent mode compares to some of our other AI coding tools:  Tool What it is Agent mode A mode where Copilot is capable of iterating on its own code, recognizing errors, and fixing them automatically GitHub Copilot coding agent An autonomous SWE agent that asynchronously works on your behalf to do everything from resolving issues to solving for human feedback  Code completion A Copilot feature that offers autocomplete-style suggestions in supported IDEs  How does agent mode in GitHub Copilot work? At its core, agent mode works as an orchestrator of several different tools and variables (e.g., your prompt and workspace) through a system prompt that tells Copilot to keep iterating on its own output until it reaches a final state.  When you send a natural-language prompt to Copilot agent mode, it’s augmented by our backend system prompt. This includes your query, a summarized structure of the workspace, machine context, and tool descriptions. Here’s a breakdown of what happens when you use Copilot agent mode:  You prompt Copilot with clear requirements on the end result you want. Copilot parses the question and asks an AI language model how to resolve the task, then begins working. Copilot monitors the first iteration for errors and determines how to fix them. Agent mode autonomously uses various tools to get to the end result.  After it runs commands and applies edits, agent mode works to detect syntax errors, terminal output, test results, and build errors. Based on the results, it then determines how to course-correct, whether that’s by making additional edits, terminal commands, or performing tool calls. The LLM has an ever-expanding set of tools to call, each with capabilities that help Copilot complete the task—and you’re in charge of which tools you want agent mode to use. Each tool, such as read_file, edit_file, and run_in_terminal, gives Copilot detailed instructions on how and when to use it. These tools allow Copilot to search your workspace, read file contents, run terminal commands, get errors from the editor and apply proposed changes, and more. You’re not limited to just built-in tools. You can extend agent mode’s capabilities by installing more specialized tools from Model Context Protocol (MCP) servers or extensions. MCP is an open standard that enables AI models to interact with external tools and services through a unified interface. We recently announced the GitHub MCP server, which allows you to: Automate GitHub workflows and processes. Extract and analyze data from GitHub repositories. Build AI-powered tools and applications that interact with GitHub’s ecosystem. Combining the power of agent mode and MCP means that the LLM’s knowledge expands even further once connected to your services and data sources. ✨ What can I do with GitHub Copilot agent mode? What are some use cases? Agent mode brings an agentic workflow to GitHub Copilot, offering real-time, synchronous help across any number of tasks in your workflows.  Whether you let the agent take the idea and run with it, or you lead it each step of the way and control the path, you’re in the driver’s seat with Copilot as your, well, copilot.   In my personal experience, agent mode has been a game-changer for starting small projects and proof-of-concepts from scratch. When I needed to modernize our open source history visualization scripts, I put agent mode to the test with both GPT-4o and Claude 3.7 models. The results were remarkable—it transformed our basic matplotlib histograms into sophisticated, SVG-based animated line charts with minimal guidance. What truly impressed me was seeing Copilot produce a perfect SVG histogram on its first attempt. This intelligent assistance not only accelerates development but has fundamentally transformed how I approach both prototyping and refactoring. Zhe-You Liu, Apache Airflow Committer Here are some ways we’ve seen developers inside and outside GitHub use agent mode: Refactoring code  Migrating

May is Maintainer Month–a chance to spotlight the people behind the projects powering the internet. We’re marking the occasion by opening applications to two high-profile opportunities where open source projects can take center stage. Whether you’re maintaining a mission-critical dev tool or launching a weekend side project that’s gaining traction, this is your shot to show the world what you’ve built. This summer and fall (or winter and spring, depending on what part of the world you live in!), bring your project to life. Connect with the developers who’ll use it. Tell the story only you can tell. Event 1 – Open Source Spotlight @ WeAreDevelopers World Congress July 9 – 11, 2025 Berlin, Germany Apply by May 31 We’re heading to Europe for the 10th anniversary of WeAreDevelopers World Congress–one of the world’s largest developer conferences, drawing more than 15,000 engineers, contributors, and tech leaders for three days of code, conversation, and controlled chaos.  We’re bringing the Open Source Spotlight back to the show floor–a dedicated space in our booth, where your terminal, your live demo, and your repository get real-world attention. The crew is all here & already having some great conversations about @OpenFeature & #featureflags @github‘s Open Source Spotlight booth @WeAreDevs World Congress Be sure to drop by Exhibit Hall 2.2 to say hello pic.twitter.com/cJSgRIRX4f — DevCycle (@DevCycleHQ) July 18, 2024 Fun fact: Thomas Dohmke, GitHub CEO, Copilot power user, and my boss’s boss’s boss is keynoting at this year’s World Congress. Your project could be just a few booths away. (Not saying he’ll swing by, but it has happened). What’s in it for you (besides fame, glory, and stickers)? Live demo space in GitHub’s booth Two free exhibitor passes to explore the full event Visibility with more than 15,000 developers, decision makers, and future fans Apply for Open Source Spotlight in Berlin Event 2 – Open Source Zone @ GitHub Universe October 29 – 30, 2025 San Francisco, CA Apply by July 31 The Open Source Zone is a vibrant corner of GitHub Universe dedicated to celebrating the open source community. This is your chance to demo your project live, share your story, and connect with thousands of developers, contributors, and industry leaders from around the world. Last year, maintainers showcased everything from browser-based VR to open source AI tooling. This year, we want to see your project on display. @dmarcos casually bending reality with A-Frame in the Open Source Zone last year Ready to bring your project from README to real-world? Here’s what you get: Your project in front of thousands of developers and decision makers A booth space with power, Wi-Fi, and good vibes Two free passes (because flying solo isn’t always fun) Travel stipends are available if you’re coming from far away Apply for Open Source Zone in San Francisco “Booth duty isn’t everyone’s idea of a vacation, but if you’re passionate about your project and love nerding out with other developers, these are some of the best places to do it.” Lee Reilly, self-quoting in third person like it’s totally normal  For maintainers, by maintainers Maintainer Month is about celebrating your work and amplifying your impact, and these events are built to do exactly that. So whether you’re building a Python package, hardware firmware, or the next big AI dev tool, we want to help you share it with the community that matters most: other developers. Let’s celebrate maintainers. Not just in May, but all year long. Got questions? Curious if your project’s a fit? Drop us a line at opensourcezone@github.com. We’d love to hear what you’re working on. The post Shine a spotlight on your open source project appeared first on The GitHub Blog. ​ Open Source The GitHub Blog

Memory Tagging Extension (MTE) is an advanced memory safety feature that is intended to make memory corruption vulnerabilities almost impossible to exploit. But no mitigation is ever completely airtight—especially in kernel code that manipulates memory at a low level. Last year, I wrote about CVE-2023-6241, a vulnerability in ARM’s Mali GPU driver, which enabled an untrusted Android app to bypass MTE and gain arbitrary kernel code execution. In this post, I’ll walk through CVE-2025-0072: a newly patched vulnerability that I also found in ARM’s Mali GPU driver. Like the previous one, it enables a malicious Android app to bypass MTE and gain arbitrary kernel code execution. I reported the issue to Arm on December 12, 2024. It was fixed in Mali driver version r54p0, released publicly on May 2, 2025, and included in Android’s May 2025 security update. The vulnerability affects devices with newer Arm Mali GPUs that use the Command Stream Frontend (CSF) architecture, such as Google’s Pixel 7, 8, and 9 series. I developed and tested the exploit on a Pixel 8 with kernel MTE enabled, and I believe it should work on the 7 and 9 as well with minor modifications. What follows is a deep dive into how CSF queues work, the steps I used to exploit this bug, and how it ultimately bypasses MTE protections to achieve kernel code execution. How CSF queues work—and how they become dangerous Arm Mali GPUs with the CSF feature communicate with userland applications through command queues, implemented in the driver as kbase_queue objects. The queues are created by using the KBASE_IOCTL_CS_QUEUE_REGISTER ioctl. To use the kbase_queue that is created, it first has to be bound to a kbase_queue_group, which is created with the KBASE_IOCTL_CS_QUEUE_GROUP_CREATE ioctl. A kbase_queue can be bound to a kbase_queue_group with the KBASE_IOCTL_CS_QUEUE_BIND ioctl. When binding a kbase_queue to a kbase_queue_group, a handle is created from get_user_pages_mmap_handle and returned to the user application. int kbase_csf_queue_bind(struct kbase_context *kctx, union kbase_ioctl_cs_queue_bind *bind) { … group = find_queue_group(kctx, bind->in.group_handle); queue = find_queue(kctx, bind->in.buffer_gpu_addr); … ret = get_user_pages_mmap_handle(kctx, queue); if (ret) goto out; bind->out.mmap_handle = queue->handle; group->bound_queues[bind->in.csi_index] = queue; queue->group = group; queue->group_priority = group->priority; queue->csi_index = (s8)bind->in.csi_index; queue->bind_state = KBASE_CSF_QUEUE_BIND_IN_PROGRESS; out: rt_mutex_unlock(&kctx->csf.lock); return ret; } In addition, mutual references are stored between the kbase_queue_group and the queue. Note that when the call finishes, queue->bind_state is set to KBASE_CSF_QUEUE_BIND_IN_PROGRESS, indicating that the binding is not completed. To complete the binding, the user application must call mmap with the handle returned from the ioctl as the file offset. This mmap call is handled by kbase_csf_cpu_mmap_user_io_pages, which allocates GPU memory via kbase_csf_alloc_command_stream_user_pages and maps it to user space. int kbase_csf_alloc_command_stream_user_pages(struct kbase_context *kctx, struct kbase_queue *queue) { struct kbase_device *kbdev = kctx->kbdev; int ret; lockdep_assert_held(&kctx->csf.lock); ret = kbase_mem_pool_alloc_pages(&kctx->mem_pools.small[KBASE_MEM_GROUP_CSF_IO], KBASEP_NUM_CS_USER_IO_PAGES, queue->phys, false, //<—— 1. kctx->task); … ret = kernel_map_user_io_pages(kctx, queue); … get_queue(queue); queue->bind_state = KBASE_CSF_QUEUE_BOUND; mutex_unlock(&kbdev->csf.reg_lock); return 0; … } In 1. in the above snippet, kbase_mem_pool_alloc_pages is called to allocate memory pages from the GPU memory pool, whose addresses are then stored in the queue->phys field. These pages are then mapped to user space and the bind_state of the queue is set to KBASE_CSF_QUEUE_BOUND. These pages are only freed when the mmapped area is unmapped from the user space. In that case, kbase_csf_free_command_stream_user_pages is called to free the pages via kbase_mem_pool_free_pages. void kbase_csf_free_command_stream_user_pages(struct kbase_context *kctx, struct kbase_queue *queue) { kernel_unmap_user_io_pages(kctx, queue); kbase_mem_pool_free_pages(&kctx->mem_pools.small[KBASE_MEM_GROUP_CSF_IO], KBASEP_NUM_CS_USER_IO_PAGES, queue->phys, true, false); … } This frees the pages stored in queue->phys, and because this only happens when the pages are unmapped from user space, it prevents the pages from being accessed after they are freed. An exploit idea The interesting part begins when we ask: what happens if we can modify queue->phys after mapping them into user space. For example, if I can trigger kbase_csf_alloc_command_user_pages again to overwrite new pages to queue->phys, and map them to user space and then unmap the previously mapped region, kbase_csf_free_command_stream_user_pages will be called to free the pages in queue->phys. However, because queue->phys is now overwritten by the newly allocated pages, I ended up in a situation where I free the new pages while unmapping an old region: In the above figure, the right columns are mappings in the user space, green rectangles are mapped, while gray ones are unmapped. The left column are backing pages stored in queue->phys. The new queue->phys are pages that are currently stored in queue->phys, while old queue->phys are pages that are stored previously but are replaced by the new ones. Green indicates that the pages are alive, while red indicates that they are freed. After overwriting queue->phys and unmapping the old region, the new queue->phys are freed instead, while still mapped to the new user region. This means that user space will have access to the freed new queue->phys pages. This then gives me a page use-after-free vulnerability. The vulnerability So let’s take a look at how to achieve this situation. The first obvious thing to try is to see if I can bind a kbase_queue multiple times using the KBASE_IOCTL_CS_QUEUE_BIND ioctl. This, however, is not possible because the queue->group field is checked before binding: int kbase_csf_queue_bind(struct kbase_context *kctx, union kbase_ioctl_cs_queue_bind *bind) { … if (queue->group || group->bound_queues[bind->in.csi_index]) goto out; … } After a kbase_queue is bound, its queue->group is set to the kbase_queue_group that it binds to, which prevents the kbase_queue from binding again. Moreover, once a kbase_queue is bound, it cannot be unbound via any ioctl. It can be terminated with KBASE_IOCTL_CS_QUEUE_TERMINATE, but that will also delete the kbase_queue. So if rebinding from the queue is not possible, what about trying to unbind from a kbase_queue_group? For example, what happens if a kbase_queue_group gets terminated with the KBASE_IOCTL_CS_QUEUE_GROUP_TERMINATE ioctl? When a kbase_queue_group terminates, as part of the clean up process, it calls kbase_csf_term_descheduled_queue_group to unbind queues that it bound to: void kbase_csf_term_descheduled_queue_group(struct kbase_queue_group *group) { … for (i = 0; i < max_streams; i++) { struct kbase_queue *queue = group->bound_queues[i]; /* The group is already being evicted from the scheduler */ if (queue) unbind_stopped_queue(kctx, queue);

From AI breakthroughs to industry transformation, see how leaders like CoreWeave, JPMorganChase, USAA and Lowe’s are reshaping the future.   ​  ​From AI breakthroughs to industry transformation, see how leaders like CoreWeave, JPMorganChase, USAA and Lowe’s are reshaping the future. Customer Blog | Dell