Planet Debian Derivatives

Deepin: deepin 25.1.0 Released: AI-Powered, Smooth as Silk to the Core

sun, ruonan — 2026-04-10T05:21:32+00:00

Dear deepin Community: As an open-source operating system that shines in the global rankings on DistroWatch and is widely recognized by users worldwide, deepin has been continuously listening to your feedback since the release of deepin 25. We’ve been refining details, fixing issues, and introducing innovations. Today, we are excited to announce that the deepin 25.1.0 images are officially released! Release Highlights Major Evolution of UOS AI: The writing agent has been fully reconstructed, supporting outline-first generation and source tracing. A new system-level "Claw Mode" has been added, supporting automatic computer control via natural language commands. The Skills Center is ...Read more

Deepin: deepin 25.1.0 Release Note

xiaofei — 2026-04-10T04:53:34+00:00

As an open-source operating system that shines in the global rankings on DistroWatch and is widely recognized by users worldwide, deepin has been continuously listening to your feedback since the release of deepin 25. We’ve been refining details, fixing issues, and introducing innovations. Today, we are excited to announce that the deepin 25.1.0 images are officially released! I. Major Updates UOS AI Evolution This update deeply empowers productivity, bringing a system-level reconstruction and ecological expansion to UOS AI. System-level Claw Mode: The newly launched system-level native Claw mode fully integrates with mainstream IM application interfaces such as Lark, DingTalk, and ...Read more

ZEVENET: How to Choose a Cybersecurity Provider in 2026: Why Most Can’t Be Trusted

Isabel Perez — 2026-04-09T15:28:40+00:00

Cybersecurity is no longer just a technical problem. It’s a trust problem.

Only 5% of IT decision-makers say that both they and their organization fully trust their cybersecurity providers, according to the Cybersecurity Trust Reality 2026 report by Sophos, based on responses from 5,000 organizations across 17 countries.

A remarkably low figure and a deeply concerning one, especially in a context where attacks on digital infrastructure are growing in both sophistication and frequency, where AI is amplifying existing threats, and where virtually any actor can launch a devastating cyberattack.

Blindly trusting a provider you cannot evaluate has itself become a vulnerability.

This article won’t give you a vendor ranking. It will tell you what to look for to determine whether your current provider — or one you’re evaluating — is actually protecting your business.

The Trust Crisis Nobody Wants to Talk About

The data points clearly in one direction: most organizations work with cybersecurity providers they don’t fully trust.

This isn’t a matter of subjective perception.

According to the Sophos report:

79% say it is difficult to assess the reliability of new cybersecurity providers or partners.
62% also struggle to trust the providers they already work with.
47% say the information provided by vendors is not sufficiently objective or detailed.

And the consequences are tangible:

51% say they are more concerned about the possibility of their organization suffering a serious cyber incident.
45% say it makes them more likely to switch providers — a costly and disruptive process for most organizations.
42% report an increase in oversight requirements.
41% say they have less peace of mind about their cybersecurity posture.
38% express concern that they or their organization may have chosen the wrong provider.

The underlying problem is structural: trust in cybersecurity has historically been built on commercial promises, not verifiable mechanisms.

Certifications, audits, and service level agreements provide a framework, but they don’t replace the ability to independently verify what your provider is actually doing inside your infrastructure.

For security teams, this creates constant friction: slower decision-making, higher provider turnover, and a risk posture that depends more on faith than on real knowledge.

Why This Is Urgent

The trust problem doesn’t exist in isolation. It becomes critical because the threat landscape has changed substantially in recent years.

Attacks on digital infrastructure are more frequent, more sophisticated, and harder to attribute.

Ransomware remains the dominant threat in enterprise environments, with organized groups operating with their own business models: affiliates, technical support, distribution channels.

According to data reported by Lisa News, the World Bank estimates that 92% of the world’s critical infrastructure has known vulnerabilities.

And artificial intelligence is reshaping the threat landscape significantly: it doesn’t create new attack categories, but it dramatically lowers the barrier to entry. It enables highly personalized social engineering attacks at scale, automated vulnerability scanning, and the development of malware with autonomous adaptation capabilities.

The result is an environment where any organization, regardless of size or sector, is a potential target. The question is no longer whether you will be attacked, but whether your infrastructure is in a position to detect, contain, and recover from it.

In that context, working with a provider whose real capabilities you cannot verify is not just a trust problem. It’s an active vulnerability.

Why Trusting Cybersecurity Providers Is So Difficult

The problem isn’t that providers are bad. The problem is structural.

Lack of Real Visibility

Many market solutions operate as black boxes. They promise protection, but:

They don’t let you inspect which rules are active in your WAF.
They don’t show you what traffic is being blocked or why.
They don’t offer traceability that you can audit independently.

Without visibility, security is an assumption. And an assumption protects no one.

Vendor Lock-in

The rise of SaaS and cloud-only solutions has brought operational advantages. But it has also created a structural problem: in many cases, your security infrastructure is outside your control.

This translates into:

Security policies you cannot customize.
Rules you cannot review.
Data flowing through third-party infrastructure.

And when an incident occurs, you depend on the provider’s response capacity, not your own.

Fragmented Security

In a typical 2026 infrastructure, security is often distributed across multiple tools: a reverse proxy here, an external WAF there, third-party DDoS protection, another vendor for monitoring.

The result is not greater protection. It’s greater complexity, more points of failure, and reduced capacity to respond to incidents.

What Makes a Cybersecurity Solution Truly Trustworthy

Trust in cybersecurity is not a matter of brand or marketing. It’s a matter of architecture.

A trustworthy solution must offer:

Full traffic visibility Layer 7 inspection (HTTP/HTTPS), detailed logs with real traceability, and the ability to precisely identify what is being blocked and why. Not a marketing dashboard (auditable data).
Control over security rules Real access to WAF rules (OWASP, custom, per application) and the ability to adjust them to your environment. If you can’t touch the rules, you don’t have control. And without control, there is no trust.
Integrated security, not stacked WAF, DDoS protection, and traffic management in a single layer reduces complexity, eliminates blind spots, and accelerates incident response. Fragmented architectures multiply the attack surface.
Transparency in costs and features No hidden modules, no per-feature licensing, no surprises when scaling. Opaque models make evaluation harder and erode trust over time.
Deployment flexibility On-premises, cloud, virtual, dedicated hardware, or hybrid environments. Because every infrastructure is different, and security cannot depend on a single deployment model.

The Problem with Many Current Solutions

Platforms like F5 or Netscaler offer solid technical capabilities, but carry structural problems that make it harder to achieve exactly what you need most today: transparency and control.

High complexity and cost: multiple modules, additional per-feature licenses, and complex configurations increase TCO and create dependency on the vendor’s own professional services.
Closed ecosystems: limited customization, restricted access to critical configurations, and reliance on proprietary ecosystems that make independent auditing difficult.
Loss of control in cloud-only models: in purely SaaS solutions, the infrastructure is not yours. You cannot fully audit what happens, and you depend on external decisions about updates, policy changes, or service availability.

This doesn’t mean these solutions don’t work. It means that if what you’re looking for is trust based on control and visibility, your architecture matters as much as the vendor you choose.

How to Regain Control: Integrated ADC + WAF as the First Line of Defense

The trend gaining traction among the most mature organizations is not adding more tools. It’s simplifying and unifying the delivery and security layer.

This is where the concept of an Application Delivery Controller (ADC) with integrated WAF changes the equation.

A modern ADC is not just a load balancer. It’s the layer that:

Manages and optimizes application traffic.
Inspects requests in real time before they reach the backend.
Applies security rules — WAF, bot control, DDoS protection — in an integrated and auditable way.
Provides full visibility into what is happening across your HTTP/HTTPS traffic.

When this layer is transparent, configurable, and deployable within your own infrastructure, security stops being a black box and becomes a system you can understand, audit, and control.

Practical Case: From Fragmented Infrastructure to Full Control

A company running several exposed digital services operated with NGINX as a proxy, a third-party external WAF, and separate tools for monitoring and DDoS protection.

The problem wasn’t a lack of tools. It was a lack of visibility across them.

When an incident occurred, diagnosis time spiked because each tool’s logs were independent. There was no unified view of traffic.

After migrating to an ADC architecture with integrated WAF:

Traffic inspection and control were centralized into a single layer.
Incident response times decreased significantly.
The security team shifted from reacting to having proactive visibility.

The result wasn’t just more security. It was more control. And more control means more trust.

How SKUDONET Fits Into This Picture

SKUDONET is a European Application Delivery and Security platform designed for environments where control, visibility, and deployment flexibility are not optional.

Its architecture integrates into a single platform:

ADC with advanced load balancing and high availability.
WAF with IPDS (Intrusion Prevention and Detection System): deep Layer 7 inspection, OWASP rules, and full customization capability.
Integrated DDoS protection, without relying on external services.
Real traffic visibility: auditable logs, full traceability, no black boxes.

And unlike cloud-only solutions, SKUDONET can be deployed on dedicated hardware, bare metal, virtual machines, cloud, or hybrid environments.

This means the infrastructure can be wherever you decide it should be. And the rules are yours to control.

Trust doesn’t come from trusting the vendor. It comes from being able to verify what it does.

Trust in Cybersecurity Is Architecture, Not Promises

In a context where 95% of companies don’t fully trust their providers, where attacks on digital infrastructure keep growing, and where AI is amplifying risk significantly, the relevant question is not which vendor has the best marketing.

The questions are:

Can you see what’s happening in your infrastructure?
Can you control it?
Can you audit it independently?

If the answer is no, you have a vulnerability that no SLA contract will cover.

Real trust in cybersecurity is not purchased. It is built on visibility, control, and architectures you can understand.

Where to Start

If you are assessing whether your application infrastructure is truly protected, the first step is not switching providers.

It’s understanding how your traffic is managed today, what level of visibility you have over it, and whether the security rules being applied are auditable and under your control.

SKUDONET offers an ADC + WAF platform you can deploy within your own infrastructure, with full visibility and no opaque dependencies.

Discover how it works

Deepin: deepin 25.1 Acknowledgments: Thank You

徐, 小龙 — 2026-04-09T11:18:19+00:00

During the development and refinement cycle of deepin 25.1, hundreds of community members participated in code writing, issue feedback, multi-language translation, community building, and ecosystem promotion. Below is the complete list of contributors for this release cycle. Every line of code and every piece of feedback is the core driving force behind deepin. 💻 Code Contributions (PR & Commits & Issues) Thank you to the following developers for contributing valuable code to the system core, desktop environment, and various applications (sorted by count descending, June 2025 – April 2026): Statistics source: https://www.deepin.org/index/datastat PR Contributions Commits Contributions Issues Contributions mhduiy opsiff ...Read more

Deepin: (中文) 极客浪漫！deepin人共建的终端音乐播放器来了！

xiaofei — 2026-04-09T02:23:19+00:00

Sorry, this entry is only available in 中文.

GreenboneOS: Patch Now! CVE-2026-35616 and CVE-2026-21643: Fortinet EMS Actively Exploited

Joseph Lee — 2026-04-08T13:46:23+00:00

Fortinet FortiClient EMS faces immediate risk from two critical severity CVEs: CVE-2026-35616 in versions 7.4.5-7.4.6 and CVE-2026-21643 in 7.4.4. CVE-2026-35616 (CVSS 9.8) is an actively exploited vulnerability in Fortinet FortiClient Enterprise Management Server (EMS) 7.4.5 through 7.4.6, published on April 4, 2026. The flaw is an improper access control [CWE-284] that can be exploited for […]

Deepin: deepin 25 Operating System User Installation & Usage FAQ

徐, 小龙 — 2026-04-08T07:43:33+00:00

1. Download & Image Selection Q1: Where can I download the official deepin 25 ISO image? A: Visit the official download page: https://www.deepin.org/en/download/ Q2: How do I choose the correct image for my computer? A: Select the image according to your processor architecture: Architecture Supported Processors (Examples) Notes AMD64 (x86_64) Intel Core, AMD Ryzen Most common; suitable for the vast majority of personal computers ARM64 Phytium D2000/D3000/E2000/S2500/S5000C, Kunpeng 920 For Chinese ARM platforms Loong64 Loongson 3A5000 (requires New World firmware) or newer Must use balenaEtcher or the dd command to create bootable media RISC-V Specific RISC-V development boards only Technology ...Read more

Deepin: (中文) 应用更新| 三款开源设计软件升级，没有Adobe也能做设计

xiaofei — 2026-04-08T03:18:57+00:00

Sorry, this entry is only available in 中文.

GreenboneOS: March 2026 Threat Report: New Critical Risks Span the Enterprise Attack Surface

Joseph Lee — 2026-04-07T11:02:57+00:00

This month exposed new cyber security risks at all levels of enterprise IT infrastructure. New critical vulnerability exposure emerged in perimeter networking gear and core network appliances. Other risks included actively exploited flaws in major browsers, enterprise email clients, agentic workflow platforms, core OS components, and virtually every other aspect of the enterprise IT ecosystem. […]

Tails: Tails 7.6.1

Tails — 2026-04-07T00:00:00+00:00

This release is an emergency release to fix important security vulnerabilities in Tor Browser.

Changes and updates

Update Tor Browser to 15.0.9, which fixes several vulnerabilities in Firefox 140.9.1.

We are not aware of these vulnerabilities being exploited in practice.
Update the Tor client to 0.4.9.6.
Update Thunderbird to 140.9.0.
Update some firmware packages. This improves support for newer hardware: graphics, Wi-Fi, and so on.

For more details, read our changelog.

Get Tails 7.6.1

To upgrade your Tails USB stick and keep your Persistent Storage

Automatic upgrades are available from Tails 7.0 or later to 7.6.1.
If you cannot do an automatic upgrade or if Tails fails to start after an automatic upgrade, please try to do a manual upgrade.

To install Tails 7.6.1 on a new USB stick

Follow our installation instructions:

The Persistent Storage on the USB stick will be lost if you install instead of upgrading.

To download only

If you don't need installation or upgrade instructions, you can download Tails 7.6.1 directly:

ARMBIAN: Github Highlights

Michael Robinson — 2026-04-06T14:10:37+00:00

This week’s Armbian development saw significant enhancements across hardware support and system functionality. The Arduino UNO Q was officially added, along with new firmware and flash binaries for the QRB2210 and QCM2290 variants. HDMI CEC support was introduced for Rockchip RK3588/RK3576 SoCs, while panel compatibility expanded with updates for Raspberry Pi and Hardkernel ODROID-Vu8S. Key kernel improvements included a bump to version 7.0-rc6 and rewritten patches for Rockchip64-6.18. The release also featured workflow hardening, exclusion of unsupported boards, and fixes for USB-C OTG mode on Odroid-M2. These updates collectively strengthen Armbian’s platform stability and broaden its device coverage.

Changes

Add Arduino UNO Q. by @igorpecovnik in armbian/armbian.github.io#268
Add firmware for Arduino UNO Q (QRB2210/QCM2290). by @SuperKali in armbian/firmware#123
Add HDMI CEC support to Rockchip RK3588/RK3576 SoCs. by @chaitan3 in armbian/build#9622
Agatti: add flash binaries for Arduino UNO Q (QRB2210). by @SuperKali in armbian/qcombin#1
Arduino logo. by @igorpecovnik in armbian/armbian.github.io#269
ch13726a: Added missing MIPI_DSI_MODE_VIDEO. by @kay-lambdadelta in armbian/build#9621
config: rockchip64: build Motorcomm YT6801 drivers built-in for OOB Ethernet. by @c127dev in armbian/build#9625
drm: add support for rpi panel v2. by @ackPeng in armbian/linux-rockchip#465
Exclude end-of-support boards from armbian-images.json. by @igorpecovnik in armbian/armbian.github.io#271
Harden data-update-partners workflow. by @igorpecovnik in armbian/armbian.github.io#270
mainline: bump edge to 7.0-rc6. by @EvilOlaf in armbian/build#9618
Odroid-M2: Add support for Hardkernel ODROID-Vu8S panel. by @mlegenovic in armbian/build#9627
Odroid-M2: Fix USB-C port in OTG mode. by @mlegenovic in armbian/build#9633
Remove radxa-dragon-q6a from targets-release-nightly blacklist. by @igorpecovnik in armbian/armbian.github.io#267
rockchip-vendor: CONFIG_BT_HCIBTUSB=m. by @vidplace7 in armbian/build#9628
rockchip64-6.18: rewrite kernel patches against 6.18.21. by @EvilOlaf in armbian/build#9629
SpacemiT: Disable k1-usb: add disconnect function support. by @pyavitz in armbian/build#9620

BunsenLabs Linux: Forum Reorganizing

BunsenLabs Linux — 2026-04-05T00:00:00+00:00

