Problem s udrzovanim programu v base

[Dan Lukes]

Tyman Vladimir wrote, On 02/18/03 21:16:
>> Treba to, kdo to udela a dedictvi z historie prekroci. Vyjmuti openssl
>> ze zakladniho systemu by si vynutilo vyjmuti nebo prekopani i dalsich
>> veci, coz by mohlo treba skoncit tak, ze by se v zakladnim systemu nedalo
>> ani prihlasit na konzoli. Takze pokud se s tim jednou zacne, bude to
> 
> Co takhle ten kdo to openssl do base "zakopal" takovym zpusobem, ze se bez nej
> nejde prihlasit na konzoli. IMHO si myslim, ze se i bez openssl na konsoli 
> prihlasim :-)

	To vite - openssl je pomerne dobre a rozsahle kryptograficke dilo, 
takze pokud v jadre potrebujete nejakou kryptografii (napriklad IPSEC) 
tak si muzete prislusnou  kryptografii bud' vyvinou separatne sam, nebo 
pouzit openssl. Prvni je mozna zbytecne casove narocne, to druhe zase 
znamena zavislost na kodu onoho ciziho baliku - ktery se tim de-facto 
stava zakladni soucasti systemu (a tedy nikoliv jen externim third-party 
programem - portem).

	Obdobne je to i v nekterych dalsich pripadech - zminovan byl napriklad 
perl, ktery je integralni soucasti zase tim, ze se pri generovani 
systemu dosud pouziva, takze bez nej nelze funkcni system zkompilovat.

	V pripade perlu se nakonec takove zavisloti zbavit podari, proste tim, 
ze se prestane pouzivat, v priopade openssl ale muze byt stejny postup 
natolik neefektivni, ze se to proste nevyplati.


	Mimochodem, rad bych zminil, ze me nemoznost upgrade na aktualni verzi 
vetsinou nepripada jako nijak zvlastni omezeni, a to se povazuji za 
pomerne intenzivniho uzivatele vcetne nekterych pomerne kritickych 
komercnich nasazeni tohoto systemu - opravy bezpecnostnich chyb jsou 
obvykle k dispozici formou patchu (nebo pres cvsup) tak jako tak a co se 
tyce nejakych novych funkci, ty jen velice vyjimecne byvaji natolik 
nepostradatelne, aby se kvuli nim vyplatilo provadet nejake harakiry a 
ohrozovat stabilitu vysledneho systemu, i kdyz nevylucuji, ze ve 
vyjimecnych pripadech to muze byt jinak (napriklad pokud jste vlastnikem 
hardwaroveho kryptografickeho zarizeni, pak patrne budete chtit provest 
upgrade na posleni openssl). Co nejrychlejsi zahrnovani nejnovejsich 
verzi cehokoliv do stabilniho systemu je spis hrozba nez vyhoda ...

	Celkove bych skoro rekl, ze nahrazovat klicove komponenty systemu (a 
zrovna openssl je pomerne dost klicova komponenta) je vhodne jen z 
vaznych duvodu a po peclivem posouzeni moznych dopadu - a pro cloveka, 
ktery je schopen takoveho posouzeni patrne nebude problem upgrade 
provest - kterymkoli z nekolika moznych zpusobu. Ostatnim nelze takove 
vymeny doporucit - ti by meli spise pockat na pristi verzi ...

	Nerikam, ze to neni vec, kterou by nebylo dobre v budoucnosti menit - 
rikam, ze fakticke dopady toho, ze nektere komponenty nelze samozstatne 
ugradovat povazuji za spise zanedbatelne a z toho odvozuji zavaznost a 
prioritu reseni tohoto problemu ...

	Nicemu, co jsem rekl, nebudiz rozumeno tak, ze by nekdo jiny nemohl mit 
na vec nazor jiny ...

>> zasadni bezpecnostni diru. Pokud tato situace nastane a nova verze FreeBSD
>> jeste neni v planu, vyda se nove CD s meziverzi, aby existovala alespon
>> jedna zakladni instalace systemu na CD takova, ktera neobsahuje takovouto
>> bezpecnostni diru. Tj. jedna se o politiku vytvareni verzi, aby existovala
>> zakladni instalace systemu bez der, ktera s problemem upgrade zakladniho
>> systemu nesouvisi.
> 
> 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)?

	Jen pro presnost, release jdou v prumeru prave po trech mesicich. 
Nebudeme si zastirat, ze to je prevazne z ekonomickych duvodu 
souvisejicich se zasilanim subscription CD ...

	Ze stejneho duvodu patrne 4.6 vysla v dobe, kdy patrne nebyla release 
zcela pripravena ...

>> Misto upgrade baliku se pro aktualizaci systemovych casti vydavaji
>> pokyny, jake prikazy je potreba udelat (patch, cd, make...), aby se
>> dotycne casti aktualizovaly. Pro nekoho to problem urcite je, tomu
>> bych se az tak moc nedivil. Byly i pokusy s binarnimi upgrady casti
>> systemu, ale skoncily opet na nedostatku lidskych zdroju.
> 
> Tim se alespon v pripade chyb v knihovnach stejne nevyhnu prekladu/instalaci celeho 
> systemu a hlavne naslednemu restartu. Kdyz uz tohle musim podstoupit tak je urcite 
> lepsi updatovat cely system pres cvsup na stable. Otazka byla proc musim toto
> delat pri chybe v openssh.

	Protoze tato knihovna muze byt staticky prilinkovana k nekterym castem 
systemu - nahrazeni zdrojovych kodu bez rekompilace systemu tedy problem 
neodstrani. I dynamicky linkovanych komponent neni upgrade bez 
rekompilace bezpecna "automaticky" - jen kdyz  se rozhrani a logika kodu 
nezmenila prilis (coz obvykle nehrozi, pokud se jen opravovala chyba - 
takze se to tyka zejmena skutecnych upgrade)...

>> Vubec mi neni jasne, co si predstavujete pod pojmem
>> "priorita/podpora"? Pokud nekdo chce neco skutecne udelat,
> 
> 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.

	:-)

	No, a z ceho usuzujete, ze vas nazor, ze by si problem zasluhoval vetsi 
pozornost neni mensinovy, kdyz jak sam rikate, venuje se mu jen malo 
lidi a jeste ne prilis aktivne ... ? ;-)


					Dan

-- 
Dan Lukes     tel: +420 2 21914205, fax: +420 2 21914206
root of  FIONet, KolejNET,  webmaster  of www.freebsd.cz
AKA: dan at obluda.cz, dan at freebsd.cz,dan at kolej.mff.cuni.cz