Arch Linux has disabled new account registrations on the Arch User Repository (AUR) as they work to contain a malware campaign that swept through the community package repository last week.
The AUR is where Arch users look in for software that has not made it into the official repositories yet. It is community-run and unsupported, meaning packages are user-submitted with no safety guarantee from the Arch team.
Over 1,500 packages were hit in the first wave alone, and two more waves followed shortly after developers thought they had it cleaned up.
What happened?
On June 11, Arch developer Jonathan Grotelüschen opened a dedicated thread on aur-general asking the community to report compromised packages. A formal news post from Campbell Jones followed the next day, acknowledging "a high volume of malicious package adoptions and updates" in the AUR.
Community member a821 traced the initial packages to a malicious npm package called js-digest, which was embedded in post-install scripts. Shortly after, koraynilay ran a broader search against GitHub's AUR mirror using js-digest as the marker and found around 850+ packages that were affected, noting the count was already dropping as devs removed them.
By the end of the day, Jonathan posted that they had deleted all known malicious commits, linking to a document that listed over 1,500 packages.
That was not the end of it. On June 13, a821 flagged a new batch using a different technique. This time, the word "bun" was split across string literals as 'b''u''n' to slip past detection.
Around 50 packages were caught in this wave, spanning browser packages, a cluster of nodejs-* entries, plasma6-applets-fancytasks, a NeoVim plugin, and LibreWolf extensions.
A day later, Nicolas Boichat spotted another batch, this one more heavily obfuscated. He caught it using a locally-run Gemma E2B model, with htbrowser-bin among the packages he flagged.
What can you do?
Fast-forward to now, Leonidas Spyropoulos of the Arch Linux team announced on June 15 that new AUR account registrations had been disabled as they are busy cleaning up the AUR.
Another thing to keep in mind is that the core Arch Linux repositories remain unaffected, with the malicious commits limited to the AUR.
If you suspect malicious packages might've made it onto your system or you just want to be cautious, then the Arch team suggests reviewing every PKGBUILD and install script change before updating, particularly right now.
And if anything suspicious does show up, they encourage users to flag it via the aur-general mailing list by replying to the AUR REPORT THREAD (also linked earlier).
CachyOS is a relatively new distribution that has gained mass popularity due to its cutting-edge software and features that focus on performance optimization, finding a very specific niche easily.
In its recent updates, CachyOS has changed the default package management system to the Rust-based Shelly from Octopi, so obviously, I was bound to check it out.
What does Shelly offer?
To start with, Shelly is a one stop solution to manage packages not only from CachyOS's own repositories, but also AUR, AppImage and Flathub, all at the same place. It also provides quite a nifty clean look that just makes sense, both of which give it a clear edge over Octopi already, which can manage the default repositories and AUR only, and looks a little dated.
Interface
The home page shows recent activity, a package dashboard which displays the number of packages installed through AUR and Flatpak, and the absolute total number of packages on the system. It also shows the percentage of packages which are totally updated, with the available updates on the right side.
There's a search bar on top which will search through the distribution's repositories, AUR and Flathub all at the same time. If a package is available from multiple sources, Shelly lists them in order of preference, first the distribution's repositories, then AUR and finally Flathub.
All the different possible sources are tabbed on the left of the window, which means you can manage the packages from all different sources separately and seamlessly.
🚧
On CachyOS with GNOME even when the system is on dark mode, the app doesn't seem to be. There's no internal option to change it, either. This is what I noticed in my testing.
Settings
The settings keep things to a minimal. There are toggle switches for AUR, Flatpak and AppImage management, as well as for the tray icon. These settings are confirmed on the first start of the application.
You can move around the left menu to the top, again with a toggle switch. In the advanced settings, you can enable the "No Confirm" button to slide through the confirmation for the installation, uninstallation or updating of any package. You can also limit the number of parallel downloads, with the default being 10. There's an interesting option called "Purify Packages" which gets rid of any corrupt packages on the system.
How well does it work?
In most aspects, Shelly works really well. Package management from the distribution's repositories, AUR and Flathub are virtually error-free. Search works really, and so does the installation and uninstallation.
AppImage is a little patchy, though. I tried to install balenaEtcher's AppImage and Raspberry Pi's Imager, the former was not installed and embedded into the system menu, but the latter was.
How does it compare to Pamac and Octopi?
With the first look itself, the interface, Shelly looks like it is several steps ahead from both Pamac and Octopi. It looks like it belongs on a modern system, is sleek and intuitively accessible unlike the other two.
As for the functionality, Pamac and Octopi work reliably well at what they do. Shelly works fairly well, too, while providing more options at the same time, with some aspects being a little troubling, perhaps.
Final Thoughts
The change to Shelly as the default package manager is very promising, it seems to suit CachyOS much better than Octopi in my opinion. It offers a lot of new, interesting features, and delivers on them fairly well. Let us know what you think about this change in the comments. Cheers!
Pocket-sized computer tools are the definition of cool, recruiting many people over to the developer side of things, including your humble writer.
A project like Flipper One, which is intended to be a device that features the full mainline Linux kernel in a small package with a full range of connectivity, not to be used as a full-fledged computer (not all the time, at least) but rather a cyberdeck that can be used for development, experimentation and last but not the least, pentesting, is such a dream come true.
With its radical philosophy of complete openness, both in terms of hardware and software, and the ability to do whatever is possible with the hardware on board, it is a project that would have sent my 14 year-old self into a hyperventilating fit. So what exactly can it do? And how do you fit into the picture? That's exactly what we will tell you today.
Flipper One at a glance
Flipper One hasn't been released yet, but there are some ambitious features that have been planned for it. While Flipper Zero was more of an offline access tool, with emphasis on NFC, RFID infrared, UART and so on, Flipper One is intended to be a network connected Linux system. So obviously, we start with:
Connectivity
Flipper One self proclaims as a "Swiss Army knife for IP networks across all OSI layers", which include:
5G modem
Wi-Fi 6E
Two Gigabit Ethernet ports
Upto 5 Gbps wired connectivity over USB-C Ethernet
All this results in Flipper One being usable as anything from a multi-hotspot bridge, an inline Ethernet sniffer, a VPN gateway, or a USB Wi-Fi/Ethernet adapter for another device.
Hardware
The hardware is a particularly interesting aspect of Flipper One, as it is has a completely custom, unique build. We will describe the technical aspects later, focusing first on the build of the device. It has a small monochrome 256x144px display, designed to show all necessary information from the custom software onboard, a touchpad, a 5-button D-pad, a back button, an app-switching button, and 5 buttons used for further navigation to power, edit, run or escape programs, and to view other options. Oh, there's a push-to-talk button as well for a pre-installed offline AI assistant. Fancy, eh?
As for the ports, it has the following:
Two USB-C, one multipurpose, one only for power
USB-A
HDMI
Two Ethernet
3.5mm audio jack
MicroSD card slot
Nano SIM card slot
M.2 expansion module
Now finally onto the hardware on board:
A main Rockchip RK3576 chip
A secondary low-powered Raspberry Pi RP2350B MCU
8 GB RAM
64 GB internal storage
7000 mAh battery (tentatively)
As an ARM based device, the processing is comparable to the power offered by a Raspberry Pi 5, handling basic operations rather well.
Software
Here's where things get really interesting. The Flipper team intends Flipper One to be able to support the mainline Linux kernel, and has gone to the massive undertaking of having absolutely no proprietary binary blobs in any of their software. This includes the operating systems as well as the firmware. They're building FlipperOS, a layer on top of Debian, which you can do anything to.
There's also FlipperCTL, which has been created as a response to full-fledged Linux operating systems being awkward and uncomfortable on small screens. It is, therefore, a UI designed for a screen as small as that, controlled by a D-pad and a few buttons. The idea then, is to wrap utilities like ping, nmap and traceroute into this FlipperCTL interface.
Abilities
Apart from the use cases already mentioned, like as a pentesting tool or a networking agent, it can also be used as a survival desktop or a thin client, using the USB-C port to connect to a monitor. The exact details of the OS haven't been decided yet, but something slick like KDE Plasma with something resourceful like Kali Linux to suit all pentesting needs is the way Flipper is planning to go. It is also being planned as a hacker's TV media box, to be used as a media platform using Kodi or something similar. This would turn any HDMI input taking monitor into your personal media box, a luxury that is quite underrated in situations like a strange hotel room.
Not to forget, the presence of both a CPU and an MCU is by design, as the intention is to have the device functioning at low power, with the LCD and buttons, even without the main CPU running. Even when Linux is off, the device can run simple programs off of the MCU.
So what can you do?
But where do you come in? Well, the entire device is still under development and needs contributions from anyone who can provide it to be completed. Flipper has made a Developer Portal for Flipper One, where the entire development process is to be made open. That means half-baked task tracking, documentation, internal discussions, debates and everything.
You don't need to be a software developer, strictly, you could be a designer, just work on documentation, 3D models, so on and so forth. So, what all can you contribute to?
Hardware: PCBs, antennae, chips, processors, connectors and everything in between (literally).
Mechanics: Designing, enclosure, plastic/metal parts, mounting parts and so on.
Linux: Firmware for the RP2350 microcontroller, relating to practically every component that the software will interact with.
Interface: UI/UX design, visuals and graphics.
Docs: Documentation, wikis, guides, progress made on the portal itself.
Testing: This one you can find out for yourself.
Conclusion
Flipper's team has taken up a humongous task, trying to make this entire project totally open, the hardware design plans, the software blobs barring no small proprietary bits, and has shown courage admitting the need for help finishing the project. The Developer Portal is a great approach, inviting all the people from across the globe to contribute in any way that they possibly can. And with a beautiful passion project such as this? I'm expecting they absolutely will want to. I urge the readers to do that as well, if you have some skill and time to contribute.
This kind of project instills hope in user-level innovation after long bouts of polished, corporate products and we're all here for it. Let us know what you think of the device in the comments. Cheers!
When KDE announced that Plasma 6.8 would be dropping the X11 session entirely, not everyone was happy about it. Wayland has been the default on most major distributions for a while now, but there's still a significant chunk of users with reasons to stay on X11.
One such case is of a group of developers who took the code that KDE itself is walking away from and started building an X11-first desktop around it. That project is SonicDE.
Their goal is to maintain and actively develop the parts of KDE Plasma's X11 stack that are being left behind, while cutting out Wayland dependencies and pushing X11 support forward rather than just holding the line.
The work can be traced back to a KWin/X11 patchset called kwin-x11-improved, which was later merged with the full KWin/X11 source by Joseph Crowell in September 2025 under the name "KDE-Lite," and rebranded as SonicDE by December.
SonicDE: X11 Plasma Restored
Image sourced from Joseph Crowell, one of the contributing developers of SonicDE.
It is a collection of KDE Plasma and KDE Frameworks component forks, each rebuilt with X11 as the focus. The project now spans 40 repositories on GitHub, with the team working through the KDE stack and stripping out what's not needed.
The most prominent of those is sonic-win, a fork of KWin/X11 that handles window management and compositing. It's the most active repository in the project and the one where most of the foundational work is happening.
Alongside it are sonic-workspace, derived from plasma-workspace, and sonic-desktop-interface, forked from plasma-desktop. The former provides the core environment components, while the latter handles the desktop shell. Together with sonic-win, these three form the backbone of what SonicDE actually is as a desktop.
The project covers a lot of ground beyond the core trio of components.
For networking, sonic-network-manager is there; sonic-audio-applet-pulse covers PulseAudio volume management; sonic-screenlocker takes care of screen locking; sonic-screen manages display configuration; and login sessions are handled by sonic-login-manager.
From left to right we have SonicDE on EndeavourOS, Artix Linux, and Vendefoul Wolf.
SonicDE also ships a Silver theme, forked from the Klassy theming utility for Plasma, alongside a matching silver-sddm login screen. Together, they give the desktop a consistent look rather than just resembling a stripped-down Plasma install.
What users actually get is an X11 desktop that behaves the way longtime KDE users expect, while still inheriting improvements from the upstream Plasma components it forks from.
And since SonicDE is being built to be init system agnostic from the start, it isn't locked to systemd. BSD support is one of the stated goals too, so the project is thinking well beyond Linux users.
Availability of this?
It is already packaged for Arch Linux-based distributions, with additional builds available for Debian, Devuan, Artix Linux, and Vendefoul Wolf. The official website has the links for the packages for those distros.
Also good to know is that the developers are already packaging SonicDE for Gentoo, NixOS, OpenMandriva, and FreeBSD, so keep an eye out on their socials and GitHub page for updates.
Following Linux 7.0 in April and the stable point releases since, Linux 7.1 is now available as a major feature release in the 7.x series.
You get a bunch of upgrades with this, ranging from a new NTFS driver that landed after four years of development all the way to a bugfix for a long-standing audio issue on the Steam Deck OLED.
And, if you remember our reporting from a few months ago, then this release also formally drops i486 CPU support from the kernel build system.
What's new in this release?
Intel's Flexible Return and Event Delivery (FRED) is now enabled by default in Linux, having previously required a manual fred=on boot flag. The switch was held back until publicly available hardware could be properly evaluated, and the code has since been tested thoroughly enough to flip from opt-in to opt-out.
Phoronix reports that people running Intel Core Ultra Series 3 "Panther Lake" should see real gains here, particularly on I/O-heavy workloads like databases, networking applications, and audio processing.
The crypto subsystem picks up some Intel QAT additions too. For QAT Gen4 and Gen5 hardware, basic Zstd compression offload is now available. The Gen6 version, intended for the Diamond Rapids platform, gets a native Zstd implementation covering both compression and decompression.
The amd-pstate driver gains CPPC Performance Priority, Dynamic EPP (Energy Performance Preference), and Raw EPP with this release for more granular control over power and performance on modern AMD Ryzen and EPYC hardware.
Similarly, the AMDgpu driver sees several changes this cycle, including SMU 15.0.8 IP support, DCN 4.2 display updates, a new DebugFS interface for monitoring 64-bit PCIe registers, and a fix for a GPU page fault triggering on non-4K page size kernel builds.
And, after four years of work, a new NTFS driver has landed in the mainline kernel. We covered its development last December, when it was still working its way toward integration.
Linus Torvalds called the merge the "ntfs resurrection," though he briefly un-pulled the code over a Git structure issue before accepting a revised pull request. The new driver is available via the NTFS_FS Kconfig switch, and NTFS3 is still around for now.
Finally, we have the newly introduced support for 12 new SoCs, including Qualcomm's Glymur, Mahua, Eliza, and IPQ5210, Axis ARTPEC-9, Microchip's LAN9691 and PIC64GX, Renesas RZ/G3L, NXP S32N79, Rockchip's RV1103B, and ARM's Zena and Corstone-1000-A320.
Should you install this?
📋
It is to get excited about a new kernel release, But compiling a new kernel or installing a new one is usually considered intermediate to expert zone. For a regular Linux user, it is better to wait for the distro to provide it, unless you have a compelling reason to get the new kernel early.
It depends. If something in this release addresses a gap you had with earlier kernels, it's worth the upgrade. You can download the tarball from the official website and get started installing it on something like Ubuntu.
For the rest of us, it depends on the distribution one is using. Not every distro will be providing this release upgrade. Rolling releases like Arch Linux and more frequently updated distros like Fedora and its derivatives will be picking this up soon.
Others on distros like Debian or Linux Mint likely won't see it on their computers.
On May 27, Adam Williamson of the Fedora QA team sent a message to contributor Nathan Giovannini, CC'ing the project's devel and test mailing lists so everyone could see what had been going on.
Adam had been combing through Nathan's Bugzilla history and found what he described as the work of "some kind of agentic AI system," operating unsupervised across both Fedora's bug tracker and several upstream projects.
Soon after, Nathan replied, saying his credentials had been compromised and that he had nothing to do with any of it.
The agent had been mass-reassigning Bugzilla reports to Nathan's account, despite him not being the maintainer for any of the affected packages. In Fedora's Bugzilla instance, the assignee is supposed to be whoever can actually resolve the bug downstream, typically the package maintainer.
It had also been prematurely closing bugs, where the correct protocol was to mark a bug as POST when a fix was proposed upstream but wasn't pushed downstream. The agent was just closing them outright after submitting or merging an upstream patch.
Then there were the NOTABUG closures. The agent had been shutting bugs in components it had no ownership over, with comments Adam identified as clearly LLM-generated. Some of those comments just restated what the original reporter had already written. Others sounded plausible but were wrong.
The fourth problem was the most serious. The agent submitted an incorrect fix to the Anaconda installer project, and when a maintainer pushed back, it kept firing back LLM-generated responses until the maintainer gave in and merged it.
The Anaconda team reverted the PR, but two related pull requests had already shipped in Anaconda 45.5.
A supply chain problem?
This is not a particularly sophisticated attack.
A contributor account gets compromised, an AI agent runs through it, and bad code ends up in a release before anyone notices. The damage in this case was caught and cleaned up, but the scenario itself is not hard to replicate.
Fedora approved a policy on AI-assisted contributions last year, placing full accountability on the human contributor and requiring transparency when AI tools are involved. Submitting unreviewed, low-quality machine-generated content is explicitly called out as unacceptable.
What played out here was the policy's failure conditions, except it was routed through a stolen account rather than a contributor acting in bad faith, so the policy had no way to apply.
Open source software sits underneath nearly all modern enterprise infrastructure, which is what makes the supply chain angle worth taking very seriously.
IBM and Red Hat announced Project Lightwell in late May as a $5 billion effort to secure open source supply chains using AI tooling and a team of over 20,000 engineers. It targets vulnerability remediation across upstream and enterprise environments, from language ecosystems to AI frameworks.
However, it does not address the specific problem of agentic AI operating through hijacked contributor accounts, but it reflects where the industry is moving towards as AI keeps accelerating both the discovery and exploitation of vulnerabilities.
Fedora's 2FA problem isn't going away
The incident kicked off a debate on the devel list that has apparently been sitting unresolved since the XZ backdoor in 2024.
Daniel Berrangé, a Red Hat engineer and long-time Fedora contributor, pointed out that mandatory 2FA had come up after that incident; the only outcome was a soft recommendation that provenpackagers should have it enabled, and nothing has moved since.
Fabio Valentini raised a separate issue saying that a lot of this activity happened on Bugzilla, which uses its own account system and may not support 2FA at all. Daniel acknowledged that but said it was not a reason to avoid mandating it for the Fedora Accounts (FAS), and noted Bugzilla may become less relevant if Fedora eventually moves to the issue tracker on Fedora Forge.
Michael Catanzaro, a GNOME developer, said he uses 2FA everywhere except Fedora, even though his Fedora account is among his most sensitive. The sticking point in his case is that Kerberos ticket renewal isn't working properly with 2FA in GNOME Online Accounts.
In the end, seeing that a compromised account got bad code into their repos, the Fedora folks ought to step up their efforts when it comes to mandating 2FA for contributors whose work affects many users.
If you have been keeping an eye on the display server situation on Linux, you know where things are headed. Wayland is taking over as distros are dropping X11 sessions one by one.
So naturally, someone went ahead and built a brand new X11 server from scratch. Developer Jos Dehaes recently went public with yserver, a new MIT-licensed X11 display server written entirely in Rust.
Now, this will either impress you or make you shout "Clanker!" but this project was built with significant help from Claude Code, Anthropic's AI coding agent. The repo has both a CLAUDE.md and an AGENTS.md file in plain sight, making this a proper vibe-coded project.
What is it?
Well, yserver isn't aiming to clone X.Org, rather it is meant to be a practical X11 server for modern Linux that focuses on what real desktop environments and applications actually need today.
Everything that has accumulated over decades and serves no purpose in today's computing environment has been dropped. That includes the DDX driver ABI, multiple X11 screen support, non-TrueColor legacy visuals, indirect GLX, and endian-swapped clients.
Under the hood, yserver drives hardware directly through DRM/KMS and Vulkan, skipping the usual middleware layers that sit between the display server and the GPU. This means a more direct path to the hardware with fewer moving parts sitting in the middle.
According to the project's documentation, yserver uses libseat for seat management, which ensures it can run without root and the core is deliberately single-threaded, resulting in predictable protocol behavior.
What can it do?
0:00
/0:10
Compiz running under yserver. Video courtesy of Jos Dehaes.
Currently, yserver can already boot into MATE, Xfce, and Cinnamon sessions, and it has also been tested with window managers like FVWM3, e16, and Window Maker. FreeBSD support is on the roadmap, but work on it has not started yet.
Hardware coverage is wider than you might expect. In testing, Jos has covered AMD Ryzen and Radeon setups, Intel Kaby Lake iGPU, NVIDIA with the proprietary driver, Snapdragon X1, and Apple M1 and M2 on Asahi Linux.
These were all tested on MATE, Xfce, and Cinnamon configurations, btw.
The obvious question
Major players in the Linux space like Ubuntu dropped the X11 session in 25.10, Fedora has done away with X11 on its flagship Workstation desktop edition, and KDE has already announced Plasma 6.8 will drop X11 support entirely.
So who is yserver for, exactly? Well, there is still a distinct group of users stuck on X11, whether because of legacy desktop environments, specific hardware setups, or workflows that just have not made the jump yet.
And the project itself is very early. There is one primary contributor, and the security model is incomplete, with the design documentation clearly stating that clients can currently read other clients' windows and global input.
Heck, even the name is a placeholder. 😅
So, yserver won't be replacing Wayland or X11 on your computer anytime soon, but it is a nice project to know about, and it also shows us how prevalent vibe coding has become, whether you like it or not.
