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.

Let’s consider a standard situation where you have a main work computer on which you have three different projects.
One project is on nodejs, the second is a production project on python, and the third is your personal “pet project”, also on python.
You also have personal and work email in the same system, and, say, a browser and home-banking.
And all this under your login.
Well, not under the root login, of course! ¯\_(ツ)_/¯
Everything is quite normal.

Many technically competent developers may have dozens of such projects.
And dozens of keys for SSH or GIT servers.

An example with the popular PyTorch framework

It’s quite ordinary: you write your code, commit it from time to time, and then a torchtriton update arrives in your cozy pet project.
And after that, the following data sets were transferred from your system, in accordance with the binary’s main function:

• Get system information:
  • nameservers from /etc/resolv.conf
  • hostname from gethostname()
  • current username from getlogin()
  • current working directory name from getcwd()
  • environment variables
• Read the following files:
  • /etc/hosts
  • /etc/passwd
  • The first 1,000 files in $HOME/*
  • $HOME/.gitconfig
  • $HOME/.ssh/*

The update arrived and the confidential data flew away.
It’s not just everything under your account (and possibly the system) has been compromised, but also, down the chain, everything you managed, committed to, and connected to.

Without going into detail about how exactly and why everything is organized, access is provided through the following chain:

1

Nginx stream ingress <> Main Nginx Frontend <> Nginx Backend inside GitLab instance.

The Main Frontend manages the gitlab subdomain, which is closed to external access via auth_basic authorization.

In this note I will not provide the full code for all components, I will only give snippets and tips on what to pay attention to when assembling a site on jekyll.

File modification time

Every page has at least three timestamp points in different files, page elements, or server responses, and they must all be the same.

• ld+json "dateModified": "2025-03-07T15:43:42+00:00"
• sitemap <lastmod>2025-03-07T15:43:42+00:00</lastmod>
• headres last-modified: Fri, 07 Mar 2025 15:43:42 GMT