Normale Ansicht

Mozilla veröffentlicht Firefox 139

27. Mai 2025 um 18:15

Mozilla hat Firefox 139 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

Benutzerdefiniertes Hintergrundbild oder -farbe für Startseite

Der Nutzer kann für die Standard-Startseite von Firefox auf Wunsch aus verschiedene Hintergrundbildern oder Hintergrundfarben wählen, die Firefox zur Auswahl stellt. Ab sofort kann der Nutzer stattdessen auch ein eigenes Bild hinterlegen oder eine beliebige Farbe auswählen.

Diese Neuerung wird schrittweise im Laufe der kommenden Wochen für alle Nutzer ausgerollt werden.

Mehr Sicherheit für Firefox-Nutzer

Auch in Firefox 139 wurden wieder mehrere Sicherheitslücken geschlossen. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 139 daher für alle Nutzer dringend empfohlen.

Sonstige Endnutzer-Neuerungen in Firefox 139

Die Übersetzungsfunktion von Firefox kann nicht länger nur für Websites genutzt werden, sondern auch für Seiten, die durch Add-ons bereitgestellt werden. Außerdem werden jetzt auch bestimmte aria-*-Attribute für Barrierefreiheits-Werkzeuge übersetzt.

Untertitel für die Bild-im-Bild-Funktion für Videos werden ab sofort auch auf der im deutschsprachigen Raum sehr populären Streaming-Plattform Joyn unterstützt. Außerdem werden Untertitel auf Disney+ wieder unterstützt, nachdem es Änderungen seitens Disney gab.

Im strengen Schutz vor Aktivitätenverfolgung werden nicht länger Consent Management Plattformen, sogenannte „Cookie-Dialoge“, blockiert, was für einen sehr großen Teil aller Webkompatibilitätsprobleme dieser Schutzstufe verantwortlich war.

Die vor wenigen Versionen neu umgesetzte Chronik-Sidebar hat die Optionen der alten Sidebar zurückerhalten, nicht nur nach Datum oder Website, sondern auch nach Datum und Website sowie dem Zeitpunkt des letzten Besuches sortieren zu können. Auch das Kontextmenü der einzelnen Einträge beinhaltet jetzt wieder alle Optionen der alten Sidebar. Außerdem wurde das Problem behoben, dass für manche Nutzer der Browser nicht mehr mit geöffneter Sidebar gestartet wurde, wenn diese beim Beenden von Firefox geöffnet war.

Das Design der Verknüpfungen auf der Standard-Startseite von Firefox wurde überarbeitet.

Die aktuelle Seite kann jetzt auch per Schnellaktions-Schaltfläche als PDF-Datei gespeichert werden, wenn „Seite speichern“ in die Adressleiste eingegeben wird.

Beim automatischen Ausfüllen gespeicherter Adressen berücksichtigt Firefox jetzt auch dynamisch veränderte Auswahlfelder.

Die Upload-Performance von HTTP/3 wurde erheblich verbessert, insbesondere bei wiederaufgenommenen Verbindungen sowie bei Verbindungen mit hoher Bandbreite und hoher Verzögerung.

Das Filter-Feld im Netzwerkanalyse-Entwicklerwerkzeug merkt sich die Eingabe nun über Sitzungen hinweg.

Aufgrund aktueller Änderungen, wie Chrome Benutzerdaten unter Windows verschlüsselt, kann Firefox Passwörter und Zahlungsmethoden nicht länger direkt aus Chrome importieren. Deswegen steht diese Option nicht länger zur Verfügung. Passwörter können jedoch weiterhin aus Chrome in eine CSV-Datei exportiert und diese anschließend in Firefox importiert werden.

In Folge der bevorstehenden Abschaltung von Fakespot steht der sogenannte „Review Checker“ ab dem 10. Juni nicht länger zur Verfügung. Da es sich hierbei um ein bislang nicht flächendeckend ausgerolltes Feature handelt, welches außerdem für die deutschsprachige Amazon-Website standardmäßig deaktiviert war (und keine anderen deutschsprachigen Shops unterstützt werden), dürften hiervon nur wenige Leser dieses Blogs betroffen sein.

Die SearchEngines-Unternehmensrichtlinie zur Verwaltung der standardmäßig verfügbaren Suchmaschinen funktioniert nun in allen Firefox-Versionen und nicht länger nur in Firefox ESR.

Verbesserungen der Webplattform und für Erweiterungs-Entwickler

