Vlákno názorů k článku
Man po půlnoci píše „gimme gimme gimme“ jako vzpomínku na ABBA od Miroslav Šilhavý - Pozoruhodné je, že šest let to v kódu...

Ale o tom není přeci otázka. Tento vtípek je úsměvný.
Vede jen k zamyšlení, jestli náhodou není možné do kódu dostat něco nebezpečného, aniž by si toho někdo všiml.
Easter egg budete asi psát pro pobavení, a nebudete jeho účel ani nijak maskovat.
Pokud je ale možné do kódu dostat - řekněme - skoro cokoliv, pak napíšu takový kód, aby z něho nebylo na první pohled patrné, že je nebezpečný, a vpašuji ho tam.

Samotný vtípek je hovadina, která asi fakt nikomu neublížila, ale ukázala selhání potřebných mechanismů.

Zbraně taky nikomu samy o sobě neškodí, ale najít mechanismus, aby se ale nedaly zneužít je nemožné. Jestli ze samotné podstaty nepožadujete něco, co nejde.

A možná jste jenom docela suchar.

Ano, najít obdobný easter egg v programu, kde by dle mého zvážení mohl způsobit chybu, nejspíš sama pošlu pull request s opravou. V tomhle případě bych dopadla jako kolega výše a zasmála bych se. Využití manu popsané na stackexchange by mě totiž ani ve snu nenapadlo.

(ale jinak, ač mi easter eggy nevadí, tohle uznávám byl trochu blbý nápad kvůli provedení. Cow vtípky v Aptu a emerge jsou v pohodě, ale nepředvídatelný výstup programu v určitou dobu úplně OK není)

Znovu se ptám na jednoduchou otázku: pokud mohl projít takový vtípek, kde berete jistotu že v důležitějších programech nejsou vpašovány horší části kódu?

Pořád všichni hodnotíte vtipnost a neškodlivost, ale nikdo se nezaráží nad tím, co to indikuje.

Prošel, protože ho všichni brali jako neškodný vtípek. Horší části kódu nejsou neškodné vtípky. Jakou záruku že v důležitějších programech nejsou vpašovány horší části kódu máme v uzavřeném software? Když se ten program zachová tak jak nečekám, můžu se mrknout do zdrojáku proč se tak děje?

V uzavřeném software mám možnost ve své vlastní firmě zjednat nápravu. U OSS nemám ani tu možnost. Při uzavřeném vývoji mám zaměstnance zesmluvněné a nesou odpovědnost a dohledatelnou minimálně za úmyslné činy. U OSS, v takových případech, nedohledáte ani totožnost.

Pokud někdo o eggu věděl a neřešil ho, je z mého pohledu stejně nezodpovědný, jak ten, kdo ho tam zanesl. V této diskusi jsou příklady, kdy takovýto "rádoby neškodný" vtípek může mít dopady (např. ekonomické).

A co když budu chtít vědět, jaká data ten systém šifrovaně někam posílá a podobně? Co když ta firma nechce zjednat nápravu, protože jí chování vyhovuje? A co když tvůrce software už neexistuje?

Při uzavřeném vývoji se nemusím dovolat ani jména, ani nápravy, ani zjistit co se děje.

To je správná úvaha, ale tam už musím uvažovat, komu důvěřuji.

Naše post-rakouskouherská mentalita nám velí, že nadřazená autorita (stát) garantuje spoustu věcí - např. důchodový systém, nebo jakost vzdělávání. Proti tomu např. anglosaský systém preferuje konkrétní vztahy důvěr. Zjednodušeně: u nás každému inženýrovi důvěřujeme stejně. V Británii se Vás nejprve zeptají, ze které školy ten titul máte. Když jdete do zaměstnání v USA, ptáte se, jaký má zaměstnavatel důchodový program a posuzujete, jestli zaměstnavatel bude na trhu ještě v době, až dojdete do důchodu. U nás chceme věřit v autority.

