Bei jedem Betriebssystem gibt es Anwender, die aus irgendeinem Grund aufgehört haben ihre Betriebssysteme und/oder Programme zu aktualisieren. Eine Entscheidung, die nicht nur die Sicherheit beeinträchtigt, sondern eine ganze Kette an Folgeproblemen nach sich zieht. Am Ende schlägt man dann mit komischen Problemen in Supportforen auf, weil man in einer seltsamen Binnenlogik festsitzt.

Erfahrungsgemäß beginnt die Fehlentwicklung bei einem einzigen Programm. Entweder wird dieses nicht weiter entwickelt, das Lizenzmodell wird geändert oder man ist mit funktionalen Änderungen nicht einverstanden. Also beschließt man, dass man diesen Aktualisierung nicht machen möchte. Das kann auch mal mit einem ganzen Betriebssystemupdate so sein - siehe Windows Vista oder Windows 10 - ist aber in dieser Gestalt seltener.

Eine kluge Vorgehensweise besteht darin sofort nach einer Alternative zu suchen und die Migration vorzubereiten, so lange das alte Programm noch nicht zu lange aus der Unterstützung raus gefallen ist oder vielleicht sogar noch Legacy-Support genießt.

Eine schlechte Entscheidung ist es aber einfach auf der Version zu bleiben, die man gerade nutzt. Eine Entscheidung, die leider viel zu viele Anwender aus Bequemlichkeit wählen.

Diese Programmversion mag funktionieren und vielleicht macht sie auch noch das eine oder andere Betriebssystemupgrade mit, aber irgendwann kommt der Moment an dem das Programm mit einer neuen Version des verwendeten Systems nicht mehr funktioniert. Bei Linux und macOS dürfte das sogar relativ schnell passieren, bei Windows kann das mitunter Jahre dauern.

Also beschließt der nunmehr hartnäckige Verweigerer, dass er nun auch beim Betriebssystem auf Aktualisierungen verzichtet. Ein paar Jahre Legacy-Support gibt es ja für alle Systeme und dann sieht man weiter.

Nun kommt der Verweigerer in das Stadium in dem sich viele Programme nicht mehr aktualisieren lassen, weil die blöden Entwickler alte OS-Versionen nicht mehr unterstützen. Der Verweigerer friert also seine kompletten genutzten Versionen ein. Vielleicht sogar für viele Jahre.

Die Interoperabilität ist längst obsolet. Zugesandte Dateien lassen sich immer seltener reibungslos öffnen. Man klinkt sich zunehmend aus diesem Prozess aus oder beschwert sich gar über neumodische Formate. Browser werden meist sehr lange unterstützt und somit lässt sich das Internet mit obsoleten Betriebssystemversionen lange nutzen.

Doch irgendwann geht auch die verwendete Hardware kaputt und neue Hardware verlangt leidlich aktuelle Betriebssysteme. Auf diesem laufen aber alle alten Programme nicht und die alten Dateiversionen lassen sich nicht mehr reibungslos importieren.

Wutentbrannt schlägt der Verweigerer nun im Supportforum seiner Wahl auf. Dem Frust muss Luft gemacht werden.

Besser man endet nicht so.

Die richtige Entscheidung muss ganz am Anfang getroffen werden. Kein Programm wird ewig existiert, fortlaufende Migrationen sind Teil des Alltags. Daher sollte man drei Grundsätze beherzigen:

1. Man versucht seine Datenbestände kontinuierlich auf unterstützte Programme zu migrieren. In der Regel ist man zu dem jeweiligen Zeitpunkt nicht alleine und kann auf Unterstützung im Internet hoffen.
2. Sollte eine Migration absolut unmöglich sein, muss man das Programm vom restlichen System isolieren und ggf. in einer virtuellen Maschine betreiben. Dadurch verhindert man, dass dieses Problem auf die restlichen genutzten Programme ausstrahlt.
3. Archivierungen von Dateien nimmt man weiterhin nur in Dateiformaten vor, die für diesen Zweck entworfen wurden. PDF/A wäre hier ein geeignetes Beispiel. Keinesfalls nimmt man irgendwelche binären Formate - seien sie freie Software oder nicht.

Bilder:
Einleitungsbild und Beitragsbild von von geralt via pixabay 

Seit 2009 nutze ich bereits die Radkarte von Radfahrer, welche dann bei Launchpad von Johannes Formann fortgeführt wurde. Im November 2018 hat der aktuelle Maintainer das Projekt leider eingestellt, der Code ist aber noch vorhanden und funktioniert sogar (mit kleinen Einschränkungen noch). Hier also eine aktualisierte, komplette Anleitung, wie ich derzeit Radkarten für mein Garmin erstelle.

Karte erstellen

Will man auf Basis des Radkarten-Projekts selbst eine Karte für das Garmin erstellt, geht man wie folgt vor.

Zuerst lädt man den Quellcode mit Bazaar herunter:

$ bzr branch lp:radkarte

Hier muss natürlich das Paket bzr installiert sein.

Danach wechselt man in den entstandenen Ordner:

$ cd radkarte

Theoretisch gibt man nun einfach nur

$ ant dist

ein, um die Generierung anzustoßen. Hierfür müssen die drei Pakete ant ant-contrib ant-optional installiert sein.

Zusätzlich benötigt man für andere Abhängigkeiten die Pakete m4 subversion sowie eine Java-Installation (z.B. openjdk-11-jdk).

Speicherort

Die fertigen gepackten Karten liegen am Ende unter build/dist/ als gmapsupp__singleMap.img.zip bzw. gmapsupp__full.img.zip. Es gibt in dem Ordner noch andere Dateien, die mich aber nicht interessieren. Je nach Wahl entpackt man die gewünschte zip-Datei und kopiert die entpackte Image-Datei gmapsupp*.img auf die SD-Karte des Garmins in den Ordner garmin/.

Andere Region generieren

Wenn man eine andere Karte als Deutschland generieren will (z.B. nur ein bestimmtes Bundesland), muss man den Downloadpfad und -dateiname in der build.xml anpassen (Zeile 21/22):

<property name="dl_path" value="europe/germany/"/>

<property name="dl_region" value="saarland"/>

Karten-ID ändern

Die Karten-ID steht an einer zentralen Stelle in der build.xml (Zeile 29):

<property name="family_id_base" value="5900"/>

Für eine andere Karte auf dem gleichen Garmin-Gerät muss die ID geändert werden. Hierzu einfach nur die ersten beiden Ziffern der 5900 ändern. Ich nehme im Übrigen immer die Telefonvorwahl des Landes als Kennziffer, also „4900“ für Deutschland.

Bekannte Probleme

Seekarten und Grenzen

Die Seekarten und Grenzen wurden bisher vom Server der Uni Wuppertal geholt, der aber nicht mehr aktiv zu sein scheint. Die Karten liegen nun auf dem Server von OSM-Nutzer Kukuk.

Das heißt, in der build.xml muss

<get src="http://osm2.pleiades.uni-wuppertal.de/sea/latest/sea.zip"

<get src="http://osm2.pleiades.uni-wuppertal.de/bounds/latest/bounds.zip"

durch Folgendes ersetzt werden:

<get src="http://osm.thkukuk.de/data/sea-latest.zip"

<get src="http://osm.thkukuk.de/data/bounds-latest.zip"

Patch für mkgmap funktioniert nicht

Ich weiß leider nicht genau, was der Patch machen soll (es hat etwas mit dem Garmin-MDR-Dateiformat zu tun), aber es wird bei der Generierung gemeldet:

[patch] patching file uk/me/parabola/mkgmap/combiners/FileInfo.java

[patch] Hunk #1 succeeded at 265 with fuzz 2 (offset 25 lines).

[patch] patching file uk/me/parabola/mkgmap/combiners/GmapsuppBuilder.java

[patch] Hunk #1 FAILED at 338.

Grund hierfür ist, dass der Patch sich auf eine ältere Code-Version von mkgmap bezieht und die neue sich zu stark geändert hat. Für die Erstellung der gmapsupp*.img ist dies glücklicherweise unwichtig.

Purism hat für das lang geplante Librem5 nun die Karten auf den Tisch gelegt. Die Spezifikationen sind bekannt und die Vorbestellungen laufen an. Die bekannten Fakten lesen sich ernüchternd. Sowohl die Hardware, als auch das Betriebssystem dürften Experimentalcharakter haben.

Purism hat mit Librem 5 den viel beachteten Versuch unternommen ein Smartphone zu entwickeln, das sich ganz auf Privatsphäre und Datenschutz konzentriert. Die Community hat das Projekt mit viel Enthusiasmus begleitet und die Entwicklung mit 1,5 Mio. US-Dollar angeschoben. Zweifel waren aber von Vornherein angebracht. Purism hat zwar Erfahrung im Hardware-Bereich, weil man bereits seit längerem Notebooks mit Privatsphären-Fokus ausliefert, aber die Testberichte lesen sich hier auch durchwachsen. Das ist umso bemerkenswerten, weil Linux auf dem Desktop bereits ein sehr stimmiges Gesamtpaket ausliefert und mit Coreboot ambitionierte freie Projekte existieren. Freie Hardware ist im Desktop- und Notebook-Segment auch kein so schwieriges Thema, wie bei den mobilen Begleitern der Gegenwart.

Smartphones sind ein deutlich schwierigeres Umfeld. Nicht nur existiert kaum Hardware, die sich ohne proprietäre Firmware betreiben lässt, es gibt auch keine lauffähige Linux-Version für Smartphones. Ubuntu Touch und Plasma Mobile sind hier die am weitesten gediehenen Projekte. Vorgeblich freie Betriebssysteme setzen ansonsten immer auf einen Android-Basis auf.

Genau diese beiden Projekte hat Purism aber mehr oder minder links liegen gelassen und PureOS auf GNOME ausgerichtet gestürzt. Allen Unkenrufen zum Trotz ist die GNOME Shell und die damit verbundenen Apps mitnichten Mobile-Tauglich. Hier lag von Anfang an ein weiter Weg vor Purism.

Die nun veröffentlichten Spezifikationen lesen sich nicht sehr aktuell. Das Display löst nur mit 720x1440 Pixeln auf, 32GB nicht erweiterbarer Speicher ist eher ein Wert, den man aus dem Apple-Universum kennt. Bluetooth 4 ist veraltet und hat nicht die Energiesparfunktionen der aktuellen Version 5 etc. pp.

Zusammengefasst ist das ein Ergebnis, das bestenfalls Enthusiasten ansprechen wird. Das Librem 5 ist in dieser Version vermutlich kein Gerät, das ein anderes Smartphone ersetzen kann, egal wie Genügsam der Anwender ist. Es bleibt zu hoffen, dass Purism in der aktuellen Version lediglich eine Experimentalstudie sieht, wodurch man Feedback einer breiteren Öffentlichkeit erhalten möchte um schnell mit einer weiteren Version nachzulegen. Ansonsten ist das eine Totgeburt, wie so viele andere hoffnungsvolle Android-Konkurrenten.

Bilder:
Einleitungs- und Beitragsbild von Siez18 via pixabay

Um neue Linux-VMs mit einer funktionierenden und zu unserer Umgebung passenden DNS-Konfiguration zu provisionieren, habe ich mir eine kleine Ansible-Rolle namens resolv.conf erstellt, welche ich im Folgenden vorstellen möchte.

Die Rolle resolv.conf

# tree roles/resolv.conf
roles/resolv.conf
├── handlers
│   └── main.yml
├── tasks
│   └── main.yml
└── templates
    └── resolv.conf.j2

Die Rolle kommt sehr minimalistisch daher und umfasst nur die zwingend erforderlichen Verzeichnisse und Dateien.

tasks/main.yml

---
- name: make sure line 'dns=none' is set in /etc/NetworkManager/NetworkManager.conf
  ini_file:
    path: /etc/NetworkManager/NetworkManager.conf
    state: present
    no_extra_spaces: yes
    section: main
    option: dns
    value: none
    owner: root
    group: root
    mode: 0644
    backup: yes
  notify:
  - reload NetworkManager

- name: deploy resolv.conf template
  template:
    src: roles/resolv.conf/templates/resolv.conf.j2
    dest: /etc/resolv.conf
    owner: root
    group: root
    mode: 0644
    backup: yes
  notify:
  - reload NetworkManager