Als erster Browserhersteller aktiviert Mozilla die Unterstützung für die Temporal API zum besseren Umgang mit Datums- und Zeitangaben.

Firefox unterstützt jetzt das hidden=until-found-Attribut, um Inhalte über die Browsersuche finden zu können, die standardmäßig ausgeblendet sind. Genauso lassen sich jetzt auch geschlossene <details>-Elemente durchsuchen und bei einem Treffer über die Browsersuche automatisch ausklappen.

Verbesserungen gab es auch unter der Haube, welche die Webkompatibilität mit anderen Browsern verbessern.

Firefox 139 unterstützt die WebExtension-Methode chrome.management.setEnabled, um andere Erweiterungen zu aktivieren respektive zu deaktivieren. Allerdings ist diese Unterstützung exklusiv für Erweiterungen, welche über eine Unternehmensrichtlinie installiert worden sind.

Außerdem neu ist die Unterstützung einer neuen WebExtension-API, um mit den Tab-Gruppen von Firefox zu interagieren.

Für Erweiterungs-Entwickler gibt es mit extensions.webextensions.prefer-update-over-install-for-existing-addon eine neue versteckte Option, um den Update-Ablauf anstelle des Ablaufes für eine Neuinstallation auszuführen, wenn eine lokale Erweiterung über about:addons installiert wird.

Weitere Verbesserungen der Webplattform und für Erweiterungsentwickler lassen sich wie immer in den MDN Web Docs nachlesen.

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

Sicherheitslücken in Open-Source-Projekten: Der Fall XZ Utils und die Lehren daraus

27. Mai 2025 um 15:56

Open-Source-Software steht für Transparenz und Zusammenarbeit. Gleichzeitig ist sie ein beliebtes Ziel für Angreifer, die Schwachstellen im Code ausnutzen. Besonders kleinere Projekte leiden unter Personalmangel und fehlenden Prüfmechanismen. Der XZ-Utils-Vorfall zeigt, wie gefährlich manipulierte Beiträge werden können. Wie können sich Open-Source-Projekte besser vor solchen Angriffen schützen?

Der Beitrag Sicherheitslücken in Open-Source-Projekten: Der Fall XZ Utils und die Lehren daraus erschien zuerst auf Linux Abos.

Linux Kernel 6.15 veröffentlicht: Viele Neuerungen unter der Haube

Von: MK
26. Mai 2025 um 15:20

Nach einer kurzen Verzögerung durch einen späten Fehlerbericht ist Linux 6.15 offiziell erschienen. Ein Feature musste in letzter Minute deaktiviert werden. Trotzdem bringt die neue Version zahlreiche Verbesserungen im Speicher-, Datei- und Sicherheitssystem mit. Im Fokus stehen Optimierungen für Container, effizientere Speicherverwaltung und Inline-Verschlüsselung. Auch das Dateisystem Bcachefs wurde stark erweitert. Btrfs, Ext4 und F2FS […]

Der Beitrag Linux Kernel 6.15 veröffentlicht: Viele Neuerungen unter der Haube erschien zuerst auf fosstopia.

acme.sh für eine REST-API

26. Mai 2025 um 07:36

