staging.inyokaproject.org

Mozilla hat Firefox 85 für Windows, Apple macOS und Linux veröffentlicht. Dieser Artikel fasst die wichtigsten Neuerungen zusammen – wie immer auf diesem Blog weit ausführlicher als auf anderen Websites.

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

Verbesserte Privatsphäre dank Netzwerk-Partitionierung

Das Tracking von Internet-Nutzern erfolgt heute längst nicht mehr nur über Cookies. Auch eine Vielzahl anderer Technologien wird dazu missbraucht, um Nutzer seitenübergreifend zu verfolgen. Um dies zu erschweren und die Privatsphäre der Nutzer weiter zu verbessern, hat Mozilla eine sogenannte Netzwerk-Partitionierung eingeführt. Dadurch werden Ressourcen, welche bislang in einem gemeinsamen Pool gespeichert worden sind, in Zukunft auf Website-Basis isoliert.

Firefox ist nicht der erste Browser, der eine Netzwerk-Partitionierung implementiert hat. Apple hat dies bereits vor einigen Jahren in Safari getan, Google ist kürzlich mit Chrome nachgezogen. Allerdings bietet Mozilla von allen Browser-Herstellern das bislang umfangreichste System zur Partitionierung. Auch die Blockierung sogenannter „Super-Cookies“ wird durch die Netzwerk-Partitionierung begünstigt.

Weitere Privatsphäre-Verbesserungen

Eine weitere Verbesserung der Privatsphäre wird für Nutzer aktiviert, welche den strengen Schutz anstelle der Standard-Einstellung ausgewählt haben. In diesem Fall verwendet Firefox jetzt die „Level 2“-Liste, welche noch mehr Tracker blockiert.

Wird ein Begriff in die Adressleiste eingegeben und anschließend Strg + Enter gedrückt, verwendet Firefox nun automatisch https:// anstelle von http:// als Protokoll.

Viele Verbesserungen bei den Lesezeichen

Lesezeichen sind nicht nur eines der ältesten Features von Firefox, es ist auch ein Bereich, welcher in den letzten Jahren praktisch unverändert geblieben ist. Mit Firefox 85 hat Mozilla einen großen Fokus auf die Verbesserung der Lesezeichen-Funktionalität gelegt.

Die Änderungen schließen unter anderem ein, dass sich Firefox nun den zuletzt verwendeten Speicherort merkt und beim nächsten Lesezeichen standardmäßig vorschlägt, eine Integration der „Weiteren Lesezeichen“ in die Lesezeichen-Symbolleiste (kann vom Benutzer abgeschaltet werden), die Möglichkeit, die Lesezeichen-Symbolleiste nur in neuen Tabs anzuzeigen oder auch per Tastatur ein- und auszublenden.

Die Verbesserungen der Lesezeichen sind so umfangreich, dass sich ein eigener Artikel ausführlich nur mit den Lesezeichen-Verbesserungen von Firefox 85 beschäftigt.

Verbesserte Konfiguration der Adressleiste

Im November hatte Mozilla mit der Veröffentlichung von Firefox 83 mehrere Verbesserungen der Adressleiste vorgenommen. Dazu zählt auch die Integration zusätzlicher Schaltflächen, über welche ausschließlich die Lesezeichen, die Chronik oder offene Tabs durchsucht werden können. Die Funktionalität, die Ergebnisse der Adressleiste zu filtern, besitzt Firefox bereits seit vielen Jahren, wurde durch die neue Integration aber erst vielen Nutzern bekannt, die bisher nicht wussten, dass das möglich ist.

Wer diese Funktion nicht braucht oder die Idee grundsätzlich gut findet, aber nicht jeden dieser Filter benötigt, kann die angezeigten Schaltflächen ab Firefox 85 konfigurieren. Ab dann finden sich die entsprechenden Einträge bei den ebenfalls an dieser Stelle angezeigten Suchmaschinen in den Such-Einstellungen von Firefox. Wie bei den Suchmaschinen genügt auch hier ein einfacher Klick für die Entfernung des jeweiligen Häkchens. Bonus: Die Such-Einstellungen zeigen außerdem das Zeichen an, welches man statt Betätigung der jeweiligen Schaltfläche zum Filtern in die Adressleiste eingeben kann.

Ebenfalls neu seit Firefox 83: Wird der Name einer Suchmaschine zu tippen begonnen, erfolgt ein prominenter Vorschlag zur Nutzung der Suchmaschine und das Drücken der Tabulator-Taste wählt die Suchmaschine aus.

Auch diese Neuerung lässt sich ab Firefox 85 über die Firefox-Einstellungen abschalten. Dies geschieht in den Adressleisten-Einstellungen im Bereich Datenschutz & Sicherheit.

Mehr Kontrolle über Startseite und neuen Tab

Hat der Nutzer eine Erweiterung wie New Tab Override installiert, öffnet Firefox mit jedem neuen Tab die in New Tab Override konfigurierte Seite anstelle der Standard-Startseite von Firefox. Während Nutzer, die sich New Tab Override installieren, vermutlich ganz bewusst den neuen Tab verändern wollen, gibt es auch andere Erweiterungen, welche ganz nebenbei, neben ihrer eigentlichen Kernfunktion, ebenfalls den neuen Tab überschreiben. Gleiches gilt für die Startseite von Firefox.

Bislang hätte auf die komplette Erweiterung verzichtet werden müssen, wenn die entsprechende Seite nicht überschrieben werden sollte. Und hatte man mehrere Erweiterungen installiert, welche die jeweilige Seite überschreiben, hat die Reihenfolge der Installation der Erweiterung bestimmt, welche Erweiterung „gewinnt“.

Ab Firefox 85 kann der Nutzer bestimmen, welche Erweiterung den Vorzug für die Startseite respektive den neuen Tab erhalten soll – oder gar keine Erweiterung, falls das Überschreiben nur eine unerwünschte Funktion einer Erweiterung ist. Dann kann auch weiterhin die Standard-Startseite von Firefox oder oder eine komplett leere Seite genutzt werden, ohne die Erweiterung deaktivieren zu müssen.

Alle Passwörter mit einem Mal löschen

Wer gespeicherte Passwörter löschen wollte, konnte dies bisher Eintrag für Eintrag erledigen. Mühsam wurde es, wenn alle gespeicherten Zugangsdaten mit einem Mal gelöscht werden sollten, insbesondere wenn es derer viele gab.

Ab sofort ist die vollständige Bereinigung aller Zugangsdaten auch direkt aus Firefox heraus möglich.

Import von Passwörtern aus KeePass und Bitwarden

Die Möglichkeit, Daten wie Lesezeichen oder auch gespeicherte Zugangsdaten aus anderen Browsern importieren zu können, ist nicht neu. Einige Nutzer lassen ihre Passwörter jedoch nicht im Browser, sondern in einem externen Passwort-Manager speichern. Firefox 85 erlaubt den Import von Passwörtern via CSV-Datei. Unterstützt werden dabei neben den Exports aus Firefox selbst und Google Chrome auch die Passwort-Manager KeePass inklusive Forks KeePassX und KeePassXC sowie Bitwarden.

Dieses Feature ist in Firefox 85 standardmäßig noch deaktiviert und kann aktiviert werden, indem über about:config der Schalter signon.management.page.fileImport.enabled per Doppelklick auf true gestellt wird. Danach steht die Funktion via about:logins zur Verfügung.

WebRender für weitere Geräte

WebRender stammt wie die mit Firefox 57 eingeführte CSS-Engine Stylo ebenfalls aus der 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 den letzten Monaten wurde WebRender für zahlreiche weitere Systeme ausgerollt und Firefox 85 bildet keine Ausnahme. Ab sofort werden auch Mac-Computer mit Apple Silicon-Chip unterstützt. Nachdem WebRender in Firefox 84 erstmals auch Linux (Gnome/X11) erreichte, wird nun auch Gnome/Wayland unterstützt (allerdings kein XWayland). Außerdem steht WebRender jetzt auch auf Linux-Systemen mit großen Bildschirmen zur Verfügung (bisher auf kleine und mittlere Bildschirme limitiert).

Verbesserte Unterstützung von Apple Silicon

Seit etwas mehr als zwei Monaten gibt es die ersten Computer, welche mit dem Apple M1 auf der neuen Silicon-Plattform von Apple basieren. Die Trennung von Intel geht einher mit einem Wechsel der Prozessor-Architektur von x86-64 zu ARM64. Firefox 84 war die erste Firefox-Version mit nativer Unterstützung für Apple Silicon, so dass keine Emulation via Rosetta 2 notwendig ist. Dies machte sich direkt bemerkbar: Firefox 84 startete 2,5 Mal schneller und Webanwendungen sind laut SpeedoMeter 2.0-Benchmark doppelt so schnell wie noch mit Firefox 83.

Neben der zuvor erwähnten Unterstützung von WebRender gibt es mit Firefox 85 nun auch den OpenH264-Codec für Apple Silicon und der Hardware-Decoder für VP9 steht jetzt ebenfalls auf entsprechenden Geräten zur Verfügung.

Keine Unterstützung des Adobe Flash Players mehr

Der Adobe Flash Player war das letzte verbliebene NPAPI-Plugin, nachdem andere NPAPI-Plugins wie Oracle Java oder Microsoft Silverlight bereits seit Firefox 52 nicht mehr unterstützt werden. NPAPI-Plugins waren für viele Jahre ein wichtiger Teil der Webplattform. In den letzten Jahren hat deren Bedeutung aber immer stärker abgenommen. Praktisch alles, was früher ausschließlich mittels NPAPI-Plugin umsetzbar war, wird heute, dank entsprechender Weiterentwicklung von Webstandards, nativ durch die Browser unterstützt. Heute gelten NPAPI-Plugins vor allem aus einer Sicherheits-Perspektive als problematisch.

Wie bereits im Jahr 2017 kommuniziert, hat Adobe kürzlich die Unterstützung des Adobe Flash Players eingestellt. Firefox 85 ist die erste Version, welche den Flash Player technisch nicht mehr unterstützt.

Für Nutzer ändert sich durch das Update diesbezüglich aber nicht tatsächlich etwas, denn der Adobe Flash Player besitzt eine eingebaute „Zeitbombe“ und funktioniert bereits seit dem 12. Januar in keinem Browser mehr. Das Support-Ende kann also weder durch einen Wechsel des Browsers noch durch die Verwendung einer älteren Firefox-Version umgangen werden.

Verbesserungen der Entwicklerwerkzeuge und Webplattform

Der Mehrzeilen-Modus der Konsole hat eine neue Funktion zur einheitlichen Formatierung des eingegebenen Codes erhalten.

Firefox hat Unterstützung für die :focus-visible Pseudoklasse in CSS erhalten. Natürlich wurde auch die Funktion „Pseudoklassen umschalten“ der Entwicklerwerkzeuge entsprechend erweitert.

