Vlákno názorů k článku
Greg Kroah-Hartman odmítl omluvu studentů Minnesotské university od Lael Ophir - To že do open source může přispět kdokoliv,...

Vy se pořád soustřeďujete na rozlišování toho, zda chyby vznikla náhodně (co to je?), zanedbáním nebo záměrně. Za prvé se to ale rozlišit nedá, maximálně se můžete dohadovat, zda to byl víc záměr nebo jen nepozornost. Za druhé je to rozlišování k ničemu. Když ta chyba v kódu je, škodí úplně stejně bez ohledu na to, jakým způsobem vznikla.

K čemu tedy podle vás je potřeba ten větší vhled do problému? Co by se dělo jinak, pokud byste uměl rozlišit, které chyby byly záměrné a které byly nedbalost? Když najdete chybu, která vznikla nedbalostí, tak ji ve zdrojáku necháte? To asi ne, že… Takže jediné řešení je umět najít co nejvíc chyb co nejdříve. A k tomu vůbec nepotřebujete vědět, zda ta chyba vznikla úmyslně nebo omylem.

@Filip Jirsák

Moc to zjednodušujete.

Náhodnému vnosu chyby nezabráníte - to může být neznalostí, nepozorností, nebo třeba i překlepem.

Zanedbání je trochu jiná kategorie. Na projektu máte určitá pravidla, která se nedají rozumně automaticky kontrolovat a je z velké části na důvěře, že je vývojář dodržuje. Je však dobré umět ověřit a odhadovat, jestli některá ze zásad nečiní v praxi problémy. Pokud ano, lze upravit pravidla, nebo přemýšlet o možnostech kontroly (automatické, periodické, ...).

Záměrná chyba se technicky neliší (jak píšete: chyba jako chyba), ale liší se motivací.

U náhodně vnesené chyby neočekáváte, že by byla nějak důmyslně skrývaná. U zanedbání to nebude časté, ale někdy se stane, že si vývojář chce systematicky ulehčit práci a tak svoji nedůslednost trochu maskuje. U záměrně vnesených chyb však musíte očekávat, že mohou být odhalitelné nejobtížněji. Může jít například o kombinaci nenápadně vypadajících chyb, každá na jiném místě, a jako celek dávají smysl jen tomu, kdo je vytvořil.

Zájem by měl být v tom, umět to rozlišit (pochopitelně to nepůjde přesně). Podle toho pak lze rizika zhodnotit a přemýšlet nad způsoby prevence. Na nedbalé lajdáky může např. fungovat reputace a tomu odpovídající řetězec kontrol. Na záměrné kombinované chyby může třeba pomoci heuristika nad zaměřením, tempem a rozsetím vývoje. -- to jen tak, co mě projde hlavou, za to mě nechytejte za slovo, jsou to fakt jen příklady.

K čemu tedy podle vás je potřeba ten větší vhled do problému? Co by se dělo jinak, pokud byste uměl rozlišit, které chyby byly záměrné a které byly nedbalost? Když najdete chybu, která vznikla nedbalostí, tak ji ve zdrojáku necháte?

Samozřejmě, že tam chybu nechcete, bez ohledu na to, pod jakou motivací vznikla. Vhled do problému by mohl přinést lepší možnosti prevence. Vědět, jaké části kódu mají projít hlubší revizí, jaké přispěvatele je potřeba kontrolovat pravidelně a jaké jen namátkově. Nastavit plochá pravidla fungovalo v době, kdy k Linuxu (ale netýká se to jen něj) přicházeli jen nadšenci se svými konkrétními místními cíli. Jeden potřeboval podporu určitého hardwaru, druhý hledal možnosti zpracování síťového provozu, třetí potřeboval ovládat parametry výkonu. Dnes se v projektech sbíhají i komerční zájmy firem, které zastřešují zájmy svých zákazníků podle vlastních představ. Přispívají organizace, na které mají nutně vliv vlády jejich zemí. Kyberzločin se stal extrémně výnosnou činností. Přibyly motivace a tím i rizika. To všechno jsou změny v prostředí, ve společnosti, které vyžadují změny v přístupu ve vedení OSS projektů. Ty změny se dějí, ale potřebují stále lepší vhled do situace. Snad je to odpověď na Vaši otázku.