Now that carbon has been released, the forums are bit out of date. The Death Star is needed. As a test, we will use it on... ArchLabs & Friends! You're far too trusting.

https://forums.bunsenlabs.org/viewtopic.php?id=9760

Vote now to destroy or save. It's a barbaric system but, George Lucas, you know...

Deepin: deepin Community Monthly Report for March 2026

xiaofei — 2026-04-03T07:46:10+00:00

Learn more about deepin details, historical versions, user reviews, etc.: https://distrowatch.com/table.php?distribution=deepin I. March Community Data Overview II. Community Products 1. deepin 25.0.13 Internal Testing Released: Stability Enhancements and Multi-Scenario Fixes In March, deepin 25 internal test version 25.0.13 was pushed, focusing on fixing high-frequency community feedback issues, further improving overall system stability: Security & Stability Enhancements: Fixed multiple kernel security vulnerabilities; optimized system exception logs in scenarios such as suspend/resume, hibernation, and reboot stress testing, improving long-term operational reliability. Desktop & Window Management Optimizations: Fixed anomalies and crashes in X11/Treeland during multi-screen switching, lock screen, auto-hide taskbar, and Alt+Tab switching scenarios. Application ...Read more

Deepin: (中文) 免费开源！deepin 用户自研字体管理器，现已上架应用商店

xiaofei — 2026-04-03T02:54:22+00:00

Sorry, this entry is only available in 中文.

SparkyLinux: Sparky news 2026/03

pavroo — 2026-04-01T18:24:15+00:00

The 3rd monthly Sparky project and donate report of the 2026: – Linux kernel updated up to 6.19.10, 6.18.20-LTS, 6.12.79-LTS – added to repos: Electron-Mail, Opera GX – the CLI sparky-installer got an option to install 32 grub-efi on 64bit machines; sparky testing (9) only – Sparky 2026.03 & Special Editions of the testing/rolling line released – according of change the nitrogen wallpaper…

Source

ARMBIAN: Armbian Newsletter

Michael Robinson — 2026-04-01T16:25:06+00:00

Welcome to the latest Armbian Newsletter: your source for the latest developments, community highlights, and behind-the-scenes updates from the world of open-source ARM and RISC-V computing.

The past two months have been particularly active for the embedded ecosystem. At EMBEDDED WORLD 2026, developers, hardware vendors, and open-source communities gathered to showcase the latest innovations shaping the future of embedded computing. In parallel, the Armbian project continues to evolve with new releases, expanded board support, and ongoing improvements to the build framework driven by the contributions of its global community and the growing demand for reliable Linux on ARM and RISC-V platforms.

Join us in making open source better! Every donation helps Armbian improve security, performance, and reliability — so everyone can enjoy a solid foundation for their devices.

Github Highlights

Armbian blogMichael Robinson

My First embedded world and I Already Can’t Wait for the Next

I’d been putting this off for years. Every March, I’d read someone else’s embedded world recap, tell myself “next year”, and go back to my terminal. This year I actually went and I’m still processing everything I saw. First things first: the team Before I talk about any stand or

Armbian blogDaniele Briguglio

Armbian Q1 2026: Technical Milestones and the Road to Embedded World

The first quarter of 2026 has been a period of significant technical consolidation for the Armbian project. Driven by the v26.02 (Goa) release cycle, the project has focused on three core pillars: aggressive framework refactoring, the stable rollout of the Linux 6.18 LTS kernel, and the maturation of

Armbian blogMichael Robinson

ARMBIAN: Armbian Q1 2026: Technical Milestones and the Road to Embedded World

Michael Robinson — 2026-04-01T16:06:48+00:00

The first quarter of 2026 has been a period of significant technical consolidation for the Armbian project. Driven by the v26.02 (Goa) release cycle, the project has focused on three core pillars: aggressive framework refactoring, the stable rollout of the Linux 6.18 LTS kernel, and the maturation of the Armbian Imager utility.

Core Framework Refactoring

A primary objective this quarter was the reduction of technical debt within the armbian/build repository. The development team initiated a systematic cleanup to improve build reliability and maintenance.

