Planet Debian Derivatives

Ubuntu en Modo Congelado Cambios que desaparecen al reiniciar

2026-03-14T17:13:18+00:00

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

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

Sorry, this entry is only available in 中文.

Fedora 42 approaching end of life

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

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

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

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

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

Qubes Canary 046

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

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

Qubes Canary 046

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


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

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

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

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

3. The Qubes Master Signing Key fingerprint is:

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

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

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


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

None.


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

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

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

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

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


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

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

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

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

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

Source: Blockchain.info
000000000000000000017245ca11dddd962050ba2ce7fb38f0ab6a10d4a9cf00


Footnotes
----------

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

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

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

Source: canary-046-2026.txt

Marek Marczykowski-Górecki’s PGP signature

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

Simon Gaiser (aka HW42)’s PGP signature

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

What is the purpose of this announcement?

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

What is a Qubes canary?

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

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

Why should I care about canaries?

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

What are some signs of an unhealthy canary?

Here is a non-exhaustive list of examples:

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

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

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

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

What are the PGP signatures that accompany canaries?

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

Why should I care whether a canary is authentic?

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

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

How do I verify the PGP signatures on a canary?

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

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

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

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

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

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

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

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

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

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

Use Git to clone the qubes-secpack repo.

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

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

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

Verify signed Git tags.

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

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

Verify PGP signatures, e.g.:

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

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

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

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

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

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

2026-03-12T17:23:03+00:00

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

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

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

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

In this article we will analyze:

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

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

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

Why OWASP CRS Remains the Standard for WAF Protection

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

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

Among the threats it can detect are:

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

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

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

How the OWASP CRS Inspection Pipeline Works

The ModSecurity Phase Model

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

Simplified pipeline:

Each phase analyzes a different part of the traffic.

Phase 1

Analyzes information available immediately:

HTTP headers
URI
query string
request metadata

Phase 2

Analyzes the full content of the request:

request body
POST parameters
JSON
XML
complex payloads

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

A Subtle Issue in OWASP CRS

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

ARGS_GET
REQUEST_URI
QUERY_STRING

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

This means that a request such as:

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

Host: example.com

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

From a security perspective, this raises an obvious question:

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

The Security Principle: Fail Fast

In system architecture there is a fundamental principle:

Fail Fast

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

Applied to a WAF, this means:

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

Not later.

How Modern High-Performance Reverse Proxies Work

Modern reverse proxies are designed to reduce:

latency
memory consumption
buffering

To achieve this, many proxies operate in streaming mode.

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

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

Simplified flow:

But when combined with OWASP CRS, a problem appears.

The Conflict Between High-Performance Proxies and OWASP CRS

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

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

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

From a security perspective, this is suboptimal.

Architecture Comparison: Traditional Pipeline vs Fail Fast

High-Performance Proxy with Traditional CRS

Result:

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

Fail Fast Pipeline

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

Applying the SKUDONET Fail Fast Approach to the WAF

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

The idea is simple:

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

This requires partially reorganizing the logic of OWASP CRS rules.

Technical Example: CRS Rules That Can Be Evaluated Earlier

A simplified CRS rule example might look like this:

SecRule ARGS_GET “@detectSQLi” \

“id:942100,\

phase:2,\

block,\

msg:’SQL Injection Attack Detected'”

Here we see the key issue:

phase:2

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

Conceptually, an early detection could be evaluated like this:

SecRule REQUEST_URI “@detectSQLi” \

“id:942100,\

phase:1,\

block”

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

Want to see how this works in practice?

Try the SKUDONET WAF Demo

Early Evaluation (Phase 1)

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

headers
URL
query string

Examples of early detection include:

SQL injection in the URL
command injection
path traversal
header anomalies

Simplified flow:

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

Deep Evaluation (Phase 2)

When the body arrives, the second inspection phase runs:

This phase enables the detection of more complex attack patterns.

Conclusion

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

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

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

This approach allows organizations to:

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

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

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

FAQ

What is fail fast in cybersecurity?

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

What is OWASP CRS?

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

Why can OWASP CRS delay attack detection?

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

Why is the fail fast principle important for reverse proxies?

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

What role does a WAF play in an ADC?

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

See Fail Fast WAF Protection in Action

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

Start the SKUDONET Demo

deepin App Store Upgraded!

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

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

Greenbone’s OPENVAS SCAN Now Covers Red Hat 10 and Rocky Linux 10 Security Advisories!

2026-03-11T13:38:15+00:00

Operating system (OS) security updates are critical for maintaining a strong enterprise security posture. OS vulnerabilities in on-prem and cloud assets, fleets of staff workstations, development environments, container hosts, virtualization platforms, and edge infrastructure may offer an attacker the initial access they need to execute a costly cyber attack. Linux, especially Red Hat Enterprise Linux […]

MWC Barcelona 2026 Recap: Driving the Future of Open Networking

2026-03-11T10:09:44+00:00

Another MWC Barcelona has come to an end, and what a strong week it was for VyOS Networks.

We were proud to be part of one of the most important global gatherings in telecom, cloud, and infrastructure, where we met with customers, partners, and industry leaders navigating familiar challenges: vendor lock-in, licensing complexity, fragmented tooling, and growing performance demands across cloud, edge, and on-prem environments.

That is exactly where VyOS continues to stand out.

(中文) 微信终于支持聊天记录导入导出，deepin 应用商店直接更

2026-03-11T02:23:13+00:00

Sorry, this entry is only available in 中文.

VyOS Project March 2026 Update

2026-03-10T13:11:57+00:00

Hello, Community! The somewhat belated development update that covers changes in the VyOS rolling release in February is finally here. A lot of our attention in February went to VyOS Stream 2026.02, promoting VyOS at MWC Barcelona 2026, and the ongoing work on VyOS 1.5.0. However, there are quite a few updates in rolling that are worth a mention, including support for background operations in the HTTP API, multiple VPP CLI design improvements, and a whole bunch of bug fixes.

R_evolution: a small webapp to explain Human Evolution

2026-03-09T16:14:25+00:00

In 2023 I was invited to give a lecture on human evolution at our local high school (Liceo Bertrand Russell). In that occasion I developed a digital presentation with the open source tool impress.js and Strut, using the open material of the exhibition "Facce. I molti volti della storia umana" and integrating a webapp done with Odyssey.js, o create an interactive journey through hominid fossils, linking their geographical locations with the forensic facial reconstructions we realized at Arc-Team.

Fast forward to today: I had to give the same lesson, so I decided to dust off that old project, but as often happens with "vintage" web code, it was broken.

The Power of Open Source AI

To bring the project back to life, I experimented with OpenCode, an Open Source AI application. The process was surprisingly smooth; the AI helped me refactor the legacy code and fix the dependencies that had broken over the years.

This sparked an idea: why keep this resource on a local drive when it can still serve a purpose?

Introducing "r_evolution"

I’ve created a new GitHub repository called r_evolution. It’s a simple, functional web app where you can explore the map of human evolution and see the facial reconstructions of our ancestors.

Live Demo: https://lucaarcteam.github.io/r_evolution/r_evolution.html
Source Code: Check it out on GitHub (feel free to fork!)

A Call for Collaboration

Currently, the app is in Italian, as it was born for a local context. However, in the spirit of Open Research, I would love for the community to help:

Translate the content into English (or other languages).
Update the data with newer fossil discoveries.
Improve the code for better mobile compatibility.

It was great to see students engaging with these reconstructions once again. It’s a reminder that Open Source isn't just about the tools we use today, but about the "digital stratigraphy" we leave behind—and how easy it is to revive it when the foundations are open.

Stay Open and have a nice day!

The r_evolution webapp

February 2026 Threat Report: A River of Perpetual Risk

2026-03-09T11:23:11+00:00

February 2026’s cyber security headlines were dominated by the sudden emerging risk of CVE-2026-20127, a critical-severity vulnerability in Cisco Catalyst SD-WAN. However, this month, other high-risk vulnerabilities impacting widely deployed enterprise software also opened new gaps for attackers to exploit. To effectively defend IT infrastructure, security teams need granular visibility, reliable threat intelligence for prioritization, […]

ElectronMail

2026-03-05T16:20:06+00:00

There is a new application available for Sparkers: ElectronMail What is ElectronMail? Features: – Open Source – Reproducible builds – Cross platform – Full-text search – JavaScript-based/unlimited messages filtering – Offline access to the email messages – Multi accounts support – Automatic login into the app – Automatic login into the email accounts – Persistent email account…

Source

deepin Community Monthly Report for February 2026

2026-03-05T06:24:47+00:00

Learn more about deepin details, historical versions, user reviews, etc.: https://distrowatch.com/table.php?distribution=deepin I. February Community Data Overview II. Community Products 1. deepin 25.0.12 Internal Testing Launched: File Manager Enhancements, Multi-Screen & Audio Issues Fixed In February, the deepin 25 internal test version 25.0.12 was released, focusing on expanding file manager functionality and optimizing system stability: File Manager Efficiency Upgrade: Supports right-click to pin top tabs, allowing important directories to remain permanently accessible; when previewing images, the sidebar supports drag-and-drop enlargement, making viewing images more efficient for work. Email Function Enhancement: Added email printing feature to meet daily office needs. High-Frequency Issue Fixes: Resolved issues such ...Read more

(中文) UOS AI / OpenClaw 都能用！社区大神整活，玲珑商店 Skill 来了！

2026-03-03T02:19:51+00:00

Sorry, this entry is only available in 中文.

Emergency Patch: CVE-2026-20127 in Cisco Catalyst SD-WAN Actively Exploited Against Critical Infrastructure

2026-03-02T13:47:06+00:00

! Update March 6, 2026 New Actively Exploited Flaws in Cisco Catalyst SD-WAN Of the five additional vulnerabilities affecting Catalyst SD-WAN that were disclosed in a second security report the same day, CVE-2026-20128 CVSS 7.5 and CVE-2026-20122 CVSS 5.4 are now reported by Cisco as actively exploited in the wild. No PoCs for either CVE […]

Sparky news 2026/02

2026-03-01T15:43:58+00:00

The 2nd monthly Sparky project and donate report of the 2026: – Linux kernel updated up to 6.19.5, 6.18.15-LTS, 6.12.74-LTS, 6.6.127-LTS – Sparky 8.2 Seven Sisters released – added Linux kernel 6.18 LTS to sparky repos; 6.6 LTS will be not updated any more Many thanks to all of you for supporting our open-source projects. Your donations help keeping them and us alive. Don’t forget to send…

