Názor k článku
Linuxové jádro končí se šestiletou podporou LTS, je s ní příliš mnoho práce od Filip Jirsák - Problém je, že asi nevíte, co se očekává...

Problém je, že asi nevíte, co se očekává od bezpečnostních oprav. Od bezpečnostních oprav se očekává, že že chybu opraví skoro vždy. To by ale ti vaši fulltime zaměstnanci komerčních firem museli pokrývat všechny bezpečnostní patche. Jakmile ale bezpečnostní patche do nějaké nezanedbatelné míry vyrábí i méně zkušení lidé, najednou nemůžete vědět, zda opravu té chyby, která vás zajímá, dělal někdo zkušený nebo nezkušený. Takže se na ty opravy nemůžete spolehnout.

No a pro pochopení spousty bezpečnostních oprav opravdu nestačí umět číst kód. To platí pro nějaké jednoduché chyby typu buffer overflow, ale když je ta chyba někde ve špatně navrženém procesu, ve špatném časování apod., opravdu nestačí umět číst zdrojový kód.

„Backport bezpečnostní chyby“ v distribuci také může vypadat tak, že maintainer aplikuje na předchozí verzi patch, který označuje nezabezpečenou metodu jako zastaralou a v dokumentaci uvádí, že se místo ní má používat nová metoda. Tato metoda je zavedena tím stejným patchem, a má (logicky) nové rozhraní, tj. není součástí API ani ABI té předchozí „patchované“ verze. Takže jsou tam dokonce dva důvody, proč se dál bude volat ta stará nebezpečná metoda – ale to je maintainerovi jedno, on si udělá čárku, že backportoval bezpečnostní opravu. Ano, tenhle konkrétní příklad je z Debianu, takže je to trochu specifické –ale jak jako koncový uživatel distribuce poznáte, který backport bezpečnostní opravy dělal někdo příčetný a který byl udělá jenom pro tu čárku?