Um die Datei /etc/resolv.conf mit Ansible verwalten zu können, habe ich zuerst dem NetworkManager abgewöhnt, diese Datei zu anzufassen. Dazu habe ich das Ansible-Modul ini_file verwendet, welche die benötigte Option dns=none in der Sektion [main] setzt.

Der zweite Task nutzt das Modul template, um aus der Datei unter roles/resolv.conf/templates/resolv.conf.j2 die Zielkonfiguration in der Datei /etc/resolv.conf auf dem Zielsystem zu erstellen. Aktuell enthält mein Template statischen Text und ich hätte auch das Modul copy nutzen können, um diese Datei auf das Zielsystem zu bringen. Ich verwende jedoch das template-Modul, um mir die Möglichkeit offen zu halten, durch Verwendung von Variablen den Inhalt dynamisch erstellen zu lassen.

Mit dem Parameter notify: wird an zwei Stellen ein Handler namens ‚reload NetworkManager‘ benachrichtigt. Auf diesen gehe ich im nächsten Abschnitt ein.

handlers/main.yml

Mit den Ansible Handlers lassen sich Aktionen auslösen, welche nur dann ausgeführt werden sollen, wenn durch einen Task Änderungen auf dem Zielsystem durchgeführt wurden. Die Handler werden erst am Ende eines Playbooks abgearbeitet und nur einmal ausgeführt, auch wenn Sie von mehreren Tasks über Änderungen benachrichtigt wurden.

# cat resolv.conf/handlers/main.yml 
---
  - name: reload NetworkManager
    service:
      name: NetworkManager
      state: reloaded

Bei dem in diesem Text beschriebenen Beispiel führt der Handler mit dem Namen ‚reload NetworkManager‘ den darunter definierten Task aus. Jedoch nur dann wenn einer der beiden Tasks (oder beide) aus tasks/main.yml zu einer Änderung auf dem Zielsystem geführt hat.

Es gilt zu beachten, dass Handler erst dann ausgeführt werden, wenn alle Tasks erfolgreich ausgeführt wurden. Dies kann in einigen Fällen die Fehlersuche etwas erschweren. Ich habe dazu ein Beispiel in Ansible: Up and Running von Rene Moser und Lorin Hochstein gefunden, welches ich hier gerne wiedergeben möchte. Stellt euch vor, euer Playbook hat folgenden Ablauf:

1. Ihr führt ein Playbook aus
2. Einer der Tasks verwendet notify bei Änderungen
3. In einem folgenden Tasks tritt ein Fehler auf, welcher zum Abbruch der Verarbeitung führt
4. Ihr behebt das Problem und führt das Playbook erneut aus

Der Task aus Schritt 2 hat seine Änderungen bereits erfolgreich durchgeführt. Bei der erneuten Ausführung des Playbooks wird sein Status daher OK und nicht CHANGED sein. Der Handler wurde jedoch nicht ausgeführt, da die Verarbeitung zuvor abgebrochen wurde. Auch bei der erneuten Ausführung des Playbooks wird der Handler nicht mehr ausgeführt, da der dazu erforderliche Task zu keiner Änderung im Zielsystem mehr führt.

Hochstein schreibt, dass Handler meist genutzt werden, um Dienste neuzustarten oder deren Konfiguration neu zu laden. Dies kann selbstverständlich auch erreicht werden, wenn man auf den Einsatz von Handlern verzichtet und einen Dienst am Ende des Playbooks explizit neustartet. Welches der bessere Weg ist, möge jeder für sich selbst entscheiden.

Fazit

Dies war eine meiner ersten Ansible-Rollen überhaupt. Ob dies der geschickteste Weg ist, die DNS-Konfiguration herzustellen, oder ob es noch elegantere Ansätze gibt, mag ich nicht abschließend beurteilen. Zumindest scheint auch diese Lösung robust zu sein und hat mich bisher nicht im Stich gelassen.

Falls ihr Fragen oder Anregungen habt, hinterlasst gern einen Kommentar. Ich freue mich stets neue Lösungswege kennen zu lernen.

Kürzlich hatte ich den seltenen Fall, dass mein Laptop nicht mehr booten wollte. Ich hatte die Vermutung, dass bei der Installation des Kernel-Updates etwas bei der Erstellung des initramfs oder des Updates von GRUB2 schief gegangen ist. Grandioserweise hatte ich einmal die Idee die Wartezeit bei GRUB2 auf 0 einzustellen, so dass es mir leider auch nicht möglich war einen anderen Kernel zu booten.

Ein USB-Stick mit grml wollte komischerweise auch nicht booten, obwohl USB-Boot im BIOS erlaubt war und das System auch von USB-Stick installiert wurde. Zum Glück lag noch ein Wechselgehäuse herum und ich konnte die Festplatte per USB an mein Netbook anschließen.

Damit ich mir das Vorgehen zur Rettung nicht wieder mühselig bei askubuntu und help.ubuntu.com zusammensuchen muss halte ich die Befehle, die mir zum Erfolg verhalfen, in meinem Schmierzettel fest. Das Setup der Vollverschlüsselung ist das Standardsetup mit LUKS/dm-crypt, das der Debian-Installer anlegt wenn man Verschlüsselung auswählt.

⚠️ Falls ihr auch mal in diese Situation kommt: Dass das Vorgehen bei mir geholfen hat heißt nicht, dass es allgemeingültig anwendbar ist! Die Befehle sind nicht ungefährlich also schaut vorher in die manpages der Befehle und denkt nach bevor ihr sie auf euren Datenträger los lasst!¹ Und: Backup! Backup! Backup!

Erst mal musste ich rausfinden welche device id meine Laptop-SSD in meinem Netbook bekommen hatte, dazu genügt der Aufruf von blkid als root (Alle weiteren Befehle werden als root ausgeführt). In der Ausgabe sah ich dann unter anderem die Partitionen meines Laptop-Systems:

/dev/sdb1: UUID="b9f4c6ab-48a8-4582-b6c7-8ff11e9f42f9" TYPE="ext2" PARTUUID="e091aba6-01"
/dev/sdb5: UUID="847dac14-3bfb-4f3b-9176-339c34c4ee14" TYPE="crypto_LUKS" PARTUUID="e091aba6-05"

/dev/sdb1 ist meine unverschlüsselte /boot-Partition und /dev/sdb5 mein verschlüsseltes /.

Die Partition wird entschlüsselt indem man folgenden Befehl und anschließend das Entschlüsselungspasswort eingibt:

cryptsetup luksOpen /dev/sdb5 laptop

Nach einigen Anleitungen sollten nun die entschlüsselten Partitionen bereits unter /dev/mapper/ aufzufinden zu sein, in meinem Fall musste ich aber erst noch nach LVM block devices scannen und diese aktivieren:

vgscan
vgchange -ay

Nun kann ich das / meines Laptops nach /mnt meines Netbooks mounten:

mount /dev/mapper/laptop-vg-root /mnt

Um GRUB neu auf /boot schreiben zu können musste ich natürlich /boot auch noch mounten:

mount /dev/sdb1 /mnt/boot

Anschließend konnte ich auf mein Laptop-System chrooten:

mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt

Nun konnte ich in /etc/default/grub die unsinnige Wartezeit von 0 Sekunden auf 5 Sekunden hochsetzen und GRUB neu schreiben lassen, anschließend habe ich zur Sicherheit auch noch mal das initramfs neu erstellen lassen:

update-grub
update-initramfs -uk all

Nachdem ich die SSD wieder in meinen Laptop gesteckt habe booted auch dieser wieder problemlos. 😄

Ein früher Schritt in unserem Bereitstellungsprozess für RHEL-Systeme umfasst die Registrierung des Systems im Red Hat Customer Portal und das Hinzufügen einer geeigneten Subskription. Um diese beiden Schritte zu automatisieren, nutze ich eine Ansible-Rolle, welche ich euch im Folgenden vorstellen möchte.

Umfeld

RHEL läuft bei uns vorwiegend innerhalb verschiedener Virtualisierungs-Cluster und vereinzelt auf dedizierten Servern (Blech). Wir nutzen für die Entwicklung und den Betrieb folgende Subskriptionen:

• Red Hat Developer Subscription
• Red Hat Enterprise Linux Server, Standard (Physical or Virtual Nodes)
• Red Hat Enterprise Linux for Virtual Datacenters, Standard

Die Rolle ‚register-rhel-subscription‘

Meine Rolle kommt minimalistisch daher und besitzt folgende Strukur:

# tree roles/register-rhel-subscription               
roles/register-rhel-subscription
|-- defaults
|   `-- main.yml
|-- tasks
|   `-- main.yml

tasks/main.yml

---
# tasks file for register-rhel-subscription
# Register System and add Subcription
 - name: Register system and add subscription
   redhat_subscription:
     activationkey: "{{ org_activationkey }}"
     org_id: 1234567
     state: present

redhat_subscription ist ein Ansible-Modul, welches das Kommando subscription-manager verwendet, um Registrierung und Subskription eines Systems zu verwalten.

Dem Parameter activationkey wird ein Aktivierungsschlüssel übergeben, welcher zuvor im Customer Portal erstellt werden muss. Dieser Schlüssel ermöglicht eine Registrierung, ohne interaktive Eingabe von Benutzername und Kennwort. In obigem Code wird dem Parameter der Inhalt der Variable org_activationkey übergeben. Wie und wo diese Variable definiert wird, werde ich im nächsten Abschnitt erklären.

Die ebenfalls erforderliche org_id kann man mit dem folgenden Kommando in Erfahrung bringen: sudo subscription-manager identity

Durch state: present wird der gewünschte Zielzustand deklariert. In diesem Fall soll das System also registriert werden. Ändert man diesen Parameter zu state: absent wird das System entsprechend de-registriert.

defaults/main.yml

In dieser Datei wird der Standard-Wert für die Variable org_activationkey definiert.

---
# defaults file for register-rhel-subscription
org_activationkey: "my-datacenter-sub"

Der in dieser Datei spezifizierte Wert kann je nach Bedarf z.B. in host_vars und group_vars überschrieben werden (Siehe dazu: Using Variables). So kann bspw. über die Gruppenzugehörigkeiten im Inventory gesteuert werden, welche Subskription einem Host bzw. einer Gruppe von Hosts zugewiesen werden soll.

Beispiel-Playbook

---
- hosts: all
  tasks:
    - name: Group by OS
      group_by: key=os_{{ ansible_distribution }}
      changed_when: False

- hosts: os_RedHat
  roles:
    - register-rhel-subscription

Fazit

Diesen Text zu schreiben hat deutlich länger gedauert, als die eigentliche Aufgabe umzusetzen. Bisher macht diese Lösung einen robusten Eindruck.

Falls ihr Fragen oder Anregungen habt, sind diese in den Kommentaren herzlich willkommen.

Ich erstelle regelmäßig Screenshots oder andere Grafiken, beispielsweise für diese Webseite. Um das Bild an die Farbgebung der Webseite anzupassen, benötige ich häufig den Farbcode von einer bestimmten Stelle des abgebildeten Programms oder der abgebildeten Webseite.

Mein bisheriger Weg um an den richtigen Farbcode zu kommen war etwas kompliziert. Zuerst habe ich einen Screenshot erstellt und diesen in Gimp importiert. Dann habe ich mir mit dem color picker von Gimp den Farbcode der gewünschten Stelle anzeigen lassen.

Es geht aber sehr viel einfacher, mit dem Tool “Pick“.

Mit “Pick” Hex- oder RGB-Farbcodes von einer beliebigen Stelle des Desktops anzeigen lassen

Pick ist ein Werkzeug, das es einem ermöglicht den Farbcode von einer beliebigen Stelle auf dem Desktop, bzw. von jeder Stelle eines Programms anzeigen zu lassen.

Die Farbe an der ausgewählten Stelle kann man sich in verschiedenen Farbcodes anzeigen lassen, beispielsweise als HEX- oder RGB-Codes. Beim picken einer Farbe auf dem Desktop erstellt Pick einen Screenshot, so dass man später nachvollziehen kann von welcher Stelle, bzw. aus welchem Programm oder Webseite man die Farbe gepickt hat.

Um die Farbe an der richtigen stelle auf dem Desktop zu wählen, öffnet Pick eine Lupe mit einem Cursor. In dieser Ansicht kann man außerdem mit dem Mausrad noch hineinzoomen, so dass man pixelgenau den richtigen Farbton picken kann.