Toolchain Optimization: Through a series of pull requests, including #9218, #9252, and #9256, significant "dead code" was removed from the internal toolchain. This refactoring simplifies the logic required to support a diversifying array of ARM and RISC-V architectures.
mmdebstrap Transition: The framework has officially transitioned to mmdebstrap as the exclusive engine for rootfs creation (#9512). By deprecating the legacy debootstrap method, the project ensures faster, more consistent, and reproducible builds across varied host environments.
Bash Modernization: Internal build scripts have been transitioned from POSIX to Bash syntax to leverage modern shell features and enhance overall script reliability.

Kernel and Hardware Integration

Q1 marked the broad adoption of the Linux 6.18 LTS kernel series, providing improved driver support and hardware abstraction for tier-1 platforms.

Linux 6.18 LTS Rollout: Stable support for the 6.18.y kernel was merged for major families, including meson64, rockchip64, and UEFI targets (#9069, #9086).
Hardware Support Expansion:
- SpacemiT MusePi Pro: Full integration and kernel patching were completed (#9422).
- Orange Pi RV2: Initial support and nightly build availability were established for this RISC-V target.
- Radxa Rock 4D & ODROID M2: These boards were elevated to the stable support tier within the 26.02 release.
Firmware Updates: U-Boot was bumped to v2026.01 for several platforms. Notably, boot delays on the Orange Pi 5 series were addressed via updated U-Boot candidates (#9450).

Ecosystem Tools: Armbian Imager

The Armbian Imager has transitioned from a utility to a cornerstone of the project’s user experience, with a focus on security and onboarding efficiency.

Cross-Platform Security: Code signing was implemented for both macOS and Windows artifacts to reduce installation friction for non-Linux users (imager#87).
Performance Improvements: The utility now features optimized image decompression and enhanced device disconnect detection (imager#28).
Automated Reporting: A new AI Actions Report workflow (armbian.github.io#165) was implemented to automate development highlights, providing greater transparency into the commit history for the community.

Strategic Industry Alignment

The technical trajectory of Q1 was intentionally aligned with Armbian’s presence at Embedded World 2026 in Nuremberg.

By showcasing the framework and Imager as guests of Seeed Studio, the project demonstrated its readiness for industrial-scale deployment. The shift toward mainline kernel and U-Boot support—specifically targeting the retirement of vendor-specific bootloaders—remains a priority for long-term security and professional-grade stability.

Contributors & Credits

The progress in Q1 2026 is the result of sustained contributions from the Armbian Dev team and the wider community. Detailed changelogs and commit histories are available at github.com/armbian/build.

ARMBIAN: My first embedded world and I already can't wait for the next

Daniele Briguglio — 2026-04-01T16:05:59+00:00

I&aposd been putting this off for years. Every March, I&aposd read someone else&aposs embedded world recap, tell myself "next year", and go back to my terminal. This year I actually went and I&aposm still processing everything I saw.

First things first: the team

Before I talk about any stand or chip, I need to tell you what made this trip different from anything I&aposve done before. There were five of us from the Armbian team at the show: Igor, Werner, Meko, amazingfate, and me. Five people. Four countries. Some of us had worked together for years and never met in person.

You know how it is in open-source, you collaborate through GitHub, you argue about patches on the mailing list, you review each other&aposs code at odd hours. But you don&apost always know the face behind the username. Meeting those people for real, shaking their hand, having a coffee together, that&aposs something no pull request can replicate. And honestly, it was worth the trip on its own.

The show itself: I wasn&apost ready for this

Arriving at the Nuremberg Messe for the first time is a genuine shock. I knew embedded world was big. I did not know it was this big. Enormous halls, thousands of exhibitors, tens of thousands of attendees. On day one I got genuinely lost between the pavilions spent a solid half hour wandering with no idea where I was. I&aposm told this is a rite of passage.

What surprised me most about the atmosphere is how concrete everything felt. This isn&apost a conference where people pitch vaporware from behind polished booths. Engineers and developers everywhere, talking about real problems, showing real hardware. You can walk from a giant like Qualcomm to a small team doing something fascinating with a handful of sensors and both conversations feel equally substantive.

What we saw on the floor

Rockchip was a mandatory stop for us, and they didn&apost disappoint. On their stand: the RK3572 EVB an evaluation board we hadn&apost seen in person before. Reading specs in a datasheet is one thing. Seeing the board running, understanding its real-world size, its connectors, how it behaves, that&aposs a completely different kind of knowledge. The kind you can only get by showing up.

Rockchip Employees (Most left and right) and Jianfeng Liu, Mecid Urganci & Igor Pecovnik

Seeed Studio had live demos of AI Vision and AI Sound, and the one that genuinely impressed me was their AI camera with a built-in NPU doing real-time object recognition. I&aposm not talking about laggy, stuttering inference, it was smooth. Fluid. The kind of performance that makes you stop walking and just stare for a minute. Seeing that level of real-time AI running on a compact edge device was one of those moments where the future stops feeling abstract.

Seedstudio x Armbian (Maximilian Riedl , Igor Pecovnik, Jianfeng Liu, Daniele Briguglio)

Qualcomm brought the Arduino Ventuno Q, and this is where things got interesting and a little funny. meko had already run his benchmarks on the board when amazingfate noticed something: Chromium&aposs hardware acceleration wasn&apost enabled. So he enabled it. Right there. Directly on the board. In front of the stand staff.

The reaction from the Qualcomm team? Complete, genuine astonishment. They didn&apost see it coming. That&aposs what happens when you bring a group of Armbian developers to a trade show, we don&apost just look at things, we poke at them.

Armbian at the Foundries.io booth

Collabora was present at the show, and amazingfate got to meet some of the team. Their kernel and GPU driver work is always relevant to what we do, so that conversation mattered even if I wasn&apost there for it personally.

The moment that hit hardest: Armbian on the BeagleBadge

During a meeting with the BeagleBoard.org team inside the show, they showed us their brand new project: the BeagleBadge. Launched right there at embedded world 2026, it won Best in Show in the Wearables category; a Linux-powered wearable badge with a 4.2" ePaper display, dual-core ARM Cortex-A53, Wi-Fi 6, LoRa, and more sensors than I can list here. Built around the Texas Instruments AM62L32, manufactured by Seeed Studio.

Impressive hardware. But here&aposs the part that actually stopped me in my tracks: Armbian was running on it. There&aposs an official "Armbian BeagleBadge demo for EW2026" image — Debian Trixie, Linux 6.12 — listed right on the BeagleBoard.org site.

Our OS. On a Best-in-Show winning badge. At the world&aposs biggest embedded show.

That&aposs not a small thing. That&aposs the community&aposs work showing up exactly where it matters.

What embedded world taught me about where this industry is going

Three days of walking, talking, and observing gives you a pretty clear picture of the currents moving through the embedded world right now.

Edge AI is not a trend anymore, it&aposs infrastructure. Every major vendor had something running inference locally, without cloud, on modest hardware. This is real, it&aposs shipping, and it&aposs going to reshape what we expect embedded systems to do.

Open-source has earned its seat at the table. I half-expected it to be the hobbyist corner of the show. It wasn&apost. Companies are building on Linux, on open stacks, on ecosystems maintained by communities like ours. That&aposs not charity, it&aposs strategy. And it means the work we do in Armbian matters more than we sometimes give ourselves credit for.

The line between prototype and product is razor thin. At most stands you&aposd see a mix: shipping products, reference designs, things that will exist in six months. That gap is where the interesting information lives; what&aposs coming, which platforms are getting serious investment, which vendors are committed to mainline Linux support. You don&apost learn that from a datasheet. You learn it by being there.

Would I go back?

Without a second thought.

If you&aposre an Armbian community member who&aposs been putting this off the same way I was stop putting it off. The technical exposure is valuable. The networking is real. And meeting the people you build things with, face to face, is something that doesn&apost have a substitute.

The show runs every year in Nuremberg. I&aposll be there.

See you in 2027. 🇩🇪

Deepin: (中文) 470+次投递，390+人参与：这场 Wine 生态共建，我们一起创造了什么？

xiaofei — 2026-04-01T10:24:51+00:00

Sorry, this entry is only available in 中文.

Pardus: Pardus 25.1 Sürümü Yayımlandı

Mohammad Niaei — 2026-04-01T05:53:50+00:00

TÜBİTAK tarafından geliştirilmeye devam edilen Pardus’un 25.1 sürümü yayımlandı. Pardus 25.1; Pardus 25 ailesinin ilk ara sürümüdür.

ARMBIAN: Github Highlights

Michael Robinson — 2026-03-31T02:52:23+00:00

This week in Armbian development saw a significant expansion of hardware support, including new board images and compatibility for devices such as the Ariaboard Photonicat 2, SpacemiT MUSE Book, NanoPC T6 Plus, and Mekotronics R58S2. Kernel patches were updated across multiple platforms, notably for Rockchip and Sunxi families, enhancing stability and performance. Several new modules were introduced in the configuration framework, including browser-based code-server, memory management, Docker log viewing, and subscription tracking. Improvements to documentation, security hardening, and code formatting were also implemented. Notable fixes addressed USB, Ethernet, and device-specific issues, while ZFS functionality and tuning interfaces received updates. The release continues Armbian’s commitment to broad hardware support and robust system features.

Changes

action: fix typos, update defaults, and harden GPG signing. by @igorpecovnik in armbian/build#9613
Add Ariaboard Photonicat 2 support for rockchip64-6.18. by @HackingGate in armbian/build#9535
Add container_type field to Uptime Kuma config. by @igorpecovnik in armbian/configng#776
Add image and reusable slug for Qidi X-4. by @Shadowrom2020 in armbian/armbian.github.io#262
Add Laptop SpacemiT MUSE Book. by @pyavitz in armbian/build#9591
Add line breaks to improve .md rendering. by @igorpecovnik in armbian/configng#784
Add NanoPC T6 plus image. by @igorpecovnik in armbian/armbian.github.io#266
Add radxa-dragon-q6a to nightly release blacklist. by @igorpecovnik in armbian/armbian.github.io#260
add recomputer rk3588-devkit support. by @ackPeng in armbian/linux-rockchip#460
add rockchip patch for fusb302 to support aw3561. by @ackPeng in armbian/linux-rockchip#456
add rockchip zbit mtd spi flash support. by @ackPeng in armbian/linux-rockchip#464
Add rtl8710bufw_SMIC.bin for RTL8188GU WiFi USB. by @Shadowrom2020 in armbian/firmware#121
add support for imx708 raspberry pi v3 camera. by @ackPeng in armbian/linux-rockchip#457
Add trixie and noble to nightly manual targets. by @igorpecovnik in armbian/armbian.github.io#263
Add xfce desktop for riscv64 legacy branch in stable builds. by @igorpecovnik in armbian/armbian.github.io#264
aic8800-dkms extension. by @Shadowrom2020 in armbian/build#9578
arm64: dts: rockchip: add Mekotronics R58S2. by @HeyMeco in armbian/linux-rockchip#461
armbian-kernel: improve code documentation and formatting. by @igorpecovnik in armbian/build#9559
Board image: Add Mekotronics R58S2. by @igorpecovnik in armbian/armbian.github.io#265
Board: Add Mekotronics R58S2. by @HeyMeco in armbian/build#9610
Bump geekyeggo/delete-artifact from 5 to 6. by @igorpecovnik in armbian/os#443
docs: expand GitHub Actions section with examples and inputs reference. by @igorpecovnik in armbian/documentation#900
docs: reorganize ZFS documentation with proper tab formatting. by @igorpecovnik in armbian/configng#779
docs: simplify code-server documentation footer. by @igorpecovnik in armbian/configng#792
Dozzle: Proper image. by @igorpecovnik in armbian/configng#775
families: sm8550: Limit kernel version to 6.18.18. by @kasimling in armbian/build#9604
feat: add code-server module for browser-based VS Code. by @igorpecovnik in armbian/configng#790
feat: add comprehensive memory management module. by @igorpecovnik in armbian/configng#781
feat: add Dozzle Docker log viewer module. by @igorpecovnik in armbian/configng#773
feat: add Wallos subscription tracker module. by @igorpecovnik in armbian/configng#785
feat: ZFS pool import and scan functionality. by @igorpecovnik in armbian/configng#782
Fix Docker image configuration for GitHub Actions. by @igorpecovnik in armbian/docker-armbian-build#12
fix: force destroy VMs when graceful shutdown fails. by @igorpecovnik in armbian/configng#793
fix: improve kvmtest module security, UI, and add channel selection. by @igorpecovnik in armbian/configng#789
fix: resolve mixed indentation in prometheus heredoc. by @igorpecovnik in armbian/configng#794
framework artifact-rootfs - remove the last vestige of LEGACY_DEBOOTSTRAP. by @tabrisnet in armbian/build#9599
HACK: Enable PCIe switch on RK3399. by @retro98boy in armbian/build#9574
KDE Neon: add more packages for touchscreen devices. by @kasimling in armbian/build#9551
mkspi: fix devicetree opp voltage settings. by @redrathnure in armbian/build#9603
nanopi-zero2: add USB support for RK3528 (current + edge). by @rubycomm in armbian/build#9500
OrangePi5Pro: Comprehensive HW Support: YT6801 PCIe-Eth, Codec ES8388 Audio, eFUSE & U-Boot v2025.10. by @c127dev in armbian/build#9600
qcom/sc8280xp: sync microsoft blackrock (windows dev kit 2023) latest firmware for mainline kernel. by @rbqvq in armbian/firmware#122
Qidi X-6: fix devicetree opp voltage settings. by @Shadowrom2020 in armbian/build#9577
refactor: update KVM test images to latest releases. by @igorpecovnik in armbian/configng#783
rock-3a: bump uboot to v2026.04-rc4. by @EvilOlaf in armbian/build#9576
rockchip-rv1106: Enable (=m) Realtek 8188EU wifi. by @vidplace7 in armbian/build#9607
rockchip64-6.18: rewrite kernel patches against 6.18.20. by @EvilOlaf in armbian/build#9587
rockchip64: rk3528: fix USB OTG and ethernet for NanoPi Zero2. by @rubycomm in armbian/build#9597
sm8550-6.18: Fix TF card IO performance regression. by @kasimling in armbian/build#9546
SpacemiT MUSE Book: Fixup SRC_CMDLINE var. by @pyavitz in armbian/build#9612
stmmac: Refactor Phytium ethernet patches into modular components. by @igorpecovnik in armbian/build#9585
style: simplify markdown formatting in Wallos footer. by @igorpecovnik in armbian/configng#787
sunxi-6.18: rewrite kernel patches against 6.18.20. by @EvilOlaf in armbian/build#9611
sunxi: drm/gem-dma: Support dedicated DMA device for allocation. by @EvilOlaf in armbian/build#9605
sunxi: edge: bump to 7.0. by @EvilOlaf in armbian/build#9549
sunxi: Enable device mapper snapshot support. by @frank-f in armbian/build#9590
sunxi: fix iommu driver patch to allow compilation. by @EvilOlaf in armbian/build#9592
sunxi: fix Unhandled Exception in EL3. and/causing secondary cpus not coming online. by @EvilOlaf in armbian/build#9586
sunxi: remove BSP GMAC/EPHY patch that breaks H6 internal EMAC. by @igorpecovnik in armbian/build#9609
uefi edge: bump to 7.0. by @EvilOlaf in armbian/build#9547
uefi-arm64-6.12: fix stmmac compilation errors. by @igorpecovnik in armbian/build#9596
uefi-x86-6.18: rewrite kernel patches against 6.18.20. by @EvilOlaf in armbian/build#9588
update seeed studio rk3576 devkit camera and dp overlay. by @ackPeng in armbian/linux-rockchip#463
Update some board csc file. by @retro98boy in armbian/build#9573
Update ZFS tuning recommendations and remove settings view. by @igorpecovnik in armbian/configng#780
ZFS Performance Tuning Interface. by @igorpecovnik in armbian/configng#777
[2026.5] - framework rootfs-create: remove LEGACY_DEBOOTSTRAP, use only the upstream mmdebstrap. by @tabrisnet in armbian/build#9512

VyOS: VyOS 1.5.0 GA release

Daniil Baturin — 2026-03-31T00:30:00+00:00

Hello, Community!

VyOS 1.5.0 LTS release is now finalized and its CLI is frozen for any non-compatible changes. Right now subscribers can already download the generic ISO and other on-premises flavors for x86-64 systems. If you are contributing to VyOS and want LTS release images for personal use, remember that we are happy to share them through contributor subscriptions.

Its development started in 2024 and followed the usual two-year LTS release cycle. In those two years we introduced multiple big features including a long-awaited accelerated dataplane and a huge amount of bug fixes.

Download the full release notes

Elive: Elive 3.8.50 Stable ‘Retrowave’ is released!

Thanatermesis — 2026-03-30T19:32:58+00:00

The Elive Team is pleased to announce a new stable release: Elive Retrowave 3.8.50 LTS, featuring a fully Synthwave‑inspired OS. This version has many months of strong testing to ensure stability and improvements keep the system lightweight, efficient, and extremely reliable. We are happy to offer this release in both 32‑bit and 64‑bit versions, absolutely free of charge, now and in the future. For those who prefer to keep the classic look and feel, the installer includes an option to switch to the default desktop designs, making this variant fullySEE DETAILS

Check more in the Elive Linux website.

Deepin: (中文) WHLUG 仲春茶叙，共话开源与 AI 新趋势

xiaofei — 2026-03-30T09:09:27+00:00

Sorry, this entry is only available in 中文.

Deepin: (中文) deepin 亮相 OS2ATC，斩获“最具影响力桌面及服务器操作系统”奖

xiaofei — 2026-03-30T02:38:03+00:00

Sorry, this entry is only available in 中文.

Deepin: (中文) 飞桨黑客松第十期文心合作伙伴赛道启动！丰厚奖金等着你！

xiaofei — 2026-03-30T02:29:42+00:00

Sorry, this entry is only available in 中文.

Deepin: (中文) 聚力“如意” | deepin 共推 RISC-V 生态高质量发展

xiaofei — 2026-03-30T01:59:13+00:00

Sorry, this entry is only available in 中文.

Grml developers: Evgeni Golov: Converting Dovecot password schemes on the fly without (too much) cursing

Grml developers — 2026-03-28T22:11:57+00:00

I finally upgraded my mail server to Debian 13 and, as expected, the Dovecot part was quite a ride.

The configuration syntax changed between Dovecot 2.3 (Debian 12) and Dovecot 2.4 (Debian 13), so I started first with diffing my configuration against a vanilla Debian 12 one (this setup is slightly old) and then applied the same (logical) changes to a vanilla Debian 13 one. This mostly went well. Mostly because my user database is stored in SQL and while the Dovecot Configuration Upgrader says it can convert old dovecot-auth-sql.conf.ext files to the new syntax, it only does so for the structure, not the SQL queries themselves. While I don't expect it to be able to parse the queries and adopt them correctly, at least a hint that the field names in userdb changed and might require adjustment would've been cool.

Once I got that all sorted, Dovecot would still refuse to let me in:

Error: sql: Invalid password in passdb: Weak password scheme 'MD5-CRYPT' used and refused

Yeah, right. Did I mention that this setup is old?

The quick cure against this is a auth_allow_weak_schemes = yes in /etc/dovecot/conf.d/10-auth.conf, but long term I really should upgrade the password hashes in the database to something more modern.

And this is what this post is about.

My database only contains hashed (and salted) passwords, so I can't just update them without changing the password. And while there are only 9 users in total, I wanted to play nice and professional. (LOL)

There is a Converting Password Schemes howto in the Dovecot documentation, but it uses a rather odd looking PHP script, wrapped in a shell script which leaks the plaintext password to the process list, and I really didn't want to remember how to write PHP to complete this task.

Luckily, I know Python.

The general idea is:

As we're using plaintext authentication (auth_mechanisms = plain login), the plaintext password is available during login.
After Dovecot's imap-login has verified the password against the old (insecure) hash in the database, we can execute a post-login script, which will connect to the database and update it with a new hash of the plaintext password.

To make the plaintext password available to the post-login script, we add '%{password}' as userdb_plain_pass to the SELECT statement of our passdb query. The original howto also says to add a prefetch userdb, which we do. The sql userdb remains, as otherwise Postfix can't use Dovecot to deliver mail.

Now comes the interesting part. We need to write a script that is executed by Dovecot's script-login and that will update the database for us. Thanks to Python's passlib and mysqlclient, the database and hashing parts are relatively straight forward:

#!/usr/bin/env python3

import os

import MySQLdb
import passlib.hash

DB_SETTINGS = {"host": "127.0.0.1", "user": "user", "password": "password", "database": "mail"}
SELECT_QUERY = "SELECT password_enc FROM mail_users WHERE username=%(username)s"
UPDATE_QUERY = "UPDATE mail_users SET password_enc=%(pwhash)s WHERE username=%(username)s"

SCHEME = "bcrypt"
EXPECTED_PREFIX = "$2b$"


def main():
    # https://doc.dovecot.org/2.4.3/core/config/post_login_scripting.html
    # https://doc.dovecot.org/2.4.3/howto/convert_password_schemes.html
    user = os.environ.get("USER")

    plain_pass = os.environ.get("PLAIN_PASS")
    if plain_pass is not None:
        db = MySQLdb.connect(**DB_SETTINGS)
        cursor = db.cursor()
        cursor.execute(SELECT_QUERY, {"username": user})
        result = cursor.fetchone()
        current_pwhash = result[0]

        if not current_pwhash.startswith(EXPECTED_PREFIX):
            hash_module = getattr(passlib.hash, SCHEME)
            pwhash = hash_module.hash(plain_pass)
            data = {"pwhash": pwhash, "username": user}
            cursor.execute(UPDATE_QUERY, data)
        cursor.close()
        db.close()


if __name__ == "__main__":
    main()

But if we add that as executable = script-login /etc/dovecot/dpsu.py to our imap-postlogin service, as the howto suggests, the users won't be able to login anymore:

Error: Post-login script denied access to user

WAT?

Remember that shell script I wanted to avoid? It ends with exec "$@".

Turns out the script-login "API" is rather interesting. It's not "pass in a list of scripts to call and I'll call all of them". It's "pass a list of scripts, I'll execv the first item and pass the rest as args, and every item is expected to execv the next one again". 🤯

With that (cursed) knowledge, the script becomes:

#!/usr/bin/env python3

import os
import sys

import MySQLdb
import passlib.hash

DB_SETTINGS = {"host": "127.0.0.1", "user": "user", "password": "password", "database": "mail"}
SELECT_QUERY = "SELECT password_enc FROM mail_users WHERE username=%(username)s"
UPDATE_QUERY = "UPDATE mail_users SET password_enc=%(pwhash)s WHERE username=%(username)s"

SCHEME = "bcrypt"
EXPECTED_PREFIX = "$2b$"


def main():
    # https://doc.dovecot.org/2.4.3/core/config/post_login_scripting.html
    # https://doc.dovecot.org/2.4.3/howto/convert_password_schemes.html
    user = os.environ.get("USER")

    plain_pass = os.environ.get("PLAIN_PASS")
    if plain_pass is not None:
        db = MySQLdb.connect(**DB_SETTINGS)
        cursor = db.cursor()
        cursor.execute(SELECT_QUERY, {"username": user})
        result = cursor.fetchone()
        current_pwhash = result[0]

        if not current_pwhash.startswith(EXPECTED_PREFIX):
            hash_module = getattr(passlib.hash, SCHEME)
            pwhash = hash_module.hash(plain_pass)
            data = {"pwhash": pwhash, "username": user}
            cursor.execute(UPDATE_QUERY, data)
        cursor.close()
        db.close()

    os.execv(sys.argv[1], sys.argv[1:])


if __name__ == "__main__":
    main()

And the passwords are getting gradually updated as the users log in. Once all are updated, we can remove the post-login script and drop the auth_allow_weak_schemes = yes.

Deepin: (中文) 我用 UOS AI 开发了一款 deepin 专属磁盘清理工具

xiaofei — 2026-03-27T02:38:15+00:00

Sorry, this entry is only available in 中文.

Deepin: (中文) 从用户反馈出发｜Wine 11.0 + 新手友好，打造更优质的 Windows 应用兼容体验

xiaofei — 2026-03-26T06:17:15+00:00

Sorry, this entry is only available in 中文.

Tails: Tails 7.6

Tails — 2026-03-26T00:00:00+00:00

New features

Automatic Tor bridges

You can now learn about Tor bridges directly from the Tor Connection assistant in Tails.

Tor bridges are secret Tor relays that hide that you are connecting to Tor. If connecting to Tor is blocked from where you are, you can use a bridge as your first Tor relay to circumvent this censorship.

In Tails 7.6, choose Connect to Tor automatically when opening Tor Connection. If access to the Tor network is blocked, the bridge configuration screen offers a new option called Ask for a Tor bridge based on your region.

This feature uses the same technology as the connection assistant in Tor Browser outside of Tails, which was introduced in Tor Browser 11.5 (July 2022).

Tails downloads information about bridges that are most likely to work in your region from the Moat API of the Tor Project. To circumvent censorship, this connection is disguised as a connection to another website using domain fronting.

GNOME Secrets

In Tails 7.6, the Secrets password manager replaces KeePassXC.

Secrets has a simpler interface and is better integrated in the GNOME desktop. For example, accessibility features, such as the screen keyboard and cursor size, are working again with Secrets.

Secrets offers to unlock your previous KeePassXC database automatically, because both Secrets and KeePassXC use the same file format to store passwords.

If you miss more advanced features from KeePassXC, you can install KeePassXC as additional software.

The main keyboard shortcuts of Secrets are similar to the ones of KeePassXC, with Shift in addition to Ctrl:

Shift+Ctrl+C: copy password
Shift+Ctrl+V: copy address
Shift+Ctrl+B: copy username
Shift+Ctrl+T: copy one-time password

To see the full list of keyboard shortcuts of Secrets, press Ctrl+?.

Changes and updates

Update Electrum from 4.5.8 to 4.7.0.
Update Tor Browser to 15.0.8.
Update Thunderbird to 140.8.0.
Update most firmware packages. This improves support for newer hardware: graphics, Wi-Fi, and so on.

Fixed problems

Translate the confirmation dialog that appears before saving the language and keyboard layout on the USB stick. (#21448)
Fix the Learn More button in the Thunderbird migration notification. (#21455)
Fix automated upgrades in Turkish. (#21466)

For more details, read our changelog.

Get Tails 7.6

To upgrade your Tails USB stick and keep your Persistent Storage

Automatic upgrades are available from Tails 7.0 or later to 7.6.
If you cannot do an automatic upgrade or if Tails fails to start after an automatic upgrade, please try to do a manual upgrade.

To install Tails 7.6 on a new USB stick

Follow our installation instructions:

The Persistent Storage on the USB stick will be lost if you install instead of upgrading.

To download only

If you don't need installation or upgrade instructions, you can download Tails 7.6 directly:

ARMBIAN: Armbianmonitor saves the day!

Michael Robinson — 2026-03-25T15:40:32+00:00

Diagnosing System Issues and Getting Support with Armbianmonitor

Armbian is a lightweight operating system based on Debian/Ubuntu, highly optimized for single-board computers (SBCs) like the Raspberry Pi, Orange Pi, and many others. When facing system problems on an SBC running Armbian, the built-in utility armbianmonitor is an essential diagnostic tool. It quickly gathers crucial system data, making troubleshooting faster and more accurate for both the user and the community providing support.

Key Diagnostic Functions

The primary use of armbianmonitor is to generate real-time performance and system configuration reports. By running the command without any arguments, you get a menu of options, but the most vital functions for diagnosis are:

System Status (armbianmonitor -m): This provides a live monitoring dashboard. It displays key metrics like CPU frequency, load average, temperature, memory usage, and disk I/O. By watching this output while a problem (like a system freeze or slowdown) occurs, you can often pinpoint the bottleneck—for instance, a sudden spike in CPU temperature indicating a cooling problem, or sustained high memory usage pointing to a resource leak.
System Information (armbianmonitor -u or -d): This is the most crucial function for seeking online support. It gathers a comprehensive, anonymized report including details about the kernel version, device model, installed packages, boot logs, and hardware configuration. This data is essential because the performance and stability of SBCs are often highly dependent on the specific kernel and hardware drivers used for that model.

Getting Support Online

When seeking help on platforms like the Armbian forum or GitHub, simply describing the symptoms is rarely enough. The person helping you needs to know the exact state of your system.

By running armbianmonitor -u, the utility uploads the detailed diagnostic report to a public pastebin service (like https://www.google.com/search?q=paste.armbian.com) and provides a unique, short URL. You can then include this URL directly in your support request. This allows community members to instantly access the exact configuration, eliminating back-and-forth questions about device type, OS version, and log file locations. This standardized method is the fastest way to receive targeted, effective assistance and ensures your issue is diagnosed accurately.

Deepin: (中文) 应用商店 | 4款超实用轻量应用，提升学习办公效率

xiaofei — 2026-03-25T09:30:45+00:00

Sorry, this entry is only available in 中文.

ZEVENET: Top Netscaler Alternatives in Europe (2026 Guide)

Isabel Perez — 2026-03-25T08:00:12+00:00

For years, NetScaler has been one of the most widely used Application Delivery Controllers (ADCs) in enterprise environments.

Many organisations rely on NetScaler to ensure high availability, application security, and traffic management across critical infrastructures.

However, in recent years, companies have started to evaluate alternative ADC platforms for several reasons, including:

licensing complexity
vendor dependency
infrastructure modernization
the need for simplified operations

In addition, the growing importance of digital sovereignty and infrastructure resilience has encouraged many European organisations to explore alternative platforms.

In this guide, we review some of the most relevant alternatives to NetScaler available today.

What is NetScaler?

NetScaler (Citrix ADC) is an Application Delivery Controller designed to optimise, secure, and control application traffic across enterprise infrastructures.

Typical capabilities include:

Layer 4 and Layer 7 load balancing
SSL/TLS offloading
Web Application Firewall (WAF)
traffic optimization and routing
high availability clustering

These platforms are usually deployed in front of applications to ensure:

performance
security
availability

Because ADC platforms sit at the entry point of many critical systems, they play a key role in infrastructure reliability.

Why Companies Are Looking for NetScaler Alternatives

While NetScaler remains a powerful platform, many organisations are currently evaluating alternatives.

Some of the most common reasons are as follows.

Increasing Licensing Complexity

Enterprise ADC solutions often require multiple licenses and additional modules to unlock advanced features.

This can lead to increased operational costs and licensing complexity.

Many infrastructure teams now prefer all-in-one platforms that include advanced capabilities from the start.

Vendor Lock-In Concerns

Some organisations prefer to reduce their dependence on a single-vendor ecosystem.

Vendor lock-in can make infrastructure evolution more difficult, particularly when organisations need flexibility to deploy across hybrid environments.

Infrastructure Modernization

Modern infrastructures increasingly combine:

on-premise environments
virtualization
public cloud
hybrid architectures

Infrastructure teams, therefore, require solutions that can operate consistently across multiple environments.

Infrastructure Sovereignty

Another emerging topic is infrastructure sovereignty.

Organisations operating critical services are evaluating whether key components of their infrastructure should rely on external technology providers.

This has led some companies to explore European alternatives for their infrastructure stack.

Top Netscaler Alternatives

Below are several well-known ADC platforms used by enterprises today.

SKUDONET

SKUDONET is a European Application Delivery Controller platform designed to provide high availability, load balancing, and advanced security in a single solution.

The platform combines application delivery and cybersecurity features into a unified architecture that can be deployed across multiple environments.

Key capabilities include:

Layer 4 and Layer 7 load balancing
Integrated Web Application Firewall
intelligent traffic routing
multi-protocol support
clustering and high availability

SKUDONET can be deployed across a wide range of infrastructures, including:

bare metal environments
virtualized infrastructures
on-premise deployments
public and hybrid cloud environments

Unlike some enterprise solutions, all advanced capabilities are included in the platform without requiring additional modules or extra costs.

Another differentiator is the platform’s focus on ease of management, allowing infrastructure teams to control load balancing and security from a centralised interface.

F5 BIG-IP

F5 is one of the most established vendors in the ADC market.

Its BIG-IP platform offers advanced traffic management and security capabilities for complex enterprise environments.

Key strengths include:

advanced traffic policies
broad enterprise ecosystem
extensive feature set

However, some organisations report that F5 deployments can become complex to manage and expensive to scale.

HAProxy Enterprise

HAProxy is widely known for its high performance and reliability.

The enterprise edition offers additional features designed for organisations that require professional support and enterprise-grade capabilities.

Strengths include:

high performance
scalability
strong open-source ecosystem

HAProxy is commonly used in environments that require high throughput and strong customisation capabilities.

NGINX Plus

NGINX Plus is a popular application delivery platform that evolved from the widely used NGINX open-source web server.

It is frequently adopted in environments where DevOps teams prioritise automation and API-driven infrastructure.

Key strengths include:

strong developer ecosystem
integration with modern application stacks
API gateway capabilities

NGINX is particularly common in cloud-native environments.

Netscaler Alternatives Comparison

When evaluating ADC platforms, differences often go beyond feature lists.

Many organisations today face challenges related to:

complex licensing structures
increasing operational overhead
limited visibility across the infrastructure
long-term dependency on specific vendors

As infrastructure environments evolve, these factors become increasingly relevant in platform selection.

The comparison below outlines how different ADC platforms typically approach these challenges.

Note:
The comparison reflects common patterns observed across ADC platforms. Specific capabilities and configurations may vary depending on vendor, deployment model, and use case.

For many teams, selecting an ADC platform is not only about technical capabilities.

It often involves balancing factors such as:

operational complexity
visibility and control
long-term flexibility
alignment with infrastructure strategy

When Should You Consider Migrating from NetScaler?

Organisations typically evaluate alternative ADC platforms during several key moments.

Common scenarios include:

infrastructure modernisation projects
cloud migration initiatives
licensing renewal cycles
architecture redesigns
vendor diversification strategies

These transitions provide an opportunity to reassess infrastructure platforms and evaluate alternative technologies.

Conclusion

Application Delivery Controllers remain a critical component of modern infrastructure.

As organisations continue to modernise their environments and prioritise resilience, flexibility, and security, many teams are exploring alternative ADC platforms.

While NetScaler remains a widely used solution, a growing number of companies are evaluating alternatives that provide:

simplified operations
flexible deployment models
transparent licensing
integrated security features

European platforms such as SKUDONET represent one of the options organisations can consider when designing their next-generation application delivery infrastructure.

Explore Alternatives to Netscaler

Organisations evaluating alternatives to NetScaler often start with a simple question:

What would a different approach to application delivery look like in practice?

If your team is currently reviewing ADC platforms, exploring different architectures and deployment models can help clarify the right direction.

At SKUDONET, we regularly work with infrastructure teams evaluating their current setup and exploring alternative approaches.

If it’s useful, you can:

explore how different deployment models work in practice
Review migration considerations from existing ADC platforms
Discuss specific infrastructure requirements with our engineering team

Explore SKUDONET or request a technical walkthrough

ARMBIAN: Github Highlights

Michael Robinson — 2026-03-24T00:59:07+00:00

This week in Armbian development saw significant enhancements across multiple areas, including expanded board support and improved hardware compatibility. Notable additions include new images and configurations for Qidi X-6, X-7, and Ariaboard Photonicat2 mainboards, as well as refined kernel patch maintenance and updates for various platforms. The build system received important fixes, such as resolving compilation errors and device tree issues, alongside improvements in Docker utilities and offline mode detection. Several refactoring efforts streamlined backend processes and enhanced user interface elements. The team also introduced automatic fallback mechanisms for Hetzner server types, optimizing runner scaling. Overall, these updates reinforce Armbian&aposs commitment to stability, broader hardware support, and a smoother user experience.

Changes

Add automatic fallback to smaller Hetzner server types with runner count scaling. by @igorpecovnik in armbian/actions#15
Add board and board vendror image for Ariaboard Photonicat2. by @HackingGate in armbian/armbian.github.io#255
Add image for Qidi X-7 Mainboard. by @Shadowrom2020 in armbian/armbian.github.io#257
Add some board image. by @retro98boy in armbian/armbian.github.io#258
Add support for dialog via new wrapper functions. by @igorpecovnik in armbian/configng#762
Add support for qidi x-* boards. by @Shadowrom2020 in armbian/build#9564
Change unit tests badge link in documentation. by @igorpecovnik in armbian/documentation#885
Drop patches that landed upstream and fix two. by @igorpecovnik in armbian/build#9544
edge: bump 7.0 to rc5. by @EvilOlaf in armbian/build#9580
Enable BCACHE on Raspberry Pi build. by @aulanov in armbian/build#9550
feat: offline mode detection with local asset cache. by @SuperKali in armbian/imager#117
feat: settings refactoring, DiskArbitration device detection, and filename parser improvements. by @SuperKali in armbian/imager#114
fix race condition and NULL ptr deref in PCIe threaded probe. by @AlomeProg in armbian/linux-rockchip#458
fix(docker): add trixie support for upstream docker-ce to fix HomeAssistant installation. by @igorpecovnik in armbian/configng#765
fix: correct dialog argument order causing box option errors. by @igorpecovnik in armbian/configng#768
fix: resolve Phytium stmmac compilation errors for kernel 6.19. by @igorpecovnik in armbian/build#9545
fix: settings modal reset, custom image manufacturer, and board detection setting. by @SuperKali in armbian/imager#116
Image for Qidi X-6 Mainboard. by @Shadowrom2020 in armbian/armbian.github.io#256
kernel patch maintenance. by @EvilOlaf in armbian/build#9562
meson64-6.18: rewrite kernel config. by @EvilOlaf in armbian/build#9581
mksklipad50: fix devicetree opp voltage settings. by @torte71 in armbian/build#9569
OrangePi-RV2/R2S: rename board config from wip to csc. by @sven-ola in armbian/build#9560
Qidi X-6: fix defconfig patch. by @Shadowrom2020 in armbian/build#9567
refactor: add comprehensive Docker wrapper utilities with progress display. by @igorpecovnik in armbian/configng#769
refactor: deduplicate hooks, add CSS design tokens, clean up backend. by @SuperKali in armbian/imager#115
rockchip64-7.0: mekotronics-r58x-pro: analog sound: use SuperKali&aposs new clock. by @rpardini in armbian/build#9554
rockchip64: rk3588: add I2S MCLK output gate clocks for audio codec support. by @SuperKali in armbian/build#9548
rockchip64: rk3588: update I2S MCLK gate patches to match upstream v3 and add u-boot clock IDs. by @SuperKali in armbian/build#9568
sm8250: Fix application of Retroid Pocket 5/mini device trees. by @kay-lambdadelta in armbian/build#9572
SpacemiT: Update ATFSOURCE, BOOTSOURCE and SD card support.. by @pyavitz in armbian/build#9552
sunxi-6.18: remove stray commit from patch. by @EvilOlaf in armbian/build#9556
sunxi: bump edge to 6.19.y, current to 6.18.y and legacy to 6.12.y. by @EvilOlaf in armbian/build#9381
Update odroidxu4-current to 6.6.129. by @belegdol in armbian/build#9558
Update VERSION. by @EvilOlaf in armbian/build#9553

Qubes: XSAs released on 2026-03-24

Qubes — 2026-03-24T00:00:00+00:00

The Xen Project has released one or more Xen security advisories (XSAs). The security of Qubes OS is not affected.

XSAs that DO affect the security of Qubes OS

The following XSAs do affect the security of Qubes OS:

(none)

XSAs that DO NOT affect the security of Qubes OS

The following XSAs do not affect the security of Qubes OS, and no user action is necessary:

XSA-482
- In-VM escalation only
- Qubes OS does not support Secure Boot inside VMs.

About this announcement

Qubes OS uses the Xen hypervisor as part of its architecture. When the Xen Project publicly discloses a vulnerability in the Xen hypervisor, they issue a notice called a Xen security advisory (XSA). Vulnerabilities in the Xen hypervisor sometimes have security implications for Qubes OS. When they do, we issue a notice called a Qubes security bulletin (QSB). (QSBs are also issued for non-Xen vulnerabilities.) However, QSBs can provide only positive confirmation that certain XSAs do affect the security of Qubes OS. QSBs cannot provide negative confirmation that other XSAs do not affect the security of Qubes OS. Therefore, we also maintain an XSA tracker, which is a comprehensive list of all XSAs publicly disclosed to date, including whether each one affects the security of Qubes OS. When new XSAs are published, we add them to the XSA tracker and publish a notice like this one in order to inform Qubes users that a new batch of XSAs has been released and whether each one affects the security of Qubes OS.

Purism PureOS: Wired Confirmed iPhone’s Worst-Kept Secret: Closed Systems Fail at Scale

Purism — 2026-03-23T16:28:47+00:00

For years, Apple has sold the myth of the “unhackable iPhone.” A walled garden. A fortress. A device so locked down that only nation-states could dream of breaking in. Wired’s latest reporting just blew that narrative apart.

The post Wired Confirmed iPhone’s Worst-Kept Secret: Closed Systems Fail at Scale appeared first on Purism.

SparkyLinux: Sparky 2026.03 Special Editions

pavroo — 2026-03-23T12:42:39+00:00

There are new iso images of Sparky 2026.03 Special Editions out there: GameOver, Multimedia and Rescue. This release is based on Debian testing “Forky”. The March update of Sparky Special Edition iso images features Linux kernel 6.19.8, updated packages from Debian and Sparky testing repos as of March 21, 2026, and most changes introduced at the 2026.03 release. There is no need to reinstall…

Source

ZEVENET: SKUDONET Enterprise Edition 10.1.5 Released: performance, stability, and operational management improvements

Isabel Perez — 2026-03-23T11:13:09+00:00

Maintaining a stable application infrastructure isn’t just about major changes. In critical environments, incremental improvements in performance, resource management, and system behavior make a real difference in day-to-day operations.

The new SKUDONET Enterprise Edition 10.1.5 introduces optimizations focused on efficiency, operational stability, and consistency in traffic and security management.

Key improvements in this release

SSL memory optimization in HTTP/S farms

One of the most sensitive aspects of any ADC is managing encrypted connections.

In this version, memory usage for SSL operations within HTTP/S farms has been optimized, improving efficiency in high encrypted traffic scenarios.

Additionally, internal behavior has been streamlined by removing legacy memory reset functions, contributing to more predictable performance.

Impact: better resource utilization and increased stability under load.

Enhanced logging and diagnostics

Logging mechanisms in HTTP/S farms have been improved, and core dump generation has been introduced, enabling deeper analysis when incidents occur.

This allows technical teams to:

detect issues faster
analyze complex behaviors
reduce troubleshooting time

Impact: greater visibility and diagnostic capabilities in production environments.

Improved APT operations management

A wait-lock system has been introduced to prevent concurrent APT executions.

In environments where tasks are automated or multiple operations are managed simultaneously, this avoids conflicts during package management.

Impact: improved system stability and reduced risk of inconsistencies.

Included fixes

WebGUI – HSTS configuration

An issue in the WebGUI template affecting HSTS configuration has been resolved.

Behavior and rendering are now consistent with the defined configuration.

WAF – Ruleset management

The ruleset deactivation process in the WAF has been improved.

The WebGUI now correctly updates the payload, ensuring that rule changes are consistently reflected.

Impact: increased reliability in managing security policies.

Why do these improvements matter?

In modern ADC platforms like SKUDONET, the challenge isn’t just distributing traffic—it’s doing so efficiently, securely, and with full observability.

Small improvements in:

memory management
operational control
configuration consistency

have a direct impact on:

service availability
user experience
operational workload

As defined in SKUDONET’s architecture, the ADC acts as a central point for availability, security, and performance in application delivery.

Conclusion

Version 10.1.5 strengthens key aspects of day-to-day operations:

more efficient resource usage
improved diagnostic capabilities
more predictable system behavior
enhanced WAF management

It doesn’t introduce disruptive changes, but it does deliver meaningful improvements that reinforce stability and reliability in production environments.

If you’re looking to improve the stability and security of your infrastructure without adding complexity, discover how SKUDONET adapts to physical, virtual, and cloud environments with a unified approach to Application Delivery—try it free for 30 days.

If you work with SKUDONET Enterprise Edition or want to stay up to date with the latest technical updates, visit our Timeline.

VyOS: VyOS Stream 2026.03 is available for download

Daniil Baturin — 2026-03-20T09:28:00+00:00

Hello, Community!

VyOS Stream 2026.03 is available for download now. It features multiple backports from the rolling release, including restored ability to directly upgrade from VyOS 1.3.x, a big rework of the VPP CLI, post-quantum pre-shared key support for IPsec, and multiple bug fixes.

GreenboneOS: Patch Now! 7 New Critical Vulnerabilities in Veeam Backup & Replication

Joseph Lee — 2026-03-19T09:07:49+00:00

On March 12th, 2026, Veeam published two security advisories containing 7 critical and one high-severity vulnerability in its Backup & Replication server. The flaws cumulatively affect the version 12 and 13 builds. Although there are no reports of active exploitation or public proof-of-concept (PoC) exploits available yet, Veeam has appeared on CISA’s Known Exploited Vulnerabilities […]

Deepin: (中文) 还在“养虾”？deepin 请你吃“虾”了

xiaofei — 2026-03-18T11:11:00+00:00

Sorry, this entry is only available in 中文.

ZEVENET: OWASP CRS and Fail Fast: Improving Attack Detection in WAFs and Reverse Proxies

Isabel Perez — 2026-03-18T09:23:03+00:00

In web application security, detecting attacks as early as possible is critical.
Every millisecond that a malicious request travels through an infrastructure increases backend exposure and consumes unnecessary resources.

Web Application Firewalls (WAFs) based on the OWASP Core Rule Set (CRS) have become one of the most widely used mechanisms to protect applications against attacks such as:

SQL Injection
Command Injection
Path Traversal
Remote Code Execution
Cross-Site Scripting (XSS)

However, when these rules are integrated into modern high-performance reverse proxies, a limitation appears due to the historical processing model inherited from ModSecurity.

In this article we will analyze:

how the OWASP CRS inspection pipeline works
what issue appears in modern reverse proxies
how applying the fail fast principle can improve security

We will also explain how SKUDONET has implemented this approach to stop attacks as early as possible in the WAF data path.

In perimeter security, stopping an attack one step earlier in the data flow can make a critical difference.

Why OWASP CRS Remains the Standard for WAF Protection

The OWASP Core Rule Set (CRS) is one of the most widely used rule sets for Web Application Firewalls.

It is built on ModSecurity and provides predefined rules designed to detect patterns associated with common vulnerabilities, particularly those included in the OWASP Top 10.

Among the threats it can detect are:

SQL injection
Cross-site scripting
Remote command execution
Path traversal
protocol anomalies
malicious bots

The goal of OWASP CRS is to analyze every HTTP request before it reaches the backend, blocking malicious patterns through an anomaly scoring system.

This model has proven effective for years, but it was designed at a time when most proxies did not operate in high-performance streaming mode.

How the OWASP CRS Inspection Pipeline Works

The ModSecurity Phase Model

OWASP CRS follows the ModSecurity inspection model, which divides the analysis of an HTTP request into several phases.

Simplified pipeline:

Each phase analyzes a different part of the traffic.

Phase 1

Analyzes information available immediately:

HTTP headers
URI
query string
request metadata

Phase 2

Analyzes the full content of the request:

request body
POST parameters
JSON
XML
complex payloads

This approach works well for deep inspection, but it introduces an important consequence.

A Subtle Issue in OWASP CRS

Within OWASP CRS there are rules that analyze variables available from the very beginning of the request, such as:

ARGS_GET
REQUEST_URI
QUERY_STRING

However, many of these rules are executed in Phase 2.

This means that a request such as:

GET /login.php?user=admin’ OR ‘1’=’1 HTTP/1.1

Host: example.com

contains a SQL injection clearly visible in the URL, yet it may not be evaluated until Phase 2.

From a security perspective, this raises an obvious question:

If the attack is already detectable in Phase 1, why wait until Phase 2 to block it?

The Security Principle: Fail Fast

In system architecture there is a fundamental principle:

Fail Fast

A system should detect invalid conditions as early as possible in the execution flow.

Applied to a WAF, this means:

An attack should be stopped as soon as it becomes detectable.

Not later.

How Modern High-Performance Reverse Proxies Work

Modern reverse proxies are designed to reduce:

latency
memory consumption
buffering

To achieve this, many proxies operate in streaming mode.

An efficient proxy may process a request in the following way:

Receive HTTP headers
Analyze them
Immediately forward them to the backend
Later receive the request body
Analyze and forward it

Simplified flow:

But when combined with OWASP CRS, a problem appears.

The Conflict Between High-Performance Proxies and OWASP CRS

If the proxy operates in streaming mode while OWASP CRS follows its traditional model:

WAF Phase 1 executes (but the full evaluation is completed in Phase 2)
Headers are forwarded to the backend
The request body arrives later
WAF Phase 2 executes, (completing the evaluation started in Phase 1).
The body is forwarded to the backend

This means the backend may receive part of the request before the WAF has made the final decision.

From a security perspective, this is suboptimal.

Architecture Comparison: Traditional Pipeline vs Fail Fast

High-Performance Proxy with Traditional CRS

Result:

the backend has already received traffic
part of the attack has already progressed through the infrastructure

Fail Fast Pipeline

In this model, the attack is stopped at the earliest possible point in the data path.

Applying the SKUDONET Fail Fast Approach to the WAF

To address this problem, SKUDONET implemented an approach based on the fail fast principle.

The idea is simple:

If an attack can be detected in Phase 1, it should be evaluated in Phase 1.

This requires partially reorganizing the logic of OWASP CRS rules.

Technical Example: CRS Rules That Can Be Evaluated Earlier

A simplified CRS rule example might look like this:

SecRule ARGS_GET “@detectSQLi” \

“id:942100,\

phase:2,\

block,\

msg:’SQL Injection Attack Detected'”

Here we see the key issue:

phase:2

Even if the attack pattern appears in the URL, the rule may execute later.

Conceptually, an early detection could be evaluated like this:

SecRule REQUEST_URI “@detectSQLi” \

“id:942100,\

phase:1,\

block”

This allows attacks to be detected before the traffic progresses through the processing pipeline.

Want to see how this works in practice?

Try the SKUDONET WAF Demo

Early Evaluation (Phase 1)

At this stage the WAF analyzes elements available from the start of the request:

headers
URL
query string

Examples of early detection include:

SQL injection in the URL
command injection
path traversal
header anomalies

Simplified flow:

If the attack is detected here, the request never reaches the backend.

Deep Evaluation (Phase 2)

When the body arrives, the second inspection phase runs:

This phase enables the detection of more complex attack patterns.

Conclusion

OWASP CRS remains one of the most important tools for protecting web applications.

However, when deployed in modern high-performance architectures, the traditional phase model may introduce certain limitations, particularly in environments where reverse proxies operate in streaming mode.

The fail fast principle offers a clear solution:
detect attacks as early as possible in the processing flow and block them before they progress through the infrastructure.

This approach allows organizations to:

identify threats in early stages of the request
reduce backend exposure
improve the overall efficiency of the security system

In modern infrastructures, every millisecond matters.
And in perimeter security, stopping an attack one step earlier can make all the difference.

Platforms like SKUDONET apply this fail fast approach directly within the reverse proxy pipeline, allowing attacks to be stopped as early as possible in the WAF data path.

FAQ

What is fail fast in cybersecurity?

Fail fast is a design principle where systems detect invalid or malicious conditions as early as possible. In WAF architectures, this means identifying and blocking malicious requests at the earliest stage of the inspection pipeline.

What is OWASP CRS?

OWASP Core Rule Set (CRS) is a collection of security rules used by Web Application Firewalls to detect common web attacks such as SQL injection, cross-site scripting (XSS), and command injection.

Why can OWASP CRS delay attack detection?

Some OWASP CRS rules analyze request parameters during Phase 2 of the ModSecurity inspection model, even when malicious patterns may already be visible earlier in the request lifecycle.

Why is the fail fast principle important for reverse proxies?

High-performance reverse proxies often forward HTTP headers to the backend before the full request body is received. Detecting attacks early prevents malicious requests from reaching backend services and reduces unnecessary resource consumption.

What role does a WAF play in an ADC?

In modern Application Delivery Controllers (ADC), the Web Application Firewall is integrated directly into the Layer-7 proxy pipeline, allowing malicious traffic to be inspected and blocked before it reaches application servers.

See Fail Fast WAF Protection in Action

If you want to see how the fail fast approach works in a real reverse proxy environment, you can test the SKUDONET platform.

Start the SKUDONET Demo

ZEVENET: SKUDONET Enterprise Edition 10.1.4 Released: Full Control of Fail Fast, Improved WAF Accuracy, and Critical Fixes

Isabel Perez — 2026-03-17T17:37:10+00:00

SKUDONET Enterprise Edition 10.1.4 is now available, consolidating the improvements introduced in version 10.1.3 and adding critical fixes and enhancements to ensure greater stability, more accurate security processing, and better control over threat mitigation.

This release responds directly to issues identified after the previous version, delivering a more refined and reliable platform for production environments .

In addition to resolving bugs, version 10.1.4 introduces a key evolution of the Fail Fast capability, giving administrators full control over how and when malicious traffic is blocked.

What’s new in SKUDONET EE 10.1.4

Full control of Fail Fast with SKD_FAIL_FAST

Version 10.1.3 introduced the concept of Fail Fast within the IPDS engine. Now, version 10.1.4 takes it a step further.

A new variable, SKD_FAIL_FAST, allows administrators to enable or disable early-stage request blocking during rule evaluation.

What does this mean in practice?

Malicious requests can be blocked earlier in the inspection pipeline
Security decisions are applied before full rule processing completes
Unnecessary processing of suspicious traffic is reduced

Why it matters

In high-traffic or attack scenarios:

Reduces CPU and memory consumption
Improves response time under attack
Prevents backend overload

This gives teams granular control over security behavior, allowing them to adapt protection strategies depending on performance or security requirements.

Improved OWASP CRS rule processing

The handling of OWASP Core Rule Set (CRS) rules has been improved to ensure they are evaluated in the correct processing phases.

Problem

Incorrect rule evaluation phases can lead to:

False positives
Missed detections
Inconsistent behavior

Solution

Rules are now executed in their intended phases
Detection accuracy is improved
Alignment with OWASP standards is reinforced

This results in a more reliable WAF behavior, especially in environments with:

APIs
Complex payloads
Custom security rules

Improved WAF validation in HTTP/S farms

Version 10.1.4 introduces enhanced validation and consistency checks for WAF rulesets applied to HTTP/S farms.

Impact

Ensures correct rule configuration
Prevents misconfigurations before deployment
Improves reliability of applied security policies

For administrators, this means fewer unexpected behaviors and more predictable WAF enforcement in production.

Bug fixes for production stability

This release includes critical fixes that address issues detected in previous versions:

Improved WAF reload behavior in HTTP/S farms

WAF reload processes now ensure a more consistent application of changes
Configuration updates are applied in a more reliable and predictable way
Improved consistency across running farms during policy updates

This enhancement provides administrators with greater confidence when applying changes to active environments, reducing variability and ensuring smoother WAF policy updates in production.

Key improvements introduced in 10.1.3 (included in this release)

Version 10.1.4 also includes all improvements from 10.1.3, ensuring a consolidated and stable release.

System performance optimizations

System-level tuning improves:

Resource management
Service scheduling
Overall responsiveness

This allows the ADC to maintain stability under high traffic loads and intensive processing scenarios.

Improved service management in the GUI

The services view now includes a permanent sorting option, making it easier to:

Navigate large service lists
Manage multiple farms
Operate complex infrastructures

A small UX improvement with a big operational impact.

Introduction of Fail Fast in IPDS

Version 10.1.3 introduced the Fail Fast concept, enabling:

Immediate blocking of malicious requests
Reduced unnecessary processing
Faster response to automated threats

Version 10.1.4 builds on this by adding control through SKD_FAIL_FAST.

Why Fail Fast changes application security

Fail Fast is not just a feature — it’s a change in how security is applied at the ADC level.

Traditional approach

Requests are fully processed
Security rules are evaluated step by step
Malicious traffic consumes resources before being blocked

Fail Fast approach

Malicious patterns are detected early
Requests are dropped immediately
Backend and ADC resources are preserved

This is especially critical in:

DDoS-like scenarios
Bot attacks
API abuse

Fail Fast turns the ADC into a more proactive and efficient security layer.

Why this update matters for production environments

This release directly impacts three key areas:

Stability

Fixes ensure predictable behavior in WAF and routing-related operations.

Security accuracy

Better OWASP CRS handling and validation improve detection quality and reduce false positives.

Performance efficiency

Fail Fast and system optimizations reduce resource usage and improve response times under load.

If you work with SKUDONET Enterprise Edition or want to stay up to date with the latest technical updates, visit our Timeline.

If you’d like to experience these improvements firsthand, try the SKUDONET Enterprise Edition 30-day trial.

Univention Corporate Server: Separate Admin Accounts in UCS: Role-Based Delegation and Just-in-Time Authentication

Felix Botner — 2026-03-17T08:16:13+00:00

Running administrative accounts and regular user accounts in the same directory is common in many environments – but separating them can significantly improve security. With Delegative Administration and Just-in-Time Authentication, UCS cleanly separates roles from identities. The result: less ACL complexity, clearer structures, and a more modern approach to administration.

In many IT environments, this is still common practice: domain administrators are also regular users. The same account that reads email, logs into business applications, and accesses internal services may also hold full administrative privileges in the directory.

Convenient? Absolutely. Risk-free? Not quite. If such an account is compromised, the impact goes far beyond a single user. A compromised admin account can potentially expose the entire infrastructure. That is why the German BSI IT-Grundschutz framework recommends clearly separating administrative accounts from regular user identities. In theory, that sounds pretty straightforward. In practice, the real question is: how do you actually implement that separation?

With UCS 5.2-4, released in December 2025, Univention introduces two new Nubus features designed to address exactly this challenge: Delegative Administration and Just-in-Time Authentication. Both features are currently available in preview. This article explains how they work and why they matter.

Delegative Administration in UCS: Rollen statt komplexer LDAP-ACLs

Anyone who wants to delegate administrative permissions in a directory service in a structured and transparent way sooner or later ends up dealing with LDAP Access Control Lists (ACLs). From a technical standpoint, they are extremely powerful. ACLs allow administrators to define very precisely who can read, modify, or delete specific objects. A new department can be placed in its own organizational unit (OU). A help desk team might receive permission to reset passwords. An external service provider could be granted temporary access to a specific part of the directory.

All of this is possible with ACLs. But things tend to get messy quickly. With every additional rule or exception, the configuration becomes harder to understand. And at some point, figuring out why a certain access is allowed or denied means digging through increasingly complex rule logic. Delegation is possible, but transparency often suffers.

Delegative Administration in Nubus introduces a new approach to authorization in the directory service through the Univention Directory Manager (UDM). The idea is simple: administrators should be able to define clearly who is allowed to do what in the directory service, and under which conditions. Right now, the feature is still in preview. According to the documentation, Delegative Administration is not yet intended for production use. Configuration and setup details may still change in upcoming releases.

One important limitation of the current preview is that Delegative Administration doesn‘t control which modules are visible in the Univention Management Console (UMC). Module visibility continues to be handled by the existing authorization mechanisms, primarily UCS policies. Delegative Administration operates at a different level. It evaluates authorization directly within UDM, checking whether a specific action in the directory service is allowed.

Role-Based Authorization in the Univention Directory Manager (UDM)

Instead of deriving permissions indirectly from ACL rules, Delegative Administration uses explicit roles. A role specifies

which object types it applies to (e.g., users or groups),
which part of the directory it covers (such as a specific OU),
which actions are allowed (read, modify, create, delete),
and which attributes can be accessed or modified.

Roles can be assigned directly to users or groups. When a role is assigned to a group, all members automatically inherit it. Authorization checks happen inside the UDM layer, where each requested operation is evaluated against the role definitions. The underlying LDAP ACLs stay exactly as they are.

This example shows how straightforward this works:

access by role="myRole"
   to objecttype="users/user" position.subtree="cn=users,{ldap/base}"
   grant actions="search,read"
   grant properties="*" permission="read"

This definition grants the role myRole read-only access to user objects of type users/user within a specific subtree below cn=users. Within that scope, the allowed actions are defined explicitly—in this case search and read. Other actions such as create or delete could be added as needed. Attribute access can also be controlled. In this example, all attributes may be read, but none can be modified.

How Delegative Administration Works for an Organizational Unit

The concept becomes easier to understand with a simple example. Imagine a user account called ou1-admin. This account is assigned a role that grants administrative permissions only for the organizational unit OU1. After logging in, the administrator only sees that part of the LDAP tree. The same applies to the user management module: it lists only the accounts located within that organizational unit.

Within this scope, the administrator can modify certain attributes, for example, the description field of a user object. But the boundaries are strict. If the user tries to assign roles or work outside OU1, the system returns a clear “Permission denied” message.

Now imagine assigning an additional administrative role for OU2 to the same account. After the next login, both organizational units appear in the directory tree. The administrative scope expands accordingly. Permissions are not extended implicitly or through hidden rule interactions. Instead, they grow in a transparent and predictable way through additional roles.

The result is a role-based model for administrative permissions that is easier to delegate, easier to configure, and far easier to understand than complex ACL structures. Please note, that Delegative Administration doesn’t replace LDAP ACLs. Instead, it adds a clearly structured authorization layer inside the Univention Directory Manager.

Defining roles, however, is only the first step. Even a perfectly configured OU administrator can become a risk if the administrative account lives in the same directory as all regular user accounts. This is exactly where Just-in-Time Authentication comes into play.

Just-in-Time Authentication in Nubus: Separating Administrative Accounts

The second feature is Just-in-Time Authentication. It works together with Delegative Administration and addresses another important question: where should administrative accounts actually live? The basic idea is simple: administrative accounts and regular user accounts should not be stored in the same directory. Instead, the two are separated:

One directory service stores the managed accounts.
A second directory service (e.g., Nubus or Active Directory) contains the administrative identities.

Administrators sign in with accounts from that external directory, but they still manage objects in the Nubus directory where the users actually reside. This creates a clear separation between managed identities and administrative identities. It follows established security best practices and aligns with the requirements defined in the BSI IT-Grundschutz, which recommend keeping administrative accounts separate.

How Just-in-Time Authentication Works with Keycloak and OIDC

Technically, this mechanism is based on OpenID Connect (OIDC). When someone signs in to the Univention Management Console (UMC), authentication happens through the Nubus identity provider, Keycloak. For Just-in-Time Authentication, Keycloak is configured to trust the identity provider of the external management domain. This establishes a federation between the two systems:

Signing in to the UMC first redirects the request to Keycloak.
Keycloak forwards the login request to the identity provider of the management domain.
The user authenticates there, against the external directory.
The external identity provider returns an OIDC token, which includes information such as:

nubus_id: a unique identifier for the management domain
nubus_roles_from_groups: the roles used to authorize the account

Nubus Keycloak passes this information on to the UMC.

At that point, the UMC detects that the account doesn’t exist in the local LDAP directory. And this is where the key idea of Just-in-Time Authentication becomes visible. No local admin account is created. Nothing is synchronized or replicated. There is no shadow account in the directory. Instead, the roles contained in the token nubus_roles_from_groups are applied only for the duration of that session.

Think of it as a visitor badge. The identity remains in the external system. During the session, the permissions defined in the token are activated temporarily. Once the user logs out, those permissions disappear again.

If the administrative account is disabled in the external system, access to the UMC stops immediately as well. Because no local copy of the account exists in the Nubus directory, the account status takes effect directly through the authentication flow. No additional status synchronization is required.

Delegative Administration and Just-in-Time Authentication: Two Pieces of the Same Model

The real strength of these features becomes clear when you look at them together.

Delegative Administration defines what an account is allowed to do in the directory.
Just-in-Time-Authentication defines where that account comes from.

If roles are defined but administrative accounts still live in the same directory as the managed user accounts, a structural risk remains. The admin account exists permanently inside the system. It’s technically part of the same directory and has to be protected there with additional safeguards. In that situation, the separation between administrative and regular identities may exist as a policy—but not as part of the architecture.

Just-in-Time Authentication changes that. Administrative identities remain in a separate management domain, such as an Active Directory or another Nubus system. They don’t exist as local objects in the target directory. They are not replicated, synchronized, or stored there permanently. Only when an administrator signs in through OpenID Connect are the required roles applied temporarily for that session.

Together, these two features make it possible to manage administrative access in a way that is structured, transparent, and easy to control—without adding more LDAP ACL complexity and without maintaining duplicate accounts.

Both features are currently available in preview with Nubus for UCS. If separating administrative accounts is something you’re working on, let‘s talk.

Der Beitrag Separate Admin Accounts in UCS: Role-Based Delegation and Just-in-Time Authentication erschien zuerst auf Univention.

Deepin: (中文) 新手必看超详细教程！如何在deepin上运行Windows应用

xiaofei — 2026-03-17T02:27:07+00:00

Sorry, this entry is only available in 中文.

ARMBIAN: Github Highlights

Michael Robinson — 2026-03-17T02:24:49+00:00

This week in Armbian development saw significant progress across board support and kernel updates. New boards such as the Cainiao CNIOT Core, EByte ECB41-PGE, DG SVR 865 Tiny, and NORCO EMB-3531 received initial support, expanding hardware compatibility. Kernel patches were rewritten for the meson64 and rockchip64 platforms, aligning with version 6.18.18, while edge releases were bumped to 7.0-rc3 and rc4. Improvements included enhanced SD card and audio support for SpacemiT and Youyeetoo YY3588 boards, as well as refined configuration checks and display fixes. Several upstream patches were dropped or disabled, and the Dependabot schedule was updated for daily maintenance. Additional fixes addressed USB modes, Docker host-gateway resolution, and Xorg display issues, rounding out a productive week for the Armbian project.

Changes

Add cainiao-cniot-core board and cainiao vendor image. by @retro98boy in armbian/armbian.github.io#251
Add EByte Vendor // ECB41-PGE board. by @vidplace7 in armbian/armbian.github.io#250
add recomputer rk3576-devkit dts. by @ackPeng in armbian/linux-rockchip#451
Add support for the Radxa Display 10 FHD to the Rock 5B Plus. by @FlorianKohn in armbian/linux-rockchip#453
add: initial support for DG SVR 865 Tiny board (SM8250/QCS8250). by @Lemon1151 in armbian/build#9423
arch: arm: dts: add EByte ECB41-PGE (RK3506g2). by @vidplace7 in armbian/linux-rockchip#454
armbian-zram-config: refine check for existing /tmp mount. by @vidplace7 in armbian/build#9514
cainiao cniot core improve. by @retro98boy in armbian/build#9526
chore: update Dependabot schedule to daily updates. by @igorpecovnik in armbian/build#9537
csc board: Add NORCO EMB-3531 initial support. by @retro98boy in armbian/build#9456
Drop patches that landed upstream and fix two. by @igorpecovnik in armbian/build#9544
edge: bump 7.0 to rc4. by @EvilOlaf in armbian/build#9543
extension: ccache-remote: fix Docker host-gateway for hostnames resolving to loopback. by @iav in armbian/build#9505
fix(orangepi5max): change usbdrd_dwc3_0 mode from otg to host. by @Echoflare in armbian/linux-rockchip#449
fix: correct repository dispatch event type name. by @igorpecovnik in armbian/armbian.github.io#254
framework run_host_x86_binary_logged - support 32-bit x86. by @tabrisnet in armbian/build#9466
Gateway AM-GZ80x: Update $board and meson-axg family conf. by @pyavitz in armbian/build#9533
maint: meson64-current: rewrite patches against 6.18.18. by @EvilOlaf in armbian/build#9528
maint: rockchip64-current: rewrite kernel patches against 6.18.18. by @EvilOlaf in armbian/build#9527
meson64: a311d: Fix Xorg display when etnaviv enabled. by @retro98boy in armbian/build#9524
Odroid-M2: Support for weather board zero. by @mlegenovic in armbian/build#9523
odroidn2: u-boot: bump to v2026.04-rc3; make fancy, incl LWIP. by @rpardini in armbian/build#9507
OrangePi 3 LTS: Update $board.conf file. by @pyavitz in armbian/build#9495
OrangePi-RV2/R2S: add sdcard and emmc for Linux-7.x. by @sven-ola in armbian/build#9539
Reword BTF memory check. by @x13-me in armbian/build#9502
RK3506: Add spidev overlays for RK3506 family. by @vidplace7 in armbian/linux-rockchip#450
rockchip64: bump edge to 7.0-rc3. by @EvilOlaf in armbian/build#9445
rockchip64: cleanup old patchsets. by @EvilOlaf in armbian/build#9498
rockchip: Add CSC board EByte ECB41-PGE (RK3506G). by @vidplace7 in armbian/build#9513
rockchip: refresh LibreELEC patch import for edge 6.19 kernel. by @paolosabatino in armbian/build#9506
rockchip: restore proper LE patches for rockchip armhf. by @paolosabatino in armbian/build#9530
rpi4b: bump edge to 7.0. by @EvilOlaf in armbian/build#9529
Spacemit rv2 rename dtb. by @sven-ola in armbian/build#9531
SpacemiT: Add SD card support, CPU freq scaling and other fixups. by @pyavitz in armbian/build#9518
SpacemiT: Disable patches that made it upstream (7.0-rc4). by @pyavitz in armbian/build#9540
spacemit: enable powervr drm driver for current 6.18 kernels. by @sven-ola in armbian/build#9515
sunxi: bump edge to 6.19.y, current to 6.18.y and legacy to 6.12.y. by @EvilOlaf in armbian/build#9381
Youyeetoo YY3588: Enable ES8388 audio support + RK3588 I2S MCLK gate fix . by @SuperKali in armbian/build#9534

Qubes: XSAs released on 2026-03-17

Qubes — 2026-03-17T00:00:00+00:00

The Xen Project has released one or more Xen security advisories (XSAs). The security of Qubes OS is affected.

XSAs that DO affect the security of Qubes OS

The following XSAs do affect the security of Qubes OS:

XSA-480
- See QSB-110

XSAs that DO NOT affect the security of Qubes OS

The following XSAs do not affect the security of Qubes OS, and no user action is necessary:

XSA-481
- Denial of service only

About this announcement

Qubes: QSB-110: Use after free of paging structures in EPT (XSA-480)

Qubes — 2026-03-17T00:00:00+00:00

We have published Qubes Security Bulletin (QSB) 110: Use after free of paging structures in EPT (XSA-480). The text of this QSB and its accompanying cryptographic signatures are reproduced below, followed by a general explanation of this announcement and authentication instructions.

Qubes Security Bulletin 110

             ---===[ Qubes Security Bulletin 110 ]===---

                              2026-03-17

         Use after free of paging structures in EPT (XSA-480)

User action
------------

Continue to update normally [1] in order to receive the security updates
described in the "Patching" section below. No other user action is
required in response to this QSB.

Summary
--------

On 2026-03-17, the Xen Project published XSA-480, "Use after free of
paging structures in EPT" [3]:
| The Intel EPT paging code uses an optimization to defer flushing of any cached
| EPT state until the p2m lock is dropped, so that multiple modifications done
| under the same locked region only issue a single flush.
| 
| Freeing of paging structures however is not deferred until the flushing is
| done, and can result in freed pages transiently being present in cached state.
| Such stale entries can point to memory ranges not owned by the guest, thus
| allowing access to unintended memory regions.

Impact
-------

On affected systems, an attacker controlling any PVH or HVM qube can attempt
to exploit this vulnerability in order to compromise Qubes OS.

Affected systems
-----------------

Only x86 Intel systems are affected.

Patching
---------

The following packages contain security updates that address the
vulnerabilities described in this bulletin:

  For Qubes 4.2, in dom0:
  - Xen packages version 4.17.6-3
  For Qubes 4.3, in dom0:
  - Xen packages version 4.19.4-5

These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [2] Once available, the packages should be installed
via the Qubes Update tool or its command-line equivalents. [1]

Dom0 must be restarted afterward in order for the updates to take
effect.

If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new Xen
binaries.

Credits
--------

See the original Xen Security Advisory and linked publications.

References
-----------

[1] https://www.qubes-os.org/doc/how-to-update/
[2] https://www.qubes-os.org/doc/testing/
[3] https://xenbits.xen.org/xsa/advisory-480.html

--
The Qubes Security Team
https://www.qubes-os.org/security/

Source: qsb-110-2026.txt

Marek Marczykowski-Górecki’s PGP signature

Source: qsb-110-2026.txt.sig.marmarek

Simon Gaiser (aka HW42)’s PGP signature

Source: qsb-110-2026.txt.sig.simon

What is the purpose of this announcement?

The purpose of this announcement is to inform the Qubes community that a new Qubes security bulletin (QSB) has been published.

What is a Qubes security bulletin (QSB)?

A Qubes security bulletin (QSB) is a security announcement issued by the Qubes security team. A QSB typically provides a summary and impact analysis of one or more recently-discovered software vulnerabilities, including details about patching to address them.

Why should I care about QSBs?

QSBs tell you what actions you must take in order to protect yourself from recently-discovered security vulnerabilities. In most cases, security vulnerabilities are addressed by updating normally. However, in some cases, special user action is required. In all cases, the required actions are detailed in QSBs.

What are the PGP signatures that accompany QSBs?

A PGP signature is a cryptographic digital signature made in accordance with the OpenPGP standard. PGP signatures can be cryptographically verified with programs like GNU Privacy Guard (GPG). The Qubes security team cryptographically signs all QSBs so that Qubes users have a reliable way to check whether QSBs are genuine. The only way to be certain that a QSB is authentic is by verifying its PGP signatures.

Why should I care whether a QSB is authentic?

A forged QSB could deceive you into taking actions that adversely affect the security of your Qubes OS system, such as installing malware or making configuration changes that render your system vulnerable to attack. Falsified QSBs could sow fear, uncertainty, and doubt about the security of Qubes OS or the status of the Qubes OS Project.

How do I verify the PGP signatures on a QSB?

The following command-line instructions assume a Linux system with git and gpg installed. (For Windows and Mac options, see OpenPGP software.)

Obtain the Qubes Master Signing Key (QMSK), e.g.:

$ gpg --fetch-keys https://keys.qubes-os.org/keys/qubes-master-signing-key.asc
gpg: directory '/home/user/.gnupg' created
gpg: keybox '/home/user/.gnupg/pubring.kbx' created
gpg: requesting key from 'https://keys.qubes-os.org/keys/qubes-master-signing-key.asc'
gpg: /home/user/.gnupg/trustdb.gpg: trustdb created
gpg: key DDFA1A3E36879494: public key "Qubes Master Signing Key" imported
gpg: Total number processed: 1
gpg:               imported: 1

(For more ways to obtain the QMSK, see How to import and authenticate the Qubes Master Signing Key.)

View the fingerprint of the PGP key you just imported. (Note: gpg> indicates a prompt inside of the GnuPG program. Type what appears after it when prompted.)

$ gpg --edit-key 0x427F11FD0FAA4B080123F01CDDFA1A3E36879494
gpg (GnuPG) 2.2.27; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
   
   
pub  rsa4096/DDFA1A3E36879494
     created: 2010-04-01  expires: never       usage: SC
     trust: unknown       validity: unknown
[ unknown] (1). Qubes Master Signing Key
   
gpg> fpr
pub   rsa4096/DDFA1A3E36879494 2010-04-01 Qubes Master Signing Key
 Primary key fingerprint: 427F 11FD 0FAA 4B08 0123  F01C DDFA 1A3E 3687 9494

Important: At this point, you still don’t know whether the key you just imported is the genuine QMSK or a forgery. In order for this entire procedure to provide meaningful security benefits, you must authenticate the QMSK out-of-band. Do not skip this step! The standard method is to obtain the QMSK fingerprint from multiple independent sources in several different ways and check to see whether they match the key you just imported. For more information, see How to import and authenticate the Qubes Master Signing Key.

Tip: After you have authenticated the QMSK out-of-band to your satisfaction, record the QMSK fingerprint in a safe place (or several) so that you don’t have to repeat this step in the future.

Once you are satisfied that you have the genuine QMSK, set its trust level to 5 (“ultimate”), then quit GnuPG with q.

gpg> trust
pub  rsa4096/DDFA1A3E36879494
     created: 2010-04-01  expires: never       usage: SC
     trust: unknown       validity: unknown
[ unknown] (1). Qubes Master Signing Key
   
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)
   
  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  5 = I trust ultimately
  m = back to the main menu
   
Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y
   
pub  rsa4096/DDFA1A3E36879494
     created: 2010-04-01  expires: never       usage: SC
     trust: ultimate      validity: unknown
[ unknown] (1). Qubes Master Signing Key
Please note that the shown key validity is not necessarily correct
unless you restart the program.
   
gpg> q

Use Git to clone the qubes-secpack repo.

$ git clone https://github.com/QubesOS/qubes-secpack.git
Cloning into 'qubes-secpack'...
remote: Enumerating objects: 4065, done.
remote: Counting objects: 100% (1474/1474), done.
remote: Compressing objects: 100% (742/742), done.
remote: Total 4065 (delta 743), reused 1413 (delta 731), pack-reused 2591
Receiving objects: 100% (4065/4065), 1.64 MiB | 2.53 MiB/s, done.
Resolving deltas: 100% (1910/1910), done.

Import the included PGP keys. (See our PGP key policies for important information about these keys.)

$ gpg --import qubes-secpack/keys/*/*
gpg: key 063938BA42CFA724: public key "Marek Marczykowski-Górecki (Qubes OS signing key)" imported
gpg: qubes-secpack/keys/core-devs/retired: read error: Is a directory
gpg: no valid OpenPGP data found.
gpg: key 8C05216CE09C093C: 1 signature not checked due to a missing key
gpg: key 8C05216CE09C093C: public key "HW42 (Qubes Signing Key)" imported
gpg: key DA0434BC706E1FCF: public key "Simon Gaiser (Qubes OS signing key)" imported
gpg: key 8CE137352A019A17: 2 signatures not checked due to missing keys
gpg: key 8CE137352A019A17: public key "Andrew David Wong (Qubes Documentation Signing Key)" imported
gpg: key AAA743B42FBC07A9: public key "Brennan Novak (Qubes Website & Documentation Signing)" imported
gpg: key B6A0BB95CA74A5C3: public key "Joanna Rutkowska (Qubes Documentation Signing Key)" imported
gpg: key F32894BE9684938A: public key "Marek Marczykowski-Górecki (Qubes Documentation Signing Key)" imported
gpg: key 6E7A27B909DAFB92: public key "Hakisho Nukama (Qubes Documentation Signing Key)" imported
gpg: key 485C7504F27D0A72: 1 signature not checked due to a missing key
gpg: key 485C7504F27D0A72: public key "Sven Semmler (Qubes Documentation Signing Key)" imported
gpg: key BB52274595B71262: public key "unman (Qubes Documentation Signing Key)" imported
gpg: key DC2F3678D272F2A8: 1 signature not checked due to a missing key
gpg: key DC2F3678D272F2A8: public key "Wojtek Porczyk (Qubes OS documentation signing key)" imported
gpg: key FD64F4F9E9720C4D: 1 signature not checked due to a missing key
gpg: key FD64F4F9E9720C4D: public key "Zrubi (Qubes Documentation Signing Key)" imported
gpg: key DDFA1A3E36879494: "Qubes Master Signing Key" not changed
gpg: key 1848792F9E2795E9: public key "Qubes OS Release 4 Signing Key" imported
gpg: qubes-secpack/keys/release-keys/retired: read error: Is a directory
gpg: no valid OpenPGP data found.
gpg: key D655A4F21830E06A: public key "Marek Marczykowski-Górecki (Qubes security pack)" imported
gpg: key ACC2602F3F48CB21: public key "Qubes OS Security Team" imported
gpg: qubes-secpack/keys/security-team/retired: read error: Is a directory
gpg: no valid OpenPGP data found.
gpg: key 4AC18DE1112E1490: public key "Simon Gaiser (Qubes Security Pack signing key)" imported
gpg: Total number processed: 17
gpg:               imported: 16
gpg:              unchanged: 1
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   6  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:   6  signed:   0  trust: 6-, 0q, 0n, 0m, 0f, 0u

Verify signed Git tags.

$ cd qubes-secpack/
$ git tag -v `git describe`
object 266e14a6fae57c9a91362c9ac784d3a891f4d351
type commit
tag marmarek_sec_266e14a6
tagger Marek Marczykowski-Górecki 1677757924 +0100
   
Tag for commit 266e14a6fae57c9a91362c9ac784d3a891f4d351
gpg: Signature made Thu 02 Mar 2023 03:52:04 AM PST
gpg:                using RSA key 2D1771FE4D767EDC76B089FAD655A4F21830E06A
gpg: Good signature from "Marek Marczykowski-Górecki (Qubes security pack)" [full]

The exact output will differ, but the final line should always start with gpg: Good signature from... followed by an appropriate key. The [full] indicates full trust, which this key inherits in virtue of being validly signed by the QMSK.

Verify PGP signatures, e.g.:

$ cd QSBs/
$ gpg --verify qsb-087-2022.txt.sig.marmarek qsb-087-2022.txt
gpg: Signature made Wed 23 Nov 2022 04:05:51 AM PST
gpg:                using RSA key 2D1771FE4D767EDC76B089FAD655A4F21830E06A
gpg: Good signature from "Marek Marczykowski-Górecki (Qubes security pack)" [full]
$ gpg --verify qsb-087-2022.txt.sig.simon qsb-087-2022.txt
gpg: Signature made Wed 23 Nov 2022 03:50:42 AM PST
gpg:                using RSA key EA18E7F040C41DDAEFE9AA0F4AC18DE1112E1490
gpg: Good signature from "Simon Gaiser (Qubes Security Pack signing key)" [full]
$ cd ../canaries/
$ gpg --verify canary-034-2023.txt.sig.marmarek canary-034-2023.txt
gpg: Signature made Thu 02 Mar 2023 03:51:48 AM PST
gpg:                using RSA key 2D1771FE4D767EDC76B089FAD655A4F21830E06A
gpg: Good signature from "Marek Marczykowski-Górecki (Qubes security pack)" [full]
$ gpg --verify canary-034-2023.txt.sig.simon canary-034-2023.txt
gpg: Signature made Thu 02 Mar 2023 01:47:52 AM PST
gpg:                using RSA key EA18E7F040C41DDAEFE9AA0F4AC18DE1112E1490
gpg: Good signature from "Simon Gaiser (Qubes Security Pack signing key)" [full]

Again, the exact output will differ, but the final line of output from each gpg --verify command should always start with gpg: Good signature from... followed by an appropriate key.

For this announcement (QSB-110), the commands are:

$ gpg --verify qsb-110-2026.txt.sig.marmarek qsb-110-2026.txt
$ gpg --verify qsb-110-2026.txt.sig.simon qsb-110-2026.txt

You can also verify the signatures directly from this announcement in addition to or instead of verifying the files from the qubes-secpack. Simply copy and paste the QSB-110 text into a plain text file and do the same for both signature files. Then, perform the same authentication steps as listed above, substituting the filenames above with the names of the files you just created.

Purism PureOS: PureOS Crimson Development Report: January and February 2026 – Beta Released

Purism — 2026-03-16T20:30:40+00:00

We are very pleased to announce that the PureOS Crimson beta is released! This means that we have a new set of install images for all devices - Librem 5, Librem 11, servers, and PCs - and we have a path to upgrade existing installations from Byzantium.

The post PureOS Crimson Development Report: January and February 2026 – Beta Released appeared first on Purism.

GreenboneOS: Peacocks and crows in IT security

Greenbone AG — 2026-03-16T07:43:33+00:00

A field report on open source, competition, enforcement of rights, and the question of how to defend a fair and sustainable open source ecosystem. Summary This report describes a real case of misuse of open source software using the example of OPENVAS, the open source vulnerability management system we developed. A market participant had systematically […]

Qubes: Fedora 43 templates available for Qubes OS 4.2

Qubes — 2026-03-16T00:00:00+00:00

The following new Fedora 43 templates are now available for Qubes OS 4.2:

fedora-43-xfce (default Fedora template with the Xfce desktop environment)
fedora-43 (alternative Fedora template with the GNOME desktop environment)
fedora-43-minimal (minimal template for advanced users)

Note: These templates have already been released for Qubes OS 4.3.

There are two ways to upgrade a template to a new Fedora release:

Recommended: Install a fresh template to replace an existing one. This option is simpler for less experienced users, but it won’t preserve any modifications you’ve made to your template. After you install the new template, you’ll have to redo your desired template modifications (if any) and switch everything that was set to the old template to the new template. If you choose to modify your template, you may wish to write those modifications down so that you remember what to redo on each fresh install. To see a log of package manager actions, open a terminal in the template and use the dnf history command.
Advanced: Perform an in-place upgrade of an existing Fedora template. This option will preserve any modifications you’ve made to the template, but it may be more complicated for less experienced users.

Note: No user action is required regarding the OS version in dom0 (see our note on dom0 and EOL).

SparkyLinux: Sparky 2026.03

pavroo — 2026-03-15T16:57:58+00:00

New SparkyLinux 2026.03 “Tiamat” ISO images are available of the semi-rolling line. This release is based on the Debian testing “Forky”. Main changes: – Packages updated from Debian and Sparky testing repositories as of March 14, 2026 – Linux kernel 6.19.6 (7.0-rc3, 6.19.8, 6.18.18-LTS, 6.12.77-LTS in Sparky repositories) – Firefox 140.8.0esr (148.0.2-latest in Sparky repositories) …

Source

Xanadu developers: Ubuntu en Modo Congelado Cambios que desaparecen al reiniciar

Jesus Palencia — 2026-03-14T17:13:18+00:00

Pardus: Bilim ve Teknoloji Haftası’nda Genç Bilişim Ekosistemi ile Bir Araya Geldik

Hace İbrahim Özbal — 2026-03-13T11:00:00+00:00

Bilim ve Teknoloji Haftası kapsamında MEB YEĞİTEK ETKİM ve TÜBİTAK BİLGEM YTE iş birliğiyle düzenlenen programda, Genç Bilişim Ekosistemi öğrencileriyle bir araya gelerek açık kaynak ve özgür yazılım dünyasını paylaştık. Pardus ekibi olarak, genç yeteneklerin yerli teknolojilerle tanıştığı ve sektör uzmanlarıyla doğrudan etkileşim kurduğu bu inovasyon dolu buluşmanın parçası olmaktan büyük mutluluk duyuyoruz.

Deepin: (中文) 告别熬夜憋稿！UOS AI 写作重磅上线，每个字都长在需求上

xiaofei — 2026-03-13T02:58:41+00:00

Sorry, this entry is only available in 中文.

Qubes: Fedora 42 approaching end of life

Qubes — 2026-03-13T00:00:00+00:00

Fedora 42 is currently scheduled to reach end of life (EOL) on 2026-05-13 (two months from the date of this announcement). Please upgrade all of your Fedora templates and standalones by that date. For more information, see Upgrading to avoid EOL.

There are two ways to upgrade a template to a new Fedora release:

Recommended: Install a new template to replace an existing one. This option is simpler for less experienced users, but it won’t preserve any modifications you’ve made to your template. After you install the new template, you’ll have to redo your desired template modifications (if any) and switch everything that was set to the old template to the new template. If you choose to modify your template, you may wish to write those modifications down so that you remember what to redo on each fresh install. To see a log of package manager actions, open a terminal in the old Fedora template and use the dnf history command.
Advanced: Perform an in-place upgrade of an existing Fedora template. This option will preserve any modifications you’ve made to the template, but it may be more complicated for less experienced users.

Please note that no user action is required regarding the OS version in dom0 (see our note on dom0 and EOL).

Qubes: Qubes Canary 046

Qubes — 2026-03-13T00:00:00+00:00

We have published Qubes Canary 046. The text of this canary and its accompanying cryptographic signatures are reproduced below. For an explanation of this announcement and instructions for authenticating this canary, please see the end of this announcement.

Qubes Canary 046

                    ---===[ Qubes Canary 046 ]===---


Statements
-----------

The Qubes security team members who have digitally signed this file [1]
state the following:

1. The date of issue of this canary is March 12, 2026.

2. There have been 109 Qubes security bulletins published so far.

3. The Qubes Master Signing Key fingerprint is:

       427F 11FD 0FAA 4B08 0123  F01C DDFA 1A3E 3687 9494

4. No warrants have ever been served to us with regard to the Qubes OS
   Project (e.g. to hand out the private signing keys or to introduce
   backdoors).

5. We plan to publish the next of these canary statements in the first
   fourteen days of June 2026. Special note should be taken if no new
   canary is published by that time or if the list of statements changes
   without plausible explanation.


Special announcements
----------------------

None.


Disclaimers and notes
----------------------

We would like to remind you that Qubes OS has been designed under the
assumption that all relevant infrastructure is permanently compromised.
This means that we assume NO trust in any of the servers or services
which host or provide any Qubes-related data, in particular, software
updates, source code repositories, and Qubes ISO downloads.

This canary scheme is not infallible. Although signing the declaration
makes it very difficult for a third party to produce arbitrary
declarations, it does not prevent them from using force or other means,
like blackmail or compromising the signers' laptops, to coerce us to
produce false declarations.

The proof of freshness provided below serves to demonstrate that this
canary could not have been created prior to the date stated. It shows
that a series of canaries was not created in advance.

This declaration is merely a best effort and is provided without any
guarantee or warranty. It is not legally binding in any way to anybody.
None of the signers should be ever held legally responsible for any of
the statements made here.


Proof of freshness
-------------------

Thu, 12 Mar 2026 11:22:20 +0000

Source: DER SPIEGEL - International (https://www.spiegel.de/international/index.rss)
Insta, TikTok and Co.: Is Australia's Social Media Ban for Children Actually Working?
"Reckless, Suicidal Race": The Deadly Threat Posed by Artificial Intelligence
Portrait of a City after Four Years of War: The Courage of Kyiv
U.S. Historian Robert Kagan: "We Are Watching a Country Fall Under Dictatorship Almost Without Resistance"
Nord Stream: How Early Did the CIA Know about the Pipeline Attack?

Source: NYT > World News (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
Iran War Live Updates: Iraq Closes Oil Terminals Amid Growing Disruption to Global Supplies
Trump’s Iran War Is Causing Problems For His Ally in Italy, Giorgia Meloni
How Russia’s Scorched-Earth Attacks Put Ukraine’s Power Grid Near Collapse
China Wants Its Ethnic Minorities to Blend In. Now It’s the Law.
At China’s Big Political Meeting, a Rare Debate About Inequality

Source: BBC News (https://feeds.bbci.co.uk/news/world/rss.xml)
China approves 'ethnic unity' law requiring minorities to learn Mandarin
Epstein used modelling agent to recruit girls, Brazilian women tell BBC
War in Ukraine spills into Hungarian election campaign
Noma head chef resigns from restaurant amid abuse allegations
Hozier, Jessie Buckley and Bruce Springsteen record Shane MacGowan tribute album

Source: Blockchain.info
000000000000000000017245ca11dddd962050ba2ce7fb38f0ab6a10d4a9cf00


Footnotes
----------

[1] This file should be signed in two ways: (1) via detached PGP
signatures by each of the signers, distributed together with this canary
in the qubes-secpack.git repo, and (2) via digital signatures on the
corresponding qubes-secpack.git repo tags. [2]

[2] Don't just trust the contents of this file blindly! Verify the
digital signatures! Instructions for doing so are documented here:
https://www.qubes-os.org/security/pack/

--
The Qubes Security Team
https://www.qubes-os.org/security/

Source: canary-046-2026.txt

Marek Marczykowski-Górecki’s PGP signature

Source: canary-046-2026.txt.sig.marmarek

Simon Gaiser (aka HW42)’s PGP signature

Source: canary-046-2026.txt.sig.simon

What is the purpose of this announcement?

The purpose of this announcement is to inform the Qubes community that a new Qubes canary has been published.

What is a Qubes canary?

A Qubes canary is a security announcement periodically issued by the Qubes security team consisting of several statements to the effect that the signers of the canary have not been compromised. The idea is that, as long as signed canaries including such statements continue to be published, all is well. However, if the canaries should suddenly cease, if one or more signers begin declining to sign them, or if the included statements change significantly without plausible explanation, then this may indicate that something has gone wrong.

The name originates from the practice in which miners would bring caged canaries into coal mines. If the level of methane gas in the mine reached a dangerous level, the canary would die, indicating to miners that they should evacuate. (See the Wikipedia article on warrant canaries for more information, but bear in mind that Qubes Canaries are not strictly limited to legal warrants.)

Why should I care about canaries?

Canaries provide an important indication about the security status of the project. If the canary is healthy, it’s a strong sign that things are running normally. However, if the canary is unhealthy, it could mean that the project or its members are being coerced in some way.

What are some signs of an unhealthy canary?

Here is a non-exhaustive list of examples:

Dead canary. In each canary, we state a window of time during which you should expect the next canary to be published. If no canary is published within that window of time and no good explanation is provided for missing the deadline, then the canary has died.
Missing statement(s). Canaries include a set of numbered statements at the top. These statements are generally the same across canaries, except for specific numbers and dates that have changed since the previous canary. If an important statement was present in older canaries but suddenly goes missing from new canaries with no correction or explanation, then this may be an indication that the signers can no longer truthfully make that statement.
Missing signature(s). Qubes canaries are signed by the members of the Qubes security team (see below). If one of them has been signing all canaries but suddenly and permanently stops signing new canaries without any explanation, then this may indicate that this person is under duress or can no longer truthfully sign the statements contained in the canary.

No, there are many canary-related possibilities that should not worry you. Here is a non-exhaustive list of examples:

Unusual reposts. The only canaries that matter are the ones that are validly signed in the Qubes security pack (qubes-secpack). Reposts of canaries (like the one in this announcement) do not have any authority (except insofar as they reproduce validly-signed text from the qubes-secpack). If the actual canary in the qubes-secpack is healthy, but reposts are late, absent, or modified on the website, mailing lists, forum, or social media platforms, you should not be concerned about the canary.
Last-minute signature(s). If the canary is signed at the last minute but before the deadline, that’s okay. (People get busy and procrastinate sometimes.)
Signatures at different times. If one signature is earlier or later than the other, but both are present within a reasonable period of time, that’s okay. (For example, sometimes one signer is out of town, but we try to plan the deadlines around this.)
Permitted changes. If something about a canary changes without violating any of the statements in prior canaries, that’s okay. (For example, canaries are usually scheduled for the first fourteen days of a given month, but there’s no rule that says they have to be.)
Unusual but planned changes. If something unusual happens, but it was announced in advance, and the appropriate statements are signed, that’s okay (e.g., when Joanna left the security team and Simon joined it).

In general, it would not be realistic for an organization to exist that never changed, had zero turnover, and never made mistakes. Therefore, it would be reasonable to expect such events to occur periodically, and it would be unreasonable to regard every unusual or unexpected canary-related event as a sign of compromise. For example, if something usual happens with a canary, and we say it was a mistake and correct it (with valid signatures), you will have to decide for yourself whether it’s more likely that it really was just a mistake or that something is wrong and that this is how we chose to send you a subtle signal about it. This will require you to think carefully about which among many possible scenarios is most likely given the evidence available to you. Since this is fundamentally a matter of judgment, canaries are ultimately a social scheme, not a technical one.

What are the PGP signatures that accompany canaries?

A PGP signature is a cryptographic digital signature made in accordance with the OpenPGP standard. PGP signatures can be cryptographically verified with programs like GNU Privacy Guard (GPG). The Qubes security team cryptographically signs all canaries so that Qubes users have a reliable way to check whether canaries are genuine. The only way to be certain that a canary is authentic is by verifying its PGP signatures.

Why should I care whether a canary is authentic?

If you fail to notice that a canary is unhealthy or has died, you may continue to trust the Qubes security team even after they have signaled via the canary (or lack thereof) that they been compromised or coerced.

Alternatively, an adversary could fabricate a canary in an attempt to deceive the public. Such a canary would not be validly signed, but users who neglect to check the signatures on the fake canary would not be aware of this, so they may mistakenly believe it to be genuine, especially if it closely mimics the language of authentic canaries. Such falsified canaries could include manipulated text designed to sow fear, uncertainty, and doubt about the security of Qubes OS or the status of the Qubes OS Project.

How do I verify the PGP signatures on a canary?

The following command-line instructions assume a Linux system with git and gpg installed. (For Windows and Mac options, see OpenPGP software.)

Obtain the Qubes Master Signing Key (QMSK), e.g.:

$ gpg --fetch-keys https://keys.qubes-os.org/keys/qubes-master-signing-key.asc
gpg: directory '/home/user/.gnupg' created
gpg: keybox '/home/user/.gnupg/pubring.kbx' created
gpg: requesting key from 'https://keys.qubes-os.org/keys/qubes-master-signing-key.asc'
gpg: /home/user/.gnupg/trustdb.gpg: trustdb created
gpg: key DDFA1A3E36879494: public key "Qubes Master Signing Key" imported
gpg: Total number processed: 1
gpg:               imported: 1

(For more ways to obtain the QMSK, see How to import and authenticate the Qubes Master Signing Key.)

View the fingerprint of the PGP key you just imported. (Note: gpg> indicates a prompt inside of the GnuPG program. Type what appears after it when prompted.)

$ gpg --edit-key 0x427F11FD0FAA4B080123F01CDDFA1A3E36879494
gpg (GnuPG) 2.2.27; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
   
   
pub  rsa4096/DDFA1A3E36879494
     created: 2010-04-01  expires: never       usage: SC
     trust: unknown       validity: unknown
[ unknown] (1). Qubes Master Signing Key
   
gpg> fpr
pub   rsa4096/DDFA1A3E36879494 2010-04-01 Qubes Master Signing Key
 Primary key fingerprint: 427F 11FD 0FAA 4B08 0123  F01C DDFA 1A3E 3687 9494

Important: At this point, you still don’t know whether the key you just imported is the genuine QMSK or a forgery. In order for this entire procedure to provide meaningful security benefits, you must authenticate the QMSK out-of-band. Do not skip this step! The standard method is to obtain the QMSK fingerprint from multiple independent sources in several different ways and check to see whether they match the key you just imported. For more information, see How to import and authenticate the Qubes Master Signing Key.

Tip: After you have authenticated the QMSK out-of-band to your satisfaction, record the QMSK fingerprint in a safe place (or several) so that you don’t have to repeat this step in the future.

Once you are satisfied that you have the genuine QMSK, set its trust level to 5 (“ultimate”), then quit GnuPG with q.

gpg> trust
pub  rsa4096/DDFA1A3E36879494
     created: 2010-04-01  expires: never       usage: SC
     trust: unknown       validity: unknown
[ unknown] (1). Qubes Master Signing Key
   
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)
   
  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  5 = I trust ultimately
  m = back to the main menu
   
Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y
   
pub  rsa4096/DDFA1A3E36879494
     created: 2010-04-01  expires: never       usage: SC
     trust: ultimate      validity: unknown
[ unknown] (1). Qubes Master Signing Key
Please note that the shown key validity is not necessarily correct
unless you restart the program.
   
gpg> q

Use Git to clone the qubes-secpack repo.

$ git clone https://github.com/QubesOS/qubes-secpack.git
Cloning into 'qubes-secpack'...
remote: Enumerating objects: 4065, done.
remote: Counting objects: 100% (1474/1474), done.
remote: Compressing objects: 100% (742/742), done.
remote: Total 4065 (delta 743), reused 1413 (delta 731), pack-reused 2591
Receiving objects: 100% (4065/4065), 1.64 MiB | 2.53 MiB/s, done.
Resolving deltas: 100% (1910/1910), done.

Import the included PGP keys. (See our PGP key policies for important information about these keys.)

$ gpg --import qubes-secpack/keys/*/*
gpg: key 063938BA42CFA724: public key "Marek Marczykowski-Górecki (Qubes OS signing key)" imported
gpg: qubes-secpack/keys/core-devs/retired: read error: Is a directory
gpg: no valid OpenPGP data found.
gpg: key 8C05216CE09C093C: 1 signature not checked due to a missing key
gpg: key 8C05216CE09C093C: public key "HW42 (Qubes Signing Key)" imported
gpg: key DA0434BC706E1FCF: public key "Simon Gaiser (Qubes OS signing key)" imported
gpg: key 8CE137352A019A17: 2 signatures not checked due to missing keys
gpg: key 8CE137352A019A17: public key "Andrew David Wong (Qubes Documentation Signing Key)" imported
gpg: key AAA743B42FBC07A9: public key "Brennan Novak (Qubes Website & Documentation Signing)" imported
gpg: key B6A0BB95CA74A5C3: public key "Joanna Rutkowska (Qubes Documentation Signing Key)" imported
gpg: key F32894BE9684938A: public key "Marek Marczykowski-Górecki (Qubes Documentation Signing Key)" imported
gpg: key 6E7A27B909DAFB92: public key "Hakisho Nukama (Qubes Documentation Signing Key)" imported
gpg: key 485C7504F27D0A72: 1 signature not checked due to a missing key
gpg: key 485C7504F27D0A72: public key "Sven Semmler (Qubes Documentation Signing Key)" imported
gpg: key BB52274595B71262: public key "unman (Qubes Documentation Signing Key)" imported
gpg: key DC2F3678D272F2A8: 1 signature not checked due to a missing key
gpg: key DC2F3678D272F2A8: public key "Wojtek Porczyk (Qubes OS documentation signing key)" imported
gpg: key FD64F4F9E9720C4D: 1 signature not checked due to a missing key
gpg: key FD64F4F9E9720C4D: public key "Zrubi (Qubes Documentation Signing Key)" imported
gpg: key DDFA1A3E36879494: "Qubes Master Signing Key" not changed
gpg: key 1848792F9E2795E9: public key "Qubes OS Release 4 Signing Key" imported
gpg: qubes-secpack/keys/release-keys/retired: read error: Is a directory
gpg: no valid OpenPGP data found.
gpg: key D655A4F21830E06A: public key "Marek Marczykowski-Górecki (Qubes security pack)" imported
gpg: key ACC2602F3F48CB21: public key "Qubes OS Security Team" imported
gpg: qubes-secpack/keys/security-team/retired: read error: Is a directory
gpg: no valid OpenPGP data found.
gpg: key 4AC18DE1112E1490: public key "Simon Gaiser (Qubes Security Pack signing key)" imported
gpg: Total number processed: 17
gpg:               imported: 16
gpg:              unchanged: 1
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   6  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:   6  signed:   0  trust: 6-, 0q, 0n, 0m, 0f, 0u

Verify signed Git tags.

$ cd qubes-secpack/
$ git tag -v `git describe`
object 266e14a6fae57c9a91362c9ac784d3a891f4d351
type commit
tag marmarek_sec_266e14a6
tagger Marek Marczykowski-Górecki 1677757924 +0100
   
Tag for commit 266e14a6fae57c9a91362c9ac784d3a891f4d351
gpg: Signature made Thu 02 Mar 2023 03:52:04 AM PST
gpg:                using RSA key 2D1771FE4D767EDC76B089FAD655A4F21830E06A
gpg: Good signature from "Marek Marczykowski-Górecki (Qubes security pack)" [full]

Verify PGP signatures, e.g.:

$ cd QSBs/
$ gpg --verify qsb-087-2022.txt.sig.marmarek qsb-087-2022.txt
gpg: Signature made Wed 23 Nov 2022 04:05:51 AM PST
gpg:                using RSA key 2D1771FE4D767EDC76B089FAD655A4F21830E06A
gpg: Good signature from "Marek Marczykowski-Górecki (Qubes security pack)" [full]
$ gpg --verify qsb-087-2022.txt.sig.simon qsb-087-2022.txt
gpg: Signature made Wed 23 Nov 2022 03:50:42 AM PST
gpg:                using RSA key EA18E7F040C41DDAEFE9AA0F4AC18DE1112E1490
gpg: Good signature from "Simon Gaiser (Qubes Security Pack signing key)" [full]
$ cd ../canaries/
$ gpg --verify canary-034-2023.txt.sig.marmarek canary-034-2023.txt
gpg: Signature made Thu 02 Mar 2023 03:51:48 AM PST
gpg:                using RSA key 2D1771FE4D767EDC76B089FAD655A4F21830E06A
gpg: Good signature from "Marek Marczykowski-Górecki (Qubes security pack)" [full]
$ gpg --verify canary-034-2023.txt.sig.simon canary-034-2023.txt
gpg: Signature made Thu 02 Mar 2023 01:47:52 AM PST
gpg:                using RSA key EA18E7F040C41DDAEFE9AA0F4AC18DE1112E1490
gpg: Good signature from "Simon Gaiser (Qubes Security Pack signing key)" [full]

Again, the exact output will differ, but the final line of output from each gpg --verify command should always start with gpg: Good signature from... followed by an appropriate key.

For this announcement (Qubes Canary 046), the commands are:

$ gpg --verify canary-046-2026.txt.sig.marmarek canary-046-2026.txt
$ gpg --verify canary-046-2026.txt.sig.simon canary-046-2026.txt

You can also verify the signatures directly from this announcement in addition to or instead of verifying the files from the qubes-secpack. Simply copy and paste the Qubes Canary 046 text into a plain text file and do the same for both signature files. Then, perform the same authentication steps as listed above, substituting the filenames above with the names of the files you just created.

Univention Corporate Server: Univention Nubus Brings Applications to Users

Ingo Steuwer — 2026-03-12T15:34:56+00:00

The classic IAM task – simple, secure, and centrally managed

Almost every organization faces the same challenge: employees work with a wide variety of applications – specialized software, collaboration tools, cloud services, and internal systems. Access should be as simple as possible for users, while the organization needs control over who can access which data and services.

This is exactly where Identity & Access Management (IAM) comes in. With Univention Nubus, applications and users can be connected centrally – securely, conveniently, and scalably.

Starting Point: Many Applications, Many Users – Many Requirements

The needs of users and organizations may initially seem contradictory, but a well-designed IAM can bring them together:

Users want:

A single account instead of multiple login credentials
Fast, seamless access to all applications
A clear interface to quickly find the tools they need

Organizations require:

Freedom to choose their applications
Control over access and permissions
Secure authentication, ideally with two-factor authentication (2FA)
Transparent and traceable processes for onboarding and offboarding users

IAM as a “Single Source of Truth”

The foundation of a functional IAM is a central location where all identities and permissions are managed – the so-called Single Source of Truth.

In Nubus, this role is fulfilled by the central directory, which manages:

Identities
Groups and roles
Access rights
Authentication methods (passwords, 2FA, etc.)

At the same time, IAM covers the user lifecycle:
It controls who joins the organization, who leaves, and what changes are made to accounts and permissions. New employees automatically receive the appropriate access, role changes take effect immediately, and access is reliably revoked when someone leaves. This prevents orphaned accounts or uncontrolled permissions.

Application Integration: SSO and User Lifecycle

An IAM only realizes its full potential when applications are seamlessly integrated. Nubus relies consistently on open and established standards.

Single Sign-on (SSO)
SSO allows users to log in once and then access multiple applications. Depending on the type of application, different methods are used:

Kerberos for intranet applications
OpenID Connect (OIDC) or SAML for web applications

In practice, this means one login in the morning is enough to access all relevant systems throughout the workday – without repeated password prompts. This not only improves convenience but also significantly reduces password issues and support requests.

User Lifecycle Integration
Beyond login, managing user accounts in connected applications is crucial. Nubus supports both common models:

Pull mechanisms, where applications retrieve user data from the directory service (e.g., via LDAP)
Push mechanisms, where accounts are actively provisioned in target systems (e.g., via APIs like SCIM)

Open interfaces are a core principle: they are documented, freely usable, and widely adopted. This allows organizations to flexibly integrate new applications and continue using existing systems.

Groups serve as the unifying element, representing the smallest common denominator for roles and permissions. Once defined, groups can be consistently used across multiple applications – providing clarity and reducing complexity.

User Convenience: Easy Access and Clear Overview

For end users, the benefits of IAM are most apparent in daily work. Instead of dealing with multiple credentials and entry points, they experience a consistent and easy-to-understand environment.

With seamless Single Sign-on, repeated logins are eliminated. Applications open directly, without additional hurdles. This saves time and reduces frustration – especially with frequently used systems.

This is complemented by a central web portal displaying all available applications and services in a clear overview. Users don’t have to remember which application serves which purpose or how to access it. Instead, all relevant tools are available in one place – structured, quickly accessible, and tailored to their role.

Especially in organizations with many specialized applications, this results in a significantly better user experience and higher acceptance of the IT environment.

Efficient Administration: Automated and User-Friendly

In addition to the user perspective, the administrative side is also crucial. An IAM must be powerful but also efficient to operate daily.

With Nubus, repetitive tasks can be automated – such as creating new users, assigning groups, or revoking permissions. Through interfaces like the UDM REST API, these processes can be integrated into existing HR or ITSM systems.

At the same time, an intuitive web interface is available for everyday work. Administrators can manage user accounts, adjust permissions, or configure two-factor authentication.

This combination of automation and a user-friendly interface ensures that both large organizations with many users and smaller IT teams can work efficiently.

Extensibility and Integration: Open and Future-Proof

IT environments are continuously evolving – new applications are added, others retired. An IAM must therefore be flexible and extensible.

Nubus relies on standardized APIs and open integration mechanisms. New applications can be connected systematically without proprietary interfaces or costly custom development.

Pre-packaged integrations for widely used applications are particularly helpful. They allow a fast start, as many typical configuration steps are already prepared. Organizations can quickly generate value and gradually integrate their existing application landscape.

Through automation and standardization, the environment remains manageable even as it grows.

Result: Control for Organizations, Convenience for Users

Ultimately, both the organization and its users benefit significantly from a central IAM with Nubus.

For organizations, this means:

Transparency and control: knowing who has access to which systems, managing permissions, and reliably meeting security requirements
Reduced administrative effort through automated processes

For users, this means:

A simplified work environment: one account, one login, one central entry point
Quick access to applications that work seamlessly together

This creates an IT environment that is both secure and user-friendly – a key foundation for productive work.

Conclusion

Connecting applications and users is the classic task of IAM – and one of the central prerequisites for a modern, high-performance IT infrastructure.

With Univention Nubus, this task can be implemented holistically:
A central “Single Source of Truth,” open interfaces, integrated user lifecycle, and convenient Single Sign-On ensure that organizations retain control and users can work efficiently.

IAM thus becomes not just a security tool but a real enabler for digital collaboration.

Next Step to Central IAM

Discover how Univention Nubus brings your applications, identities, and access rights together in one platform – open, secure, and future-proof.

Learn more about Nubus now

Der Beitrag Univention Nubus Brings Applications to Users erschien zuerst auf Univention.

Deepin: deepin App Store Upgraded!

xiaofei — 2026-03-12T02:54:12+00:00

deepin, a prominent open-source operating system recognized globally with an impressive ranking on DistroWatch, consistently focuses on optimizing the desktop experience. Recently, the official App Store has completed a new round of upgrades. This all-in-one application management platform now features over 100,000 commonly used applications spanning scenarios like office work, daily life, and entertainment. These officially verified, reliable resources comprehensively meet the needs of both individual and enterprise users, ensuring safety and peace of mind. This upgrade focuses on practical features, visual experience, and bug fixes. It delivers comprehensive enhancements across operational experience, ecosystem integration, interface layout, and management efficiency, ...Read more