Source

[STABLE RELEASE] Bunsenlabs Carbon Official ISOs

2026-02-27T00:00:00+00:00

The BunsenLabs team are happy to announce our latest release, BunsenLabs Carbon.

Based on Debian Trixie, Carbon has had many improvements, including a new desktop appearance and assistance (coming soon) for users who want to experiment with Wayland.

If you have liked BL in the past, you're going to love this.

There is much more detail in the Release Notes: https://forums.bunsenlabs.org/viewtopic.php?id=9675

Downloads are available from the BunsenLabs website: https://www.bunsenlabs.org/installation.html

A big thank you to all the community members who contributed feedback, suggestions and code!

The BunsenLabs Team

Tails 7.5

2026-02-26T00:00:00+00:00

Changes and updates

Update Tor Browser to 15.0.7.
Simplify the home page of Tor Browser.
Update the Tor client to 0.4.9.5.
Update Thunderbird to 140.7.1.
Install Thunderbird as additional software to improve its security, if you have both the Thunderbird Email Client and Additional Software features of the Persistent Storage turned on.

Until Tails 7.5, a new version of Thunderbird was released by Mozilla only a few days after we released a new version of Tails. As a consequence, the version of Thunderbird in Tails was almost always outdated, with known security vulnerabilities.

By installing Thunderbird as additional software, the latest version of Thunderbird is installed automatically from your Persistent Storage each time you start Tails.

If the Thunderbird Migration dialog below appears when you start Thunderbird, it means that Tails successfully installed Thunderbird as additional software.
Include the language pack for Mexican Spanish in Thunderbird in addition to the language pack for Spanish from Spain.

For more details, read our changelog.

Get Tails 7.5

To upgrade your Tails USB stick and keep your Persistent Storage

Automatic upgrades are available from Tails 7.0 or later to 7.5.
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.5 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.5 directly:

VyOS Stream 2026.02 is available for download

2026-02-25T12:32:59+00:00

Hello, Community!

VyOS Stream 2026.02 is available for download now. It features multiple backports from the rolling release, including TLS support for syslog, NAT66 source groups, IPFIX support in VPP, FRR and VPP updates, and over fifty bug fixes. It also makes the VPP configuration subsystem use DPDK as the default driver for NICs that support it and fall back to XDP automatically if needed — there is no need to and no option to configure the driver by hand anymore.

Stable Clonezilla live 3.3.1-35 Released

2026-02-24T11:36:15+00:00

This release of Clonezilla live (3.3.1-35) includes major enhancements and bug fixes.

ENHANCEMENTS AND CHANGES SINCE 3.3.0-33

The underlying GNU/Linux operating system was upgraded. This release is based on the Debian Sid repository (as of 2026/Feb/20).
The Linux kernel was updated to 6.18.9-1.
Partclone was updated to 0.3.45.
Implemented mechanisms for cloning 4kn disks to 512n/e disks and 512n/e disks to 4kn disks. Thanks to john (zx1100e1).
Improved functions do_ntfs_512to4k_fix and do_ntfs_4kto512_fix by updating Total Sectors (Offset 40) for NTFS.
Added a new program, ocs-pt-512-4k-convert, to convert 512B to 4kn partition tables.
Rewrote ocs-expand-gpt-pt to be more robust, including 512B to 4kn conversion if mismatched sectors are detected.
Added a mechanism to change the master key from a LUKS header. Thanks to nbergont for the contribution.
Rewrote ocs-get-nic-fw-lst to retrieve firmware lists directly from Linux kernel modules.
Added two more info files in image dir: fdisk.list and blkdev.json. Thanks to arij for the suggestion.
Included makeboot64.cmd instead of makeboot64.bat in the live system. Thanks to Tom Hoar.
Improved BitLocker support: partitions now work on the clone server (ocs-onthefly), and the system now prompts for passwords again if entered incorrectly. Thanks to Marcos Diez.
Enabled the "-edio" (Direct I/O) option in the TUI by default.
Restricted the "-smtd" and "-smmcb" options enabled by default to non-x86-64 machines.
Added the 'lsb-release' package to the live system.
The time synchronization mechanism can now be disabled if ocs_time_sync="no" is assigned in the boot parameters.
Updated Brazilian Portuguese translation. Thanks to Rafael Fontenelle.

BUG FIXES

Fixed an issue in function udp_send_part_img_or_dev where multicast sending from raw devices failed for partitions with unknown filesystems; it now utilizes partclone.dd.
Fixed a bug where ocs-get-dev-info failed to identify extended partitions on MBR disks.
Removed extra LVM and LUKS information in dev-fs.list that previously caused partition order errors and failed network clones via ocs-onthefly. Thanks to kokutou kiritsugu for reporting this.
Resolved a bug related to restoring MTD/eMMC devices.
Appended '--rescue' to partclone options to bypass mtdblock read errors.
Fixed a bug where ocs-sr could not find devices using a PTUUID.
Updated ocs-live-run-menu to set the TERM as fbterm so box-drawing characters display correctly. Thanks to ottokang for identifying this.
Improved ocs-blk-dev-info efficiency and removed double quotation marks from model and serial outputs to prevent menu breakage. Thanks to pete-15.
Updated ocs-cvt-dev to avoid name collisions during the conversion process.

Nubus for Kubernetes 1.17: Release Highlights

2026-02-23T15:04:19+00:00

With this blog post, I am starting a new series in which I present the updates of the roughly monthly Nubus for Kubernetes releases. We begin with a look back at version 1.17, which was released at the end of January and brings many improvements for Nubus operators – including the new Structured Logging format for Kubernetes.

Structured Logging

Since version 1.17, Nubus for Kubernetes offers a new output format for log entries: Structured Logging. This uses the open standard logfmt and generates log outputs that are easy to process both for humans and log analysis tools.

This makes auditing and monitoring in well-known log analysis tools such as the ELK Stack or Grafana Loki significantly easier. Nubus sends the log entries directly to these or other analysis tools available in the data center, where they can be evaluated together with information from other software solutions.

Details on the log format can be found in the release notes and will also be documented in the Nubus Manual in the future.

Moving Away from ingress-nginx

The Ingress in a Kubernetes cluster is responsible for managing external access to the services running inside. It primarily acts as a reverse proxy for HTTP connections and for HTTPS encryption. This Kubernetes component is also modular, allowing operators to choose between different implementations.

Currently, Nubus for Kubernetes in the delivered Helm charts only supports the ingress-nginx implementation. This was long the standard but recently an end of it’s maintenance has been announced. Therefore, operators are forced to switch to other Ingress solutions.

With version 1.17, the dependency on ingress-nginx has been reduced, enabling the use of other implementations in the future. With the upcoming release 1.18 all dependencies will be removed and Nubus will be tested with traefik and HA-Proxy Ingress.

UDM and Provisioning Move Closer Together

The Provisioning component of Univention Nubus ensures that changes from the Univention Directory Manager (UDM), such as new users or groups, are passed on to other systems. Previously, provisioning used its own library, the so-called Transformer, to convert data from the directory service into the Nubus data model.

In version 1.17, this functionality was integrated directly into the UDM REST API. This means that the data model is now consistent throughout, complexity is reduced, and errors caused by different implementations are avoided. For operators, this means more reliable processes with less maintenance effort.

Updates, Updates, Updates

With each release of the Nubus for Kubernetes container images, the underlying open-source software is also updated. Version 1.17 therefore brings numerous small bug fixes and security updates. All details can be found in the release notes.

Der Beitrag Nubus for Kubernetes 1.17: Release Highlights erschien zuerst auf Univention.

HackMetu’26, Pardus ve Siber Güvenlik Temasıyla ODTÜ’de Gerçekleştirildi

2026-02-23T07:09:46+00:00

HackMetu’26’da genç mühendislerle birlikte üretmenin heyecanını yaşadık. 21–22 Şubat 2026 tarihlerinde IEEE ODTÜ Öğrenci Kolu tarafından organize edilen etkinlik; #Pardus Projesi ve TBD Genç Ankara paydaşlığında gerçekleştirildi. 24 saatlik hackathon süresince genç geliştiriciler, Pardus ve Merkezi Yönetim Sistemlerini siber güvenlik perspektifiyle ele alarak uygulanabilir çözümler geliştirdi.

Sovereign IT with Open Source: How to Build Your Own Modular Application Stack

2026-02-20T07:09:18+00:00

Digital independence begins with IT architecture: organizations that want to operate IT services sovereignly need open standards, centralized identity management, and full control over users, roles, and access. This article describes how IAM becomes the solid foundation of a modular application stack – flexible, secure, future-proof, and easier than you might think.

Digital sovereignty is more than an internet hype or marketing slogan. It determines whether organizations can shape their processes themselves – or remain dependent on vendors, licensing models, and proprietary interfaces. The good news: by relying on open standards and open source, a wide variety of IT services can be seamlessly integrated – from file servers to specialized applications – allowing the step-by-step construction of a software stack optimized for one’s own needs, benefiting from its modularity and gaining independence from hyperscaler services.

For applications and services to work smoothly together, a connecting element is required: an Identity & Access Management (IAM) system that handles the integration and management of users, roles, and permissions – securely linking all applications and enabling cross-application data flows. Such an IAM manages user identities, regulates access rights, and allows the automation of entire process chains.
In short: without IAM, there is no application stack – at least not one that remains controllable in the long term.

Below, I will introduce central building blocks for a technically sound implementation of an open IAM and show which standards have proven effective and which architectural decisions make the difference – from single sign-on with OpenID Connect or SAML, single logout via frontend or backchannel logout, user lifecycle management with SCIM, a single source of truth for roles and contextual control of permission assignment, automation and deployment with Kubernetes & Helm, to provisioning.

IAM as the Foundation of a Sovereign Application Stack

Organizations that want to operate an application stack themselves need more than containers, computing resources, and a colorful mix of (open-source) components. The challenge lies in a well-thought-out architecture: how do all services interact cleanly – and how is the overview of access, roles, and data flows maintained?

This is exactly where Identity & Access Management (IAM) comes into play. As versatile as modern applications are, without centralized identity and access management, shadow identities, fragmented roles, and security gaps arise. Without overarching IAM, organizations sooner or later face the same problems as with traditional silo solutions: login credentials circulate via email, former employees retain unintended access to sensitive data, and no one really knows who has which rights. An open IAM solves these problems based on established protocols and interfaces.

