Do you want to know what I like to write about? You've found the right place!


Blog


I've recently migrated my server and services from the cloud to my homelab server. Blame it on me or blame it on the economy, but I found it more reasonable to pay for a small server once rather than rent a VPS. A cheap VPS is always great, but as soon as you need higher performance, the numbers add up quickly.

Thus, I bought and set up a 1-liter computer as a homelab server. As my IP address isn't static, and I don't trust my ISP's firewall enough to expose my home IP, I decided to configure a dual-server setup, my homelab server as the backbone, and a VPS acting as the front-facing edge. That way, I don't expose my real home IP address, only the VPS is public.

To connect the homelab with the VPS, a VPN made the most sense. I've self-hosted OpenVPN before, and remembered that, although a great solution, it's too complex for my current needs. Configuring tunnels, routes, ciphers, certificates, as well as ports, clients, and keys, was too much work. I also had used Pritunl before, but even this seemed too complex for such a simple need: connecting two devices.

Enter WireGuard. I had heard of it before, but never got to use it. If it is supposed to be simpler, it may just fulfill my needs, won't it? _"Let's quickly read the documentation"_, I thought.

What I didn't expect is to be left with tears of joy at how simple everything is. Just configure peers, as well as your public and private keys. _"That can't be it, though, right? I'm surely missing something?"_, I thought to myself. But nope. That is it, that is everything. No hidden magic, no unnecessary fluff, no need to configure special tunnel routing or DNS. Forget about self-signed certificates and deciding ciphers.

I installed WireGuard on my homelab server and on the VPS, configured peers and keys, and was ready to go. With the `wg-quick` tool, the entire IP dance is also automated. The only things I had to configure additionally were a keepalive, as my homelab is behind a NAT, as well as the MTU, since my ISP's router disagreed with the automatic MTU detection.

My homelab server is now fully configured, and, at the time of writing, this blog article is being served from my homelab over WireGuard to my VPS, then delivered to you. Mission accomplished, without getting any (additional) gray hairs.

---

For the curious about the homelab itself, I got a second-hand Lenovo ThinkCentre M75q-1 Tiny. It's so small and quiet; it's living happily in my living room, alongside my Android TV. Still, it has more than enough power for all my needs.

If you're more interested in this device or similar ones, I've found [this blog article](https://www.servethehome.com/lenovo-thinkcentre-m75q-1-tiny-review-project-tinyminimicro/) (no affiliation) to be pretty insightful.

WireGuard is stupidly simple


Well, it's bad. You've probably heard about it already. Around two weeks ago the [XZ backdoor](https://en.wikipedia.org/wiki/XZ_Utils_backdoor) was found by Andres Freund.

If not: In a nutshell, a bad actor worked since 2021 in many small steps to gain trust and gain control as a maintainer of the XZ Utils project -- a compression utility used in one way or another in most, if not all, Linux distributions. The backdoor would allow the attacker to execute arbitrary code on virtually every single Linux server. But luckily the backdoor was found before it could be exploited.

We may have dodged a bullet here. But this sets a precedent. This might not be the first time a backdoor was found in a widely used software, but this case is different. The attacker worked for years to gain trust and control. This is a new level of attack, and it's more difficult to prevent.

The question is: How can we prevent this from happening again? Is it even possible to prevent?

I don't have the answer, and I'm sure a lot of genius people are working hard on solving this.

And another question also arises: Are we completely sure that there's no other backdoor out there on other widely used software? I mean, it's naive to think there's none -- there's surely something somewhere, on an open-source project or not. But it will take a lot of effort to find them. Who's going to do it?

I could try and end this post with a positive note, "We can be glad we were lucky this time", but no. We can't count on luck. We need to be proactive and find measures to prevent this from happening again. Make such attacks impossible...

... and goddamn help maintainers of such projects! Projects that are in use virtually everywhere, but nobody gives them the attention they deserve. It's sad, but the [xkcd 2347](https://xkcd.com/2347/) remains true.

And as long as it's true, events like this will happen.

---

As I'm primarily a web developer, I remember events like [event-stream](https://www.theregister.com/2018/11/26/npm_repo_bitcoin_stealer/) and [colors / faker](https://www.bleepingcomputer.com/news/security/dev-corrupts-npm-libs-colors-and-faker-breaking-thousands-of-apps/), which happened for similar reasons. But the state of frontend packages on the web is a whole another can of worms...

Also, you can find a great timeline of events and more insightful links on [Evan's blog](https://boehs.org/node/everything-i-know-about-the-xz-backdoor).


Concerning the XZ backdoor


Hello you!

As you may see, this is the first blog entry in my website.
I've had this idea of writing a blog for a long time, but I never came
to doing it. Now it's here, and it's here to stay!

I plan to write mostly about programming- and informatics-related topics.
Maybe also about other topics, but I haven't decided it yet. We'll see!


Blog

2026

WireGuard is stupidly simple

2024

Concerning the XZ backdoor

2021

Hello world