Cobra's bits (Posts about debian)

Debian 13

Cobra — Sun, 10 Aug 2025 13:14:47 GMT

Trixie is stable, Forky is the new testing.

Take the time to update your sources from the old sources.list to the new deb822 format!

apt modernize-sources
sed -i 's/trixie/forky/g' /etc/apt/sources.list.d/debian.source

Let's not encrypt?

Cobra — Mon, 30 Dec 2024 14:24:34 GMT

This blog is powered by Hiawatha, a light-weight webserver designed for security and ease of use. Consequently, Hiawatha comes with a script that allows one to easily request certificates from the Let's Encrypt initiative and (in conjunction with a daily cron job) to automagically renew them when the time has come.

This setup has worked almost flawlessly for several years. In 2021, I've received an information from Let's Encrypt that they would modify (as planned) their chain of trust, requiring corresponding changes in the LE_ISSUERS option in the configuration file of the script designated for requesting or renewing certificates.

I should have known that this change will happen every three years, but since I didn't receive any mail this time, it never occurred to me that the failure of renewal had this simple reason. Instead, I've searched everywhere for nonexisting error messages until I had run out of ideas. Without any options left, I've asked Haui for help, convinced that he would see light where I could see only dark. And it indeed didn't take him long to identify an outdated LE_ISSUERS value in the configuration file as the culprit.

We can easily look up the common name of the current certificate's issuer:

openssl x509 -in /etc/hiawatha/tls/pdes-net.org.pem -noout -text | grep CN

But that won't help if the current certificate is not renewed because of an outdated issuer. The present situation was different in that I've requested new certificates in September as a temporary (HOHOHO) workaround. These new certificates were issued with the new CN of R10, as compared to the old R3 in the configuration file, making it clear that the latter is outdated. It would have been so easy if I hadn't been such a fool and categorically ruled out this possibility. 🫥

Well, I may get old and useless, but I hope to recall once and for all that the authoritative instance for looking up the current issuer for Let's Encrypt can be found here: https://letsencrypt.org/certificates/. And if I don't, I'm sure to remember that I can find this information in my own blog. 🫩

Backdoor in xz

Cobra — Mon, 01 Apr 2024 11:50:12 GMT

The upstream xz repository and the xz tarballs have been backdoored.

This backdoor is very indirect and only shows up when a few known specific criteria are met. Others may be yet discovered! However, this backdoor is at least triggerable by remote unprivileged systems connecting to public SSH ports.

This supply-chain attack targets .deb- and .rpm-based distributions, but the backdoored versions of xz or xz-utils (5.6.0 and 5.6.1) have made it only into rolling-release distributions such as Fedora Rawhide, Debian Testing/Sid, OpenSuse Tumbleweed, and Archlinux (where it is inactive).

The server of this blog is running Debian Testing and had the compromised version of xz-utils installed since March 17. The backdoor was reported last Friday, March 29. I've installed the patch provided by Debian on Saturday, March 30, and examined the system logs, which do not show any evidence that the system has been compromised in any way. In fact, according to my current understanding, the system did not meet all the requirements for the backdoor to be executed. However, I will remain vigilant and let the users of the server know if further action needs to be taken.

More links (in German): Heise 30.03.2024 09:35, Heise 30.03.2024 22:28, Heise 02.04.2024 17:10

Debian 12

Cobra — Sun, 02 Jul 2023 13:04:04 GMT

A little late, but better late than never:

Bookworm is stable, Trixie is the new testing.

sed -i 's/bookworm/trixie/g' /etc/apt/sources.list

Debian 11

Cobra — Sun, 22 Aug 2021 09:24:04 GMT

Bullseye is stable, Bookworm is the new testing.

sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list

Debian 10

Cobra — Sun, 07 Jul 2019 09:24:02 GMT

Buster is stable, Bullseye is the new testing.

sed -i 's/buster/bullseye/g' /etc/apt/sources.list

Oid's Graffel