A solid foundation alone does not yet make a secure house. The right building blocks are also needed – starting with authentication.

Diagram 1: Modular infrastructures managed centrally via a central Identity & Access Management with standardized interfaces

Building Block 1: Single Sign-on and Single Logout

A modern application stack often includes services such as file storage, webmail, video conferencing, office and project management software, or industry-specific applications. To prevent login from becoming increasingly complex and time-consuming for users across these applications, a central authentication mechanism is needed: single sign-on (SSO).

With SSO, users log in once and gain access to all connected services. Authentication is carried out using protocols such as OpenID Connect (OIDC) or SAML. Both are widely adopted open standards supported by almost all modern web applications.

SSO is convenient – but it only solves half the problem. While logging in usually works smoothly, logging out often falls short. Single logout (SLO) means that logging out once also closes all sessions in the connected services. In practice, this step is often overlooked – with consequences for security and data protection. Logging out of the email client does not automatically terminate sessions in the video conference service, file storage, or project platform – a potential avenue for misuse.

Depending on the protocol used, different single logout methods exist – for example, frontend logout, where the browser actively terminates all sessions, or backchannel logout, where the IAM communicates directly with connected services. Which method is possible depends on the capabilities of the respective application and the care taken in technical integration.

Reality shows: while SSO is often quickly hailed as a success, SLO is the real challenge. A missing logout mechanism may seem harmless, but it can become a security risk – especially with sensitive data or public workstations.

Building Block 2: User Lifecycle Management

Single sign-on enables convenient access to IT services, but what happens before and after? Proper user account management requires monitoring the entire lifecycle of identities: from creating new users or groups, through changes, to deletion. This is what user lifecycle management is about.

Many systems rely solely on the login event: an account is automatically created when someone logs in for the first time. This may suffice for simple scenarios – but for controlled, traceable IT management, this model is insufficient. What happens if someone never logs in? Or if a person leaves the organization?

Without centralized event control, shadow identities – accounts existing in the system but no longer linked to a person – emerge quickly. Rights and group memberships are difficult to synchronize, too. Losing oversight is not just an organizational issue but also a data protection and security problem.

For technical implementation, several approaches exist:

Via APIs – whether open or proprietary – data can often be written directly to target systems. This offers flexibility but usually comes with high integration effort and low reusability.
Directory services (e.g., LDAP-based) can serve as a shared source for user and group data but generally only work with systems that actively access them.
System for Cross-domain Identity Management (SCIM) is an open standard for provisioning identity data. It allows events like account creation, name changes, or deletion to be transmitted automatically and standardized between systems – including groups and permissions.

Comprehensive user lifecycle management with SCIM or a comparable mechanism is not only more convenient but also safer. It prevents data remnants, reduces errors, and allows identities to be managed consistently across system boundaries – regardless of the size or heterogeneity of the stack.

If you would like to explore the topic of User Lifecycle Management in more depth and learn how our IAM solution Nubus enhances security, efficiency, and compliance in schools and enterprises, you can find further insights in this article: https://www.univention.com/blog-en/2025/10/user-lifecycle-management-nubus/

Diagram 2: Manage digital identities centrally with Nubus and provide them across applications

Building Block 3: Permissions and Roles

Access alone is not enough – equally important is the question: what is a user allowed to do within an application? An open IAM must not only manage identities but also assign and control permissions in a differentiated manner. Groups, roles, and permissions must be represented so they can be automatically transferred to different applications. Many IAM systems rely on role models assigning certain rights to user groups – e.g., “teacher,” “employee,” “project manager,” or “admin.”

Technically, there are two common approaches:

OIDC allows roles and permissions to be included in claims, which contain information such as groups, role names, or attributes – e.g., role=project-admin. This works well but requires IAM and applications to agree on what each term means. It is not standardized.
SCIM goes a step further: it explicitly defines how entitlements and roles can be provisioned. Groups and rights can be transferred and kept consistent across systems – provided the target application fully supports SCIM. Like OIDC, IAM and applications must agree on the meaning of entitlements.

In practice, limits are quickly reached. Many applications interpret claims differently or ignore entitlements entirely. To be safe, a clear architectural decision is required: there must be a leading instance where users, roles, and permissions are managed – a single source of truth. An IAM ideally fulfills this role: storing rights centrally, synchronizing them with other systems, and remaining independent of specific applications.

In addition to static role-based permissions, contextual control is gaining importance: who can access what, when, where, and from which device – modern IAM systems can represent these conditions in a granular manner. This results in a permissions model that is not only differentiated but flexible enough for hybrid scenarios.

Automation and Deployment with Kubernetes & Helm

Organizations that want to reliably operate open components like IAM, directory services, office applications, or file storage need a platform that enables repeatable deployments, updates, and integrations – even in running operations.

Kubernetes has become the standard in many organizations for operating containerized applications scalably and resiliently. Combined with the Helm package manager, complex setups like an IAM with associated services can be described declaratively, installed automatically, and reproduced as needed – e.g., in test, integration, and production environments.

In self-built application stacks, this is essential: without automated deployment, releases quickly become confusing, configurations inconsistent, and extensions risky. Kubernetes and Helm provide structure and make it easier to operate IAM modularly, update it regularly, and integrate it traceably. Prerequisite for this repeatability is a consistent continuous delivery approach. Only when builds, tests, and deployments are standardized and automated can the quality of the overall system be reliably ensured – across many components.

Secure Integration of Existing Systems

Many organizations already have established infrastructures – e.g., a central Active Directory for user management. Achieving digital sovereignty does not require starting from scratch; existing systems can be cleverly integrated.

When introducing an open IAM, it is often sensible to include existing directories initially and import or synchronize identity data from them. In hybrid scenarios, the new IAM can become the leading system or run in parallel to the existing directory, gradually replacing it step by step.

Technically, several options exist: manual exports can be implemented quickly but are error-prone and unsustainable. Better are connections via LDAP, SCIM, or API, where changes in user data are retrieved automatically or event-driven. Crucial is that processes like onboarding, role assignment, and offboarding work seamlessly – regardless of where the data is maintained.

In practice, a gradual transition is often advisable: existing systems remain initially, while new components are integrated and tested according to standards. This allows a controlled change – without loss of functionality but with growing control.

Open Source in Practice: Examples of Sovereign IT

A modular application stack consists of more than individual services – the interaction between them is decisive. Only when identities, roles, applications, and data flows are integrated via open standards does an architecture emerge that can be operated independently, adapted, and sustainably maintained. That this is practicable even in very large environments is demonstrated by the project openDesk, promoted by the Zentrum für Digitale Souveränität.

openDesk relies on a combination of proven open-source components: Open-Xchange for email and calendar, Nextcloud for files, Collabora for online document editing, Element for messaging, OpenProject for project management – and the IAM Nubus from Univention GmbH, which as a central link enables the technical interaction of the components and convenient access to all services via a modern portal. The modular setup works – for example at the Robert Koch-Institut and in the Bundestag administration.

Nubus demonstrates the important role an open IAM can play: it not only manages identities but also centrally controls access rights and provides this information via open interfaces. An example is the ambitious open-source project of the state of Schleswig-Holstein, which is currently building a new statewide directory service with Nubus. This will eventually replace the previous Active Directory environment and enable secure access to specialized applications, devices, and central IT systems – role-based, data protection compliant, and fully under local control.

Diagram 3: Modular infrastructures illustrated using the openDesk case study

To get started with a sovereign cloud infrastructure using Nubus as IAM, pre-configured integrations are helpful. For example, the Active Directory connection allows an open IAM to synchronize with an existing AD – including accounts, groups, and passwords. There are also ready-made integration packages for complete applications such as Nextcloud or Open-Xchange, which make connecting third-party software to Nubus particularly easy. Further packages are being developed and gradually released. Connector tools for Google Workspace, Apple School Manager, or Microsoft 365 also support single sign-on to these cloud services. These tools facilitate a smooth transition to open, controllable architectures – without having to replace everything immediately.

These projects show: digital sovereignty is not an abstract goal but can be concretely implemented with open source – step by step, traceably, and sustainably.

Conclusion: IAM as the Key to Digital Sovereignty

Digital sovereignty is not created by a product label but by an architecture that remains open, controllable, and adaptable. Organizations that want to operate IT services themselves or integrate them into existing structures need an IAM that grows with them – from authentication through roles and permissions to full automation.

Many organizations build their own IAM systems from LDAP, scripts, and database reconciliations in hopes of maximum flexibility. Such homemade solutions quickly hit limits: lack of logging, poor scalability, security risks. Using an established open-source IAM, by contrast, offers tested standards, community support, and extensibility – without technical debt.

A sovereign IT stack needs more than containers and services. Only with a central IAM can identities, roles, and access rights be reliably managed – across all applications. It is the connecting element that turns individual parts into a functional whole: interoperable, controllable, and sustainably maintainable.

This article has already been published in Informatik Aktuell and can be viewed here.

Do you want to ensure your digital operational capability even in emergency situations and keep critical IT services running reliably?
With “Nubus for Business Continuity”, a prepared, parallel IAM runs in standby mode, ready to take over immediately in a crisis and maintain access to applications, systems, and data. Learn how a sovereign IAM strategy can help you reduce risks and strengthen your IT resilience here: https://www.univention.com/solutions/nubus-for-business-continuity/

Der Beitrag Sovereign IT with Open Source: How to Build Your Own Modular Application Stack erschien zuerst auf Univention.

Privacy Under Siege

2026-02-18T16:55:58+00:00

Surveillance, Breaches, and Gaps in the Law It has become clear that privacy risks are not isolated incidents. They are part of a larger pattern. Major organizations continue to experience large scale data breaches. Brightspeed recently suffered a breach affecting around one million customers. Brightspeed opened an internal cybersecurity investigation in early January this year, after Crimson […]

The post Privacy Under Siege appeared first on Purism.

Sparky 8.2

2026-02-16T13:52:30+00:00

There is the second update available for Sparky 8 – 8.2. 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 February 14, 2026. – Linux kernel: 6.12.69-LTS (6.19.1, 6.12.72 LTS, 6.6.125-LTS in sparky repositories) …

Source

(中文) 你的 AI 还在"嘴炮"，别人的 AI 已经开始"干活"了

2026-02-14T09:06:28+00:00

Sorry, this entry is only available in 中文.

Mustafa Akgül Özgür Yazılım 2026 Kış Kampı Tamamlandı