Außerdem speichert Pick den Verlauf der gepickten Farben, so dass man diese später einfach wieder aufrufen kann. Ein Klick auf den Button “Copy” kopiert den Farbcode in die Zwischenablage. Von dort aus kann man diesen einfach im Bildbearbeitungsprogramm einfügen.

Pick ist Open Source, der Quellcode des Programms ist auf GitHub zu finden. Die Webseite des Projekts ist https://kryogenix.org/code/pick. Wer sich nicht selber um die benötigten Abhängigkeiten, bzw. um Updates für Pick kümmern möchte, der kann sich einfach das Snap-Paket installieren. Dabei handelt es sich auch um die vom Projekt empfohlene Installationsmethode.

Bei einigen Distributionen muss zuerst snapd installiert werden, damit Snaps installiert und ausgeführt werden können. Da das Snap-Paketformat maßgeblich von Canonical entwickelt wird, kann man Snaps unter Ubuntu direkt installieren und nutzen. Pick lässt sich unter Ubuntu einfach mit “sudo snap install pick-colour-picker” installieren.

Pick ist für mich ein praktisches Werkzeug um den Hex-Code einer Farbe von einer beliebigen Stelle auf dem Bildschirm herauszufinden um damit weiterarbeiten zu können. Es ist eines dieser kleinen Tools, die nur eine Aufgabe erfüllen, diese aber sehr gut.

Pick: Farbcodes von beliebiger Stelle des Desktops picken ist ein Beitrag von techgrube.de.

Was machen Sie mit einem USB-Stick, den Sie auf der Straße finden? Wenn Ihnen die Grundregeln der IT-Sicherheit bekannt sind, dann stecken Sie den USB-Stick natürlich nicht in die Buchse Ihres Notebooks. Da könnte nämlich einiges schief gehen:

• Vielleicht handelt es sich nicht um einen USB-Stick sondern um ein Gerät, das sich zuerst auflädt und dann über einen Stromstoß Ihren Computer zerstört (siehe https://usbkill.com).
• Oder, nicht ganz so schlimm, das Gerät ist ein Hacking-Device, das zwar wie ein USB-Stick aussieht, sich in Wirklichkeit aber als Tastatur ausgibt und sofort beim Anstecken Schad- oder Überwachungs-Software installiert. Es gibt ine ganze Palette derartiger Geräte, z.B. Rubber Ducky oder Digispark.
• Wenn Sie richtiggehend Glück haben, ist Ihr Fund wirklich ein gewöhnlicher USB-Stick. Es könnte aber sein, dass die darauf enthaltenen Dateien Viren oder andere Schad-Software enthalten …

Am sichersten ist es also, das Fundstück — so es keinem Besitzer zuzuordnen ist — zum Elektroschrott zu bringen.

CIRCLean

Wenn die Neugier doch siegt, kommt das Projekt CIRCLean des Computer Incident Response Center Luxembourg ins Spiel. Das ist eine winzige Raspberry-Pi-Distribution, die eine simple Aufgabe erfüllt: Nach dem Start des Raspberry Pi werden die Dateien des ersten USB-Sticks (obere Buchse) auf die eines zweiten USB-Sticks (untere Buchse) kopiert. Bei verdächtigen Dateien (Office-Dateien mit Makros, EXE- und BAT-Dateien) wird dabei der Dateiname in DANGEROUS_<ursprünglicher-name>_DANGEROUS geändert. ZIP-Dateien werden ausgepackt, ihr Inhalt wird natürlich ebenfalls überprüft.

Zur Inbetriebnahme laden Sie das CIRCLean-Image von der folgenden Webseite herunter und übertragen es auf eine SD-Karte:

https://www.circl.lu/projects/CIRCLean

Jetzt brauchen Sie nur noch einen alten Raspberry Pi. (Die Modelle 3B+ und 4B werden leider noch nicht unterstützt.) Die Anwendung von CIRCLean sieht so aus:

• Sie stecken die SD-Karte in den Raspberry Pi, schalten den Rechner aber vorerst noch nicht ein.
• Sie stecken den Quell-USB-Stick in eine der oberen USB-Buchsen.
• Sie stecken den Ziel-USB-Stick in eine der unteren USB-Buchsen. Dieser USB-Stick sollte ein leeres VFAT-Dateisystem enthalten. Das Dateisystem muss genug Platz für alle Dateien der Quelle bieten, wobei Sie berücksichtigen müssen, dass ZIP-Dateien ausgepackt werden.
• Der Raspberry Pi muss weder mit einem Netzwerk noch mit einem Monitor verbunden werden.
• Nun verbinden Sie den Raspberry Pi mit der Stromversorgung.
• CIRCLean bootet, kopiert die Dateien vom Quell- zum Ziel-USB-Stick und fährt den Mini-Computer danach automatisch wieder herunter.

Ohne Monitor ist das Ende des Kopierprozesses schwer zu erkennen. Deswegen werden während des Kopiervorgangs diverse Musikstücke abgespielt. Über einen Lautsprecher oder Kopfhörer mit 3,5mm-Klinkenbuchse können Sie eindeutig feststellen, ob CIRCLean noch arbeitet.

Einschränkungen

Die Grundidee von CIRCLean ist gut, die Implementierung wirkt aber etwas halbherzig.

• Es gibt keine Benutzeroberfläche. Natürlich ist es toll, dass CIRCLean geringe Hardware-Anforderungen stellt. Ordentliche Status-Ausgaben auf einem angeschlossenen Monitor würden aber wesentlich mehr Sicherheit vermitteln.
• CIRCLean läuft aktuell nur mit alten Raspberry-Pi-Modellen.
• Die Überprüfung, ob die Dateien frei von Schad-Software sind, ist rudimentär. Es wird dabei kein Viren-Scanner verwendet. Eine absolute Sicherheit, dass die kopierten Dateien auf dem Ziel-USB-Stick frei von Sicherheitsrisken sind, kann CIRCLean daher nicht geben.
• Bei USB-Sticks mit vielen Dateien ist CIRCLean langsam.

Quellen

• https://www.circl.lu/projects/CIRCLean
• https://github.com/CIRCL/Circlean
• https://github.com/CIRCL/PyCIRCLean/blob/master/filecheck/filecheck.py

Heut auf dem Tag genau vor 5 Jahren habe ich mich entschlossen zu Ubuntu zu wechseln und daher möchte ich hier einen kleinen Rückblick schreiben.

Nachdem ich lange Zeit Debian genutzt habe (Version 4 bis 7) zwang mich der Kauf meines damals neuen Notebooks zum umdenken. Mangels Treiber lief Debian auf dem Gerät so langsam das an einer normalen Arbeit nicht mehr zu denken war. Obwohl ich bereits einige Distributionen getestet hatte (Suse, Mandriva, Slackware) kam mir Ubuntu mit der Verwandschaft zu Debian am sinnvollsten vor.

Am 21.07.2014 kaufte ich also eine Zeitschrift mit Ubuntu 14.04 DVD und entschloss mich zum Wechsel. Die Installation war mir von vorheringen Experimenten nicht fremd, und ich wurde auch nicht entäuscht. Das System lief flott und tat das was es sollte. So stand mein Entschluss fest: Ubuntu ist die Distribution die ich ab nun auf allen Rechnern einsetzten werde.

Nachdem das Notebook installiert war habe ich auch meinen Desktop sowie den Server auf Ubuntu umgestellt. Hier habe ich mit 14.04 angefangen und später zunächst auf 16.04 bis aktuell 18.04 gewechselt.
Mir war immer wichtig das sowohl auf Notebook, Desktop und auch dem Server die gleiche Ubuntu Version läuft da ich eine homogene Umgebung mag. Auch im beruflichen Umfeld habe ich wert darauf gelegt mit der jeweiligen Ubuntu Version zu arbeiten.

Jetzt nach 5 Jahren Ubuntu kann ich sagen das ich den wechsel nicht bereut habe. Ganz im Gegenteil hat es sich als eine gute Entscheidung erwiesen.

Mozilla hat vor kurzem Firefox 68 veröffentlicht. Firefox 68 stellt gleichzeitig auch die neue Basis von Firefox ESR dar, der Browser-Version mit Langzeitunterstützung. Dieser Artikel fasst die wichtigsten Neuerungen zusammen.

Download Mozilla Firefox für Microsoft Windows, Apple macOS und Linux

Mehr Sicherheit für Firefox-Nutzer

Geschlossene Sicherheitslücken

Auch in Firefox 68 hat Mozilla wieder zahlreiche Sicherheitslücken geschlossen, worunter auch einige sind, welche von Mozilla als besonders schwerwiegend eingestuft werden. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 68 daher für alle Nutzer dringend empfohlen.

Eine Folge der in Firefox 68 geschlossenen Sicherheitslücken ist, dass lokale Dateien nicht länger auf andere Dateien im gleichen Verzeichnis zugreifen können. Diese Einschränkung kann über about:config aufgehoben werden, indem der Schalter privacy.file_unique_origin auf false gesetzt wird. Aus Sicherheitsgründen sei hiervon jedoch ausdrücklich abgeraten.

Automatische MITM-Erkennung und -Behebung

Nicht nur Schadsoftware, auch sogenannte „Sicherheits“-Software unterbricht verschlüsselte Verbindungen (das heißt Verbindungen über https://) immer wieder, um die Inhalte zu lesen, bevor diese den Browser erreichen, und verkauft dies dann auch noch als Feature. Man spricht dabei von einem sogenannten Man-in-the-Middle („MITM“). Die Folge für Firefox-Nutzer ist aufgrund der häufig mangelhaften Implementierung in einigen Fällen, dass Firefox keine Verbindungen über https:// mehr herstellen kann. Firefox 68 versucht MITM zu erkennen und automatisch zu beheben.

Kamera- und Mikrofon-Zugriff nur noch über HTTPS

Die verschlüsselte Übertragung von Daten im Web gewinnt immer mehr an Bedeutung. Bereits über 78 Prozent aller von Firefox-Nutzern geladenen Webseiten werden über HTTPS anstelle von HTTP übertragen.

Auch immer mehr Web-Features können nur noch in einem sicheren Kontext genutzt werden. Von einem sicheren Kontext spricht man bei der Verwendung von HTTPS, aber auch verschlüsselte WebSocket-Verbindungen (wss://) sowie lokale Ressourcen (wie http://localhost/ oder file://) werden als sicherer Kontext betrachtet.

Ab Firefox 68 erfordert auch der Zugriff auf Kamera und Mikrofon via getUserMedia-API einen sicheren Kontext.

Windows: Launcher-Prozess

Der Launcher-Prozess ist ein spezieller Firefox-Prozess, der in Firefox 67 für erste Nutzer und ab Firefox 68 für alle Nutzer unter Windows aktiviert ist und die Sicherheit verbessern soll.

Nutzer, die unter Windows mit Administratoren-Rechten unterwegs sind und das UAC-Feature von Windows deaktiviert haben, können keine URLs mehr auf den Desktop ziehen, um dort eine Verknüpfung zur jeweiligen Website zu erstellen. Hintergrund sowie mögliche Lösungen werden in einem Hilfe-Artikel (engl.) beschrieben.

Cryptomining- und Fingerprinting-Blocker

In Firefox 67 hat Mozilla seinen integrierten Content-Blocker optional um die Möglichkeit erweitert, Cryptomining– sowie Fingerprinting-Scripts zu blockieren. Ab Firefox 68 sind beide neue Schutz-Optionen Teil der strengen Konfiguration und nicht mehr nur über die Option „Benutzerdefiniert“ auswählbar.

WebRender für AMD-Nutzer

WebRender stammt wie die mit Firefox 57 eingeführte CSS-Engine Stylo ebenfalls aus Mozillas Next-Generation-Engine Servo und ist in der Programmiersprache Rust geschrieben. Es handelt sich bei WebRender um einen Renderer für Webseiten-Inhalte, welcher unter stärkerer Einbeziehung der Grafikkarte als bisher im Grunde wie eine Spiele-Engine arbeitet, aber für das Rendering von Web-Content optimiert ist und dadurch große Performance-Vorteile liefern soll.

In Firefox 67 wurde WebRender für die ersten Nutzer aktiviert. Voraussetzung war Windows 10 als Betriebssystem, ein Computer, welcher sich nicht im Akku-Betrieb befindet, sowie eine halbwegs moderne Grafikkarte von Nvidia. Mit Firefox 68 qualifizieren erstmals auch Grafikkarten von AMD für die Nutzung von WebRender.

QuantumBar: Neuentwicklung der Adressleiste

Die Adressleiste, welche in Firefox auch Awesome Bar genannt wird, ist eine der wichtigsten Komponenten eines jeden Browsers. Und eben jene Komponente wurde von Grund auf neu entwickelt. Die Neu-Implementierung hört auf den Namen QuantumBar, passend zu Firefox Quantum, wie sich Firefox seit Firefox 57, dem größten Firefox-Release aller Zeiten, nennt.

Die QuantumBar kommt ohne proprietäre Mozilla-Technik wie XUL und XBL aus. Stattdessen ist sie vollständig in handelsüblicher Webtechnologie programmiert. Abgesehen davon bildet die QuantumBar die Grundlage für weitere Verbesserungen und Experimente in der Zukunft, was mit der alten Implementierung sehr erschwert gewesen wäre.

Das Entfernen eines Chronik-Eintrags über die Adressleiste erfordert nun auf allen Plattformen eine Kombination von Shift + Entf respektive Shift + Backspace, während die Shift-Taste vorher nur auf Apple macOS erforderlich war. Ansonsten sollten dem Nutzer kaum Unterschiede auffallen.

In Firefox 68.0 funktioniert allerdings das Aufrufen von JavaScript-Bookmarklets über die Eingabe eines Schlüsselworts in die Adressleiste nicht. Dies wird im nächsten Firefox-Update behoben sein.

Neuentwicklung des Add-on Managers

Auch der Add-on Manager ist eine wichtige Komponente von Firefox, da über diesen sämtliche Erweiterungen, Themes und Sprachpakete verwaltet werden. Und auch die Oberfläche des Add-on Managers wurde in Firefox 68 neu entwickelt, auch hier auf Basis von Webtechnologie statt XUL und XBL. Im Falle des Add-on Managers sind aber auch optisch größere Unterschiede zu erkennen.

Im neuen Listen-Design, welches auf den ersten Blick nur leicht verändert ist, bleibt mehr Platz für die Beschreibungen, weil die Buttons zugunsten eines Drei-Punkte-Menüs verschwunden sind, wie es bereits an anderen Stellen von Firefox vorkommt. Die Detail-Ansicht der Erweiterungen lässt sich aber auch wie bisher per einfachem Klick an eine beliebige Stelle der entsprechenden Zeile öffnen.

Deaktivierte Erweiterungen werden von aktivierten Erweiterungen jetzt durch eine Überschrift klarer voneinander getrennt. In den Details gibt es optional jetzt auch Reiter für die Versionshinweise des letzten Updates sowie die von der Erweiterung benötigten Berechtigungen. Ebenfalls neu ist die Möglichkeit, Erweiterungen an Mozilla zu melden. Dabei steht eine Vielzahl möglicher Gründe zur Auswahl.

Unterhalb der installierten Add-ons gibt es Empfehlungen für weitere Erweiterungen. Die Empfehlungen basieren auf den installierten Erweiterungen, Einstellungen sowie Nutzungs-Statistiken. Wer keine Empfehlungen mag, kann diese über about:config abschalten, indem der Schalter extensions.htmlaboutaddons.recommendations.enabled auf false gesetzt wird.

Dunkle Lese-Ansicht nun vollständig dunkel

Per Klick auf das Buch-Symbol in der Adressleiste erscheinen Artikel auf Webseiten so aufbereitet, dass sie störungsfrei gelesen werden können. Konkret bedeutet dies eine angenehme Farbgebung und Schriftgestaltung sowie keine störenden Elemente wie Werbung. Im Vordergrund steht der Inhalt des Artikels. Der Nutzer hat dabei die Wahl zwischen einer serifen sowie einer serifenlosen Schriftart, kann das Farbschema ändern (Hell, Dunkel, Sepia) sowie die Schriftgröße anpassen. Außerdem kann sich der Nutzer den Artikel sogar vorlesen lassen.

Wird das dunkle Farbschema gewählt, erscheinen ab Firefox 68 auch die Bedienelemente der Lese-Ansicht in dunkler Farbe.

BITS für Updates unter Windows

Unter Windows nutzt Firefox ab sofort den Windows Background Intelligent Transfer Service (BITS) für Updates. Der Nutzer sollte von dieser Änderung zunächst nichts bemerken. In Zukunft soll BITS genutzt werden, um Updates auch dann installieren zu können, wenn Firefox geschlossen ist.

Verbesserungen für Firefox-Erweiterungen (WebExtensions)

Natürlich gab es auch in Firefox 68 wieder einige Neuerungen für Entwickler von Firefox-Erweiterungen. Unter anderem gibt es nun eine Schnittstelle zum WLAN-Anmeldemasken in öffentlichen Netzwerken zu erkennen und entsprechend darauf zu reagieren. Die WebRequest-API hat Verbesserungen für die Nutzung in privaten Fenstern und für Tab-Umgebungen erhalten. Das Verhalten der tabs.duplicate()-Methode wurde angepasst, um kompatibel mit dem Verhalten von Google Chrome zu sein.

Eine Übersicht über diese und weitere Neuerungen für Erweiterungs-Entwickler gibt es hier.

Verbesserungen der Webplattform

Firefox 68 unterstützt das CSS-Feature Scroll Snap, worüber gesteuert werden kann, dass das Layout beim Scrollen an bestimmten Stellen einrastet.

Das CSS Pseudo-Element ::marker wird von Firefox nun unterstützt. Die Notification API benötigt nun eine Interaktion durch den Benutzer, bevor diese anfragen darf, ob der Benutzer Benachrichtigungen erhalten möchte.

Firefox unterstützt jetzt außerdem den numerischen Datentyp BigInt in JavaScript. Der window.open()-Funktion kann ab sofort auch die noreferrer-Option mitgegeben werden.

Dies war nur eine kleine Auswahl an Änderungen der Webplattform. Weitere Informationen zu Verbesserungen der Webplattform in Firefox 68 finden sich in den MDN web docs.

Neuerungen für Webentwickler

about:compat listet Kompatibilitäts-Fixes auf

Normalerweise sind Webseiten selbst dafür verantwortlich, dass diese in jedem Browser korrekt funktionieren. In Ausnahmefällen hilft Firefox aber auch nach. So kann es sein, dass Firefox auf bestimmten Webseiten entweder vorgibt, ein anderer Browser zu sein, weil Firefox-Nutzer durch User-Agent-Sniffing ausgeschlossen werden, Firefox kann aber auch Probleme lösen, indem Code in eine Webseite injiziert wird.

Solche Maßnahmen sind Ausnahme und nicht die Regel und immer nur temporär angedacht, während das Ziel ist, dass das Problem seitens Webseite gelöst wird.

Mit about:compat bietet Firefox ab sofort eine Übersicht über aktive Kompatibilitäts-Anpassungen an, die von Firefox vorgenommen werden. Neben der Nennung der betroffenen Domain ist immer auch das dazugehörige Ticket in Mozillas Bugtracking-System verlinkt, außerdem kann über diese Seite jede Anpassung einzeln deaktiviert und wieder aktiviert werden.

Probleme mit dem Kontrastverhältnis

Die Entwicklerwerkzeuge von Firefox besitzen im Reiter Barrierefreiheit ein Feature, um das Kontrastverhältnis zwischen Hintergrund- und Textfarbe von Elementen zu überprüfen. Bislang konnte diese Überprüfung Element für Element vorgenommen werden, ab Firefox 68 gibt es einen Audit-Button, der die gesamte Webseite überprüft und die Probleme auflistet.

Druck-Stil-Simulation

Webseiten, wie sie auf dem Bildschirm erscheinen, müssen ausgedruckt nicht zwangsläufig genauso aussehen. Mittels CSS lassen sich Regeln festlegen, welche speziell für die Druckansicht gelten.

So bequem sich bisher bereits das CSS von Webseiten mittels integrierter Entwicklerwerkzeuge zur Laufzeit ändern und Änderungen damit testen lassen, so schwierig ist dies bisher für die Druckansicht von Webseiten.

Ab Firefox 68 gibt es eine Schaltfläche in den Entwicklerwerkzeugen von Firefox, welche das Print-CSS einer Webseite aktivieren. Damit lassen sich Anpassungen des Druck-Stils genauso einfach testen wie es mit dem regulären Webseiten-Stil bereits seit Jahren der Fall ist.

Entwickler-Werkzeuge erklären, wieso CSS auf Webseiten nicht funktioniert

Ein Problem, welches vermutlich viele kennen, die Webseiten erstellen: Man hat einem Element eine Eigenschaft per CSS zugewiesen, wundert sich dann aber, wieso nicht das passiert, was passieren soll. Ab Firefox 68 kann der Mozilla-Browser in solchen Situationen helfen.

Dann nämlich stellt Firefox inaktives CSS im Regeln-Panel des Inspektors blass und mit einem Info-Symbol dar. Fährt man mit der Maus über das Symbol, erscheint eine Erklärung, wieso diese Regel inaktiv ist. Zum Beispiel würde bei der Verwendung der Eigenschaft align-items außerhalb eines Flex- oder Grid-Containers die Erklärung kommen, dass diese Eigenschaft nur mit display: flex oder display: grid einen Effekt hat.

Standardmäßig ist dieses Feature in Firefox 68 noch deaktiviert, kann aber aktiviert werden, indem über about:config der Schalter devtools.inspector.inactive.css.enabled auf true gesetzt wird. Bislang sind erst diverse Regeln für Flex- und Grid-Layouts implementiert, viele weitere Regeln sollen folgen.

Weitere Verbesserungen der Entwicklerwerkzeuge

Die Konsole zeigt jetzt mehr Informationen zu CSS-Fehlern an, darunter auch alle Elemente, welche die entsprechende Eigenschaft genutzt haben. Anti-Tracking-Warnungen in der Konsole werden außerdem gruppiert.

Über die Netzwerkanalyse ist es nun per Kontextmenü möglich, bestimmte Ressourcen zu blockieren. Dort kann außerdem jetzt die Breite der Spalten angepasst werden.

Im Werkzeug Web-Speicher ist es jetzt möglich, die Werte aus der Sidebar zu kopieren. Im Responsive Design Modus wurde der Dialog zum Hinzufügen von Geräten überarbeitet. In der Schriftarten-Ansicht gibt es nun auch eine Einstellung für den Zeichenabstand. Überarbeitet wurde auch der Farbwähler im Inspektor.

Auf Webseiten, deren Server noch kein TLS 1.2 oder höher spricht, wird eine Warnung in der Konsole ausgegeben.

Weitere Informationen zu Verbesserungen für Webentwickler in Firefox 68 finden sich in den MDN web docs.

Enterprise Features

Alle Unterschiede zwischen Firefox 68 und Firefox ESR 68

Firefox 68 ist gleichzeitig die neue Basis für Firefox ESR, die Firefox-Version mit Langzeitunterstützung. Während Firefox 68 und Firefox ESR 68 grundsätzlich identisch sind, gibt es doch ein paar wichtige Unterschiede zwischen beiden Versionen. Diese Unterschiede und weitere wissenswerte Informationen für System-Administratoren wurden in einem gesonderten Artikel ausführlich behandelt.

Neue Enterprise Policies

Mittels Enterprise Policy Engine kann Firefox vorkonfiguriert werden, was vor allem im Unternehmensumfeld interessant ist. Dies geschieht auf Windows über GPO, auf Apple macOS via .plist-Datei oder plattformübergreifend auf Windows, Apple macOS und Linux über eine Datei policies.json.

In Firefox 68 sind zahlreiche neue Einstellungen dazugekommen, welche via Enterprise Policy Engine konfiguriert werden können. Firefox 68 stellt das mit Abstand größte Update diesbezüglich seit Einführung der Enterprise Policy Engine dar.

Eine Übersicht über alle Enterprise Policies und deren Konfiguration gibt es hier.

Tipp: Mit dem Enterprise Policy Generator wird die Konfiguration von Firefox zum Kinderspiel. Im Laufe der nächsten Wochen wird ein großes Update auf Version 5.0 erscheinen, dann mit vollständiger Unterstützung aller neuen Policies von Firefox 68.

Sonstige Neuerungen in Firefox 68

Mozilla hat den Schutz vor der missbräuchlichen Benutzung von Authentifizierungsdialogen verbessert. Beim Hinzufügen von Cookie-Ausnahmen werden bei Weglassen des Protokolls nun automatisch sowohl für HTTP als auch HTTPS Ausnahmen hinzugefügt.

Die Multiprozess-Architektur, welche eine wichtige Grundlage für Sicherheit sowie Stabilität des Browsers ist, kann nicht länger abgeschaltet werden.

Die in Firefox integrierten Suchmaschinen wurden in WebExtensions umgewandelt. Dies hat zur Folge, dass diese auf about:support derzeit unter den Erweiterungen erscheinen.

Für Nutzer von Windows 10 wird bei Installation von Firefox ab sofort eine Verknüpfung in der Taskleiste angelegt.

Firefox 68.0.1

Mittlerweile hat Mozilla Firefox 68.0.1 veröffentlicht. Die Neuerungen von Firefox 68.0.1 werden in einem gesonderten Artikel behandelt.

Der Beitrag Die Neuerungen von Firefox 68 erschien zuerst auf soeren-hentzschel.at.

Die meisten Dienste im Netz lassen sich in zwei Kategorien einteilen: Zentralisierte Dienste und dezentralisierte Angebote. Bei ersteren gibt es eine zentrale Instanz über die der Dienst betrieben wird, bei letzteren eine dezentralisierte Struktur unabhängig betriebener Server. Dezentralisierte Dienste sind oft Open Source aber auch zentralisierte Angebote können quelloffen sein.

Dezentralisierte Dienste, insbesondere zur Kommunikation, sind aber vor allem in der Open Source Community populär. Die Vorteile liegen auf der Hand. Durch die dezentrale Struktur gibt es keine neuralgischen Punkte, deren Störung das Angebot lahmlegen würde. Dezentrale quelloffene Lösungen kommen zudem dem "Do-it-yourself" Gedanken in der OSS-Szene entgegen, nach dem jeder Dienstbetreiber werden kann.

In der Praxis gibt es im Bereich der Kommunikation nur ein dezentrales Angebot von wirklicher Bedeutung: Die E-Mail. Dies hat vor allem historische Gründe und liegt in den gewachsenen Kommunikationsstrukturen. Andere dezentralisierte Kommunikationslösungen konnten sich nie gegen die zentralisierte, oft proprietäre Konkurrenz durchsetzen. Warum das so ist kann man sehr gut an XMPP/"Jabber" zeigen.

Jabber bzw. XMPP kam auf als die 2000er noch jung waren. Die große Konkurrenz hieß ICQ, damals der unbestrittene Markführer für Kurznachrichten. Die Älteren werden sich vielleicht noch erinnern. Smartphones waren noch noch nicht mal in den Forschungslaboren der großen IT-Konzerne angekommen und selbst Notebooks für die breite Öffentlichkeit unbezahlbar. Messenger bediente man damals auf dem PC und beide Kommunikationspartner waren zeitgleich online. Verschlüsselung setzte Rechenkapazitäten voraus, die fast niemand privat besaß.

Nach der Standardisierung 2004 wurde XMPP die Basis für viele proprietäre Angebote. Google experimentierte mit einer VoIP-Funktion (Google Talk) und 2005 zog die Erweiterung "Jingle" in XMPP ein. Hinzu kam dann auch noch Gruppenchats (MUC) und einiges weiteres. XMPP hatte das Potenzial die Standardlösung für Messenger zu werden, vergleichbar der E-Mail für zeitversetzte Kommunikation. Nicht nur Google-Kunden hatten automatisch XMPP, sondern auch die in Deutschland wichtigen Dienste von United Internet lieferten dies für ihre E-Mail Nutzer aus. Mittelfristig hätte man ICQ sicher den Rang abgelaufen.

Dann kamen zwei heftige Einschläge. Zuerst änderte das iPhone ab 2007 die Art wie man kommunizierte, dann erfuhr die Weltöffentlichkeit 2013, dass westliche Geheimdienste alles mithörten. Auf beides war XMPP nicht vorbereitet.

In der Folgezeit hoben neue StartUps Messengerdienste wie WhatsApp aus der Taufe und nicht mehr ganz so neue StartUps wie Facebook erweiterten ihre Angebote irgendwann um Kurznachrichtendienste. Beides auf Basis von XMPP aber beide koppelten sich entweder sofort oder später vom Netzwerk ab. Geschlossene Kommunikationsnetze versprachen eine stabilere Kundenbasis. Eine agil handelnde zentrale Stelle hätte nun Fehleranalyse betrieben und versucht den Dienst konkurrenzfähig zu halten. Die Veränderung der Kommunikationsgewohnheit war offensichtlich. Die Verknüpfung des Messengers mit der Telefonnummer war beispielsweise eine geniale Idee von WhatsApp, die nahezu jeder nachfolgende Dienst kopierte. XMPP nicht. Hier musste man wie zu ICQ-Zeiten weiterhin eine separate Kennung dem Kommunikatiospartner mitteilen. Nur eines von vielen Beispielen, bei denen man den Anschluss verlor.

Das zweite Problem war die fehlende Verschlüsselung für text-, audio- und videobasierte Kommunikation. Hier griff man zuerst auf OTR zurück, eine Lösung die ebenso wie XMPP älter als das Smartphone war. Weil hierfür beide Kommunikationspartner zeitgleich online sein müssen, eignete sic dieser Ansatz für die Welt der mobilen Kommunikation überhaupt nicht. Erst 2015 implementierte der Entwickler von Conversations im Rahmen eines GSoC-Projektes das Signal-Protokoll (vormals Axolotl) in XMPP. Eine notwendige Erweiterung, die bis heute nicht offiziell angenommen wurde. Die Verschlüsselung von Video- und Sprachkommunikation trieb Jitsi voran und setzte hierfür auf OTR und ZRTP. Bisher nutzt diese Methode kein anderer Client.

Hier kommen wir zum Kern des Problems dezentralisierter Dienste. Die Kommunikationsgewohnheiten ändern sich rasant und neue Anforderungen entstehen. Dezentralisierte Dienste nehmen erstens die Herausforderung viel zu spät auf (OMEMO kam 2 Jahre nach Snowden!), Conversations als mobil funktionsfähige Lösung 5 Jahre nach WhatsApp. Zweitens fragmentieren solche Erweiterungen das Ökosystem, weil die Standardisierung ewig dauert und die Clients diese nicht zeitnah implementieren. OMEMO ist immer noch nicht in der Mehrheit der Clients integriert. Für mobile und sichere Kommunikation braucht der Anwender also nicht nur den richtigen Client und einen passenden Server, sondern der Kommunikationspartner auch.

XMPP funktioniert zudem nicht nur dezentral, es wird auch dezentral entwickelt. Wenn es eine zentrale Entwicklung des Protokolls und Referenzclients gibt, kann man Änderungen verhältnismäßig schnell ausrollen. Das Ökosystem passt sich dann meist schnell an. Bei XMPP fügen kleine Entwicklergruppen oder Einzelpersonen Erweiterungen an und versuchen diese offiziell zu machen. Server und Clients ziehen nach oder eben auch nicht. Bis sich Änderungen durchsetzen vergeht so viel Zeit.

Selbst wenn man dann irgendwann funktional gleichgezogen hat man agileren zentralisierten Projekten, ist der Zug schon lange abgefahren. Die Entwicklung der letzten Jahre hat eines schließlich deutlich gezeigt: Es gewinnt nicht das qualitativ hochwertigste Projekt, sondern jenes, dass sich früh etablieren und große Marktanteile sichern konnte. Ansonsten wäre Android nicht so erfolgreich und WhatsApp auch nicht.

Das spricht nun nicht unbedingt gegen dezentrale Ansätze allgemein - wohl aber gegen dezentrale Ansätze in der Massenkommunikation. Der Anspruch an einen Messenger ist es - vergleichbar zu WhatsApp nahezu jeden zu erreichen. Wenn er dies nicht leisten kann wenden sich die Menschen ab, weil niemand dutzende verschiedene Messenger bediene möchte. Soll der Dienst jedoch nur in einer definierten Gruppe zum Einsatz kommen können diese natürlich per Absprache Änderungen festlegen oder notfalls auf ein anderes Angebot migrieren.

Bilder:
Einleitungsbild und Beitragsbild von von geralt via pixabay

Die meisten Dienste im Netz lassen sich in zwei Kategorien einteilen: Zentralisierte Dienste und dezentralisierte Angebote. Bei ersteren gibt es eine zentrale Instanz über die der Dienst betrieben wird, bei letzteren eine dezentralisierte Struktur unabhängig betriebener Server. Dezentralisierte Dienste sind oft Open Source aber auch zentralisierte Angebote können quelloffen sein.

Dezentralisierte Dienste, insbesondere zur Kommunikation, sind aber vor allem in der Open Source Community populär. Die Vorteile liegen auf der Hand. Durch die dezentrale Struktur gibt es keine neuralgischen Punkte, deren Störung das Angebot lahmlegen würde. Dezentrale quelloffene Lösungen kommen zudem dem "Do-it-yourself" Gedanken in der OSS-Szene entgegen, nach dem jeder Dienstbetreiber werden kann.

In der Praxis gibt es im Bereich der Kommunikation nur ein dezentrales Angebot von wirklicher Bedeutung: Die E-Mail. Dies hat vor allem historische Gründe und liegt in den gewachsenen Kommunikationsstrukturen. Andere dezentralisierte Kommunikationslösungen konnten sich nie gegen die zentralisierte, oft proprietäre Konkurrenz durchsetzen. Warum das so ist kann man sehr gut an XMPP/"Jabber" zeigen.

Jabber bzw. XMPP kam auf als die 2000er noch jung waren. Die große Konkurrenz hieß ICQ, damals der unbestrittene Markführer für Kurznachrichten. Die Älteren werden sich vielleicht noch erinnern. Smartphones waren noch noch nicht mal in den Forschungslaboren der großen IT-Konzerne angekommen und selbst Notebooks für die breite Öffentlichkeit unbezahlbar. Messenger bediente man damals auf dem PC und beide Kommunikationspartner waren zeitgleich online. Verschlüsselung setzte Rechenkapazitäten voraus, die fast niemand privat besaß.

Nach der Standardisierung 2004 wurde XMPP die Basis für viele proprietäre Angebote. Google experimentierte mit einer VoIP-Funktion (Google Talk) und 2005 zog die Erweiterung "Jingle" in XMPP ein. Hinzu kam dann auch noch Gruppenchats (MUC) und einiges weiteres. XMPP hatte das Potenzial die Standardlösung für Messenger zu werden, vergleichbar der E-Mail für zeitversetzte Kommunikation. Nicht nur Google-Kunden hatten automatisch XMPP, sondern auch die in Deutschland wichtigen Dienste von United Internet lieferten dies für ihre E-Mail Nutzer aus. Mittelfristig hätte man ICQ sicher den Rang abgelaufen.

Dann kamen zwei heftige Einschläge. Zuerst änderte das iPhone ab 2007 die Art wie man kommunizierte, dann erfuhr die Weltöffentlichkeit 2013, dass westliche Geheimdienste alles mithörten. Auf beides war XMPP nicht vorbereitet.

In der Folgezeit hoben neue StartUps Messengerdienste wie WhatsApp aus der Taufe und nicht mehr ganz so neue StartUps wie Facebook erweiterten ihre Angebote irgendwann um Kurznachrichtendienste. Beides auf Basis von XMPP aber beide koppelten sich entweder sofort oder später vom Netzwerk ab. Geschlossene Kommunikationsnetze versprachen eine stabilere Kundenbasis. Eine agil handelnde zentrale Stelle hätte nun Fehleranalyse betrieben und versucht den Dienst konkurrenzfähig zu halten. Die Veränderung der Kommunikationsgewohnheit war offensichtlich. Die Verknüpfung des Messengers mit der Telefonnummer war beispielsweise eine geniale Idee von WhatsApp, die nahezu jeder nachfolgende Dienst kopierte. XMPP nicht. Hier musste man wie zu ICQ-Zeiten weiterhin eine separate Kennung dem Kommunikatiospartner mitteilen. Nur eines von vielen Beispielen, bei denen man den Anschluss verlor.

Das zweite Problem war die fehlende Verschlüsselung für text-, audio- und videobasierte Kommunikation. Hier griff man zuerst auf OTR zurück, eine Lösung die ebenso wie XMPP älter als das Smartphone war. Weil hierfür beide Kommunikationspartner zeitgleich online sein müssen, eignete sic dieser Ansatz für die Welt der mobilen Kommunikation überhaupt nicht. Erst 2015 implementierte der Entwickler von Conversations im Rahmen eines GSoC-Projektes das Signal-Protokoll (vormals Axolotl) in XMPP. Eine notwendige Erweiterung, die bis heute nicht offiziell angenommen wurde. Die Verschlüsselung von Video- und Sprachkommunikation trieb Jitsi voran und setzte hierfür auf OTR und ZRTP. Bisher nutzt diese Methode kein anderer Client.

Hier kommen wir zum Kern des Problems dezentralisierter Dienste. Die Kommunikationsgewohnheiten ändern sich rasant und neue Anforderungen entstehen. Dezentralisierte Dienste nehmen erstens die Herausforderung viel zu spät auf (OMEMO kam 2 Jahre nach Snowden!), Conversations als mobil funktionsfähige Lösung 5 Jahre nach WhatsApp. Zweitens fragmentieren solche Erweiterungen das Ökosystem, weil die Standardisierung ewig dauert und die Clients diese nicht zeitnah implementieren. OMEMO ist immer noch nicht in der Mehrheit der Clients integriert. Für mobile und sichere Kommunikation braucht der Anwender also nicht nur den richtigen Client und einen passenden Server, sondern der Kommunikationspartner auch.

XMPP funktioniert zudem nicht nur dezentral, es wird auch dezentral entwickelt. Wenn es eine zentrale Entwicklung des Protokolls und Referenzclients gibt, kann man Änderungen verhältnismäßig schnell ausrollen. Das Ökosystem passt sich dann meist schnell an. Bei XMPP fügen kleine Entwicklergruppen oder Einzelpersonen Erweiterungen an und versuchen diese offiziell zu machen. Server und Clients ziehen nach oder eben auch nicht. Bis sich Änderungen durchsetzen vergeht so viel Zeit.

Selbst wenn man dann irgendwann funktional gleichgezogen hat man agileren zentralisierten Projekten, ist der Zug schon lange abgefahren. Die Entwicklung der letzten Jahre hat eines schließlich deutlich gezeigt: Es gewinnt nicht das qualitativ hochwertigste Projekt, sondern jenes, dass sich früh etablieren und große Marktanteile sichern konnte. Ansonsten wäre Android nicht so erfolgreich und WhatsApp auch nicht.

Das spricht nun nicht unbedingt gegen dezentrale Ansätze allgemein - wohl aber gegen dezentrale Ansätze in der Massenkommunikation. Der Anspruch an einen Messenger ist es - vergleichbar zu WhatsApp nahezu jeden zu erreichen. Wenn er dies nicht leisten kann wenden sich die Menschen ab, weil niemand dutzende verschiedene Messenger bediene möchte. Soll der Dienst jedoch nur in einer definierten Gruppe zum Einsatz kommen können diese natürlich per Absprache Änderungen festlegen oder notfalls auf ein anderes Angebot migrieren.

Bilder:
Einleitungsbild und Beitragsbild von von geralt via pixabay

Drittanbieter Lösungen für Smartphone-Tastaturen erfreuen sich ungebrochener Beliebtheit. Es gibt zahllose kleine und große Anbieter für die beiden großen Betriebssysteme iOS und Android. Vor allem unter der freien Lösung Android erfreuen sich diese Tastaturen großer Beliebtheit.

Tastaturen sind per Definition die beste Art Daten abzugreifen. Abgesehen von der Sprachinteraktion laufen schließlich alle Eingaben über diese Methode. Umso weniger Verständnis kann man daher für Leute aufbringen, die für vermeintliche Vorteile wie irgendwelche Emojis oder Wischgesten, Tastaturen irgendwelcher Drittanbieter aus den App Stores installieren. Im Grunde genommen sind das nichts anderes als legale Keylogger.

Bereits vor einigen Jahren wurde öffentlich, dass der Tastaturanbieter AI Type in großem Umfang Daten gespeichert hat. Unter anderem scheinbar alle Tastatureingaben, Passwörter usw. usf. Der Anbieter gehörte zwar nicht zu den ganz großen der Branche aber der Skandal war mal wieder perfekt. Die ehemals sehr bekannte App Swype kam ebenfalls vor einigen Jahren in die Kritik, weil sie extrem oft Standortdaten abfragte. Die Abfrage sollte zwar lediglich die Lokalisierung verbessern und die Nutzer nicht tracken, zeigt aber was möglich ist. Swypes Weiterentwicklung stellte die Firma 2018 ein, das Problem bleibt aber bestehen.

Auch andere Tastaturen wie beispielsweise SwiftKey lassen sich umfangreiche Berechtigungen erteilen, auch wenn man hier darlegt, dass diese Berechtigungen für den Betrieb notwendig sind. Die App trackt die Anwender auf Schritt und Schritt - auch ohne Anmeldung bei SwiftKey. Die eingebaute Synchronisationsfunktion von SwiftKey muss zudem naturgemäß auch die erlernten Personalisierungsdaten auf Server übertragen, ansonsten kann keine Synchronisation erfolgen. 

SwiftKey gehört übrigens zu Microsoft, das nach dem Scheitern seine eigenen mobilen Bemühungen nun versucht seine Apps bei iOS und Android unterzubringen. Seit der Veröffentlichung von Windows 10 wissen wir außerdem, dass Microsoft anfängt in größerem Maßstab Telemetriedaten zu erheben und somit von einem lizenzbasierten Geschäftsmodell auf ein (abo- und) datenbasiertes Modell wechselt, wie es große Konkurrenten bereits betreiben. Man kann in dem Zusammenhang durchaus Überlegungen dazu anstellen, weshalb ein Softwareunternehmen mehrere hundert Millionen für eine Tastatur-App ausgibt.

Bei Tastaturen bleibt man bei den Herstellertastaturen. Keine Funktion, keine nette Vereinfachung - einfach nichts - rechtfertigt den Umstieg auf eine unkontrollierbare Drittanbieterlösung. Wer es dennoch macht, sollte sich nicht beklagen, wenn in Zukunft mal wieder ein Leck unbequeme Tatsachen zu Tage fördert. Natürlich können auch Herstellertastaturen unsicher sein. Die Smartphonehersteller wollen aber immer noch Smartphones verkaufen und verdienen damit ihr Geld. Schlechte Presse bedeutet schlechte Absatzzahlen, das Risiko ist für die Anbieter daher viel größer, als für ein Softwareunternehmen, das lediglich eine App veröffentlicht.

Bilder:

Einleitungs- und Beitragsbild von freestocks.org via Unsplash

E-Mail Verschlüsselung via OpenPGP ist transparent, Open Source, sicher, ungebrochen und vollkommen leicht zu verwenden - finden viele ihrer Anhänger. Natürlich verwenden es alle nur so wie es konzipiert ist und das System verhindert konsequente Fehlbedienung durch den Anwender.

Die meisten E-Mail Anwender - so sie nicht via Webmail ihre E-Mails abrufen - nutzen vermutlich Thunderbird. Doof nur, dass PGP bzw. GPG hier gar nicht integriert ist. Zum Glück haben zahlreiche Tutorials hier Enigmail bekannt gemacht. Das Wissen darüber kann man also halbwegs voraussetzen. Das installiert man also erst einmal aus dem Addonbereich. Im Anschluss erhält der Anwender vollkommen ungefragt p=p, wodurch sich zwar das gesamte Verfahren vereinfachen soll, was aber für den Anwender nicht sonderlich transparent funktioniert.

Mit p=p erhält der Nutzer zwar ein PGP-Zertifikat im Hintergrund aber der Handschlag mit den meisten anderen E-Mail Kommunikationspartner schlägt natürlich fehl. Enigmail kennt aktuell drei Schlüsselserver, darunter auch noch einen SKS-Server (siehe: Kommentar: OpenPGP Keyserver - Letzte Zuckungen). Letztere enthält natürlich uralte und sogar gefälschte Zertifikate für die Zieladresse. Der neue OpenPGP-Keyserver enthält aber noch fast keine Schlüssel.

Eigentlich endet hier schon das Experiment, denn mangels Zertifikat scheitert die verschlüsselte Kommunikation. Einen automatischen Abgleich von standardmäßig vorhandenen Zertifikaten wie bei jedem modernen Messenger gibt es schließlich nicht und wird sich auch mit p=p nicht flächendeckend etablieren. Einfach, weil E-Mail schließlich auch ohne Zertifikat funktioniert.

Aber vielleicht gibt es ja eine Signatur in einer älteren E-Mail oder eines der Zertifikate auf dem SKS-Keyserver ist doch echt. Mit einem kundigen Blick prüft man den langen Fingerabdruck, greift zum Telefon und ruft seinen Kommunikationspartner zur Schlüsselverifizierung an. Eigentlich braucht man nun gar keine Mail mehr schreiben, aber vielleicht soll es ja um einen Anhang gehen. Also zieht man das Prozedere weiter durch. Man muss es ja nur einmal machen. Es sei denn der Schlüssel des Gegenübers läuft ab, wird zurückgezogen oder er wechselt die E-Mail Adresse. Okay, einmal ist definitiv übertrieben. Aber man muss es nicht immer machen. Wenigstens etwas.

Also ran ans Werk. p=p meldet Privatsphärenstatus: Unsicher. Ein Klick darauf sagt "Bitte aktivieren Sie den Schutz, um die Handshake-Funktion nutzen zu können." Aha natürlich, gleich mal die Suchmaschine der Wahl befragen. Okay, Lösung gefunden. E-Mail abgebrochen, Einstellungen neu gesetzt, wieder von vorn. Nun sagt mir der Hinweis, dass die Nachricht sicher ist aber ich soll nochmal telefonisch überprüfen. Also erneut zum Telefonhörer gegriffen. Eventuell sollte man bei der Gelegenheit mal VoIP am Rechner einrichten. Anyway: E-Mail ist endlich raus.

Telefon klingelt. Kommunikationspartner ist dran. Die Nachrichten haben alle "p=p" als Betreff. Das Zielsystem unterstützt kein p=p, bei dezentralen Systemen hat schließlich jeder die Freiheit eine andere Lösung zu nutzen. Geschützte Nachrichtenbetreffe kann das Programm nicht. Daher deaktiviert man die Funktion für die Zukunft. Die folgende Mail geht also mit vollkommen transparenten Metadaten und unverschlüsseltem Betreff, der die E-Mail zusammen fasst, raus.

PGP ist logisch, selbsterklärend und ganz trivial. Behaupten machen. Vor allem solche, die noch nie eine moderne Kommunikationslösung mit Verschlüsselung und weitergehendem Schutz der Metadaten verwendet haben.

Bilder:

Einleitungs- und Beitragsbild von Free To Use Sounds via Unsplash

E-Mail Verschlüsselung via OpenPGP ist transparent, Open Source, sicher, ungebrochen und vollkommen leicht zu verwenden - finden viele ihrer Anhänger. Natürlich verwenden es alle nur so wie es konzipiert ist und das System verhindert konsequente Fehlbedienung durch den Anwender.

Die meisten E-Mail Anwender - so sie nicht via Webmail ihre E-Mails abrufen - nutzen vermutlich Thunderbird. Doof nur, dass PGP bzw. GPG hier gar nicht integriert ist. Zum Glück haben zahlreiche Tutorials hier Enigmail bekannt gemacht. Das Wissen darüber kann man also halbwegs voraussetzen. Das installiert man also erst einmal aus dem Addonbereich. Im Anschluss erhält der Anwender vollkommen ungefragt p=p, wodurch sich zwar das gesamte Verfahren vereinfachen soll, was aber für den Anwender nicht sonderlich transparent funktioniert.

Mit p=p erhält der Nutzer zwar ein PGP-Zertifikat im Hintergrund aber der Handschlag mit den meisten anderen E-Mail Kommunikationspartner schlägt natürlich fehl. Enigmail kennt aktuell drei Schlüsselserver, darunter auch noch einen SKS-Server (siehe: Kommentar: OpenPGP Keyserver - Letzte Zuckungen). Letztere enthält natürlich uralte und sogar gefälschte Zertifikate für die Zieladresse. Der neue OpenPGP-Keyserver enthält aber noch fast keine Schlüssel.

Eigentlich endet hier schon das Experiment, denn mangels Zertifikat scheitert die verschlüsselte Kommunikation. Einen automatischen Abgleich von standardmäßig vorhandenen Zertifikaten wie bei jedem modernen Messenger gibt es schließlich nicht und wird sich auch mit p=p nicht flächendeckend etablieren. Einfach, weil E-Mail schließlich auch ohne Zertifikat funktioniert.

Aber vielleicht gibt es ja eine Signatur in einer älteren E-Mail oder eines der Zertifikate auf dem SKS-Keyserver ist doch echt. Mit einem kundigen Blick prüft man den langen Fingerabdruck, greift zum Telefon und ruft seinen Kommunikationspartner zur Schlüsselverifizierung an. Eigentlich braucht man nun gar keine Mail mehr schreiben, aber vielleicht soll es ja um einen Anhang gehen. Also zieht man das Prozedere weiter durch. Man muss es ja nur einmal machen. Es sei denn der Schlüssel des Gegenübers läuft ab, wird zurückgezogen oder er wechselt die E-Mail Adresse. Okay, einmal ist definitiv übertrieben. Aber man muss es nicht immer machen. Wenigstens etwas.

Also ran ans Werk. p=p meldet Privatsphärenstatus: Unsicher. Ein Klick darauf sagt "Bitte aktivieren Sie den Schutz, um die Handshake-Funktion nutzen zu können." Aha natürlich, gleich mal die Suchmaschine der Wahl befragen. Okay, Lösung gefunden. E-Mail abgebrochen, Einstellungen neu gesetzt, wieder von vorn. Nun sagt mir der Hinweis, dass die Nachricht sicher ist aber ich soll nochmal telefonisch überprüfen. Also erneut zum Telefonhörer gegriffen. Eventuell sollte man bei der Gelegenheit mal VoIP am Rechner einrichten. Anyway: E-Mail ist endlich raus.

Telefon klingelt. Kommunikationspartner ist dran. Die Nachrichten haben alle "p=p" als Betreff. Das Zielsystem unterstützt kein p=p, bei dezentralen Systemen hat schließlich jeder die Freiheit eine andere Lösung zu nutzen. Geschützte Nachrichtenbetreffe kann das Programm nicht. Daher deaktiviert man die Funktion für die Zukunft. Die folgende Mail geht also mit vollkommen transparenten Metadaten und unverschlüsseltem Betreff, der die E-Mail zusammen fasst, raus.

PGP ist logisch, selbsterklärend und ganz trivial. Behaupten machen. Vor allem solche, die noch nie eine moderne Kommunikationslösung mit Verschlüsselung und weitergehendem Schutz der Metadaten verwendet haben.

Bilder:

Einleitungs- und Beitragsbild von Free To Use Sounds via Unsplash

LUKS1 oder LUKS2, normales dm-crypt, VeraCrypt oder Truecrypt - die Möglichkeiten zur Verschlüsselung unter Linux sind fast keine Grenzen gesetzt. Mit zuluCrypt steht eine Software zur Verfügung, die versucht alle diese Lösungen in einer Oberfläche zu vereinen.

zuluCrypt steht bei vielen Linux-Distributoren direkt in den Paketquellen zur Verfügung. Anwender haben die Wahl zwischen einer Kommandozeilen-Lösung und einer Qt-basierten Oberfläche.

Die Oberfläche präsentiert sich sehr minimalistisch. Übersetzungen stehen für Deutsch und Französisch zur Verfügung. Via Erstellen lassen sich neue Container als Datei oder auf einem Laufwerk anlegen. Man spezifiziert Größe und Dateiname und kann in einem nächsten Schritt den Typ wählen.

Zur Authentifizierung stehen die Optionen Schlüssel, Schlüsseldatei oder Schlüssel und Schlüsseldatei zur Verfügung. Zusätzlich lässt sich das Dateisystem des Containers definieren. Anschließend kann man via Open den zuvor erstellten Container auswählen und öffnen.

zuluCrypt hängt den Container in /run/media/privat/<benutzer> ein. Die Oberfläche erinnert leicht an TrueCrypt bzw. VeraCrypt. Wer hier mehr Optionen haben möchte kann zusätzlich auch noch zuluMount installieren. Letzteres ermöglicht dann auch die Verwaltung von EncFS, gocryptfs, securefs, eCryptFS and cryfs. Diese kommen primär zur Cloud-Verschlüsselung zum Einsatz (siehe auch: Cloud).

zuluCrypt ist vor allem für die leichte Erstellung von LUKS-Containern interessant, da dies ansonsten nicht ganz trivial ist (siehe auch: Verschlüsselten Container mit LUKS anlegen). Für VeraCrypt bietet die originale Software naturgemäß mehr Optionen (siehe: VeraCrypt - Systemübergreifende Verschlüsselung). Die Stärke von zuluCrypt besteht ansonsten vor allem darin fast alle bekannten und weniger bekannten Lösungen zu untersützen, weshalb man die meisten Container mit dieser einen Software einbinden kann. Mittels Disclocker-Backend kann man wohl auch BitLocker-Container unter Linux einbinden. Dieses steht aber für die meisten Distributionen nicht zur Verfügung.

Bilder:

Einleitungs- und Beitragsbild von Tumisu via pixabay

LUKS1 oder LUKS2, normales dm-crypt, VeraCrypt oder Truecrypt - die Möglichkeiten zur Verschlüsselung unter Linux sind fast keine Grenzen gesetzt. Mit zuluCrypt steht eine Software zur Verfügung, die versucht alle diese Lösungen in einer Oberfläche zu vereinen.

zuluCrypt steht bei vielen Linux-Distributoren direkt in den Paketquellen zur Verfügung. Anwender haben die Wahl zwischen einer Kommandozeilen-Lösung und einer Qt-basierten Oberfläche.

Die Oberfläche präsentiert sich sehr minimalistisch. Übersetzungen stehen für Deutsch und Französisch zur Verfügung. Via Erstellen lassen sich neue Container als Datei oder auf einem Laufwerk anlegen. Man spezifiziert Größe und Dateiname und kann in einem nächsten Schritt den Typ wählen.

Zur Authentifizierung stehen die Optionen Schlüssel, Schlüsseldatei oder Schlüssel und Schlüsseldatei zur Verfügung. Zusätzlich lässt sich das Dateisystem des Containers definieren. Anschließend kann man via Open den zuvor erstellten Container auswählen und öffnen.

zuluCrypt hängt den Container in /run/media/privat/<benutzer> ein. Die Oberfläche erinnert leicht an TrueCrypt bzw. VeraCrypt. Wer hier mehr Optionen haben möchte kann zusätzlich auch noch zuluMount installieren. Letzteres ermöglicht dann auch die Verwaltung von EncFS, gocryptfs, securefs, eCryptFS and cryfs. Diese kommen primär zur Cloud-Verschlüsselung zum Einsatz (siehe auch: Cloud).

zuluCrypt ist vor allem für die leichte Erstellung von LUKS-Containern interessant, da dies ansonsten nicht ganz trivial ist (siehe auch: Verschlüsselten Container mit LUKS anlegen). Für VeraCrypt bietet die originale Software naturgemäß mehr Optionen (siehe: VeraCrypt - Systemübergreifende Verschlüsselung). Die Stärke von zuluCrypt besteht ansonsten vor allem darin fast alle bekannten und weniger bekannten Lösungen zu untersützen, weshalb man die meisten Container mit dieser einen Software einbinden kann. Mittels Disclocker-Backend kann man wohl auch BitLocker-Container unter Linux einbinden. Dieses steht aber für die meisten Distributionen nicht zur Verfügung.

Bilder:

Einleitungs- und Beitragsbild von Tumisu via pixabay

Immer mehr Passwortmanager integrieren TOTP-Schlüssel. Damit kommen die Entwickler zahlreichen Anfragen von Anwendern nach. Bequemlichkeit ist jedoch der größte Feind der Sicherheit und der Begriff "Zwei-Faktor-Authentifizierung" für solche Einmal-Passwörter zeigt bereits warum dies eine schlechte Idee ist.

Das Problem betrifft sowohl proprietäre Software wie Enpass (siehe auch: Enpass - Ein Passwortmanager für alle Systeme) oder SafeInCloud (siehe auch: SafeInCloud - Vielfältiger Passwortmanager) aber auch freie Software wie KeePassXC. Letztere haben einen sehr bezeichnenden FAQ-Eintrag für das Problem angelegt:

Q: KeePassXC allows me to store my TOTP secrets. Doesn't this alleviate any advantage of two-factor authentication?
A: Yes. But only if you store them in the same database as your password. We believe that storing both together can still be more secure than not using 2FA at all, but to maximize the security gain from using 2FA, you should always store TOTP secrets in a separate database, secured with a different password, possibly even on a different computer.

Quelle: KeePassXC - Documentation and FAQ

Die KeePass-Entwickler benennen hier schon das Problem und ziehen sich zugleich aus der Affäre. Denn natürlich werden aus Bequemlichkeit die meisten Anwender die TOTP-Schlüssel in der gleichen Datenbank speichern - vermutlich sogar genau den Karteikarten der Dienste zugeordnet.

Die Idee hinter dieses zeitbasierten Einmalkennwörtern ist es eben einen zweiten Faktor hinzuziehen. Also ein zweites Gerät, meistens das Smartphone, das zusätzlich zur Kenntnis des Kennworts im Besitz der anmeldenden Person sein muss. Die Speicherung des TOTP-Schlüssels in der Passwort-Datenbank führt diese Idee ad absurdum.

TOTP-Schlüssel haben dann nur noch eine geschwächte Schutzwirkung. Sie können zusätzlich Sicherheit bei einfach zu merkenden Passwörtern bieten (aber hat man die, wenn man einen Passwortmanager nutzt?) oder dienen als zusätzlicher Schutz bei Angriffen auf den Dienstanbieter. Wobei letzteres auch nur dann was bringt, wenn das TOTP-Geheimnis nicht offen beim Anbieter gespeichert war. Letzteres sollte zwar nicht passieren, aber eigentlich sollten Anbieter auch keine Passwörter im Klartext speichern - tun leider trotzdem viel zu viele.

Wann macht also die Speicherung von TOTP-Schlüsseln in einem Kennwortprogramm Sinn? Eigentlich nur wenn der Dienst verpflichtend TOTP fordert aber man den Zugang z. B. in einem Team nutzt und den zweiten Faktor nicht zu einem Wanderpokal machen möchte. Ein sehr spezieller Fall, der für die meisten Anwender nicht zutreffen wird.

Macht es euch also nicht zu bequem und erzeugt Einmal-Kennwörter zur Zwei-Faktor-Authentifizierung zusätzlich auf einem zweiten Gerät. Dieses zweite Gerät muss auch kein Smartphone sein, spezialisierte Werkzeuge gibt es auch für alle Desktopbetriebssysteme (siehe auch: TOTP Codes auf dem Desktop erzeugen). Natürlich sollte es sich dennoch um ein separates Gerät handeln. Beispielsweise wäre ein altes Netbook denkbar.

Bilder:

Einleitungs- und Beitragsbild von MasterTux via pixabay

Immer mehr Passwortmanager integrieren TOTP-Schlüssel. Damit kommen die Entwickler zahlreichen Anfragen von Anwendern nach. Bequemlichkeit ist jedoch der größte Feind der Sicherheit und der Begriff "Zwei-Faktor-Authentifizierung" für solche Einmal-Passwörter zeigt bereits warum dies eine schlechte Idee ist.

Das Problem betrifft sowohl proprietäre Software wie Enpass (siehe auch: Enpass - Ein Passwortmanager für alle Systeme) oder SafeInCloud (siehe auch: SafeInCloud - Vielfältiger Passwortmanager) aber auch freie Software wie KeePassXC. Letztere haben einen sehr bezeichnenden FAQ-Eintrag für das Problem angelegt:

Q: KeePassXC allows me to store my TOTP secrets. Doesn't this alleviate any advantage of two-factor authentication?
A: Yes. But only if you store them in the same database as your password. We believe that storing both together can still be more secure than not using 2FA at all, but to maximize the security gain from using 2FA, you should always store TOTP secrets in a separate database, secured with a different password, possibly even on a different computer.

Quelle: KeePassXC - Documentation and FAQ

Die KeePass-Entwickler benennen hier schon das Problem und ziehen sich zugleich aus der Affäre. Denn natürlich werden aus Bequemlichkeit die meisten Anwender die TOTP-Schlüssel in der gleichen Datenbank speichern - vermutlich sogar genau den Karteikarten der Dienste zugeordnet.

Die Idee hinter dieses zeitbasierten Einmalkennwörtern ist es eben einen zweiten Faktor hinzuziehen. Also ein zweites Gerät, meistens das Smartphone, das zusätzlich zur Kenntnis des Kennworts im Besitz der anmeldenden Person sein muss. Die Speicherung des TOTP-Schlüssels in der Passwort-Datenbank führt diese Idee ad absurdum.

TOTP-Schlüssel haben dann nur noch eine geschwächte Schutzwirkung. Sie können zusätzlich Sicherheit bei einfach zu merkenden Passwörtern bieten (aber hat man die, wenn man einen Passwortmanager nutzt?) oder dienen als zusätzlicher Schutz bei Angriffen auf den Dienstanbieter. Wobei letzteres auch nur dann was bringt, wenn das TOTP-Geheimnis nicht offen beim Anbieter gespeichert war. Letzteres sollte zwar nicht passieren, aber eigentlich sollten Anbieter auch keine Passwörter im Klartext speichern - tun leider trotzdem viel zu viele.

Wann macht also die Speicherung von TOTP-Schlüsseln in einem Kennwortprogramm Sinn? Eigentlich nur wenn der Dienst verpflichtend TOTP fordert aber man den Zugang z. B. in einem Team nutzt und den zweiten Faktor nicht zu einem Wanderpokal machen möchte. Ein sehr spezieller Fall, der für die meisten Anwender nicht zutreffen wird.

Macht es euch also nicht zu bequem und erzeugt Einmal-Kennwörter zur Zwei-Faktor-Authentifizierung zusätzlich auf einem zweiten Gerät. Dieses zweite Gerät muss auch kein Smartphone sein, spezialisierte Werkzeuge gibt es auch für alle Desktopbetriebssysteme (siehe auch: TOTP Codes auf dem Desktop erzeugen). Natürlich sollte es sich dennoch um ein separates Gerät handeln. Beispielsweise wäre ein altes Netbook denkbar.

Bilder:

Einleitungs- und Beitragsbild von MasterTux via pixabay

Heise berichtete heute über eine Analyse zu OpenPGP, die im wesentlichen die Ersetzung von OpenPGP in allen Bereichen fordert. Sowas kommt natürlich am Freitag für die Klickzahlen, dennoch legt es den Finger in die Wunde. OpenPGP ist eine eierlegende Wollmilchsau mit Rückwärtskompatibilität bis in die 90er und in jedem Einsatzgebiet gäbe es bessere Alternativen.

Anlass der Debatte ist das aktuelle Problem der SKS Keyserver (siehe auch: Kommentar: OpenPGP Keyserver - Letzte Zuckungen), aber die Probleme mit OpenPGP sind nicht neu. EFAIL war ein ganz schöner GAU - sowohl hinsichtlich der technischen Probleme, als auch der Kommunikation - den die PGP-Anhänger schnell verdrängt haben (siehe: Kommentar: EFAIL - Nebelkerzen und was ist eigentliche eine Lücke?). Genau genommen ist der einzige Bereich, in dem PGP nicht zu ersetzen ist die E-Mail Verschlüsselung. Der Grund liegt hier aber weniger in den Qualitäten von OpenPGP, sondern schlicht darin, dass sich hier zwei uralte Protokolle treffen und ihre Goldene Hochzeit feiern.

Interessant an dem Artikel ist ein Blick in die Heise-Kommentare. Hier sieht man die übliche Abwehrstrategie der Befürworter dieser uralten Technologien. Auf Kritik kontert man mit Whataboutism und vor allem dem hochhalten des Open-Source- bzw. Community-Gedankens.

Merke: Mache etwas nur quelloffen, dezentralisiere es und bilde eine treue Community. Dann ist es auf jeden Fall sicher.

Vielleicht gibt es auch nur keine ernsthaften Angriffe auf PGP, weil es schlicht niemand nutzt und es deshalb uninteressant ist. Das wäre dann nicht Security through obscurity, sondern Security through insignificance. Nichts worauf man wirklich vertrauen sollte.

Bilder:
Einleitungs- und Beitragsbild von KRiemer via pixaybay

Heise berichtete heute über eine Analyse zu OpenPGP, die im wesentlichen die Ersetzung von OpenPGP in allen Bereichen fordert. Sowas kommt natürlich am Freitag für die Klickzahlen, dennoch legt es den Finger in die Wunde. OpenPGP ist eine eierlegende Wollmilchsau mit Rückwärtskompatibilität bis in die 90er und in jedem Einsatzgebiet gäbe es bessere Alternativen.

Anlass der Debatte ist das aktuelle Problem der SKS Keyserver (siehe auch: Kommentar: OpenPGP Keyserver - Letzte Zuckungen), aber die Probleme mit OpenPGP sind nicht neu. EFAIL war ein ganz schöner GAU - sowohl hinsichtlich der technischen Probleme, als auch der Kommunikation - den die PGP-Anhänger schnell verdrängt haben (siehe: Kommentar: EFAIL - Nebelkerzen und was ist eigentliche eine Lücke?). Genau genommen ist der einzige Bereich, in dem PGP nicht zu ersetzen ist die E-Mail Verschlüsselung. Der Grund liegt hier aber weniger in den Qualitäten von OpenPGP, sondern schlicht darin, dass sich hier zwei uralte Protokolle treffen und ihre Goldene Hochzeit feiern.

Interessant an dem Artikel ist ein Blick in die Heise-Kommentare. Hier sieht man die übliche Abwehrstrategie der Befürworter dieser uralten Technologien. Auf Kritik kontert man mit Whataboutism und vor allem dem hochhalten des Open-Source- bzw. Community-Gedankens.

Merke: Mache etwas nur quelloffen, dezentralisiere es und bilde eine treue Community. Dann ist es auf jeden Fall sicher.

Vielleicht gibt es auch nur keine ernsthaften Angriffe auf PGP, weil es schlicht niemand nutzt und es deshalb uninteressant ist. Das wäre dann nicht Security through obscurity, sondern Security through insignificance. Nichts worauf man wirklich vertrauen sollte.

Bilder:
Einleitungs- und Beitragsbild von KRiemer via pixaybay

Mozilla hat mit Firefox 68.0.1 das erste Update für Firefox 68 veröffentlicht.

Mit dem Update auf Firefox 68.0.1 verbessert Mozilla die Kompatibilität seines Browsers mit der kommenden Version Catalina (10.15) des Betriebssysstems Apple macOS.

Mit Firefox 68.0 hatte Mozilla die mit Firefox ausgelieferten Suchmaschinen auf WebExtensions umgestellt. In diesem Zusammenhang gab es noch Probleme, die mit dem Update behoben worden sind. So gab es in manchen Sprachen Probleme mit der Zeichenkodierung. Außerdem konnte es für Nutzer in russischen Regionen vorkommen, dass sich die eingestellte Standard-Suchmaschine geändert hat.

Außerdem konnte es für Nutzer mancher Sprachen vorkommen, dass im Panel der Storage Access API ein falscher Text angezeigt wurde.

Schließlich wurde noch ein Problem behoben, welches sich unter anderem bei HBO GO zeigte, indem dort der Vollbild-Button in den Videos nicht zu sehen war.

Der Beitrag Mozilla veröffentlicht Firefox 68.0.1 erschien zuerst auf soeren-hentzschel.at.

Um ein PDF in Bilder (hier im PNG-Format) umzuwandeln, gibt es verschiedene Möglichkeiten. Ich selber habe bisher immer mit ImageMagick und dem Kommando convert gearbeitet.

Das Umwandeln geht dann über z.B.

convert -density 300 -quality 80 source.pdf destination.png

Besteht das PDF aus mehreren Seiten, werden die Zieldateien durch ensprechendes Suffix ergänzt.

Seit einigen Monaten geht dieses Kommando allerdings nicht mehr und folgende Fehlermeldung wird angezeigt:

convert: attempt to perform an operation not 
allowed by the security policy 
`PDF' @ error/constitute.c/IsCoderAuthorized/408.

Hintergrund ist, dass neuerdings mit den Security Policies ImageMagick besser kontrolliert werden kann bezüglich RAM-Nutzung, verwendeten Dateiformaten, etc.

Mit der Zeile

  <policy domain="coder" rights="read | write" pattern="PDF" />

in der Datei /etc/ImageMagick-7/policy.xml ist es möglich, diese Beschränkung manuell für das PDF-Format aufzuheben.

Alternativ kann auch von den Poppler-Utils das Programm pdftoppm verwendet werden:

pdftoppm -png source.png destination.png

Es geht ja momentan durch die News, google hat bald Stadia am Start. Das ist eine Plattform, die die Computerspiele als Streaming Dienst anbieten wird.

Vorteil für den User, die Hardware muss nur den Chrome Browser starten und betreiben können. Die normalen integrierten Grafikkerne in den CPUs werden reichen, wenn sie jetzt schon FullHD Videos darstellen können.

Das bedeutet also, jeder halbwegs aktuelle  Laptop ohne dedizierte Grafikkarte ist dafür geeignet.

Was mich dazu bewogen hat, schonmal das Starterpaket zu ordern. Es besteht im wesentlichen aus Controllpad und Chromecast Ultra.

"Warum das? Ist das nicht zu teuer?" Lieber Spiele kaufen und lokal Spiele installieren!

Naja, mein Gedanke ist: Der momentane Laptop ist der XC1506 von Tuxedo, rennt wie der Teufel, aber der kommt auch mal an sein Lebensende und dann?

Wieder einen Haufen Geld für einen Spiele tauglichen Laptop ausgeben, oder nicht doch lieber einen Laptop in Top Qualität ohne dedizierte Grafik und mit ordentlich Akkulaufzeit, der ganz nebenbei auch leichter und preiswerter ist?

Für mich mit meinen 2-3 Spielen, die ich gelegentlich in Wellen mal spiele doch die klügere Alternative.

Ok, Spielen geht dann natürlich nur Online und es fragt sich, ob es überhaupt meine Spielekategorien, also Singleplayer;Strategie; auf Stadia geben wird...

Hhm. was meint ihr?

In der jüngeren Vergangenheit berichteten verschiedene Online-Medien (siehe [0] und [1]) über eine neuartige sehr effiziente Zip-Bombe [2], welche der Entwickler David Fitfield entwickelt und zusammen mit einer detaillierten Beschreibung veröffentlicht [3] hat.

Es reizte mich, diese Zip-Bombe auszuprobieren. Im folgenden beschreibe ich, wie ich eine Disk-Image-Datei [4] und ein Loop-Device [5] verwendet habe, um dies gefahlos tun zu können, ohne mir mein komplettes Dateisystem vollzuschreiben.

Die Prozedur besteht aus den folgenden Schritten:

1. Disk-Image-Datei mit definierter Größe erzeugen
2. Dateisystem in erstellter Disk-Image-Datei erzeugen
3. Einhängepunkt erzeugen und Disk-Image-Datei einhängen

Die einzelnen Schritte werden im Detail im folgenden Code-Block dargestellt:

[root@example.com ~]# fallocate -l 1G /tmp/zipbomb.img
[root@example.com ~]# mkfs.ext4 -F /tmp/zipbomb.img
mke2fs 1.42.9 (28-Dec-2013)
Discarding device blocks: done                            
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
65536 inodes, 262144 blocks
13107 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=268435456
8 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

[root@example.com ~]# mount -o loop /tmp/zipbomb.img /mnt
[root@example.com ~]# mount | grep /mnt
/tmp/zipbomb.img on /mnt type ext4 (rw,relatime,seclabel,data=ordered)
[root@example.com ~]#

Nun hängt in /mnt ein Dateisytem von 1 GB Größe, welches von der Zip-Bombe vollgeschrieben werden kann. Viel Spaß beim Ausprobieren.

Und wie probiere ich nun die Zip-Bombe aus?

Na ganz einfach:

[root@example.com ~]# cd /mnt
[root@example.com ~]# wget https://www.bamsoftware.com/hacks/zipbomb/zbsm.zip
[root@example.com ~]# unzip zbsm.zip

Es dauert auch nicht lange, bis euer Dateisystem unter /mnt voll ist.

Quellen und weiterführende Links

[0] DerStandard: Verstopfte Festplatte: „ZIP-Bombe“ verwandelt 46 Megabyte in 4,5 Petabyte
[1] Golem.de: Malware: Zip-Bombe entpackt 46 MByte zu 4,5 Petabyte
[2] Wikipedia: Archivbombe
[3] David Filield: A better zip bomb
[4] Wikipedia (en): IMG (file format)
[5] Wikipedia: Loop device