Cobra — Sun, 19 May 2019 17:06:08 GMT

I generally like Debian, as documented by the fact that it's my Linux distribution of choice for pdes-net.org, for the two compute server at the office, for the Mini (which is currently out of order due to a defunct SSD), and for the virtual machine that I've reserved for online banking (biig mistake...see below). Since the stable version of Debian delivers only outdated software, I'm using 'testing' as the base, and if needed, I also install packages from 'sid'.

On my main systems, however, I don't use Debian, but Archlinux. I have several good reasons for this decision. One of them is that packages that belong in a museum are not reserved to Debian Stable, but are also regularly found in Testing or Sid.

One example is 'look', which I've recently reported to be a fast way for finding an entry in a huge file. The version of look in Debian, however, contains a bug that has been fixed ten years ago. Except, of course, in Debian (and all derivatives).

But what are 10 years if you can have 20? In 2010, c't presented a Perl script for downloading and processing the transactions from an account at Deutsche Bank. The script served me well for several years, but it broke a number of times due to changes of the web interface and Perl itself. I was able to fix the script the first four times, but the last time, about five years ago, I had to ask haui for help. And a few weeks ago, it simply broke completely, and I decided to let it go and extend my old bash script to process the csv files downloaded from Deutsche Bank.

Part of one of the new scripts is the following oneliner:

tail -n +4 $current_rates | iconv -f ISO8859-1 -t utf8 | awk '{split($0,a,";"); print a[14]}' | sed 's/,/./g' | bc -l | xargs printf %.2f"\n" | tr '\n' ' ' | awk '{print strftime("%Y-%m-%d")"\t"$7"\t"$6"\t"$1"\t"$5"\t"$4" \t"$2" \t"$3}'> $cleaned_rates

Worked perfectly on my notebook running Archlinux, but in the virtual machine reserved for online banking, I got the following error message:

mawk: line 2: function strftime never defined

Hmmm...

$ awk -W version
mawk 1.3.3 Nov 1996, Copyright (C) Michael D. Brennan

Are you kidding me? That's rather extreme even for Debian standards. Particularly when considering that version 1.3.4 was published in 2009, and strftime was added to it in 2012. But surely, sid has a more recent version...NOT 😒

Even CentOS 6 came with mawk 1.3.4. Shame on you, Debilian!

Well, the only choice was to install gawk, and in this particular case, the performance hit doesn't matter at all. But why isn't that the default, if the Debilians have chosen to neglect mawk? And why do they do that anyway?

Well, whatever. The scripts are working now. 😉

Search package providing a certain command

Cobra — Wed, 24 Apr 2019 16:10:46 GMT

I've posted a short note on this topic almost exactly ten years ago, and it's time for an update. The situation: you've heard or read about a certain tool and want to install it, but you can't find it no matter how hard you try.

My first advice: don't search and install via graphical applications. ”Software centers” popular in consumer distributions may not show command line applications at all, so if you've read my last post and search for dc, you won't find what you are looking for.

Second: not every command comes in a package with the same name. For example, in Archlinux, dc is bundled with bc, and it is the latter (much more popular) application which gives the package its name.

To master such situations, it's time to leave graphical software centers behind and to learn a few basics about the actual package manager underneath. As an example, I'm showing a search for dig and drill, each of which is contained in a differently named package, with the name of these packages depending (as always) on the distribution.

Archlinux

pacman -Fs dig
        bind-tools
pacman -Fs drill
        ldns

Debian

wajig whichpkg /usr/bin/dig
        dnsutils
wajig whichpkg /usr/bin/drill
        ldnsutils

CentOS/Fedora

yum/dnf provides /usr/bin/dig
        bind-utils
yum/dnf provides /usr/bin/drill
        ldns

OpenSUSE

Reportedly, zypper offers the same functionality.

Of the big six, that leaves Gentoo and Slackware. If you use these or a distribution whose package manager is not covered here, while it offers the desired funtionality, send me a note.

