Beiträge von lush

[Blockierte Grafik: http://www.pro-linux.de/images/NB3/imgdb/n_gnome-shell-mit-starter-und-suche.jpg]
Wer Gnome 3.6 schon jetzt ausprobieren will, findet den Quellcode der Betaversion (3.5.90) auf dem FTP-Server des Gnome-Projektes. Binärpakete gibt es keine. Laut Änderungsprotokoll
besitzt die auf dem FTP-Server verfügbare Version 3.5.90 bereits
sämtliche Funktionen der kommenden Gnome-Version. Das Team kümmert sich
jetzt nur noch um das Beseitigen von Fehlern.Gnome 3.6 soll
unter anderem eine bessere Übersicht der Apps ermöglichen. Ferner wurde
das Benachrichtigungssystem verbessert und am GTK-Aussehen gefeilt.
Weitere Verbesserungen betreffen das Sperren des Bildschirms. Das
Wiederherstellen des Instant Messengers wartet jetzt so lange, bis
sämtliche Netzwerkverbindungen wieder hergestellt wurden.
Die Fedora-Entwickler haben bereits bekannt gegeben,
dass Gnome 3.6 in Fedora 18 (Spherical Cow) enthalten sein wird. Andere
Distributionen wie Ubuntu stehen zumindest der in Gnome 3.6 enthaltenen
Nautilus-Version aufgrund dessen erneut reduzierten Funktionsumfangs
ablehnend gegenüber und planen Gnome 3.6 mit Nautilus 3.4 auszuliefern.

LibreOffice 3.5

Zum sechsten Mal seit der Freigabe von LibreOffice 3.5 hat The Document Foundation
(TDF) ein Update der freien Office-Suite für Linux, Mac OS X und
Windows veröffentlicht. Nachdem inzwischen bereits die Nachfolgeversion
3.6 erschienen ist, ist die parallel gepflegte Version 3.5 laut der Document Foundation für »konservativere Anwender« gedacht.LibreOffice
3.5.6 behebt eine Reihe von Fehlern und verbessert darüber hinaus die
Stabilität der Suite. Die vollständige Liste von Korrekturen kann man
den Änderungslogs der zwei Veröffentlichungskandidaten (RC1 und RC2) entnehmen. Neue Funktionen wurden nicht hinzugefügt.
LibreOffice 3.5.6 ist in zahlreichen Sprachen verfügbar. Die aktualisierte Version ist auf den Webseiten des Projektes unter de.libreoffice.org zu finden.
Neben der Softwareentwicklung laufen auch die Vorbereitungen zur LibreOffice-Konferenz,
die vom 17. bis 19. Oktober in Berlin stattfindet. Der Call for Papers
wurde um eine Woche verlängert läuft noch bis einschließlich 22. August.
Das Programm ist daher noch nicht verfügbar. Die Konferenz findet im Konferenzzentrum des Bundesministeriums für Wirtschaft und Technologie in Berlin-Mitte statt.
Für die LibreOffice-Konferenz 2013 wurde jetzt bereits die Suche nach einem Veranstaltungsort
begonnen. Die Konferenz soll zwischen September und November 2013
stattfinden, bevorzugt im Oktober. Bewerbungen können bis zum 15.
Oktober 2012 eingereicht werden.

[Blockierte Grafik: http://www.pro-linux.de/images/NB3/imgdb/n_opensuse-logo.jpg]

Der Suse-Mitarbeiter Olaf Kirch
erläutert den derzeitigen Stand der Diskussion der Nürnberger zum Thema
UEFI Secure Boot in einen ausführlichen Blog-Eintrag. Darin spricht
Kirch zunächst allgemein über mögliche Probleme, die sich für
Linux-Distributoren im Zusammenhang mit UEFI-Secure-Boot ergeben, und
stellt dann die von Suse für seine Unternehmensprodukte favorisierte
Lösung vor.Die sieht ebenfalls den Einsatz des von Matthew
Garret von Red Hat entwickelten Bootloaders Shim vor, der aller
Voraussicht nach über eine Microsoft-Signatur verfügen wird. Das weitere
Vorgehen bei Suse unterscheidet sich jedoch in einigen Punkten von
Fedoras Plan und trägt in einigen Details auch Züge der von Canonical
für Ubuntu geplanten Lösung. Was das bedeutet erläutert der
Suse-Entwickler Vojtěch Pavlík in einem weiteren Blog-Eintrag.
Zwar
will auch Suse den von Garret entwickelten Mini-Boot-Loader Shim
einsetzen, der soll aber in zwei Versionen beiliegen, einmal mit
Microsoft-Schlüssel signiert und einmal mit einer Signatur von Suse,
womit die Strategie auch Züge der von Canoncial favorisierten Lösung
trägt, denn Ubuntu will künftig ebenfalls einen eigenen, selbst
signierten Boot-Loader mitliefern. Die Shim-Variante von Suse mit
eigener Signatur wird bei Hardware mit UEFI-Firmware und eingeschaltetem
Secure Boot nur booten, wenn in der Firmware ein öffentlicher Schlüssel
hinterlegt ist, der die Signatur von Suse verifiziert. Im Unterschied
zu Fedoras Lösung erweitert Suse Shim derart, dass der die öffentlichen
Schlüssel zum Verifizieren von Kernel und Grub in separaten Dateien
ablegt, während Fedoras Shim diese Schlüssel in der Binärdatei enthält,
was das Hinzufügen weiterer Schlüssel ohne Neuübersetzen und Signieren
von Shim verhindert. Suse nennt seine in Dateiform gespeicherten
öffentliche Schlüssel MOKs (Machine Owner Keys). Damit Shim unerlaubte
Modifikationen erkennen kann, soll der Hash-Wert der Datei in einer
sogenannten »Boot Services Only Variable« von UEFI gesichert sein,
welche die UEFI-Spezifikationen neben »Authenticated Variables«
ebenfalls vorsehen. Im weiteren Verlauf gleicht die sichere Boot-Kette
wieder dem Fedora-Verfahren, bei dem Shim den eigentlichen Boot-Loader
Grub2 nachlädt und ausführt, sofern dieser vertrauenswürdig ist, was
Shim wiederum einem der hinterlegten MOKs entnimmt, die Shim an Grub
übergibt. Damit kann Grub seinerseits prüfen, ob der ausgewählte Kernel
vertrauenswürdig ist, und diesen dann starten.
Suses Verfahren
erlaubt auf einfache Weise das Starten selbst signierter Kernel via
Secure Boot, weil der zugehörige Schlüssel nur bei Shim hinterlegt sein
muss, während bei Fedoras Verfahren auch Shim und Grub mit privaten
Schlüsseln signiert und die zugehörigen öffentlichen Schlüssel in der
UEFI-Firmware hinterlegt sein müssen. Pavlík räumt zwar ein, dass sein
Verfahren auf dem ersten Blick den UEFI-Spezifikationen sowie den
Windows-8-Logo-Anforderungen zu widersprechen scheint, dass es die UEFI
Spezifikationen aber erlauben, wenn auch nicht zwingend verlangen, dass
eine UEFI-Implementation benutzerautorisierten EFI-Code mit »ungültiger«
Signatur mit einem Datei-basierten Schlüssel verifiziert, dessen
Hash-Wert in einer Boot Services Only Variable gespeichert ist. Sogar
Garret selbst hat sich inzwischen in seinem Blog anerkennend zu Pavlíks Vorschlag geäußert und kann sich vorstellen, die Lösung auch für Fedora zu übernehmen.
Laut
Olaf Kirch steht im Moment jedoch lediglich die Überlegung im Raum, die
von Pavlík aufgezeigte Lösung für Suse Linux Enterprise 11 Service Pack
3 bei einer Neuinstallation auf Geräten mit Secure-Boot anzubieten.
Weitere Details und konkrete Pläne will Kirch erst in den kommenden
Tagen in Form weiterer Blog-Einträge rund um das UEFI-Secure-Boot
diskutieren und vervollständigen. Das gibt auch der
Opensuse-Gemeinschaft die Möglichkeit, über den Vorschlag für ihre
eigene Distribution nachzudenken, denn beim Opensuse-Projekt ist in
dieser Frage bisher noch keine Entscheidung gefallen.