May 14, 2026

hackergotchi for GreenboneOS

GreenboneOS

New High-Severity Linux Flaws: Copy Fail, Copy Fail 2, and Dirty Frag Offer Local Privilege Escalation to Root

Three new high-severity local privilege escalation (LPE) vulnerabilities affecting Linux were recently disclosed, creating significant global risk. Although user-level access is a prerequisite for their exploitation, the new CVEs allow command execution as the root user and full system takeover. The CVEs are considered reliably exploitable on all major Linux distributions. The name “Copy Fail” […]

14 May, 2026 05:03AM by Joseph Lee

hackergotchi for VyOS

VyOS

How we Rebuilt docs.vyos.io for the AI Era (MyST, Opus Reviewers, and Context7)

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)

May 13, 2026

hackergotchi for Deepin

Deepin

hackergotchi for Qubes

Qubes

XSAs released on 2026-05-12

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

XSAs that DO affect the security of Qubes OS

The following XSAs do affect the security of Qubes OS:

XSAs that DO NOT affect the security of Qubes OS

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

  • (none)

About this announcement

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

13 May, 2026 12:00AM

QSB-113: AMD CPU Opcode Cache corruption (XSA-490)

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


             ---===[ 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

Marek Marczykowski-Górecki’s PGP signature

-----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

Simon Gaiser (aka HW42)’s PGP signature

-----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

What is the purpose of this announcement?

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

What is a Qubes security bulletin (QSB)?

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

Why should I care about QSBs?

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

What are the PGP signatures that accompany QSBs?

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

Why should I care whether a QSB is authentic?

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

How do I verify the PGP signatures on a QSB?

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

  1. 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.)

  2. 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
    
  3. 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.

  4. 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
    
  5. 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.
    
  6. 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
    
  7. 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.

  8. 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.

13 May, 2026 12:00AM

May 12, 2026

hackergotchi for Xanadu developers

Xanadu developers

hackergotchi for Deepin

Deepin

deepin Community April 2026 User Issue and Feature Request Feedback Progress Synchronization

deepin, an open‑source operating system that performs remarkably in the DistroWatch global ranking and is widely recognised by users worldwide, values the voice of every user. With the launch of deepin 25.1 in April, community feedback has been enthusiastic. This summary integrates user issues and feature requests collected from multiple channels, including the deepin Forum. Adhering to the principle of transparent co‑construction, we are normalising the regular synchronisation of progress. We now release the monthly community feedback summary for April 2026. Everyone is welcome to actively share suggestions on the deepin Forum and participate in product iteration together. Official Forum: https://bbs.deepin.org/ ...Read more

12 May, 2026 05:19AM by xiaofei

May 11, 2026

hackergotchi for Purism PureOS

Purism PureOS

Purism’s Product Philosophy in an Age of Government–Big Tech Convergence

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

hackergotchi for Tails

Tails

Tails 7.7.3

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.

Changes and updates

  • 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.

Fixed problems

For more details, read our changelog.

Get Tails 7.7.3

To upgrade your Tails USB stick and keep your Persistent Storage

  • 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.

To install Tails 7.7.3 on a new USB stick

Follow our installation instructions.

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

To download only

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

11 May, 2026 02:47PM

hackergotchi for ARMBIAN

ARMBIAN

Github Highlights

Github Highlights

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

Changes

11 May, 2026 02:23PM by Michael Robinson

hackergotchi for SparkyLinux

SparkyLinux

Sparky 8.3

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) …

Source

11 May, 2026 01:13PM by pavroo

hackergotchi for ArcheOS

ArcheOS

DCMTK, a collection of libraries for DICOM standard

 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)

May 09, 2026

hackergotchi for Deepin

Deepin

Urgent Security Update: Fix for Dirty Frag Kernel CVES – Upgrade ASAP

