Debian's release team has made reproducible builds a hard requirement for the Debian 14 "Forky" cycle. Since May 9, the project's migration software has blocked any package failing a reproducibility check from entering testing.
If a package already in testing breaks reproducibility later, it gets blocked too. Paul Gevers from the release team shared the news on the debian-devel-announce mailing list over the weekend.
What are reproducible builds?
Not rocket science, for starters. When a package is built reproducibly, compiling the same source code in the same environment always produces the exact same binary every single time.
That might sound like it should just be how things work by default, but in practice it often isn't. 😅
The culprits are usually mundane. A timestamp baked into the binary, a build ID generated on the fly, files written to the archive in whatever order the filesystem felt like. None of it changes what the software actually does, but it means two builds of the same source won't match.
That gap has security implications. If binaries don't need to match their source, there's room for something to be slipped in at the build stage without touching the code at all.
Reproducible builds cut that off. Anyone can independently rebuild a package and verify the result against what Debian actually ships.
Debian has been working on this alongside the Reproducible Builds project (linked earlier) for years, steadily pushing reproducibility rates across the archive. The setup at reproduce.debian.net has been running continuous rebuilds and tracking results throughout the forky cycle.
What does this mean?
Tracking reproducibility rates for 'all' on Debian's forky branch.
Currently, 98.29% of architecture-independent packages in Forky reproduce successfully, with 23,731 passing and 414 still flagged as 'bad' for not being reproducible. That 414 figure will only get smaller as the block on non-reproducible migrations takes effect going forward.
For you, the user, this translates into a stronger guarantee that what you install from Debian "Forky" actually matches the published source code. No wondering whether something crept in between the source and the binary you are running.
And that verification isn't limited to Debian's own infrastructure either. Independent rebuilders can check it too, which is kind of the whole point.
Maintainers, meanwhile, have been reminded that cleanly migrating a package is the uploader's responsibility. If a package is blocked because of autopkgtest regressions in reverse dependencies, the expectation is that the uploader files the appropriate release-critical bugs.
Sasha Levin, NVIDIA engineer and co-maintainer of the stable and long-term support kernel trees, has proposed a new patch that adds a mechanism called killswitch to the Linux kernel.
It's pitched as a way for system administrators to disable a vulnerable kernel function on a running system, and the timing of it isn't a coincidence either. The patch follows the rising risk of Linux Privilege Escalation (LPE) vulnerabilities like Copy Fail and Dirty Frag.
What is it?
The Linux kernel is built out of many thousands of small functions, each handling a specific job, like processing a network packet, opening a file, or talking to a USB device. When a security flaw shows up in one of these functions, the proper fix is to patch the code and ship a new kernel.
What killswitch entails is a more "must exterminate" approach, where the admin gives the kernel a function name and a return value. From that point on, the function still gets called by whatever was calling it, but it just hands back that value and exits. The actual code inside never runs.
In practice, that means a single line at the terminal:
After this, every program trying to send data through AF_ALG (the kernel cryptography interface Copy Fail also exploited) gets an error back. Whatever bug sat in af_alg_sendmsg is now unreachable because the function never actually executes.
The effect kicks in across every CPU core immediately, and it lasts until the admin disengages it or the system reboots. Engaging anything requires root privileges.
There's also a boot parameter version killswitch=fn1=val,fn2=val,..., for cases where an operator needs to apply the mitigation across a whole fleet of machines through the bootloader.
Sasha points at AF_ALG, ksmbd, nftables, vsock, and ax25 as good candidates for this patch, saying that:
For most users, the cost of "this socket family stops working for the day" is much smaller than the cost of running a known vulnerable kernel until the fix land.
Any risks?
The biggest catch is that killswitch doesn't fix anything. It just stops the function from running. Anything in userspace that depends on that function stops working too, for as long as the killswitch stays engaged.
Engaging it also taints the kernel, which is its way of marking that the running code isn't pure upstream Linux anymore. A new flag (H, bit 20) gets set the moment any killswitch is active, and it persists across disengage all the way to the next reboot.
Any crash that happens afterward carries an H in its banner, which acts as a signal to the Linux maintainers triaging the bug that the image was modified. The patch also dedicates a whole section called "Choosing the right target," warning operators not to pick the wrong function.
Someone on Reddit has described this as "a security feature that may be worse than the vulnerability," and many people agree with that sentiment.
AI was involved
There's one more thing worth flagging. At the bottom of the patch, just above the diff, sits an Assisted-by: Claude:claude-opus-4-7 line, marking it as one Sasha put together with help from Anthropic's AI assistant.
That isn't a one-off. The Assisted-by tag itself comes from a kernel policy, which Sasha had a hand in shaping. It lays out how AI-assisted contributions should be attributed in commit messages, alongside configuration files for tools like Claude, Copilot, and Cursor.
It also fits a wider pattern. Greg Kroah-Hartman has been running his own AI fuzzer against the kernel, and the first bugs it surfaced were in ksmbd, which is one of the subsystems Sasha specifically called out as a killswitch candidate.
As things stand, killswitch is just a patch on the Linux Kernel Mailing List, not merged into mainline, and not in any released kernel or distro. Whether it lands and in what form depends on the upcoming review cycle.
In recent times, Huawei has been China's best-standing answer to Apple's monopoly over the personal tech market. Smartphones, laptops, tablets, they do it all and they do it at a level on-par with the best companies currently working.
This is not a dynamic that has been around forever, but a more recent shift as China has been seeing a huge surge in the usage of domestic software, such as operating systems and databases. The credit is given to a steady improvement in the smoothness and ease of usage of these technologies.
Yu Chengdong, Huawei’s Executive Director reported that as of the end of March 2026, HarmonyOS has been on more than 55 million devices, adding 23 million in just under six months, which is a massive number for sure. Market giants who wish to maintain their monopoly have every reason to be worried about the competition.
What makes it a popular choice?
The reason for such popularity and wide usage of HarmonyOS can be seen through the improvements it has made to its operating system in its latest release, HarmonyOS 6, such as:
Fluid animations that make the phone feel smoother, such as bringing the lighting and glass-like UI elements.
Measurable performance improvement made by Ark engine (the APIs that handle multimedia and graphics, especially gaming and video), and giving a better battery life.
Latest AI assistance tools, including scheduling and camera features that configure depth and focus in one touch.
AI-driven StarShield Security Architecture to improve security with added focus on anti-scam features and privacy improvements.
Wider native adaptations of third-party apps.
Huawei's growing range of affordable and feature rich mobile devices
These are only some of the elements that HarmonyOS and Huawei owe their success to. But what does it mean for the open-source community?
How does it impact FOSS communities?
HarmonyOS is based on OpenHarmony, an open source mobile operating system base that is similar to Android's AOSP but independent from it. This mass adoption of HarmonyOS encourages more contributions to the OpenHarmony kernel, showing growth in related projects as well, such as EulerOS.
The catch, however, is that HarmonyOS still functions on a lot of proprietary layers, including the aforementioned Ark compiler and the UI elements. Added to that, the Chinese documentation makes it inaccessible to a large chunk of the world population.
Some people are critical of rather unusual activities, such as Huawei spamming open source projects, urging them to use HarmonyOS. Critics see it as intrusive, while others find it acceptable as they're only using whatever means they can to bring more apps and services into the fold of their OS.
A new challenger?
A new contender challenging the Apple/Google duopoly is actually a good news for the consumers, especially with more affordable devices, as it keeps all makers involved on their toes.
While this benchmark of 55 million devices indicates that there is scope beyond iOS and Android in the mobile operating system domains. Of course, this success is tightly coupled to the awesome Huawei hardware.
Let me know what your thoughts are on Huawei's milestone in the comments. Cheers!
Backing up photos and videos is something most people think about only after losing something they can't get back. Local storage is still the most secure option, as long as the files are encrypted and access to the storage medium is under your control.
The catch is that local storage doesn't help much when you need to pull up a file on the go. Being away from home and needing quick access to a specific photo or video is the kind of situation it fails to handle.
Services from big tech players like Google Photos and Microsoft OneDrive fill that gap well enough, and for a while, OneDrive was my go-to.
But, seeing how aggressively Microsoft has pushed its Copilot offering across its product lineup, I thought to myself, 'it won't be long before some new Copilot-powered feature is rolled out that messes around with images and videos.'
That's why I went searching for new options. Initially, Proton Drive (partner link) looked like an option, but I wanted something outside the Proton ecosystem, so I ended up on Ente Photos.
What is Ente Photos?
Btw, that's Ducky, Ente's mascot.
It is an open source, end-to-end encrypted photo storage service that was started in 2020. The goal, as the Ente team puts it, is to help people preserve their memories with privacy without relying on services that treat your data as a resource to be mined.
Beyond Photos, they also offer Auth, a cross-platform two-factor authentication app that backs up your 2FA secrets in an encrypted format, and Locker, which is aimed at storing sensitive documents and files securely.
We got the chance to speak with Vishnu Mohandas, the founder of Ente, back in 2024, where he told us about his vision for building a privacy-respecting alternative to the likes of Google Photos and iCloud Photos.
Quite some time has passed since, and I finally got around to trying it out and, in the process, moved away from yet another Big Tech service.
I made the switch
Before I could do anything, I had to get my files from OneDrive, and boy does Microsoft keep things painfully slow there. Downloading files from the web version of OneDrive meant it would zip the folders first, then begin the download process.
That wouldn't have worked for me, as I had over 200 GB of files to download.
To fix the painfully slow downloads, I had to install the OneDrive client on Windows 11 and configure it to keep a local copy of the files on my device. This got me my files much faster than the website, and the download was complete in a few hours.
These were a mix of different file types, most of which ended up on an external hard disk, with the photos and videos kept separate for the move to Ente Photos.
Moving on to the migration, I already had an Ente account, so I logged in and picked the 200 GB paid plan, which cost me ₹4788 annually. Keep in mind that Ente charges in USD/EUR globally, so what you end up paying in your local currency will depend on conversion rates and your payment method.
There is also a free tier that offers 10 GB of storage permanently, which is a good way to test things out before committing.
From left: You will find the Ente Photos INR prices, the login screen, and the Linux packages.
After everything was set, I started exploring the Linux client on my Fedora Workstation daily driver.
The sidebar menu showed me how much storage quota I had (200 GB ofc), along with buttons to access uncategorized content, hidden content, the trash, my account, any watched folders, a tool to free up space, and the preferences menu.
The sidebar menu on the Ente Photos Linux client.
The preferences menu had options to change the interface language, set the theme between System, Light, and Dark, and enable the Machine Learning feature, which lets Ente Photos run on-device processing for face recognition and other ML-powered features.
There were also options to make the client run at startup, point it to a custom domain for self-hosted setups, and configure the app lock.
I then began the file uploads, which took a very long time. There were 21,000+ items to be uploaded, and that happened mostly because Ente Photos encrypted the files on-device before sending them to the servers, which adds overhead that services like OneDrive simply don't have to deal with.
It is the price you pay for actual end-to-end encryption, and honestly, a fair one. 🤷
The file upload flow on the Linux client of Ente Photos.
Though, I did miss the folder-based organization that OneDrive had. As a general-purpose cloud storage service, OneDrive lets you build out a full folder and subfolder hierarchy for any type of file, whereas Ente's offering focuses more on photos and videos.
It did ask me during the initial upload whether I wanted separate albums, but I mistakenly went with the single album option (as you see above).
The file upload progress tracking works well.
Tracking active uploads was working as expected. Ente Photos shows a dedicated interface element in the bottom-right corner that, when clicked, breaks down everything: currently uploading files, successful uploads, ignored uploads where matching files were already found, unsupported files, and failed uploads.
I could also select multiple images and videos to share them as a link with others, favorite them, fix the timestamps, edit the location, download them, archive them, hide them, or even delete them.
I used the download option, and it worked as expected, with a slightly slow processing time because I was connected to a VPN. Overall, the Linux client didn't disappoint, and doesn't feel like an afterthought. It feels like something that was built for the platform.
The mobile app
I then moved to testing the Android app for Ente Photos on an Android 16-powered smartphone, and the experience over there was on par with the OneDrive client. Or even better, I would say, as the interface didn't feel overwhelming or jampacked.
I just had to configure which folders I needed backed up, and Ente Photos did the rest. It just runs silently in the background, backing up as new content is added, and there's even an option to configure so that only new content is backed up, preventing any unnecessary clutter from ending up on your cloud storage.
There's also a private sharing option, which lets you generate end-to-end encrypted links to any album, which recipients can open without requiring an Ente account (if creating a public link).
You can also password-protect the link and set it to expire after a certain period of time.
The mobile app also has a handy search function (even the Linux client had that; I forgot to test it lol) and the machine learning features, which are disabled by default, so you are always in control of whether Ente runs any on-device processing on your photos.
As of writing this, the mobile app has been extremely reliable in my day-to-day use, and its memories feature is like the cherry on top, giving me a nice trip down memory lane every now and then.
But keep this in mind…
Ente Technologies, Inc. is incorporated in the United States, its servers are located in Europe, and its Indian operations run through a subsidiary registered in Bangalore. They operate in three different regions, with three different sets of rules to follow.
In practice, that means Ente can be compelled by authorities in any of those regions to hand over account metadata, things like your identity, billing information, and access logs.
Your files are a different matter entirely. End-to-end encryption (E2EE) means the files are encrypted on your device before they ever reach the servers, so not even Ente can read them.
For me, that is what the switch ultimately came down to.
It is getting harder for Linux distributions to stay neutral on AI. Between enterprise-grade solutions like RHEL AI and the steady rise of local inference tools, the pressure to take a position has been building for a while.
Canonical recently made theirs clear, moving Ubuntu toward a local-first AI approach built around open-weight models and open source inference tooling, keeping everything on-device rather than routing it through a cloud subscription.
The proposal came from contributor Gordon Messmer from the packaging team at the end of March, and the Fedora Council has since voted on it with a unanimous +6.
Currently, a lazy consensus period is the last thing standing before it is fully official, with Jef Spaleta, the Fedora Project Leader, acting as the Executive Sponsor (to keep things moving).
The goal here is to make AI development on Fedora less painful by introducing better tooling and packaging. It also aims to offer a smoother experience for users running AI applications and a dedicated space for developers to get their work in front of people who might actually use it.
Also worth knowing is that this initiative is not about adding AI tools to Fedora's existing lineup of Editions or system images. Moreover, none of the resulting images will come pre-configured to connect to remote AI services or monitor how you use your system.
On the technical side, the proposal calls for building an LTS kernel to provide a more stable foundation, alongside bundling user-friendly tools like Goose CLI and Podman Desktop to cover common AI backend workflows.
As for the images this initiative will deliver, there are three planned. The base image, targeting accelerated AI/ML workloads without any proprietary components, will be published as a Fedora Spin.
Two Fedora Remixes follow, one with CUDA runtime support and one with the full CUDA toolkit, the latter of which has some licensing issues that the project will have to tackle.
And before you ask, the developers are planning for a Fedora 45 release timeline for those, which is a few months away in October.
Why though?
Fedora has a habit of being first. Wayland as default, PipeWire, and Flatpak all landed in Fedora before they became the norm across the broader Linux ecosystem. Sitting out the AI wave entirely would be a strange departure from that track record, and probably not a wise one.
Jef, the project leader, has already laid out his rationale, arguing that AI-assisted development is already normalizing upstream. Fedora, he argues, is better off being in that conversation, pushing toward local-first and more ethical tooling, than watching from the sidelines while others set the direction.
However, not everyone is on board. Fernando F. Mancera, a long-time Fedora contributor, withdrew from the project entirely in response, writing "I do not think we can move this forward in a community way. The present situation in Fedora is clearly not for me."
There are many such disagreements in the thread, ranging from concerns about chasing an AI hype cycle to deeper objections around the NVIDIA/CUDA components and whether the community was brought along properly.
Where Fedora is headed is not that much of a stretch, as the Linux kernel already allows AI-assisted contributions, with an "Assisted-by" tag and clear human accountability as the guardrails. And Ubuntu's AI roadmap, as you already know, is moving in the same local-first direction.
But whether the project can pull this off cleanly while keeping community expectations and its own philosophy intact remains to be seen.
Only last week, we were talking about how LVFS, the firmware update service for Linux, had turned up the heat on vendors who didn't contribute their fair share.
To tackle that, the project has been going through a phased restrictions rollout that includes things like introducing fair-use download utilization graphs and removing detailed per-firmware analytics.
But that obviously wouldn't solve their lack of funding.
Luckily, two vendors have stepped up. Lenovo and Dell have both signed on as Premier sponsors for LVFS, each putting in $100,000 a year to help fund the project going forward.
Premier is the highest level of financial commitment any vendor can make to the project.
This update was announced yesterday, with the LVFS homepage already reflecting the update. Between the two of them, that's $200,000 a year going into a project that had been running almost entirely on the goodwill of the Linux Foundation and Red Hat.
Richard Hughes, the lone full-time developer at LVFS, wrapped up the announcement by saying:
With the huge industry support from Lenovo and Dell (and our existing sponsors of Framework, OSFF, and of course both the Linux Foundation and Red Hat) we can build this ecosystem stronger and higher than before; we can continue the great work we’ve done long into the future.
Where's everyone else?
This is how firmware upgrades are delivered to me on Fedora Workstation, thanks to LVFS.
It's not a coincidence that the first Premier sponsors are also two of the most Linux-invested OEMs in the industry. Lenovo, one of the largest PC vendors around, ships Ubuntu on laptops, desktops, and workstations worldwide and has over 700 Ubuntu-certified devices to its name.
These certified devices are the result of Canonical and the OEM's engineers actively collaborating to verify that the hardware runs Ubuntu reliably, covering things like drivers, firmware, and general day-to-day compatibility.
Brands that think Linux is some niche thing are ignorant at best and apathetic at worst. 🙂
The platform hasn't been that for a long time and the argument that Linux users don't represent a significant enough market to justify any investment stopped making sense years ago.
The vendors still treating LVFS like a free service they have no obligation to support should probably pay attention to what comes next. API access gets cut for non-Startup vendors in August. Automated upload limits follow in December.
It has not been a week since we came across Copy Fail, the exploit that took advantage of an old logic flaw to escalate a local user to root, giving them all kinds of harmful access over a system they shouldn't have.
A security researcher, Hyunwoo Kim (v4bel), has reported a new Linux kernel privilege escalation threat. This one is called Dirty Frag, and the disclosure of it has not gone as planned.
Hyunwoo had set a five-day embargo after submitting details to the linux-distros mailing list, but an unnamed third party published the exploit publicly the same day, and that was that.
A working exploit is now out in the open; most distros have no patch, and the algif_aead blacklist you may have applied for Copy Fail does nothing against this.
What is Dirty Frag?
Like Copy Fail, Dirty Frag modifies the in-memory copy of a system file without touching the version on disk. Every subsequent read of that file sees the corrupted copy, and nothing on the filesystem looks wrong.
Dirty Frag does this through two separate flaws. The first, xfrm-ESP Page-Cache Write (CVE-2026-43284), targets /usr/bin/su, replacing its in-memory copy with one that hands out a root shell.
The second, RxRPC Page-Cache Write(CVE-2026-43500), goes after /etc/passwd and empties the root password field. PAM accepts the blank entry and lets a root login through.
More importantly, they are chained because neither works on every system alone. The first needs a user namespace, which some Ubuntu AppArmor setups block. The second does not have that requirement, but the rxrpc.ko module it relies on is absent from most distros' default builds.
Ubuntu is one of the few that does ship it, though. Together, the two cover every major distro.
What can you do?
Most distros have nothing out yet, perhaps except AlmaLinux, which is one step ahead of the others with patched kernels already in its testing repository. For everyone else, the immediate option is blacklisting the three modules involved:
Doing so also clears the page cache, getting rid of any tampering that may have already happened. Hyunwoo also recommends updating the kernel and rebooting as soon as your distro has a patch out.
