New High-Severity Linux Flaws: Copy Fail, Copy Fail 2, and Dirty Frag Offer Local Privilege Escalation to Root
14 May, 2026 05:03AM by Joseph Lee
14 May, 2026 05:03AM by Joseph Lee
The VyOS documentation site has carried us a long way. Sphinx + reStructuredText served the project well for years — but the world around our documentation has changed faster than our toolchain. Contributors write in Markdown. LLM coding assistants pull docs into their context windows. Reviewers expect machine-assisted feedback. AI agents need a stable, machine-readable surface to reason about VyOS configuration.
14 May, 2026 12:30AM by Yuriy Andamasov (yuriy@sentrium.io)
13 May, 2026 02:20AM by xiaofei
The Xen Project has released one or more Xen security advisories (XSAs). The security of Qubes OS is affected.
The following XSAs do affect the security of Qubes OS:
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
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.
We have published Qubes Security Bulletin (QSB) 113: AMD CPU Opcode Cache corruption (XSA-490). 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 113 ]===---
2026-05-12
AMD CPU Opcode Cache corruption (XSA-490)
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-05-12, the Xen Project published XSA-490, "x86: CPU Opcode Cache
corruption" (CVE-2025-54518) [3]:
| AMD have disclosed a potential vulnerability in certain CPUs which can
| cause instructions to execute at a higher privilege.
For more information, see AMD's "CPU OP Cache Corruption" advisory. [4]
Impact
-------
On affected systems, an attacker can attempt to exploit this
vulnerability in order to:
- escalate privileges from userspace to the kernel inside of a given
qube in order to escape sandboxes inside that qube
- compromise Qubes OS itself
Affected systems
-----------------
Only AMD Zen 2 systems are affected. Systems with other AMD
microarchitectures and systems with Intel processors are not 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-5
For Qubes 4.3, in dom0:
- Xen packages, version 4.19.4-8
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 AMD's "CPU OP Cache Corruption" advisory. [4]
References
-----------
[1] https://doc.qubes-os.org/en/latest/user/how-to-guides/how-to-update.html
[2] https://doc.qubes-os.org/en/latest/user/downloading-installing-upgrading/testing.html
[3] https://xenbits.xen.org/xsa/advisory-490.html
[4] https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7052.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
Source: qsb-113-2026.txt
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEELRdx/k12ftx2sIn61lWk8hgw4GoFAmoEZPMACgkQ1lWk8hgw
4Gog8Q/+MhlqZQ4EfpXn0jy4qP2SOD2mk0e5gzokxhMrvENxKzBKa5h2UB/zFruU
uud72pSlvH7bP1+izHrxK5Ld+lPaK4ZVXbbyaC6Cqx09HihGLljhMl/zKELT6hi8
LzZqT3+eSPiagi58cqkRdiKOhCM+ew4TUAtoAPHSd/Wun8Ao8Cl3HZiAHlsIc1uJ
T8mHfAD7WetO24aa72g8D5s/huOLccUKIiXdDygtGJO1uTPT1uGfav5YtFYeB0nZ
y6HqFSNKC83JFHUZpP6FJqNsYn/M96Faw8G4utiV9N1Vhd8APnPU/DGSY1hE46/x
5ANuH2mIeGiuIG8pF1ucRRjLejpatN829MVxz8D8e6eI9SqprysMBi5LJw9rlihk
F31p028hlx+towv3cVHqtr/qHWAzHe7RzQce6CnKd/R0Aoj3fAhLMdgwHiKYkF4L
Fq9XpJJeQyJ9cRxs2zyLGX7XQWfb7cobP8CImL+fOaY0RxEovkKcsiyVRwcOu+OX
afAMNAGyn+EJxKwp4nF4vzvFbqAJILtuMCPfqvCMKHbUe2rnOudGsOzDps8P5+eD
5l6oDKly2NfMiIiyyjbDYuKYzE3JQlTMSbiAlYRIxaP3/yhQxM/H/hxTvtx4o6GG
9mCcc3SpWhAsp7kOJM0bkK2zZezgovQ2L6dHBlem+HpizfHvrEU=
=EDLg
-----END PGP SIGNATURE-----
Source: qsb-113-2026.txt.sig.marmarek
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE6hjn8EDEHdrv6aoPSsGN4REuFJAFAmoEXn8ACgkQSsGN4REu
FJCQRw/9FEFMx/P4GvKO5Kf4xTwuvdDasQ67hJD7D04xXNqOyiot/k4CgWQ421CI
efsecioFz0MAKqGa1cHYL44wOxAw1ot7QP5AmPvkiRVO8se0hsBepZggzB5vf50X
F+amqs3TAIcEiVlIf9PO9pgHz1oZuj0lqQBQkvD2zSwpb9oXPTIFicAndDYHkX8f
GT5iRc4tI4aVAYwnThIQWaEFxgUU8+EpspnA7hkZbz0rxx6rmNqyEY16oTt5Pu2U
6E93rcIo9+M+zmuQjkkQiN3jjJn3gukCQ7uBTHRcTrc+vUVEDii83CxDPMUlxXfj
t3MlC2Zk93Ikw7PEDaY0QqP3d0a7IjwY547rzPKzkPIyLsMMTrRktOwkKSz3BUgr
WSvjkhnSiDKaxZXf9u0/vMRzXfLsXC4+bZI78d9IewLB1bfBKeVTUTcgaLgoteLn
mjP3rueNCXXRXhhcZOEyZxfIhv+ePsFaVGSjdDFJ+B1tFz1j6rkuymOWimuqw52Z
wiCFcQJqzDoalMHvySEdrfs3FPQc7lJ2lYjs+90XXDwfNnpei1Lwtm3Zt9zTvetp
PZmZSgmvIV5WOJRSmgRMEGj46lPjJMO5h8RJAM6IVsre2ssjO/+pgcb8rYGq81LT
8cV8vbN7mk4QI6MWn5kvD+jO7fABqOLVTOZBEsWaRl1xSmfcCsg=
=zem1
-----END PGP SIGNATURE-----
Source: qsb-113-2026.txt.sig.simon
The purpose of this announcement is to inform the Qubes community that a new Qubes security bulletin (QSB) has been published.
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.
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.
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.
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.
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-113), the commands are:
$ gpg --verify qsb-113-2026.txt.sig.marmarek qsb-113-2026.txt
$ gpg --verify qsb-113-2026.txt.sig.simon qsb-113-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-113 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.
12 May, 2026 05:19AM by xiaofei
Purism exists because individual rights are no longer reliably protected by policy alone. In practice, they are determined by the design of the technology people are required to use.
The post Purism’s Product Philosophy in an Age of Government–Big Tech Convergence appeared first on Purism.
11 May, 2026 04:27PM by Purism
This release is an emergency release to fix a critical security vulnerability in the Linux kernel, as well as security vulnerabilities in Tor Browser and in the Tor client.
Update the Linux kernel to 6.12.86, which fixes Dirty Frag, a vulnerability that could allow an application in Tails to gain administration privileges.
For example, if an attacker was able to exploit other unknown security vulnerabilities in an application included in Tails, they might then use Copy Fail to take full control of your Tails and deanonymize you.
We are not aware of this vulnerability being used in practice until now.
Update Tor Browser to 15.0.12.
Update the Tor client to 0.4.9.8.
Update Thunderbird to 140.10.1.
For more details, read our changelog.
Automatic upgrades are available from Tails 7.0 or later to 7.7.3.
If you cannot do an automatic upgrade or if Tails fails to start after an automatic upgrade, please try to do a manual upgrade.
Follow our installation instructions.
The Persistent Storage on the USB stick will be lost if you install instead of upgrading.
If you don't need installation or upgrade instructions, you can download Tails 7.7.3 directly:

This week&aposs work centers on release and CI infrastructure, board and U-Boot updates, and build framework hardening.
On the release pipeline, asset manifest JSON is now emitted alongside uploads, third-party armbian-images.json sources are merged into the main download index, and dispatch chains were rewired so that build completion fans out cleanly to download-index regeneration and website sync. Ubuntu resolute (26.04) entered the daily build matrix, with corresponding prepare-host adjustments for its qemu-user packaging and a targeted blacklist for boards failing resolute plus GNOME. The new Armbian SDK images are now surfaced on the website and ship preloaded with the build framework, code-server, and developer tooling.
On the platform side, U-Boot v2026.04 lands for Helios4, Rock-5B-Plus, Rock-5T, and NanoPi-M5 (with mainline UFS via a vendor-SPL hybrid), while new bleedingedge branches were introduced for rockchip64 and meson64. Initial support arrived for the Photonicat2 board, new RK3576 SPL and RK3588 DDR blobs were added, Panthor firmware expanded to cover additional Mali GPUs, and a PCIe LTSSM timeout fix improves cold-boot NVMe detection on Rockchip. NanoPC-T6 LTS Plus was renamed, panther-x2 moved from CSC to EOS, and odroidxu4-current advanced to 6.6.138.
In the build framework, an unsafe eval was replaced with declare -g and namerefs, destructive commands were properly quoted, and Docker --privileged is now gated behind an explicit DOCKER_PRIVILEGED toggle. The desktop configuration tree migrated to the armbian-config module_desktops system, kernel build failures now propagate exit codes correctly, missing BOOT_FDT_FILE surfaces as an error alert, and SysRq-via-BREAK was restored on dw-apb-uart for mvebu-6.18 and rockchip64-7.0 kernels.
#Armbian #EmbeddedLinux #UBoot #Rockchip #SBC #LinuxKernel
bleedingedge BRANCH for rockchip64. by @EvilOlaf in armbian/build#9738bleedingedge BRANCH with 7.1-rc2. by @EvilOlaf in armbian/build#976111 May, 2026 02:23PM by Michael Robinson
There is the third update available for Sparky 8 – 8.3. This is a quarterly update of the Sparky 8 “Seven Sisters” stable release. Sparky 8 is based on and fully compatible with Debian 13 “Trixie”. Main changes: – All packages updated from the stable Debian and Sparky repositories as of May 9, 2026. – Linux kernel 6.12.86-LTS (7.0.6, 6.18.29-LTS, 6.12.87-LTS in sparky repositories) …
11 May, 2026 01:13PM by pavroo
Hi everyone,
As mentioned in my previous post, I’ve been working on a paper regarding our 3D documentation of the Similaun Mummy (Ötzi) and his equipment. During this project (conducted between 2022 and 2024), we processed DICOM data from the CT scan performed by the South Tyrol Health Care Service (Azienda Sanitaria dell'Alto Adige / Südtiroler Sanitätsbetrieb) in 2021.
To extract the CT scan metadata, Alessandro Bezzi identified an excellent FLOSS tool that worked perfectly for our needs: DCMTK.
DCMTK is a comprehensive collection of libraries and applications implementing large parts of the DICOM standard. Below, you can see a screenshot of the shell output showing the metadata of the .dcm image we analyzed.
I believe this is an incredibly useful application for anyone working in mummy studies and beyond. For this reason, I have officially added DCMTK to the ArcheOS software list, which you can find here: https://github.com/lucaarcteam/ArcheOS-software-list/blob/main/software/dicom.md.
I hope you find this useful. Have a nice day!
11 May, 2026 08:23AM by Luca Bezzi (noreply@blogger.com)
09 May, 2026 06:28AM by xiaofei
08 May, 2026 02:13AM by xiaofei
07 May, 2026 06:20AM by xiaofei
06 May, 2026 01:34PM by Joseph Lee
Debian 12 (Bookworm) is currently scheduled to reach end-of-life (EOL) on 2026-06-10 (approximately one month from the date of this announcement). Please upgrade all of your Debian 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 Debian release:
Recommended: Install a fresh template to replace the 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, see /var/log/dpkg.log and /var/log/apt/history.log in the old Debian template.
Advanced: Perform an in-place upgrade of an existing Debian template. This option will preserve any modifications you’ve made to the template, but it may be more complicated for less experienced users.
Debian releases have two EOL dates: regular and long-term support (LTS). Qubes OS support for Debian templates ends at the regular EOL date, not the LTS EOL date.

This week&aposs work centers on release pipeline modernization, desktop and userland refinements, and board and kernel platform maintenance.
On the release and CI side, the build matrix gained codename parameterisation with Ubuntu 26.04 "resolute" set as default, a dedicated Bianbu target, and exposed map overrides, while standard-support targets now include UEFI desktops and a plain cloud variant. The KDE fast-HDMI matrix was switched from kde-neon to kde-plasma, mesa-vpu was dropped from auto-attached extensions, and external CI now skips slots with a warning when upstream sources break. Supporting fixes route forky/loong64 base-files lookups to the main archive and add AI cover image generation to the blog workflow.
Desktop and userland changes focus on the Bianbu environment, where PVR DRI was enabled, detection corrected, menu entries added, systemd suspend re-enabled on K1, and gnome-initial-setup purged post-install. Broader fixes pass --allow-downgrades on pinned package installs, align LAN/WAN labels across IPv4 and IPv6 rows in the MOTD, harden console-width handling against invalid COLUMNS values, and correct output to /etc/armbian-image-release.
Platform support sees explicit ARCH=arm64 declarations on five inheriting boards, validate-board-config now following inheritance from ${SRC}/config/boards, and targeted fixes for imx8m binman hooks and rockchip family tweaks under forky (addgroup → groupadd). Kernel and DTS work restores 6.18.y on sm8550, syncs CAINIAO CNIoT-CORE DTS from 6.18 to 6.12, disables broken drm/xe patches under uefi-loong64-7.0, and improves the SMART AM40 and Retroid Pocket board definitions. AX210 firmware lands for mainline, and Seeed Studio reComputer images join the catalogue.
#Armbian #EmbeddedLinux #ARM64 #Rockchip #Ubuntu #KDE #Mainline
current and add edge as target. by @EvilOlaf in armbian/build#972405 May, 2026 03:36AM by Michael Robinson
Today we're happy to release OSMC's May 2026 update for all supported devices. This update continues to bring Kodi v21.3 as Kodi v22 becomes nearer to release.
Recently, we announced test builds that added Dolby Vision FEL support. Today, we're happy to make Dolby Vision FEL support for all Vero V users out of the box without any need to install any special test builds.
Shortly, we'll be updating the Wiki and product pages to reflect these changes.
On the OSMC side, we've made a number of changes to keep things running smoothly:
/boot/cmdline.txt support for Vero V to allow customising boot parametersTo get the latest and greatest version of OSMC, simply head to My OSMC -> Updater and check for updates manually on your exising OSMC set up. Of course — if you have updates scheduled automatically you should receive an update notification shortly.
If you enjoy OSMC, please follow us on X, like us on Facebook and consider making a donation if you would like to support further development.
You may also wish to check out our Store, which offers a wide variety of high quality products which will help you get the most out of OSMC.
Vero V is our latest and greatest flagship and the best way to enjoy OSMC and with Dolby Vision now supported, it's better than ever.
04 May, 2026 06:51PM by Sam Nazarko
04 May, 2026 09:29AM by Joseph Lee
This release is an emergency release to fix a critical security vulnerability in the Linux kernel.
Update the Linux kernel to 6.12.85, which fixes Copy Fail, a vulnerability that could allow an application in Tails to gain administration privileges.
For example, if an attacker was able to exploit other unknown security vulnerabilities in an application included in Tails, they might then use Copy Fail to take full control of your Tails and deanonymize you.
We are not aware of this vulnerability being used in practice until now.
For more details, read our changelog.
Automatic upgrades are available from Tails 7.0 or later to 7.7.2.
If you cannot do an automatic upgrade or if Tails fails to start after an automatic upgrade, please try to do a manual upgrade.
Follow our installation instructions.
The Persistent Storage on the USB stick will be lost if you install instead of upgrading.
If you don't need installation or upgrade instructions, you can download Tails 7.7.2 directly:
Hi everyone,
Lately, I’ve been working on a scientific paper regarding one of our past projects from 2023: the 3D documentation of the Similaun Mummy (Ötzi) via SfM (Structure from Motion). The project was carried out on behalf of the South Tyrol Museum of Archaeology and was presented on August 14, 2025, in Peru at the XI World Congress on Mummy Studies in Cuzco, as you can see in the official post of the Museum. For those interested, I’m including links to some news coverage regarding our presentation below (RAI-TGR, Archaeologie on line, Der Standard).
As part of this project, once we obtained the 3D model of Ötzi, we decided to integrate it with DICOM data from the latest CT scans. To achieve this, I used the open-source software InVesalius to automatically extract the 3D model of the skeleton, and 3DHOP to visualize both 3D models (mummy and skeleton) together.
To allow the skeleton model to be viewed within the mummy model in 3DHOP, I utilized the excellent existing "Plane Sections" tool, but I also developed a new tool called "x-ray". This tool manipulates the transparency of the upper layer (the mummy) to reveal the internal layer (the skeleton).
![]() |
| The 3DHOP x-ray extension I developed for the project. |
I hope this post proves useful to the community.
Have a nice day!
03 May, 2026 11:15AM by Luca Bezzi (noreply@blogger.com)
The 4rd monthly Sparky project and donate report of the 2026: – Linux kernel updated up to 7.0.3, 6.18.26-LTS, 6.12.85-LTS – Linux kernel 6.19 is EOL, so removed from Sparky repos – preparations for a next Sparky stable release 8.3 is on the way, stay tuned. Many thanks to all of you for supporting our open-source projects. Your donations help keeping them and us alive. Don’t forget to…
01 May, 2026 05:50PM by pavroo
We are proud to announce our new stable release 🚢 version 2026.04, code-named ‘CashFloh’!
Grml is a bootable live system (Live CD) based on Debian. Grml 2026.04 brings you fresh software packages from Debian testing/forky, switches from ISOLINUX to GRUB2 for BIOS boot, enhanced hardware support and addresses known bugs from previous releases.
Like in the previous release 2025.12, Live ISOs 📀 are available for 64-bit x86 (amd64) and 64-bit ARM CPUs (arm64).
For a detailed overview of the changes from Grml 2025.12 to 2026.04, please check out the official release announcement.
Once again netcup contributed financially, this time specifically to this release. Thank you, netcup ❤️
We also want to thank our individual sponsors donating through GitHub. If you like what we are doing, please join in!
Thanks to everyone who contributed to Grml and this release, stay healthy and happy Grml-ing! ❤️🧡💛💚💙💜
If you remaster Grml ISOs or build your own, please take a look at the grml-live changelog.
In the next release, we will stop shipping grml-live in the GRML_FULL ISO flavour.
Let us know if you have usecases for running grml-live from Grml!
Now head over to our download page and grab your own copy.
30 April, 2026 09:36AM by xiaofei
This release is an emergency release to fix important security vulnerabilities in Tor Browser.
Update Tor Browser to 15.0.11, which fixes several vulnerabilities in Firefox 140.10.1.
We are not aware of these vulnerabilities being exploited in practice until now.
Update Thunderbird to 140.10.0.
Stop making it possible to start our ISO images from a USB stick.
Since 2019, we recommend USB images to start Tails from a USB stick, which is by far the most common way of running Tails.
We still distribute ISO images to start Tails from a DVD or in a virtual machine. Until now, these ISO images worked on USB sticks as well, but provided a degraded experience without automatic upgrades or Persistent Storage.
Our ISO images no longer work on USB sticks to save a few megabytes and prevent confusion for people who use USB sticks.
For more details, read our changelog.
Automatic upgrades are available from Tails 7.0 or later to 7.7.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.
Follow our installation instructions.
The Persistent Storage on the USB stick will be lost if you install instead of upgrading.
If you don't need installation or upgrade instructions, you can download Tails 7.7.1 directly:
29 April, 2026 01:29PM by Greenbone AG
29 April, 2026 12:26PM by t.lamprecht (invalid@example.com)
Hello, Community!
Now that VyOS 1.5.0 is out of the door, it's time to share the news about new developments in VyOS rolling release that happened in March and April that either weren't included in VyOS 1.5.0 and VyOS Stream 2026.03 or didn't get a prominent mention. They include support for BGP link-state address family, post-quantum pre-shared keys in IPsec, and more.
29 April, 2026 11:17AM by Daniil Baturin (daniil@sentrium.io)
28 April, 2026 09:58AM by xiaofei
28 April, 2026 05:57AM by xiaofei

This week in Armbian development saw a broad range of updates spanning kernel enhancements, desktop improvements, and infrastructure refinements. Notable changes include new developer documentation for the desktop submodule, expanded GPU and multimedia support for vendor-kernel desktops, and several kernel version bumps for various platforms. The build system received fixes for filesystem resizing and improved dependency handling, while CI workflows were optimized with increased timeouts and better error handling. New hardware targets were added, including Radxa Dragon Q6A and Nio 12L, alongside updates to u-boot and kernel drivers for multiple devices. Additional improvements focused on patch maintenance, logo updates, and enhanced automation for VM provisioning. These collective efforts continue to strengthen Armbian’s reliability, performance, and hardware compatibility.
-@ to normalized dtc invocation. by @rpardini in armbian/build#972028 April, 2026 01:46AM by Michael Robinson
The Xen Project has released one or more Xen security advisories (XSAs). The security of Qubes OS is not affected.
The following XSAs do affect the security of Qubes OS:
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
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.
Attacks on open source projects have become the norm and therefore also threaten the supply chain of Univention products. To ensure the necessary security and transparency, we rely on signatures, SBOMs and VEX in Univention Nubus. The benefits behind these approaches are explained below.
The “supply chain” of a software includes all parties involved – from writing the source code to commissioning in the data center. In most environments, it consists of a mix of in-house development and externally sourced software.
External software can either be freely available from the internet or provided by commercial vendors. This distinction is relevant for questions of responsibility and licensing terms – but less decisive for the fundamental security of the supply chain.
Almost all risks in the software supply chain can be assigned to two areas:
To keep up with the high dynamics of vulnerability management, automated processes are essential. The following process chain has become established:
In the following, the most important technical measures required for this process are described.
Signatures have become the standard mechanism for verifying trustworthiness – regardless of whether software is installed in UCS as a “.deb” package, as a container or on Windows. While implementations differ in detail between various package formats and repository servers, they are always based on a key pair: a private key held by the software creator and a public key that operators can use for verification, for example based on the GPG implementation.
When providing software, the software creator – for example Univention – uses the private key to sign either the software packages themselves or, as in Debian repositories, the checksums. These signatures are part of the software distribution. When operating Nubus with Univention Corporate Server, the mechanisms implemented by “apt” are used, while for Nubus for Kubernetes, containers and Helm charts are signed (see below). Since both methods are widely used, automated verification with standard tools is possible.
A complete verification includes not only signatures but also checksums. These are generated by the package creator using standardized hash algorithms. The operator applies the same algorithm and normally obtains the same result, i.e. the same checksum. If an attacker manages to modify a package on the download server, the checksum will differ and the attack will be detected. Thanks to the signature of the checksums, manipulations of these would also be detected.
Keeping track of which software and especially which libraries are currently deployed can be more or less complex depending on the environment. However, such a “software inventory” is essential for assessing potential vulnerabilities.
When Nubus is deployed on Univention Corporate Server (UCS), the main components can still be determined relatively easily thanks to the Debian-based package management using tools such as “dpkg” and “apt”. For container images used via Docker on UCS or in Nubus for Kubernetes, this is much less obvious. Since there are different methods of packaging software into containers, different analysis tools are required to capture all contents.
Nubus for Kubernetes therefore provides the contents of container images in a standardized format as a so-called “Software Bill of Materials” (SBOM). This makes it possible to easily and automatically determine which software in which version is contained in each container image – including the libraries used.
In addition to the information required for vulnerability management, both Debian packages of UCS and SBOMs of container images also contain license information that can be used for compliance management.
Thanks to SBOMs, operators gain a detailed insight into the software and libraries obtained from trusted sources. On this basis, automated comparison with vulnerability databases is possible, which typically reference “Common Vulnerabilities and Exposures” (CVE) IDs.
Automated vulnerability scanners usually compare the versions of the software used with versions affected by vulnerabilities. If the deployed version is affected, they report a potential vulnerability.
Such findings are often valid and must always be reviewed. However, they are not infrequently so-called “false positives”. The most common causes are:
As a software manufacturer, Univention systematically evaluates such cases and decides whether a vulnerability is exploitable and whether a fix is provided as an update or backport – this process is referred to as “triaging”. To make this information available to operators, the “Vulnerability Exploitability eXchange” (VEX) format was defined. It complements SBOMs with information on vulnerabilities that could not be resolved by a simple version update. Univention provides VEX information for all container images of Nubus for Kubernetes.
As with software packages and container images, it is also important to verify signatures for VEX and SBOMs. Otherwise, attackers could manipulate this information to hide vulnerabilities. Signature verification reliably detects such changes.
With Nubus for Kubernetes, Univention covers all aspects of supply chain security. All components (“artifacts”) of a release – including container images, Helm charts, SBOMs and VEX – are signed. The implementation is based on the widely used “Sigstore” project, which is already integrated into many Kubernetes environments. Details of the implementation and examples of how to verify the authenticity of the artifacts can be found in the “Supply Chain Security” chapter of the Nubus for Kubernetes Operation Manual.
The German Federal Office for Information Security (BSI) addresses supply chain security both in the IT-Grundschutz catalog and in various technical guidelines. All implementations of Nubus for Kubernetes are designed to implement these requirements in a practical manner.
Good entry points into the extensive information provided by the BSI include:
SBOMs not only contain the version numbers of the software used, but also the respective license information. These may be open source licenses or proprietary licenses. This allows operators to perform compliance checks to determine whether the license terms are acceptable for their organization and can be complied with. Thanks to the standardized SBOM format, these checks can be automated.
A typical approach is to define acceptable licenses within the organization and validate the contents of SBOMs against them. If new software is added or an existing software changes its license, an automated check detects if the new license does not comply with the defined requirements. This allows the organization to act before the software is deployed and the license terms potentially take effect.
Freely available open source projects unfortunately vary greatly in their maturity regarding supply chain security. The provision of signatures and checksums has become common, as these are automatically generated by most build processes. However, SBOMs or even VEX information are rare and often not meaningful for individual software libraries.
Open source software manufacturers such as Univention therefore take on a dual role in supply chain security: on the one hand, they secure the supply chain of the software used in their products, and on the other hand, they themselves are part of such a supply chain for their customers. As a manufacturer, they close a gap by generating, for example, complete SBOMs from the base information provided by open source projects.
Univention takes this responsibility seriously and ensures that software included in delivered products originates from trustworthy sources, can be maintained with security updates and is provided under OSI-compliant open source licenses. The techniques and automations described in this article are also used internally.
As a Univention customer, you receive the assurance as part of the subscription agreement that these security measures have already been implemented.
Der Beitrag Secure Supply Chains with Univention Nubus: Overview of SBOM, VEX and Signatures erschien zuerst auf Univention.
27 April, 2026 10:26AM by Ingo Steuwer
Qubes OS 4.2 is scheduled to reach end-of-life (EOL) on 2026-06-21, approximately two months from the date of this announcement.
If you’re currently using Qubes 4.2, you should upgrade to Qubes 4.3 no later than 2026-06-21. There are two ways to upgrade:
Perform a clean installation of Qubes 4.3. This involves backing up your current system, replacing your current installation with a fresh Qubes 4.3 installation, then restoring from your backup. Many users find this option to be simpler, easier, and less error-prone. However, if you’ve made extensive customizations in dom0, they may need to be redone.
Perform an in-place upgrade from Qubes 4.2 to Qubes 4.3. Instead of replacing your existing installation, this method involves installing a special command-line tool in dom0, then using it to upgrade your existing Qubes 4.2 installation to Qubes 4.3. This is a more complex multi-stage process, which makes it most suitable for advanced users. This method preserves your qubes and all the customizations you’ve made in dom0 that are compatible with the in-place upgrade process. While not strictly required, we still strongly recommend making a full backup before attempting an in-place upgrade. This way, if anything goes wrong, your data is still safe, and you always have the option of falling back to performing a clean installation.
(If you’re already on Qubes 4.3, then you don’t have to do anything. This announcement doesn’t apply to you.)
When a Qubes OS release reaches end-of-life (EOL), it’s no longer supported. This means that bugs discovered in that release will no longer be fixed, and enhancements will no longer be added. Most importantly, releases that have reached EOL no longer receive security updates, which is why it’s critically important to upgrade to a supported release.
The Qubes OS Project uses the semantic versioning standard. Version numbers are written as [major].[minor].[patch]. When a major or minor release reaches EOL, all of its patch releases also reach EOL. For example, when we say that “Qubes 4.2” (without specifying a [patch] number) is approaching EOL, we’re specifying a particular minor release, inclusive of all patch releases within it. This means that Qubes 4.2.0, 4.2.1, 4.2.2, 4.2.3, and 4.2.4 will all reach EOL at the same time (on 2026-06-21), since they’re all patch releases of the same minor release.
According to our support policy, stable Qubes OS releases are supported for six months after each subsequent major or minor release. This means that Qubes 4.2 reaches EOL six months after Qubes 4.3 was released. Since Qubes 4.3.0 was released on 2025-12-21, Qubes 4.2’s EOL date is six months later, which is 2026-06-21.
24 April, 2026 10:17AM by xiaofei
24 April, 2026 01:50AM by xiaofei
23 April, 2026 02:47AM by xiaofei
Since 2023, Microsoft has started replacing the Secure Boot certificates originally issued in 2011. These older certificates begin expiring in June 2026.
Tails now notifies you if the computer that you are using has outdated Secure Boot certificates and needs an update.
root user. (#21514)For more details, read our changelog.
Automatic upgrades are available from Tails 7.0 or later to 7.7.
If you cannot do an automatic upgrade or if Tails fails to start after an automatic upgrade, please try to do a manual upgrade.
Follow our installation instructions.
The Persistent Storage on the USB stick will be lost if you install instead of upgrading.
If you don't need installation or upgrade instructions, you can download Tails 7.7 directly:
A live webinar hosted by Bluella, a company specialized in infrastructure and cybersecurity solutions, in collaboration with SKUDONET, will explore how modern applications handle performance and security challenges in real time.
Live Webinar | 14 May 2026 | 10:00 AM CET | 2:30 PM IST
Unlike traditional sessions focused on theory, this webinar will demonstrate real-world scenarios as they happen offering a practical view of how infrastructures behave under pressure, attacks, and unexpected conditions.
Modern applications don’t fail suddenly.
And most teams only realize it when it’s already too late.
Because the real issue is not just traffic or security it’s the lack of visibility and control across fragmented systems.
During the session, attendees will experience real-world scenarios in action, including:
How infrastructure reacts when demand suddenly increases and how performance can degrade before any alert is triggered.
How malicious requests blend into normal traffic and how they can be detected and mitigated before causing damage.
How attackers can manipulate application behavior and silently redirect users without their knowledge.
How modern infrastructures maintain availability and continuity under pressure.
All demonstrated live, showing how these challenges can be handled in practice using SKUDONET’s platform.
This session is not about slides or theory.
It’s about seeing what actually happens and understanding how to respond in real time.
If you want to understand how modern infrastructures behave under real conditions and how to handle it in practice:
21 April, 2026 03:00PM by Isabel Perez
21 April, 2026 03:18AM by xiaofei

This week in Armbian development saw significant progress across board support, desktop environments, and infrastructure. Notably, NanoPC T6 LTS Plus was added as a reusable board, and support for Ubuntu 26.04 LTS ("Resolute") expanded to desktop package coverage and testing. Multiple improvements targeted desktop environments, including package updates, installation fixes, and branding enhancements for browsers. Kernel and bootloader updates were implemented for various boards, with mainline kernel bumped to 7.0 stable and u-boot upgrades for Rockchip devices. Infrastructure enhancements included new CI workflows, multi-arch unit tests, and migration to a REST API. Several bug fixes, optimizations, and cosmetic cleanups rounded out the release, ensuring greater stability and usability for Armbian users.
20 April, 2026 04:20PM by Michael Robinson
20 April, 2026 10:53AM by Joseph Lee
Red Hat OpenShift Virtualization helps teams modernize how they run virtual machines, but production networking still needs to be deliberate. As VM environments grow, teams need stronger segmentation, clearer policy control, predictable performance, and an operating model they can trust.
In this episode of the VyOS Networks Power 5 podcast, Santiago Blanquet, Chief Revenue Officer at VyOS Networks, joins Gizem Yiğit, Marketing Product Manager, to discuss how VyOS 1.5 LTS strengthens Red Hat OpenShift Virtualization with enterprise-grade, high-performance networking built for production use.
20 April, 2026 05:30AM by Gizem Yigit (g.yigit@vyos.io)
The Xen Project has released one or more Xen security advisories (XSAs). The security of Qubes OS is affected.
The following XSAs do affect the security of Qubes OS:
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
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.
We have published Qubes Security Bulletin (QSB) 112: Floating Point Divider State Sampling (XSA-488). 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 112 ]===---
2026-04-18
Floating Point Divider State Sampling (XSA-488)
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-04-17, the Xen Project published XSA-488, "x86: Floating Point
Divider State Sampling" (CVE-2025-54505) [3]:
| Researchers from the CISPA Helmholtz Center for Information Security
| have discovered Floating Point Divider State Sampling. It is detailed
| in a paper titled "TREVEX: A Black-Box Detection Framework For
| Data-Flow Transient Execution Vulnerabilities"
|
| For more information, see:
| https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7053.html
| https://roots.ec/blog/fpdss/
Impact
-------
An attacker might be able to infer data belonging to other contexts,
including data belonging to other qubes.
Affected systems
-----------------
Only AMD CPUs with the Zen or Zen+ microarchitecture (Family 17h) are
believed to be affected. Other AMD CPUs (including later Zen
generations) and CPUs from other manufacturers are not believed to be
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-4
For Qubes 4.3, in dom0:
- Xen packages, version 4.19.4-7
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://doc.qubes-os.org/en/latest/user/how-to-guides/how-to-update.html
[2] https://doc.qubes-os.org/en/latest/user/downloading-installing-upgrading/testing.html
[3] https://xenbits.xen.org/xsa/advisory-488.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
Source: qsb-112-2026.txt
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEELRdx/k12ftx2sIn61lWk8hgw4GoFAmnjWdQACgkQ1lWk8hgw
4GpFRA/7Bl1DIRzKJ7O8Y0VC3HLM6q5rCa6tk9hyjkjNLFH8MB6LqTsYl71ma2iS
HtWp+xJbg77Jrdf8X4PdFP4vH/38VT9MxAjFnF13HIi7IxEc2bCHpAPQYSDmT0+1
1d5z5A8yX5A32ZswIFEDjIfG9KdobrKq9c8ZGBMonpbylH2keNJobqkJ2DYzSjZI
BLai5S5U2PO884hxa3t52R5dAO0nojypx9hI8BfV/UGk4htBgBbdL/k0TNOymOfZ
3j9lV3khBMAoNLRZnRViEqmDE1i7FldK+WAEmNzPP1Y2YdU9S6MyLd6rvdGA6VLg
NCXwzyiUKdSvGvYiVpnB1JXZP3sGtoulr0xwodwQbR1rLlYS6uW+CRZKk6FSrM8t
juVsa+fTWqxSfGU55Mvm2LKdFl1MKChD+Ln9QeYaw14kvqYIv3nOBiLcL+UGBYbb
3SaieSqqSe7nvmWWeA/dReObtHUGyLT1ZOTxObpQRFX2cdOQyZTj+wzROtGV31jn
jvJqZ/GBGTaMTOJrNv+7nNzJbICiLHmLwR+/FZbRxt4rs5+ek1Ovt4k0qGIN2jti
GXSAvU0lkWIqEtuxHDjD/f7hYJI/DQ6OCDq5HO5lHfl25RIGP0TdbWam4fLyj0NG
rmID8bDIJ6WT/20VqTXN5pyiL7vo3QGqmh9iWyoJXeKjezFktAc=
=sq1L
-----END PGP SIGNATURE-----
Source: qsb-112-2026.txt.sig.marmarek
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE6hjn8EDEHdrv6aoPSsGN4REuFJAFAmnj92wACgkQSsGN4REu
FJA1lA//VBqhmIeONyVFhyNej/2sI1MUTbELKA9f+9zKQaw/tgeM5y7SbbazgYdc
zWVRObsENtLSrBG0vIPwVat93B76lDeoJZAWxfW9MQ2lBx3/QKPArU+8abOfzel4
eRQOchaH3hPVszIK8jtLMX9YyUSF3BWedBnIOp2wnmvNgR/Aczv73XcgVWAgF6RG
81T5S6ailrgZgWDq4xnd0699UdUSSAgxSYvMxeM8suqDWDb+viiF2kCoSyXJ4K7P
mHKh3VR7VGEj9kUHB7DsbOd1jspioWV/Y/FAEISTB6BLjQMWSPAZlQSmKCql4PMl
YB3o8yaE6XbvjBmixMwUivhDq2QzewzqxZdDKqJxZ+wDh8hGBYu8dyN+SOMCG251
SnMSsx0MOWqOh3I4ng0GLAhE3kPzgehsaZYTXFcaxTMRMSnnWuGaNlpkjUmOFQup
D2VcQbCyLBsaM/32ZxbZ86SBcZEgF0uPJO0Qc/11mW+nydPYHVnjHBon31eMlFLo
7MdinyUlAztrv8OL0kw9ip1ytiw17k9N0ynU7cWZPWHkmhLyz4McxjGQ1PD9wOes
ApxUn8DjvSXXcHdkPt2xMI/fOH575t2WaTV+Tyud32hdHFYX0sQ40dvz1khL1RJT
s65YivSaBv61M8NMU0mnZHDMH27lTKL/LIa8EPmi8WtD2dqTwM8=
=6b1c
-----END PGP SIGNATURE-----
Source: qsb-112-2026.txt.sig.simon
The purpose of this announcement is to inform the Qubes community that a new Qubes security bulletin (QSB) has been published.
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.
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.
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.
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.
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-112), the commands are:
$ gpg --verify qsb-112-2026.txt.sig.marmarek qsb-112-2026.txt
$ gpg --verify qsb-112-2026.txt.sig.simon qsb-112-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-112 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.
Following the PureOS Crimson beta release in our last post, we are eagerly looking forward to the general release. We received a lot of constructive feedback about the beta, and with only a few blockers left, we are taking the opportunity to make this the best PureOS release yet.
The post PureOS Crimson Development Report: March 2026 appeared first on Purism.
17 April, 2026 08:39PM by Purism