Když to převedu do praxe: při autonehodě, starý člověk zemře po menším nárazu, který by dobře stavěný mladý člověk třeba přežil. Výše trestu (který je zároveň i prevencí) se neodvíjí ploše od toho, kolik joulů energie vozidlo předalo do kostí oběti. Stejná chyba má někdy následek smrti a přijde trest, jindy stejná chyba nic nezpůsobí. Řeší se motivace, zanedbání a konkrétní okolnosti. Někdy z takového případu vzejde to, že se upraví tvar silnice, instalují semafory a přechod pro chodce, nebo se třeba udělá zábradlí, aby tam chodci nevstupovali. Jindy dojdete k tomu, že je potřeba mladým řidičům dát řidičák jen na zkoušku, nebo obecně snížit rychlostní limity. Jenže žádnou takovou změnu na silnici neuděláte, pokud nemáte rozlišení příčin. Pokud byste měl k dispozici jen počet nehod a počet předaných joulů, dojdete dokola jen k tomu, že je potřeba jezdit a chodit opatrněji.

Miroslav Šilhavý: Víte, proč se přichází na chyby v programech až po té, co se ten program běžně používá? Třeba až po několika letech od okamžiku, kdy se tam ta chyba dostala? Protože ty chyby se důmyslně skrývají samy od sebe. Resp. ty, které nejsou důmyslně skryté obvykle odhalí rovnou vývojář nebo někdo po něm ještě ve fázi kontroly kódu. Jenže je dost chyb, kterých si nikdo nevšimne, protože nejsou tak zjevné. To jsou ty chyby, které se dostanou až do produkčního kódu, o kterých se pak dozvíte z nějaké CVE a řeší se jako bezpečnostní díra. (Samozřejmě je spousta dalších chyb, které vznikají stejným způsobem, ale nejsou následně vyhodnoceny jako bezpečnostní problém – ať už je to hodnocení správné nebo ne).

Takže opět platí to samé. Je úplně jedno, jakým způsobem se do kódu ta chyba dostala. Jediné, co pomáhá, je umět takové chyby najít a opravit.

Vědět, jaké části kódu mají projít hlubší revizí, jaké přispěvatele je potřeba kontrolovat pravidelně a jaké jen namátkově.
To všechno se ví a aplikuje se to.

Nastavit plochá pravidla fungovalo v době, kdy k Linuxu (ale netýká se to jen něj) přicházeli jen nadšenci se svými konkrétními místními cíli.
Jenže plochá pravidla měl Linux možná kdysi dávno na začátku. Stejně jako to, že přispívali jen nadšenci se svými konkrétními místními cíli. Ale asi nemusíme řešit, jak to bylo před třiceti lety.

Jenže žádnou takovou změnu na silnici neuděláte, pokud nemáte rozlišení příčin.
Akorát že mezi příčinami se nezkoumá něco tak neuchopitelného, jako motivace. Pokud auto nabourá, protože mělo výrobní vadu, řeší se, jak tu výrobní vadu příště detekovat. Neřeší se, jestli zaměstnanec, který tu výrobní vadu způsobil, to udělal úmyslně, nedbalostí, přehlédnutím nebo z nějakého jiného důvodu. Protože až byste velmi drahými opatřeními zajistil, že nikdo tu chybu neudělá úmyslně, zjistil byste, že k nim dochází pořád dál, akorát neúmyslně. Takže je zbytečné řešit jednu příčinu chyb, když k těm chybám může docházet ze spousty jiných příčin. Řešení je jediné – zlepšovat mechanismy detekce těch chyb.

Pokud auto nabourá, protože mělo výrobní vadu, řeší se, jak tu výrobní vadu příště detekovat. Neřeší se, jestli zaměstnanec, který tu výrobní vadu způsobil, to udělal úmyslně, nedbalostí, přehlédnutím nebo z nějakého jiného důvodu. Protože až byste velmi drahými opatřeními zajistil, že nikdo tu chybu neudělá úmyslně, zjistil byste, že k nim dochází pořád dál, akorát neúmyslně.

S touto částí si dovolím nesouhlasit. Pojďme z automobilového průmyslu do NASA a ke dvěma haváriím raketoplánů. Challenger bouchnul kvůli těsnění, které ztratilo svoji pružnost v mrazu, Columbia kvůli porušenému tepelnému štítu po srážce s izolační pěnou.

Pochopitelně v obou případech došlo k technické nápravě: změny materiálů, konstrukční změny. V druhém případě se zlepšily i způsoby detekce (salto raketoplánu, aby bylo možno nafotit jej zespoda).

Jenže v obou případech se našly i další faktory. V prvním nebylo vyhodnoceno varování konstruktérů těsnění, že start v mrazu není dobrý nápad. V druhém případě o problému věděli, ale zkušenost z asi stovky startů všem napovídala, že důsledky srážky s izolační pěnou nejsou vážné. V obou případech nejdelší čas NASA strávila úpravou postupů, aby se každý faktor vyhodnocoval (Challenger) a aby nedocházelo k povyšování chyb na standard (Columbia).

