Below is a set of snippets for configuring WireGuard for three different Linux distributions and FreeBSD.
The setup assumes a Debian server with a 10.9.21.0/24 network.

Server, Debian

apt install wireguard-tools
nano /etc/network/interfaces.d/wg0

auto wg0
iface wg0 inet static
    address 10.9.21.1/32
    pre-up ip link add wg0 type wireguard
    pre-up wg setconf wg0 /etc/wireguard/wg0.conf
    up ip -4 route add 10.9.21.0/24 dev wg0
    # up /bin/systemctl restart sshd.service
    post-down ip link del wg0

umask 077
cd /etc/wireguard/
wg genkey > server-private.key
wg pubkey < server-private.key > server-public.key

nano /etc/wireguard/wg0.conf

[Interface]
ListenPort = 1234
PrivateKey = <server-private.key>

[Peer]
# Debian client
PublicKey = <public.key>
AllowedIPs = 10.9.21.3/32

[Peer]
# CentOS client
PublicKey = <public.key>
AllowedIPs = 10.9.21.4/32

[Peer]
# Ubuntu client
PublicKey = <public.key>
AllowedIPs = 10.9.21.5/32

[Peer]
# FreeBSD client
PublicKey = <public.key>
AllowedIPs = 10.9.21.6/32

A good addition to the collection.
The news needs to be given time to settle, and then the details can be savored.

• Red Hat, RED HAT, CARL!
• GitHub Actions, as usual.
• NPM, we’re already used to it.
• Arch User Repository, it’s already more interesting.

Let’s rebuild Nginx with CVE-2026-9256 patch according to the Debian-way.

A critical vulnerability in nginx allows remote code execution with the privileges of the nginx worker process by sending a specially crafted HTTP request.
But that’s not the point.
The problem is that Debian maintainers are in no hurry to release a new patch package.

• Security Bug Tracker CVE-2026-9256
• NGINX ngx_http_rewrite_module vulnerability CVE-2026-9256

apt --no-install-recommends \
    --no-install-suggests install \
    build-essential \
    fakeroot \
    devscripts

nano /etc/apt/sources.list

# trixie sources
deb-src https://deb.debian.org/debian/ trixie main contrib non-free non-free-firmware
deb-src http://security.debian.org/debian-security/ trixie-security main contrib non-free non-free-firmware
deb-src https://deb.debian.org/debian/ trixie-updates main contrib non-free non-free-firmware

Only six months had passed, but the news feed continued to bring new funny vulnerabilities.
As usual, I don’t focus on system vulnerabilities in snapd / Rust Coreutils / Flatpak, or kernel (Copy Fail, Dirty Frag, Fragnesia, pidfd, PinTheft, GRO Frag) or AppArmor.

No matter how dangerous they may be, they are “conditionally” passive, meaning that if they are present, a number of factors and active actions from within or outside are required for successful exploitation.

I’m much more interested in tracking compromises of package distribution systems, libraries, and other package repositories.

Because these are “active” and direct attacks, they require almost no combination of factors; after downloading, they will immediately hit the developer’s repository, then collect their personal/financial/authorization information, and then continue to act in a chain fashion on all servers to which they had access.

Continuing with the previous boring opuses about environment isolation, it’s time to remember Wayland.
Of course, this is not a call to action, but just simple examples and reflections.
I personally adhere to a philosophy where the user is the center of the system, and he has the right to configure everything as he sees fit, and not as it is imposed by general trends, or as it is implemented in a specific distribution, at the same time understanding and accepting all the risks and consequences of these actions.
As the saying goes, “If you know what you are doing.”

And before we begin, it’s worth writing again that:

• Yes, I understand that this is all very superficial.
• Yes, any connections to the local graphical shell are not allowed for anything dangerous, and you must use VNC or virt-viewer/spice.
• Unprivileged LXC should be replaced with Xen / KVM
• And yes, I know that it is possible to breakout from KVM isolation too.
• I know about Flatpak.
• And finally, yes, I have known about Qubes OS and its architecture, let’s say, since its inception, which was 2010.

And, simplifying and adapting QubesOS ideas to my everyday needs, I prefer to use either other local users or lightweight unprivileged LXC environments.

And yes, I don’t run anything potentially dangerous in them, but rather something that many of you use directly under your system account, for example:

• Firefox for everyday use and casual browsing.
• Several projects using packages from PyPI, RubyGems.
• Separately, what I compile from sources from GitHub.
• Third-party programs, such as element-desktop, Telegram, Zoom.