Podobně, jak jsem popsal, se rozhoduji i u softwaru. Někdo může věřit Microsoftu, někod IBM, někdo Oraclu, někdo dalším firmám. Někdo může víc věřit konceptu OSS. A co tu říkám je, že není možné jen slepě věřit konceptu OSS, že je všespásný. Sice teoreticky můžete kód revidovat, ale v praxi to už několikrát selhalo. Vzpomeňte si na velké průsery, jako je linux CoW, nebo ne dostatečně bezpečné generování klíčů Debianem. To byly chyby, které bych považoval za velmi kritické, přesto si jich nikdo nevšiml, ačkoliv bariéra neexistovala. Navíc se můžeme bát toho, že tyto chyby do kódu zanesl někdo záměrně, nebo že díky dostatku financí je dokázal odhalit a v mezidobí zneužívat. To vše je u uzavřeného vývoje taky, jen je mnohem menší množina těch, kteří "mohou".

Bezpečnost, obecně, ne jen v softwaru, musí být být nepřetržitý proces zlepšování, ale zejména kontrol a auditů. A pak už se musíte rozhodnout, jestli kombinaci vendor+auditor důvěřujete.

Zajímavé by bylo srovnání např. přístupu k StartSSL vs. certifikáty od Let's Encrypt. Všichni jsme četli, a asi i všichni souhlasíme, že kořenový certifikát nemůže zůstat důvěryhodný, když vydavatel udělal prohřešky proti pravidlům. Také nikdo neřešil, jestli ve skutečnosti představovaly ohrožení, či nikoliv. Byly to prostě kroky, které vedly k podlomení důvěry, jak celý projekt (celá firma) funguje. Proti tomu Let¨s Encrypt, který dělá jen zlomkové ověření totožnosti oproti StartSSL, důvěryhodnost získává. Proč? Protože dodržují do puntíku stanovená pravidla a snaží se je neustále vylepšovat a získávají důvěru (samozřejmě, politika velkých firem v tomto projektu také hraje svoji roli).

Co se tu snažím složitě popsat je, že vůbec nejde o to, jestli konkrétní incident znamenal nějaké ohrožení či škodu. To se ve skutečnosti nedá vyvrátit (viz heslo "důkaz negativní skutečnosti"). Naopak lze potvrdit, že kdyby tam oněch asi 7 řádků kódu nebylo, byla by aplikace určitě jednodušší, bezpečnější a hlavně by fungovala podle svého popisu.

Ku příkladu, kdybych byl zadavatelem nějakého projektu, a dodavatel by mi toto propašoval do kódu, naprosto nutně by to vedlo k oslabení důvěry mezi našimi stranami. V tomto případě asi ne ke ztrátě, ale trval bych na tom, aby mi dodavatel v budoucnu dokázal, že takovým excesům předejde. Pokud by to byla dodávka do kontrolovaného prostředí - např. do banky, mohlo by takové zjištění vést ke ztrátě auditu, nebo přinejmenším ke zbytečné výhradě.

Chyby (i záměrné) můžou být v jakémkoliv projektu. Rozdíl je jen v tom, že ty uzavřené je opravují pod pokličkou. Kvalita záleží na spoustě věcí. Záleží na tom, jak je celý projekt vedený, jak jsou programátoři dobří, taky na jejich morálních kvalitách, jejich motivaci to napsat pořádně, jestli se ten den dobře vyspali, jak moc je tlačí termín vydání a tak. Otevřenost kódu je jen jeden střípek.

V tomhle konkrétním případě ten vývojář psal kód pro zábavu, tak tam strčil nějaký vtípek ... no a nedomyslel důsledky. Jiné projekty píšou programátoři čistě jen za prachy, vtípky a kontrola mezí v poli by je jen zdržovaly. Tak si vyberte :-)

Stále jen hodnotíte, že zde šlo o prkotinu. Z mého pohledu je vážnější systémové selhání, než hodnotit, jaký dopad to mělo. Dokonce i daleko nebezpečnější, ale neúmyslnou chybu programátora bych hodnotil mírněji, než tento dost hloupý a nevydařený vtip.

Jasně, ale stále zde nechápu to, proč někdo předpokládá, že stejným způsobem se nemůže do projektu dostat i opravdu škodlivý kód? Podle mě je zřejmé, že si toho 6 let nikdo nevšiml, protože po prvním hlášení byl problém odstraněn - tedy ani ze strany autora nebyl bagatelizován.

