GPG-Key fuer Repositories importieren

Wer unter Debian oder Ubuntu ein Repository, sprich eine Fremdquelle, manuell hinzufügt (deb-Zeile in sources.list(.d/) mit einem Editor oder über ein Frontend oder mit apt-add-repo), erhält nach “apt update” (in apt-add-repo enthalten) einen gpg-Error. In folgenden Beispielen ziehe ich TeamViewer heran.

$ sudo apt update
Hit:1 http://linux.teamviewer.com/deb stable InRelease
(...)                               
Err:1 http://linux.teamviewer.com/deb stable InRelease                                               
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY C5E224500C1289C0
(...)
Reading package lists... Done
Building dependency tree       
Reading state information... Done
All packages are up to date.
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://linux.teamviewer.com/deb stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY C5E224500C1289C0
W: Failed to fetch http://linux.teamviewer.com/deb/dists/stable/InRelease  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY C5E224500C1289C0
W: Some index files failed to download. They have been ignored, or old ones used instead.
$

Das an sich ist wahrlich nichts neues, auch nicht, was zu tun ist, wird trotzdem immer wieder in Foren gefragt.

Im Fall TeamViewer kann man bislang ausführen:

1
wget -q https://download.teamviewer.com/download/linux/signature/TeamViewer2017.asc -O- | sudo apt-key add -

Man zieht also den Key im ASCII-Format vom teamviewer.com-Server (selbstverständlich über https) und importiert ihn mit apt-key. Das Paket add-apt-key ist auch für das kommende Ubuntu 22.04 Version 1.0-0.5, sage und schreibe 15 (!) Jahre alt. Entsprechend kann eine Message kommen:

$ sudo apt-key add TeamViewer2017.asc
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
OK
$

Das bedeutet, noch funktioniert es, ist aber abzulehnen, da die Methode über kurz oder lang entfernt wird. Entsprechend sollte man sich beizeiten informieren und am besten generell die ersetzende Methode verwenden.

GPG-Keys verwaltet man mit dem Kommando gpg und entsprechenden Optionen. Durch die obige Ausgabe wissen wir, es handelt sich um den Pubkey C5E224500C1289C0. Dies ist lediglich der rechte 16stellige Teil des 40stelligen rsa4096-Pubkeys 8CAE012EBFAC38B17A937CD8C5E224500C1289C0, genügt jedoch.

Wir könnten den Pubkey also mit “gpg –receive-keys” direkt von einem entsprechenden Keyserver ziehen und importieren. Das funktioniert, nur weiß apt davon nichts, die Fehlerausgabe besteht fort.

Es ist also so aufzubereiten, daß apt damit umgehen kann. Dabei kann mit wget das .asc-File gezogen, der relevante Teil über “gpg –dearmor” umgewandelt und über install oder gpg importiert werden.

Beispiel als Zweizeiler mit wget und install nach “/etc/apt/trusted.gpg.d/”:

1
2
wget -q https://download.teamviewer.com/download/linux/signature/TeamViewer2017.asc -O- | gpg --dearmor > teamviewer2017.gpg
sudo install -o root -g root -m 644 teamviewer2017.gpg /etc/apt/trusted.gpg.d/

Beispiel als Einzeiler mit wget und tee nach “/etc/apt/trusted.gpg.d/”:

1
wget -q https://download.teamviewer.com/download/linux/signature/TeamViewer2017.asc -O- | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/teamviewer2017.gpg >/dev/null

Beispiel als Einzeiler mit wget und tee nach “/usr/share/keyrings/”:

1
wget -q https://download.teamviewer.com/download/linux/signature/TeamViewer2017.asc -O- | gpg --dearmor | sudo tee /usr/share/keyrings/teamviewer2017.gpg >/dev/null

Beide Pfade sind möglich. Bei “/usr/share/keyrings/” erscheint der Key dann auch in software-properties* → Authentication, kann also auch dort wieder entfernt werden, so man möchte.

Hat man mit gpg bereits importiert oder möchte es so, kann man auch dies als Ausgangslage nutzen.