Dear deepin users and community partners, Recently, a local privilege escalation vulnerability in the Linux kernel was disclosed, referred to in the industry as Dirty Frag or Copy Fail 2. This vulnerability is a variant of the same class as the Copy Fail vulnerability. An attacker who has already obtained local low-privilege code execution may exploit this vulnerability to tamper with the page cache of read-only files, further escalate privileges, and gain root access. According to publicly available information, exploit code for this vulnerability has already been circulated. Given its severity and widespread impact, we strongly recommend that all users ...Read more

09 May, 2026 06:28AM by xiaofei

May 08, 2026

deepin Community Monthly Report for April 2026

I. April Community Data Overview II. Community Products deepin 25.1 Image Officially Released: AI-Powered, Silky Smooth Experience In April, deepin welcomed a major version update – the official release of the deepin 25.1 image. This version accumulates results from multiple internal testing rounds, delivering comprehensive upgrades in AI capabilities, kernel performance, and desktop experience: Major Evolution of UOS AI The writing agent has been completely restructured, supporting "outline-first" mode and multi‑format export. The system‑level Claw mode is now available, allowing the AI to automatically control the computer and execute cross‑application tasks via natural language commands. Native integration with Feishu, DingTalk, ...Read more

08 May, 2026 02:13AM by xiaofei

May 07, 2026

May 06, 2026

hackergotchi for GreenboneOS

GreenboneOS

April 2026 Threat Report: Mythos or Reality? Time to Find Out

In April 2026, the cyber security landscape was flooded with news about Anthropic’s new Mythos bug-hunting AI and Project Glasswing. The rose-colored takeaway is that one year from now, software will be free from vulnerabilities because AI will find all of the flaws and vendors will patch. Major software companies will scan all their products […]

06 May, 2026 01:34PM by Joseph Lee

hackergotchi for Qubes

Qubes

Debian 12 (Bookworm) approaching end of life

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:

Note on Debian LTS

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.

06 May, 2026 12:00AM

May 05, 2026

hackergotchi for ARMBIAN

ARMBIAN

Github Highlights

Github Highlights

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 (addgroupgroupadd). 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

Changes


05 May, 2026 03:36AM by Michael Robinson

May 04, 2026

hackergotchi for OSMC

OSMC

OSMC's May update is here with Dolby Vision FEL support

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.

Dolby Vision FEL support

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:

Bug fixes

  • Fix audio issues at 44.1Khz when playing 4K video on Vero V
  • Fix some connectivity issues with WiFi using ConnMan

Improving the user experience

  • Vero V: Allow YUV for VESA displays that support it
  • Vero V: Added Dolby Vision FEL support
  • Add /boot/cmdline.txt support for Vero V to allow customising boot parameters
  • Allow user to disable splash screen when booting Vero V for more verbose boot

Wrap up

To 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

hackergotchi for GreenboneOS

GreenboneOS

Emergency Patch! CVE-2026-41940 in cPanel & WHM Enables Full Server Takeover

Published on April 29th, 2026, CVE-2026-41940 (CVSS 9.8, EPSS ≥ 95th pctl) allows unauthenticated remote attackers to gain administrative access to cPanel & WHM, and WP Squared through a missing authentication flaw [CWE-306]. Successful exploitation can grant control over hosted websites, databases, email accounts, the server operating system and configuration, and adjacent websites in shared-hosting […]

04 May, 2026 09:29AM by Joseph Lee

hackergotchi for Tails

Tails

Tails 7.7.2

This release is an emergency release to fix a critical security vulnerability in the Linux kernel.

Changes and updates

  • 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.

Fixed problems

For more details, read our changelog.

Get Tails 7.7.2

To upgrade your Tails USB stick and keep your Persistent Storage

  • 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.

To install Tails 7.7.2 on a new USB stick

Follow our installation instructions.

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

To download only

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

04 May, 2026 12:00AM

May 03, 2026

hackergotchi for ArcheOS

ArcheOS