Já chápu, že zde jsem na půdě, která OSS glorifikuje a korporace odsuzuje, ale ta zaslepenost je až moc velká. A to prosím upozorňuji, že většina serverů, které mám ve správě, jede na Linuxu a FreeBSD, jen menšina na Windows.

Podle mě je zřejmé, že si toho 6 let nikdo nevšiml, protože po prvním hlášení byl problém odstraněn - tedy ani ze strany autora nebyl bagatelizován.
To je ale chybné vyvození. Zřejmé je, že s tím za šest let nikdo neměl sebemenší problém, nebo alespoň neměl důvod to hlásit. To ale vůbec neznamená, že si toho nikdo nevšiml. Pravděpodobné je, že si toho lidé všimli, ale buď se tomu zasmáli, nebo si řekli, že je to hloupý vtip, ale dál to nijak neřešili, protože to byl vtip a nezpůsoboval jim žádný problém.

Vůbec nejde o nějaký OSS, ale o to, že pořád tvrdošíjně považujete za chybu něco, co nejspíš nikdo šest let za chybu nepovažoval, a spousta lidí to nepovažuje za chybu i nadále.

Ano, protože v bezpečnosti stačí, když to považuje za chybu jeden, a je potřeba se tím zabývat. Příklady, kdy to může způsobit (nějaký) problém byly nalezeny. Podle mě v tomto nemůžete brát, že vox populi, vox dei. Pokud to hordy lidí viděly, a nedošlo jim, že to způsobit problém může, pak je to o to víc zarážející.

Naopak Vy tu obhajujete něco, co už bylo vyvráceno: kdyby to bylo tak, jak píšete, tak by to z kódu po nahlášení chyby neodstranili!

Ano, protože v bezpečnosti stačí, když to považuje za chybu jeden, a je potřeba se tím zabývat.
Vždyť ano – jeden to považoval za chybu a autor se tím začal zabývat.

Pokud to hordy lidí viděly, a nedošlo jim, že to způsobit problém může, pak je to o to víc zarážející.
Všechno může způsobit problémy. Vy jste ale napsal, „pokud to někdo považuje za chybu, je potřeba se tím zabývat“. Za těch 6 let to nikdo za chybu nepovažoval, až teď se někdo našel – a autor se tím začal zabývat.

Naopak Vy tu obhajujete něco, co už bylo vyvráceno: kdyby to bylo tak, jak píšete, tak by to z kódu po nahlášení chyby neodstranili!
Já jsem tvrdil, že mně by úplně stačil ten první patch, který to vypisoval jen tehdy, pokud bylo man voláno (nesmyslně) bez parametrů. To je můj názor, takže to těžko může být vyvráceno. Nakonec zvítězil jiný názor, že to tam nemá být vůbec a já to rozhodnutí respektuju (co bych s tím taky asi tak mohl dělat jiného). Ale nejde o nic, co by bylo potvrzováno nebo vyvraceno – jde o názor na to, jakou funkci má mít daná aplikace, to není nic objektivního, co by se dalo potvrzovat nebo vyvracet.

Není na tom nic zarážejícího, prostě někdo po šesti letech přišel s tím, že mu tahle funkce aplikace nevyhovuje, a dospělo se k tomu, že bude nejlepší tu funkci odstranit. Také se mohlo dojít k tomu, že je to prima funkce a pokud kvůli ní padá nějaký test, je potřeba opravit ten test.

@nobody (neregistrovaný) ---.pel.cz
atarist (neregistrovaný) 89.24.56.--- 21.11. 20:36
ze man bez parametru musi vypsat
presto ze p.Silhavy je dost mimo(n), je dobre upozornit, ze neslo jen u man bez parametru ... coz je argument proti p.Silhavemu co ocividne nechape opensource ;-)
jinak musim uznat ze demagogie "kdyz je tam neco neskodneho a nikdo si nevsiml(pritom si vsimli, jen to nevadilo), tak to znamena ze se tam muze dat neco skodneho a nikdo si nevsimne" je opravdu postavena na hlavu ;-)