If you&aposve installed a desktop environment with armbian-config over the last few months, you may have noticed things feel different: there&aposs a tier you can pick, the browser actually works on every arch, uninstall doesn&apost take half your system with it, and there&aposs no snap pop-up surprising you on Ubuntu builds. That&aposs not by accident the desktop submodule has been quietly rebuilt from the ground up. Here&aposs what landed, why we did it, and what it means for you.
Three tiers, instead of one all-or-nothing install:
And because changing your mind is allowed you can move between tiers any time without a reinstall. armbian-config --api module_desktops upgrade de=xfce tier=full computes the delta and only adds what&aposs missing. The reverse path, downgrade, only removes packages from the original install manifest, never anything you added on your own.
On Ubuntu, the apt names chromium, firefox, and thunderbird are snap-transitional packages installing them silently pulls in snapd, runs the apps in a snap sandbox, and gives you a slow start, broken hardware acceleration, and a confusing menu of "two Chromiums" if you ever want the real thing.
Armbian images don&apost ship snapd, so we now route those names to real, native .debs hosted on apt.armbian.com. The desktop install path writes an apt pin priority file at /etc/apt/preferences.d/armbian-desktops that forces our packages to win over the snap-shims even on systems where the snap version is technically newer. The result: apt install chromium gives you a real, native Chromium. No snapd. No surprise pop-ups.
On amd64 systems, the browser slot maps to Google Chrome (also from apt.armbian.com); on RISC-V Ubuntu builds you get real Firefox. Debian releases keep using upstream chromium / firefox-esr those have always been real .debs and need no help.
Each DE XFCE, GNOME, KDE Plasma, KDE Neon, MATE, Cinnamon, i3-wm, xmonad, Enlightenment, Budgie, Deepin is now a single declarative YAML file in the configng repo. The engine works out which packages exist on which release on which arch, substitutes per-platform replacements where needed, and silently drops broken ones. Same XFCE definition runs on Debian bookworm/trixie/forky and Ubuntu noble/resolute across arm64 / amd64 / armhf / riscv64.
Adding a new desktop environment is a YAML edit and a smoke test no per-distro shell scripts, no codepaths to chase.
Every desktop install records a manifest of exactly which packages it added under /etc/armbian/desktop/<de>.packages. Removal undoes only those. Packages that were already on your system before you installed the desktop stay put. No more "I uninstalled XFCE and lost half my system."
gdm3, sddm, or lightdm via in-place sed edits your WaylandEnable=false and other tweaks survive.libfido2-1 on resolute, libu2f-udev on older releases.cups-pk-helper ships with every desktop install now.code no longer prompts you to add Microsoft&aposs apt source — we host the real package, the prompt is suppressed, the pin keeps Microsoft from sneaking in over the top.A scheduled Claude AI supported GitHub Actions workflow scans the YAML matrix against armbian/build&aposs supported releases and the live Debian/Ubuntu archives flags releases not yet covered, flags packages that no longer exist upstream then opens a PR with proposed YAML fixes. Dead packages and missing releases stop accumulating silently.
On any modern Armbian install:
sudo armbian-config
# or scripted:
sudo armbian-config --api module_desktops install de=xfce tier=full
sudo armbian-config --api module_desktops upgrade de=xfce tier=full
sudo armbian-config --api module_desktops downgrade de=xfce tier=mid
sudo armbian-config --api module_desktops remove de=xfce
Supported desktops today: XFCE, GNOME, KDE Plasma, KDE Neon (Ubuntu noble only), MATE, Cinnamon, i3-wm and xmonad, Enlightenment, Budgie and Deepin experimental. Supported targets: Debian bookworm / trixie / forky and Ubuntu noble / resolute on every Armbian arch.
16 April, 2026 03:04AM by Igor Pecovnik
What really happens when your web application fails?
Together with Bluella, a company specialized in infrastructure and cybersecurity solutions, we’ll walk through real-world scenarios showing how modern applications break under pressure and how to maintain control in real time.
Live Webinar | 14 May 2026 | 10:00 AM CET | 2:30 PM IST
The session will focus on practical, real-time demonstrations of traffic spikes, cyberattacks, and failover scenarios, offering a clear view of what actually happens behind application downtime.
Most teams still assume that application failures are caused by bugs.
But in reality, that’s rarely the case.
And here’s the real issue:
By the time teams notice something is wrong, it’s already too late.
And when this happens, the impact is not only technical: it’s operational, it’s financial and it’s personal.
The result is always the same:
The root problem is not just traffic or security.
It’s lack of visibility and control.
In many environments:
This creates blind spots.
And blind spots are where failures begin.
Understanding the problem is important.
But what really matters is seeing how it happens and how it can be controlled.
Modern infrastructures need to:
This is where visibility and control become critical.
To address these challenges, Bluella and SKUDONET are hosting a live webinar focused on real-world scenarios and practical demonstrations.
Live Webinar | 14 May 2026 | 10:00 AM CET | 2:30 PM IST
Hosted by Bluella in collaboration with SKUDONET
During the live session, attendees will experience:
All demonstrated live, showing how these challenges can be handled in practice using SKUDONET’s platform.
This session is designed for:
If you want to understand what really happens behind application failures and see how to handle it in practice:
15 April, 2026 10:50AM by Isabel Perez
This release is an emergency release to fix an important security vulnerability in the confinement of Tor Browser.
Update Flatpak to 1.16.6, which fixes CVE-2026-34078, a major sandbox escape vulnerability. Using this vulnerability, an attacker could break the security confinement of Tor Browser and access all files that don't require an administration password, including in the Persistent Storage.
This vulnerability can only be exploited by a powerful attacker who has already exploited another vulnerability to take control of Tor Browser.
For more details, read our changelog.
Automatic upgrades are available from Tails 7.0 or later to 7.6.2.
If you cannot do an automatic upgrade or if Tails fails to start after an automatic upgrade, please try to do a manual upgrade.
Follow our installation instructions.
The Persistent Storage on the USB stick will be lost if you install instead of upgrading.
If you don't need installation or upgrade instructions, you can download Tails 7.6.2 directly:
We have published Qubes Security Bulletin (QSB) 111: xfce4-screensaver login bypass. 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 111 ]===---
2026-04-14
xfce4-screensaver login bypass
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
--------
When connecting or disconnecting a display or, in some cases, when simply
activating the xfce4-screensaver login prompt on a locked screen, there
is a very short window of time during which keyboard input is not
intercepted by xfce4-screensaver and is instead sent to the application
that was active before locking.
The issue has been fixed upstream in [2].
Impact
-------
The time window is normally too short for any real harm to occur when
physically typing on a keyboard. However, if an attacker is able to
generate input events in an automated way, the attacker can attempt to
deactivate the screensaver by sending a command quickly enough.
Affected systems
-----------------
The default Qubes OS 4.3 configuration, which uses xfce4-screensaver and
the Xfce desktop environment, is affected. Other Qubes OS releases and
other screensavers are not affected.
Systems that permit an attacker physical access to a keyboard interface
are affected. Most systems permit such access in some way, since the
user's legitimate keyboard must connect to the system through such an
interface, but the degree of difficulty for the attacker varies
significantly depending on the nature of the interface.
- The easiest method for an attacker is unrestricted USB keyboard input
without a confirmation prompt, but this is disabled in Qubes OS by
default. However, users can override this default configuration to
allow unrestricted USB keyboard input, and many users do so because
they have no other way to connect a legitimate keyboard to their
systems. If the user has allowed unrestricted USB keyboard input,
then an attacker can easily and quickly generate keyboard input
events by connecting a USB device that emulates a keyboard.
- An attacker could also use a non-USB keyboard input interface, such
as a PS/2 port. However, such interfaces are less common nowadays.
Nonetheless, if the system has such an interface, and if the attacker
has physical access to it, then the system is affected, even if USB
keyboard input is restricted.
- Even when there is no keyboard input interface exposed on the outside
of the machine as a convenient port, as in the case of a laptop with
disabled USB keyboard input and no PS/2 port, it may still be
possible for the attacker to physically modify the machine in order
to gain access to such an interface. For example, built-in laptop
keyboards must still be internally connected to the laptop's
motherboard through such an interface in order to function properly.
An attacker who can gain access to the internal components of the
machine could disconnect the legitimate keyboard and attach their own
malicious device to the same interface. However, this form of attack
is significantly more complex than the foregoing attack vectors and
requires extensive physical access, making it much more difficult to
execute successfully.
Discussion
-----------
In general, we consider most attacks that require physical access to the
system to fall outside the scope of the Qubes security model. Aside from
the general challenges of protecting against physical attacks, this is
primarily because physical protections depend heavily on the hardware
and firmware details of the system. Since Qubes OS is designed to run on
any x86 system that meets its system requirements [3], these hardware
and firmware details can vary significantly between systems and are
typically outside of Qubes' control. Nonetheless, we consider this
screensaver login bypass vulnerability to fall within the scope of the
Qubes security model, since Qubes OS does have control over keyboard
input interception on the lock screen.
Patching
---------
The following packages contain security updates that address the
vulnerabilities described in this bulletin:
For Qubes 4.3, in dom0 (no GUI domain):
- xfce4-screensaver 4.18.4-5
For systems with a GUI domain, a similar update will be provided by the
distribution of the template on which the GUI domain is based (e.g.,
Fedora or Debian).
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. [4] Once available, the packages should be installed
via the Qubes Update tool or its command-line equivalents. [1]
Dom0's user session must be restarted afterward in order for the updates
to take effect. This can be accomplished by logging out of Xfce4, then
logging back in again, or by simply restarting the system.
Credits
--------
The issue was reported by Murat Altindis and Maria Kessler of AWARE7
GmbH.
Qubes issue #10720 [5] is likely a report of the same problem. This
issue was incorrectly identified as a duplicate of another issue that
sounds similar but that is not relevant to the security of Qubes OS.
References
-----------
[1] https://doc.qubes-os.org/en/latest/user/how-to-guides/how-to-update.html
[2] https://gitlab.xfce.org/apps/xfce4-screensaver/-/commit/4436087c6af5e915a2438d7c1dd0fdc282f547f8
[3] https://doc.qubes-os.org/en/latest/user/hardware/system-requirements.html
[4] https://doc.qubes-os.org/en/latest/user/downloading-installing-upgrading/testing.html
[5] https://github.com/QubesOS/qubes-issues/issues/10720
--
The Qubes Security Team
https://www.qubes-os.org/security/
Source: qsb-111-2026.txt
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEELRdx/k12ftx2sIn61lWk8hgw4GoFAmndgcIACgkQ1lWk8hgw
4GpjTA//Uu9j7FMKVj014K5ORjHWgIv5PAVmvl6LaMQpxctGtFoBH9/PXGppv/E8
tsSv9+hFH14a0AH+yj63wflYuWc5rnMA1Z93D/29T8QKpY6ygijr1i5+L19Rb+6Q
lW2H8LefiZgdYANjImilUzBD9Pc8BjvDUXJ+jqO0ETeyiBvFLX65MgFw2GREo+yB
yGBkCOBKdCiuOdnxhWUCwCM4Cdrs4eIjfO/97aOqE3KbqzHLRM2LuBsFKq3N5kBW
NJnH3TLQZVvfHA96JNbY0WFbnSO09J4cs1b61kLK/wIUSM/JoqkQ94ieNNOGvJKa
0TQ0WyIwfjX4mIrVzZ6jbWZPbFDJfjvlNwnwicl4UuQtB3ChzPfWJ5zK/ama9ixW
MNWwD6hfyj60XoR2DIL42j5lZvEOUDcn84T7jy8bS6/bbNsa1dYgYyToaUIOqiiM
0QrDWqVu9eL4v+zA8IvNTqnayPF6xb4t4j9bB26QlNcoKRbcysnYlRPAWB2aYr1X
iV0bE/I3KJqXAyR+rvf1zPerkAodExV0o0C08NYSbgR2lN8cyoDrMBx5meHyQ6wa
seAdM7cWy0JSos4J+sdY83nRKojB0uMcpbKAankstxJ2L8Th6MQnmULWYGBT+msG
HJjFWcSIzS+P3uYvg1FlBVeIcR/oQexDDM78q/wsqqPzbyokxmo=
=AWM/
-----END PGP SIGNATURE-----
Source: qsb-111-2026.txt.sig.marmarek
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE6hjn8EDEHdrv6aoPSsGN4REuFJAFAmndisoACgkQSsGN4REu
FJAAXA/9F7StrFFMXOxW/ApJQX/MxthsaK94s/iI43dLSK60xs4KFUsCFUibYamc
lcYT/m1GdOdG+4JYKW5M9CbkaZix9f1w8IuwGBpJ6qN857IfAINStyv+bX0HEb8s
dFgR0bMIHkJiCIZWgFGSxyLKAR5GVUHS/JIJIe8OEawiAKc1NA+Z6TTRPIo0y4yX
QB1UC6vgFNVq1jRRiEo+m+vi3fLsXyWEbPGpG5KlJQZ+0T7mY/XYaumkJQtgobwb
mBt3mBrEGgc2532uw6LYO6YpsxITKiLPejY/gen41K+W9b3WxPzTJrao+NGohnZk
hFM+mTvCYnfcL2fVRt9OBJijn0YU0aVAaS+Ri6BzCGo6ZUop8I2Z0TpBR7axEaWi
wJrZWR6sz15094x4XbnrnaJtcXylEswMmhSOTnpWy5jUW4DhyUNyGSCgF3GiGzN7
Vpb6KdDybaxDCTUwexd890Y3hNFbm1pGlYfUzq1H4OEVHsUy4NATFad1QjzEmirn
7bLJE17/Kgqva5MqyTH6jUAabE88oo1W93dG+lKLJ4uwicQMJjM3V9U/SIqNbhy0
wLLyx8cF+UCnGkZKZVGmEbG0dV6U+D0T28ExQs2aOEHpOURN1Uui6v7XyXG0aUyK
AlIyeZxkyCyQPL5pMAKhhNZhPnWNIuqlkraOj5GCdd7xjbvrFfk=
=jkhv
-----END PGP SIGNATURE-----
Source: qsb-111-2026.txt.sig.simon
The purpose of this announcement is to inform the Qubes community that a new Qubes security bulletin (QSB) has been published.
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.
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.
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.
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.
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-111), the commands are:
$ gpg --verify qsb-111-2026.txt.sig.marmarek qsb-111-2026.txt
$ gpg --verify qsb-111-2026.txt.sig.simon qsb-111-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-111 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.
14 April, 2026 11:01AM by Joseph Lee
With the release of Nubus for Kubernetes 1.19, we have deliberately focused on security updates. In addition to patches for recently discovered vulnerabilities, we have significantly expanded our “VEX” information in particular, in order to make our handling of potential security issues more transparent and better usable for automated evaluations. You can learn more about the background and details in this blog post.
To ensure that only secure software is operated in Kubernetes environments, many operators integrate automated security scans into their deployment pipelines. These scans check container images for known vulnerabilities and report corresponding findings. The basis for this is public data sources containing known CVEs (Common Vulnerabilities and Exposures) for open-source software.
In practice, however, these automated procedures reach their limits: purely database-based assessments often lead to a large number of false positives, as the specific usage context of the affected components is not taken into account.
Typical causes include:
To improve the reliability of these scans and reduce unnecessary alerts, we have implemented several measures. Wherever possible without changing product functionality, we have updated dependencies to newer versions, even in cases where vulnerabilities were not exploitable.
Where vulnerabilities are not exploitable or have been closed through targeted patches, another key component comes into play: the structured provision of additional context information in the form of VEX data.
An essential part of handling reported vulnerabilities in Nubus for Kubernetes 1.19 is the expansion of the information provided in VEX (Vulnerability Exploitability eXchange) format.
VEX is an industry-standard, machine-readable format for describing security assessments by manufacturers. While traditional security scanners only identify known vulnerabilities (CVEs – Common Vulnerabilities and Exposures), they often lack the context needed to properly assess them. VEX provides exactly this context by describing how a vulnerability is handled in the specific product and whether it is actually relevant.
This is particularly important because automated scans often produce findings even when:
The VEX information included in Nubus makes it possible to clearly mark these cases and evaluate the results of security scanners accordingly. Further details can also be found in the section on supply chain security. Operators can integrate the provided data into their existing security tools and thus enhance their automated testing processes with the necessary manufacturer perspective.
VEX has been used in Nubus for Kubernetes since version 1.16, initially focusing on vulnerabilities with the severity level “critical.” With version 1.19, this approach has been expanded: now all vulnerabilities with the severity level “high” identified by our internal scanning systems are also included.
VEX thus helps transform a large number of technical individual findings into contextualized and reliable security information.
The Nubus Provisioning API, which reliably informs applications and integrations about changes to users, groups, and other objects, has also been further developed in version 1.19. The focus here is on the so-called “univentionObjectIdentifier” – the central, immutable identifier of an object in the Nubus Directory Service.
This identifier serves as a stable reference for integrations, for example to uniquely assign objects or consistently track changes. In the previous structure, however, access to it was not always optimal: the identifier was present but not anchored at the most intuitive place in the API. At the same time, multiple similar identifiers such as entryUUID existed, which could lead to uncertainty in practice – especially since entryUUID is not guaranteed to be immutable.
With Nubus for Kubernetes 1.19, this model has been deliberately simplified and structured more clearly. The central field id now directly contains the univentionObjectIdentifier and thus provides the relevant identifier at the expected location. The previous attribute remains for backward compatibility and continues to provide the same value. The attribute entryUUID, however, has been removed to avoid ambiguity and to clearly focus usage on a single stable identifier.
This adjustment reduces the complexity of the API and makes the development and maintenance of integrations significantly easier.
This makes the Provisioning API overall easier to use and more robust in existing integration and Kubernetes scenarios.
A complete overview can be found in the API schema documentation.
As usual, Nubus for Kubernetes is available via the Univention OCI registry. Installation instructions can be found in the operations manual. All details are also available in the release notes.
Der Beitrag Nubus for Kubernetes 1.19 Released erschien zuerst auf Univention.
14 April, 2026 05:43AM by Ingo Steuwer