2026-02-13T07:35:13+00:00

Afyon Kocatepe Üniversitesi ev sahipliğinde Linux Kullanıcıları Derneği (LKD) koordinasyonunda 4–8 Şubat 2026 tarihleri arasında düzenlenen Mustafa Akgül Özgür Yazılım 2026 Kış Kampı, özgür yazılım ve açık kaynak teknolojiler alanında önemli bir buluşma noktası oldu.

(中文) 玲珑商店社区版 2.0 时代开启！支持十余款发行版玲珑环境自动安装

2026-02-13T02:23:14+00:00

Sorry, this entry is only available in 中文.

32 bit support will end with BunsenLabs Boron

2026-02-13T00:00:00+00:00

Debian - on which BunsenLabs is based - have dropped 32 bit kernels, installers and iso images from the current stable Trixie release.

BunsenLabs will be forced to do likewise, and the upcoming Carbon release will have no 32 bit iso images, or 32bit package repositories.

Users with 32 bit machines can continue to use BunsenLabs Boron for as long as Debian Long Term Support for Bookworm continues, which is expected to be until June 30, 2028:
https://wiki.debian.org/LTS

Previous discussion:
https://forums.bunsenlabs.org/viewtopic … 48#p140748

January 2026 Threat Report: Off to a Raucous Start – Part 2

2026-02-11T10:20:56+00:00

So far, 2026 is off to a raucous start. With so much activity in the software vulnerability landscape it’s easy to understand the concerns of global executives discussed in Part 1 of the January 2026 Threat Report. This volatility also highlights the value of Greenbone’s industry-leading detection coverage. In Part 2 of the January Threat […]

(中文) Wine 应用适配新突破！3ds Max、WPS PDF 适配上线

2026-02-11T02:34:03+00:00

Sorry, this entry is only available in 中文.

Tails 7.4.2

2026-02-11T00:00:00+00:00

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

Changes and updates

Update the Linux kernel to 6.12.69, which fixes DSA 6126-1, multiple security vulnerabilities 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 DSA 6126-1 to take full control of your Tails and deanonymize you.

This attack is very unlikely, but could be performed by a strong attacker, such as a government or a hacking firm. We are not aware of this attack being used in practice.
Update Thunderbird to 140.7.1.

Fixed problems