Pod to bych se s dovolením podepsal, panu Šilhavému bych ve vší vážnosti doporučil terapii, která by mu pomohla správně chápat realitu a pro všechny ostatní, kteří mají rádi Ester Eggs a nemají Debian based distra, ale také i ty, kteří v následujícím vidí nebezpečí kvůli chudáčkovi slonovi:


$ aptitude moo
V tomto programu nejsou žádná velikonoční vajíčka.

$ aptitude -v moo
V tomto programu opravdu nejsou žádná velikonoční vajíčka.

$ aptitude -vv moo
Neříkal jsem snad, že v tomto programu nejsou žádná velikonoční vajíčka?

$ aptitude -vvv moo
Přestaň!

$ aptitude -vvvv moo
Fajn. Když ti dám velikonoční vajíčko, půjdeš už pryč?

$ aptitude -vvvvv moo
Dobrá, vyhráls.

                            /----\
                    -------/      \
                   /               \
                  /                |
-----------------/                  --------\
----------------------------------------------

$ aptitude -vvvvvv moo
Co to je? Co by to bylo! Přece had žeroucí slona.

Víte, kdyby ten vtip byl jen ve výstupu nějakých opravdu neškodných parametrů - např. při "man --help --help" apod., nebo kdyby se obejvilo nějaké vajíčko při "man man", tak by to byl opravdu žert. Tady byl neúsudek v tom, že to navracelo na výstup stderr, něco, co nemělo, a mohlo to zmást scripty, které s tím pracovaly. To je důvod, proč mi to vadí. Easter eggy se nejčastěji vsouvaly do helpů, tedy tam, kde se opravdu vůbec neočekává jakékoliv další navazování na výstupy.

Je to takto formulované přijatelnější?

Protože kdyby to někdo kontroloval, nemohlo by to z principu projít, a kdyby, tak by to muselo být dokumentované (man man :))))

Z běžného principu řešení bezpečnosti. Pokud vím, že je v kódu cokoliv, co tam nepatří, nenechám to projít. Pokud vím, že něco je napsáno suboptimálně, dokumentuji to. To nejsou moje výmysly, to jsou obecně uznávaná pravidla.

Je možné, že existuje nějaká metoda bezpečné akceptace easter eggů, já o ní nevím. V tomto případě bylo jasně prokázáno, že tento vtípek není bez dopadů a byly ukázány příklady, kdy to způsobí škodu.

I selhaný test je zbytečná škoda, kterou zaplatí někdo jiný, než autor eggu.

To je věc principu, ne příkladů. Program dělá něco, co dělat nemá, a dělá to za vědomí autora, případně i dalších lidí. Kdo bude rozhodovat, jestli je vtípek bezpečný, či nebezpečný? To je moje první otázka.

Moje druhá otázka je, když se takto volně staví k bezpečnosti autor, a možná i řetězec dalších lidí ve vývoji, jak můžeme důvěřovat, že uvidí, nebo správně odhadnou dopady nějakých, ještě méně viditelných průšvihů.

Jinak co se týče dopadů, už tu byly zmíněny dva:
1) nemusí proběhnout (automatické) testování vývoje (deploye) nějakého projektu,
2) zhroutí se scripty, které závisí na man -w, případně budou zneužitelné k práci s podstrčeným souborem "gimme gimme gimme" (namísto souboru, který má vrátit man -w).

Asi mi teď budete říkat něco o tom, jak je to malá pravděpodobnost, případně že v druhém případě se jedná o sérii chyb, kdyby se to mělo projevit. S tím dopředu souhlasím, přesto tvrdím, že ta prvotní chyba tam neměla být.

Co vy víte? Třeba docházelo, jen nešťastní admini nebyli schopni sporadickou chybu reprodukovat - koho by napadlo, že má čekat na 0:30 každý den, aby chybu reprodukoval?

A k těm šesti letům: jakýsi A. H. byl šest let úspěšným kancléřem velké země a všichni kolem přeháněli.

Úspěšně se vyhýbáte dvěma rovinám úvah:
1) to, že patrně nejste schopný dopředu posoudit dopady (příklady uvedeny, Vámi znegovány),
2) že buďto tato úvaha selhala v řetězci více lidí, nebo že řetězec lidí v tomto vývoji neexistuje nebo je chabý.