Die Unterstützung von rel=preload (zuvor schrittweise ausgerollt) zur Verbesserung der Website-Performance ist nun für alle Nutzer verfügbar.

Das HTML-Feature menuitem, welches nicht länger Teil des HTML-Standards ist, wird standardmäßig nicht mehr unterstützt.

Ausführliche Informationen zu Verbesserungen der Webplattform in Firefox 85 finden sich auf hacks.mozilla.org sowie in den MDN web docs.

Sonstige Neuerungen in Firefox 85

Das Design der Checkboxen in den Einstellungen wurde nun gemäß der Photon Design-Richtlinien angepasst.

Das Logo der standardmäßig mit ausgelieferten Suchmaschine Microsoft Bing wurde aktualisiert.

Auch für WebExtension-Entwickler gab es wieder ein paar Verbesserungen, welche sich hier nachlesen lassen.

Natürlich kam auch in Firefox 85 die Unterstützung weiterer Unternehmensrichtlinien sowie Fehlerbehebungen und Verbesserungen unter der Haube dazu.

Geschlossene Sicherheitslücken

Wie immer hat Mozilla auch in Firefox 85 wieder mehrere Sicherheitslücken geschlossen. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 85 daher für alle Nutzer dringend empfohlen.

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

Zum Abfragen von DNS-Servern kann unter Linux und macOS das Werkzeug dig genutzt werden. Unter Umständen muss dig unter Ubuntu erst installiert werden:

apt install dnsutils

Um mittels dig eine Domain aufzulösen, wird diese einfach als Parameter genutzt:

dig example.com

Anschließend wird die entsprechende Antwort geliefert:

; <
> DiG 9.16.1-Ubuntu <
> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<
Soll ein bestimmter DNS-Server abgefragt werden, so kann dies durch einen zusätzlichen Parameter mit einem vorangestellten At-Zeichen erledigt werden:
example.com @hydrogen.ns.hetzner.com.
Damit wird der entsprechende DNS-Server abgerufen:
; <
> DiG 9.16.1-Ubuntu <
> example.com @hydrogen.ns.hetzner.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<

Mozilla Hubs ist eine Art virtueller Treffpunkt, den Mozilla im Jahr 2018 gestartet hat. Nun steht eine deutlich verbesserte Version bereit.

Mit dem Start von Mozilla Hubs im April 2018 ging eine Online-Plattform an den Start, welche es Nutzern ermöglicht, sich in sogenannten Räumen virtuell zu treffen. Das Besondere an Hubs: es spielt sich komplett im Web ab: keine geschlossene Plattform, keine Installation einer Anwendung, keine Abhängigkeit von einem bestimmten Gerät. Einfach eine URL teilen und miteinander treffen. Hubs funktioniert in jedem Browser, am Smartphone – und auch mit der VR-Brille, wo Hubs als virtuelle Plattform sein volles Potential entfaltet.

Die nun gestartete neue Version von Mozilla Hubs bringt einige Verbesserungen wie ein neues Design für den Desktop und Mobilgeräte sowie eine verbesserte Navigation. Chat-Nachrichten, die bisher im Bild erschienen und nach wenigen Sekunden verschwunden waren, finden sich nun in einer neuen Chat-Seitenleiste.

Darüber hinaus ist es nun auch möglich, auf support.mozilla.org Support zu Mozilla Hubs erhalten.

Für Kunden der kostenpflichtigen Hubs Cloud werden die Änderungen auf AWS am oder kurz nach dem 25. März 2021 ausgerollt werden.

Der Beitrag Mozilla Hubs: Deutlich verbesserte Version gestartet erschien zuerst auf soeren-hentzschel.at.

Linux wird deutlich seltener angegriffen als Windows (und macOS). Schadsoftware in freier Wildbahn wird selten gesichtet, wobei die Verfügbarkeit von Spionagetools für Linux zu Denken geben sollte. Die deutlich stärker bedrohten Systeme Windows und macOS haben in den vergangenen Jahren viele Verbesserungen erhalten. Bei Linux gibt es auch problematische Baustellen.

Momentan befasse ich mich ein wenig intensiver mit dem sicheren Betrieb von Linux (siehe auch: 5 Gedanken für mehr Sicherheit unter Linux). Linux hat in diesem Bereich immer einen guten Ruf. Enthusiastische Nutzer haben das gerne auf die vermeintlich überlegene Sicherheitsarchitektur zurückgeführt. Hier hat die Konkurrenz aber kräftig aufgeholt und neue (wenn auch umstrittene) Lösungen eingeführt. Linux arbeitet dagegen immer noch mit den Mechanismen von ehedem. Durchaus erfolgreich mag jetzt mancher einwerfen.

Wenn man ein bisschen recherchiert, stößt man allerdings auf Berichte, die einem zu denken geben sollten. Der Artikel von Hanno Böck „Warum ein Sicherheitsfix 3 Jahre nicht ankam„, ist ein lesenswertes Beispiel für die Probleme bei der Distribution von Linux. Es gibt leider zahlreiche Bibliotheken, die kaum Releasemanagement betreiben und bei denen die Distributionen irgendwelche Git-Versionsstände paketieren. Es bleibt dann der Expertise der Maintainer überlassen, wie gut oder schlecht das ist. Die Älteren werden sich da ein ziemliches Debakel bei Debian erinnern.

Uralte, kaum gepflegte Bibliotheken sind ebenso Thema eines älteren Artikels auf Golem mit dem zugegebenermaßen reißerischen Titel „Windows 10 sicherer als Linux-Desktops„. Die Lücke ist zwar geschlossen, der Inhalt aber nach wie vor aktuell. Im Multimedia-Bereich war man bei Linux lange Jahre froh, wenn man überhaupt alles zum Laufen bekam. Handbücher, Tutorials und Wikis enthalten daher wie selbstverständlich die Tipps bei GStreamer auch bad und ugly zu installieren. Über die Titulatur macht sich da niemand mehr Gedanken. Uralte, schlecht gepflegte Bibliotheken, bei einigen Distributionen auch noch in separate Repositorien ausgelagert und aus dem Internet heruntergeladene Inhalte sind einfach tolle Kombinationen.

Linux-Anwender können vermutlich froh über die geringen Marktanteile und die starke Fragmentierung des Ökosystems sein. Das dürfte ein wirksamer Schutz gegen Schadsoftware sein als die vermeintlich überlegene Architektur.

Bilder:

Einleitungs- und Beitragsbild von vishnu vijayan via Pixabay

Der Artikel Linux-Sicherheit – Es ist nicht alles gut erschien zuerst auf [Mer]Curius

Linux wird deutlich seltener angegriffen als Windows (und macOS). Schadsoftware in freier Wildbahn wird selten gesichtet, wobei die Verfügbarkeit von Spionagetools für Linux zu Denken geben sollte. Die deutlich stärker bedrohten Systeme Windows und macOS haben in den vergangenen Jahren viele Verbesserungen erhalten. Bei Linux gibt es auch problematische Baustellen.

Momentan befasse ich mich ein wenig intensiver mit dem sicheren Betrieb von Linux (siehe auch: 5 Gedanken für mehr Sicherheit unter Linux). Linux hat in diesem Bereich immer einen guten Ruf. Enthusiastische Nutzer haben das gerne auf die vermeintlich überlegene Sicherheitsarchitektur zurückgeführt. Hier hat die Konkurrenz aber kräftig aufgeholt und neue (wenn auch umstrittene) Lösungen eingeführt. Linux arbeitet dagegen immer noch mit den Mechanismen von ehedem. Durchaus erfolgreich mag jetzt mancher einwerfen.

Wenn man ein bisschen recherchiert, stößt man allerdings auf Berichte, die einem zu denken geben sollten. Der Artikel von Hanno Böck "Warum ein Sicherheitsfix 3 Jahre nicht ankam", ist ein lesenswertes Beispiel für die Probleme bei der Distribution von Linux. Es gibt leider zahlreiche Bibliotheken, die kaum Releasemanagement betreiben und bei denen die Distributionen irgendwelche Git-Versionsstände paketieren. Es bleibt dann der Expertise der Maintainer überlassen, wie gut oder schlecht das ist. Die Älteren werden sich da ein ziemliches Debakel bei Debian erinnern.

Uralte, kaum gepflegte Bibliotheken sind ebenso Thema eines älteren Artikels auf Golem mit dem zugegebenermaßen reißerischen Titel "Windows 10 sicherer als Linux-Desktops". Die Lücke ist zwar geschlossen, der Inhalt aber nach wie vor aktuell. Im Multimedia-Bereich war man bei Linux lange Jahre froh, wenn man überhaupt alles zum Laufen bekam. Handbücher, Tutorials und Wikis enthalten daher wie selbstverständlich die Tipps bei GStreamer auch bad und ugly zu installieren. Über die Titulatur macht sich da niemand mehr Gedanken. Uralte, schlecht gepflegte Bibliotheken, bei einigen Distributionen auch noch in separate Repositorien ausgelagert und aus dem Internet heruntergeladene Inhalte sind einfach tolle Kombinationen.

Linux-Anwender können vermutlich froh über die geringen Marktanteile und die starke Fragmentierung des Ökosystems sein. Das dürfte ein wirksamer Schutz gegen Schadsoftware sein als die vermeintlich überlegene Architektur.

Bilder:

Einleitungs- und Beitragsbild von vishnu vijayan via Pixabay

Bei Verwendung des dunklen System-Themes nutzt Firefox standardmäßig ebenfalls ein dunkles Design. Text-Dokumente wurden jedoch immer noch auf weißem Hintergrund angezeigt. Dies ändert sich mit Firefox 86.

Heute bietet praktisch jedes System einen sogenanntes Dark-Mode, in welchem dunkle Farben verwendet werden, was (abhängig von der Bildschirmtechnologie) nicht nur die Akkulaufzeit verbessern kann, sondern gerade in dunkler Umgebung auch für die Augen angenehmer sein kann. Auch Firefox besitzt ein dunkles Theme, welches standardmäßig automatisch aktiviert wird, wenn der Dark-Mode des Betriebssystems aktiv ist.

Beim Betrachten von Text-Dokumenten in Firefox hatte man bislang jedoch nicht viel von diesem dunklen Theme, denn hier war der Hintergrund weiterhin Weiß und der Natur eines Text-Dokumentes gemäß gab es von dieser Weißfläche sehr viel.

Ab Firefox 86 werden auch für Text-Dokumente im Dark-Mode dunkle Farben benutzt.

Firefox 86 wird nach aktueller Planung am 23. Februar 2021 erscheinen.

Der Beitrag Firefox 86: Dark-Mode für Text-Dokumente erschien zuerst auf soeren-hentzschel.at.

Linux gilt gemeinhin schon als sehr sicher. Zweifelsohne ist der Druck durch Schadsoftware viel geringer und die Gefahr, sich einfach im Betrieb „was einzufangen“ ist natürlich geringer. Zwischen den Linux-Distributionen gibt es aber Unterschiede und man kann hier individuell durchaus Verbesserungen vornehmen. Linux ist nicht gleich Linux.