3DHOP X-Ray Tool

 

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 realized that, due to time constraints, I had never shared the code for this tool. I’ve now corrected that by creating a small GitHub repository, which you can find here: https://github.com/lucaarcteam/3dhop_x-ray_extension.

I hope this post proves useful to the community.

Have a nice day!

03 May, 2026 11:15AM by Luca Bezzi (noreply@blogger.com)

May 01, 2026

hackergotchi for SparkyLinux

SparkyLinux

Sparky news 2026/04

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…

Source

01 May, 2026 05:50PM by pavroo

April 30, 2026

hackergotchi for Grml developers

Grml developers

grml development blog: Grml - new stable release 2026.04 available

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.

❤️ Thanks ❤️

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! ❤️🧡💛💚💙💜

grml-live changes

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!

Get your copy

Now head over to our download page and grab your own copy.

30 April, 2026 01:55PM

hackergotchi for Deepin

Deepin

Urgent Security Update | Fix for Linux Kernel Copy Fail Local Privilege Escalation Vulnerability – Upgrade Immediately!

Dear deepin users and community partners, Recently, the deepin community detected a high-risk local privilege escalation vulnerability in the Linux kernel. This vulnerability, dubbed "Copy Fail" (CVE-2026-31431), exists in the Linux kernel cryptographic subsystem (the algif_aead module). It originates from a code optimization introduced in 2017, which causes the AF_ALG cryptographic interface to potentially share the same kernel page cache page between the source and destination buffers when processing AEAD cryptographic operations. Given its severity and widespread impact, we strongly recommend that all users upgrade as soon as possible to ensure the security of your systems.   I. Vulnerability Information CVE ...Read more

30 April, 2026 09:36AM by xiaofei

hackergotchi for Tails

Tails

Tails 7.7.1

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

Changes and updates

  • 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.

Get Tails 7.7.1

To upgrade your Tails USB stick and keep your Persistent Storage

  • 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.

To install Tails 7.7.1 on a new USB stick

Follow our installation instructions.

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

To download only

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

30 April, 2026 12:00AM

April 29, 2026

hackergotchi for ARMBIAN

ARMBIAN

Armbian Newsletter April 2026

Armbian Newsletter April 2026

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

Armbian has released images based on Ubuntu 26.04 LTS, codenamed Resolute Raccoon the latest long-term support base. As always, Armbian applies its own platform-optimized kernel, board-specific patches, and tested drivers on top so what you get is a clean, stable foundation across SBCs, PCs, and cloud environments, with no Snap packages, fully compatible with the Ubuntu ecosystem, and no surprises.


SPONSORED
Armbian Newsletter April 2026

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

We rewrote how Armbian installs desktops. Here’s what changed
A friendlier, faster, snap-free desktop install in armbian-config If you’ve installed a desktop environment with armbian-config over the last few months, you may have noticed things feel different: there’s a tier you can pick, the browser actually works on every arch, uninstall doesn’t take half your system with it, and
Armbian Newsletter April 2026
Armbian Q1 2026: Technical Milestones and the Road to Embedded World
The first quarter of 2026 has been a period of significant technical consolidation for the Armbian project. Driven by the v26.02 (Goa) release cycle, the project has focused on three core pillars: aggressive framework refactoring, the stable rollout of the Linux 6.18 LTS kernel, and the maturation of
Armbian Newsletter April 2026
Github Highlights
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
Armbian Newsletter April 2026

29 April, 2026 03:36PM by Michael Robinson

hackergotchi for GreenboneOS

GreenboneOS

What Is the EU Cyber Resilience Act? Scope, Products, and Who It Affects

Until recently, a digital product could be placed on the European market with essentially no binding cyber security standard attached to it. Manufacturers decided how much security to build in, and buyers had no assurances and no way to compare. When vulnerabilities emerged, there was no legal obligation to report or fix them. Products could […]

29 April, 2026 01:29PM by Greenbone AG

hackergotchi for Proxmox VE

Proxmox VE

Proxmox Backup Server 4.2 released!

