Problem s udrzovanim programu v base

[Cejka Rudolf]

Tyman Vladimir wrote (2003/02/18):
> To je jasne. Myslim, ze se snad shodneme na tom, ze:

Ano, ale jeste bych doplnil jeden bod: Nedostatky jsou zname i u ostatnich
zpusobu aktualizaci a neni vubec jednoduche rozhodnout, co je lepsi, a jeste
obtiznejsi je najit novy zpusob aktualizaci bez znamych nedostatku.

> Co kdyz se bezpecnostni dira objevi tak 3 mesice po vydani release (v prumeru 
> jdou release po pul roce). Bude se take v tom pripade delat release
> (pochybuji)?

Urcite ne. Jeste jednou zopakuji: Je snaha, aby existovala alespon jedna
instalace systemu, ktera v zakladni instalaci neobsahuje vyznamnou
bezpecnostni diru, tj. aby se nestavalo jako u jinych operacnich systemu,
ze jeste nez administrator staci hned po instalaci nejzakladnejsich
komponent opravit bezpecnostni diry, uz mu pocitac nekdo prolomi.

Nove verze jsou tak jednou za 3 az 4 mesice, takze pokud by cela nova
release mela vyjit driv nebo hodne podobne jako opravena predchozi
release, udela se rovnou cela nova release.

> Znamena to tedy, ze release by mel byt bez bezpecnostnich chyb (to
> bude tezko splnitelne)?

Pro aktualne posledni release a zakladni instalaci bez pridanych
baliku skutecne ano.

> Kdo urcuje, ktera chyba je zavazna tak aby se musel vydat release?

Relase tym.

> Pokud by k vyskytu tech chyb doslo tak o mesic pozdeji tak by zadny
> release nebyl a vyresilo by se to SA.

Rozhodovala by zavaznost problemu. U lokalnich exploitu by to urcite
skoncilo jen SA, ale u remote exploitu spis nova CD.

> Proc si proste nepriznat fakt, ze z hlediska vyskytu 
> zavaznych bezpecnostnich der vysla 4.6 v ten nejnevhodnejsi okamzik

Jo, to je pravda. O prazninach je to s nalezenymi bezpecnostnimi
dirami vzdycky nejhorsi. Jenze co s tim? V lete ma asi proste
moc lidi moc casu a tak hledaji a hledaji, az najdou.

> Ja jsem jen chtel poukazat na fakt,
> ze stavajici system pridelava praci i tem kdo napr. na te 4.6.1-2 delali.

Prekladovy system je udelany tak, ze v podstate jen otagovali zdrojove
kody a prislusny snapshot zverejnili jako 4.6.1/4.6.2. Prace bylo radove
min (vzdyt snapshoty se pro i386 ostatne delaji automaticky kazdy den),
nez prace na novem release. Vsechno souvisi se vsim - diky plne
automatizovanosti prekladoveho systemu jsou takoveto release bez
problemu, ale na druhou stranu je obtizne tento prekladovy system zmenit
tak, aby se zachovaly soucasne vyhody a odstranily soucasne nedostatky.

> Tim se alespon v pripade chyb v knihovnach stejne nevyhnu
> prekladu/instalaci celeho systemu a hlavne naslednemu restartu.

Zalezi na situaci. OpenSSL a kryptokod jsou opravdu velmi provazane
veci a neni to tak, ze by ho po padu patentu nekdo do systemu vnucoval.
SSL bylo v systemu i v dobe existence patentu, jen Amerika a zbytek
sveta museli instalovat neco jineho.

> Otazka byla proc musim toto delat pri chybe v openssh.

Treba ne, treba jen stacilo, aby nekdo venoval vic casu zjisteni,
co vsechno se musi upgradovat.

> Pokud jste to pochopil jako napadani tak to doslo k nedorozumeni a 
> at ctu svuj puvodni mail jak ctu tak tam nevidim, ze bych nekoho/neco
> obvinoval z male snahy nebo maleho vysledneho efektu. 

Fajn, e-mailovy sum.

> Je to jasne pri pohledu na archiv maillistu libh - pocet zprav ani pocet
> prispevovatelu neni urcite takovy jaky by si vec, ktera bude znamenat velky
> zasah do systemu zasluhovala.

Coz neni o neochote vyvojaru projektu, ale o dalsich lidech, kteri bud
nejsou schopni takove veci zvladat a delat, nebo nechteji prilozit ruku
k dilu. A o tom to vsechno je. A na tom konci ne jen veci ve FreeBSD,
ale i spousta aktivit okolo Linuxu. Tak, hotovka ;-) 

-- 
Rudolf Cejka <cejkar at fit.vutbr.cz> http://www.fit.vutbr.cz/~cejkar
Brno University of Technology, Faculty of Information Technology
Bozetechova 2, 612 66  Brno, Czech Republic