Beispiel als Dreizeiler mit gpg und tee nach “/usr/share/keyrings/”:

1
2
3
sudo gpg --receive-keys --keyserver hkps://keyserver.ubuntu.com --recv-keys C5E224500C1289C0
sudo gpg -a --output TeamViewer2017.asc --export C5E224500C1289C0
cat TeamViewer2017.asc | gpg --dearmor | sudo tee /usr/share/keyrings/teamviewer2017.gpg >/dev/null

Im Beispielfall TeamViewer kann man den mit gpg importierten Pubkey danach auch wieder entfernen:

1
sudo gpg --delete-keys C5E224500C1289C0

Der für apt relevante “/usr/share/keyrings/teamviewer2017.gpg” bleibt dabei erhalten.

Hinweis noch zum Copypasten: Das WP-Plugin für Code ist zwar optisch OK, aber etwas tricky. Also aufpassen, daß man Befehlszeilen vollständig in ein Terminal kopiert!

Vor Kaspersky wird gewarnt

warn ru

Als Rußland über Krim und Teile des Donjezkbeckens hinaus in die Ukraine einmarschiert ist, habe ich als ITler selbstredend sofort an russische Software, insbesondere Kaspersky, gedacht.

Mal davon abgesehen, daß es dazu bekanntlich seit 4 Jahren schon Bedenken und sogar Gesetze/Verordnungen gibt – in den USA und den NL, nicht etwa in dieser naiven BRD – sind nach anderthalb Wochen manche wie aufgescheuchte Hühner aufgewacht (wie nun plötzlich alles Russische verbannt wird – und nein, Russisch Brot heißt nur so, kommt aus Dresden). Bspw. hat Günter Born einen entsprechenden Artikel gebracht gehabt und gleichzeitig bemängelt, daß “das BSI nur bei Schönwetterbetrieb irgendwelche Binsen veröffentlicht”.

Das ist nun auch schon wieder her, dieses Amt…von einer wohl längeren Kaffeepause zurück warnt seit heute “vor dem Einsatz von Kaspersky-Virenschutzprodukten”. Man habe auch die Möglichkeit, sich “vom BSI oder von den zuständigen Verfassungsschutzbehörden beraten zu lassen”. Ahja. Ausgerechnet.

Man versucht, sich ggü. Kaspersky mehr oder weniger vorsichtig auszudrücken, sprich bewiesen ist bislang nichts (als Anti-Malware-Software gehört sie auch zu den führenden), Kaspersky Lab als russische Firma könne jedoch zu Aktionen gezwungen werden.

Da es nun mal aber um Sicherheit geht, ist von keiner auszugehen. Nun dreht es sich vor allem nicht nur um Consumer-Produkte wie KIS, woran die meisten User des darunterliegenden Spielzeugsystems denken dürften, sondern Firmen und Institutionen mit Kaspersky Endpoint Security. Da können zwar irgendwelche Entscheider ohne nötigem technischem Background beschließen (jammern werden sie sowieso ungenutzter teurer Lizenzen wegen), aber mal eben ein paar Server und Clients im vierstelligen Bereich auf irgendwas anderes umstellen, ist illusorisch.

Zumal das dann nicht nacheinander passieren müßte, sondern wie auf verseuchten Systemen auf sämtlichen gleichzeitig (bzw. auf einen Schlag abschalten und saubere nach und nach dazuschalten) und auch nicht nur Deinstall von KES und Install von ja-was-denn-gleich. Es müßten sämtliche Rechner komplett neu installiert werden, wenn man Vorsatz unterstellt. Für saubere Systeme allgemein sowieso – ich sage mal nur kavremvr.exe (oder auch NRnR.exe, MCPR.exe etc. der Konkurrenz). D.h., diese sich tief ins System eingrabenden Programme sind selbst nicht in der Lage und/oder willens, sich sauber zu entfernen. Jeweilige Remover werden auch nur einen Teil hinterherkehren.

Wenn schon so grundlegend, könnte man auch gleich mal richtig umstellen. Linux, ohgottohgott!