We're pleased to announce the release of Proxmox Backup Server 4.2.

This version is based on Debian 13.4 ("Trixie"), uses Linux kernel 7.0 as the new stable default for improved hardware support, and comes with ZFS 2.4 for reliable, enterprise-grade storage.

Here are the highlights
  • Move groups and namespaces within a datastore for easier backup reorganization
  • Server-side encryption/decryption for sync jobs
  • Improved sync performance with concurrent group processing...

Read more

29 April, 2026 12:26PM by t.lamprecht (invalid@example.com)

hackergotchi for VyOS

VyOS

VyOS Project April 2026 Update

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)

April 28, 2026

hackergotchi for Deepin

Deepin

[Tutorial] Seamless Experience on Windows Offline Installation Guide for deepin 25 WSL

For daily development and testing, many users want a convenient way to use Linux toolchains within a Windows environment. This is where WSL (Windows Subsystem for Linux) becomes the best choice. What is WSL? WSL is a feature provided by Microsoft that enables developers to run a GNU/Linux environment—including most command-line tools, utilities, and applications—directly on Windows without the overhead of a traditional virtual machine or dual-boot setup. With WSL, you get a near-native Linux experience. A New Installation Experience Microsoft recently updated its WSL ecosystem rules: distributing Linux distributions is no longer strictly tied to the Microsoft Store. This ...Read more

28 April, 2026 09:58AM by xiaofei

hackergotchi for ARMBIAN

ARMBIAN

Github Highlights

Github Highlights

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.

Changes


28 April, 2026 01:46AM by Michael Robinson

hackergotchi for Qubes

Qubes

XSAs released on 2026-04-28

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

XSAs that DO affect the security of Qubes OS

The following XSAs do affect the security of Qubes OS:

  • (none)

XSAs that DO NOT affect the security of Qubes OS

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

  • XSA-483
    • Qubes OS does not use oxenstored.
  • XSA-484
    • Denial of service only
  • XSA-485
    • In-VM attack only
  • XSA-486
    • Grant table v2 is disabled in Qubes OS.
  • XSA-487
    • In-VM attack only
  • XSA-489
    • Qubes OS does not use XAPI.

About this announcement

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

28 April, 2026 12:00AM

April 27, 2026

hackergotchi for Xanadu developers

Xanadu developers

hackergotchi for Univention Corporate Server

Univention Corporate Server

Secure Supply Chains with Univention Nubus: Overview of SBOM, VEX and Signatures

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.

Motivation: Risk Management of Operated Software

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:

  1. Vulnerability management
    Both before commissioning and during operation, operators need an up-to-date overview of known or newly discovered vulnerabilities. Based on this, measures such as updates or configuration adjustments can be derived. Since new vulnerabilities are continuously published, this process should be automated and carried out regularly.
  2. Injected malicious code
    An increasingly common attack vector is the injection of malicious code – either via compromised download servers or directly into the source code. Attackers gain access to code repositories, download servers or infrastructure and manipulate the downloadable software. Operators must therefore ensure that unauthorized modifications are detected before software is used in production.

Processes at the Operator: Automated Identification and Analysis

To keep up with the high dynamics of vulnerability management, automated processes are essential. The following process chain has become established:

  1. Identify update options
    Automated mechanisms detect available updates for software products and their dependencies. Operators define rules for which updates are applied automatically and when manual intervention is required.
  2. Verify sources
    It is defined which sources are considered trustworthy. Verification is performed both at the level of approved source servers and the publishers of individual software packages. Software from untrusted sources is not used.
  3. Identify vulnerabilities
    Vulnerabilities are reported after a software release and can therefore affect both already deployed and newly introduced software. Operators therefore carry out regular analyses of all software in operation in order to identify risks and initiate measures. These analyses are also applied to newly introduced software.
  4. Select measures
    In the simplest case, vulnerabilities can already be addressed by installing updates (step 1). However, since this is not always possible, operators often use dashboards in risk management to identify the need for action. Alternatives to updates can include configuration changes, temporary deactivation of functions or the targeted detection of attacks exploiting these vulnerabilities.