Fix opening the Wi-Fi settings from the Tor Connection assistant. (#18587)
Fix reopening Electrum when it was not closed cleanly. (#21390)
Fix applying the language saved to the USB stick in the Welcome Screen. (#21383)

For more details, read our changelog.

Get Tails 7.4.2

To upgrade your Tails USB stick and keep your Persistent Storage

Automatic upgrades are available from Tails 7.0 or later to 7.4.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.4.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.4.2 directly:

Fedora 43 templates available for Qubes OS 4.3

2026-02-06T00:00:00+00:00

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

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

Note: Fedora 43 template availability for Qubes OS 4.2 will be announced separately.

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

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

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

deepin Community Monthly Report for January 2026

2026-02-05T10:14:06+00:00

Learn more about deepin details, historical versions, user reviews, etc.: https://distrowatch.com/table.php?distribution=deepin I. Overview of Community Data for January 2026 II. Community Products 2.1 Release of deepin 25.0.10 Version Image: Comprehensive Optimization of Installation Experience and System Interaction In January 2026, deepin officially released the deepin 25.0.10 system image, focusing on experience upgrades for the installation process, file management, and system interaction. Optimized System Installation Experience: Enhanced data formatting prompts during full-disk installation, supporting the retention of user data and reuse of original account configurations, simplifying system migration and upgrade processes. Improved File Manager Efficiency: Added features such as automatic scrolling during file drag-and-drop, ...Read more

January 2026 Threat Report: Off to a Raucous Start

2026-02-05T07:04:27+00:00

So far, 2026 is off to a raucous start. The number of critical severity vulnerabilities impacting widely deployed software is staggering. Defenders need to scan widely and scan often to detect new threats in their infrastructure and prioritize mitigation efforts based on the potential impact to business operations, privacy regulations, and other compliance responsibilities. Defenders […]

Sim Swap Attacks Surging

2026-02-04T18:26:59+00:00

SIM swap attacks are skyrocketing. A SIM Swap attack is when cybercriminals hijack mobile numbers by convincing carriers to transfer a victim’s phone number to a SIM card they control. Once successful, attackers intercept text-based authentication codes, unlocking access to cryptocurrency wallets, banking apps, and social media accounts.

The post Sim Swap Attacks Surging appeared first on Purism.

When Open Source Infrastructure Stops Being Easy to Operate

2026-02-04T13:18:27+00:00

Open Source infrastructure is often a deliberate and well-reasoned choice. It offers transparency, control and a level of flexibility that fits well with how many engineering teams like to build and operate systems. Deploying an open source load balancer or reverse proxy is usually a conscious decision, backed by solid documentation, community knowledge and proven behavior in production.

In most cases, it performs exactly as expected. Configuration is understandable, behavior is predictable and the system feels under control.

The challenge does not appear at deployment time. It emerges later, as traffic increases, environments expand and the same platform has to support more services, more changes and more operators. Configuration grows, operational tasks multiply and the margin for error narrows. Changes that were once straightforward start requiring coordination, validation and caution.

At that stage, the problem is not the software itself. The difficulty lies in operating open source infrastructure reliably as the system grows and operational demands increase.

An open-source load balancer in a growing environment

At this stage, most teams know the technology well. They trust Open Source and often run mature projects like HAProxy, NGINX, Apache, or even the SKUDONET Community Edition. These tools are proven, fast and predictable, and they give administrators full control over how traffic is handled.
As the environment grows, friction starts to appear:

A single configuration evolves into multiple files spread across environments
Changes require coordination across teams and systems
Visibility relies on logs that are not always centralized or easy to correlate
Updates and patches must be planned, tested and rolled out manually
High-availability setups work, but upgrading them without disruption becomes increasingly difficult

Security adds more pressure. Rules, ACLs or WAF logic exist, but tuning them safely takes effort. When something goes wrong, it is not always clear whether the issue comes from configuration, traffic patterns or the infrastructure itself.

None of this breaks the system. But it slows it down operationally. The load balancer still works, yet running it demands more time, more care and more experience than before. This is usually when teams start questioning whether relying only on community tooling is still the right model for their current scale.

The natural next step: teams start looking beyond community tools

When this point is reached, teams know what is not working and they start by looking around the ecosystem they already trust. Users of HAProxy, NGINX or Apache usually do not want to replace their stack. Instead, they evaluate the commercial or enterprise options built around the same technologies, expecting easier operation, better visibility and safer upgrades.
These editions typically promise:

centralized management
technical support
safer update and upgrade processes
additional security capabilities

The problem is that this promise does not always translate into simpler operations. Some enterprise versions keep much of the same operational complexity as the community tools, with configuration-heavy workflows and limited abstraction. Others introduce pricing models that grow quickly with traffic and environments, or platforms that are technically powerful but harder to operate on a daily basis.

SKUDONET Enterprise as the natural evolution from Open Source

SKUDONET Enterprise is designed to remove the operational friction that appears when Open Source infrastructure grows.

Configuration, traffic control and visibility are handled from a single plane, instead of being spread across files, nodes and environments. This reduces the effort required to introduce changes and lowers the operational risk.

In practice, this translates into:

Centralized management and visibility, without losing control over traffic behavior or routing logic
Simpler operations, where updates, high availability and scaling do not rely on complex or fragile maintenance workflows
Security that remains manageable, with clear insight into how rules behave and how traffic is affected
Operational continuity, even as environments, traffic volume and teams evolve

High availability, updates and maintenance are treated as part of the platform, not as separate projects that require careful coordination. Routine tasks no longer depend on manual processes or deep system-specific knowledge to be executed safely.

Integration remains straightforward. Existing architectures and deployment models stay in place, allowing teams to add Enterprise capabilities without redesigning their stack or introducing heavy control layers.

Pricing stays predictable as environments scale, avoiding the cost escalation and licensing complexity commonly associated with traditional commercial editions.
The result is a platform that preserves the technical foundations teams trust, while making infrastructure easier to operate, easier to maintain and easier to scale.

If you want to evaluate how this approach works in practice, you can try SKUDONET Enterprise with a 30-day demo and validate the fit in your own environment.

TRY ENTERPRISE DEMO

(中文) 先进生产力：在 deepin 25 上装 OpenClaw 接飞书

2026-02-04T10:05:58+00:00

Sorry, this entry is only available in 中文.

BunsenLabs Carbon Release Candidate 3 iso available

2026-02-03T00:00:00+00:00

BunsenLabs Carbon Release Candidate 3 iso is available here: https://sourceforge.net/projects/bunsen … hybrid.iso https://sourceforge.net/projects/bunsen … iso.sha256

sha256 sum: 47de769531fc0c99d9e0fa4b095ff280919684e5baae29fe264b9970e962a45f

Unless unexpected bugs come up, this should be the same as the Official Release of Bunsenlabs Carbon.

If you do find a new bug related to the Carbon RC3 iso, please post it in the Bug Reports section, adding a tag [Carbon RC3].

Sparky news 2026/01

2026-02-01T19:26:46+00:00

The 1st monthly Sparky project and donate report of the 2026: – Linux kernel updated up to 6.18.8, 6.12.68-LTS, 6.6.122-LTS – Added new desktop to Sparky testing (9): Labwc – Sparky 2026.01~dev2 Labwc released – changed ‘firefox-sparky’ packaga name to ‘firefox-latest’ Many thanks to all of you for supporting our open-source projects. Your donations help keeping them and us alive.

Source

Michael Prokop: apt, SHA-1 keys + 2026-02-01

2026-01-31T13:57:30+00:00

You might have seen Policy will reject signature within a year warnings in apt(-get) update runs like this:

root@424812bd4556:/# apt update
Get:1 http://foo.example.org/debian demo InRelease [4229 B]
Hit:2 http://deb.debian.org/debian trixie InRelease
Hit:3 http://deb.debian.org/debian trixie-updates InRelease
Hit:4 http://deb.debian.org/debian-security trixie-security InRelease
Get:5 http://foo.example.org/debian demo/main amd64 Packages [1097 B]
Fetched 5326 B in 0s (43.2 kB/s)
All packages are up to date.
Warning: http://foo.example.org/debian/dists/demo/InRelease: Policy will reject signature within a year, see --audit for details

root@424812bd4556:/# apt --audit update
Hit:1 http://foo.example.org/debian demo InRelease
Hit:2 http://deb.debian.org/debian trixie InRelease
Hit:3 http://deb.debian.org/debian trixie-updates InRelease
Hit:4 http://deb.debian.org/debian-security trixie-security InRelease
All packages are up to date.    
Warning:  http://foo.example.org/debian/dists/demo/InRelease: Policy will reject signature within a year, see --audit for details
Audit:  http://foo.example.org/debian/dists/demo/InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is:
   Signing key on 54321ABCD6789ABCD0123ABCD124567ABCD89123 is not bound:
              No binding signature at time 2024-06-19T10:33:47Z
     because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance
     because: SHA1 is not considered secure since 2026-02-01T00:00:00Z
Audit: The sources.list(5) entry for 'http://foo.example.org/debian' should be upgraded to deb822 .sources
Audit: Missing Signed-By in the sources.list(5) entry for 'http://foo.example.org/debian'
Audit: Consider migrating all sources.list(5) entries to the deb822 .sources format
Audit: The deb822 .sources format supports both embedded as well as external OpenPGP keys
Audit: See apt-secure(8) for best practices in configuring repository signing.
Audit: Some sources can be modernized. Run 'apt modernize-sources' to do so.

If you ignored this for the last year, I would like to tell you that 2026-02-01 is not that far away (hello from the past if you’re reading this because you’re already affected).

Let’s simulate the future:

root@424812bd4556:/# apt --update -y install faketime
[...]
root@424812bd4556:/# export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/faketime/libfaketime.so.1 FAKETIME="2026-08-29 23:42:11" 
root@424812bd4556:/# date
Sat Aug 29 23:42:11 UTC 2026

root@424812bd4556:/# apt update
Get:1 http://foo.example.org/debian demo InRelease [4229 B]
Hit:2 http://deb.debian.org/debian trixie InRelease                                 
Err:1 http://foo.example.org/debian demo InRelease
  Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on 54321ABCD6789ABCD0123ABCD124567ABCD89123 is not bound:            No binding signature at time 2024-06-19T10:33:47Z   because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance   because: SHA1 is not considered secure since 2026-02-01T00:00:00Z
[...]
Warning: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. OpenPGP signature verification failed: http://foo.example.org/debian demo InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on 54321ABCD6789ABCD0123ABCD124567ABCD89123 is not bound:            No binding signature at time 2024-06-19T10:33:47Z   because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance   because: SHA1 is not considered secure since 2026-02-01T00:00:00Z
[...]
root@424812bd4556:/# echo $?
100

Now, the proper solution would have been to fix the signing key underneath (via e.g. sq cert lint &dash&dashfix &dash&dashcert-file $PRIVAT_KEY_FILE > $PRIVAT_KEY_FILE-fixed).

If you don’t have access to the according private key (e.g. when using an upstream repository that has been ignoring this issue), you’re out of luck for a proper fix.

But there’s a workaround for the apt situation (related see apt commit 0989275c2f7afb7a5f7698a096664a1035118ebf):

root@424812bd4556:/# cat /usr/share/apt/default-sequoia.config
# Default APT Sequoia configuration. To overwrite, consider copying this
# to /etc/crypto-policies/back-ends/apt-sequoia.config and modify the
# desired values.
[asymmetric_algorithms]
dsa2048 = 2024-02-01
dsa3072 = 2024-02-01
dsa4096 = 2024-02-01
brainpoolp256 = 2028-02-01
brainpoolp384 = 2028-02-01
brainpoolp512 = 2028-02-01
rsa2048  = 2030-02-01

[hash_algorithms]
sha1.second_preimage_resistance = 2026-02-01    # Extend the expiry for legacy repositories
sha224 = 2026-02-01

[packets]
signature.v3 = 2026-02-01   # Extend the expiry

Adjust this according to your needs:

root@424812bd4556:/# mkdir -p /etc/crypto-policies/back-ends/

root@424812bd4556:/# cp /usr/share/apt/default-sequoia.config /etc/crypto-policies/back-ends/apt-sequoia.config

root@424812bd4556:/# $EDITOR /etc/crypto-policies/back-ends/apt-sequoia.config

root@424812bd4556:/# cat /etc/crypto-policies/back-ends/apt-sequoia.config
# APT Sequoia override configuration
[asymmetric_algorithms]
dsa2048 = 2024-02-01
dsa3072 = 2024-02-01
dsa4096 = 2024-02-01
brainpoolp256 = 2028-02-01
brainpoolp384 = 2028-02-01
brainpoolp512 = 2028-02-01
rsa2048  = 2030-02-01

[hash_algorithms]
sha1.second_preimage_resistance = 2026-09-01    # Extend the expiry for legacy repositories
sha224 = 2026-09-01

[packets]
signature.v3 = 2026-02-01   # Extend the expiry

Then we’re back into the original situation, being a warning instead of an error:

root@424812bd4556:/# apt update
Hit:1 http://deb.debian.org/debian trixie InRelease
Get:2 http://foo.example.org/debian demo InRelease [4229 B]
Hit:3 http://deb.debian.org/debian trixie-updates InRelease
Hit:4 http://deb.debian.org/debian-security trixie-security InRelease
Warning: http://foo.example.org/debian/dists/demo/InRelease: Policy will reject signature within a year, see --audit for details
[..]

Please note that this is a workaround, and not a proper solution.

Urgent Security Update | OpenSSL Multiple Vulnerabilities Fixed, Please Upgrade ASAP!

2026-01-30T10:05:41+00:00

🔔 Dear deepin Users and Community Members, Recently, OpenSSL has released multiple security vulnerability fix announcements, involving 13 security vulnerabilities, including 2 High/Medium-risk vulnerabilities. To ensure the security of your system, we strongly recommend all users upgrade the relevant packages as soon as possible. I. Vulnerability Information The CVE identifiers involved in this fix are as follows: CVE-2025-9230, CVE-2025-9231, CVE-2025-9232, CVE-2025-15467, CVE-2025-15468, CVE-2025-66199, CVE-2025-68160, CVE-2025-69418, CVE-2025-69419, CVE-2025-69420, CVE-2025-69421, CVE-2026-22795, CVE-2026-22796 Key High/Medium Risk Vulnerability Fixes CVE-2025-15467 | High CMS AuthEnvelopedData Parsing Stack Buffer Overflow: This vulnerability could lead to Remote Code Execution (RCE) under specific conditions. Immediate updating ...Read more

VyOS Project January 2026 Update

2026-01-30T09:00:00+00:00

Hello, Community! The belated development update for December 2025 and January 2026 is finally here.

We are getting closer to the 1.5 release but there's also quite a bit of work towards the future. In particular, there's good progress towards replacing the old configuration command completion mechanism with a VyConf-based equivalent, which will allow us to get rid of legacy command definition files eventually.

More immediate improvements include certificate-based authentication for OpenConnect, new operational commands for VPP, support for configuring watchdog timers, and multiple bug fixes.

Tails 7.4.1

2026-01-30T00:00:00+00:00

This release is an emergency release to fix critical security vulnerabilities in OpenSSL, a network encryption library used by Tor.

Changes and updates

Included software

Update the OpenSSL library to 3.5.4, which fixes DSA 6113-1, a set of vulnerabilities that could be critical. Using this set of vulnerabilities, an malicious Tor relay might be able to deanonymize a Tails user.

We are not aware of these vulnerabilities being exploited in practice.
Update the Tor client to 0.4.8.22.
Update Thunderbird to 140.7.0.

Fixed problems

Fix Gmail authentication in Thunderbird. (#21384)
Add a spinner when opening the Wi-Fi settings from the Tor Connection assistant. (#18594)

For more details, read our changelog.

Known issues

The homepage of Tor Browser incorrectly says you are still using Tails 7.4, even after you have upgraded to 7.4.1. It also links to the release notes for that older version.

If in doubt, to verify that you are using Tails 7.4.1, choose Apps ▸ Tails ▸ About Tails.

Get Tails 7.4.1

To upgrade your Tails USB stick and keep your Persistent Storage

Automatic upgrades are available from Tails 7.0 or later to 7.4.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.4.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.4.1 directly:

Why multi-tenant proxies make security decisions harder for applications

2026-01-29T08:23:45+00:00

In recent weeks, several incidents surfaced where content providers blocked traffic coming from multi-tenant proxies to stop automated attacks or illegal rebroadcasting. The countermeasure reduced the offensive surface, but also denied access to legitimate users travelling through the same channel. It illustrates a common issue: upstream security — security applied at proxies, CDNs or scrubbing centers before traffic reaches the application — does not always retain the context required to make good decisions.

The relevant point is not the individual incident, but what it exposes: when security runs upstream and multi-tenant, the backend loses semantics, session state and part of the operational timeline. This alters how attacks are detected, how they are mitigated, and how user continuity is preserved.

The issue is not that these proxies “fail”, but that their efficiency relies on sharing channel, capacity and enforcement across thousands of customers. The model optimizes cost and scale, but erodes signals that were historically essential for security and operations: origin, semantics, persistence and temporal correlation. Once those signals disappear, security stops being a purely defensive problem and becomes an operational decision problem.

Shared-proxy architectures and their operational trade-offs

Multi-tenant proxies — Cloudflare being the most visible reference — terminate TLS, filter bots, apply WAF rules, absorb DDoS and optimize latency before forwarding requests to the backend. Operationally, the model offers:

shared scale
economic amortization
simplified management

The problem emerges in the least visible layer: traffic identity. When thousands of customers share the same defensive channel, the IP address no longer represents a user, it represents the proxy. For the backend, origin stops being an identity signal and becomes a collective. Attackers, legitimate users and corporate SSO traffic exit through the same door.

Traditional web security largely assumed origin was enough to make decisions. In a multi-tenant model, that signal degrades and the system no longer separates legitimate from abusive behavior with the same clarity.

At that point the decision collapses to two choices:

block the channel → stops the attack but penalizes legitimate users
allow the channel → preserves continuity but lets part of the attack through

The difficulty is not having two options, but having to choose with incomplete information. That is where the multi-tenant model shows its real cost: it gains efficiency but loses context.

How upstream filtering fragments application context

Context loss is not just about hiding origin or masking IP. In production it appears across multiple planes, and — importantly — not in the same place nor at the same time. This fragments the operational timeline, weakens signals and complicates defensive decision-making.

TLS plane

When TLS negotiation and establishment happen before reaching the application, the backend stops seeing signals that do not indicate attack but do indicate degradation of legitimate clients, such as:

renegotiation attempts
handshake failures
client-side timeouts
cipher downgrades
inconsistent SNI

During brownouts or incident response, these signals matter because they describe the real client, not the attacker. In a multi-tenant proxy, that degradation disappears and the application only sees “apparently normal” HTTP. For continuity and SLO compliance, that information is lost in the wrong plane.

WAF plane

When filtering occurs before the application — at a proxy or intermediary — another effect appears: the backend sees the symptom but not the cause.
The real circuit is:

Request → WAF/Proxy → Block → END

but for the backend it becomes simply: less traffic

Without correlation between planes, root-cause analysis becomes unreliable. A drop in requests may look like failure, user abandonment or load pressure when it is in fact defensive blocking.

Session plane

In modern architectures, user state does not live in the connection but in the session: identity, role, flow position and transactional continuity. When session lives in a proxy or intermediary layer, the backend loses persistence and affinity. In applications driven by login, payment or transactional actions, this is critical.

The symptoms do not resemble an attack; they resemble broken UX:

unexpected logouts
interrupted payments
inconsistent login flows
failover correct from infrastructure perspective but wrong from user perspective

A typical case where infrastructure “works”, but the user churns because the flow cannot complete.

Observability plane

The quietest plane concerns who sees what and when. If logs, metrics and traces stay at the proxy or upstream service, the downstream side — the one closer to application and backend — becomes partial or blind.

Without temporal continuity across planes, the following increase:

time-to-detect
time-to-mitigate
internal noise
post-mortem cost

And, more importantly, real-time defensive decisions degrade — precisely where continuity matters.

From origin-based filtering to behavior-based decisions

In recent years, defensive analysis has shifted toward behavior. Where the client comes from matters less than what the client is trying to do. Regular timings, repeated attempts, invalid sequences, actions that violate flow logic, or discrepancies between what the client requests and what the application expects are more stable signals than an aggregated IP.

In short:

Question	Traditional signal	Relevant signal	Defensive value
Where does it come from?	IP / ASN / reputation	—	Low (ambiguous in multi-tenant)
What is it trying to do?	—	Behavior / semantics	High (context + intent)

Interpreting intent requires three planes that upstream proxies lose by design:

session (who and where in the flow)
semantics (what action is being attempted)
timeline (in what order things occur)

Without those planes, defensive decisions simplify. With them, they can be made precise.

The application-side plane where context actually exists

If context disappears upstream, the question is not “remove the proxy”, but locating where the information lives that distinguishes abuse from legitimate use. That information only exists where three things converge:

what the user does
what the application expects
what the system allows

That point is usually the application or the component immediately before it (typically an ADC or integrated WAF), where session, semantics, protocol, results and transactional continuity coexist.

A practical example:

login() → login_failed() → login_failed() → login_failed()

vs:

login() → 2FA() → checkout() → pay()

For the upstream proxy, both are valid HTTP. For the application, they are different intentions: abuse vs legitimate flow.

What matters here is not “blocking more”, but blocking with context — which in operations becomes the difference between:

blocking the channel
blocking the behavior

and, in service terms, between losing legitimate users or preserving continuity.

Where SKUDONET fits

SKUDONET operates in that plane closer to the application, without the constraints of the multi-tenant model. The approach is mono-tenant and unified: TLS, session, WAF, load-balancing and observability coexist in the same plane without fragmenting across layers or externalizing identity and semantics.

This has three operational consequences:

1. Origin retains meaning

No aggregation or masking. IP becomes useful again when combined with behavior.

2. Transactional flows maintain continuity

3. Timeline and semantics correlate

Errors, attempts and results occur in the same place, enabling precise decisions instead of global blocking.

Schematically:

Plane	Upstream multi-tenant	SKUDONET
Identity	Aggregated	Individual
Session	External	Local
Semantics	Partial	Complete
Observability	Fragmented	Correlated
Defense	Binary	Contextual
Continuity	Fragile	Transactional

From this plane, security stops being “block proxy yes/no” and focuses on blocking abuse while preserving legitimate users.

Conclusion

Multi-tenant proxies solve scale, cost and distribution. But continuity, semantics and intent still live near the application — because it is the only plane where full context exists.

If continuity and application-level context matter to your stack, you can evaluate SKUDONET Enterprise Edition with a 30-day trial.

TRY ENTERPRISE DEMO

(中文) 四大场景全覆盖：deepin/UOS 系统打印机配置指南

2026-01-28T03:02:39+00:00

Sorry, this entry is only available in 中文.

XSAs released on 2026-01-27

2026-01-27T00:00:00+00:00

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

XSAs that DO affect the security of Qubes OS

The following XSAs do affect the security of Qubes OS:

(none)

XSAs that DO NOT affect the security of Qubes OS

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

XSA-477
- This XSA affects only HVMs with shadow paging and tracing enabled. In Qubes OS, shadow paging and tracing are disabled at build time.
XSA-478
- This XSA affects only XAPI, which is an alternative toolstack. Qubes OS uses libxl instead of XAPI.
XSA-479
- This XSA affects only in-VM isolation, which Qubes OS does not rely on for security. We will still provide the fix for this issue at a later date, but it will not be accompanied by a Qubes security bulletin (QSB).

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.

(中文) 调试更高效，投递更省心！deepin 系统 Windows 应用兼容体验再优化

2026-01-26T10:24:41+00:00

Sorry, this entry is only available in 中文.

Igalia Multimedia contributions in 2025

2026-01-26T09:34:37+00:00

Now that 2025 is over, it’s time to look back and feel proud of the path we’ve walked. Last year has been really exciting in terms of contributions to GStreamer and WebKit for the Igalia Multimedia team.

With more than 459 contributions along the year, we’ve been one of the top contributors to the GStreamer project, in areas like Vulkan Video, GstValidate, VA, GStreamer Editing Services, WebRTC or H.266 support.

Igalia’s contributions to the GStreamer project

In Vulkan Video we’ve worked on the VP9 video decoder, and cooperated with other contributors to push the AV1 decoder as well. There’s now an H.264 base class for video encoding that is designed to support general hardware-accelerated processing.

GStreaming Editing Services, the framework to build video editing applications, has gained time remapping support, which now allows to include fast/slow motion effects in the videos. Video transformations (scaling, cropping, rounded corners, etc) are now hardware-accelerated thanks to the addition of new Skia-based GStreamer elements and integration with OpenGL. Buffer pool tuning and pipeline improvements have helped to optimize memory usage and performance, enabling the edition of 4K video at 60 frames per second. Much of this work to improve and ensure quality in GStreamer Editing Services has also brought improvements in the GstValidate testing framework, which will be useful for other parts of GStreamer.

Regarding H.266 (VVC), full playback support (with decoders such as vvdec and avdec_h266, demuxers and muxers for Matroska, MP4 and TS, and parsers for the vvc1 and vvi1 formats) is now available in GStreamer 1.26 thanks to Igalia’s work. This allows user applications such as the WebKitGTK web browser to leverage the hardware accelerated decoding provided by VAAPI to play H.266 video using GStreamer.

Igalia has also been one of the top contributors to GStreamer Rust, with 43 contributions. Most of the commits there have been related to Vulkan Video.

Igalia’s contributions to the GStreamer Rust project

In addition to GStreamer, the team also has a strong presence in WebKit, where we leverage our GStreamer knowledge to implement many features of the web engine related to multimedia. From the 1739 contributions to the WebKit project done last year by Igalia, the Multimedia team has made 323 of them. Nearly one third of those have been related to generic multimedia playback, and the rest have been on areas such as WebRTC, MediaStream, MSE, WebAudio, a new Quirks system to provide adaptations for specific hardware multimedia platforms at runtime, WebCodecs or MediaRecorder.

Igalia Multimedia Team’s contributions to different areas of the WebKit project

We’re happy about what we’ve achieved along the year and look forward to maintaining this success and bringing even more exciting features and contributions in 2026.

0 0

BunsenLabs Carbon Release Notes

2026-01-26T00:00:00+00:00

What's New in BunsenLabs Carbon? ================================

The BunsenLabs Session is now able to launch Wayland sessions, if the necessary apps and configurations are provided. In the near future a "plugin" metapackage will be available to add a base Wayland session to a BL Carbon system.

Several core apps have been changed to ones that support Wayland as well as X11,
or make theming simpler:
nitrogen > xwwall + feh
tint2 > xfce4-panel
lxappearance > nwg-look
lxterminal > xfce4-terminal
arandr > lxrandr
policykit-1-gnome (obsolete) > mate-polkit

These packages have been dropped from the default install:
xserver-xorg-video-intel (only needed for pre-2007 Intel graphics)
qt5-style-plugins

picom configs have been substantially updated to use the current picom, which now needs 3D acceleration and openGL.
(actual appearance settings have not been changed much)

A wrapper script has been added for pkexec under Wayland, and sudoedit is now used to edit files as root.
See:
https://forums.bunsenlabs.org/viewtopic … 01#p143401
https://forums.bunsenlabs.org/viewtopic … 42#p144442

A "bl-menu" command has been added so a menu can be started from the same launcher regardless of running on X11 or Wayland.

blob has seen a lot of work, eg:
- added support for saving and restoring xfce4-panel settings via xfconf
- added Carbon-Sage and Carbon-Bark presets
- older presets still use tint2 (it looks nice): users will be prompted to install it if necessary
- picom files in older presets have been updated so current picom does not crash

openbox and labwc config files have been moved to ~/.config/bunsen/openbox and ~/.config/bunsen/labwc
This means the location of the default openbox rc.xml has changed, but users' original ~/.config/openbox/bl-rc.xml will still exist, so they can either just open that and ~/.config/bunsen/openbox/rc.xml side by side and copy across any changes they want to keep, or use a GUI diff app to compare them (eg meld).
(Later, they can remove bl-rc.xml and bl-menu.xml)

xfce4-panel plugin icons are resized to match the panel with entries in ~/.config/gtk-3.0/gtk.css :

/* some buttons are too big */

#pulseaudio-button * { -gtk-icon-transform: scale(0.6); }

#xfce4-power-manager-plugin * { -gtk-icon-transform: scale(0.4); }

#battery-14 * { -gtk-icon-transform: scale(0.6); }
/* adjust the "#14" to match the widget ID of your battery plugin */

If the audio, power-manager-plugin or battery icons look the wrong size,
adjust the scale number to suit your desktop. (The battery icon is hidden by default.)

Two menu items in ~/.config/jgmenu/prepend.csv are commented out:
- Dropbox (bl-dropbox-pipemenu), which helps users to install and use Dropbox
- Choose Language (bl-setlocale), which lets users choose a locale if their login greeter does not offer that option

bl-exit now uses xfce4-screensaver for locking (it works on Wayland too).

BUNSEN_SESSION_TYPE environment variable is set to x11 or wayland and can be used by scripts etc.

XDG_CURRENT_DESKTOP environment variable is set to 'BunsenLabs:XFCE'

bunsen-meta-bluetooth now depends on libspa-0.2-bluetooth for pipewire support.

Apt signing keys are now installed to /usr/share/keyrings but till BL Nitrogen have a symlink from the old location in /etc/apt/trusted.gpg.d

live-build:
- use zstd compression
- ensure grub first boot menu entry shows "BunsenLabs"
- add Signed-By field to sources
- make sure en_US.UTF-8 locale is installed along with user's chosen locale

bl-welcome:
- rewrite welcome screen to take slightly less space (thanks to @sleekmason)
- offer to convert sources to deb822 format
- drop PAE test (no more 32 bit)

Set GTK4 apps to use dark theme by default in gsettings and add some limited support for theme setting:
https://forums.bunsenlabs.org/viewtopic … 80#p147480

CREDITS
=======

As always, many people have contributed, with special credit to:
@hhh
@micko01
@sleekmason
@greenjeans

And thanks to Pawel Czerwinski for the beautiful wallpaper that @hhh has adapted for Carbon!

POSSIBLE ISSUES
===============

1) 32bit isos and packages are not available from BL Carbon because Debian have dropped support.
See: https://forums.bunsenlabs.org/viewtopic … 94#p148894
Users of BL Boron with 32bit systems should not attempt to upgrade to Carbon. Boron will be supported as long as Debian Bookworm, ie until June 2028.

2) NOTE for Virtual Machine users:
If you get an unusable desktop when running Carbon on a VM you may need to disable compositing or enable OpenGL and 3d acceleration.

The compositor, picom 12.5-1, in Debian Trixie and BunsenLabs Carbon, requires OpenGL and 3D acceleration to work properly.

If your BunsenLabs Carbon desktop is unusable when running on a Virtual Machine,
you can:

a) Disable composition from the menu: User Settings > Compositor > Disable Compositing
You will lose round corners, shadows etc but the desktop will be usable.
To make it permanent: menu > User Settings > BunsenLabs Session > Edit autostart
and comment out this line:
bl-compositor --start

b) If your virtual machine manager supports it, enable OpenGL and 3D acceleration.
If you are using virt-manager:
In the settings menu, open up the Display Spice section:
Select Spice server for Type:, and None for Listen type.
Check the OpenGL checkbox. Hit Apply.
In the Video Virtio section:
Set Virtio for Model, and check the 3D acceleration checkbox. Hit Apply.

EDIT:
c) a third option is to uninstall picom and install compton. After logout/in you should still have transparency and drop shadows, but at the cost of losing picom's round corners.