Já si pamatuji doby, kdy první Pentium od Intelu (60 a 66 MHz modely) měly chybu ve floating point operacích, a dodavatelé se snažili bráni tím, aby jim zákazníci "prokázali", v jakém konkrétním případě jim může vadit chyba projevující se v řádu (tuším) e-5. Přesto všichni víme, že procesor s takovou chybou je prostě vadný.

Jasně, takže podle Vás spadne nějaký script, a první, co uděláte je, že začnete studovat zdrojáky?

Prvním předpokladem je snažit se chybu reprodukovat. Pak existuje jakýsi obor tzv. "očekavatelných vlastností", ale rozhodně do očekavaelných vlastností manu nepatří výhybka v 0:30. Takže, poměrně logicky, spustíte celou sérii testů znovu, a s nejvyšší pravděpodobností se už znovu netrefíte do stejné minuty v jiný den.

Zde je naopak jasně prokázáno, že chování programu je závadné, a není potřeba hledat, jestli to někoho poškodilo. Dokonce ani nikdo nediskutuje (ani v nejmenším), že by tato "vlastnost" měla v kódu zůstat. Jen z Vašich příspěvků to vypadá, jako že se nic nestalo, a mohl by tam tento "milý" vtípek zůstat.

Při prvním průchodu testu můžu mít nižší logování, teprve při pádu budu zvyšovat úroveň. A očekávám, že zrovna man mi dá ze stejného vstupu stejný výstup.

To, že to nikdo nebyl schopný reprodukovat, či odhalit, není důkaz toho, že to nikomu nezkazilo večer hledáním nedohledatelného.

Bavíme se tu o sračkách, program prostě toto dělat nesmí a je zbytečné to obhajovat tím, že nikdo nevyčíslil škodu.

Ale pane, vy neumíte číst text. Já jsem nevyzdvihoval uzavřený vývoj, jen jsem poznamenal, že existuje tato slabina u OSS a podotknul, že si ji ne každý uvědomuje.

Stejně tak za námahu nestály "easter eggy" v podobě linux CoW, nebo Debianních slabých klíčů? Easter egg podle Vás lidé viděli, ale smáli se mu a nechali ho tam záměrně, zatímco tyto průšvihy "jen" přehlédli?

Vás bych za bezpečáka opravdu nechtěl, to je krásný příklad řízení metodou "management by hope".

Pořád nějak nechápu, pánové, vy mi tu tvrdíte, že je to tak v pořádku, že tam ten kód má zůstat? Pokud ano, pak se můžeme shodnout na tom, že se neshodneme.

Pokud uznáváte, že tam být do budoucna nemá, pak to podle mě znamená i to, že tam vůbec neměl být. Závažné podle mě je to, že se nejedná o chybu (chybovat je lidské), ale o záměr-nezodpovědnost někoho, kdo měl moc takový kód zveřejnit.

Hitler byl příklad jen toho, že není důkaz "že to 6 let nikomu nevadilo", a přesně jsem psal, co píšete: zatímco toto mohl odhalit a fixovat každý, stejně to neodhalil a nefixoval. Z čeho pak pramení důvěra ve výhody OSS jakožto více sebe-regulující platformy z hlediska bezpečnosti?

Mně prostě to, že easter egg tohoto typu do kódu prošlo a fungovalo bez odhalení, prostě nahání husí kůži.

Když někdo bude jezdit na přehuštěných letních pneumatikách v zimě, mohu obecně říci, že ohrožuje bezpečnost a prokazuje nezodpovědnost; je lhostejné, jestli už takto jezdí 10 let bez nehody. Obdobně, naštěstí, drtivá většina lidí nikdy nezaboří nos do airbagu, přesto bychom považovali za nezodpovědné ho z auta vyjmout (nehledě na ztrátu technické způsobilosti). Dokonce bychom považovali za nebezpečné vyjmout airbag u spolujezdce, přesto, že by dotyčný tvrdil, že vždy a zásadně jezdí v autě sám.