Btw.,…

Caesar: “Die Iden des März’ sind da.”
Spurinna: “Da sind sie, aber noch nicht vorbei.”

Ob der russische Zar die Geschichte kennt? Mit seinem Faible für historisches sollte er das, zumal Rußland mit dem byzantinischen Doppeladler und als “Drittes Rom” seit dem 16. Jh. lächerlicherweise ja auch einen Teil der römischen Geschichte für sich zu vereinnahmen sucht.

Update:

Wie bereits 2018 versucht sich erwartbar Jewgeni Kasperski zu wehren. Sein Problem bzw. das der Firma Kaspersky Lab ist allerdings, daß, mag er auch noch so hehre Ziele haben, mögen bestimmte Stellen auch den Source Code einsehen können, Entwickler in der Schweiz sitzen, es sind Binaries. Sie müssen nicht aus diesem Source Code stammen, die Software kann auch jederzeit verändert werden, müßte also mindestens permanent überwacht und bei kleinstem Verdacht sofort in irgendeiner Weise gesperrt werden. Ein Unding.

Nicht zu reden davon, daß IT-Kleingeister auf beiden Seiten Rußland vom Internet trennen wollen. Ein Malware-Scanner, der stetig Server kontaktieren muß, ist dann abgeschnitten.

Btw., schon jemand über das ebenfalls bekannte Dr. Web “cure it” nachgedacht? Moskau und St. Petersburg. Erstklassiger Scanner der anderen Art (einzelnes, nicht zu installierendes Windows-Executable, das alles enthält und daher auf Bedarf jeweils aktuell zu ziehen ist, ~350 MiB, natürlich nicht vom verdächtigen System und Rüberbeamen auch bloß mit CDR, sprich schreibgeschützt), der auf möglichen Befall checkt, also im Nachhinein. Allerdings: wer zuerst kommt, mahlt zuerst. Dennoch kann “cure it” weitgehend cleanen, wobei ein verseuchtes und behandeltes System grundsätzlich als kompromittiert gilt.

CLT 2022

CLT 2022 Logo

Hätte man die Chemnitzer Linux-Tage zwei Wochen später veranstalten wollen, wäre das “sogar” vor Ort möglich gewesen (sofern nicht wieder ein Medizinalratloser willkürliche Riegel vorschiebt). Aber sowas braucht ja eine organisatorische Vorlaufzeit und wenigstens halbwegs Planungssicherheit.

2021 ist pünktlich zum Start 9:30 das Eigentliche zusammengebrochen. Mir ist aber auch nicht klar, wieso man das Streaming ausschließlich in viel zu hohen Auflösungen und damit exorbitantem Traffic anbieten muß. Es geht auch nicht nur um die Server-Seite, ich als User (schnelle Flatrate her oder hin) kann unnötigen Traffic nicht ab. Daher habe ich mir das nur eine zeitlang des technischen Interesses am dahinterstehenden System wegen angetan.

Auch reine Audiostreams (.ogg oder .mp3), was in den meisten Fällen genügt (und nicht selten durch ungeübte Vortragende schon eine Zumutung ist), hat es 2021 nicht mehr gegeben. In den Jahren davor habe ich, wenn ich nicht gerade in Chemnitz gewesen bin, mit vlc in den einen oder anderen Raum ‘reingehört (.m3u hier auch verlinkt), was prima nebenbei geht. Wie Radio eben. Man wird morgen sehen, ob das in Chemnitz erkannt worden ist.

Update 2022-03-12: Ich habe über das Pad in der Eröffnungskonferenz gefragt…nein, reine Audiostreams gibt es (wieder) nicht. So irritiert, wie geantwortet worden ist, kann man erkennen, daß man das dort auch überhaupt nicht (mehr) auf dem Schirm hat. Also sollte man sich genau überlegen, in welchen Raum und wie lange man geht. Ganzen Tag nebenbei laufen lassen wie Webradio, ist keine gute Idee.

Firefox 98: Profile nicht abwaertskompatibel