Update: An attentive reader reminded me of the Pacman Rosetta, which includes OpenSUSE and Gentoo. 😎

Server speed

Cobra — Tue, 27 Mar 2018 19:22:15 GMT

An important feature of a server is the speed of its internet connection, or more precisely, its latency and bandwidth. How can we measure these quantities if all we have is command line access?

Regarding latency, look at my last post. Here's an example from pdes-net.org with the fastest mirror:

± netselect -vv https://mirror.de.leaseweb.net/debian/
Running netselect to choose 1 out of 1 address.
............
https://mirror.de.leaseweb.net/debian/ 2 ms   6 hops  100% ok (10/10) [    3]

If you want a closer look at the 6 hops, use mtr-tiny.

Concerning bandwidth, use speedtest-cli:

sudo wajig install speedtest-cli

Here's an example from pdes-net.org:

± speedtest
Retrieving speedtest.net configuration...
Testing from netcup GmbH (185.170.112.87)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by IT Ohlendorf (Salzgitter) [111.93 km]: 11.215 ms
Testing download speed.................................................
Download: 427.58 Mbit/s
Testing upload speed...................................................
Upload: 393.16 Mbit/s

Hm. A ping of 2 ms and a symmetric down- and upload of 0.4 GB/s for a handful of € per month? Why can't I have that at home?

HTTPS mirrors

Cobra — Sun, 11 Mar 2018 11:25:22 GMT

And while we're at it, let's also configure HTTPS mirrors for our package updates. That may seem superfluous at the first glance, as these packages are public content and are signed with the private GPG keys of the developers, certifying their authenticity. However, the signatures are only one part of the story, and the encrypted transfer is the other. In fact, updates installed via a plain-text HTTP connection can be intercepted by GPG replay attacks. A comprehensive analysis of this scenario was done a decade ago at the University of Arizona. The following brief summary is due to Joe Damato:

“Even with GPG signatures on both the packages and the repositories, repositories are still vulnerable to replay attacks; you should access your repositories over HTTPS if at all possible. The short explanation of one attack is that a malicious attacker can snapshot repository metadata and the associated GPG signature at a particular time and replay that metadata and signature to a client which requests it, preventing the client from seeing updated packages. Since the metadata is not touched, the GPG signature will be valid. The attacker can then use an exploit against a known bug in the software that was not updated to attack the machine.”

The distributions I'm currently using and am familiar with (Archlinux and Debian) do not use HTTPS mirrors by default, but can be coaxed into doing so.

That's particularly easy for Archlinux after installing reflector, a python script that allows to filter mirrors by various criteria such as their geographical location, up-to-dateness, download rate, and, last but not least, connection protocol. The following one-liner overwrites /etc/pacman.d/mirrorlist with the current top-ten of all HTTPS mirrors in terms of up-to-dateness, overall score and speed:

reflector --verbose --protocol https --latest 100 --score 50 --fastest 10 --sort score --save /etc/pacman.d/mirrorlist

This command can be run manually, or automatically by either using a pacman hook to trigger it in the event of mirrorlist updates, or by a timed systemd service. Reflector is thus an as flexible as convenient tool for selecting the optimum mirrors.

I expected that Debian would offer something equivalent, but to my considerable surprise and disappointment, there's nothing coming even close. The netselect derivative netselect-apt is only capable of finding the ten fastest mirrors for the relevant release of Debian (i.e, stable, testing, or sid). But how do I know if these mirror support HTTPS? To the best of my knowledge, the only way short of trying them one-by-one is the python script available here (or one of its forks).

Armed with this script (I'm using the multithreaded variant), I usually just create a list with all mirrors, which I then pipe through netselect to find the fastest one:

± ./find-https-debian-archives.py --generic --no-err | awk '{print $1}' | grep https | tr '\n' ' ' | xargs netselect -vv

Oh, and one should not forget to install 'apt-transport-https' to allow apt to use HTTPS mirrors. Only true Debilians will find this situation tolerable.