Fedora hat jetzt ein Security Team

Eric H. Christensen hat heute offiziell das neu gegründete Fedora Security Team auf der Devel-Announce-Liste vorgestellt.

Hauptaufgabe des Teams soll es sein, Paketbetreuer bei der Behebung von Sicherheitsproblemen zu helfen. So kann das Team z.B. dem Upstream eines Paketes dabei helfen, einen Patch für das Problem zu entwickeln oder ein neues Release, welches das Problem beseitigt, bereitzustellen. Anschließend soll das Team dann mit dem Paketbetreuer zusammen daran arbeiten, möglichst schnell aktualisierte Pakete bereitzustellen.

Nach Aussage von Christensen verfügt das Security Team bereits über 20 Mitglieder. Mit der heutigen Ankündigung stehen interessierten jedoch die Türen für die Mitarbeit im Security Team von Fedora offen.

IMHO: Fedora (Desktop) als rolling-release?

IMHO ist der Kommentar von Fedora-Blog.de.
IMHO = In My Humble Opinion (Meiner bescheidenen Meinung nach).

Warum denn nicht?!?

Mit Fedora.next wird Fedora bekanntlich in die 3 “Produkte” Desktop, Server und Cloud aufgeteilt und jedes dieser Produkte kann eigene Release-Zyklen haben.

Und wenn man ehrlich ist, ist Fedora bereits mehr oder weniger ein Semi-Rolling-Release, da Komponenten wie z.B. der Kernel oder PulseAudio auch innerhalb des Releases auf die jeweils aktuellen Releases aktualisiert werden.

Vor diesem Hintergrund finde ich, das man den Gedanken, zumindest das Desktop-Produkt von Fedora auf ein Rolling-Release umzustellen, ruhig mal völlig unvoreingenommen diskutieren sollte. Zumal zu erwarten ist, das Fedora Server und Cloud über kurz oder lang von Fedora Desktop abweichende Release-Zyklen bekommen werden. Oder welcher Admin ist so wahnsinnig und macht alle 6 Monate ein Upgrade seiner Server auf die aktuelle Fedora Version? ;-)

Würde man Fedora Desktop auf ein rolling-release umstellen, würde man damit auch gleichzeitig einiges an Ressourcen in der Qualitätssicherung freimachen und könnte diese freien Ressourcen dann für die QA von Cloud und Server verwenden. Die QA von Fedora Desktop würde sich dann nur noch darauf beschränken, die regelmäßig (alle 6 Monate?) aktualisierten Installationsmedien zu überprüfen, welche dann auf Basis der Stable- und Updates-Repositories erzeugt werden.

Konkret könnte ein Rolling-Release von Fedora Desktop dann so aussehen, das Rawhide als so etwas wie Debian-Unstable fungiert, wo neue Pakete oder größere Upgrades (z.B. Gnome 3.12 -> 3.14) lagern, bis sie stabil genug für Updaes-Testing sind und dann entweder nach einer gewissen Zeit oder aufgrund vorher definierter Kriterien weiter nach Updates-Testing und von dort wie bislang auch in das Updates-Repository wandern.

Das bislang für neue Releases notwendige Branchen und der damit verbundene QA-Aufwand würde somit, wie bereits erwähnt. zumindest für das Desktop-Produkt entfallen, da Fedora Desktop Releases im Grunde nur noch Snapshots des Stable- und Updates-Repositories sind, die dementsprechend weniger QA-Aufwand erfordern.

Abschließend noch eine kleine Umfrage:

Sollte eine Umstellung von Fedora Desktop auf rolling-releases zumindest ergebnisoffen diskutiert werden?

Ergebnis anzeigen

Loading ... Loading ...
Sicherlich gäbe es noch einige andere Gründe, die für ein rolling-release von Fedora Desktop sprechen, aber es würde sicher den Umfang diese Beitrages sprengen, wenn hier auf jedes mögliche Argument eingegangen wird. Wenn Ihr jedoch noch einige Argumente für (oder gegen) ein rolling-release von Fedora Desktop habt, schreibt sie doch einfach in die Kommentare.

dnf bekommt protected_packages Plugin

Die kommende Version 0.5.3 von Fedoras zukünftigem Paketmanager dnf wird im dnf-plugnis-core Paket ein protected_packages Plugin mitbringen. Dieses Plugin wird u.a. verhindern, das man den aktuell gebooteten Kernel deinstalliert und seinem System dadurch den Todesstoß verpasst.

dnf: Metadaten vor jedem Update auffrischen

Dnf verfügt seit Version 0.5.2 über einen neuen Parameter –refresh, der die lokal gespeicherten Metadaten aktualisiert, sofern sie nicht mehr aktuell sind.

Wer also mit folgendem Befehl nach neuen Updates sucht, kann davon ausgehen, das immer die aktuellen Metadaten verwendet werden

su -c'dnf update --refresh'

Somit erspart man sich dank dieses sinnvollen Parameters den Aufruf von

su -c'dnf clean all'

vor jedem Update sowie den damit verbundenen kompletten Download aller Metadaten.

Gnome kann sich nicht mehr mit Facebook verbinden

Wer seit kurzem versucht, eine Verbindung mit Facebook in den Gnome-Online-Accounts (GOA) einzurichten, bekommt nur noch die Meldung

Fehler beim Zugriff auf die App
Leider wurde die App, die du verwenden willst, deaktiviert oder sie existiert nicht.

zu sehen.

Auf Seiten des Gnome-Projektes rätselt man noch, warum die Facebook-App nicht mehr vorhanden ist. Möglicherweise hängt es damit zusammen, das Facebook seine Unterstützung für Chats über XMPP demnächst einstellen will.

dnf bekommt autoremove Feature

Der zukünftige Standard-Paketmanager von Fedora bekommt mit Version 0.5.2, die sich bereits im updates-testing Repository befindet, ein autoremove Feature, das sich an dem gleichnamigen Feature von apt-get orientiert und im Gegensatz zum (undokumentierten) autoremove Feature von yum dokumentiert wird.

Ab dnf 0.5.2 ist es somit möglich, mittels

su -c'dnf autoerase'

alle Pakete, die als Abhängigkeit installiert wurden, aber zwischenzeitlich von keinem anderen Paket mehr benötigt werden, aus dem System zu entfernen.

Dieses Feature dürfte jedoch nur für die Leute interessant sein, die keinen

clean_requirements_on_remove=true

Eintrag in ihrer dnf.conf stehen haben, da dieser im Grunde die selbe Funktion hat, wie die autoerase Funktion. Der einzige Unterschied zwischen den beiden Möglichkeiten dürfte sein, das clean_requirements_on_remove automatisch ausgeführt wird, sobald Pakete aus dem System entfernt werden.

Gnome Terminal kann wieder Transparenz

Wie Debarshi Ray in seinem Blog berichtet, verfügen die Gnome-Terminal Pakete aus dem Gnome 3.12 COPR ab sofort über einen Patch, der das in Gnome 3.08 entfernte Transparenz-Feature zurückbringt.

Ray weißt jedoch auch darauf hin, das es sich hierbei um einen Downstream-Patch handelt, da der Patch vom Gnome Terminal Entwickler abgelehnt wurde. Ferner gibt es momentan noch einen Bug in Adwaita, der dafür sorgt, das auch die Menüleiste transparent dargestellt wird, sobald die Transparenz aktiviert wurde. Ray hofft jedoch, das der Bug bald gefixt ist.