Warnung: Firefox ändert mal wieder etwas an den Profilen, sprich mit Fx 98.0 candidate build 2 (die Final ist für 2022-03-08 avisiert) einmal gestartet, kann das Profil nicht wieder mit der derzeitigen Final 97.0.1 geladen werden.

Ein realistisches Szenario, da Fx 98.0cb2 Sites reproduzierbar crashen läßt, die aus einem Link in Thunderbird geladen werden.

Wer also diese Dev-Version testen will, vorher “~/.mozilla/” sichern!

enlightenment: suid setzen

Nachdem in einem Forum-Thread bezeichnenderweise auch nach anderthalb Tagen statt einer Lösung für

“Enlightenment cannot successfully start the enlightenment_system service since it can’t become group root. Missing setuid bit?”

nur ein Link zu einem Bugreport (den ich auch längst gefunden gehabt habe) gepostet worden ist, habe ich mich unter dem Bugreport erbarmt. Das Problem an sich ist nicht neu (ist bei mir damals mit e17, e18, e19 auf Lubuntu oder siduction allerdings nicht aufgetreten), Lösungen in anderen Foren sind jedoch auch nicht wirklich existent. Eine vielleicht, freilich noch vor dem usrmerge, damit mit anderen Pfaden.

1
2
# chmod 4755 /usr/lib/x86_64-linux-gnu/enlightenment/utils/enlightenment_sys
# chmod 4755 /usr/lib/x86_64-linux-gnu/enlightenment/utils/enlightenment_system

Der launchpad.net-Editor ist im übrigen ein Grauen. Weder gibt es ersichtlich Codeblocks noch Link-Syntax (vielleicht wenigstens BBCode, habe ich aber nicht auch noch ausprobieren wollen, denn Vorschau und Editieren sind ebenfalls nicht möglich, dafür aber sinnfreie nicht verhinderbare harte Zeilenumbrüche trotz wesentlich breiterem Editor-Fenster). Paßt damit bestens zu Canonical/Ubuntu.

Paketquelle partner nicht in Jammy

Kurzinfo für Ubuntu 22.04: Es gibt einen Vorschlag Steve Langaseks, die ohnehin seit Groovy leere Paketquelle partner (in Focal ist AFlash zu dessen mehr oder eher weniger Lebzeiten als letztes noch enthalten gewesen) zu schließen. Gegenmeinungen scheint es bislang keine zu geben…oder mit anderen Worten, interessiert keinen mehr. Im Einzelnen oder überhaupt.

Die Begründung ist allerdings schräg. Der Snap Store sei mittlerweile so ausgereift, daß dieser partner ersetzen könne. Was nichts über das aufblasende bis hin das Prinzip Linux-Paketverwaltung zerstörerische snap selbst aussagt…

Arch Linux 2022.01.01, Image in VBox nicht UEFI-faehig

Um in einer VBox-VM statt im CSM-Mode (Compatibility Support Module, das UEFI verhält sich, als sei es ein BIOS) im UEFI-Mode zu booten, ist lediglich im “VM VirtualBox Manager” unter System → Motherboard → Extended Features “Enable EFI (special OSes only)” zu aktivieren. Alternativ in einem Terminal:

1
vboxmanage modifyvm "VM name" --firmware efi

Selbstverständlich muß das zu bootende Image so oder hybrid erstellt worden sein (ein installiertes System sowieso). Das einfache Bootmenu von Arch Linux erscheint dann wie folgt:

Nicht so beim aktuellen Image archlinux-2022.01.01-x86_64.iso. Die Arch-Einträge fehlen, schlicht da das Image in VBox-VMs im UEFI-Mode nicht boot-fähig ist. Nativ soll es OK sein.

Man kommt nur in die EFI Shell oder das rudimentäre UEFI-Menu. Änderungstests in letzterem oder im VM-Manager sind erfolglos. Andere UEFI-fähige Distributions-Images, bspw. ein mit isorespin.sh angepaßtes Lubuntu oder das aktuelle EndeavourOS booten anstandslos, ebenso Arch-Images davor.