Pokud to přirovnám k easter eggu, je to podobné, jako kdyby v 0:30 začal rychloměr ukazovat o 10 km/h více. Asi by to nikoho neohrozilo (prostě by řidiči jeli pomaleji); přesto, např. na dálnici se smí jet minimálně 80 km/h, a to už by mohlo vést přinejmenším k porušení předpisů. Ale hlavně: důvěřoval byste autu, jehož ručka rychloměru by si, jen kvůli vtipu vývojáře, někdy dělala, co chce? Nebo byste platil audit kódu řídicí jednotky (předpokládejme, že byste ho dostal k auditu k dispozici)?

Ne, ne, zde prostě musí nejprve převládnout formální hodnocení situace (primární nezodpovědnost, selhání procesu vývoje), teprve následně můžeme (ale ani nemusíme) hodnotit, jestli to někomu ublížilo.

Pořád nějak nechápu, pánové, vy mi tu tvrdíte, že je to tak v pořádku, že tam ten kód má zůstat?
Já bych neměl vůbec žádný problém s tím prvním navrženým patchem – tedy že by se to vypisovalo jen v případě, kdy se zadá man bez parametrů.

Vy máte nějaký důvod, proč ten kód v pořádku není?

Mně prostě to, že easter egg tohoto typu do kódu prošlo a fungovalo bez odhalení, prostě nahání husí kůži.
Prošlo ovšem předpokládá, že je na tom něco špatně.

program prostě toto dělat nesmí
To je pouze váš názor. Já nevidím žádný důvod, proč by to program dělat nesměl, a ani nevidím, že byste někde takový důvod napsal. To velikonoční vajíčko mohlo být ještě méně invazivní, jak to řešila první oprava, mohlo být více zdůrazněno, že jde o vtípek. Ale opravit by potřeboval spíš ten test…

Tak to nebylo položeno. V případě vývoje vlastního software, podle situace, programátora pokárám a proškolím zaměstnance, proč by to neměli dělat. Při větším prohřešku ho vyhodím podle § 55 a nechám ho uhradit škodu až do zákonné výše.

V případě OSS nemáte jak vývoj řídit a ověřovat. Projektů, které vybraly dostatek peněz a zaplatily si nezávislý audit, se dá napočítat na prstech.

To si nemyslím. Uzavřený vývoj u třetí strany u mě opět může požívat - asi podle toho, co to bude za vendora - více, či méně důvěry, že podobné principy také následuje. Bude i těžší - finančně, fyzicky, místně - protlačit do kódu jakéhokoliv vendora něco zneužitelného (musím být na místě, projít přijímacím pohovorem, nedostanu se hned k projektu, který bych chtěl, ...). U OSS jsou principy fungování jiné, a zrovna v tomto ohledu vidím slabiny.

Víte, provedl jste tady poměrně silnou ofenzivu. Tak bych se jen rád zeptal, jaký operační systém a prohlížeč vlastně používáte (zjevně nějaký ano). Protože v každém operačním systému i prohlížeči (troufnu si tvrdit, že bez výjimky), byla důvěra nabourána mnohem více, než je výpis gimme, gimme gimme na obrazovku. Tak by mě zajímalo, jak s tím dokážete žít.

Ofenzivu v jakém slova smyslu? Že jsem se nahlas zamyslel nad tím, jak může i zcela otevřený proces podlehnout takové chybě - v tomto případě pouze v chybě úsudku. Nevím jak Vy, ale já cítím velký rozdíl mezi chybou nezáměrnou a úmyslem. V tomto případě to nebyl úmysl uškodit, přesto to byl úmysl a ne jen chyba programátora.

Nene, to si vůbec nemyslím.
Oproti výhodám necentralizovaného vývoje vidím ale zároveň i slabinu v tom, že mnohdy OSS zavání tím, že není dobře auditovaný. Také ale vím, že to není železné pravidlo.

Tady je smutné, že to prostě sám mantainer neodhadl a udělal easter egg opravdu pitomě, že ovlivňoval výstup za běžného běhu, ale jen v krátký časový úsek. To je jedna část toho, co si myslím.

Druhá část je právě o tom, že ani stovky očí, pokud to opravdu viděly, jak tu někteří píší, neodhalili, že to je potenciální problém.

První slabina je stejná jako pro OSS, tak pro uzavřený vývoj.
Druhá slabina je specifická pro OSS a musí se řešit jinak, než u uzavřeného vývoje, neb vývoj OSS probíhá trochu odlišně.