Last edited by johnraff (Yesterday 02:44:14)

High availability is not redundancy — it’s operational decision-making

2026-01-23T10:39:01+00:00

For years, high availability (HA) was treated as a redundancy problem: duplicate servers, replicate databases, maintain a secondary site and ensure that if something failed, there was a plan B waiting. That model worked when applications were monolithic, topologies were simple, and traffic variability was low. Today the environment looks different: applications are split into services, traffic is irregular, encryption is the norm, and infrastructure is distributed. Availability is no longer decided at the machine level, but at the operational plane.

The first relevant distinction appears when we separate binary failures from degradations. Most HA architectures are designed to detect obvious “crashes,” yet in production the meaningful incidents are rarely crashes—they are partial degradations (brownouts): the database responds, but slowly; a backend accepts connections but does not process; the Web Application Firewall (WAF) blocks legitimate traffic; intermittent timeouts create queues. For a basic health-check everything is “up”; for the user, it isn’t.

From redundancy to operational continuity

Operational degradations in production are not homogeneous. In general, we can distinguish at least six categories:

Failure (binary crash)
Partial failure (works, but incompletely)
Brownout (responds, but not on time)
Silent drop (no error, but traffic is lost)
Control-plane stall (decisions arrive too late)
Data-plane stall (traffic is blocked in-path)

