[linux-l] Re: Debian testing

[Christoph Biedl]

Volker Grabsch wrote...

> Grundsätzlich werden Sicherheitslücken in den aktuellsten Versionen als
> erstes behoben, von den Autoren selbst. Da Unstable mit diesen Versionen
> Schritt hält, profitiert dies i.d.R. als erstes davon.
> (Wie immer gibt's natürlich auch Ausnahmen)

Da bin ich noch dabei.

> Extra Patches für Stable und Testing werden dann von den
> Paket-Maintainern bzw. einem Security-Team zusammengestellt. Dort will
> man ja die alte bewährte Version berbehalten, und kann daher nicht direkt
> auf die neuste Version hochgehen. Stattdessen picken sich die Maintainer
> die Security-Patches heraus und pflegen sie in die älteren Versionen
> ein.

Was testing angeht, kenne ich eher die Variante, daß über das ganz
normale Verfahren die Pakete früher oder später halt in testing
ankommen, und so als Nebeneffekt auch das Sicherheitsproblem
beseitigen.

(...)

> Das heißt also: Security-Fixes landen als erstes in Unstable, und
> gleichzeitig bis kurz danach kommt ein Fix für Stable. Eventuell auch
> einer für Testing.

Soweit die Theorie. Die (traurige) Realität der letzten Monate sieht
aber so aus, daß stable security noch länger braucht als die Migration
der Pakete von unstable nach testing. Wenn ich mir mal einige security
announces anschaue:

Package: xine-lib
CVE-2006-6172 assigned: 2006-11-30
Bereinigt in unstable:  2006-12-06 (1.1.2+dfsg-2)
Bereinigt in testing:   2006-12-14
Bereinigt in stable:    2006-12-28
http://www.debian.org/security/2006/dsa-1244
http://packages.qa.debian.org/x/xine-lib.html

Package: evince
CVE-2006-5864 assigned: 2006-11-10
Bereinigt in unstable:  2006-12-07 (0.4.0-3)
Bereinigt in testing:   2006-12-11 
Bereinigt in stable:    2006-12-28
http://www.debian.org/security/2006/dsa-1243
http://packages.qa.debian.org/e/evince.html

Package: clamav
CVE-2006-6406 assigned: 2006-12-09
CVE-2006-6481 assigned: 2006-12-11
Bereinigt in unstable:  2006-12-12 (0.88.7-1)
Bereinigt in testing:   2006-12-17
Bereinigt in stable:    2006-12-17
http://www.debian.org/security/2006/dsa-1238
http://packages.qa.debian.org/c/clamav.html

Package: links2
CVE-2006-5925 assigned: 2006-11-15
Bereinigt in unstable:  2006-11-30 (2.1pre26-1)
Bereinigt in testing:   2006-12-04 (als 2.1pre26-2)
Bereinigt in stable:    2006-12-21
http://www.debian.org/security/2006/dsa-1240
http://packages.qa.debian.org/l/links2.html

Package: asterisk
CVE-2006-5444 assigned: 2006-10-12
Bereinigt in unstable:  2006-10-25 (1.2.13~dfsg-1)
Bereinigt in testing:   2006-11-14 (als 1.2.13~dfsg-2)
Bereinigt in stable:    2006-12-06
http://www.debian.org/security/2006/dsa-1229
http://packages.qa.debian.org/a/asterisk.html


Ermittlung: In den jeweiligen DSA steht das Datum der
Veröffentlichung, das nehme ich als "bereinigt in stable"; außerdem
der Verweis auf CVE; nicht zuletzt die Version, mit der das in
unstable/testing gefixt wurde. Unter der zweiten Adresse bei
http://packages.qa.debian.org/<Paketname> findet man dann, wann diese
Versionen nach unstable und nach testing gekommen sind.

Jetzt noch die passenden Heise-Meldungen rauszusuchen ist mir zu
aufwendig, aber gefühlt kam es mehr als einmal vor, daß der Fix in
Debian /noch/ später kam als die Meldung dort. Und ich dachte immer,
es gäbe einen vertraulichen Kanal, über den Distributoren vorab über
Fixes informiert werden, damit sie zeitnah Fixes bereitstellen können?
Dann muß der bei Debian gründlich verstopft sein.

Ja, das ist übel. Ja, das sollte nicht so sein.

> So gesehen ist Unstable am "aktuellsten", aus den oben genannten Gründen
> ist dennoch Stable als sicherer anzusehen.

Nuja, sicherer nicht unbedingt, aber halt - ähm - stabiler.

[ was tun? ]

Es gibt hier keinen goldenen Weg. 

Die security announcements mitzunehmen ist auf jeden Fall eine gute
Idee.

Wer kritische Software(*) einsetzt und damit Dienste gegen unsichere
Netze (also "nach außen") oder für begrenzt vertrauenswürdige Nutzer
anbietet und/oder aufgrund seiner Stellung (man denke sich ein
größeres community-Portal) ein gewisses Risiko eines gezielten
Angriffs ist - der sollte sich auf keinen Fall auf die
Debian-Mechanismen der security updates verlassen. Deren Reaktionszeit
ist einfach zu langsam. In so einer Stellung ist aber Mitlesen der
einschlägigen Mailinglisten sowieso Pflicht.

(*) hierzu sollte man ehrlicherweise auch PHP zählen.

Eher würde ich also, ganz entgegen Deiner Meinung, ein System mit
testing betreiben, weil mir das eine gewisse Grundstabilität sichert,
zumindest die meiste Zeit. Gleichzeitig muß ich ein Auge auf unstable
behalten, falls dort eine neue Version kommt und das changelog
einen security fix erwähnt (was ich eigentlich schon vorher wissen
sollte).

Entweder kann ich dann die Version aus unstable direkt installieren
und bin glücklich; oder ich kann, weil der Unterschied selten
besonders groß sein dürfte, selber mit dem Patch einen backport bauen.
Ja, das artet schnell in Arbeit aus. Vor allem, weil schon jedes(!)
normale Update die Stabilität zerreißen kann; ein Testsystem und
Experimentierfreude gehören also zur Grundausstattung.

Glücklich der, dessen Software keine große Weiterentwicklung mehr
erlebt. Dann kann man auch noch selber die Patches nach stable
bringen.

    Christoph

PS: Ups, diese Mail startete als Kritik am Debian security team und am
    Schluß war's dann ein "Am besten machst Du gleich alles selber"
    geworden. Über die allmähliche Verfertigung der Gedanken beim
    Red^H^H^HSchreiben.