„Aus den Wirren der Paketabhängigkeiten im Dschungel von Systemd“ man könnte einen Roman damit betiteln 🙂 Gestern abend, es war mal wieder Serverupdatezeit, flutschte eine Anzeige eines Fedora-Paketes, daß keinen Sinn machte, über den Bildschirm: qrencode-libs
QR Codes auf einem Server?
Ja, wenn man eine Webseite hat, die z.b. QR Codes ausgibt, weil eine HandyApp einen Bestätigungscode haben will, warum nicht. Dummerweise hatte dieser Server genau einen Job und der hatte nichts mit QR Codes zu tun. „Naja,ok, das wird jemand mal irgendwann für was ausprobiert haben… kann weg!“ denkste Dir so.. und dann kommt das Erwachen: „Wieso will dnf jetzt systemd löschen?“
$ sudo dnf erase qrencode-libs
[sudo] Passwort für ….. :
Fehler:
Problem: The operation would result in removing the following protected packages: systemd
Das kommt so …
Der Systemd hat eine harte Abhängigkeit auf die lib von dem qrencoder :
$ rpm -q -R systemd | grep qrenc
libqrencode.so.3()(64bit)
ganz genau genommen ist es journalctl:
$ ldd /usr/bin/journalctl |grep qrenc
libqrencode.so.3 => /lib64/libqrencode.so.3 (0x00007fef36540000)
„Kann mir bitte einer erklären, wieso journalctl QR CODES bauen können müßte ?????“
Kann ja wohl nur ein Fehler sein 😉 Der Maintainer bei Redhat war da jetzt anderer Meinung:
What do you mean "wrongfully"? It's "rightfullly" linking against qrencode-libs because that functionality is used by journalctl. While somewhat unfortunate, it's correct.
Steht aber allein da, denn auch bei Manjaro Linux ist das schon mal jemandem vor mir aufgefallen und siehe:
https://forum.manjaro.org/t/systemd-238-51-1-has-picked-up-a-dependency-on-qrencode/43070
Could this be due to a dirty chroot?
$ ldd `which journalctl` linux-vdso.so.1 (0x00007fff47fc9000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f55fd82e000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f55fd477000) libsystemd-shared-238.so => /usr/lib/systemd/libsystemd-shared-238.so (0x00007f55fd027000) libqrencode.so.4 => not foundI’m pretty certain
journalctldoesn’t need qrencode?
Das sehe ich auch so, trotzdem habe ich mal etwas geforscht und die Ursache gefunden:
journalctl .c
#if HAVE_QRENCODE
/* If this is not an UTF-8 system don’t print any QR codes */
if (is_locale_utf8()) {
fputs(„\nTo transfer the verification key to your phone please scan the QR code below:\n\n“, stderr);
print_qr_code(stderr, seed, seed_size, n, arg_interval, hn, machine);
}
#endif
Jetzt wirds spannend:
Wozu wird das benutzt?
Um, wenn es ein UTF8-System ist UND der Code mit dem QR Support kompiliert wurde, einen Verifikations Schlüssel als QR CODE fürs Handy auszugeben, um mit dem Versiegelungs-Schlüssel abgesicherte Journaleinträge zu prüfen.
Das Verfahren heißt bei Systemd Forward Secure Sealing (FSS). Keine Ahnung wer das Feature von Journald nutzt. Es klingt jedenfalls nach einer brauchbaren Idee, falls ein Hacker die Einträge manipuliert. Ich bezweifle aber stark, daß der Key dabei per QR Code an ein Handy übermittelt werden muß, statt per SCP an einen anderen Server.
Für diese eine Zeile Code da oben, die kaum jemand jemals einsetzen wird (Bitte Zahlen liefern, wer welche hat), immer noch diese Lib mit sich rumschleppen… was solls, GB sind billig 😉