The component that arbitrates this ambiguity is the load balancer. Not because it is the most critical part of the system, but because it is the only one observing real-time traffic and responsible for deciding when a service is “healthy,” when it is degraded, and when failover should be triggered. That decision becomes complex when factors like TLS encryption, session handling, inspection, security controls or latency decoupled from load interact. The load balancer does not merely route traffic—it determines continuity.

In real incidents, operational ambiguity surfaces like this:

Phenomenon	Failure type	Detected by health-check	User impact	LB decision	Real complexity
Backend down	Binary	Yes	High	Immediate failover	Low
Backend slow	Brownout	Partial	High	Late / None	High
Intermittent timeouts	Brownout	Not always	Medium/High	Ambiguous	High
WAF blocking	Security	No	High	None	High
Slow TLS handshake	TLS layer	Partial	Medium	N/A	Medium
Session saturation	Stateful	No	High	Unknown	High
Session transfer	Operational	No	Medium	Late	Medium
DB degradation	Backend	Partial	High	Not correlated	High

There is also a persistent misconception between availability and scaling. Scaling answers the question “how much load can I absorb?” High availability answers a completely different one: “what happens when something fails?” An application can scale flawlessly and still suffer a major incident because failover triggered too late, sessions failed to survive backend changes, or the control plane took too long to propagate state.

Encrypted traffic inspection adds another layer. In many environments, TLS inspection and the Web Application Firewall sit on a different plane than the load balancer. In theory this is modular; in practice it introduces coordination. If the firewall blocks part of legitimate traffic, the load balancer sees fewer errors than the system actually produces. If the backend degrades but the firewall masks the problem upstream, there is no clear signal. Availability becomes a question of coupling between planes.

The final problem is often epistemological: who owns the truth of the incident? During an outage, observability depends on who retains context. If the balancing plane, the inspection plane, the security plane and the monitoring plane are separate tools, the post-mortem becomes archaeology: fragmented logs, incomplete metrics, sampling, misaligned timestamps, and three contradictory narratives of the same event.

So what does high availability actually mean in 2026?

For operational teams, the definition that best fits reality is this: High availability is the ability to maintain continuity under non-binary failures.
This implies:

understanding degradation vs true unavailability
basing decisions on traffic and context, not just checks
coordinating security, inspection and session
having observability at the same plane that decides failover
treating availability as an operational problem, not as hardware redundancy

Where does SKUDONET fit in this model?

SKUDONET Enterprise Edition is built around that premise: availability does not depend solely on having an extra node, but on coordinating in a single operational plane load balancing at layers 4 and 7, TLS termination and inspection, security policies, certificate management, and traffic observability. The goal is not to abstract complexity, but to place decision-making and understanding in the same context.

In environments where failover is exceptional, this coupling may go unnoticed. But in environments where degradation is intermittent and traffic is non-linear, high availability stops being a passive mechanism and becomes a process. What SKUDONET provides is not a guarantee that nothing will fail—such a guarantee does not exist—but an architecture where continuity depends less on assumptions and more on signals.

A 30-day evaluation of SKUDONET Enterprise Edition is available for teams who want to validate behavior under real workloads.

TRY ENTERPRISE DEMO

Breaking: XDG Adds Native Support for Linyaps

2026-01-23T09:54:47+00:00

In the world of Linux desktop computing, there exists a foundational "common language" that underpins all interoperability—the XDG specifications, developed and maintained by the freedesktop.org organization. XDG is the critical standard for solving Linux's ecosystem fragmentation and establishing unified resource access protocols. Whether you are an application developer or a distribution maintainer, ensuring your product runs well on a modern Linux desktop necessitates adherence to the XDG standard. It is the key cornerstone enabling the Linux desktop to evolve from "working in silos" to "unified collaboration." From desktop icons and application menus to system notifications and file dialogs, XDG specifications permeate every facet ...Read more

High availability is not redundancy — it’s operational decision-making

2026-01-22T08:27:03+00:00

From redundancy to operational continuity

Operational degradations in production are not homogeneous. In general, we can distinguish at least six categories:

Failure (binary crash)
Partial failure (works, but incompletely)
Brownout (responds, but not on time)
Silent drop (no error, but traffic is lost)
Control-plane stall (decisions arrive too late)
Data-plane stall (traffic is blocked in-path)

In real incidents, operational ambiguity surfaces like this:

Phenomenon	Failure type	Detected by health-check	User impact	LB decision	Real complexity
Backend down	Binary	Yes	High	Immediate failover	Low
Backend slow	Brownout	Partial	High	Late / None	High
Intermittent timeouts	Brownout	Not always	Medium/High	Ambiguous	High
WAF blocking	Security	No	High	None	High
Slow TLS handshake	TLS layer	Partial	Medium	N/A	Medium
Session saturation	Stateful	No	High	Unknown	High
Session transfer	Operational	No	Medium	Late	Medium
DB degradation	Backend	Partial	High	Not correlated	High

So what does high availability actually mean in 2026?

For operational teams, the definition that best fits reality is this: High availability is the ability to maintain continuity under non-binary failures.
This implies:

understanding degradation vs true unavailability
basing decisions on traffic and context, not just checks
coordinating security, inspection and session
having observability at the same plane that decides failover
treating availability as an operational problem, not as hardware redundancy

Where does SKUDONET fit in this model?

A 30-day evaluation of SKUDONET Enterprise Edition is available for teams who want to validate behavior under real workloads.

TRY ENTERPRISE DEMO

Evgeni Golov: Validating cloud-init configs without being root

2026-01-21T19:42:45+00:00

Somehow this whole DevOps thing is all about generating the wildest things from some (usually equally wild) template.

And today we're gonna generate YAML from ERB, what could possibly go wrong?!

Well, actually, quite a lot, so one wants to validate the generated result before using it to break systems at scale.

The YAML we generate is a cloud-init cloud-config, and while checking that we generated a valid YAML document is easy (and we were already doing that), it would be much better if we could check that cloud-init can actually use it.