In the following, the most important technical measures required for this process are described.

Foundation: Signatures – Trustworthiness of the Source

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.

Overview Through SBOM: Components of the Software

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.

Process Insight with VEX – When Updates are not the Best Option

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:

  1. No version change with backported fixes
    To maintain compatibility, especially in long-term support environments, security fixes are selectively backported to older versions. Since the version number does not change or only slightly, scanners report a vulnerability even though it has already been fixed. This is particularly common with Debian packages.
  2. No exploitability of the vulnerability
    In many configurations, not all functions of a software or library are used. If a vulnerability only occurs in a function that is not used in the specific environment, it is effectively not exploitable. Since scanners lack this contextual knowledge, they still report a risk. If an update is associated with complications or incompatibilities, it may be more reasonable to accept a non-exploitable vulnerability.

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.

Implementation with Nubus for Kubernetes

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.

Entry Points into the BSI IT-Grundschutz

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:

  1. The technical guideline BSI TR-03183 on requirements for manufacturers and products, based on the supply chain security defined in the “Cyber Resilience Act” (CRA). The guideline consists of three parts, of which part 2 covers SBOMs and part 3 covers VEX.
  2. The requirements for software manufacturers such as Univention in the BSI IT-Grundschutz catalog, described in CON.8 “Software Development”. This includes, for example, CON.8.A6 (obligation to use trustworthy software components) and CON.8.A8 (provision of checksums and signatures).
  3. The requirements for operators of software, described in the “OPS” modules, such as OPS.1.1.3.A10 (verification of signatures before using software packages) and OPS.1.1.3.A15 (handling of updates to protect against newly discovered vulnerabilities).

Extended Benefit: License Compliance

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.

Taking Responsibility as a Software Manufacturer

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

hackergotchi for Qubes

Qubes

Qubes OS 4.2 approaching end of life

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.)

What does end-of-life (EOL) mean?

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.

What about patch releases?

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.

How are EOL dates determined?

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.

27 April, 2026 12:00AM

April 24, 2026

hackergotchi for Deepin

Deepin

Security Update, Upgrade Recommended | deepin 25.1 Official Release Announcement

🔔 Dear deepin users and community members, deepin 25.1 is here! This update includes an emergency fix for the recently discovered “Pack2TheRoot” high-risk vulnerability, along with an optimization for the audio device loss issue that some recent upgraders have experienced. We strongly recommend that everyone update as soon as possible. I. Update Details – April 23, 2026 Fixed audio device loss on some systems. Removed some outdated intelligent mirror sources and resolved update failures caused by IP bans for certain users. Patched several known CVE security vulnerabilities (including the “Pack2TheRoot” high‑risk vulnerability) to improve system security. Explanation of the Emergency ...Read more

24 April, 2026 01:50AM by xiaofei

April 23, 2026

hackergotchi for Tails

Tails

Tails 7.7

New feature

Detection of outdated Secure Boot certificates

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.

Notification: Secure Boot Update Needed

Changes and updates