Ursächlich soll systemd 250.1-1 sein, es gibt einen Bugreport dazu bei archlinux.org. So es so ist, müßte dann, da Upstream, jedoch einer bei systemd erstellt werden.

Erhärtet wird es, da ein User ein Image mit systemd 249.x erstellt hat, das entsprechend boot-fähig ist. Jener bietet es zwar zum Download an, ein OS-Image von irgendjemandem verändert, so nett es gemeint ist, würde ich jedoch nicht verwenden.

Ebensogut könnte es ein Zusammenspiel mehrerer Faktoren, d.h. mit VBox sein, würde also (auch) dorthin gehören. Freilich nutze ich prinzipiell die jeweils aktuelle Version, sprich Testbuilds, derzeit 6.1.31 (das letzte ist knapp 4 Wochen alt, jetzt könnte so langsam mal wieder was kommen, manchmal gibt’s 3 Versionen pro Woche). In besagten Threads wird 6.1.30 final verwendet.

Wer jetzt Arch Linux in einer VBox-VM mit UEFI installieren will (mit CSM gibt es kein Problem), kann 2021.12.01 heranziehen – hat dann natürlich erheblich zu aktualisieren, was bei arch durch permanente Updates aber ohnehin der Fall ist – oder mit 2022.01.01 in der EFI Shell folgendes aufrufen:

1
FS1:\EFI\BOOT\BOOTx64.EFI

Das installierte System scheint keine UEFI-Boot-Probleme mit aktuellem systemd in VBox-VMs zu haben.

Update 1: Zwischenzeitlich ist upstream ein Bugreport für systemd erstellt worden.

Update 2: Der Commit boot: Fix readdir_harder() on VirtualBox für systemd ist 2022-01-10 Spätabend hinzugefügt worden, Arch Linux liefert systemd 250.2-2 damit in testing bereits aus. Das Februar-Image sollte dann dahingehend problemlos boot-fähig sein.

Update 2022-01-18: Die heutige (eigentlich vom 13.) Final VBox 6.1.32 löst zwar das Problem, Arch Linux 2022.01.01 zeigt im UEFI-Mode das vollständige Menu und kann folgerichtig booten. Jedoch bringt VBox 6.1.33-149396 das Problem zurück.

Update 2022-02-01: archlinux-2022.02.01-x86_64.iso funktioniert dahingehend korrekt.
FYI: Das wenige Stunden zuvor von testing nach extra gewanderte archinstall 2.3.1 ist enthalten.

pdf, finale Ungleichheit

Das Portable Document Format ist entwickelt worden, um ein finales Dokument zu erhalten, das in jedem OS in jedem pdf-Viewer gleich aussieht, ebenfalls gedruckt. Es ist wie gesagt ein Endprodukt, es soll nicht editierbar sein (was User offensichtlich nie verstehen werden). Daß Drittanbieter Bastelprogramme anbieten, ändert daran nichts.

In 3 Jahrzehnten ist freilich immer weiter angeflanscht worden, so daß es nicht nur den einen Standard, die eine Version gibt. Bspw. für Archivierung sollte PDF/A (in Unterversionen), ISO 19005, gewählt werden, absichtlich unteres Level.

Hybrid-PDF kann man bei der Erstellung (LibreOffice) wählen, um in einem .pdf-File sowohl PDF als auch ODF zu speichern. Das .pdf-File wird damit durch Trickserei editierbar, man braucht nicht separat .odt bzw. .ods zu speichern. Natürlich ist dabei die Filesize größer. Wenn das File weitergegeben werden und nicht editierbar sein soll, darf man das selbstverständlich nicht hybrid speichern (eher exportieren).

Sind Forms eingebettet, kann ein solches pdf-File als ausfüllbares Formular verwendet werden. Dazu genügt ein pdf-Viewer.

Read more “pdf, finale Ungleichheit”

Streams in vlc abspielen

Streams einer bekannten Videoplattform sind dafür vorgesehen, im Browser zu laufen. Um darüber hinausgehendes zu verhindern, werden ständig neue technische Rafinessen ersonnen (man denke nur an Fragmentierung des Videos, separate Audiospuren etc.).