Seit vielen Jahren verwende ich Let’s Encrypt-Zertifikate für meine Webserver. Zum Ausstellen der Zertifikate habe ich in den Anfangszeiten das Kommando certbot genutzt. Weil die Installation dieses Python-Scripts aber oft Probleme bereitete, bin ich schon vor vielen Jahren auf das Shell-Script acme.sh umgestiegen (siehe https://github.com/acmesh-official/acme.sh).

Kürzlich bin ich auf einen Sonderfall gestoßen, bei dem acme.sh nicht auf Anhieb funktioniert. Die Kurzfassung: Ich verwende Apache als Proxy für eine REST-API, die in einem Docker-Container läuft. Bei der Zertifikatausstellung/-erneuerung ist Apache (der auf dem Rechner auch als regulärer Webserver läuft) im Weg; die REST-API liefert wiederum keine statischen Dateien aus. Die Domain-Verifizierung scheitert. Abhilfe schafft eine etwas umständliche Apache-Konfiguration.

Ausgangspunkt

Ausgangspunkt ist also ein »gewöhnlicher« Apache-Webserver. Dieser soll nun zusätzlich eine REST-API ausliefern, die in einem Docker-Container läuft (localhost:8880). Die erste Konfiguration sah ziemlich simpel aus:

# zusätzliche Apache-Proxy-Konfigurationsdatei 
# für einen Docker-Container 
<VirtualHost *:443>
    ServerName api.example.com

    # SSL
    SSLEngine on
    SSLCertificateFile    /etc/acme-letsencrypt/api.example.com.pem
    SSLCertificateKeyFile /etc/acme-letsencrypt/api.example.com.key

    # Proxy: localhost:8880 <-> https://api.example.com
    ProxyPreserveHost On
    ProxyPass         / http://localhost:8880/
    ProxyPassReverse  / http://localhost:8880/

    # Logging Konfiguration ...
</VirtualHost>


#  HTTP -> HTTPS
<VirtualHost *:80>
    ServerName api.example.com
    Redirect permanent / https://api.example.com
</VirtualHost>

Das Problem

Das Problem besteht darin, dass acme.sh zwar diverse Domain-Verifizierungsverfahren kennt, aber keines so richtig zu meiner Konfiguration passt:

  • acme.sh ... --webroot scheitert, weil die API eine reine API ist und keine statischen Dateien ausliefert.
  • acme.sh ... --standalone scheitert, weil der bereits laufende Webserver Port 80 blockiert.
  • acme.sh ... --apache scheitert mit could not resolve api.example.com.well-known.

Die Lösung

Die Lösung besteht darin, die Apache-Proxy-Konfiguration dahingehend zu ändern, dass zusätzlich in einem Verzeichnis statische Dateien ausgeliefert werden dürfen. Dazu habe ich das neue Verzeichnis /var/www/acme-challenge eingerichtet:

mkdir /var/www/acme-challenge
chown www-data:www-data /var/www/acme-challenge/

Danach habe ich die Konfigurationsdatei für Apache umgebaut, so dass Anfragen an api.example.com/.well-known/acme-challenge mit statischen Dateien aus dem Verzeichnis /var/www/acme-challenge/.well-known/acme-challenge bedient werden:

# Apache-Konfiguration wie bisher
<VirtualHost *:443>
    ServerName api.example.com

    # SSL
    SSLEngine on
    SSLCertificateFile    /etc/acme-letsencrypt/api.example.com.pem
    SSLCertificateKeyFile /etc/acme-letsencrypt/api.example.com.key

    # Proxy: localhost:8880 <-> api.example.com
    ProxyPreserveHost On
    ProxyPass         / http://localhost:8880/
    ProxyPassReverse  / http://localhost:8880/

    # Logging Konfiguration ...
</VirtualHost>

# geändert: HTTP auf HTTPS umleiten, aber nicht
# für well-known-Verzeichnis
<VirtualHost *:80>
    ServerName api.example.com

    # Handle ACME challenges locally
    Alias /.well-known/acme-challenge /var/www/acme-challenge/.well-known/acme-challenge
    <Directory /var/www/acme-challenge/.well-known/acme-challenge>
        Require all granted
    </Directory>

    # Redirect everything EXCEPT ACME challenges to HTTPS
    RewriteEngine On
    RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/
    RewriteRule ^(.*)$ https://api.example.com$1 [R=301,L]
</VirtualHost>

Nach diesen Vorbereitungsarbeiten und mit systemctl reload apache2 gelingt nun endlich das Zertifikaterstellen und -erneuern mit dem --webroot-Verfahren. Dabei richtet acme.sh vorübergehend die Datei /var/www/acme-challenge/.well-known/acme-challenge/xxx ein und testet dann via HTTP (Port 80), ob die Datei gelesen werden kann.

# Zertifikat erstmalig erstellen
acme.sh --issue --server letsencrypt -d api.example.com --webroot /var/www/acme-challenge

# Zertifikat installieren und Renew-Prozess einrichten
acme.sh --install-cert -d api.example.com \
  --key-file /etc/acme-letsencrypt/api.example.com.key \
  --fullchain-file /etc/acme-letsencrypt/api.example.com.pem \
  --reloadcmd "service apache2 reload"

# Renew-Prozess testen
acme.sh --renew -d api.example.com --force

Traefik

Eine noch elegantere Lösung besteht darin, den Docker-Container mit Traefik zu kombinieren (siehe https://traefik.io/traefik/). Bei korrekter Konfiguration kümmert sich Traefik um alles, nicht nur um die Proxy-Funktionen sondern sogar um das Zertifikatsmanagment. Aber diese Lösung kommt nur in Frage, wenn auf dem Host nicht schon (wie in meinem Fall) ein Webserver läuft, der die Ports 80 und 443 blockiert.

Links / Quellen

Signal blockiert Microsofts “Recall”-Funktion aus Datenschutzgründen

Von: MK
26. Mai 2025 um 06:00

Die Chat-App Signal hat eine klare Haltung zur neuen “Recall”-Funktion in Windows 11 bezogen. Um automatische Screenshots privater Chats zu verhindern, greift Signal zu ungewöhnlichen Mitteln. Mithilfe von Windows’ Digital Rights Management (DRM) wird das Aufzeichnen der Signal-Fenster blockiert. Microsofts “Recall” erstellt regelmäßig Bildschirmaufnahmen, um Aktivitäten rückverfolgbar zu machen. Das Tool ignoriert zwar Inkognito-Browserfenster, doch […]

Der Beitrag Signal blockiert Microsofts “Recall”-Funktion aus Datenschutzgründen erschien zuerst auf fosstopia.

Linux-Server mit oder ohne Swap-Partition bereitstellen?

26. Mai 2025 um 05:00

Wir schreiben das Jahr 2025. Die Frage, ob man Linux-Server mit oder ohne Swap-Partition betreiben sollte, spaltet die Linux-Gemeinschaft in einer Weise, wie wir es seit dem Editor War nicht mehr gesehen haben…

So könnte ein spannender Film für Sysadmins anfangen, oder? Ich möchte aber keinen Streit vom Zaun brechen, sondern bin an euren Erfahrungen und Gedanken interessiert. Daher freue ich mich, wenn ihr euch die Zeit nehmt, folgende Fragen in den Kommentaren zu diesem Beitrag oder in einem eigenen Blogpost zu beantworten.

  • Stellt ihr Linux-Server mit Swap-Partition bereit und wie begründet ihr eure Entscheidung?
  • Hat euch die Swap-Partition bei sehr hoher Speicherlast schon mal die Haut bzw. Daten gerettet?
  • War der Server während des Swapping noch administrierbar? Falls ja, welche Hardware wurde für die Swap-Partition genutzt?

Eine kleine Mastodon-Umfrage lieferte bisher folgendes Bild:

Schaue ich mir meine eigenen Server an, so ergibt sich ein gemischtes Bild:

  • Debian mit LAMP-Stack und Containern: 16 GB RAM & kein Swap
  • RHEL-KVM-Hypervisor 1: 32 GB RAM & 4 GB Swap
  • RHEL-KVM-Hypervisor 2: 128 GB RAM & kein Swap
  • RHEL-Container-Host (VM): 4 GB RAM & 4 GB Swap

Bis auf den Container-Host handelt es sich um Bare-Metal-Server.

Ich kann mich nicht daran erinnern, dass jemals einem dieser Systeme der Hauptspeicher ausgegangen ist oder der Swapspeicher genutzt worden wäre. Ich erinnere mich, zweimal Swapping auf Kunden-Servern beobachtet zu haben. Die Auswirkungen waren wie folgt.

Im ersten Fall kamen noch SCSI-Festplatten im RAID zum Einsatz. Die Leistung des Gesamtsystems verschlechterte sich durch das Swapping so stark, dass bereitgestellten Dienste praktisch nicht mehr verfügbar waren. Nutzer erhielten Zeitüberschreitungen ihrer Anfragen, Sitzungen brachen ab und das System war nicht mehr administrierbar. Am Ende wurde der Reset-Schalter gedrückt. Das Problem wurde schlussendlich durch eine Vergrößerung des Hauptspeichers gelöst.

Im zweiten Fall, an den ich mich erinnere, führte ein für die Nacht geplanter Task zu einem erhöhten Speicherverbrauch. Hier hat Swapping zunächst geholfen. Tasks liefen zwar länger, wurden aber erfolgreich beendet und verwendeter Hauptspeicher wurde anschließend wieder freigegeben. Hier entstand erst ein Problem, als der Speicherbedarf größer wurde und die Swap-Partition zu klein war. So kam es zum Auftritt des Out-of-Memory-Killer, der mit einer faszinierenden Genauigkeit immer genau den Prozess abgeräumt hat, den man als Sysadmin gern behalten hätte. Auch hier wurde das Problem letztendlich durch eine Erweiterung des Hauptspeichers gelöst.

Ich erinnere mich auch noch an die ein oder andere Anwendung mit einem Speicherleck. Hier hat vorhandener Swap-Speicher das Leid jedoch lediglich kurz verzögert. Das Problem wurde entweder durch einen Bugfix oder den Wechsel der Anwendung behoben.

Nun bin ich auf eure Antworten und Erfahrungsberichte gespannt.

❌