Fixed problems

  • Make the /root folder only readable by the root user. (#21514)

For more details, read our changelog.

Get Tails 7.7

To upgrade your Tails USB stick and keep your Persistent Storage

  • 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.

To install Tails 7.7 on a new USB stick

Follow our installation instructions.

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

To download only

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

23 April, 2026 12:00AM

April 21, 2026

hackergotchi for ZEVENET

ZEVENET

Live Webinar Preview: How Web Applications Fail (Load Balancing, WAF & Cybersecurity)

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.

  • They degrade.
  • They get stressed.
  • They get exploited.

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.

What you’ll see

During the session, attendees will experience real-world scenarios in action, including:

Traffic spikes and DDoS behavior

How infrastructure reacts when demand suddenly increases and how performance can degrade before any alert is triggered.

SQL Injection attempts

How malicious requests blend into normal traffic and how they can be detected and mitigated before causing damage.

Cross-Site Scripting (XSS) attacks

How attackers can manipulate application behavior and silently redirect users without their knowledge.

Load balancing and failover in action

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:

Register here

21 April, 2026 03:00PM by Isabel Perez

hackergotchi for Deepin

Deepin

April 20, 2026

hackergotchi for ARMBIAN

ARMBIAN

Github Highlights

Github Highlights

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.

Changes

20 April, 2026 04:20PM by Michael Robinson

hackergotchi for GreenboneOS

GreenboneOS

Fortinet’s Disclosure Includes Two Critical Unauthenticated RCE Flaws Affecting FortiSandbox And More

On April 14th and 15th, Fortinet disclosed 27 new vulnerabilities affecting a wide range of its products. The most severe of the new flaws, CVE-2026-39808 (CVSS 9.8) and CVE-2026-39813 (CVSS 9.8) allow unauthenticated remote code execution (RCE) on the FortiSandbox service. FortiSandbox is Fortinet’s remote sandboxing and malware analysis service, distributed as on premises hardware […]

20 April, 2026 10:53AM by Joseph Lee

hackergotchi for VyOS

VyOS

Power 5 Podcast: VyOS 1.5 LTS for Red Hat OpenShift Virtualization

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.

🎧 Listen now

20 April, 2026 05:30AM by Gizem Yigit (g.yigit@vyos.io)

April 19, 2026

hackergotchi for Qubes

Qubes

XSAs released on 2026-04-17

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

XSAs that DO affect the security of Qubes OS

The following XSAs do affect the security of Qubes OS:

XSAs that DO NOT affect the security of Qubes OS

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

  • (none)

About this announcement

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

19 April, 2026 12:00AM

QSB-112: Floating Point Divider State Sampling (XSA-488)

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


             ---===[ 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

Marek Marczykowski-Górecki’s PGP signature

-----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

Simon Gaiser (aka HW42)’s PGP signature

-----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

What is the purpose of this announcement?

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

What is a Qubes security bulletin (QSB)?

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

Why should I care about QSBs?

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

What are the PGP signatures that accompany QSBs?

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

Why should I care whether a QSB is authentic?

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

How do I verify the PGP signatures on a QSB?

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

  1. 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.)

  2. 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
    
  3. 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.

  4. 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
    
  5. 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.
    
  6. 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
    
  7. 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.

  8. 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.

19 April, 2026 12:00AM

April 17, 2026

hackergotchi for Purism PureOS

Purism PureOS

PureOS Crimson Development Report: March 2026

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

April 16, 2026

hackergotchi for ARMBIAN

ARMBIAN

We rewrote how Armbian installs desktops. Here's what changed

A friendlier, faster, snap-free desktop install in armbian-config

We rewrote how Armbian installs desktops. Here's what changed

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.

Pick the desktop you want at install, and after

Three tiers, instead of one all-or-nothing install:

  • minimal DE + display manager + a terminal. About 500 MB. Perfect for headless boards with an occasional HDMI session, or anyone who&aposd rather curate apps themselves.
  • mid adds a WWW browser, file manager, image viewer, media player, calculator, archive tool, torrent client, and the SD-card flasher. About 1 GB. The "everyday desktop" sweet spot.
  • full adds LibreOffice, GIMP, Inkscape, Audacity, Thunderbird, and VS Code. About 2.5 GB. Workstation-shaped.

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.

Snap-free Chromium, Firefox, and Thunderbird

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.

One desktop, every supported distro and arch

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.

Clean uninstall, every time

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."

The little stuff that&aposs easy to miss

  • Auto-login that doesn&apost trash your config. Enable / disable autologin for gdm3, sddm, or lightdm via in-place sed edits your WaylandEnable=false and other tweaks survive.
  • Container-aware. Same code path works inside Docker without trying to start a display manager. CI builds and scripted installs work without special-casing.
  • U2F security keys. Plug in your Yubikey and WebAuthn just works the udev rules ship via libfido2-1 on resolute, libu2f-udev on older releases.
  • Printer panel works. GNOME Settings → Printers no longer says "some settings cannot be unlocked" — cups-pk-helper ships with every desktop install now.
  • VS Code from us, not Microsoft&aposs repo. Installing 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 weekly self-audit catches drift

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.

Try it

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

April 15, 2026

hackergotchi for ZEVENET

ZEVENET

What Happens When Your Web Application Fails? | Live Webinar (May 14)

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

I want my spot

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.

Bluella-Skudonet-Live Webinar

Why Web Applications Fail (And Why It’s Not About Bugs)

Most teams still assume that application failures are caused by bugs.

But in reality, that’s rarely the case.

  • Applications don’t simply “break”.
  • They get overwhelmed.
  • They get attacked.
  • They behave in ways that are difficult to predict.

And here’s the real issue:

By the time teams notice something is wrong, it’s already too late.

 What Really Happens Before Downtime

  • Traffic spikes can silently degrade performance before any alert is triggered
  • DDoS attacks don’t always look like attacks at first
  • Malicious requests blend in with legitimate traffic
  • Infrastructure appears stable until it suddenly isn’t

And when this happens, the impact is not only technical: it’s operational, it’s financial and it’s personal.

  • For CTOs and IT leaders, it means uncertainty and pressure (not knowing if the infrastructure will hold when it matters most).
  • For engineers and DevOps teams, it means firefighting under stress, trying to understand what’s happening without full visibility.
  • For developers, it means dealing with issues that are not in the code, but still affecting application behavior and user experience.

The result is always the same:

  • Loss of control.
  • Delayed reaction.
  • And in many cases, avoidable downtime.

The Real Problem: Lack of Visibility and Control

The root problem is not just traffic or security.

It’s lack of visibility and control.

In many environments:

  • Load balancing is managed in one place
  • Security tools operate in isolation
  • Monitoring is fragmented

This creates blind spots.

And blind spots are where failures begin.

From Reaction to Control

Understanding the problem is important.

But what really matters is seeing how it happens and how it can be controlled.

Modern infrastructures need to:

  • Detect anomalies early
  • Manage traffic intelligently
  • Block malicious requests in real time
  • Maintain availability under pressure

This is where visibility and control become critical.

See It in Action: Live Webinar

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

What You’ll See

During the live session, attendees will experience:

  • How DDoS attacks and traffic spikes impact application availability in real time
  • How SQL Injection attempts are identified and mitigated before they escalate
  • How Cross-Site Scripting (XSS) attacks can silently redirect users without their knowledge
  • How load balancing and failover mechanisms ensure continuity under pressure

All demonstrated live, showing how these challenges can be handled in practice using SKUDONET’s platform.

Who Should Attend

This session is designed for:

  • Infrastructure and DevOps engineers
  • Security teams and architects
  • CTOs and IT decision-makers
  • Organizations running critical applications

If you want to understand what really happens behind application failures  and see how to handle it in practice:

Reserve your spot

15 April, 2026 10:50AM by Isabel Perez

hackergotchi for Tails

Tails

Tails 7.6.2

This release is an emergency release to fix an important security vulnerability in the confinement of Tor Browser.

Changes and updates

  • 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.

Get Tails 7.6.2

To upgrade your Tails USB stick and keep your Persistent Storage

  • 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.

To install Tails 7.6.2 on a new USB stick

Follow our installation instructions.

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

To download only

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

15 April, 2026 12:00AM

hackergotchi for Qubes

Qubes

QSB-111: xfce4-screensaver login bypass

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


             ---===[ 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

Marek Marczykowski-Górecki’s PGP signature

-----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

Simon Gaiser (aka HW42)’s PGP signature

-----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

What is the purpose of this announcement?

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

What is a Qubes security bulletin (QSB)?

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

Why should I care about QSBs?

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

What are the PGP signatures that accompany QSBs?

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

Why should I care whether a QSB is authentic?

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

How do I verify the PGP signatures on a QSB?

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

  1. 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.)

  2. 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
    
  3. 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.

  4. 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
    
  5. 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.
    
  6. 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
    
  7. 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.

  8. 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.

15 April, 2026 12:00AM

April 14, 2026

hackergotchi for GreenboneOS

GreenboneOS

Patch Now! Critical-Severity Flaws in Cisco SSM On-Prem and IMC, Plus More

In early April, Cisco announced two critical-severity CVEs along with additional high and medium-severity vulnerabilities. Collectively, the flaws allow authentication bypass, privilege escalation to an Administrator account, unauthenticated remote code execution (RCE) as the root user, information disclosure, and Denial of Service conditions. The two critical flaws are CVE-2026-20160 (CVSS 9.8) affecting Cisco Smart Software […]

14 April, 2026 11:01AM by Joseph Lee

hackergotchi for Univention Corporate Server

Univention Corporate Server

Nubus for Kubernetes 1.19 Released

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.

Prepared for Automated Security Checks

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:

  • vulnerabilities that have already been fixed by patches without scanners recognizing this
  • CVEs in (transitive) dependencies whose affected code paths are not executed in Nubus at all
  • generic assessments without reference to the actual configuration or usage

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.

VEX: Context for Security Assessments

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:

  • a vulnerability has already been resolved
  • it exists in a dependency but is not used in the product
  • or the specific configuration is not affected

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.

Concrete Benefits for Operators

  • significantly fewer false positives in automated security scans
  • better prioritization of actually relevant vulnerabilities
  • reduction of manual analysis and review efforts
  • integration of manufacturer assessments into existing security tools
  • a more solid basis for security-related decisions

VEX thus helps transform a large number of technical individual findings into contextualized and reliable security information.

Simplified Identifier in the Provisioning API

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.

Concrete Added Value for Integrations and Operations

  • a clear, stable identifier as the central reference for all objects
  • direct access via the id field without additional mapping logic
  • reduced complexity in integrations and interfaces
  • lower risk of errors due to ambiguous or mutable IDs
  • clearer API structure and improved maintainability

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.

Availability

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

hackergotchi for ARMBIAN

ARMBIAN

Github Highlights

Github Highlights

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.

Changes

14 April, 2026 03:05AM by Michael Robinson

hackergotchi for Deepin

Deepin

April 10, 2026

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

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

10 April, 2026 05:21AM by sun, ruonan

deepin 25.1.0 Release Note

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

10 April, 2026 04:53AM by xiaofei

April 09, 2026

hackergotchi for ZEVENET

ZEVENET

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

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

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

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

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

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

The Trust Crisis Nobody Wants to Talk About

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

This isn’t a matter of subjective perception.

According to the Sophos report:

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

And the consequences are tangible:

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

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

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

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

Why This Is Urgent

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

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

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

According to 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.

Why Trusting Cybersecurity Providers Is So Difficult

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

Lack of Real Visibility

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

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

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

Vendor Lock-in

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

This translates into:

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

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

Fragmented Security

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

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

What Makes a Cybersecurity Solution Truly Trustworthy

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

A trustworthy solution must offer:

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

The Problem with Many Current Solutions

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

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

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

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

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

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

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

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

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

Practical Case: From Fragmented Infrastructure to Full Control

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

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

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

After migrating to an ADC architecture with integrated WAF:

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

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

How SKUDONET Fits Into This Picture

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

Its architecture integrates into a single platform:

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

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

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

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

Trust in Cybersecurity Is Architecture, Not Promises

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

The questions are:

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

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

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

Where to Start

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

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

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

Discover how it works

 

09 April, 2026 03:28PM by Isabel Perez