1. Sichere Linux-Distribution wählen

Das ist ein Aspekt, den ich heute viel kritischer sehe (Anlass u.a.: KDE neon, Calamares – Peinliche Sicherheitsprobleme). Auch wenn alle Linux-Distributionen einige basale Sicherheitsprinzipien teilen, gibt es doch erhebliche Unterschiede. Der Punkt ist umso relevanter, da Linux-Anwender über die Paketquellen meist nahezu die komplette Software über den Distributor beziehen. Bei so manchen kleinen Hobby-Projekten darf man sich schon die Frage stellen, ob diese erstens genug Expertise haben, um hier wirklich Sicherheit zu garantieren und zweitens auch dauerhaft genug Zeit, um die Software auf hohem Niveau zu pflegen.

Das soll jetzt kein Plädoyer für ausschließlich Firmen-geführte Distributionen sein. Debian liefert hier als klassisches Community-Projekt auch gute Arbeit ab. Das soll ebenfalls kein Argument für stabile Distributionen sein, denn wenn Projekte wie Arch Linux immer ganz nah an Upstream sind, bekommen sie von dort auch immer sofort die sicherheitsrelevanten Fehlerkorrekturen.

Besonders problematisch sind jene Projekte, die Aktualisierungen – aus welchen Gründen auch immer – verzögern. Beispielsweise Linux Mint oder Manjaro. Auch Debian Testing kann hier problematisch sein. Das gilt aber auch für Distributionen, die nur einen Teil ihrer Pakete pflegen. Ich sehe hier persönlich Ubuntu immer kritischer. Die Situation in universe wird durch tendenziell rückläufige Community-Partizipation nicht besser. Natürlich wird das offen kommuniziert, aber ich möchte den Desktop sehen, der ausschließlich Pakete aus main installiert hat.

Ebenso relevant kann die Frage sein, wie viele Fremdquellen man zum Betrieb der gewünschten Software braucht. Wenn man eine Distribution nutzt, welche die erforderliche Software nicht oder nicht in der gewünschten Version ausliefert und man deshalb sein System mit zig Fremdquellen ausstattet, hat man vielleicht die falsche Distribution ausgesucht.

Ein weiterer Aspekt über den man mal nachdenken kann, sind sogenannte Reproducible Builds. Vereinfacht gesagt geht es um den Punkt: Wer garantiert dir, dass in den Binärpaketen deiner Distribution der öffentlich einsehbare Quellcode unverändert gebaut wurde.

Der Aspekt Sicherheit sollte mit bedacht werden, wenn man unter den unzähligen Distributionen seine passende Variante aussucht. Der Fokus liegt allzu oft nur auf irgendwelchen neuen Paketen oder extravaganten Paketmanagern.

2. Verschlüsselung

Wie einfach kann ich ein voll verschlüsseltes System mit meiner gewünschten Distribution umsetzen? Die Frage klingt banal, aber manche Distributionen bieten immer noch keine oder nur eine unzureichende LUKS-Verschlüsselung in ihren Installationsroutinen an. Als Standard bieten das sowieso viel zu wenige Distributoren.

Verschlüsselung wird oft noch als Feature für Paranoide abgetan, aber glaub mir, du willst deine Daten verschlüsseln. Wenn dein Notebook gestohlen wird (oder bei einem Einbruch dein Rechner) und deine Daten geraten potenziell in falsche Hände, ist das genau so ein beschissenes Gefühl, wie wenn jemand deinen Hausstand durchwühlt. So wie der Einbrecher es meist doch nur auf Wertsachen abgesehen hat, so geht es beim Notebook-Diebstahl meist um die Hardware. Die Sorge um die Dateien und die gefühlte Verletzung der Privatsphäre schwingt dennoch mit.

3. Firewall

Alte Linux-Ratgeber haben meistens einen Passus wie „Du brauchst keine Firewall“ und das Mantra tragen viele Linux-Anwender bis heute vor sich her. Distributionen wie openSUSE/SUSE Linux Enterprise oder Red Hat und Fedora liefern heute aber standardmäßig Firewalls aus. Sind die Entwickler dort einfach nur doof? Nein, natürlich nicht! Du brauchst wirklich keine Firewall, wenn du nur in deinem Keller hinter deinem Router sitzt. Aber nicht alle Linux-Nutzer gehören zu diesen lichtscheuen Wesen. Man munkelt, manche gehen raus und arbeiten mit ihren Geräten in fremden Netzen.

Hier kommt das eigene Gerät dann mit einer Vielzahl an anderen Geräten in Kontakt. Das ist natürlich kein Problem, wenn du ein perfekt gepflegtes, minimales System mit lediglich wenigen Diensten nutzt. Im Jahr 2021 unwahrscheinlich, da über Abhängigkeiten viele nicht unmittelbar benötigte Dependenzen auf dem Gerät landen. Diese Software sollte natürlich keine Sicherheitslücken aufweisen, aber wer kann das schon garantieren. Hier kann man mit einer Firewall wie ufw oder firewalld einfach für ein bisschen mehr Sicherheit sorgen.

4. AppArmor

Für Linux existieren eine ganze Reihe von Sicherheitsframeworks. Am bekanntesten dürften SELinux und AppArmor sein. SELinux ist sicher toll und Red Hat/Fedora liefern hier brauchbare Konfigurationen aus. Ich persönlich kenne aber niemanden, der das selbst auf anderen Distributionen erfolgreich und zuverlässig implementieren konnte. Wer also SELinux will, sollte direkt zu RHEL oder Fedora greifen. AppArmor ist hier viel leichter einzurichten. Distributionen wie Ubuntu (und Derivate), sowie Debian und openSUSE liefern es standardmäßig mit. Bei anderen Linux-Varianten wie Arch Linux lässt es sich mit geringem Aufwand nachträglich einrichten.

Sicherheitsframeworks wie AppArmor bieten über Profile Möglichkeiten der Zugriffskontrolle und man kann damit Programme wie z B. Firefox oder den Tor Browser in ihrem Systemzugriff stark einschränken. Nicht weil man diese Programme per se für schlecht hält (dann sollte man sie einfach nicht installieren), sondern weil sie Netzwerkzugriff haben und häufig schwerwiegende Sicherheitslücken aufweisen.

Das ist durchaus sinnvoll, da das Linux-System mit dem Sicherheitsprinzip der Zugriffsrechte etwas aus der Zeit gefallen ist. Mit AppArmor kann man Programme zusätzlich einhegen.

5. Firejail

Firejail ist eine umstrittene Lösung. Auf der einen Seite kann man damit Linux-Anwendungen quasi in ein Gefängnis stecken (ein Prinzip, das vielen heute durch Android oder iOS vertraut ist) aber auf der anderen Seite gehört Firejail in vielen Supportforen auch zu den bekannten Problemursachen.

Im Gegensatz zu AppArmor hat Firejail den Vorteil, das hier viele Profile bereits vorgefertigt durch die Community geteilt werden. Andererseits ist der Mehrwert bei einer gut gepflegten AppArmor Einrichtung überschaubar.

Deshalb sei Firejail zum Schluss dieses Artikels als Denkanstoß genannt.

Bilder:

Einleitungs- und Beitragsbild von Tumisu via Pixabay

Der Artikel 5 Gedanken für mehr Sicherheit unter Linux erschien zuerst auf [Mer]Curius

Linux gilt gemeinhin schon als sehr sicher. Zweifelsohne ist der Druck durch Schadsoftware viel geringer und die Gefahr, sich einfach im Betrieb "was einzufangen" ist natürlich geringer. Zwischen den Linux-Distributionen gibt es aber Unterschiede und man kann hier individuell durchaus Verbesserungen vornehmen. Linux ist nicht gleich Linux.

1. Sichere Linux-Distribution wählen

Das ist ein Aspekt, den ich heute viel kritischer sehe (Anlass u.a.: KDE neon, Calamares - Peinliche Sicherheitsprobleme). Auch wenn alle Linux-Distributionen einige basale Sicherheitsprinzipien teilen, gibt es doch erhebliche Unterschiede. Der Punkt ist umso relevanter, da Linux-Anwender über die Paketquellen meist nahezu die komplette Software über den Distributor beziehen. Bei so manchen kleinen Hobby-Projekten darf man sich schon die Frage stellen, ob diese erstens genug Expertise haben, um hier wirklich Sicherheit zu garantieren und zweitens auch dauerhaft genug Zeit, um die Software auf hohem Niveau zu pflegen.

Das soll jetzt kein Plädoyer für ausschließlich Firmen-geführte Distributionen sein. Debian liefert hier als klassisches Community-Projekt auch gute Arbeit ab. Das soll ebenfalls kein Argument für stabile Distributionen sein, denn wenn Projekte wie Arch Linux immer ganz nah an Upstream sind, bekommen sie von dort auch immer sofort die sicherheitsrelevanten Fehlerkorrekturen.

Besonders problematisch sind jene Projekte, die Aktualisierungen - aus welchen Gründen auch immer - verzögern. Beispielsweise Linux Mint oder Manjaro. Auch Debian Testing kann hier problematisch sein. Das gilt aber auch für Distributionen, die nur einen Teil ihrer Pakete pflegen. Ich sehe hier persönlich Ubuntu immer kritischer. Die Situation in universe wird durch tendenziell rückläufige Community-Partizipation nicht besser. Natürlich wird das offen kommuniziert, aber ich möchte den Desktop sehen, der ausschließlich Pakete aus main installiert hat.

Ebenso relevant kann die Frage sein, wie viele Fremdquellen man zum Betrieb der gewünschten Software braucht. Wenn man eine Distribution nutzt, welche die erforderliche Software nicht oder nicht in der gewünschten Version ausliefert und man deshalb sein System mit zig Fremdquellen ausstattet, hat man vielleicht die falsche Distribution ausgesucht.

Ein weiterer Aspekt über den man mal nachdenken kann, sind sogenannte Reproducible Builds. Vereinfacht gesagt geht es um den Punkt: Wer garantiert dir, dass in den Binärpaketen deiner Distribution der öffentlich einsehbare Quellcode unverändert gebaut wurde.

Der Aspekt Sicherheit sollte mit bedacht werden, wenn man unter den unzähligen Distributionen seine passende Variante aussucht. Der Fokus liegt allzu oft nur auf irgendwelchen neuen Paketen oder extravaganten Paketmanagern.

2. Verschlüsselung

Wie einfach kann ich ein voll verschlüsseltes System mit meiner gewünschten Distribution umsetzen? Die Frage klingt banal, aber manche Distributionen bieten immer noch keine oder nur eine unzureichende LUKS-Verschlüsselung in ihren Installationsroutinen an. Als Standard bieten das sowieso viel zu wenige Distributoren.

