staging.inyokaproject.org

Kurz die Vorgeschichte: Das Spiel defendguin funktioniert in intrepid nicht richtig, wenn man die binär-Pakete von Ubuntu verwendet. Kompiliere ich das Paket allerdings selbst, funktioniert es einwandfrei, ohne dass sich der Quellcode geändert hat.

Zwei Fehlerberichte gibt es zu dem Paket, beide wurden als Duplikat von Fehler #267265 markiert. Dieser ist aber non-public.

Es macht auf mich den Anschein, dass der Fehler in der Build-Infrastruktur (gcc, bibliotheken, Canonical-Build-Server??) gelegen hat. Das Paket wurde auch in den letzten Monaten offenbar nicht neu kompiliert.

Jetzt stellen sich mir ein paar Fragen:

Werden die Debian-Import bis zum Release noch einmal kompiliert?

Warum ist das geheim? Wie viele Fehlerberichte sind eigentlich geheim? Gibt es da eine Regel, welche Bugs auf non-public gestellt werden?

Irgendwie finde ich so etwas keine gute Informationspolitik. Was meint ihr?

Insbesondere lässt das bei so einem intransparenten Fehler, der ohne Quellcode-Änderung wieder verschwindet ein schlechtes Gefühl und Platz für jede Menge Theorien.

Prinzipiell werden seitens des Kernel alle Bugs die Sicherheitskritisch sind und für einen Angriff auf das System verwendet werden könnten nicht komuniziert, bis sie behoben wurden.

Das ist meines Erachtens eine gute Handhabung die letztlich der Sicherheit von Linux dient und die ein Aushebeln der ansonsten guten Informationspolitik rechtfertigt.

Ob das in diesem Fall wirklich so ist, kann ich selbstverfreilich nicht mit Sicherheit sagen.

Ein Kernel-Bug kann es in diesem Fall eigentlich nicht sein. Kompiliere ich das Paket aus der gleichen Quelle heute neu, erhalte ich auf dem gleichen Kernel eine funktionsfähige Version.

Könnte vielleicht was hiermit zu tun haben: http://ikhaya.ubuntuusers.de/2008/10/19/ubuntu-intrepid-kommt-mit-mehr-code-sicherheit...

Ja, dachte ich jetzt auch erst. Aber diese Sicherheitsfunktion soll ja nur zu Compile-Zeit eine Warnung ausgeben. Außerdem bestand das Problem bereits im Juni. Da wurde das Paket nämlich gebaut.

Wenn zu dem Zeitpunkt ein Problem mit der Build-Infrastruktur bestand, müssten die Pakete, die seit dem nicht verändert wurden, neu gebaut werden und eine neue Versionsnummer bekommen, oder?