I v běžné fabrice, když zjistíte problém s konstrukční nebo výrobní jakostí, zavádíte opatření. Změny organizační struktury, kontroly produkce, zavádění postupů (řízení jakosti). Rozdíl je ale v tom, že v běžné výrobě je obrovská empirie se zpětnou vazbou na výkon firmy. Vyrábíte blbě = proděláváte. Open source je o tuto část zpětné vazby ochuzen. Zatímco výroba je po staletí zlepšovaný proces, open source je proti tomu batole, které hýbe světem. Prostor pro zlepšování má obrovský a jakýkoliv nový pohled na to, co se děje, může jen pomoci.

Soustředit se jen na zpětné vychytávání chyb, bez rozlišení, jak vůbec vznikly, je zbytečně krátkozraké.

Tady se ale nebavíme o tom, že se nemá zjišťovat, jak chyby vznikly. Vy tvrdíte, že součástí zjišťování má být i posuzování toho, zda někdo chybu způsobil úmyslně či neúmyslně. V případě obou havárií raketoplánů mi ale není známo, že by se něco takového zkoumalo – ani vy jste o ničem takovém nepsal.

Krátkozraké je soustředit se na rozlišování věcí, které na chybu a možnosti jejího odhalení nemají žádný vliv.

Vy tvrdíte, že součástí zjišťování má být i posuzování toho, zda někdo chybu způsobil úmyslně či neúmyslně.

Jednoznačně. Z jednotlivé chyby nic nezjistíte, z mnoha už ano.
Nijak se to nevylučuje s tím, že musíte reagovat i okamžitě. Oprava chyby je samozřejmá. Další opatření (banem na probíhající útok, banem preventivně-výchovným, zhoršením reputace, ...) se už liší podle situace a u nich nelze stanovit úplně pevná a neměnná pravidla.

Ani z moha chyb nezjistíte nic, když budete zkoumat, zda to někdo způsobil úmyslně či neúmyslně. Tedy jednu věc byste zjistil – že to není buď a nebo, ale že je to celá škála možností.

Tedy jednu věc byste zjistil – že to není buď a nebo, ale že je to celá škála možností.

S tímto přístupem bychom neměli žádný pokrok ve spoustě věd, třeba v medicíně :). Tam taky nikdy nevíte přesně, který faktor působí nejvíc a že jste ho zjistil správně. Přesto se s tím dá pracovat. Možná je to pro ajťáky nepohodlně uchopitelné, ale uchopitelné to je.

Pokrok ve vědě nastal teprve tehdy, když jsme se naučili rozlišovat faktory, které vliv mají, a faktory, které vliv nemají – a nezdržovat se dál jejich zkoumáním. Medicína nezkoumá třeba vliv postavení planet v době narození člověka na jeho život, protože už se ukázalo, že tento faktor žádný vliv nemá.

Pravda, občas se vyskytne někdo s objevem, že by postavení planet mít vliv mohlo, protože to přece ještě nikdo nezkoumal, a začne požadovat, aby se o tomto tématu vedla otevřená diskuse. Ale s vědou to nemá nic společného.

@Filip Jirsák

Ano, příčiny chyb nemají vliv na samotnou existenci chyb.
Příčiny chyb však mají vliv na jejich charakter a na možnosti prevence - tedy na bezpečnost.

Příčiny chyb však mají vliv na jejich charakter a na možnosti prevence - tedy na bezpečnost.
To, zda ta chyba vznikla úmyslně nebo omylem nemá vliv na charakter chyby a na možnosti prevence. Vždyť se tu celou dobu bavíme o chybách, které byly úmyslně maskované tak, aby vypadaly jako omyl.

To, zda ta chyba vznikla úmyslně nebo omylem nemá vliv na charakter chyby a na možnosti prevence. Vždyť se tu celou dobu bavíme o chybách, které byly úmyslně maskované tak, aby vypadaly jako omyl.

Nepovažuji se za vševědoucího, ale jsem přesvědčený, že vzorce v chování těch, kteří by se snažili úmyslné chyby maskovat, se dají vypozorovat. Stejně jako se dá vypozorovat systematický (neúmslný) chybovač. K oběma pak jistě chcete přistupovat jinak: lempla zabanujete, ale systematické nebezpečí chcete nejdřív dostat pod kontrolu (zabanováním ho akorát vycvičíte příště neudělat stejnou chybu - a bude jen nebezpečnější).