vlc hat man bis vor geraumer Zeit durch Aufruf des Stream-URLs noch nutzen können. Derzeit stockt die Wiedergabe jedoch aller paar Sekunden – unbrauchbar. In Foren wird nach Lösungen gefragt. Tips, man solle doch smplayer nehmen (ohnehin nur ein Frontend für mplayer oder mpv), verkennen, daß dieser selbst derartige Streams gar nicht abrufen kann, sondern sich eines bekannten Zusatz-Tools bedient.

Ich betone, es soll ausschließlich um die Wiedergabe des temporär nur dafür im Cache gehaltenen Streams gehen. Also das, was ein Browser auch nur macht, aber ein Player technisch besser könnte, wenn ihm kein Bein gestellt wird (die Systembelastung ist merklich geringer, insbesondere unter Linux, dort haben Browser i.d.R. keine wirkliche Hardware-Beschleunigung).

vlc nutzt für Quellen entsprechende Playlists, eine Art Profile. Arch-based sind sie unter “/lib64/vlc/lua/playlist/” abgelegt, in debian-basierten Systemen unter “/usr/lib/x86_64-linux-gnu/vlc/lua/playlist/”. Default sind es .luac-Files. Es werden jedoch nicht nur Kompilate, also Binaries, erkannt, sondern auch .lua-Files.

Man benötigt keine neue vlc-Version (auch ein 4.0er nightly-snap soll nicht helfen), man kann das entsprechende .luac-File durch ein .lua-File (logscherweise raw) ersetzen.

In EndeavourOS ist das Problem damit behoben, ebenso in einer LFocal-VM (dort hat es bisher gar nicht abgespielt werden können), in einer Debian-testing-VM stockt es noch. Es sind unterschiedliche vlc-Versionen. Generell funktioniert es also – derzeit – wer es wirklich braucht (für mich ist es lediglich eine interessante technische Problemstellung gewesen), müßte in letzterem weitersuchen, bspw. Konfigurationen (VM, vlc,…) vergleichen.

LXQt: Shortcuts ohne Funktion

Wenn Tastenkombinationen keine Reaktion mehr zeigen, merkt man erstmal, wie sehr man selbst darauf baut. LXQt-Shortcuts funktionieren nicht mehr (wenn nicht mal über ctrl+alt+t ein Terminal gestartet werden kann, was ich hier ständig mache, ist das schon hart, hrr).

Sobald der Desktop aufgebaut ist, erscheint folgende Message:

lxqt-panel
Removable media/devices manager: Global shortcut 'X86Eject' cannot be registered

Ich untersuche das Problem seit Freitag (da ist es erstmals aufgetreten, testing ist in EndeavourOS, also arch-based, prinzipiell aktiviert). Es ist irrelevant, welcher Window Manager genutzt wird (openbox, xfwm4). Zwischenzeitlich habe ich schon angenommen gehabt, ich hätte die Ursache gefunden bzw. zumindest einen Workaround.

lxqt-globalkeysd kann nicht gestartet werden. Dies kann man sehen unter:

LXQt Configuration Center → Session Settings → Basic Settings → Global Keyboard Shortcuts

An der Stelle kann man den Dienst starten, freilich überlebt dieser keinen Reboot oder Relogin.

Unter

LXQt Configuration Center → Autostart → Application Autostart → LXQt Autostart

habe ich “lxqt-globalkeysd” mit “Wait for system tray” als Workaround hinzugefügt. Hilft allerdings nicht zuverlässig. Im Moment funktioniert’s, was nicht daran liegen muß.

Zum Thema kann man fast nichts finden. Vor 5 Jahren ist das Fehlerbild schon mal aufgetreten (nicht bei mir, ich habe damals LXDE genutzt). Damals soll geholfen haben:

PCmanFM → Preferences → Volume → disable “Mount removable media automatically whe they are inserted” und disable “Show available options for removable media when they inserted”

Ist hier aber auch nicht einwandfrei reproduzierbar.