Verschlüsselung wird oft noch als Feature für Paranoide abgetan, aber glaub mir, du willst deine Daten verschlüsseln. Wenn dein Notebook gestohlen wird (oder bei einem Einbruch dein Rechner) und deine Daten geraten potenziell in falsche Hände, ist das genau so ein beschissenes Gefühl, wie wenn jemand deinen Hausstand durchwühlt. So wie der Einbrecher es meist doch nur auf Wertsachen abgesehen hat, so geht es beim Notebook-Diebstahl meist um die Hardware. Die Sorge um die Dateien und die gefühlte Verletzung der Privatsphäre schwingt dennoch mit.

3. Firewall

Alte Linux-Ratgeber haben meistens einen Passus wie "Du brauchst keine Firewall" und das Mantra tragen viele Linux-Anwender bis heute vor sich her. Distributionen wie openSUSE/SUSE Linux Enterprise oder Red Hat und Fedora liefern heute aber standardmäßig Firewalls aus. Sind die Entwickler dort einfach nur doof? Nein, natürlich nicht! Du brauchst wirklich keine Firewall, wenn du nur in deinem Keller hinter deinem Router sitzt. Aber nicht alle Linux-Nutzer gehören zu diesen lichtscheuen Wesen. Man munkelt, manche gehen raus und arbeiten mit ihren Geräten in fremden Netzen.

Hier kommt das eigene Gerät dann mit einer Vielzahl an anderen Geräten in Kontakt. Das ist natürlich kein Problem, wenn du ein perfekt gepflegtes, minimales System mit lediglich wenigen Diensten nutzt. Im Jahr 2021 unwahrscheinlich, da über Abhängigkeiten viele nicht unmittelbar benötigte Dependenzen auf dem Gerät landen. Diese Software sollte natürlich keine Sicherheitslücken aufweisen, aber wer kann das schon garantieren. Hier kann man mit einer Firewall wie ufw oder firewalld einfach für ein bisschen mehr Sicherheit sorgen.

4. AppArmor

Für Linux existieren eine ganze Reihe von Sicherheitsframeworks. Am bekanntesten dürften SELinux und AppArmor sein. SELinux ist sicher toll und Red Hat/Fedora liefern hier brauchbare Konfigurationen aus. Ich persönlich kenne aber niemanden, der das selbst auf anderen Distributionen erfolgreich und zuverlässig implementieren konnte. Wer also SELinux will, sollte direkt zu RHEL oder Fedora greifen. AppArmor ist hier viel leichter einzurichten. Distributionen wie Ubuntu (und Derivate), sowie Debian und openSUSE liefern es standardmäßig mit. Bei anderen Linux-Varianten wie Arch Linux lässt es sich mit geringem Aufwand nachträglich einrichten.

Sicherheitsframeworks wie AppArmor bieten über Profile Möglichkeiten der Zugriffskontrolle und man kann damit Programme wie z B. Firefox oder den Tor Browser in ihrem Systemzugriff stark einschränken. Nicht weil man diese Programme per se für schlecht hält (dann sollte man sie einfach nicht installieren), sondern weil sie Netzwerkzugriff haben und häufig schwerwiegende Sicherheitslücken aufweisen.

Das ist durchaus sinnvoll, da das Linux-System mit dem Sicherheitsprinzip der Zugriffsrechte etwas aus der Zeit gefallen ist. Mit AppArmor kann man Programme zusätzlich einhegen.

5. Firejail

Firejail ist eine umstrittene Lösung. Auf der einen Seite kann man damit Linux-Anwendungen quasi in ein Gefängnis stecken (ein Prinzip, das vielen heute durch Android oder iOS vertraut ist) aber auf der anderen Seite gehört Firejail in vielen Supportforen auch zu den bekannten Problemursachen.

Im Gegensatz zu AppArmor hat Firejail den Vorteil, das hier viele Profile bereits vorgefertigt durch die Community geteilt werden. Andererseits ist der Mehrwert bei einer gut gepflegten AppArmor Einrichtung überschaubar.

Deshalb sei Firejail zum Schluss dieses Artikels als Denkanstoß genannt.

Bilder:

Einleitungs- und Beitragsbild von Tumisu via Pixabay