Nepovažuji se za vševědoucího, ale jsem přesvědčený, že vzorce v chování těch, kteří by se snažili úmyslné chyby maskovat, se dají vypozorovat.
To je hezké, že cílíte na ty, kteří budou své jednání maskovat neúspěšně. Jenže je potřeba reagovat i na ty chyby, které budou tak dobře zamaskované, že budou vypadat úplně stejně, jako neúmyslné chyby. Úplně stejně je potřeba reagovat i na ty skutečné neúmyslné chyby. Vy si pořád ty chyby třídíte do úhledných škatulek, abyste je pak mohl vysypat na jednu hromadu chyb, které je potřeba najít a opravit.

K oběma pak jistě chcete přistupovat jinak
Tohle může fungovat ve firmách. My se celou dobu bavíme o opensource, jehož základní vlastností je to, že může přispívat každý.

Vy říkáte, že je jedno, zda byla zranitelnost zanesena záměrně nebo omylem, protože je v každém případě třeba ji opravit. Souhlas v tom, že z hlediska nutnosti opravy zranitelnosti jsou obě situace totožné.

Nicméně je tu také zásadní rozdíl, který jste neadresoval. U nedbalostí zanesené zranitelnosti ji jednou někdo objeví - ať už za den, rok nebo dekádu. Může ji objevit vývojář nebo researcher, a ti jí nahlásí k opravě. Může ji objevit také nějaký útočník, a začít jí zneužívat. Obě možnosti jsou otevřené.

V případě záměrně zanesené chyby ji také jednou někdo objeví - ať už za den, rok nebo dekádu. Ovšem zásadní rozdíl je v tom, že útočník o zanesené zranitelnosti ví ihned, a nejspíš ji zanesl za účelem jejího zneužívání. Miroslav to popsal slovy že je to horší než 0-day, je to spíš -1-day. A je to ještě horší, protože pokud tu zranitelnost někdo jiný najde až po deseti letech, tak je to -3650-day vulnerability.

Nikoli, pořád je to 0-day vulnerability – prostě už o té chybě někdo ví. Reálným problémem začne bezpečnostní chyba být tehdy, když se o ní dozví nějaký útočník a začne ji zneužívat. Je úplně jedno, jak dlouho před tím chyba byla v kódu a nikdo o ní nevěděl – jestli to bylo dvě hodiny nebo dva roky.

Opět neřešíte příčinu vzniku problému, ale jeho následky. Pokud sedíte v gumovém člunu, může mít defekt, a ten může začít působit problémy. A můžete také mít někoho, kdo vám do člunu dělá záměrně díry. V obou případech je potřeba díry opravit. Jenže by také nebylo špatné zastavit toho, kdo vám do člunu dělá záměrně díry. A tenhle aspekt - předcházení problému namísto jeho řešení - vy prostě ignorujete.

Nejméně problematická zranitelnost není ta, kterou (ať už kdykoliv a jakkoliv) opravíte. Je to tak, která se do kódu vůbec *nedostane*.

Mícháte dohromady dvě věci. Jedna věc je, aby byl chybný kód co nejdříve odhalen. To nijak nesouvisí se způsobe vzniku chyby, prostě je potřeba tu chybu najít co nejdřív bez ohledu na to, jak vznikla.

Druhá věc je osoba, která tu chybu zapříčinila – je logické předpokládat, že pokud někdo způsobil jednu chybu, může způsobit i další, protože buď se v problematice dost neorientuje, nebo to dělá schválně. Nicméně tady narážíme na základní vlastnost otevřeného softwaru, že přispívat může každý. Pokud někdo způsobil chybu, můžete si na něj dávat větší pozor nebo ho zablokovat, ale nijak mu nezabráníte, aby druhý den poslal další patch pod novým e-mailem.

Jinak k tomu, že byli zastaveni ti, kteří teď zrovna dělají do člunu záměrné díry, právě došlo. A mnozí se tady nad tím pohoršují.

To nijak nesouvisí se způsobe vzniku chyby (...) je logické předpokládat, že pokud někdo způsobil jednu chybu, může způsobit i další, protože buď se v problematice dost neorientuje, nebo to dělá schválně

To je právě dost ploché vnímání reality. Pokud mi to udělá nějaký výzkumný tým, který se nesnaží být anonymní, komunikuje - pak mohu předpokládat, že bude i platit dohoda s nimi. Pokud to provede někdo, koho se nemůžete ani dopátrat, tak tam opravdu musíte předpokládat, že bude svoji snahu opakovat. Jenže: v tom prvním případě máte koho banovat, protože se neskrývá. V druhém případě máte někoho, komu ban vadit nebude - prostě začne pracovat pod novou identitou. Takže paradoxně podnikáte opatření vůči těm, kteří hrozbu nepředstavují, zatímco proti těm, kteří představují, nemáte v ruce žádný nástroj.