Enter cloud-init schema, or so I thought. Turns out running cloud-init schema is rather broken without root privileges, as it tries to load a ton of information from the running system. This seems like a bug (or multiple), as the data should not be required for the validation of the schema itself. I've not found a way to disable that behavior.

Luckily, I know Python.

Enter evgeni-knows-better-and-can-write-python:

#!/usr/bin/env python3

import sys
from cloudinit.config.schema import get_schema, validate_cloudconfig_file, SchemaValidationError

try:
    valid = validate_cloudconfig_file(config_path=sys.argv[1], schema=get_schema())
    if not valid:
        raise RuntimeError("Schema is not valid")
except (SchemaValidationError, RuntimeError) as e:
    print(e)
    sys.exit(1)

The canonical¹ version if this lives in the Foreman git repo, so go there if you think this will ever receive any updates.

The hardest part was to understand thevalidate_cloudconfig_file API, as it will sometimes raise an SchemaValidationError, sometimes a RuntimeError and sometimes just return False. No idea why. But the above just turns it into a couple of printed lines and a non zero exit code, unless of course there are no problems, then you get peaceful silence.

"canonical", not "Canonical" ↩

(中文) 当 BMF 遇见玲珑：一款支持 AI 的音视频转换工具这样落地 deepin

2026-01-21T08:05:16+00:00

Sorry, this entry is only available in 中文.

CVE-2025-64155: In the Wild Exploitation of FortiSIEM for Unauthenticated Root-Level RCE

2026-01-20T07:53:25+00:00

On January 13th, 2026, Fortinet publicly disclosed and patched CVE-2025-64155 (CVSS 9.8) affecting FortiSIEM along with five additional vulnerabilities across its product line [1][2][3][4][5]. In particular, CVE-2025-64155 represents high-risk exposure; immediately after its release, active exploitation was reported. The flaw was responsibly disclosed to Fortinet almost six months ago (August 2025), by Horizon3.ai. Greenbone includes […]

deepin 25.0.10 Release Note

2026-01-19T05:41:29+00:00

In order to further optimize the deepin 25 system update experience and enhance stability, the deepin 25.0.10 image is now officially released. This update focuses on system installation experience, file management, system interaction, and stability, optimizing multiple high-frequency usage scenarios, fixing a large number of known issues, and improving system smoothness and reliability. Key Updates in This Release System Installer: Optimized the prompt text for data formatting during full-disk installation, now supporting the option to retain user data and reuse the original account data, configurations, and files. Comprehensive Upgrade of File Manager: Added practical features such as automatic scrolling during file ...Read more

Tails 7.4

2026-01-15T00:00:00+00:00

New feature

Persistent language and keyboard layout

You can now save your language and keyboard layout from the Welcome Screen to the USB stick. These settings will be applied automatically when restarting Tails.

If you turn on this option, your language and keyboard layout are saved unencrypted on the USB stick to help you type the passphrase of your Persistent Storage more easily.

Changes and updates

Update Tor Browser to 15.0.4.
Update Thunderbird to 140.6.0.
Update the Linux kernel to 6.12.63.
Drop support for BitTorrent download.

With the ongoing transition from BitTorrent v1 to v2, the BitTorrent v1 files that we provided until now can become a security concern. We don't think that updating to BitTorrent v2 is worth the extra migration and maintenance cost for our team.

Direct download from one of our mirrors is usually faster.

Fixed problems

Fix opening .gpg encrypted files in Kleopatra when double-clicking or selecting Open with Kleopatra from the shortcut menu. (#21281)
Fix the desktop crashing when unlocking VeraCrypt volumes with a wrong password. (#21286)
Use 24-hour time format consistently in the top navigation bar and the lock screen. (#21310)

For more details, read our changelog.

Get Tails 7.4

To upgrade your Tails USB stick and keep your Persistent Storage

Automatic upgrades are available from Tails 7.0 or later to 7.4.
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.4 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.4 directly:

Cloud security works, but not as a unified system

2026-01-14T10:25:42+00:00

Talking about cloud today is no longer about a technological trend, but about a central piece of the business. More and more companies are moving their infrastructure to cloud providers under the promise of less hardware, less maintenance, fewer licenses and less time spent on activities that do not generate value.

Much of that promise has been fulfilled. Cloud has democratized capabilities that only large organizations could access a few years ago. Launching a service, increasing capacity or deploying a new region is now easier, faster and more accessible.

However, as often happens with technology, the story changes when we zoom into operations. Cloud simplifies infrastructure, but it does not always simplify how that infrastructure is operated. And that nuance affects not only technical teams, but also the business itself.

Cloud providers don’t sell “solutions” — they sell components

The first point of friction does not appear in compute or storage, but in the services that accompany the infrastructure. This includes security, load balancing, TLS certificates, application firewalls, monitoring and observability.

In the cloud provider’s catalog, the technology is there, but it is sold as separate components. Security on one side, certificates on another, observability on another, and advanced capabilities billed as add-ons. The customer does not go without service, but is left with a recurring question: what exactly must be purchased to remain protected and operate reliably?

A less visible aspect also emerges: security is billed per event, per inspection or per volume of traffic. What used to be a hardware expense becomes a bill based on requests, analysis and certificates. Cloud solved hardware, but externalized the operational complexity of security.

Metrics and logs exist, but they are often fragmented, sampled and weakly correlated. Understanding what happened during an incident may require navigating multiple services and data models. Cloud promises security, but it rarely promises explanations.

And at its core this is not a technical problem, but a model problem. Cloud security is commercialized as a product but consumed as a service. And when there is a mismatch between how something is purchased and how it is used, friction eventually appears.

SkudoCloud as an example of the managed approach

This is the context in which SkudoCloud emerges — not to replace the cloud provider or compete as infrastructure, but to resolve the operational coherence between load balancing, security and visibility.

SkudoCloud is a SaaS platform that enables companies to deploy advanced load balancing and application protection without assembling separate modules, tools or services. From a single interface, organizations can:

manage SSL/TLS certificates
inspect encrypted traffic
apply WAF rules
distribute load across backends
and monitor application behavior

The most evident difference appears in security. In the modular cloud model, the customer must decide what to purchase, which rules to enable, how to correlate logs and how to keep everything updated. In a managed model like SkudoCloud, certificates, WAF, TLS inspection and load balancing behave as one coherent system.

This has direct consequences for the business:

it reduces operational uncertainty
it improves visibility during incidents
and it avoids billing models tied to traffic volume or number of inspections

Instead of acquiring security, companies acquire operability. Instead of assembling components, they obtain an outcome. That is the difference of a managed approach.

Conclusion

Cloud adoption is already a given. The real question now is how to operate it sustainably. Fragmentation was a natural side effect of the migration phase. Unification will likely be the central theme of the operational phase.

Cloud simplified servers. Now it is time to simplify operations.

Learn more about SkudoCloud Load Balancer

Planet Debian Derivatives

Ubuntu en Modo Congelado Cambios que desaparecen al reiniciar

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

Fedora 42 approaching end of life

Qubes Canary 046

Qubes Canary 046

Marek Marczykowski-Górecki’s PGP signature

Simon Gaiser (aka HW42)’s PGP signature

What is the purpose of this announcement?

What is a Qubes canary?

Why should I care about canaries?

What are some signs of an unhealthy canary?

Does every unexpected or unusual occurrence related to a canary indicate something bad?

What are the PGP signatures that accompany canaries?

Why should I care whether a canary is authentic?

How do I verify the PGP signatures on a canary?

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

Why OWASP CRS Remains the Standard for WAF Protection

How the OWASP CRS Inspection Pipeline Works

The ModSecurity Phase Model

Phase 1

Phase 2

A Subtle Issue in OWASP CRS

The Security Principle: Fail Fast

How Modern High-Performance Reverse Proxies Work

The Conflict Between High-Performance Proxies and OWASP CRS

Architecture Comparison: Traditional Pipeline vs Fail Fast

High-Performance Proxy with Traditional CRS

Fail Fast Pipeline

Applying the SKUDONET Fail Fast Approach to the WAF

Technical Example: CRS Rules That Can Be Evaluated Earlier

Early Evaluation (Phase 1)

Deep Evaluation (Phase 2)

Conclusion

FAQ

What is fail fast in cybersecurity?

What is OWASP CRS?

Why can OWASP CRS delay attack detection?

Why is the fail fast principle important for reverse proxies?

What role does a WAF play in an ADC?

See Fail Fast WAF Protection in Action

deepin App Store Upgraded!

Greenbone’s OPENVAS SCAN Now Covers Red Hat 10 and Rocky Linux 10 Security Advisories!

MWC Barcelona 2026 Recap: Driving the Future of Open Networking

(中文) 微信终于支持聊天记录导入导出，deepin 应用商店直接更

VyOS Project March 2026 Update

R_evolution: a small webapp to explain Human Evolution

The Power of Open Source AI

Introducing "r_evolution"

A Call for Collaboration

February 2026 Threat Report: A River of Perpetual Risk

ElectronMail

deepin Community Monthly Report for February 2026

(中文) UOS AI / OpenClaw 都能用！社区大神整活，玲珑商店 Skill 来了！

Emergency Patch: CVE-2026-20127 in Cisco Catalyst SD-WAN Actively Exploited Against Critical Infrastructure

Sparky news 2026/02

[STABLE RELEASE] Bunsenlabs Carbon Official ISOs

Tails 7.5

Changes and updates

Get Tails 7.5

To upgrade your Tails USB stick and keep your Persistent Storage

To install Tails 7.5 on a new USB stick

To download only

VyOS Stream 2026.02 is available for download

Stable Clonezilla live 3.3.1-35 Released

This release of Clonezilla live (3.3.1-35) includes major enhancements and bug fixes.

ENHANCEMENTS AND CHANGES SINCE 3.3.0-33

BUG FIXES

Nubus for Kubernetes 1.17: Release Highlights

Structured Logging

Moving Away from ingress-nginx

UDM and Provisioning Move Closer Together

Updates, Updates, Updates

HackMetu’26, Pardus ve Siber Güvenlik Temasıyla ODTÜ’de Gerçekleştirildi

Sovereign IT with Open Source: How to Build Your Own Modular Application Stack

IAM as the Foundation of a Sovereign Application Stack

Building Block 1: Single Sign-on and Single Logout

Building Block 2: User Lifecycle Management

Building Block 3: Permissions and Roles

Automation and Deployment with Kubernetes & Helm

(中文) 玲珑商店社区版 2.0 时代开启！支持十余款发行版玲珑环境自动安装