(Ganz) kurz notiert: pip, der Paketmanager für Python, ist in der Version 21 erschienen. Größte Neuerung des Major-Releases ist das Ende der Unterstützung von Python 2 (#6148), dem alten Versionsstrang von Python, der seit Anfang 2020 schon EOL ist. Im gleichen Atemzug wurde der Support für Python 3.5 entfernt. (Siehe Changelog.)

Aus meiner Sicht ist es ein guter Schritt, ein Jahr nach dem offiziellen EOL nun auch mit den Aufräumarbeiten zu beginnen, da Python 2 und insbesondere der zehnjährige Migrationszustand viele Abhängigkeiten (wie bspw. der six library) hinterlassen hat, die nun zugunsten der Codequalität aufgelöst werden können.

Unter dem Namen Proton arbeitet Mozilla an einem neuen Design für Firefox. Wer neugierig ist, kann in der Nightly-Version von Firefox nun erste Änderungen aktivieren.

Mit Proton kommt ein neues Firefox-Design

Unter dem internen Projektnamen Proton arbeitet Mozilla an einem neuen Design seines Desktop-Browsers, welches mit Firefox 89 das Licht der Welt erblicken soll. Über Proton wurde auf diesem Blog weltweit als erstes berichtet.

Die Veröffentlichung von Firefox 89 ist derzeit für den 18. Mai 2021 in Mozillas geplant.

Proton in Firefox Nightly aktivieren

Eines direkt vorab: Es gibt keinen magischen Schalter, welcher das neue Design zu diesem Zeitpunkt in seiner finalen Form aktiviert. Immerhin haben die Implementierungs-Arbeiten gerade erst begonnen. Wer aber neugierig ist und die Entwicklung etwas direkter verfolgen möchte, kann dies tun. Voraussetzung hierfür ist die Verwendung einer Nightly-Version von Firefox.

Sobald die Nightly-Version verwendet wird, sind derzeit noch manuelle Eingriffe in about:config notwendig.

Zunächst einmal gibt es browser.proton.enabled. Hinter diesem Schalter sollen diverse Anpassungen der Oberfläche entwickelt werden. Nach heutigem Stand passiert nach Setzen dieses Schalters auf true aber noch nichts. Dies dürfte sich im Laufe der kommenden Wochen ändern.

Ein zweiter Schalter ist browser.proton.appmenu.enabled. Im Unterschied zum zuvor genannten Schalter muss dieser händisch in about:config (als Boolean) mit dem Wert true angelegt werden. Damit die Änderung wirksam wird, muss ein neues Firefox-Fenster geöffnet oder Firefox neu gestartet werden.

Hinter diesem Schalter entwickelt Mozilla Anpassungen des Hauptmenüs. Derzeit wird das Hauptmenü durch eine Kopie ersetzt, welches nur noch drei Menüeinträge beinhaltet. Für den neugierigen Nutzer ist der Schalter zu diesem Zeitpunkt also vermutlich noch nicht sehr spannend – es handelt sich dabei noch um eine Platzhalter-Implementierung. Wer aber die Entwicklung des Hauptmenüs etwas direkter verfolgen möchte, dürfte an diesem Schalter interessiert sein.

In der gleichen Weise wäre ein dritter Schalter anzulegen, browser.proton.tabs.enabled. Dahinter wird das neue Tab-Design entwickelt. Hier genügt kein neues Fenster, ein Neustart des Browsers ist notwendig.

Hier gibt es zum jetzigen Zeitpunkt auch schon am meisten zu sehen, nämlich eine andere Gestaltung von Tableiste und Tabs. Auffällig ist dabei der zweizeilige Inhalt von Tabs, welche Audio wiedergeben.

Feedback an Mozilla geben

Natürlich darf an dieser Stelle nicht der obligatorische Hinweis fehlen: Der aktuelle Stand repräsentiert noch lange nicht das fertige Design. In den nächsten Wochen und Monaten wird sich hinter den genannten (und möglicherweise noch weiteren neuen Schaltern) eine Menge tun. Und dass zwei der drei bereits vorhandenen Schalter nicht nur standardmäßig deaktiviert sind, sondern vom Nutzer sogar selbst erst angelegt werden müssen, unterstreicht das frühe Stadium der Entwicklung.

Wer dennoch Feedback an Mozilla geben möchte, hat dazu mehrere Möglichkeiten wie den Raum #Proton auf chat.mozilla.org oder ein Thema im offiziellen Nightly-Forum von Mozilla zu eröffnen. In beiden Fällen erfolgt die Kommunikation natürlich in englischer Sprache.

Der Beitrag Proton: Erste Spuren des neuen Designs zeigen sich in Firefox Nightly erschien zuerst auf soeren-hentzschel.at.

Der vor ein paar Jahren erfolgte Umbau von Firefox zu einer Multiprozess-Architektur stellte einen ganz wesentlichen Meilenstein in der technischen Entwicklung von Firefox dar. Nun ziehen die Entwickler des E-Mail-Clients Thunderbird nach.

Die Multiprozess-Architektur, an der Mozilla einige Jahre gearbeitet hatte, brachte Vorteile für die Performance und Stabilität von Firefox, vor allem aber für die Sicherheit. Der E-Mail-Client Thunderbird, welche auf der Mozilla-Plattform basiert, nutzt bislang nur einen Prozess.

Wer eine Daily-Version von Thunderbird (das Nightly-Pendant zu Firefox) nutzt, hat unter Umständen bereits bemerkt, dass Thunderbird nun mehr als einen Prozess nutzt. Dies hängt damit zusammen, dass Thunderbird den ersten Schritt in Richtung Multiprozess-Architektur gemacht hat.

Die Entwickler weisen darauf hin, dass man dadurch nicht direkt spürbare Verbesserungen erwarten sollte. Viel mehr stellt dies einen ersten wichtigen Meilenstein und die Grundlage für zukünftige Verbesserungen dar. Ein weiterer Vorteil der Multiprozess-Architektur neben den für Firefox bereits genannten ist, dass es weniger Probleme durch Code-Unterschiede zwischen Firefox und Thunderbird geben sollte.

Geplant ist die Auslieferung in einer finalen Version im nächsten Major-Release nach Thunderbird 78. Wenn man sich dabei am Release-Kalender von Firefox orientiert, wäre dies Thunderbird 91, der im Sommer dieses Jahres erscheinen soll.

Der Beitrag Thunderbird nutzt in Zukunft mehrere Prozesse erschien zuerst auf soeren-hentzschel.at.

Der Bild-in-Bild-Modus erlaubt es, Videos von der Website loszulösen und über andere Tabs und sogar Anwendungen zu legen. Ab Firefox 86 können sogar mehrere Videos gleichzeitig losgelöst und angesehen werden.

Ein Video ansehen und gleichzeitig etwas anderes am Computer machen – Firefox macht’s möglich. Bei Klick auf die entsprechende Schaltfläche wird das jeweilige Video vom Tab losgelöst und erscheint in einem eigenständigen kleinen Fenster. Dieses liegt über allen Anwendungen, d.h. Firefox muss sich nicht im Vordergrund befinden, um das Video zu sehen. Der Benutzer kann beispielsweise seine E-Mails in Thunderbird abrufen und gleichzeitig ein Video auf YouTube ansehen.

Bisher war diese Funktion auf ein Video limitiert. Multitasking-Experten dürfen sich freuen: Ab Firefox 86 wird es möglich sein, mehr als ein Video gleichzeitig vom Hauptfenster losgelöst zu haben und so mehrere Videos parallel sehen zu können, während gleichzeitig andere Aufgaben erledigt werden.

Firefox 86 wird nach aktueller Planung am 23. Februar 2021 erscheinen.

Der Beitrag Firefox 86: Bild-in-Bild für mehrere Videos gleichzeitig erschien zuerst auf soeren-hentzschel.at.

Mit der Leseansicht besitzt Firefox ein praktisches Feature zum störungsfreien Lesen sowie Vorlesen lassen von Artikeln. Ab Firefox 86 steht diese Funktion auch für lokale Dateien zur Verfügung.

Per Klick auf das Buch-Symbol in der Adressleiste erscheinen Artikel im Web 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. Der Nutzer hat hierbei auch diverse Anpassungsmöglichkeiten und kann sich die Artikel sogar vorlesen lassen.

Dabei gab es bislang eine Einschränkung: Es musste sich um Artikel im Web handeln, welche über https:// respektive http:// aufgerufen werden. Für lokal gespeicherte Dateien hat die Leseansicht bisher also nicht funktioniert. Dies ändert sich mit Firefox 86. Ab dann steht die Leseansicht auch für lokal gespeicherte Dokumente zur Verfügung, welche via file:// aufgerufen werden.

Firefox 86 wird nach aktueller Planung am 23. Februar 2021 erscheinen.

Der Beitrag Firefox 86: Leseansicht für lokale Dateien erschien zuerst auf soeren-hentzschel.at.

Anfang Dezember schrieb ich bereits über ein merkwürdiges Sicherheitsproblem bei KDE neon (siehe: Kommentar: KDE neon – Wirklich so sicher?). Nach einer genaueren Recherche ist das Problem noch deutlich gravierender, weil sich eine geringe Priorisierung der Sicherheit in den Projekten offenbart.

Anfang August schlägt das Thema im KDE Bugtracker auf. Dort erfolgt der Verweis auf einen offenen Bug in Calamares, der seit dem 29. Januar 2020 bekannt ist. Noch mal zum Rekapitulieren, hier geht es nicht um einen nicht funktionierenden Button auf Seite 3 irgendeiner Software, sondern um die falsche Speicherung des LUKS Schlüssels im initramfs, womit die komplette Systemverschlüsselung hinfällig ist.

Regelrecht erbärmlich ist der Whataboutism-Stil im Calamares-Bugtracker. Mehrere kommentierende Personen erwecken den Eindruck, eine nicht verschlüsselte Boot-Partition wäre sowieso so unsicher, dass das Thema hinfällig wäre. Das ist erstens Nonsens ist zweitens ist eine nicht verschlüsselte Boot-Partition über Jahrzehnte Standard bei allen Linux-Distributionen gewesen. Natürlich geht der Trend in die Richtung einer Komplettverschlüsselung inklusive Boot-Partition, aber der Sicherheitsgewinn ist stark theoretischer Natur. Anstelle das Problem zu lösen baut man eine kryptische Warnung ein und das war es dann bis jetzt.

Das ist auf so vielen Ebenen eine Katastrophe, das es mir sehr schwerfällt hier einen sachlichen Artikel zu schreiben.

1. Das ist ein riesiges Sicherheitsproblem und gehört ganz weit oben in die Prioritätenliste einer Installationsroutine und nicht irgendwo unter 169 andere offene Bugs.
2. Es zeigt einmal mehr, dass Installationsroutinen nicht so trivial sind, dass man hier mal eben so was hinzimmert (flapsig formuliert: KDE will eine eigene Installationsroutine).
3. KDE neon steht als inoffizielles Ubuntu-Derivat natürlich der Ubiquity Installer zur Verfügung, den man auch lange verwendete. Aus irgendwelchen nicht nachvollziehbaren Gründen (ich vermute es handelt sich hier um eine „poltiische“ und nicht sachorientierte Entscheidung) wechselte man hier auf Calamares.

Jetzt kann man natürlich argumentieren, dass dem Anwender das Problem schon auffallen wird und er dann was anderes (was eigentlich?) unternimmt. Viele Distributionen mit Calamares richten sich aber eher an Einsteiger. Was ist, wenn diese den Loginscreen dann für die Passwortabfrage zur Vollverschlüsselung halten?

Meiner Meinung nach ist das ein totales Debakel. Wäre dieser Lapsus Microsoft, Apple oder Canonical unterlaufen – das Echo wäre gewaltig. So bleibt es unter dem Radar (der Fehler besteht übrigens immer noch!).

Es zeigt aber deutlich, dass Linux und Sicherheit nicht einfach gleich gesetzt werden dürfen. Linux ist sicher, aber man sollte eine professionell geführte Distribution mit einem seriösen Sicherheitsteam nehmen. Ich möchte gar nicht wissen, was bei diesen kleinen Projekten noch für Sicherheitsrisiken unter der Oberfläche schlummern, die sich einfach niemand im Detail angeguckt hat.

Für weitere Hinweise oder wenn ich hier etwas falsch interpretiert haben sollte, bin ich natürlich dankbar!

Bilder:

Einleitungs- und Beitragsbild von Tumisu via Pixabay

Der Artikel KDE neon, Calamares – Peinliche Sicherheitsprobleme erschien zuerst auf [Mer]Curius

Anfang Dezember schrieb ich bereits über ein merkwürdiges Sicherheitsproblem bei KDE neon (siehe: Kommentar: KDE neon - Wirklich so sicher?). Nach einer genaueren Recherche ist das Problem noch deutlich gravierender, weil sich eine geringe Priorisierung der Sicherheit in den Projekten offenbart.

Anfang August schlägt das Thema im KDE Bugtracker auf. Dort erfolgt der Verweis auf einen offenen Bug in Calamares, der seit dem 29. Januar 2020 bekannt ist. Noch mal zum Rekapitulieren, hier geht es nicht um einen nicht funktionierenden Button auf Seite 3 irgendeiner Software, sondern um die falsche Speicherung des LUKS Schlüssels im initramfs, womit die komplette Systemverschlüsselung hinfällig ist.

Regelrecht erbärmlich ist der Whataboutism-Stil im Calamares-Bugtracker. Mehrere kommentierende Personen erwecken den Eindruck, eine nicht verschlüsselte Boot-Partition wäre sowieso so unsicher, dass das Thema hinfällig wäre. Das ist erstens Nonsens ist zweitens ist eine nicht verschlüsselte Boot-Partition über Jahrzehnte Standard bei allen Linux-Distributionen gewesen. Natürlich geht der Trend in die Richtung einer Komplettverschlüsselung inklusive Boot-Partition, aber der Sicherheitsgewinn ist stark theoretischer Natur. Anstelle das Problem zu lösen baut man eine kryptische Warnung ein und das war es dann bis jetzt.

Das ist auf so vielen Ebenen eine Katastrophe, das es mir sehr schwerfällt hier einen sachlichen Artikel zu schreiben.

1. Das ist ein riesiges Sicherheitsproblem und gehört ganz weit oben in die Prioritätenliste einer Installationsroutine und nicht irgendwo unter 169 andere offene Bugs.
2. Es zeigt einmal mehr, dass Installationsroutinen nicht so trivial sind, dass man hier mal eben so was hinzimmert (flapsig formuliert: KDE will eine eigene Installationsroutine).
3. KDE neon steht als inoffizielles Ubuntu-Derivat natürlich der Ubiquity Installer zur Verfügung, den man auch lange verwendete. Aus irgendwelchen nicht nachvollziehbaren Gründen (ich vermute es handelt sich hier um eine "poltiische" und nicht sachorientierte Entscheidung) wechselte man hier auf Calamares.

Jetzt kann man natürlich argumentieren, dass dem Anwender das Problem schon auffallen wird und er dann was anderes (was eigentlich?) unternimmt. Viele Distributionen mit Calamares richten sich aber eher an Einsteiger. Was ist, wenn diese den Loginscreen dann für die Passwortabfrage zur Vollverschlüsselung halten?

Meiner Meinung nach ist das ein totales Debakel. Wäre dieser Lapsus Microsoft, Apple oder Canonical unterlaufen - das Echo wäre gewaltig. So bleibt es unter dem Radar (der Fehler besteht übrigens immer noch!).

Es zeigt aber deutlich, dass Linux und Sicherheit nicht einfach gleich gesetzt werden dürfen. Linux ist sicher, aber man sollte eine professionell geführte Distribution mit einem seriösen Sicherheitsteam nehmen. Ich möchte gar nicht wissen, was bei diesen kleinen Projekten noch für Sicherheitsrisiken unter der Oberfläche schlummern, die sich einfach niemand im Detail angeguckt hat.

Für weitere Hinweise oder wenn ich hier etwas falsch interpretiert haben sollte, bin ich natürlich dankbar!

Bilder:

Einleitungs- und Beitragsbild von Tumisu via Pixabay

Die Suche nach Updates für Firefox befindet sich an einem Ort, der für manchen Nutzer nicht unbedingt offensichtlich ist. Mit Firefox 86 macht Mozilla die Update-Suche einfacher zugänglich.

Neue Versionen kann Firefox normalerweise automatisch installieren. Manchmal möchte der Nutzer jedoch manuell eine Suche nach Updates anstoßen, um den Vorgang zu beschleunigen. In Firefox funktioniert dies, indem der Dialog „Über Firefox“ aufgerufen wird. Alternativ dazu kann auch in den Firefox-Einstellungen die Suche nach Updates gestartet werden.

Dies sind nicht unbedingt Stellen, an denen jeder Nutzer diese Funktion erwarten würde. In vielen anderen Anwendungen findet man einen Menü-Eintrag für die Suche nach Updates im Hilfe-Menü (Windows / Linux) respektive im Anwendungs-Menü (Apple macOS). Mit Firefox 86 folgt Mozilla diesem „Quasi-Standard“ und integriert an dieser Stelle einen entsprechenden Menüeintrag.

Firefox 86 wird nach aktueller Planung am 23. Februar 2021 erscheinen.

Der Beitrag Firefox 86: Integration der Update-Suche in Menü erschien zuerst auf soeren-hentzschel.at.

Mit Firefox 85 hat Mozilla einen großen Fokus auf die Verbesserung der Lesezeichen-Funktion gelegt. Nutzer dürfen sich in diesem Bereich auf einige Verbesserungen freuen.

Lesezeichen sind nicht nur eines der ältesten Features von Firefox, es ist auch ein Bereich, welcher in den letzten Jahren praktisch unverändert geblieben ist. In Firefox 85 stecken jedoch gleich einige Verbesserungen der Lesezeichen-Funktion.

Hinweis: Für einen kleinen Teil der Nutzer wurden die hier beschriebenen Neuerungen bereits mit Firefox 84 aktiviert. Da die Aktivierung für den Großteil der Nutzer mit Firefox 85 erfolgt sowie zur besseren Unterscheidbarkeit von Neuerungen, welche bereits für alle Nutzer in Firefox 84 erfolgten, spricht der Artikel der Einfachheit halber durchgehend von Firefox 85.

Speicherort der Lesezeichen

Standardmäßig waren beim Speichern von Lesezeichen bisher immer die „Weiteren Lesezeichen“ als Speicherort voreingestellt.

Nicht nur, dass dies das Potential hatte, dass mancher Nutzer seine Lesezeichen nicht wiedergefunden hat, es war vor allem unpraktisch für Nutzer, welche viele Lesezeichen speichern und nicht jedes Mal den Speicherort neu auswählen wollten.

Ausnahme davon waren der Kontextmenüeintrag „Lesezeichen für diesen Link hinzufügen“ sowie „Lesezeichen für diesen Frame hinzufügen“. Hier war das Lesezeichen-Menü vorausgewählt.

Ab Firefox 85 merkt sich Firefox den zuletzt genutzten Speicherort und wählt eben jenen beim nächsten Lesezeichen automatisch als Standard aus – und das an allen Orten. Firefox verhält sich nun also konsistent, unabhängig davon, wie man ein Lesezeichen speichert.

Der Standard-Speicherort, falls noch kein Lesezeichen gesetzt worden ist, ist ab Firefox 85 die Lesezeichen-Symbolleiste, nicht länger die „Weiteren Lesezeichen“.

Anzeige der Lesezeichen-Symbolleiste

Die Lesezeichen-Symbolleiste wird bisher entweder gar nicht oder immer angezeigt. Standardmäßig wird diese gar nicht angezeigt.

Mit Firefox 85 kommt eine dritte Option hinzu, nämlich die Lesezeichen-Symbolleiste ausschließlich bei neuen Tabs, falls diese die Standard-Startseite von Firefox zeigen, einzublenden.

Wird die Lesezeichen-Symbolleiste nicht angezeigt, wird diese jetzt außerdem automatisch eingeblendet, sobald man ein Lesezeichen in dieser speichert.

Lesezeichen-Symbolleiste per Tastatur ein- und ausblenden

Das Ein- und Ausblenden der Lesezeichen-Symbolleiste war bisher nur per Maus und nicht mittels Tastatur möglich. Dies ist (bereits seit Firefox 84) mit dem Tastatur-Kommando Strg + Shift + B (macOS: Cmd + Shift + B) möglich. Umsteiger von Google Chrome haben es einfach, denn Chrome nutzt denselben Shortcut. Und für diejenigen, die sich das nicht merken können, zeigt der entsprechende Menüeintrag den Tastatur-Kurzbefehl an.

Bislang konnte diese Tastenkombination in Firefox zum Öffnen der Bibliothek genutzt werden. Das entsprechende Tastatur-Kommando wurde auf Strg + Shift + O (macOS: Cmd + Shift + O) umgelegt.

Weitere Lesezeichen in Lesezeichen-Symbolleiste

Wie bereits eingangs erwähnt, neigen Lesezeichen in den „Weiteren Lesezeichen“ dazu, in Vergessenheit zu geraten. Aus diesem Grund zeigt Firefox ab Version 85 standardmäßig die „Weiteren Lesezeichen“ zusätzlich in der Lesezeichen-Symbolleiste an. Dieser Ordner erscheint nur, wenn es überhaupt Lesezeichen an dieser Stelle gibt. Wer das nicht mag, kann diese zusätzliche Integration außerdem über das Kontextmenü der Lesezeichen-Symbolleiste ganz einfach deaktivieren.

Sonstige Lesezeichen-Verbesserungen

Ist die Lesezeichen-Symbolleiste leer, erscheint hier (bereits seit Firefox 84) ein Hinweis, dass an dieser Stelle Lesezeichen abgelegt werden können. Über einen Link in diesem Hinweis lässt sich außerdem die Bibliothek öffnen. Bisher wäre hier lediglich eine leere Fläche gewesen.

Je nachdem, ob es Lesezeichen in der Lesezeichen-Symbolleiste gab oder nicht, war die Höhe der Symbolleiste bislang unterschiedlich. Dieser Schönheitsfehler wurde behoben.

In neuen Firefox-Profilen mit weniger als drei Lesezeichen zeigt Firefox in der Lesezeichen-Symbolleiste ab sofort eine Schaltfläche an, worüber Lesezeichen aus anderen Browsern importiert werden können.

Außerdem wurde ein Flackern der Favicons in der Lesezeichen-Symbolleiste beim Starten von Firefox respektive beim Öffnen neuer Fenster behoben.

Firefox 85 wird nach aktueller Planung am 26. Januar 2021 erscheinen.

Der Beitrag Firefox 85: Viele Verbesserungen bei den Lesezeichen erschien zuerst auf soeren-hentzschel.at.

Die IT Welt unterliegt einem steten Wandel, aber manches bleibt gleich. Dazu gehört bei Linux die Trennung in Rolling Release Distributionen und solche mit festen Releases und Supportzeiträumen. Sind diese entsprechend lang, spricht man meist von Enterprise-Distributionen oder LTS-Distributionen.

Traditionell empfehle ich nur Letztere für den produktiven Einsatz. Der Kanon der relevanten Distributionen ist dabei über die Jahre sehr konstant geblieben (siehe: Linux – Eine sichere Basis). Mich erreichen häufig Kommentare und E-Mails mit der Bitte, doch mal Manjaro, Arch Linux, openSUSE Tumbleweed oder Ähnliches vorzustellen.

Momentan setze ich selbst eine RR-Distribution ein, weil mein Notebook erst ab Kernel 5.8 unterstützt wird und keine verfügbare LTS Variante diesen Kernel aktuell führt. Ich freue mich aber schon darauf, wenn ich auf dem Gerät auf eine LTS Distribution wechseln kann. Ich hatte alleine in den letzten zwei Monaten genug Scherereien damit. Beim Wechsel auf Linux 5.10 startete beispielsweise das System beispielsweise erst mal nicht, weshalb ich händisch 5.9 starten musste. Ein späteres Update bereinigte das dann. Ähnliches passierte beim Update des NetworkManager-Stacks. Alles kein Drama, aber es kostete Zeit, die ich sonst für anderes gehabt hätte.

Es gibt im wesentlichen zwei Gründe warum ich LTS-Distributionen den Vorzug gebe:

Der erste ist die Stabilität. Ein Ubuntu, Debian, openSUSE Leap oder bis vor kurzem auch CentOS System konnte ich aufsetzen, danach die Updates auf den Automodus einstellen und das Gerät dann für die nächsten 3, 5 oder sogar 10 Jahre vergessen. Die Wahrscheinlichkeit, dass ich in dieser Zeit ein Problem durch Updates bekomme, geht meiner Erfahrung nach gegen null. Anhänger von RR-Modellen führen dagegen über die verhältnismäßig aufwendigen Upgrades zwischen den Versionen an und dass sie lieber jeden Tag oder jede Woche ein bisschen Arbeit in das System stecken (sofern notwendig). Das funktioniert aber halt auch nur, wenn man selbst die Zeit, Lust und Expertise hat dies zu tun. Für betreute Systeme fällt das weg und bei kritischen Systemen, die unbedingt funktionieren müssen, eigentlich auch. Mir ist aber durchaus klar, dass viele Anwender von openSUSE Tumbleweed oder Arch Linux Installationen haben, die Jahre alt sind.

Deshalb ist der zweite Punkt für mich deutlich relevanter: Updates bringen Arbeit ohne Mehrwert. Mir ist das gerade wieder sehr deutlich vor Augen geführt worden. Aktuell müssen hier ein paar Kubuntu 18.04 Installationen aktualisiert werden. Die Systeme sind von den Versionsständen gut drei Jahre alt. Eine Aktualisierung bringt nahezu keinen funktionalen Mehrwert. Mir ist das erst völlig klar geworden, als ich den Upgrade-genervten Anwendern die Vorzüge der neuen Version wenigstens ansatzweise schmackhaft machen wollte. Ein paar Schaltflächen wurden durch die Gegend geschoben und das war es auch schon. Das gilt ebenso für GNOME und erst recht für Desktopumgebungen wie MATE und Xfce. Klar kann man nun argumentieren, dass es mehr als den Desktop gibt, aber auch dort gibt es keine relevanten Neuerungen. Firefox Updates gibt es bei jeder LTS-Version auch im Supportzeitraum und sonst so? LibreOffice bringt in jedes neue Release genau so viele neue Bugs ein, wie es alte schließt. Kontact, Evolution, Thunderbird, FileZilla, Mediaplayer, GIMP – überall kann man relevante Neuerungen mit der Lupe suchen. Warum soll man sich also die Instabilität eines RR Systems antun? Es sind doch Updates um der Updates willen.

Das sind die beiden Gründe, weshalb hier nie RR Distributionen empfohlen werden.

Bilder:

Einleitungs- und Beitragsbild von ar130405 via Pixabay

Der Artikel Warum ich nur LTS Distributionen empfehle erschien zuerst auf [Mer]Curius

Wie ihr sicher gemerkt habt, beschäftige ich mich im Rahmen eines Wochenend-Projekts mit „Kanboard im Container…“ im Speziellen und Linux-Containern im Allgemeinen. Die Einrichtung von „Backup und Restore im Kanboard-Container-Land“ liegt bereits hinter mir. Und das ist gut so, habe ich doch nun den ersten Datenverlust erlitten und musste meine Daten wiederherstellen.

Die etwas unglückliche Verkettung von Umständen, welche zum Datenverlust führten, möchte ich in diesem Artikel festhalten, so dass euch diese Erfahrung erspart bleiben kann.

Die Vorgeschichte

Da Container zustandslose Gebilde sind, nutze ich podman volumes, um die anfallenden Daten persistent zu speichern.

Als Einsteiger in die Thematik habe ich mich an der offiziellen Container-Dokumentation von Red Hat entlang gehangelt und bin den Anweisungen in Kapitel 3.4. Sharing files between two containers (die Dokumentation wurde überarbeitet; das Kapitel existiert so nicht mehr) gefolgt. Dort wird beschrieben, wie man den Volume-Pfad einer Variablen zuweist, welche später verwendet wird, um das Volume über den Pfad in den Container einzuhängen.

Da ich es nicht besser wusste, bin ich der Anleitung Schritt-für-Schritt gefolgt. Dies führte zu einer funktionierenden Konfiguration, in der meine Daten persistent gespeichert wurden.

Kommando ‚podman volume prune‘ und die Daten waren weg

Am Ende meiner Spielerei wollte ich das Spielfeld bereinigen. Dabei bin ich auf das Kommando podman volume prune gestoßen, welches laut podman-volume-prune(1) alle Volumens entfernt, die sich nicht in Verwendung befinden. Dies klang nach genau dem Befehl, nach dem ich gesucht habe.

TL;DR: Nach der Ausführung des Kommandos waren meine Volumes weg. Auch jene, die aktiv in laufenden Container-Instanzen eingehängt waren.

Die Analyse

Nach ein paar Tests und einer Internetrecherche stand die Ursache für das Verhalten fest. Diese ist im GitHub Issue #7862 dokumentiert und besagt, dass podman volume prune in Verwendung befindliche Volumes löscht, wenn diese über ihren Pfad und nicht über ihren Namen eingehängt wurden. Da ich wie oben beschrieben der Dokumentation von Red Hat strikt gefolgt bin, welche aber genau den Pfad und eben nicht den Namen verwendet, waren Ursache und Erklärung für den Datenverlust gefunden.

Die Folge

In Folge meiner Erfahrungen habe ich zwei Anfragen zur Produktverbesserung (englisch: Request For Enhancement oder kurz RFE) gestellt:

1. Bug 1914096 – Needs improvement: Building, running, and managing containers: 3.4. Sharing files between two containers
2. RFE: Let `podman volume prune` show the volumes that are going to be removed

Die erste Anfrage ist an Red Hat adressiert, mit der Bitte, in der Dokumentation den Volume-Namen an Stelle des in einer Variablen gespeicherten Volume-Pfades zu benutzen. Damit sollte verhindert werden, dass andere, die der Dokumentation folgen, die gleichen Erfahrungen wie ich machen müssen.

Als Ziel wird die Veröffentlichung von RHEL 8.4 anvisiert. Dieses Release sollte im Mai bzw. Juni 2021 erscheinen. Ich bin gespannt. Ich würde mich über eine frühere Aktualisierung der Dokumentation freuen. Update 2021-01-25: Bereits am 20. Januar wurde eine neue Version der Dokumentation veröffentlicht. In dieser war nur noch ein kleiner Tippfehler enthalten. Der Bug wurde mit dem heutigen Datum (25.01.2021) geschlossen. So ist sichergestellt, dass hier niemand mehr in die Falle tappt. Vielen Dank ans RHEL-Docs-Team im Allgemeinen und Gabriela im Speziellen.

Die zweite Anfrage richtet sich an das Upstream-Projekt. Sie beinhaltet den Vorschlag, podman volume prune (um eine Option) zu erweitern, so dass die Liste der zu löschenden Volumes angezeigt wird, bevor man die Entfernung bestätigt. Stand 17.01.2021 existiert bereits ein Pull-Request, welcher dieses Thema adressiert.

Meinen Artikel „Kanboard im Container…“ habe ich entsprechend angepasst, so dass auch dort die Volumen-Namen zum Einhängen verwendet werden und nicht die Volume-Pfade.

Alte Erkenntnis bestätigt

Dieses Beispiel zeigt wieder einmal sehr deutlich, wie wichtig eine funktionierende Datensicherung ist. Denn sie ist die zwingende Voraussetzung, um im Fehlerfall Daten auch wiederherstellen zu können. Daher kann ich nur jedem raten, ein entsprechendes Datensicherungs- und Wiederherstellungs-Konzept zu implementieren, bevor man Daten in eine Anwendung tut, die einem am Herzen liegen oder von denen die Zukunft des Unternehmens abhängt.

Zum Stöbern führe ich im Folgenden einige Artikel aus diesem Blog auf, welche sich mit dem Thema Backup befassen:

• Backup und Restore im Kanboard-Container-Land
• Mit einem Reverse-SSH-Tunnel zum Offsite-Backup
• Backup, Backup, Backup – Von den Vorteilen einer Datensicherung
• Dateibackup mit der Systemrescue-CD

Firefox erlaubt bereits seit langer Zeit den Import von gespeicherten Zugangsdaten aus anderen Browsern. Ab Firefox 85 unterstützt Mozillas Browser auch den Import von Passwörtern aus den Passwort-Managern KeePass und Bitwarden.

Die Möglichkeit, Daten wie Lesezeichen oder auch gespeicherte Zugangsdaten aus anderen Browsern importieren zu können, ist nicht neu. Einige Nutzer lassen ihre Passwörter jedoch nicht im Browser, sondern in einem externen Passwort-Manager speichern. In Zukunft wird Mozilla auch den Import aus verschiedenen Passwort-Managern ermöglichen.

Den Grundstein dafür hat Mozilla bereits in Firefox 79 gelegt. Mit Firefox 79 hat die Passwort-Verwaltung von Firefox, aufrufbar über about:logins, eine Export-Funktion für gespeicherte Zugangsdaten erhalten. Diese exportiert die Daten im CSV-Format. Mit Firefox 80 kam eine Import-Funktion hinzu, welche standardmäßig allerdings noch deaktiviert ist. Über die Import-Funktion können die CSV-Exports von Firefox selbst wie auch von Google Chrome eingelesen werden. Dies ist besonders für Linux-Nutzer interessant, da Firefox unter Linux die Passwörter von Chrome nicht direkt importieren kann. Auch der Passwort-Manager Bitwarden wird seit Firefox 80 unterstützt.

Mit Firefox 85 kommt die Unterstützung für den Passwort-Manager KeePass hinzu. Dies schließt den Fork KeePassX sowie dessen Fork KeePassXC mit ein.

In der finalen Version von Firefox 85 wird die Import-Funktion standardmäßig noch deaktiviert sein, kann aber über about:config aktiviert werden, indem der Schalter signon.management.page.fileImport.enabled per Doppelklick auf true gesetzt wird. Anschließend ist die Import-Funktion im Menü von about:logins aufrufbar.

Firefox 85 wird nach aktueller Planung am 26. Januar 2021 erscheinen.

Der Beitrag Firefox 85: Import von Passwörtern aus KeePass und Bitwarden erschien zuerst auf soeren-hentzschel.at.

Der Abgleich der gespeicherten Kontakte ist ebenso sensibel wie bei Kalenderdaten. Zahllose kostenlose und kostenpflichtige Anbieter tummeln sich auf dem Gebiet. Nur wenige machen sich Gedanken, ob das überhaupt legal ist. Immerhin übertragt man die gespeicherten Informationen über unbeteiligte Dritte an einen fremden Dienst. Besser man nimmt dafür ein NAS! Hierfür bietet Synology nun eine dezidierte App.

Dieser Artikel ist eine Alternative bzw. moderne Variante von Teil VI. Beide lassen die Verwaltung von Kontakten und ihren Abgleich via CardDAV Schnittstelle zu.

In den letzten Jahren baut Synology seine Software-Suite aus. Ursprünglich war der DiskStation Manager eine hübsche Oberfläche für gängige Dienste wie SMB, WebDAV, CalDAV oder eben CardDAV. Nach und nach rollt man nun WebApps für die einzelnen Dienste aus. Seit Längerem hat man mit Drive eine vollwertige Cloudlösung oder mit Calendar eine Terminverwaltung, die sich auch gut im Browser bedienen lässt. Synology Contacts schließt diese Lücke im Bereich der Kontaktverwaltung.

Die Installation erfolgt über das Paket-Zentrum, woraus alle unterstützten NAS-Geräte die App installieren können. Die App präsentiert sich aufgeräumt im üblichen Synology Look & Feel.

Sofern ein Zugriff von außerhalb des eigenen Netzwerks gewünscht ist und dieser nicht über VPN erfolgt empfiehlt es sich, in der Systemsteuerung unter Anwendungsportal einen eigenen Port für die App zu konfigurieren und separat freizugeben. Ansonsten teilt sich die Contacts App den Port mit der DSM-Oberfläche.

Zusätzlich zu den Standard-Adressbüchern lassen sich weitere individuelle Adressbücher anlegen. Wichtig ist, dass diese keine Ordner im CardDAV-Sinne sind, sondern eigene Adressbücher. Sie lassen sich also auch eigens zur Synchronisation einbinden.

Eine Übernahme aus der vorherigen App findet leider nicht statt. Hier muss man deshalb den Weg über Export und Import der Daten gehen. Das hat bei mir fehlerfrei funktioniert, aber ein bisschen mehr Komfort wäre schön gewesen.

Per Klick auf die drei Punkte rechts von den Adressbüchern werden die Zugangsdaten für CardDAV angezeigt. Dabei zeigt Synology Contacts zwei verschiedene Links an.

• iOS: Generische URL https://deine-domain:Port:/carddav/<benutzer>
• CardDAV-Client: https://deine-domain:Port:/carddav/<benutzer>/<Adressbuch-ID>

Diese Zweiteilung ist aber bestenfalls ein Hilfsmittel. So kann z. B. Akonadi mit den iOS URLs umgehen, ebenso DAVx5. Evolution möchte hingegen die komplette ID, findet diese aber über den Assistenten selbst heraus. Hier muss also jeder mit seinen Clients ein wenig ausprobieren, was genau funktioniert. Das ist aber weniger ein Manko von Synology Contacts, als eher der heterogenene Implementierung des Standards geschuldet.

Bilder:
Einleitungsbild und Beitragsbild von von 200 Degrees via pixabay

Der Artikel Synology NAS XII – Contacts App für Adressbuchsynchronisation erschien zuerst auf [Mer]Curius

Der Abgleich der gespeicherten Kontakte ist ebenso sensibel wie bei Kalenderdaten. Zahllose kostenlose und kostenpflichtige Anbieter tummeln sich auf dem Gebiet. Nur wenige machen sich Gedanken, ob das überhaupt legal ist. Immerhin übertragt man die gespeicherten Informationen über unbeteiligte Dritte an einen fremden Dienst. Besser man nimmt dafür ein NAS! Hierfür bietet Synology nun eine dezidierte App.

Dieser Artikel ist eine Alternative bzw. moderne Variante von Teil VI. Beide lassen die Verwaltung von Kontakten und ihren Abgleich via CardDAV Schnittstelle zu.

In den letzten Jahren baut Synology seine Software-Suite aus. Ursprünglich war der DiskStation Manager eine hübsche Oberfläche für gängige Dienste wie SMB, WebDAV, CalDAV oder eben CardDAV. Nach und nach rollt man nun WebApps für die einzelnen Dienste aus. Seit Längerem hat man mit Drive eine vollwertige Cloudlösung oder mit Calendar eine Terminverwaltung, die sich auch gut im Browser bedienen lässt. Synology Contacts schließt diese Lücke im Bereich der Kontaktverwaltung.

Die Installation erfolgt über das Paket-Zentrum, woraus alle unterstützten NAS-Geräte die App installieren können. Die App präsentiert sich aufgeräumt im üblichen Synology Look & Feel.

Sofern ein Zugriff von außerhalb des eigenen Netzwerks gewünscht ist und dieser nicht über VPN erfolgt empfiehlt es sich, in der Systemsteuerung unter Anwendungsportal einen eigenen Port für die App zu konfigurieren und separat freizugeben. Ansonsten teilt sich die Contacts App den Port mit der DSM-Oberfläche.

Zusätzlich zu den Standard-Adressbüchern lassen sich weitere individuelle Adressbücher anlegen. Wichtig ist, dass diese keine Ordner im CardDAV-Sinne sind, sondern eigene Adressbücher. Sie lassen sich also auch eigens zur Synchronisation einbinden.

Eine Übernahme aus der vorherigen App findet leider nicht statt. Hier muss man deshalb den Weg über Export und Import der Daten gehen. Das hat bei mir fehlerfrei funktioniert, aber ein bisschen mehr Komfort wäre schön gewesen.

Per Klick auf die drei Punkte rechts von den Adressbüchern werden die Zugangsdaten für CardDAV angezeigt. Dabei zeigt Synology Contacts zwei verschiedene Links an.

• iOS: Generische URL https://deine-domain:Port:/carddav/<benutzer>
• CardDAV-Client: https://deine-domain:Port:/carddav/<benutzer>/<Adressbuch-ID>

Diese Zweiteilung ist aber bestenfalls ein Hilfsmittel. So kann z. B. Akonadi mit den iOS URLs umgehen, ebenso DAVx5. Evolution möchte hingegen die komplette ID, findet diese aber über den Assistenten selbst heraus. Hier muss also jeder mit seinen Clients ein wenig ausprobieren, was genau funktioniert. Das ist aber weniger ein Manko von Synology Contacts, als eher der heterogenene Implementierung des Standards geschuldet.

Bilder:
Einleitungsbild und Beitragsbild von von 200 Degrees via pixabay

Die meisten Verschlüsselungslösungen erzeugen automatisch einen sogenannten Wiederherstellungsschlüssel. Dabei handelt es sich simplifiziert ausgedrückt meist einfach um einen zweiten Schlüssel, um bei Bedarf doch noch an seine Daten zu kommen. LUKS macht dies nicht automatisch, man kann es aber nachträglich einrichten.

Dazu muss man sich vergegenwärtigen, dass ein LUKS Volume über 8 Key-Slots verfügt. Man kann also theoretisch 8 verschiedene Schlüssel für das gleiche LUKS-Volume vergeben. Ganz egal ob es sich dabei um eine komplette Betriebssystemverschlüsselung handelt (siehe: LUKS – Betriebssystem verschlüsseln) oder um ein externes Speichermedium wie eine externe Festplatte oder einen USB Stick (siehe: LUKS – Externe Speichermedien verschlüsseln).

Will man einen Wiederherstellungsschlüssel vergeben, sollte man erst einmal prüfen, in welchem Slot die existierende Primärpassphrase gespeichert ist.

$ sudo cryptsetup luksDump /dev/nvme0n1pX

Dabei natürlich das passende Volume auswählen.

Anzeigt werden die belegten Keyslots. Bei einer normalen Installation dürfte meistens der Keyslot 0 belegt sein. Der Wiederherstellungscode kann in einen beliebigen freien Slot geschrieben werden.

Dazu genügt folgender Befehl:

$ sudo cryptsetup luksAddKey /dev/nvme0n1p3 --key-slot <Nummer>

Zuerst muss man die bestehende Passphrase eintragen und anschließend zwei mal den Wiederherstellungscode.

Beim Wiederherstellungscode gelten die üblichen Regeln für sichere Passwörter. Da man den Wiederherstellungsschlüssel im besten Fall nie eingeben muss, kann man hier einen wirklich langen Schlüssel wählen.

Anschließend kann man mit dem ersten Befehl prüfen ob nun der gewählte Keyslot belegt ist.

Den Wiederherstellungsschlüssel kann man z. B. als Ausdruck in einem Bankschließfach oder einem Tresor aufheben. Bei Bedarf lassen sich auch mehrere Schlüssel anlegen, lediglich die maximale Anzahl von 8 Schlüsseln kann nicht überschritten werden.

Der Artikel LUKS Volumes mit einem Wiederherstellungsschlüssel versehen erschien zuerst auf [Mer]Curius

Die meisten Verschlüsselungslösungen erzeugen automatisch einen sogenannten Wiederherstellungsschlüssel. Dabei handelt es sich simplifiziert ausgedrückt meist einfach um einen zweiten Schlüssel, um bei Bedarf doch noch an seine Daten zu kommen. LUKS macht dies nicht automatisch, man kann es aber nachträglich einrichten.

Dazu muss man sich vergegenwärtigen, dass ein LUKS Volume über 8 Key-Slots verfügt. Man kann also theoretisch 8 verschiedene Schlüssel für das gleiche LUKS-Volume vergeben. Ganz egal ob es sich dabei um eine komplette Betriebssystemverschlüsselung handelt (siehe: LUKS - Betriebssystem verschlüsseln) oder um ein externes Speichermedium wie eine externe Festplatte oder einen USB Stick (siehe: LUKS - Externe Speichermedien verschlüsseln).

Will man einen Wiederherstellungsschlüssel vergeben, sollte man erst einmal prüfen, in welchem Slot die existierende Primärpassphrase gespeichert ist.

$ sudo cryptsetup luksDump /dev/nvme0n1pX

Dabei natürlich das passende Volume auswählen.

Anzeigt werden die belegten Keyslots. Bei einer normalen Installation dürfte meistens der Keyslot 0 belegt sein. Der Wiederherstellungscode kann in einen beliebigen freien Slot geschrieben werden.

Dazu genügt folgender Befehl:

$ sudo cryptsetup luksAddKey /dev/nvme0n1p3 --key-slot <Nummer>

Zuerst muss man die bestehende Passphrase eintragen und anschließend zwei mal den Wiederherstellungscode.

Beim Wiederherstellungscode gelten die üblichen Regeln für sichere Passwörter. Da man den Wiederherstellungsschlüssel im besten Fall nie eingeben muss, kann man hier einen wirklich langen Schlüssel wählen.

Anschließend kann man mit dem ersten Befehl prüfen ob nun der gewählte Keyslot belegt ist.

Den Wiederherstellungsschlüssel kann man z. B. als Ausdruck in einem Bankschließfach oder einem Tresor aufheben. Bei Bedarf lassen sich auch mehrere Schlüssel anlegen, lediglich die maximale Anzahl von 8 Schlüsseln kann nicht überschritten werden.

Messenger sind aktuell wieder ein heißes Thema. Erst der staatliche Angriff auf die Verschlüsselung nun in der vergangenen Woche die AGB-Änderung von WhatsApp. Die träge Nutzerschaft setzt sich in Bewegung und der Markt sortiert sich neu. Wären da nicht diese nervigen Zwischenrufer von Seitenlinie.

Öffentliche Meinungsbildung ist ein komplexer Prozess. Es reicht nicht, nur ein gutes Produkt anzubieten, sondern dieses muss in der Öffentlichkeit auch als Alternative wahrgenommen werden. Bei vielen Sachen ist es letztlich nicht so wichtig, ob man den Dienst alleine nutzt oder Millionen Mitmenschen auch. Bei Messengern sieht das anders aus, weil hier die Verbreitung des Dienstes ein relevanter Faktor für die Nutzung ist.

Spätestens in der vergangenen Woche hat man aber sehen können, dass der Trend in die richtige Richtung geht. Nahezu alle Empfehlungen in den Fach- und Mainstreammedien sowie über die sozialen Netzwerke liefen auf zwei Alternativen hinaus: Threema und Signal. Beides hervorragende und sichere Alternativen zum Marktführer WhatsApp. Die Tendenz geht ein bisschen in Richtung Signal, aber das kann je nach Struktur des Freundes- und Bekanntenkreises auch ein wenig anders aussehen.

Endlich sind die pseudo-sicheren Messenger wie Telegram oder Viber nicht mehr in den Empfehlungslisten und ein gesellschaftlicher Fortschritt ist wirklich zum Greifen nahe.

Wären da nicht diese nervtötenden Fans föderierter Systeme, die über E-Mails und Kommentarspalten schamlos Werbung für ihre Systeme machen und Diskussionen hijacken.

Haltet euch einfach zurück!

Natürlich haben Matrix oder Rocket.Chat und meinethalben auch der Zombie XMPP ihre Berechtigung. Wenn eine geschlossene Gruppe wie die KDE-Entwickler auf Matrix wechseln oder Firmen Rocket.Chat einsetzen wollen, ist das toll! Hier spielen ganz andere Dynamiken eine Rolle und genau dafür sind diese Dienste perfekt.

Sie sind nicht für den Individualeinsatz bestimmt! Dort funktionieren sie nicht. Es hat Gründe, dass alle Messenger mit einem relevanten Marktanteil zentralisierte Systeme mit der Telefonnummer als (optionalen) Identifikator sind.

Und die föderierten Systeme sind nicht sicherer! Hört endlich auf euch das Sicherheits-Ettiket anzuheften! Sie sind vermutlich nicht mal sicherer als WhatsApp.

Föderierte Systeme haben ihre Stärken im Bereich der Autonomie und der digitalen Souveränität. Das ist ein wichtiges Thema aber es hat nicht unmittelbar etwas mit Sicherheit zu tun. Natürlich ist es toll, wenn man selbst den Server betreiben oder Clients für irgendwelche Nischensysteme entwickeln kann, aber das hat etwas mit Freiheit und nicht mit Sicherheit zu tun.

Föderierte Systeme haben systembedingt erhebliche Schwachstellen. Es sind bei allen diesen Systemen zahlreiche Serverbetreiber im Einsatz, denen man allen vertrauen muss. Bei einigen gibt es inzwischen eine Inhalte-Verschlüsselung, aber Metadaten liegen offen. Dienste wie Matrix sind zudem überhaupt nicht datensparsam konzipiert, sondern speichern auf allen beteiligten Servern die komplette Kommunikation. Ein Traum für die Sicherheitsbehörden! Offizielle Security-Audits bei Systemen wie XMPP sind oft Jahre alt. Die hohe Client-Vielfalt ermöglicht gleichzeitig unbegrenzte Möglichkeiten der Fehlkonfiguration und sich dadurch selbst zu kompromittieren.

Kurzum: Ja, digitale Souveränität bzw. Autonomie sind legitime Anliegen, sie machen in bestimmten Einsatzszenarien Sinn. Aber liebe Fans dieser Dienste hört auf, euch das Sicherheits-Ettiket anzuheften und nervt nicht von der Seitenlinie, wenn die Mehrheit gerade hinsichtlich Sicherheit und Privatsphäre einen Quantensprung unternimmt. Euer Störfeuer verunsichert nur und hält im schlimmsten Fall noch Nutzer ab, auf gute WhatsApp-Alternativen zu wechseln.

Bilder:
Einleitungs- und Beitragsbild von Gerd Altmann via pixabay

Der Artikel Kommentar: Fans von Matrix, XMPP & Co – Nervt nicht! erschien zuerst auf [Mer]Curius