Jinak k tomu, že byli zastaveni ti, kteří teď zrovna dělají do člunu záměrné díry, právě došlo. A mnozí se tady nad tím pohoršují.

Neudělali díry do člunu. Dostali se ke kýlu lodi i s vrtací soupravou, ale věrohodnými argumenty dokázali, že by ji ani nevyvrtali, protože neměli vrták. Způsobili však poplach, jako kdyby ho měli. Vyprudili tím spoustu lidí, ale neohrozili a ani nechtěli. OK, mohou nést odpovědnost za to vypruzení lidí, ale nemohou být souzeni za terorismus. Opatření LF je však takové, jako kdyby se o terorismus jednalo, použilo de facto maximální nástroj, který má k dispozici.

Takže paradoxně podnikáte opatření vůči těm, kteří hrozbu nepředstavují, zatímco proti těm, kteří představují, nemáte v ruce žádný nástroj.
Nějak nevidím důvod, proč by se měl GKH nechat zahlcovat e-maily s nesmyslnými patchi. Když je mohl zastavit, udělal to.

Dostali se ke kýlu lodi i s vrtací soupravou, ale věrohodnými argumenty dokázali, že by ji ani nevyvrtali, protože neměli vrták. Způsobili však poplach, jako kdyby ho měli. Vyprudili tím spoustu lidí, ale neohrozili a ani nechtěli. OK, mohou nést odpovědnost za to vypruzení lidí, ale nemohou být souzeni za terorismus. Opatření LF je však takové, jako kdyby se o terorismus jednalo, použilo de facto maximální nástroj, který má k dispozici.
To už jsou zase jen vaše výmysly. Za prvé úplně ignorujete, v jaké situaci ban dostali. Ban e-mailových adres univerzity do doby, než si udělá pořádek ve svých výzkumných projektech, fakt není maximální nástroj.

Nějak nevidím důvod, proč by se měl GKH nechat zahlcovat e-maily s nesmyslnými patchi. Když je mohl zastavit, udělal to.

Čistě z toho důvodu, že k jeho pozici má patřit určitý nadhled a vzhledem k moci nad projektem i určitá zdrženlivost tam, kde ji může projevit.

Nadhled projevil, když nijak nereagoval na jejich první výzkum. Když ovšem studenti začali škodit novým způsobem – a to, co dělali, bylo čisté škodění, nebylo tam nic pozitivního, jako oprava chyby v prvním případě – tak zakročil. Zdrženlivost neznamená, že budete tolerovat opakované záměrné útoky.

Už to tu padlo, ale rád zopakuji. Pokud někdo přispívá anonymně do open source projektu a záměrně zanáší zranitelnosti, tak ho nezablokujte. Respektive zablokujete, ale on si založí novou identitu, a za chvíli ho můžete mít zpátky.

Zkuste si představit, že vedete oddělení elektronické špionáže u řekněme nějaké čínské zpravodajské služby. Řeknete si, že zavedete zranitelnosti do pár desítek často používaných aplikací, protože vám to umožní krást data, technologie, identity atd. V případě klasického SW byste musel poslat podřízené do každé firmy vyrábějící takový SW, s velmi dobrým krytím aby prošli bezpečnostní prověrkou, nechat je tam zaměstnat, fyzicky docházet do kanceláře, a snažit se produkt kompromitovat. To je zatraceně velká spousta práce. A když to praskne, tak agenta chytí, a může zpívat.

To u open source je situace úplně jiná. Každý podřízený může z tepla a bezpečí kanceláře zpravodajské služby přispívat klidně do desítek projektů. Nákladem je počítač, stůl a topení/klimatizace. Když to praskne, tak dotyčný bude dál škodit na desítkách dalších projektů. A na ten, kde to prasklo, se prostě vrátí pod jinou identitou.

Tohle je principiální omezení open source vývoje. Samozřejmě by bylo možné každého přispěvatele lustrovat. Nicméně když uvážíte, že spousta projektů nemá dost zdrojů ani na schvalování kódu, nemluvě o kvalitním testování, dokumentaci a překladech, tak je jasné, že tuhle mezeru jen tak nezavřete. Ti studenti to svou prací ukazují v celé nahotě.

Já jsem tímto řekl k věci vše, co jsem chtěl říct.

@J ouda

Nějak ten komentář nechápu. Na internetu lze sledovat kde co a nejde tomu prakticky zabránit. Že se o to snaží velké firmy, jak pro sebe, tak pro vlády různých zemí, je notoricky známo.