This week saw significant development activity across the Armbian ecosystem, with numerous enhancements to desktop environment support, including the addition of KDE Neon, KDE Plasma, MATE, and i3-wm, as well as improved branding and menu documentation. The desktop module was refactored for greater modularity and YAML-driven configuration, alongside fixes for theming and package removal tracking. Hardware support expanded with new device trees for NanoPC-T6 LTS Plus and Gateway DK, plus initial support for Arduino UNO Q (Qualcomm QRB2210) and additional USB Ethernet drivers. The build system received updates for kernel versions and distribution releases, notably bumping Ubuntu from plucky/noble to resolute. Automation and audit scripts were improved for reliability and scope, and documentation was updated to reflect the new tier model and branding. Overall, these changes strengthen Armbian&aposs usability, hardware compatibility, and developer tooling.
14 April, 2026 03:05AM by Michael Robinson
14 April, 2026 02:07AM by xiaofei
10 April, 2026 05:21AM by sun, ruonan
10 April, 2026 04:53AM by xiaofei
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 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:
And the consequences are tangible:
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.
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 the World Bank Group report Cybersecurity Economics for Emerging Markets, over half of developing countries face at least one cyberattack on critical infrastructure every year. The hardest-hit sectors worldwide include finance, healthcare, communications, and utilities.
The economic impact is clear: countries that successfully reduce major incidents could boost their GDP per capita by as much as 1.5%.
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.
The problem isn’t that providers are bad. The problem is structural.
Many market solutions operate as black boxes. They promise protection, but:
Without visibility, security is an assumption. And an assumption protects no one.
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:
And when an incident occurs, you depend on the provider’s response capacity, not your own.
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.
Trust in cybersecurity is not a matter of brand or marketing. It’s a matter of architecture.
A trustworthy solution must offer:
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.
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.
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:
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.
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:
The result wasn’t just more security. It was more control. And more control means more trust.
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:
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.
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:
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.
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.
09 April, 2026 03:28PM by Isabel Perez