Hlavní navigace

Názory k článku NXNSAttack: zastavte nový druh útoku náhodnými dotazy, aktualizujte resolvery

  • 21. 5. 2020 13:09

    Danny

    Myslim, ze by nebylo od veci, aby vyvojari Knot resolveru zvazili portaci opravy (nejen) NXNSAttack tez do starsich verzi, ktere jsou dnes soucasti oficialnich "stabilnich" distrubuci - jinak v praxi ten okruh uzivatelu majicich instalovany opraveny bude proste mensi. Je-li tedy cilem autora opravdu "neco zastavit"... :-) Je malo pravdepodobne, ze na vsech mistech bude nasazena posledni verze 5.1.1 kresd z baliku (prinasejici jine zasadni zmeny, mj. i v konfiguraci daemonu - a pomerne zasadni nekompatibilni zmeny jsou v pripade kresd pomerne casty jev, coz take muze nekoho odrazovat od nasazeni - jen kvuli oprave nejake bezpecnostni diry - s rizikem, ze v mezicase obmeneny kod vnese do produkcniho prostredi jine nove chyby...).

    Prikladem muze byt ISC a jejich podpora Bindu. Takze zatimco v Debianu dle ocekavani mame "deravou" verzi 3.2.1 kresd (a prechod diky nekompatibilnim zmenam nemusi byt pro kazdeho trivialni), v pripade Bindu je uz v distribuci standardni cestou dostupny opraveny balicek, ktery je mozne obratem nasadit. Jiste, v Debianu muzou back-portovat relevantni cast kodu, ale to asi chvili potrva - pokud se nekdo odhodla - ostatne tam nejsou opraveny ani starsi diry.

    A nebo holt ti obycejnejsi uzivatele zustanou u Bindu... :-) Alespon do doby, nez i CZNIC pro knot-resolver zacne vydavat "extended-support" verze po vzoru ISC a bezpecnostni problemy sveho produktu opravovat i ve starsich - ale "v terenu" bezne pouzivanych - verzich. A podotykam - to pisu z pozice cloveka, ktery se sam nasazovat nove veci pro sve potreby neboji - ale holt ne kazdy je takovy ;-)

  • 21. 5. 2020 15:15

    Filip Jirsák

    Nebo by si naopak správci distribucí mohli uvědomit, že je rok 2020, a že udržovat v distribucích staré verze programů je nesmysl.

    Skoro každá verze jakéhokoli programu obsahuje i bezpečnostně relevantní opravy. Jaký smysl má, když si každá distribuce vyzobává nějaké opravy, o kterých někdo (kdo tomu kódu zpravidla moc nerozumí) usoudí, že zrovna ty jsou ty důležité, aby je backportoval a vytvořil tak verzi aplikace, která nikde jinde není, takže bude podstatně méně otestovaná?

    Já chápu vaše argumenty, že chcete, aby tuhle opravu mělo co nejvíc uživatelů. Ale myslím si, že to je špatný požadavek. Podle mne má mít co nejvíc uživatelů všechny opravy. Vývojáři se snaží, aby jejich aplikace byla co nejbezpečnější – a nejbezpečnější verze je tedy poslední verze aplikace. Pokud v ní distributor objeví nějakou chybu, ať se opraví v upstreamu. Ne že místo toho bude vyrábět jinou verzi s jinými chybami.

    Takže já za sebe naopak prosím vývojáře Knot Resolveru, aby na tuhle hru nepřistupovali a trvali na tom, že nejbezpečnější je nejnovější verze aplikace.

  • 21. 5. 2020 17:58

    bez přezdívky

    Jasne. Takze dodrbat celou distribuci, kvuli jedne aplikaci a jejim zavislostem zmenit verze knihoven, a kvuli tem zpetne i zbytek balicku v distribuci - co na tom, ze nove verze nemusi bezet se starymi konfiguraky, ze nemusi fungovat stejne, atp, a ze nachystat, odladit a otestovat distribuci muze byt prace tisicu vyvojaru po cely rok...

    Tak to ani omylem. To je jeste horsi, nez moderni instalace pustenim shellscriptu, ktery si vse "potrebne" nejak a odnekud postahuje ...

    Pokud autorum nejaky software nestoji za to, aby opravovali a nejakou dobu podporovali starsi verze, ani drzeli zpetnou kompatabilitu konfiguracnich souboru, tak je to prasarna, a na ty prece mame docker ...

  • 21. 5. 2020 20:59

    Filip Jirsák

    Ne, ta distribuce už je dodrbaná, protože používá staré aplikace a knihovny náhodně pozáplatované kusy kódu z novějších verzí. A nejde o jednu aplikaci, ale o všechny.

    muze byt prace tisicu vyvojaru po cely rok...
    Přenášením patchů z nových verzí do starých můžete zaměstnat spoustu vývojářů na hodně dlouho. Ale jaký to má smysl?

    Pokud autorum nejaky software nestoji za to, aby opravovali a nejakou dobu podporovali starsi verze
    To ale nepopisuje realitu. Realita je taková, že správcům distribucí nestojí za to opravovat programy. Přečtěte si článek, pod kterým diskutujeme. Proti NXNSAttacku se lze bránit dvěma způsoby – omezením počtu dotazů na autoritativní servery, což je vlastně zásah do protokolu, rekurzivní server pak vlastně funguje špatně a musí se to heuristicky vyladit tak, aby to špatné fungování nebylo moc vidět. Druhý způsob je využívat nakešované negativní odpovědi – když se podaří využít tenhle způsob, je to ideální, protože rekurzivní resolver funguje pořád perfektně, ale útočník si ani neškrtne. Jediná nevýhoda tohohle způsobu je, že v keši nemusí být potřebné záznamy, a pak může útočník útočit – dokud se keš nenaplní.

    Jenže ten druhý efektivnější způsob obrany není bezpečnostní záplata, je to nová vlastnost. Takže to do distribucí nepatří. Distribuce totiž mají rády starý software s nedokonalostmi, které už jsou dávno opravené.

    na ty prece mame docker ...
    A proč asi máme Docker? Protože je možné v něm mít aktuální software s opravenými chybami (včetně bezpečnostních). Holt je mezi lidmi poptávka po tom používat software s co nejmenším množstvím chyb, a když to nedokážou zajistit distribuce, našla se jiná cesta.

  • 22. 5. 2020 0:00

    Filip Jirsák

    Docker to vyřeší celkem jednoduše. Knot Resolver má API v podobě DNS standardů, které se moc nemění, a pokud ano, tak zpětně kompatibilně. Pak má moduly, a aktuální verze těch modulů jsou součástí toho Docker balíčku.

  • 22. 5. 2020 8:05

    Danny

    Opet se mylite. Knot Resolver ma i jina API rozhrani, nez ta popsana v RFC vztazenych k DNS protokolu. Zkuste si priste alespon otevrit dokumentaci k produktu, o kterem naruzive vedete diskuzi :-) Sirite sve nicim nepodlozene vlastni dojmy z neznalosti.

  • 21. 5. 2020 18:02

    Danny

    To je samozrejme pekna teorie :-) Provozni praxe je vyrazne slozitejsi - a skutecne zodpovedni vyvojari si toto jiz dlouhodobe samozrejme uvedomuji, takze mame long-term vydani kernelu, ESR vydani produktu z dilny od Mozilly, ESV Bindu, atd. atd.

    A ono kdyz si pozorne prohlidnete zmenove dokumenty i ke kresd, tak velmi rychle narazite na ruzne mozne problemy s rychlym prechodem na nejnovejsi verzi. Takovy prechod se logicky pochopitelne hure automatizuje i v porovnani s ciste bezpecnostnimi aktualizacemi v ramci jedne verze (optimalne vytvorenymi primo vyvojari, vyse je demonstrovano, ze toto se jinde deje), ktere ovsem vesmes nijak nezasahuji chovani aplikace - at jiz z pohledu treba API, nebo i jen konfiguraci.

    Ono to neni jen o tom, ze si upgradnete ten jeden konkretni software, ale nekdy je nutna uprava i v navazanem ekosystemu. A ta neni v praxi vzdy realizovatelna ihned. Bohuzel praktickym dusledkem toho je, ze uzivatele namisto provedeni alespon te bezpecnostni aktualizace zaplatujici tu konkretni zranitelnost projistotu... neaktualizuji vubec nic a provozuji derave sluzby. Nova major verze jim neco funkcne rozbije, a aktualizace pro tu starsi proste neni... a ted, babo rad :-) Prave proto, ze je rok 2020 je treba mit na zreteli i moznou komplexitu koncovych instalaci a netvarit se tak, ze to prece neni vyvojaruv problem, kdyz ten se rozhodne udelat nekompatibilni zmeny a soucasne se uzivatelum realne ani neposkytne cas k adaptaci - ktera mimo jine casto zahrnuje i nejake komplexnejsi testovani ve vlastnim prostredi vynucene prave temi novymi funkcemi v kodu, ktere jsou obcas i zpetne nekompatibilnimi. Ono i tohle testovani k roku 2020 proste patri.

    A presne to je smyslem tech ruznych extended-support verzi, kde se jen opravuji bezpecnostni chyby, aniz by se zasadne menila jejich okolni funkcionalita a tudiz se znacne omezi riziko funkcniho rozbiti koncove instalace pri oprave bezpecnostnich der. Je dopredu znam zivotni cyklus takovych verzi, a casto mimo jine take znamo, kdy cca lze ocekavat novou verzi verzi - s delsi bezpecnosnti podporou delsi nez dva-tri mesice. Nektere distribuce defacto jen supluji praci primarnich vyvojaru.

    Nebo take muzeme pristoupit na tezi, ze kresd je opravdu jen pro hrave geeky a do skutecne produkcniho prostredi se az tak moc nehodi.... kdyz holt je dulezitejsi mit kazde dva mesice novou verzi s novymi funkcemi ;-)

  • 21. 5. 2020 19:46

    Vít Šesták

    Ano, jsou tu různé LTS verze různých programů, kde tu LTS vydává přímo původní autor aplikace. Tam samozřejmě má smysl, aby se původní autor postaral i o fix.

    Naopak, pokud se někdo rozhodne do své distribuce nějakou LTS fakticky vytvořit vlastními silami, dělá to na svoje triko. Asi nemůžeme po autorech Knotu chtít, aby se starali o všechny forky, které se kdy kdo rozhodl vytvořit. Oni už patche vydali, informovali o problému, a forky jsou IMHO záležitostí maintainerů forků.

  • 21. 5. 2020 22:51

    Filip Jirsák

    forky jsou IMHO záležitostí maintainerů forků
    Podle mne by k tomu měla zaznít ještě jedna věc. Že ty distribuční forky jsou typicky méně kvalitní, než upstream. Protože pokud v tom forku opraví nějakou chybu, upstream se to obvykle nějak dozví (ideálně přímo od správce toho forku) a chybu opraví také. Jenže ty forky obsahují patche nebo backporty, které nikde jinde nejsou – a připravují je programátoři, kteří ten program znají hůře, než kmenoví vývojáři toho programu. Což není nic proti správcům distribučních balíčků, neznamená to, že by museli být horší programátoři. Ale když ten správce má na starosti desítky balíčků, nemůže je znát tak dobře, jako kmenoví vývojáři, kteří dělají na jednom nebo několika projektech. Samozřejmě existují výjimky, kdy se distribuční správce může s upstream vývojáři směle měřit, ale není to tak vždy.

    Upstream vývojáři samozřejmě také zvažují, jaké dopady budou mít jejich změny. Také se snaží nic zbytečně nerozbíjet, dělat změny zpětně kompatibilně, nové funkce přidávat do „velkých“ verzí. Jenže někdy holt máte na výběr jenom mezi několika špatnými variantami, a musíte vybrat tu nejméně špatnou. K čemuž má ten upstream vývojář obvykle lepší předpoklady, než správce distribučního forku.

  • 21. 5. 2020 23:08

    Vít Šesták

    Popravdě, už jsem viděl nějaký balíček (bohužel si nevzpomínám který) fakticky vyvíjený spíše v patchích distribucí, protože upstream se na to vykašlal. A asi to byl i celkem bězný balíček.

    > Jenže někdy holt máte na výběr jenom mezi několika špatnými variantami, a musíte vybrat tu nejméně špatnou.

    To je pravda. Je to vidět třeba u systémových balíčků (X11, glibc, GTK, …), kde je občas potřeba některé věci vzájemně sladit. Pokud byste uživateli hned dával věci z upstreamu, nejspíš bude dříve nebo později takový problém řešit. Uživatelé Arch Linuxu na to jsou asi celkem zvyklí, uživatelé Ubuntu už tolik ne.

    Podobně někdy můžete chtít počkat s updatem. Změny v GUI nemusí být ještě tak kritické (ostatně každá změna někoho naštve, ale lidě si obvykle zvyknou), ale nekompatibilní změna v konfiguraci serveru může být problém. Server na Debianu tak typicky není problém nechat aktualizovat automaticky (což se minimálně kvůli bezpečnostním opravám hodí…). Na jedné straně máte riziko bugu v programu, na druhé straně máte riziko problematického updatu.

  • 21. 5. 2020 23:31

    Filip Jirsák

    Jistě že výjimky existují. Ale to, že se nějaký balíček vyvíjí v patchích distribucí nevyváží to, že se desítky tisíc balíčků vyvíjí v upstreamu. Pokud to u toho jednoho balíčku trvá delší dobu, stejně vznikne fork.

    Na systémových balíčcích závisí spousta jiných knihoven a aplikací. To je něco úplně jiného, než Knot Resolver, který je až na konci – na něm už nezávisí nic. Druhá věc je, že pokud takovýhle systémový balíček něco rozbije, mají se to dozvědět vývojáři upstreamu a opravit to. Ne že si to distributor pytlíkuje nějak po svém. Já neříkám, že se mají nové verze z upstreamu hned bez kontroly dávat uživatelům. Vyjde nová verze 5.6.1, dsitributor zjistí, že se něco v jeho distribuci rozbilo, tak verzi nevydává, ale zařídí opravu a v distribuci půjde ven upstream verze 5.6.2, kde už je to opravené.

    Problematičnost updatu roste s tím, jak dlouhá doba uplynula od posledního updatu. Automatické aktualizace kvůli bezpečnostním opravám jsou samozřejmě užitečná věc – problém je, že to často nejsou bezpečnostní opravy, ale „bezpečnostní opravy“. Tváří se to oprava, ale problém to neřeší, nebo řeší jen částečně, nebo to jiný problém vytváří.

  • 21. 5. 2020 23:56

    Danny

    To je vase chimera, ze na kresd uz nemusi nic zaviset. Aspon si ty release notes prectete, nez priste vypustite dalsi podobnou blbost. Ono totiz to neni jen odpovidatko na standardizovanych tcp/udp portech, jak si mozna myslite :) A to ze to sam nepotrebujete fakt neimplikuje, ze to nekdo jiny nekde jinde nevyuzije.

  • 22. 5. 2020 8:12

    Danny

    Tak napriklad v pripade Bindu takto existuje DLZ modul integrujici Sambu (AD) do DNS. Na otazku kolik je podobnych modulu Vam nikdo kvalifikovane neodpovi. Kdyby takove veci nemely smysl, nemelo by smysl vyvijet ani API rozhrani v pripade Knot Resolveru. Jenze ono se takove rozhrani vyviji - takze asi to nejaky smysl ma :-) Bez ohledu na vas nazor.

  • 22. 5. 2020 8:50

    Filip Jirsák

    Ano, to je dobrý příklad, proč je špatně, když jeden kus DNS softwaru implementuje autoritativní DNS server i DNS resolver. To, že to má špatně Bind, ale neznamená, že to tak musí mít i všichni ostatní.

  • 22. 5. 2020 9:46

    Danny

    V prostredi nejake male site napr. neni zadny objektivni duvod, proc oddelovat autoritativni server (ktery je autoritativnim jen pro vnitrni zony) od rekurzoru. Takto to nema implementovane jen Bind, ale treba i dnsmasq. A rikate, ze to delaji spatne? :-) To ale nevykladejte me, to bezte vysvetlit autorum tech daemonu, potazmo muzete jit (na IETF) vynadat i autorum DNS RFC, ze pro DNS rekurzor pouzili stejny tcp/udp port, jako pro autoritativni DNS :-) Dejte pak vedet, jak jste pochodil.

  • 22. 5. 2020 10:28

    Filip Jirsák

    Řeč nebyla jen o malých sítích. A Bind rozhodně není server jen pro malé sítě. Vnitřní zóny jsou zase jiný problém.

    To, že se dříve nerozlišoval DNS provoz mezi klientem a rekurzorem a mezi rekurzorem a autoritativním server, neznamená, že je to tak z dnešního pohledu správně. Stejně to bylo třeba se SMTP a tam se nakonec přistoupilo k rozdělení – RFC 6409 definuje pro odesílání e-mailů port 587.

  • 22. 5. 2020 10:35

    Petr Špaček

    Když jste to nakousli, tak IETF dnsop i operátoři kteří se projevují na odborných konferencích zaměřených na DNS se dnes (lépe řečeno v téhle dekádě) shodují na tom, že autoritativní server a rekurzor měly být dvě oddělené věci, a dokonce zaznívají i hlasy že by byla chyba dát je na stejný port.

    Ve skutečnosti se pro komunikaci stub<->resolver a resover<->auth používají dva různé protokoly (s různým významem!), které shodou historických okolností používají stejný binární formát.

    BIND je jediný používaný software který kombinuje rekurzivní resolver a autoritativní server. dnsmasq je stub resolver a to je úplně jiná liga, nesrovnávejme jablka a hrušky.

  • 22. 5. 2020 11:07

    Danny

    Co si alespon precist manual? :-) Hned v preambuli naleznete: It can also act as the authoritative DNS server for one or more domains, allowing local names to appear in the global DNS. A samozrejme nize to mate rozvedene do detailu. Preji prijemne cteni! :-) Netvrdim, ze bych to treba ja takto chtel nekde provozovat, ale soucasne neplati ani vase tvrzeni o dnsmasqu (dle definice stub resolveru ad RFC 1034).

  • 22. 5. 2020 13:10

    Danny

    A opet se mylite. Tato definice MSA vznikla jiz v roce 1998 v RFC 2476 a nikoliv az v roce 2011 ve Vami odkazanem RFC, ktere jen to historicke RFC (s mezikrokem pres RFC4409) aktualizuje. Proste to neni vubec zadna novinka, tento standard tu je s nami uz dele jak 20 let. Vami odkazovane RFC ma navic aktualizaci v podobe RFC 8314, dle ktereho je i ten port 587 se cleartext/STARTTLS deprecated a pouzivat by se mel naopak port 465 s implicitnim TLS.... kdyz uz me teda chtete poucovat s tim, jak spravne odesilat email v roce 2020 ;-)

  • 22. 5. 2020 13:17

    Filip Jirsák

    Danny: Kde přesně se mýlím? Kde jsem psal, ve kterém roce to vzniklo? Kde jsem psal, že to v RFC 6409 vzniklo? Kde jsem psal, že je to novinka? Aha, nikde. To si jen vy vymýšlíte. S RFC 8314 jsem vám to nechtěl komplikovat, aby tam byla jen jedna změna protokolu a ne dvě – evidentně i ta jedna změna je pro vás příliš komplikovaná. Howgh.

  • 22. 5. 2020 13:55

    Danny

    Veta "Stejně to bylo třeba se SMTP a tam se nakonec přistoupilo k rozdělení – RFC 6409 definuje pro odesílání e-mailů port 587". Nikoliv, k tomu rozdeleni se pristoupilo jiz v RFC 2476, na ktere ale mnozi kaslou jeste dnes a tcp/25 porad jako substitut MSA pouzivaji (treba Centrum). A explicitne odkazujete na tcp/587, ktery je ale prave tim RFC 8314 oznacen jako uz zastaraly mechanismus, stejne jako je davno zastarale pouzivat tcp/25... proste moderni MSA pouziva tcp/465 s implicitnim TLS. Dva roky zastaraly je fakticky cely koncept STARTTLS mechanismu pro pripojeni MUA, a vy jej tu dnes vypichnete... to je ten vas omyl, trosku jste zaspal dobu a recma o tom, ze jste to nechtel komplikovat to fakt neokecate :-)

  • 22. 5. 2020 10:03

    Petr Špaček

    Když už srovnáváme s BINDem ... 5 let jsem byl v Red Hatu vývojářem https://pagure.io/bind-dyndb-ldap, což je LDAP backend pro BIND, takže z vlastní zkušenosti vím, že BIND API pro moduly není stabilní. bind-dyndb-ldap se musel patchovat pro každou minor verzi, a někdy i když se nezměnilo API tak se změnilo ABI a muselo se to celé přebuildit.

    API modulů jsou zkrátka hodně provázaná se jádrem a garantovat jejich stabilitu je prostě těžké, takže to nedělá ani BIND, který si jinak na kompatibilitě velmi zakládá.

  • 21. 5. 2020 23:57

    Vít Šesták

    > Knot Resolver, který je až na konci – na něm už nezávisí nic.

    To je pravda, ale když jste začal tak obecná tvrzení, pustil jsem se též do obecných tvrzení.

    > Druhá věc je, že pokud takovýhle systémový balíček něco rozbije, mají se to dozvědět vývojáři upstreamu a opravit to. Ne že si to distributor pytlíkuje nějak po svém.

    Význam Debianu / RHEL / … není v tom, že byste měl ten stejný software, který má navíc patche od distributora. Máte starší software, do kterého jsou některé věci (zejména opravy kritických chyb) vyřešeny pomocí patchů od distributora.

    > Vyjde nová verze 5.6.1, dsitributor zjistí, že se něco v jeho distribuci rozbilo, tak verzi nevydává, ale zařídí opravu a v distribuci půjde ven upstream verze 5.6.2, kde už je to opravené.

    V ideálním světě ano. Ale reálně se může stát i spousta jiných věcí:

    a. Aplikace rozbije zpětnou kompatibilitu a oznámí to.
    b. Aplikace rozbije zpětnou kompatibilitu omylem, a projeví se to jen při speciálních konfiguracích.
    c. Aplikace bude formálně zpětně kompatibilní, ale třeba konfigurace se bude často spoléhat na nějakou nedokumentovanou vlastnost. Aplikace je v tom svým způsobem nevinně, ale reálně update způsobí problémy.

    Co z toho zvládne distributor detekovat a vyřešit? Nebude v některých případech backportování znamenat nižší riziko než rolling release?

    > Problematičnost updatu roste s tím, jak dlouhá doba uplynula od posledního updatu.

    Jestli narážíte na upgrady (např. z LTS na LTS), mohu si je naplánovat tak, abych měl čas řešit případné problémy, a nezastihlo mě to nevhod.

  • 22. 5. 2020 0:46

    Filip Jirsák

    zejména opravy kritických chyb
    Problém je v tom, že tohle není pravda. Správně má být „zejména pokusy o opravy některých kritických chyb“. Kdyby to byla pravda, že jsou tam opravovány všechny vážné chyby, já bych proti tomu neřekl ani slovo. Problém je v tom, že se neřeší všechny chyby, protože to často bez rozbití zpětné kompatibility nejde. A i ty chyby, které se někdo pokusí řešit, nemusí být vyřešeny úspěšně.

    Nebude v některých případech backportování znamenat nižší riziko než rolling release?
    Ne. Navíc distribuční patche výrazně zvyšují pravděpodobnost b) a c).

    Jestli narážíte na upgrady (např. z LTS na LTS), mohu si je naplánovat tak, abych měl čas řešit případné problémy, a nezastihlo mě to nevhod.
    To platí o všech updatech. Ovšem pokud je každý update jen malá změna, je riziko problémů podstatně menší, jejich řešení jednodušší a rychlejší, a případný návrat k předchozí verzi jednodušší.

  • 22. 5. 2020 9:56

    Vít Šesták

    Bezpečnost je v praxi věcí kompromisu. Máte-li bezpečnostní opravu, je ideální, aby ji nasadilo co nejvíce lidí co nejdříve. Tomu napomáhají bezproblémové aktualizace.

    Zranitelnosti jako buffer overflow jsou celkem snadné na opravu, tady není moc co řešit. Pokud jde o koncepční problém, je to těžší – máme radši odradit hromadu uživatelů od okamžitých upgradů, nebo být na koncepční změny opatrnější?

  • 22. 5. 2020 10:21

    Filip Jirsák

    Podle mne „opatrnější“ neznamená „neopravovat bezpečnostní chyby“.

    Že je potřeba, aby byly aktualizace co nejvíc bezproblémové, s tím naprosto souhlasím. A je to přesně to, o čem jsem začal psát. Je potřeba zbavovat se různých brzd, které brání bezproblémovým aktualizacím – například LTS verze.

  • 22. 5. 2020 10:54

    Danny

    LTS ale zadnou brzdou v aktualizacich opravdu neni. Skutecnou prekazkou pro bezproblemove aktualizace na ty nejnovejsi verze jsou nekompatibilni zmeny provadene vyvojari - v pripade kresd (at jsme konkretni) treba uplne zruseni podpory pro systemd sockety pocinaje verzi 5.0 letos na konci ledna. Takze uzivatel na Debianu nadsene upgradujici z distribucni 3.2.1-4.3.0 na dnesni 5.1.1 bude dost nemile prekvapeny, zeano :) A hlavne bude pomerne komplikovany automaticky update formou tech unattended-upgrades.

  • 22. 5. 2020 11:16

    Filip Jirsák

    LTS ale zadnou brzdou v aktualizacich opravdu neni.
    Aha, takže vy jste ve své distribuci normálně aktualizoval na poslední verzi Knot Resolveru, takže vaše prosba o patchování starších verzí je bezpředmětná.

    Skutecnou prekazkou pro bezproblemove aktualizace na ty nejnovejsi verze jsou nekompatibilni zmeny provadene vyvojari
    Už jsem zde vysvětloval, že někdy jsou nekompatibilní změny nutné i kvůli opravě bezpečnostních chyb. Zkrátka se nekompatibilním změnám nelze vyhnout. Tedy se musíte naučit s nimi nějak vypořádat. A když už se umíte vypořádat s těmi nutnými změnami, vypořádáte se i s těmi, které z vašeho pohledu nutné nejsou.

    Takze uzivatel na Debianu nadsene upgradujici z distribucni 3.2.1-4.3.0 na dnesni 5.1.1 bude dost nemile prekvapeny, zeano :)
    Pokud uživatel dělá upgrade distribučního balíčku a je nemile překvapen, je to chyba distribuce. Podle mne je to jedna ze základních úloh distribuce – provést uživatele upgradem tak, aby nebyl nemile překvapen.

    A hlavne bude pomerne komplikovany automaticky update formou tech unattended-upgrades.
    Pokud distribuce neumí udělat bezobslužnou aktualizaci všeho, ať to dá vědět uživateli a má mechanismus, jak uživatele upozornit, že je potřeba udělat asistovanou aktualizaci. Mně asistovaná aktualizace nijak neuráží. Vím, že svět není černobílý, že některé aktualizace by bylo příliš obtížné zautomatizovat – nechci nic jiného, než aby to, co jde udělat automaticky, proběhlo automaticky, a o zbytku abych se dozvěděl a provedl to ručně.

    Mimochodem, když se před deseti nebo patnácti lety někdo ptal, jak má do své distribuce dostat nejnovější pár měsíců starou verzi aplikace, když v jeho distribuci je starší verze, odpovídal jsem na to – vy máte ty verze aplikací, které máte dostupné v distribuci. Nestarejte se o to, že je někde k dispozici novější verze – berte to tak, že je to verze pro jiný operační systém. Jenže svět se od té doby změnil, je mnohem větší tlak na rychlejší opravy chyb, protože chyby se reálně zneužívají. Proto je potřeba používat nejnovější upstream verze, protože tam je největší množství známých chyb opraveno. Pokud distribuce umí nabízet jenom staré verze aplikací, v dnešním světě prostě neobstojí. Může se vám to nelíbit, můžete proti tomu protestovat, ale to nic nezmění na tom, že provozovat staré verze software je čím dál víc nepřijatelné.

  • 22. 5. 2020 11:35

    Petr Špaček

    Pánové, pojďme se bavit věcně, zvrhává se to do flamewaru.

    1. Ano, Knot Resolver dělá nekompatibilní změny častěji než jiné projekty - vždy po důkladném zvážení a ne jen "protože můžeme".

    2. To, že je nějaká změna je nekompatibilní automaticky neznamená, že způsobí problémy při upgrade balíčku. "Upgrading guide" popisuje i změny, které upgrade balíčku řeší (nebo by měl řešit) automaticky.
    Pokud by Debian maintainer měl zájem, tak by mohl použít upgrade skript který je k dispozici v našem repu: https://gitlab.labs.nic.cz/knot/knot-resolver/-/blob/master/utils/upgrade/upgrade-4-to-5.lua.in

    Kupodivu naši uživatelé co si Resolver kompilují sami (a musí tedy projít a aplikovat pokyny z upgrading guide ručně) si na tyto změny nestěžují - v diskusích ale slyšíme stížnosti lidí, za které by změny měly řešit balíčky. Příčinám nerozumím.

    3. To, že nejsme schopní se dohodnout s Debian maintainery, aby byly naše balíčky v distribucích udržované nás dlouhodobě mrzí a snažíme se to řešit. Z toho důvodu hledáme posily: https://www.nic.cz/page/321/kariera-v-cznic/#labs_linux

    Nevím, co dalšího dodat. Mám pocit, že se točíme v kruzích.

  • 22. 5. 2020 12:03

    Danny

    Odstraneni podpory pro systemd sockety z kresd skutecne nesouvisi s opravou nejake bezpecnostni chyby. Ktere navic prislo tak nejak narychlo, jeste ve verzi 4.3 na zacatku prosince 2019 nebyl ani naznak ruseni (byva zvykem uzivatele nejprve predem upozornit, ze nejaka feature je deprecated a bude ostranena) a v na konci ledna vyjde 5.0 a najednou bum, prask - a je to pryc. Rozdil ve vydanich: pouhe dva mesice. To vazne nelze hazet na hrb distributorum balicku, aby se s podobnou divocinou vyporadavali tak, aby uzivatel nepostrehl funkcni problem.

    Asistovana prubezna rucni bezpecnostni aktualizace doplnena o nekompatibilni zmeny prilis neskaluje v prostredi, kde mate stovky spravovanych stroju - kde v zavislosti na konkretnich use-case jsou pochopitelne ruzne konfigurace. To je reseni pouzitelne na osobnim desktopu ci s par spravovanymi stroji. Jenze ani to Vy prokazatelne ovladate jen teoreticky, ale sve teze ani nedokazete uvest do praktickeho zivota.

    Je opravdu vtipne, ze zrovna Vy mi zde prednasite o aktualizacich - a pritom sam jeste na konci kvetna nemate aktualizovany svuj system, kde chybi prinejmensim zaplaty vydane uz v lednu... a na ktere zadna specialni asistence ani potreba neni a dokonce to muze probehnout automaticky :-)

  • 22. 5. 2020 12:47

    Petr Špaček

    Myslel jsem, že už nebudu reagovat protože bylo vše řečeno, ale musím uvést na pravou míru další argumentační faul a doložitelnou lež:

    Cituji:
    Odstraneni podpory pro systemd sockety z kresd skutecne nesouvisi s opravou nejake bezpecnostni chyby.
    To ani nikdo netvrdil, nebo jsem přehlédl nějaký komentíř? Považuji to za další argumentační faul.

    Cituji:
    ... Ktere navic prislo tak nejak narychlo, jeste ve verzi 4.3 na zacatku prosince 2019 nebyl ani naznak ruseni (byva zvykem uzivatele nejprve predem upozornit, ze nejaka feature je deprecated a bude ostranena) a v na konci ledna vyjde 5.0 a najednou bum, prask - a je to pryc. Rozdil ve vydanich: pouhe dva mesice. To vazne nelze hazet na hrb distributorum balicku, aby se s podobnou divocinou vyporadavali tak, aby uzivatel nepostrehl funkcni problem.

    To že je socket aktivace problematická se probíralo na knot-resolver-users již v červnu 2019, tj.
    https://lists.nic.cz/pipermail/knot-resolver-users/2019/000182.html

    Přímo v tomto vlákně reaguje Daniel Kahn Gillmor, který je maintainer Debian balíčku. Z toho vyvozuji, že tvrzení o překvapujícím vývoji je nepravdivé.

    Pro ulehčení práce navíc distribuce dostaly k dispozici upgrade skript a v našem repu i příklady jak se dá použít z RPM/Deb upgrade scriptletu, takže i u takto masivní změny šlo připravit plně automatický upgrade.

    (Pokud by se půl roku zdálo málo, tak Daniel Kahn Gillmor, tedy Debian maintainer, upozorňoval na omezení socket aktivace již v únoru 2018
    v https://github.com/systemd/systemd/issues/8096, takže byl dost v obraze. Kromě obtížné konfigurace to navíc způsobovalo výkonnostní problémy.)

  • 22. 5. 2020 14:31

    Danny

    A opravdu si myslite, ze je v silach kazdeho uzivatele byt prihlaseny na vsech -users mailing-listech vseho software, ktery pouziva? Ve kterem vesmiru to prosim zijete? :-)

    Ale bezva, takze nekdo si historicky postezoval na mailing-listu, ze to je pro nej slozite nastavit - tak jste to projistotu smazli podporu uplne? No to je fakt komicky duvod :-) Ten maintainer z Debianu vam v tom vlakne k tomu Vasemu "tentativelly we plan to remove socket activation in one of future versions but specific date or release version was not set yet" napsal, cituji: "I'd be disappointed with this move, if it happens. In addition to keeping sockets open across a restarted daemon, socket activation is a useful way to ensure that the daemon stays constrained, and also a way to keep the system running with a minimal configuration.". Anglicky doufam umite.

    Takze si to shrneme - v celem diskuznim vlakne k tematu jsou ctyri prispevky. Z toho jediny od nekoho mimo CZ.NIC, ktery napise, ze z toho planovaneho kroku vubec nadseny neni. A vy tu podporu pro systemd sockety stejne proste odstranite, tomu jedinemu nazoru v debate navzdory. A pak jeste v diskuzich fnukate, ze se s vami po teto zkusenosti maintainer z Debianu moc nebavi, potom co aktivne na knot-resolver-users demonstrujete jak vas jeho nazor vlastne vubec nezajima.

  • 22. 5. 2020 12:58

    Filip Jirsák

    Doporučil bych zaměřit se na význam slova „někdy“ a pochopit význam věty „když už to umíte pro tyhle případy, můžete to použít i pro ty ostatní“.

    Odstraneni podpory pro systemd sockety z kresd skutecne nesouvisi s opravou nejake bezpecnostni chyby.
    To je právě ten váš naivní pohled, že se o každé opravě bezpečnostní chyby dozvíte v nějakém přehledu. Podpora soketové aktivace nikoli nepodstatným způsobem komplikovala kód pro konfiguraci sítě. Situaci znám jen z release notes, takže netuším, jaká byla nálada mezi vývojáři – jestli třeba měli nějaké podezření, že tam chyby nebo dokonce bezpečnostní chyby mohou být; nebo jestli byli přesvědčení, že ten kód je v pořádku, jenom situaci zbytečně komplikuje. Na druhou stranu, nedovedu si představit situaci, kdy bych jako vývojář odstranil nějaký kód s odůvodněním, že je zbytečně komplikovaný, v situaci, kdy bych byl přesvědčený, že ten kód je v pořádku. Takovéhle úpravy se dělají v okamžiku, kdy víte, že tam něco smrdí, a chcete se potenciální chyby zbavit dřív, než se někde opravdu projeví.

    Takže ona to dost možná byla oprava nějaké bezpečnostní chyby, o které ale zatím nikdo nevěděl (ani vývojáři). Nebo tím mohli předejít vzniku chyby v budoucnosti. Protože tenhle typ kódu – zbytečně komplikovaný kód, který nikdo nechce – ve kterém vlastně žádná chyba není, akorát že ho někdo jednou použije jinak, než bylo zamýšleno, a teprve tou kombinací se vyrobí bezpečnostní díra. Což je mimochodem přesně ten mechanismus, který je nebezpečný pro backportování oprav – protože opravu přenesete do jiného kontextu, ve kterém s ní nikdo nepočítal. A ten, kdo to přenáší, si nemusí uvědomit všechny souvislosti.

    To je přesně ten případ, o kterém jsem psal, a který žádné backporty oprav nezachytí. Že chyby, včetně bezpečnostních, se opravují i při běžném vývoji (vylepšování) programu. prostě je to kód, o kterém nikdo neví, že je tam chyba. Nebo to někdo ví a tají to, aby ji mohl zneužívat. Ani vývojáři si nejsou vědomi toho, že by v kódu byla chyba. Ale ten kód se jim nezdá, nedali by za něj ruku do ohně, vyhýbají se mu, nelíbí se jim. Až jim jednoho dne dojde trpělivost a ten kód přepíšou nebo zahodí. Pokud tam ta chyba byla, tak ji takhle odstraní. Protože chyby nejsou kvantové jevy, chyba v programu je, i když ji nikdo nepozoroval.

    Jenze ani to Vy prokazatelne ovladate jen teoreticky, ale sve teze ani nedokazete uvest do praktickeho zivota.
    Právě že s vývojem trochu zkušeností mám. Takže vím, že zdaleka ne všechny opravy chyb (včetně bezpečnostních) jsou někde zaevidované – vývojář si to často ani neuvědomí, že to, co právě opravil, byla bezpečnostní chyba. A když to není nikde zaevidované, nemůže se o tom dozvědět distribuční správce, aby tu opravu backportoval. A také vím, že oprava spousty chyb se nedá izolovat do jednoho patche. Můžete mít dvě podobné funkce X a Y, v červnu někdo najde potenciální chybu ve funkci Y a opraví ji, za půl roku někdo zjistí bezpečnostní chybu ve funkci A, která volá X – a opraví to tak, že místo X bude nově volat Y. I zaraduje se distribuční správce, že má patch opravující bezpečnostní chybu a backportuje ho do své staré verze, takže i v jeho verzi bude funkce A volat nově funkci Y. Jenže volá starou funkci Y, která je v té distribuční verzi ta stará, bez oné červnové drobné opravy, která neřešila žádný bezpečnostní problém. No a v takové situaci jsou různé možnosti – nejpravděpodobnější je, že ta oprava i tak bude fungovat. Méně časté je, ale stává se to dost často, že ta oprava nebude mít žádný efekt nebo jen částečný, tj. pořád bude možné chybu zneužít, i když to bude komplikovanější. No a někdy se zadaří a tímhle způsobem se vyrobí mnohem závažnější chyba,než co ten patch opravoval. No ale tohle celé se neděje v upstreamu, ale v nějaké distribuci v rámci patchování, při kterém se přece nemůže nic stát, takže se to ani pořádně neotestuje.

    Je to naprosto identická situace, jako když vývojář vyrobí chybu při přidávání nové funkce programu. Backportování oprav totiž není nic jiného, přestože se neustále tváříte, že při backportování žádná chyba vzniknout nemůže. Může, ten princip je úplně stejný.

    „Drobný“ rozdíl tam ale je. Tu novou funkcionalitu píše typicky vývojář, který tu aplikaci zná, zná souvislosti toho, co dělá. Ten backport v distribuci často dělá někdo, kdo má na starosti desítky balíčků a ten kód jenom mechanicky přenese, aniž by rozuměl podstatě problému nebo dokonce dohlédl alespoň některé souvislosti. A pak je tam ještě ten rozdíl, že změna v upstreamu se bude testovat v upstreamu a pak ještě v distribucích, zatímco ten distribuční backport se bude testovat jenom v té jedné distribuci.

    Můžete hádat, jaká asi bude pravděpodobnost, že ty distribuční backporty budou stejně kvalitní, jako kód v upstreamu.

  • 22. 5. 2020 15:36

    Petr M

    @Danny:

    Představ si imaginární kus software. Běží na serveru, ukládá si nějaký data a používá hash. Má release cyklus půl roku. Používá se SHA-1, ale jak vyšlo najevo, že SHA-1 je nakřáplá (aktuální verze 11), připravili se autoři na přechod na SHA-256. To dává, kvůli bezpečnosti, smysl. Nebo ne?
    Protože autoři chtěli zachovat kompatibilitu co nejdýl, rozhodli se jet podle tohoto scénáře:
    - Verze 12: Do konfig file přidána nepovinná volba "HASH = SHA1" nebo "HASH=SHA256". Pokud chybí, používá dál SHA-1. A půl roku, do odladění beta testerama, je SHA-256 označená jako experimentální a neručí za chyby při používání. A přidají konverzi dat ze starýho formátu na nový.
    - Verze 13: SHA-256 má plnou podporu, ale výchozí je stále SHA-1. Admin má možnost volby v konfigu.
    - Verze 14: Protože se ve verzi 13 neobjevila chyba, týkající se SHA-256, je defaultní hodnota překlopena na SHA-256. Volba použícání SHA-1 zatím zůstává, ale je potřeba to explicitně vynutit.
    - Protože podle ankety uživatelů ve verzi 16 drtivá většina uživatelů formát neřešila nebo používala explicitně SHA-256, byla ve verzi 17 zakázana volba SHA-256 (ale pro kompatibilitu s budoucí verzí po načnutí SHA-256 byla volba ponechána, za pár let se bude hodit). Konverzní kód na nový formát zůstává.
    - Po roce (verze 19) je odstraněn i nepotřebný kód pro konverzi. Byl tam jenom kvůli obnovení záloh a kdo nezálohuje dýl jak půl roku, ten o svoje data nestojí.


    No a teď mějme dva adminy. Adama a Břéťu. Jsou to spolužáci, ale nemají se rádi a dělají pro konkurenční firmy. Adam jede na rolling distru, Břéťa ujíždí na LTS. Oba nabízí na severech zákazníkům výše uvedený program.

    Adam: Má aktuální verzi. Nic neřeší, jenom pokud si zákazník řekne, že ve v13 chce SHA-256, dopíše řádek do konfigu. A ten tam pak může zůstat. Jinak při update v13 na v14 přemigrují i data (kdyby to nedopadlo, dělá před updatem zálohy a stačí v konfigu nastavit do opravy chyby SHA-1).

    Břéťa: Má v LTS verzi 10, LTS verzi používá pět let a pak migruje rovnou na verzi 20. Data má hashovaný SHA-1 a "bezpečnostní záplaty" v podstatě jenom na rozhraní ven, protože vyhožení načnutýho hashe maintainer nepovažuje za bezpečnostní update. Všechno funguje do chvíle, kdy upgraduje systém a zjistí, že data z verze 10 zapíše jako poslední verze 16 (-2 roky ) a přečte 18ka (-1 rok). Ta v jeho distru není a poraď si, jak umíš.


    No a tohle je právě důvod, proč LTSkaři mají z updatů hrůzu jak jeptiška z pánskýho přirození. Vždycky takhle něco pros..ou a pak hodně bolí to po změně rozchodit a nepřijít o data.

    Btw, zmínil jsem se, že rok před updatem Břéťovi volal obchodník a ptal se, co používají za hash? Tak to jenom obchodník odpovídal firmě, která měla zájem utratit u nich nemalý prachy, ale v bezpečnostní směrnici měli zákaz MD-5 a SHA-1. Tak ty prachy dali Adamovi.


    P.S. K podpoře starších verzí v Red Hatu, Canonicalu a SuSe: Zákazník chce starou verzi, zákazník zaplatí starou verzi, zákazník dostane starou verzi. Sami od sebe to dělat nebudou.

  • 22. 5. 2020 21:33

    Vít Šesták

    Samozřejmě na každý způsob řešení najdeme worst case scenario. Navíc záleží na předpokladech:

    * LTS může vyvíjet původní autor (např. Firefox ESR), nebo se o něj může pokusit někdo na vlastní pěst. Což může vést k lepším či horším výsledkům…
    * LTS může být ultrakonzervativní, nebo může zavádět i nějaké menší a konzervativnější novinky.
    * Software může být v aktuální verzi různě otestovaný.
    * Upstream může celkem dobře dbáty na zpětnou kompatibilitu (z různých hledisek), nebo ji může více či méně úmyslně bořit a lépe nebo hůře o tom informovat.

    Předpoklady si můžeme představit různě a podle toho budou i různé výsledky. U svého počítače si můžu dovolit, když se mi občas něco rozbije. Pokud mám server nrbo pokud spravuju počítač někomu, už su to třeba dovolit nemohu. Tam bych v ideálním případě chtél:

    * Automaticky aplikovat co nejvíče bezpečnostních oprav.
    * V případě nekompatibilní změny není moc žádoucí, aby se použila automaticky, aby se něco nerozbilo. V některých případech (Remote Code Execution) to může být menší zlo, jindy (třeba DoS) může být riziko příliš malé na to, aby ospravedlnilo riziko automatického upgradu.
    * Pokud nemá dojít k automatické změně, bylo by vhodné, abych byl informován, že musím něco udělat ručně.
    * Nové fíčury mohou být fajn, ale taky mohou přinášet nové chyby. To je otázka vhodného vyvážení rizik.

    Co z dostupných možností je nejblíže? Asi jak kdy.

  • 21. 5. 2020 22:54

    Danny

    Nikdo po vyvojarich knot resolveru nechce, aby se starali o hromadu cizich forku. Ale chtit LTS verzi, ktera bude mit oficialni zivotnost delsi nez par mesicu zas takovy problem snad neni, notabene kdyz nekompatibilni zmeny jsou celkem caste. Neni to problem u kernelu, neni u konkurencich projektu - dokonce i v CZNIC jine projekty toto zvladaji - treba u Turris OS, dokonce i u autoritativniho Knotu ma nejakou podporu i starsi verze navzdory vydani verze nove. Proc by to nemohl zvladnout i team kolem resolveru? ;-)

  • 21. 5. 2020 23:56

    Filip Jirsák

    Já bych to nazýval pravým jménem. Ne LTS verze, ale „verze se známými neopravenými chybami, která má jako bonus navíc ještě zcela nové chyby, které nikdo neřeší“.

    Důvod, proč LTS verze nefungují, už jsem tu vysvětloval. NXNSAtacku se lze bránit dvěma způsoby, jeden útočníka eliminuje 100% ale nezabere ve všech případech; druhý je hack, který znamená, že software nefunguje úplně správně – ale dá se to s pomocí věštění z křišťálové koule naladit tak, aby to většinou moc neškodilo ale útočníkům většinou neposkytlo moc prostoru k útoku. No, a ten první způsob prostě jednoznačně je nová vlastnost, která v LTS verzi nemá co dělat – a byla přidána relativně nedávno, takže spousta LTS distribucí tuhle verzi nejspíš ještě nemá. Takže ještě jednou opakuji, u koncového softwaru „LTS“ znamená „známé neopravené chyby“.

    Jenom bych připomněl jak dlouho trvá, než se třeba na webu podařilo zbavit starých nebezpečných verzí SSL nebo slabých šifer. A proč? Protože LTS. A jak se to podařilo změnit? Teprve tak, že si autoři prohlížečů prosadili, že kašlou na LTS verze, vydávají prostě pravidelně nové verze prohlížeče a staré verze je nezajímají. To samé se muselo udělat se SSL knihovnami, když se ukázalo, že OpenSSL je přímo výstavní kousek LTS softwaru, akorát že je kvůli tomu děravá jak řešeto. V roce 2020 se konečně mohl udělat DNS flag day, protože už snad vypršela podpora všech LTS. Zavádění DNSSEC nebo IPv6 brzdí mimo jiné i LTS verze.

    Není to poněkud nápadné, že bezpečnostně citlivý software opakovaně skokově zvýší svou bezpečnost po té, co se vymaní z okovů LTS?

    Proc by to nemohl zvladnout i team kolem resolveru? ;-)
    Otázka není, proč by to nemohl zvládnout. Otázka je, proč by to dělal. K čemu je dobré udržovat starou verzi se známými i neznámými chybami, když máte novou verzi, kde jsou ty známé chyby opravené? Jaká je motivace pokoušet se něco zalátat s nejistým výsledkem a s rizikem, že toho nakonec stejně daleko víc rozbij, když vím, že existuje opravená otestovaná verze, kde je to opravené správně – a jediný důvod, proč na ni někdo nepřejde je ten, že existuje jakási politika odtržená od dnešní reality?

    Odpověď vývojáře je jednoduchá. Chcete používat bezpečnou verzi? Používejte aktuální verzi, můžete si ji zkompilovat, můžete použít Docker balíček. Že vaše distribuce tu verzi nemá? Tak to je asi problém té distribuce, ne?

  • 22. 5. 2020 8:38

    Danny

    Ale ony LTS verze funguji. ISC opravu vydalo i pro starsi podporovane verze a v Debianu ji obratem integrovali - a tim minimalne snizili rizika spojena s NXNSAtackem. Aneb lepsi je udelat alespon neco - nez nedelat projistotu vubec nic. Oproti tomu u kresd nemame nic nez tu nejposlednejsi verzi - a vysledkem je akorat to, ze uzivatele pouzivaji verzi zatizenou uz ctyrmi CVE. Argument at si nasadi 5.1.1 neberu - ty zmeny v 5.x jsou pro prechod natolik zasadni, ze jen nestaci podstrcit novou verzi balicku a frci se dal. Neni to pouzitelne napr. v prostredi s unattended-upgrades, prave kvuli provedenym zmenam.

    Vas argument, ze XYZ brzdi LTS verze je zcela mimo. Nasilim - tedy zahubenim LTS verzi opravdu nedocilite toho, ze by lide zacli pouzivat posledni verze SW produktu. To nefunguje, vyzkouseno v praxi. Proste zustanou u stare verze a na jakekoliv zaplatovani cehokoliv se vykaslou. Stalo se to v pripade Windows (signifikantne u XP), stejne tak najdete spoustu stroju s davno nepodporovanymi Debiany ve vydanich Wheezy, Squeeze, Lenny, spousta lidi pouziva telefony a dalsi mobilni zarizeni s neaktualnim software - jen proto, ze vyrobce jiz neaktualizuje software - novy pristroj si kvuli tomu koupit nepobezi... a takto jde pokracovat, a vzdy se najde nejaky objektivni duvod, proc tomu tak je. Sundejte si ty sve ruzove bryle ;-) Realita sveta kolem nas je proste jina.

  • 22. 5. 2020 9:20

    Filip Jirsák

    Ale ony LTS verze funguji. ISC opravu vydalo i pro starsi podporovane verze a v Debianu ji obratem integrovali - a tim minimalne snizili rizika spojena s NXNSAtackem. Aneb lepsi je udelat alespon neco - nez nedelat projistotu vubec nic.
    Ano, na tom je krásně vidět ten rozdíl v našem přístupu. Pro mne software funguje, když je v něm co nejméně chyb. Pro vás funguje, když má aspoň o něco méně chyb, než jiný software.

    Prostě je báječné useknout si ruku, protože pak vám pořád ještě jedna ruka zbyde a budete na tom líp než lidé, kteří nemají žádnou ruku.

    Oproti tomu u kresd nemame nic nez tu nejposlednejsi verzi - a vysledkem je akorat to, ze uzivatele pouzivaji verzi zatizenou uz ctyrmi CVE.
    Teď ale popíráte sám sebe. Vždyť pořád prosazujete, že není potřeba opravovat všechny známé chyby, že stačí, když se opraví alespoň některé. A řada 4 nepochybně nějaké chyby opravila.

    To nefunguje, vyzkouseno v praxi.
    Proč tedy uvádíte právě opačné příklady?

    Proste zustanou u stare verze a na jakekoliv zaplatovani cehokoliv se vykaslou.
    Já jsem ovšem nikdy nepsal, že se verze LTS mají nahradit tím, že se aktualizace zastaví úplně. Píšu přesný opak – není možné držet několik let staré verze softwaru. Na aktualizace se kašle proto, že dělat aktualizaci jednou za několik let je pracné. A kašle se na ně proto, že se kašle na bezpečnost. Jenže bezpečnost je a bude čím dál důležitější, takže používání roky starého softwaru bude čím dál méně udržitelné.

    Stalo se to v pripade Windows (signifikantne u XP)
    Ano, Windows XP byla typická LTS verze, dlouho se nic moc neměnilo, lepila se jedna záplata na druhou, až už to přestalo být udržitelné a bylo potřeba udělat novou verzi revolucí. A ten přechod samozřejmě bolel. Microsoft už se z toho poučil a Windows 10 aktualizuje průběžně.

    najdete spoustu stroju s davno nepodporovanymi Debiany ve vydanich Wheezy, Squeeze, Lenny
    Protože jednorázový přechod na novou verzi by byl moc pracný.

    spousta lidi pouziva telefony a dalsi mobilni zarizeni s neaktualnim software - jen proto, ze vyrobce jiz neaktualizuje software - novy pristroj si kvuli tomu koupit nepobezi...
    Protože skokový přechod na novou verzi je pro výrobce moc pracný. Místo aby průběžně aktualizoval knihovny a aplikace X, Y, Z, ve kterých jsou opravy bezpečnostních chyb, drží to ve starých verzích, protože u aplikace A by musel trochu pracněji řešit přechod na novou verzi.

    Děkuji za tři dobré příklady toho, jak LTS verze nefungují, resp. způsobují používání nebezpečného softwaru.

    vzdy se najde nejaky objektivni duvod, proc tomu tak je.
    No, vyjmenoval jste tři příklady, a ve všech třech případech bylo tím objektivním důvodem používání LTS verze. Mně z toho skoro vychází, že by bylo lepší LTS verze nepoužívat.

    Realita sveta kolem nas je proste jina.
    Ano, realita je taková, že je čím dál větší tlak na používání bezpečného softwaru. Což zajistí jenom aktuální upstream verze. Buďto to distribuce pochopí a budou nabízet aktuální verze, nebo to nepochopí – a realita světa kolem nás se podle toho zařídí. Resp. ona už se zařizuje – Docker, Flatpak. Mimochodem, všimněte si některých novinek, se kterými přišly některé distribuce v posledních letech. Ubuntu přišlo se Snapem, Fedora má Silverblue a CoreOS. To všechno jsou snahy distribucí dostat k uživatelům co nejrychleji aktuální verze programů. Takže oni i autoři některých distribucí tu realitu světa kolem nás vidí a reagují na ni.

  • 22. 5. 2020 9:39

    Danny

    Tak zrovna Debian Lenny nebo Etch zadne LTS nemel, nastudujte si aspon ty verze, kdyz uz chcete vest polemiku. A jak Lenny, taki Etch se da v nejakych dnesnich produkcnich prostredich stale najit. Prvni LTS mel az Squeeze. Takze i argument, ze lidi kvuli zrovna existenci LTS neupgraduji je proste naprosto mimo. Stejne tak se dodnes najdou provozni XPcka. A je fakt vtipne, ze sam LTS provozujete, i kdyz proti nemu svymi slohovymi cvicenimi brojite :)

    Ono samozrejme linearni pochod po vydavanych verzich rozhodne neni bezproblemovy. Napriklad prechod z 4.3.0 na 5.0.0 kresd zrovna hladky taky neni - a pritom jde o vydani, ktera od sebe deli necele dva mesice. Tri mesice na to vysla verze 5.1.0, ktera opet neco rozbila.

  • 22. 5. 2020 15:55

    Petr M

    LTS verzi si můžu jako vývojář dovolit, pokud:
    (Má SW stabilní set požadavků a API) &&
    (Není bezpečnostně kritický) &&
    ( (SW pracuje offline a případnou chybou nic neohrozí) ||
    (Je SW testovatelný automaticky s pokrytím min. 98%, aby to zvládl testovat a vydávat Jenkins) ||
    (Najde se někdo, kdo je ochotný platit podporu staré verze) ||
    (Je to kritická část systému, na které visí cizí software) ||
    (zákazník si koupil starou verzi s garantovanou dobou podpory))

    Jinak je opravdu lepší držet jednu plně otestovanou a záplatovanou verzi a neplýtvat síly.

    22. 5. 2020, 15:56 editováno autorem komentáře

  • 21. 5. 2020 18:04

    Ondrej Nemecek

    To nesedí. Správné řešení je rozlišit feature verze (změna funkčnosti) a patch verze (opravy chyb). Distribuční maintaineři by měli primárně zapracovávat patch verze v rámci nezměněných features (a výrobci software by měli backporty připravovat sami, tj poskytovat patche pro živé verze svého sfotware), teprve v druhé řadě by měli distribuční maintaineři zapracovávat do distribuce nové feature verze.

    Že to je hodně práce o tom žádná, ale je to asi jediné systémové řešení, které dává smysl. Trochu jiná může být situace o rolling distribucí, tam se nové features snesou lépe, ale každý ví, že se občas něco porouchá a tak nenasadí rolling distribuci na produkční server, kde je požadována maximální stabilita.

  • 21. 5. 2020 21:35

    Filip Jirsák

    Správné řešení je rozlišit feature verze (změna funkčnosti) a patch verze (opravy chyb).
    Tohle rozlišení je ovšem jenom lež autorů distribucí. V reálném světě takové rozlišení neexistuje. Víte, jaká je nejlepší obrana Knot Resolveru před NXNSAttackem? Feature implementující RFC 8198. Teprve když tahle obrana nezafunguje, protože v cache nejsou příslušné záznamy, nastupuje ta druhá obrana v podobě omezení počtu dotazů na autoritativní servery. Která není moc hezká.

    Že to je hodně práce o tom žádná, ale je to asi jediné systémové řešení, které dává smysl.
    Systémové řešení založené na chybných předpokladech nedává smysl. Chybný předpoklad číslo jedna je ten, že lze změny v softwaru rozdělit na opravy chyb a nové vlastnosti. Ve skutečnosti je to škála, každá změna je trochu změna vlastností a trochu oprava chyb, liší se jen ten poměr. Krajní případy, kdy je něco jen oprava chyby nebo jen nová funkce jsou vzácné.

    Druhý chybný předpoklad je, že software se mění pomocí patchů. Ani to není pravda. Ano, mezi změnu a patchem může být vazba 1:1, ale není to tak vždy. A nemyslím tím případy, kde je jedna změna ve více patchích, nebo jeden patch implementuje více změn. Změna v aplikaci je něco, co je mimo kód – kód je jenom nástroj, jak tu změnu provést.

    Obě dvě skutečnosti jsou přímo vlastností softwaru, není to chyba programátorů. Programátoři mohou těm požadavkům trochu vycházet vstříc, ale nelze jim vyhovět zcela. O implementaci RFC 8198 do DNS resolveru nelze objektivně rozhodnout, zda je to implementace nové vlastnosti nebo zda je to bezpečností oprava NXNSAttacku. Je to obojí.

    Jediné systémové řešení, které dává smysl, je tu energii, která se dnes věnuje na nesmyslné vyváření backportů, věnovat na testování regresí v nových verzích. LTS je přístup „radši více chyb, ale známých, než méně chyb, ale neznámých“. Který měl smysl v době, kdy chyby zas až tak nikomu nevadily, protože neexistovalo nic jako „bezpečnostní chyby“. Jenže svět IT se změnil, chyba neznamená jen to, že se uživateli něco pokazilo a bude muset být v práci přesčas. Chyba dneska může znamenat bezpečnostní problém, únik citlivých dat, ztrátu dat, výpadek. Ty chyby jsou opravené v nových verzích aplikací.

    Backportování oprav chyb nemůže fungovat. Funguje to na klasické chyby v C typu buffer overflow. Ale dnes je spousta chyb jiných. Jsou to chyby v protokolech (jako NXNSAttachk), v architektuře, v návrhu. Opravy takovýchhle chyb nejde backportovat tak, že se jenom opraví chybné řádky programu a jinak se nic nezmění.

    To, že backportování patchů opravuje chyby a nezanáší žádné nové je jenom milosrdná lež. Ano, někdy to tak je. Dříve to tak bylo mnohem víc, než nyní. A bude to platit pořád méně a méně. Ty distribuce, které se s tím smíří a naučí se s tím fungovat, přežijou. Ostatní budou nahrazeny kontejnery. To, že je Docker tak oblíbený, je důsledek toho, že distribuce na tohle nedokázaly zareagovat včas. Situace, kdy je všechno zapečené v kontejneru a při opravě kterékoli knihovny je potřeba vytvořit nový kontejner, je samozřejmě docela špatně. No jo, ale distribuce jsou na tom bohužel ještě hůř, proto se to řeší těmi kontejnery.

  • 21. 5. 2020 22:38

    Ondrej Nemecek

    Realativizujete ten koncept feature/patch verzí, ale to neznamená, že je celý špatně. Prostě jsou nekompatibilní změny a kompatibilní, které částečně korelují s dělením na feature a patch. A jelikož někdy povýšit verzi snadno ani nelze, mají LTS verze své místo. Tečka. Pak s ohledem na charakter softwaru si každý musí vývojový cyklus stanovit sám a administrátoři si zase musí zvolit zase politiku aktualizací. Ve výsledku nemá cenu nutit jeden model všem.

  • 21. 5. 2020 23:19

    Filip Jirsák

    Celý špatně je koncept distribučních patch verzí. To, že je potřeba řešit kompatibilitu, vývojáři upstreamu vědí a řeší to. Řeší to s lepší znalostí problematiky, než distribuční správci.

    A jelikož někdy povýšit verzi snadno ani nelze, mají LTS verze své místo.
    Ale proč to většinou snadno nelze? Protože tomu brání právě ta LTS politika distribucí. Snadnost povýšení na novou verzi je exponenciálně závislá na stáří verze – takhle jednoduché to je.

    administrátoři si zase musí zvolit zase politiku aktualizací
    No, zvolit. Nejbezpečnější software je aktuální upstream. Tečka. Backporty jsou jen hra na bezpečnost. Takže politika aktualizací je politika bezpečnosti. Ano, ve spoustě míst je stále bezpečnost až na druhém místě, přednost má udržování staré verze. Ale je toho čím dál míň a jsou s tím čím dál větší problémy. A často je distribuční politika silným faktorem, který spoluzpůsobuje to zabetonování na starých nebezpečných verzích.

    Samozřejmě si ještě chvíli můžete myslet, že je to věc volby. Ale čím dál víc bude nemožné provozovat nebezpečný software, tudíž bude čím dál častěji jedinou reálnou volbou volba provozovat aktuální (tj. upstream) software.

    Ono se stačí podívat na bezpečnostně nejvíc ohrožený software – desktopový operační systém a webové prohlížeče. Ona to není náhoda, že Windows 10, macOS, Chrome i Firefox vydávají pravidelné aktualizace a za bezpečnou se považuje jen aktuální verze, neexistují (s výjimkou Firefoxu) žádné LTS verze. A LTS verze Firefoxu mají na trhu ještě menší podíl, než MSIE.

    Ve výsledku nemá cenu nutit jeden model všem.
    Což teď ale ne-rolling distribuce dělají. Snad s výjimkou webových prohlížečů se s vydáním zaseknou na jedné verzi a té se drží. Teda ono už to také není stoprocentní, ale alespoň se tváří, že to tak je.

    Samozřejmě že rozdíly existují, ale ty mají být v upstreamu. Neexistuje žádný důvod, proč by měl mít Knot resolver více než jednu stabilní verzi. U glibc naopak dává smysl vydávat pro jednu verzi skutečně jen bezpečnostní opravy a vedle toho vyvíjet novou feature verzi. On je ale také rozdíl v tom, že bezpečnostní opravy pro libc většinou znamenají jen opravy chyb v kódu, kdežto bezpečnostní opravy v Knot resolveru mnohem častěji řeší problémy architektury nebo protokolu.

  • 21. 5. 2020 23:34

    Danny

    Zapominate, ze treba Microsoft podporuje i Windows 8.x. Dokonce ani s tim Apple nemate pravdu - zrovna iOS 12.4.7 vydali vcera, i kdyz posledni verzi je 13.5. Stejne tak podporovanych verzi MacOSu je vic - pro 10.13 konci podpora letos v zari, 10.14 ma podporu do konce zari 2021... navzdory posledni 10.15 vydane loni v rijnu. Proste se ohanite argumenty, ktere nejsou zcela pravdive... ;-)

  • 21. 5. 2020 23:58

    bman

    Já tedy nevím Filipe, ale dnes jste jak dogmatik a popírač skutečnosti.

    "Nejbezpečnější software je aktuální upstream"
    A na základě čeho. Pokud se to upstreamu dodělávají nové funkce, úpravy a podobně, tak je větší šance, že se tady udělá chyba. A ne ve verzi do které se funkčně nešahá.

    Ano opravy se někdy nepovedou a mohou způsobit další problém, ale to neznamená, že backport bezpečnostních oprav jsou k ničemu.
    Navíc daná oprava může i tak ypůsobit problém v upstream verzi.

    "Ona to není náhoda, že Windows 10, macOS, Chrome i Firefox vydávají pravidelné aktualizace a za bezpečnou se považuje jen aktuální verze,"
    Tak toto to už možná někdo vyvrátil.
    Win10 má několik aktuálně podporovaných verzích, které dostávají bezpečnostní opravy chyb. Já mám třeba verzi 1809 a bezpečnostní opravy má.
    I Google vydává opravy pro starší verze Andoridu.

    Redhat podporuje Enteprise verze i 10 let na různých úrovních. Takže to dělají blbě?
    Existuje i řada komerčních řešení, které jedou několik verzí. V nejnovější se dělají funkce, ve starších jen opravy. Takhle to mnohdy funguje a poíráním se to nezmění.

    Pokud chcete novější verze programů, použijete ne LTS verzi či rolling distribuci. Pokud nechcete funkční změny a jen opravy, použijte LTS. Máte právo volby.

    Ono existují určité instalace a nasazení, kde uživatelé poptávájí stabilitu a delší dobu provozu bez rizika změn v nových funkcích.

  • 22. 5. 2020 8:46

    Filip Jirsák

    A na základě čeho. Pokud se to upstreamu dodělávají nové funkce, úpravy a podobně, tak je větší šance, že se tady udělá chyba. A ne ve verzi do které se funkčně nešahá.
    Na základě toho, že ty „nové funkce, úpravy a podobně“ mimo jiné opravují bezpečnostní problémy. Pokud by nové verze programů byly stále horší a horší, byl by vývoj softwaru trochu beznadějný, nemyslíte? A bylo by nejlepší na software vůbec nesahat. Samozřejmě se občas něco nepovede, a jedna konkrétní minor verze může být horší, než ta předchozí. Ale v průměru jsou novější verze bezpečnější, než ty starší.

    Navíc není pravda, že do distribučních verzí se funkčně nesahá. Černobílé rozdělení změn na „nové vlastnosti“ a „opravy chyb“ je lež.

    backport bezpečnostních oprav jsou k ničemu
    Já netvrdím, že jsou vždy k ničemu. Někdy může backport náhodou nějakou chybu opravit a nepřidělat žádnou další. Ale obecně platí to, co jsem psal výše – nové verze aplikací opravují chyby, když do starších verzí přenesete jenom některé změny, zůstanou některé chyby neopravené. Navíc při tom přenosu vznikají další chyby.

    Všichni tu argumentují tím, že při vývoji vznikají nové chyby – a pak se tváříte, že backportování změn není vývoj a tudíž při tom nemohou vznikat chyby. Ne, backportování změn je vývoj jako každý jiný, tj. kdyby všechny ostatní podmínky zůstaly stejně, je u backportů úplně stejná pravděpodobnost chyby, jako u běžného vývoje. Jenže ve skutečnosti se backportům věnuje méně pozornosti, méně se testují, v případě distribučních patchů to obvykle dělají vývojáři, kteří daný program znají hůře.

    Jediná výhoda backportování z hlediska bezpečnosti je ta, že se občas podaří opravit známou chybu, a vytvářejí se nové neznámé chyby. Takže útočník by musel znova zkoumat tu aplikaci s opravou a hledat chyby speciálně tam. No a protože má každá distribuce ty backporty jiné, je zastoupení takové aplikace mnohem menší, takže se méně vyplatí takové chyby hledat. Security through obscurity jak vyšité.

    Win10 má několik aktuálně podporovaných verzích, které dostávají bezpečnostní opravy chyb. Já mám třeba verzi 1809 a bezpečnostní opravy má. I Google vydává opravy pro starší verze Andoridu.
    Pořád jsou to ale Windows 10. Ty různé verze se pokud vím liší zcela novým softwarem – prostě pokud máte starší verzi, některé EXE vám v systému chybí. Není to tak, že byste ve starší verzi měl starou verzi ovladačů, systémových knihoven nebo prohlížeče.

    Google vydává opravy pro starší verze Androidu, ale snad nikdo si nemyslí, že jsou stejně bezpečné, jako nové verze. Vždyť je to největší bezpečnostní výtka vůči Androidu – že výrobci neaktualizují na nové verze.

    Redhat podporuje Enteprise verze i 10 let na různých úrovních. Takže to dělají blbě?
    Ano, bohužel. Uvedu malý příklad – SSL/TLS. Aby to fungovalo, musí být klient i server podporovat stejnou verzi. V době vydání LTS verze serveru s 10letou podporou můžou někde existovat skoro 10 let staří klienti, kterým zrovna bude 10letá podpora končit. Takže síťový software by měl podporovat protokoly dvojnásobně dlouhou dobu, než je doba podpory LTS verze. Takže v tomhle případě 20 let. Takže webový server v LTS distribuci by ke konci své životnosti měl podporovat SSL/TLS, které bylo nejnovější před dvaceti lety, a neměl by podporovat žádnou verzi mladší než deset let.

    Dříve to tak distribuce opravdu zkoušely, ale když se objevily útoky na SSLv3 (v době, kdy už pár let existovalo TLS 1.2), ukázalo se, že je to neudržitelné. A bylo potřeba buď ty staré LTS verze zahodit, a nebo porušit jejich politiku a implementovat tam nové funkce.

    Existuje i řada komerčních řešení, které jedou několik verzí. V nejnovější se dělají funkce, ve starších jen opravy. Takhle to mnohdy funguje a poíráním se to nezmění.
    Realitu popíráte vy. Ano, to, co píšete, existuje. Ale my se tady bavíme o tom, jestli je to bezpečné. To, že něco existuje, neznamená, že je to bezpečné.

    Pokud nechcete funkční změny a jen opravy, použijte LTS. Máte právo volby.
    Akorát že je to volba založená na lži. Na lži, že lze všechny změny v softwaru rozlišit na funkční změny a opravy. A na lži, že se do LTS verze dostávají všechny opravy.

    Ono existují určité instalace a nasazení, kde uživatelé poptávájí stabilitu a delší dobu provozu bez rizika změn v nových funkcích.
    Ano. Akorát že se jim tají, že je to stabilita na úkor bezpečnosti. A podceňuje se riziko verzí s backportovanými změnami.

    Mimochodem, já jsem tvrdil tři věci:
    1. Není pravda, že lze změny v softwaru rozdělit do dvou výlučných skupin – funkční změny a opravy.
    2. Není pravda, že backport opravy je bez rizika.
    3. Bezpečnost softwaru zvyšují i opravy, které jsou jednoznačně jen funkční změny.

    Nic z toho se nikdo ani nepokusil vyvrátit. Místo toho argumentujete tím, že se to tak dělá dlouho. Ano, dělá, ale to neznamená, že je to správně. Svět IT se změnil, vše se mění mnohem rychleji a to, co platilo dříve – že můžete klidně používat 10 let starý software, protože se za těch 10 let moc nezměnil – zkrátka dneska vůbec neplatí.

  • 22. 5. 2020 9:26

    Danny

    Ad 3) funkcni zmeny nezridkakdy bezpecnost naopak snizi. Novy software, nove chyby :-) Protoze za temi rychlymi zmenami jsou casto ne zcela domyslena reseni tech konkretnich problemu. Kvantita - a tim myslim i cetnost vydani major verzi s novymi funkcemi - rozhodne neimplikuje kvalitu. Vysledkem te hekticke IT fabriky je automobil v kvalitativni urovni dodo, kdy tu a tam chybi treba matice drzici kolo u napravy a tak...

  • 22. 5. 2020 9:36

    Filip Jirsák

    Pokud si myslíte, že nová verze softwaru je v průměru horší, než předchozí verze, měl byste zůstat u první vydané verze.

    Jenom bych připomněl takovou drobnost, kterou neustále přehlížíte. Backport změn do staré verze je změna softwaru jako jakákoli jiná. Takže pokud je podle vás většina změn v softwaru k horšímu, týká se to úplně stejně i backportů.

    Je pozoruhodné, jak nekriticky se správci na backporty dívají. Každá změna v softwaru určitě přináší nějaké chyby a neopravuje, co by měla – ale nazvěme to backportem, abrakadabra, všechny chyby zmizí, oprava je funkční, změna neznamená žádné riziko, ani není nutné to pořádně testovat.

    Takhle by se dal vyvíjet bezchybný software, ne? Vývojáři budou normálně vyvíjet, a za nimi pojede robot, který bude všechny jejich úpravy backportovat do verze 1.0. A protože všechny backporty jsou z definice dokonalé, bude dokonalá i ta verze 1.0 s backportem všech novějších úprav.

  • 22. 5. 2020 9:58

    Danny

    Ja si nemyslim, ze nova verze je v prumeru horsi. Ale taky si nemyslim, ze by uzivatele meli houfne nasazovat vse, co z klavesnic vyvojaru zrovna vcera vecer vypadlo jejich systemem zkompiluje se to, proslo to par syntetickymi testy - tak je to asi dobry. Testovani musi byt viceurovnove - tak jako to je treba u toho TurrisOS. Ano, je to pomalejsi - ale snizuje to riziko, ze se pripadne chyby masove rozsiri. Vy tu stale v ruznych formach argumentujete, ze jedine smysluplne reseni je jedina podporovana verze - pokud mozno ta, kde vyvojar s opravou dvou chyb zavlekl ctyri dalsi :-) Nejak jste se nevyporadal s tim, proc je nutne tak spechat - proc nekteri nutne musi mit kazde tri mesice novy major release s novymi funkcemi, ale i chybami - a s nim automaticky pohrbit vsechny predchudce, kde je cela rada programatorskych chyb odladena.

  • 22. 5. 2020 10:18

    Petr Špaček

    Samozřejmě záleží na kvalitě testování. V případě Knot Resolveru sadu testů rozšiřujeme prakticky pro každý release, takže nové verze jsou otestované lépe než ty předchozí.

    Pokud vás zajímá jak konkrétně testujeme Knot Resolver na realistických datech, tak doporučuji ke shlédnutí následující přednášku:
    https://www.youtube.com/watch?v=RN-pt5wAluI&list=PLCAxS3rufJ1duAcnqJSXHJZr-R4Sf8kzg&index=6&t=3335s

    (Přednáška pokrývá jen jeden konkrétní typ testů.)

  • 22. 5. 2020 10:39

    Filip Jirsák

    Ja si nemyslim, ze nova verze je v prumeru horsi. × vyvojar s opravou dvou chyb zavlekl ctyri dalsi

    Asi byste si měl rozmyslet, co si vlastně myslíte.

    uzivatele meli houfne nasazovat vse, co z klavesnic vyvojaru zrovna vcera vecer vypadlo jejich systemem zkompiluje se to, proslo to par syntetickymi testy - tak je to asi dobry
    To jsem nikdy nepsal.

    Testovani musi byt viceurovnove
    Jako že by třeba distribuce vzala upstream, otestovala ho, když najde chyby, reportovala je zpět do upstreamu, a až po jednom nebo několika kolech žádnou podstatnou chybu nenajde, tu upstream verzi vydá? Ano, přesně takhle bych si to představoval. Naopak se mi nelíbí současná praxe, kdy si distribuce vytvoří svou vlastní verzi, tu otestuje na jedné úrovni (protože nikdo jiný tu verzi nemá, nemůže jí otestovat), a to rovnou vydá.

    Vy tu stale v ruznych formach argumentujete, ze jedine smysluplne reseni je jedina podporovana verze
    Ano, to tvrdím. Protože všechny starší verze jsou obvykle horší, obsahují více chyb. Jaký smysl má provozovat verzi s větším množstvím chyb?

    Jinak samozřejmě se bavíme o produkčních verzích. Pokud vývojáři spravují vedle nějakou řadu třeba betaverzí, ať to klidně dělají a ať to používá ten, kdo chce. Ale asi nebudu provozovat betaverzi na produkčním serveru.

    Nejak jste se nevyporadal s tim, proc je nutne tak spechat
    Ale vypořádal jsem se s tím. Důvod je strašně jednoduchý – starší verze mají obvykle více chyb, včetně chyb bezpečnostních. Celou dobu se tu bavíme o jediné věci – jestli je lepší provozovat verzi s větším množstvím chyb, nebo verzi s menším množstvím chyb. Pokud chci to druhé, jediný způsob, jak to dlouhodobě zajistit, je používat aktuální verze z upstreamu.

    pohrbit vsechny predchudce, kde je cela rada programatorskych chyb odladena
    Tohle je právě jen iluze.

  • 22. 5. 2020 10:39

    bman

    "Na základě toho, že ty „nové funkce, úpravy a podobně“ mimo jiné opravují bezpečnostní problémy."
    No a nebo nové přidávají. A nejen bezpečnostní ale i funkční změny. A to je pro určitá nasazení riziko.

    viz. backporty
    Ale Vy pořád máte premisu, že změny v nové verzi opravují chyby. Podle mě je spíš přidávají. Ale pravda může být někde uprostřed.
    Něktéré bezpečnostní chyby se možná opraví, jiné ale zase udělají.
    Ale nové chyby s dopadem na funkčnost vznikají jen v upstreamu. A to je riziko.

    Je-li nějaká bezpečnostní chyba v upstreamu i LTS verzi, tak pokud ta část kódu je stejná, tak zde není rozdíl.
    Pokud je jiná, tak se oprava nemusí podařit v LTS, upstreamu nebo obou. Opět to neukazuje, že upstream je lepší.

    "Vždyť je to největší bezpečnostní výtka vůči Androidu – že výrobci neaktualizují na nové verze"
    Ale to přece není problém Googlu, ale výrobce.
    Např. má postarší Nokia na Android 9 dostává stále bezpečnostní opravy.

    A představte si, že jsou i šílenci, co si platí delší podporu pro Debian. Takový nerozum, viz. freexian .

    A premisa, co je nejnovější je lepší, nepříjmám.

  • 22. 5. 2020 11:36

    Filip Jirsák

    No a nebo nové přidávají.
    V průměru ale víc chyb opraví než přidají. Navíc opravují známé chyby, které někdo může zneužít. Nové chyby teprve někdo musí objevit, aby je mohl zneužít.

    A to je pro určitá nasazení riziko.
    Dobře, pro některá nasazení je riziko používat bezpečnější verzi a raději se používá méně bezpečná verze. To beru. Zároveň je čím dál větší riziko používat méně bezpečné verze. Takže přestává platit „nám nevadí používat méně bezpečnou verzi, můžeme si to dovolit“. Struktura rizik se holt mění a ignorovat bezpečnostní rizika přestává být přijatelné. V některých případech tedy bude nutné řešit to, jak se bránit nežádoucím funkčním změnám v situaci, když musím řešit i bezpečnost. Přičemž řešení je známé a používá se – automatizace nasazení a testování. Nejprve se provádějí syntetické testy v předprodukčních prostředích, když procházejí, nová verze se dostává dál, až postupně se nasazuje i do produkčního prostředí. A monitoruje se, a pokud by se začaly vyskytovat nějaké anomálie, release se zastaví nebo se vrátí zpět předchozí verze.

    Ale Vy pořád máte premisu, že změny v nové verzi opravují chyby. Podle mě je spíš přidávají. Ale pravda může být někde uprostřed.
    Kdyby platila vaše varianta, software by byl čím dál horší a nejlepší by byla hned první verze. To samozřejmě neplatí. Pravda není někde uprostřed. Pravda je taková, že když si budete náhodně vybírat verze a vždy je porovnáte, v průměru bude novější verze lepší. Samozřejmě se občas stane, že se nějaká verze nepovede. Ale pak je potřeba to v následující verzi opravit a opravu vydat co nejdřív.

    Něktéré bezpečnostní chyby se možná opraví, jiné ale zase udělají.
    Ano, ale bezpečnost se celkově zlepšuje. Jinak by nemělo smysl software vyvíjet.

    Ale nové chyby s dopadem na funkčnost vznikají jen v upstreamu.
    To je omyl. Nové chyby s dopadem na funkčnost samozřejmě vznikají i v distribucích. Akorát že tam je podstatně menší počet uživatelů, než v upstreamu, takže mají menší dopad.

    Pokud je jiná, tak se oprava nemusí podařit v LTS, upstreamu nebo obou. Opět to neukazuje, že upstream je lepší.
    Jenže pravděpodobnost, že tu opravu dělá vývojář, který kódu dobře rozumí a je si vědom všech souvislostí, je mnohem vyšší v upstreamu než v distribuci. Upstream je obecně lepší ze třech důvodů – za prvé je tam větší množství oprav, za druhé jsou ty opravy dělané s lepší znalostí problematiky, za třetí je to více testované.

    Ale to přece není problém Googlu, ale výrobce.
    Ale proč je to problém pro výrobce? Protože místo toho, aby postupně bez problémů aktualizoval jednotlivé komponenty, má LTS řešení, které znamená v jednom okamžiku prakticky zahodit vše předchozí, a sestavit novou distribuci prakticky od začátku.

    A představte si, že jsou i šílenci, co si platí delší podporu pro Debian. Takový nerozum, viz. freexian.
    To, že někdo něco dělá, opravdu neznamená, že je to rozumné.

    A premisa, co je nejnovější je lepší, nepříjmám.
    Já netvrdím, že je to tak vždy, ale že je to tak obvykle. No a pokud si myslíte, že software je čím dál horší, pak nemá smysl software vyvíjet. A nebo ho nemusíte aktualizovat. Můžete si spokojeně používat nejstarší verzi, kterou seženete, a diskuse o aktualizacích vás nemusí trápit.

  • 22. 5. 2020 12:29

    bman

    Očividně jste nic neprovozoval ve velkém. Ty firmy, co si platí prodlouženou podporu na dané verzi velmi dobře vědí, proč to dělají.

    Tvrdit, že nově vyvýjená verze má méně chyb a je lepší je teda dobrá fabulace. Už jenom proto, že se do toho kódu v nové verzi hrabe.
    Změny znamenají chyby a to hlavně funkční.

    V oblasti co sleduji já, tak většina bezpečnostních chyb je od nejnovější verze dolů. To ale popírá Vaše tvrzení.

    A ano. SW se vylepšuje, umí víc věcí a třeba je lepší. Ale novou verzi musíte vyzkoušet, odladit a teprve potom nasadit. A toto než se udělá, tak samozřejmě se musí opravovat starší verze. Proto si tu podporu firmy platí a výrobci ji dělají.

  • 22. 5. 2020 13:13

    Filip Jirsák

    Očividně jste nic neprovozoval ve velkém. Ty firmy, co si platí prodlouženou podporu na dané verzi velmi dobře vědí, proč to dělají.
    Protože na dané verzi zamrzli, protože kvůli LTS verzi nemohli aktualizovat průběžně. A protože jim dodavatel nějakého softwaru garantoval provoz jenom na nějaké jedné verzi. Protože pro toho dodavatele je to samozřejmě jednodušší, podporovat tu jednu verzi. A že je v té verzi jiný software nebezpečný? To přece není starost toho dodavatele.

    Tvrdit, že nově vyvýjená verze má méně chyb a je lepší je teda dobrá fabulace. Už jenom proto, že se do toho kódu v nové verzi hrabe.
    Změny znamenají chyby a to hlavně funkční.

    Jo. Jenže backportování oprav jsou také změny. Vážně nechápu, kde se bere ta představa, že programátor napíše nějaký kód s chybou, pak někdo vezme tenhle kód a vloží ho do starší verze programu, načež ta chyba zázračně zmizí.

    V oblasti co sleduji já, tak většina bezpečnostních chyb je od nejnovější verze dolů. To ale popírá Vaše tvrzení.
    Fakt? Já tvrdím, že verze n je obvykle lepší, než všechny verze 1..n-1. Vy tvrdíte, že obvykle je stejná chyba ve verzích 1..n a teprve ve verzi n+1 je ta chyba opravená. Řekl bych, že oba tvrdíme to samé, akorát jsme se posunuli o jednu verzi.

    A ano. SW se vylepšuje, umí víc věcí a třeba je lepší. Ale novou verzi musíte vyzkoušet, odladit a teprve potom nasadit. A toto než se udělá, tak samozřejmě se musí opravovat starší verze.
    To je stále dokola to samé. Oprava staré verze znamená, že uděláte novou verzi. Ale novou verzi musíte vyzkoušet, odladit a teprve potom nasadit.

    Zdá se, že jde především o nepochopení toho, jak funguje vývoj software. Že riziko zanesení chyby záleží jenom na tom, jak je kód složitý, jak je vývojář zkušený a jak dobře se testuje. Vůbec nezáleží na tom, zda té změně dáte nálepku „oprava chyby“ nebo „nová vlastnost“ nebo „backport“. Ta chyba v tom kódu prostě buď je nebo není, bez ohledu na to, jak té změně budete říkat. A mechanismus, jakým se dělají backporty v distribucích, je náchylnější na chyby, protože to typicky dělají vývojáři, kteří mají s danou aplikací méně zkušeností, a méně se to testuje.

    Proto si tu podporu firmy platí a výrobci ji dělají.
    A proto se čím dál víc věcí provozuje v kontejnerech nebo se to odebírá jako služba. Protože LTS je tak skvělá věc, že kdo může, ten zvolí něco jiného.

  • 22. 5. 2020 18:21

    Petr M

    @bman:
    "No a nebo nové přidávají. A nejen bezpečnostní ale i funkční změny. A to je pro určitá nasazení riziko."

    No nevím jak mimo civilizaci, ale v civilizovaným světě platí, že chyba v produkci je chyba, kterou nechytily testy. Takže pokud zjistím, že program spadne při pomlčce jako třetím znaku v jednom z parametrů, ještě před fixem se zamyslím, jestli tam ta pomlčka smí být nebo ne, jestli je nějak omezená sada znaků, co udělá jinde,... a podle toho doplním testy. Až mám podchyceno, kdy problém nastane, můžu ho opravit. A tyhle nově přidaný testy si zároveň pohlídají třeba to, že uprostřed argumentu nebude otazník. Takže z množiny možných chyb verze X odeberu podmnožinu chyb způsobených chybným argumentem na command line. Přitom pořád platí, že v kódu může být cokoliv z množiny chyb, na co nejsou testy.

    "Ale nové chyby s dopadem na funkčnost vznikají jen v upstreamu. A to je riziko." A teď tu "Jak Andrejovi dotace proti jeho vůli vnutili". Jednou, ještě v korporátu jako embeďák, jsem zažil aplikaci patche o dvě verze níž, která prošla testováním, ale zákazník nám to omlátil o hlavu, i když v nové verzi to fungovalo. Zamrzala mu komunikace a občas přišly nesmysly. Ono se to totiž připravovalo o dvě verze výš a kód byl mezi tím refaktorovaný. A v přijímací části komunikačního vlákna se kombinací starýho a novýho kódu (git patch): Podmínka pro timeout dostala až za přijímací cyklus - odtud to zamrzání V refaktorované části se pro chyby používala proměnná Error a v původní err. Protože každá měla svůj řádek s deklarací, tak se prostě při merge přidalo int Error; a protože se uvnitř testovalo průběžně, nevyskočil ani warning. Proto to nechytlo ani chybu CRC A ve staré verzi to ve stavovým automatu ve stavu pro příjem délky dat (měl to být 1B) vypadla kontrola maximální délky paketu, takže vlákno akceptovalo 256B. Paket se rval do bufferu velikosti 64B. NA to naštěstí zákazník nepřišel. Chytaly by to testy celé sestavy (proti jinýmu zařízení), ale to se z časových důvodů odflinklo a pouštěly se do toho akorát korektní pakety. Klasika, jednotka času na projektu je přece 1 fčíl. A když se projevila chyba na lince (kterou jsme na 2m v rámci stolu neměli), bylo vymalováno. Jeden backport, tři fungl nový bugy. Co víc si od života přát?

    "Je-li nějaká bezpečnostní chyba v upstreamu i LTS verzi, tak pokud ta část kódu je stejná, tak zde není rozdíl.
    Pokud je jiná, tak se oprava nemusí podařit v LTS, upstreamu nebo obou. Opět to neukazuje, že upstream je lepší."

    Jenomže kód není statický. Předpokládám, že stejná chyba má stejnou příčinu a vznikla ve stejný okamžik. V tom případě bych jako měřítko kvality s dovolením použil čas od vzniku chyby do jejího odhalení a opravy. Je to celkem jasná metrika.
    U upstreamu se rozšiřuje pokrytí testy na všech úrovních, takže je vyšší pravěpodobnost zachycení chyby. Navíc kód se nejen přidává, ale zhnilý kód se i odřezává, takže když je chyba v zastaralým protokolu, který se vyhodí, odpadne s ním i ta chyba. Takže se dá předpokládat, že v upstreamu zmizí dřív.

    "Ale to přece není problém Googlu, ale výrobce.
    Např. má postarší Nokia na Android 9 dostává stále bezpečnostní opravy."

    Autorem Androidu je Google. Licenci pro výrobce vydal Google. Podmínku užívání v podobě aktualizace do X dní během Y měsíců od výroby mobilu do licence, kterou by byl výrobce vázaný, nedal Google. Takže za dobrovolnost aktualizací může Google. A protože je levnější se o už prodaný kus nestarat, zákazník to neřeší a neporušuje se licence,...

  • 21. 5. 2020 19:19

    Jan Forman

    Taková distribuce bude dobrá tak maximálně na hraní na doma.
    Je zcela normální a žádoucí, že se opravy backportují. Totiž některé byť relativně malé změny funkcionality v nových verzích můžou a často mají fatální dopad na funkci všech možných částí. Na něčem takovém vůbec nelze stavět byznys.
    Je vidět, že prakticky jste to nikdy nezkoušel, protože výsledek by byl jen hospitalizace na psychiatrii a nebo dobrovolný skok pod vlak.

    Ten backport je relativně bezpečný, narozdíl od zcela nové verze SW.
    Ono třeba i u gentoo lze udržovat verze SW dle libosti proti sobě, i když můžete být na nejaktuálnějších verzích.

    Řeknu to rovnou, někdy backportuju fix sám, abych se vyhnul nějakému totálnímu upgrade všeho okolo. Ten backport sežere řekněme do hodinky času, totální výměna komponent to je průser v kterém nevíte jak dlouho to sežere a kdy se začnou objevovat nevídané novinky.

    Backporty prostě existují téměř na všechen SW a opravdu to není jen proto, že to někoho strašně baví (je to celkem složitá sranda). Často by to prostě upgradovat nešlo a nebo to napáchalo velké škody či stálo strašně peněz.

  • 21. 5. 2020 22:35

    Filip Jirsák

    Mýlíte se ve dvou věcech – v tom, že backport je relativně bezpečný, a v tom, že všechny chyby lze opravit backportem. To, že backporty existují, neznamená, že řeší nějaký problém ani že žádný nevytváří.

    Zrovna nedávno jsem někomu potvrzoval, který commit se vztahuje k jedné hlášené bezpečnostní chybě. Dotyčný si commit backportoval a byl spokojen, jak bezpečnostní problém vyřešil. No, nevyřešil nic, protože ten commit zaváděl novou bezpečnější variantu problematické funkce, protože tu původní není možné změnit – mohlo by to rozbít existující kód. Takže oprava té chyby znamená především začít volat tu novou funkci. Což samozřejmě dotyčný neudělá – za prvé nerozumí podstatě problému, za druhé by musel upravit všechny aplikace, které to používají.

    Ale backport byl proveden a v tabulce je možné si to odškrtnout jako splněné.

  • 21. 5. 2020 23:51

    Danny

    Backport opravy vytvoreny treti stranou bude vzdy mene bezpecny a vice rizikovy - v porovnani s opravami, ktere zacleni sami vyvojari daneho produktu do sve vlastni long-term-support verze. Prave proto ma smysl, aby primo vyvojari meli vice vetvi - skutecne stabilni - pro produkcni nasazeni a vyvojove testovaci vetve, ktere kde se resi nove veci, tu a tam se vyda polo-stabilni vydani pro ty, co si radi hraji. Uz jsem zde zminoval nekolik produktu z CZNIC labsu, kde to takto funguje a klidne zminim dalsi - Bird stale podporuje jak verzi 1.6.x, tak i verzi 2.0.x :-) Samozrejme, ze do 1.6 se necpou nove funkce, ale bezpecnostni diry tam resi. Proste ono to jde - kdyz se chce... i v ramci jedne organizace.

    A nebo se naucit vyvijet tak, aby vyvoj novych verzi byl nenapadnou evoluci a nikoliv revoluci v tom duchu, ze vsechno je zase jinak. Treba takove ty opravy systemem neco nam obcas nefunguje - tak to proste zrusime, predelej si konfigurak. To proste neni pro bezny zivotni cyklus v produkcnim prostredi pouzitelne - kdyz ma bezpecnostni zaplata neco soucasne dost zasadne rozbit timto zpusobem....

  • 22. 5. 2020 0:27

    Filip Jirsák

    Pořád zaměňujete backport patche s opravou chyby. To není totéž. A pokud dělají backport patche upstream vývojáři, je sice větší naděje, že ten backport dopadne dobře – ale to neznamená, že je takový backport vždy možný.

    Když byly nalezeny bezpečnostní slabiny v protokolu SSLv3, můžou se vývojáři třeba stavět na uši, ale žádným backportem to nevyřeší. Jediná možnost je prostě přestat SSLv3 používat a používat novější verze TLS.

    ale bezpecnostni diry tam resi. Proste ono to jde - kdyz se chce... i v ramci jedne organizace
    To je jen iluze někoho, kdo do toho vývoje nevidí. A proto je to také docela problém – protože LTS verze v neznalých lidech vyvolávají dojem, že jsou bezpečné.

    Není pravda, že řeší všechny bezpečnostní díry. Řeší takové bezpečnostní díry, které lze vyřešit se zachováním zpětné kompatibility aplikace (a nejspíš ještě ne všechny). Je teoreticky možné, že zatím nebyla nalezena žádná chyba, kterou by takhle vyřešit nešlo – ale to je jen otázka štěstí. Zkrátka to, jestli to jde, není zdaleka jen otázka chtění.

    Ale co rozhodně jde, když se chce, je věřit tomu, že starý software je bezpečný. Úplně nejbezpečnější software by byl ten, kde by se pokaždé jen zvýšilo číslo verze a do release notes napsalo, že je chyba vyřešená.

    A nebo se naucit vyvijet ta
    Ano, to bude vůbec nejlepší, prostě se naučit vyvíjet bezchybný software.

    Mám pro vás na závěr jedno malé tajemství. Vývojáři o něm vědí, protože se s ním setkávají každý den, ale mimo vývojáře to asi hned každého nenapadne. Řádově víc chyb, které mohou mít dopad ne bezpečnost, se opraví během běžného vývoje, tj. přidávání nových funkcí a oprav nesouvisejících chyb. Prostě programátor v kódu narazí na místo, které by mohlo být problematické, a opraví to. (Někdy tím také něco rozbije, což pokud možno odhalí testy, ale celkově se tím software jednoznačně zlepšuje.) A z chyb, které se opravují záměrně (tj. někdo z venku to nahlásil jako chybu, je to jako chyba evidované), je spousta chyb, které mají dopad na bezpečnost, ale pouze malá část z nich je označena jako bezpečnostní chyba. Prostě je to chyba, tak se to opraví – a možná občas někomu dojde, že by se ta chyba možná i dala nějak zneužít. Ale už je to opravené, tak proč to řešit. Teprve s rozmachem Curriculum vitae enhancement (známé pod zkratkou CVE) jsou tyhle problémy častěji označovány jako bezpečnostní problém.

    Takže z oprav bezpečnostně relevantních chyb je jen část taková, že je si toho vývojový tým vědom, že to má dopad na bezpečnost. A z toho zase jen část je možné rozumně backportovat.

    Ale klidně si dál věřte tomu, že LTS verze jsou stejně bezpečné, jako aktuální verze.

  • 22. 5. 2020 9:01

    Danny

    Dekuji za obsahlou prednasku. Muzu se zeptat, kdy si vas webserver, nebo treba i ssh nastavite podle standardu odpovidajicim dnesni dobe a o kterych tu mluvite? ;-) Podle SSH banneru lze usuzovat, ze sam jedete na Ubuntu Bionic 18.04 LTS... proc tam nemate Groovyho, kdyz mate tak rad posledni verze software? :-) A navic jste nejak zapomel na bezpecnostni update - namisto lednove 7.6p1-4ubuntu0.4 tam mate starsi 7.6p1-4ubuntu0.3 :-) Inu, asi kovarova kobyla...

  • 22. 5. 2020 9:26

    Filip Jirsák

    Je to tak právě proto, že je tam LTS verze. A LTS verze se prostě vyznačují tím, že zamrznou na jedné verzi a přechod na novou verzi je obtížný. A proč je tam LTS verze? Protože to tenkrát byla jediná možnost. Upgrade mám v plánu – a když už to budu muset podstoupit, půjde tam systém, jehož nejdůležitějším úkolem není zamrznout na staré verzi.

  • 22. 5. 2020 10:04

    Danny

    Staci upravit sources.list a pustit dist-upgrade. Namisto toho vaseho TL;DR zvaneni jste to mohl mit uz davno aktualizovane na svuj cutting-edge system. To, ze nebyla jina moznost je pouze Vase vymluva. Byla to vase volba a vase rozhodnuti, tak se z teto vlastni zodpovednosti nevykrucujte :-) Proste kazete vodu, ale pijete vino.

  • 21. 5. 2020 22:28

    Petr M

    Ono pokud by šlo o chybu v kódu typu "buffer overflow" nebo podobnou prkotinu, tak není problém mít v GITu několik branchů pro podporovaný verze (1.2.x, 1.3.x,...) a "service_1x". Hook na git serveru zajistí merge commitu do všech podporovaných verzí 1.x, spustí build, unit testy, nějaký fuzzy testing a deploy do repozitáře. Všechno v cajku, chyba opravena, kafíčko, kopyta na stole...

    Jenomže ono to tak nefunguje. Soubor, kde se objevila chyba, někdo ve verzi 1.3.57 změnil a najednou merge / rebase ve verzi 1.4.59 a ve verzi 1.5.27 neprojde automaticky a vývojář opravuje chybu 2x. Navíc se ta chyba objevila ve verzi 1.2.35, ale prošel i merge do verze 1.1.167 (před chybou) a zaručí někdo, že se opravou změny v nezměněným souboru něco nerozbilo?

    Do toho QA ve firmě nechce pustit novou verzi ven, pokud si s tím nepohraje tesťák. A řekni mu, že oslava 32. narozek jeho manželky musí počkat, protože máme kolem oběda opravenou kritickou 0-day zranitelnost a je potřeba projet pět verzí SW po třech hodinách. Doporučuju si na to domlouvání s tesťákem vzít chránič zubů, helmu a pancéřovaný trenky.

    A pak je tady chyba typu "přestal nám fungovat SW XY", ze které se vyklube "implementovali nový šifrování a dost tvrdě ho vyžadují, takže musíme přidat podporu". Na to je potřeba pár voleb v konfiguráku, dopsat modul, přidat do adresáře s nastavením klíče,... Mění se konfigurace, rozhraní,... A sakra, máme navíc verzi 1.6.0.

    Takže ve finále je jednodušší (a levnější, bezpečnější,...) dělat jednu verzi, dělat ji dobře, dobře dokumentovat a dobře testovat.
    Ač je to s podivem, musím dneska souhlasit s Jirsákem. Držet starou verzi SW X jenom proto, že musí spolupracovat se starou verzí SW Y je konina. Je to zbytečná práce navíc, polovina chyb neopravená, druhá polovina oprav neotestovaná. Věci, který by zákazník ocenil (delší komunikační protokol, cachování, škálování na víc serverů,...), jsou na tom asi jako IPv6. Sice by se za půl roku třeba 20x updatovala aplikace, ale stylem "tenhle řádek v konfiguráku smaž a sem přidej tenhle parametr". Ne sylem "git clone [nová verze], meld, make config && sudo make install" a modlitba během buildu, aby "servisák" něco neubral nebo nepřidal.

    Navíc pokud je to opravdu produkční prostředí a stará se o to profík, je tam i nějaká redundance. Jenom idiot by nechal něco, co mu vydělává prachy, viset na jednom fyzickým procesoru. Pokud update odladím na jednom stroji z pěti a ten chcípne, není to zase taková tragédie. A když to pak chodí, dá se to hodit postupně i na další čtyři stroje.

  • 21. 5. 2020 23:03

    Trident

    To že je někdo uzenarsky výrobek ze zabijacky a neumi si představit že upgrade jednoho sw kusů muze znamenat update jiných kusů sw, pořízení nového hw, pořízení licence za x mega, výpadek kriticke infrastruktury třetiny republiky atd. to už asi budu muset nechat.
    Ono je to kolikrát o tom ze vám třeba ericsson nebo nokia dá nůž na krk a definuje interface a systém . Zastaralý kde musíte protistranu zaplatovat a updatovat nejde. Problém? Tak si přejděte k Huawei... Nelíbí? Tak si v té malé zemicce delejte ústředny sami. Že jste od doby tesly karlín nic sami nevymysleli? Silnější pes...
    Ale strašně mam rad tyhle teoretiky. Jen bych je nerad potkal u soudu jako "znalce" nebo ve státní správě jako to co rozhodují.

  • 21. 5. 2020 23:22

    Danny

    To ale predpoklada velmi kvalitni QA proces. A ne testovat az nasazenim v ostrem provozu - na lidech...

    Vtipne je, ze to v konecnem dusledku ten pristup kresd teamu k podporovanym verzim schytavaji i uzivatele Turrisu, kde vas vyvojari od kresd vlastne i tlaci do verze TurrisOS, ktera oficialne jeste ani neni vydana - stale jde o testovaci branch (HBK). A to se prosim vyprodukuje v ramci jedne organizace... ;-)

    Jinymi slovy - i samotny CZNIC potrebuje long-term support verzi s ohledem na jine sve vlastni produkty. Takze to neni jen problem "externich" distribuci.

  • 22. 5. 2020 0:37

    Filip Jirsák

    To ale predpoklada velmi kvalitni QA proces. A ne testovat az nasazenim v ostrem provozu - na lidech...
    Zato když někdo vezme patch, kterému pořádně nerozumí, je to zcela bezpečné a žádné QA není potřeba. Dokonce ani v případě, že ten patch sám vyrobí. A testovat to v ostrém provozu také není problém – vždyť je to unikátní patch, který se používá jenom v dané distribuci, takže uživatelů postižených problémem zase není tolik. Security through obscurity.

    kde vas vyvojari od kresd vlastne i tlaci do verze TurrisOS, ktera oficialne jeste ani neni vydana
    Podle mne je to teda chyba distribuce, když existuje opravená verze softwaru, ale v distribuci z politických důvodů není a je jen v nějaké zatím nepodporované verzi, která se vyvíjí velkým třeskem, takže trvá dlouho, než se stabilizuje.

    samotny CZNIC potrebuje long-term support verzi s ohledem na jine sve vlastni produkty
    Nikoli. I samotný CZ.NIC potřebuje v jiných svých produktech přejít na průběžné aktualizace softwaru. Akorát že zrovna tady to mají dost obtížné, když závisí na OpenWRT. Zejména když OpenWRT nedávno málem dosáhlo svatého grálu LTS verzí, totiž jediné poslední verze, která už by byla na věky.

  • 22. 5. 2020 9:08

    Danny

    Jiste - takze podle vas je chybou vyvojare Turrise, kdy maji ruzne vetve - od stabilni, produkcni "HBS" az po "HBD". Ja si to tedy nemyslim, naopak takovy pristup povazuji za zodpovedny smerem k uzivatelu,. Prekvapive smyslem "HBS" je eliminovat divoke zmeny v prubehu zivotniho cyklu stabilni verze - treba jako cele prekopani konfigurace :-) Teamu kolem TurrisOS samozrejme nic nebrani si kresd ubalit lokalne, nemusi v tom spolehat na upstream z OpenWRT.

  • 22. 5. 2020 11:25

    Vladimír Čunát

    Pro upřesnění, v upstream OpenWrt pořád kresd není. A tohle konkrétní překopání byly primárně změny v systemd socketech, což se zrovna OpenWrt nebo Turrisu netýká (bohužel... systemd se mi používá trochu lépe).

  • 22. 5. 2020 12:23

    Danny

    Jenom jsem poukazal na to, ze u produkcni stabilni verze TurrisOS sami pouzivate starsi verzi kresd a nevydavate se u HBS cestou divokych zmen a nasazovani nejposlednejsich verzi SW, po cemz vola pan Jirsak vyse.

  • 22. 5. 2020 9:48

    Petr Špaček

    Dobrý den všem diskutujícím.

    Pokusím se uvést věci na pravou míru:
    1. Minimální patch pro NXNSAttack jsme poslali distributorům přes uzavřený distros list ještě před ukončením emarga, stejným postupem jako ostatní výrobci.
    Více o distros listu zde: https://oss-security.openwall.org/wiki/mailing-lists/distros

    2. Rozhodnutí jestli patch ne/zařadit je na distribuci. Každá distribuce má svoji politiku a v Debianu se nám prostě nedaří domluvit s maintainery balíčku na spolupráci. Ve Fedoře a CentOSu je situace jiná a tam jsou aktuální verze.
    Pokud se mezi čtenáři najde zájemce, který by se balíčkováním chtěl živit, tak vás rádi přijmeme to týmu! Kvalifikační požadavky a e-mail k zasílání životopisů najdete zde:
    https://www.nic.cz/page/321/kariera-v-cznic/#labs_linux

    3. Ad nekompatibilní změny v Knot Resolveru:
    Diskusi se zájmem čteme a zvažujeme pro a proti různých přístupů. Díky za kultivovanou diskusi.

    Většina nekompatibilních změn je v API modulů, o kterém (doufám) nikde netvrdíme, že je stabilní. Když čtu zdejší diskusi, tak vidím, že to musíme v dokumentaci vyjasnit.

    Nekompatibilní změny v jiných částech se snažíme seskupit do major verzí. Výjimečně se taková změna může dostat i do ne-major verze - typicky jde o temná zákoutí, která buď vůbec nebyla dokumentovaná, nebo máme důvod si myslet, že je drtivá většina uživatelů nepoužívá.

    Pokud chcete pomoci se zlepšením naší představy co uživatelé ne/používají tak se prosím zapojte do průzkumu:
    https://www.knot-resolver.cz/survey/

    4. Podrobněji ke změnám API modulů:
    API se snažíme držet a neměnit ho "pro nic za nic". API modulů ale vystavuje ven vnitřnosti Knot Resolveru, takže změny jsou čas od času nevyhnutelné. Např. oprava CVE-2019-19331 si vyžádala změnu API modulů a bez ní ten problém prostě není řešitelný.

    Dlužno dodat, že problém je to jen pro moduly, které nejsou součástí Knot Resolveru. Pokud by autoři modulů přispívali v duchu open-source zpět do upstreamu, tak by tento problém nevznikal.

    Pokud máte vlastní modul a chcete se o něj podělit, tak to s námi prosím prodiskutujte v nově vytvořeném issue:
    https://gitlab.labs.nic.cz/knot/knot-resolver/issues/new

    5. Ad udržování starých verzí:
    Vnímáme problém v Debianu a odvozených distribucích. Pokud s tím chcete pomoct prosím přihlaste se na pracovní pozici https://www.nic.cz/page/321/kariera-v-cznic/#labs_linux .

    Zároveň ale od velkých uživatelů (kteří s námi komunikují přímo a ne skrz maintainery distribucí) víme, že chtějí poslední verze balíčků a buď používají naše repa nebo si dokonce balíčky kompilují sami - a to _zejména_ když jde o kritickou infrastrukturu. Např. RIPE NCC které na Knotu provozuje DNS root server K a vždy běží na poslední vydané verzi (navzdory tomu, že u autoritativního serveru udržujeme dvě řady - starší a poslední, RIPE NCC používá tu poslední).

    Problém s neopravenými chybami v distribucích (ale opravených v poslední verzích software) je reálný, vizte např. paper od SIDN: Kapitola 5. Resolver software evaluation v PDF https://www.sidnlabs.nl/downloads/53BNt9EPxZQOCHYjqWhYfR/7295d79a207afc79cab6309d40a15a76/When_parents_and_children_disagree_Diving_into_DNS_delegation_inconsistency.pdf

    Snad jsem na nic nezapomněl.

    Zkrátka: Máme otevřenou pracovní pozici pro "balíčkovače", takže jestli máte odhodlání přiložit ruku k dílu, tak máte možnost. Inzerát je zde: https://www.nic.cz/page/321/kariera-v-cznic/#labs_linux

    22. 5. 2020, 09:50 editováno autorem komentáře

  • 22. 5. 2020 10:39

    Danny

    A muzu se zeptat, proc ten minimálni patch pro NXNSAttack neni vami dosud na snadno dohledatelnem miste zverejnen? A pokud patch existuje, pak prece uz nic nebrani tyto patche aplikovat a vydat opravne verze naprimo - treba pro 3.2.2... vzdyt to musi byt hotove rychleji, nez sepsani celeho toho Vaseho komentare :-) V clanku se tvarite, ze opravujete akorat predchozi 5.1.0 a na zbytek ze se jako kasle, ani odkaz na ten minimalni patch v clanku nezverejnujete - tomu prece take vubec nic nebrani...

    A prosim nesmesujte vyvoj Knotu (ad Vas argument s pouzitim u RIPE; na k-rootu kresd fakt nebezi) a Knot-resolveru. Oba vime, ze jde o zcela oddelene produky - a to i systemem podpory, ale i cetnosti vydavani novych verzi. Zatimco k loni v breznu vydane 2.8.x vetvi Knota se podstatne chyby opravuji i po rijnovem vydani 2.9.x, u Knot-resolveru nic takoveho neni, realne chyby opravujete jen ve verzi vydane letos na konci dubna a jinak nic. U kresd od toho lonskeho brezna vysla v dubnu 4.0.x, v cerevenci 4.1.x, v srpnu 4.2.x, v prosnicni 4.3.x, letos v lednu nasleduje 5.0.x, v dubnu 5.1.x. Vsimate si, ze u Knotu ten vyvoj proste neni tak divoky? :-) A i o tom je tato diskuze. Zkuste se inspirovat u svych kolegu ;-)

  • 22. 5. 2020 11:15

    Petr Špaček

    Odkaz na distros list (v mém minulém příspěvku) vysvětluje jak to funguje a že všechna komunikace je po konci embarga zveřejněna na https://www.openwall.com/lists/oss-security/, kde najdete náš i náš patch: https://www.openwall.com/lists/oss-security/2020/05/19/2

    Tamtéž se dočtete:


    Minimal patch is attached but we generally do not recommend backporting.

    Knot Resolver version 5.1.1 includes mitigation and is available from
    https://www.knot-resolver.cz/download/


    Jinak řečeno, pokud by distribuce chtěly, mohly patch použít dokonce i _před_ ukončením embarba. S minimální úpravou jde aplikovat na všechny verze od 3.2.1 až po 5.1.0 a pokud by maintainer konkrétního balíčku měl zájem, tak by mohl mít opravený balíček připravený v okamžiku kdy je chyba zveřejněna. Bohužel Debian maintaineři tento zájem u Knot Resolveru dlouhodobě neprojevují. Pokud máte ambici stát se Debian/Ubuntu maintainerem a zkusit tlačit aktualizace "zevnitř distribuce", tak máte možnost - na tuto pozici hledáme člověka https://www.nic.cz/page/321/kariera-v-cznic/#labs_linux .

    Vaši odpověď o K-rootu lze interpretovat buď jako nepochopení toho co píšu, nebo argumentační faul, protože odpovídáte na něco jiného než píšu. Přikloním se k smířlivější variantě a zkusím to přeformulovat, abych napravil nepochopení:

    Snažil jsem se ilustrovat, že kritická infrastruktura K-root serverů běží na poslední verzi software, přestože Knot DNS konzervativně udržuje i větev s "předchozí" verzí. Navíc když se podíváte do changelogu verze Knot DNS 2.9.4 https://www.knot-dns.cz/2020-05-05-version-294.html, která je už na K-rootu nasazená, tak zjistíte, že technicky vzato obsahuje "nekompatibilní" změnu protokolu pro ANY dotazy (hned první odrážka).

    Zkrátka i nekompatibilní změny můžou mít svůj dobrý důvod a když se s nimi zachází rozumně, tak přispívají k lepší stabilitě ekosystému.

    Chápu, že dlouhodobě nesouhlasíte se způsobem vedení projektu Knot Resolver - váš názor tu slyším poměrně často a přemýšlíme o tom, nicméně argumenty už zazněly a nevím co dalšího dodat.

    Znovu opakuji, že pokud vy nebo kdokoliv další chcete na situaci něco změnit, tak máte možnost - přihlaste se na https://www.nic.cz/page/321/kariera-v-cznic/#labs_linux a můžete se pokusit svět pohnout směrem ke světlým zítřkům.

    Díky za pozornost!

  • 22. 5. 2020 14:58

    Danny

    Minimal patch is attached but we generally do not recommend backporting.

    A v tom bude ten zakopany pes. Sice poslete nejaky patch, ale soucasne k nemu vydate doporuceni jej nenasazovat. A doporuceny prechod na verzi 5.1.1 je s ohledem na politiku distribuce (ktera je dana a package-maintainer se ji musi ridit) ve stabilni vetvi nepruchozi. A mame tu uzasny dead-lock. Vytvoreny Vami osobne, gratuluji :-)

    Chladnym reakcim maintaineru z Debianu po tom, co jste sami predvedli na knot-resolver-users mailing-listu se popravde uz ani nedivim.

    K-rooty sem netahejte, ty bezi na kdecem - a rozhodne ne vzdy na poslednich verzich (Bind maji nekde kolem 9.14). I kdyby vypli vsechny instance s Knoty 2.9.x, tak si toho nikdo prakticky nevsimne. Rozhodne neni pravdive tvrzeni, ze by pouzivali vyhradne posledni verze software, navzdory faktu, ze u Knotu tomu treba tak i je (zajimave nicmene je, ze neuvadite datum, kdy to nasadili). A navic se chlubite cizim perim.

  • 22. 5. 2020 19:39

    Vladimír Čunát

    Pořád se točíme v tom samém problému. Udržování starých verzí a backportování patchů stojí práci, pokud to má být kvalitně. Zatím bylo rozhodnutí projektu věnovat úsilí jiným věcem.

    Osobně jsem ani přání na údržbu starších verzí neslyšel od většího počtu uživatelů, ale do budoucna to rozhodně vyloučené není. Ono taky až bude mít projekt za sebou delší historii, čekám že se jeho vnitřek bude měnit méně a bude tohle i jednodušší. V obou těchto aspektech je autoritativní Knot DNS prostě v jiné situaci.

    Mimochodem, u jednoho staršího CVE pamatuji potíž, že složitý patch (prý) bylo těžké do stabilního Debianu protlačit i když jsme nevěděli o žádných nekompatibilitách. Byla to situace kdy jsme neviděli jednoduchou opravu a prostě bylo potřeba některé části překopat. Samozřejmě, takové situace se často i špatně backportují, ale tehdy zrovna nebyl dlouhý skok v čase.

  • 22. 5. 2020 21:56

    Danny

    Ano tocime se v kruhu. Krucialni otazkou jest, odkud ti vyvojari cerpaji ty sve pocty uzivatelu, kteri se ozvou. Treba cisla o subscriberech na knot-resolver-users urcite mate, ale o tom jak dopadla zpetna vazba jsme se uz bavili. Koho tam mate dal? Par korporatnich zakazniku? :-) Realne se podobnych debat ale bude ucastnit mozna par zapalenych power-useru, ale rozhodne ne masy lidi. Bezny uzivatel v pripade problemu spise zareaguje tak, ze rovnou zvoli jine reseni - nez aby se vztekal s nejakou podobnou debatou - on totiz na ni ani nema cas. Udela to tise. Bez kravalu.

    Pozadavek na udrzbu starsich verzi prirozene vychazi z toho, jak funguje zivotni cyklus vetsiny klicovych distribuci, co lidi pouzivaji. Jejich politika je verejna a dohledatelna. Bohuzel vyvojari - viditelne i v CZNIC - asi proste zcela ignoruji, i kdyz jde o procesy zde kolem nas pritomne cele roky. Zrovna konkretne v pripade kresd jsme realne u toho Debianu ve stavu, kdy mezi full-freeze aktualni stabilni verze distribuce a dnesnim dnem bylo vydano 10 novych verzi - a z toho 6 nelze oznacit za minor vydani. Ta cisla jsou proste silena, normalni dzungle - vyprodukovana behem roku a kousek. Fakt mi netvrdte mi, ze vyvojari nevedi, jak vyvojove cykly bezne linuxove distribuce funguji - vedi to velmi dobre - ale proste na to kaslou a spokojene chrli nove a nove verze s tim, ze okolni ekosystem je proste nezajima. A kdyz uz teda milostive vydaji nejaky bezpecnostni patch, jeste vam podsunou poznamku, ze jeho nasazeni vlastne nedoporucuji. Proboha, cim takove vety autor premyslel?

    Ale rozumim, v CZNIC LABS mate asi holt politiku takovou jakou mate. Pro me je to informace, ze je lepsi kresd rovnou odinstalovat, nahradit necim jinym - a hlavne nikomu ve svem okoli pouziti tohoto vaseho produktu rozhodne nedoporucovat. I takovy Unbound, kdyz clovek nechce byt monokulturnim "bindarem" funguje podstatne lip... :) A vim, ze nejsem jediny, kdo takto od kresd utece - ja o tech problemech mozna promluvim nahlas - ale je hromada lidi co takto ztracet cas podobnou debatou fakt nebude... takze se vratime k tomu, co jsem psal - ze kresd je hracka pro geeky, ale neni to software nasaditelny tam, kde je treba dlouhodoby stabilni chod bez divokych konfiguracnich zmen.

  • 22. 5. 2020 22:26

    Filip Jirsák

    Danny: A co podle vás mají dělat vývojáři Knot Resolveru se špatně nastavenými životními cykly distribucí? Nemají to spíš řešit ti distributoři? navíc teda Red Hat i Canonical ten životní cyklus distribucí řeší, takže se vkrádá otázka, jestli teda není problém v tom Debianu.

  • 22. 5. 2020 23:00

    Danny

    A ze sam nejdete prikladem a drzite se pres dva roky stareho Ubuntu ;-) Jinak samozrejme vedete geekovske kecy cloveka, co v zivote nespravoval vetsi infrastrukturu a notabene ani svuj osobni webserver nedokaze provozovat podle tezi, ktere v diskuzich hlasa. Proc mate na svem serveru SSH 7.6, kdyz je davno venku verze 8.2..? Vy expernte na udajne spatne cykly distribuci... :D Vzdyt vam prece nic nebrani upgradovat a provozovat systemy, kde jsou cutting-edge verze vseho software.. :-) Nebo se toho sam bojite? :D Proste prestante kazat vodu se sklenickou vina v ruce ;-)

    Zivotni cyklus vetsiny distribuci je fakt, ktery se nezmeni aroganci a nasilim ze strany vyvojaru, jejichz jedinou motivaci je chrlit nove verze kodu idealne kazdy mesic k naplneni vlastnich KPI - bez ohledu na kvalitu vyprodukovaneho kodu. A on fakt knot-resolver neni jedina volba. Rozhodne neni problem sahnout po produktech, kde i ten bezny zivotni cyklus tech mainstreamovych distribuci respektuji.

  • 22. 5. 2020 23:17

    Vladimír Čunát

    Není to až tak černobílé jak to prezentujete.

    Unbound je moc pěkný a obecně ho doporučuji, ale zrovna taky neudržuje více větví, ani CVE backporty od nich nepamatuji :-) Někteří distribuční maintaineři jistě budou backportovat... nakonec to je myslím důležitý důvod proč se kupují enterprise distra.

    Naštěstí tu je alespoň ten BIND, nakonec diverzita je jeden z argumentů proč kresd vznikl - různé (ne)výhody, různé množiny bugů, apod. Osobně jsem to bral tak, že pokud někomu vadí občasná změna konfigurace dle návodu v NEWS, novou implementaci resolveru nejspíš stejně nezvolí (kresd existuje jen pár let).

    Asi to víte, ale běžné distribuce neignorujeme a vydáváme pro ně balíky (aktuálních verzí kresd). Právě proto, že při absenci backportů distribuční politiky často preferují zranitelnou verzi před potenciálně nekompatibilní. No proč ne – různí lidé mají různé priority, takto mají uživatelé k dispozici obě možnosti (když není k dispozici ta ideální).

  • 22. 5. 2020 23:42

    Danny

    Ale u Unboundu vam aspon naostro nenapisou, ze backport patche ani nedoporucuji. Chapu, ze hajite sveho kolegu - ale tohle je proste chyba.

    Problemy popsane jinde nejsou zadna novinka. Blbe se reprodukuji - ono v produkcnim prostedi jaksi neni cas a prostor debugovat podobne nahodile problemy. V pripade kresd zdaleka nejde o jediny podobny tohoto typu. Ne kazdy ma vubec nervy na to, aby to reportoval... proste se na nejakou diverzitu vykasle a vrati se k reseni, ktere funguje ;-)

    Zasadni konfiguracni zmeny jen kvuli bezpecnostnim updatum jsou navic zasadni prekazku pro automatizovany deployment bezpecnostnich zaplat standardnimi prostredky distribuce, pisu to uz ponekolikate. Je ptakovina ocekavat, ze s kazdym security updatem (kde je zadouci rychly deployment) bude u konzole sedet nekdo, kdo vyresi vyvojarske vrtochy kolem zmen konfigurace.

    Ano, kresd existuje sotva par let, ale tim spis je videt, jak ten vyvoj je chaoticky. Ono vyvoji, vcetne tech zmen (kterych navzdory mladi projektu neni malo) obvykle predchazi nejaka analyza problematiky a pozadavku. Kdo vlastne dela analyzu pred tim, nez se zacne neco kodovat? ;-) V debate - a i jinde - se projevuji az ti programatori... mate vubec nejakeho analytika...?

  • 23. 5. 2020 1:01

    Vladimír Čunát

    Nezkoumali jsme jestli ty patche fungují správně i na nějakých starých verzích. Přijde mi lepší to explicitně přiznat, aby to někdo nepochopil špatně.

    Releasy s CVE záměrně neobsahují nekompatibilní změny, takže kdo neodkládal, měl to triviální (zvláště při použití našich repozitářů). Problémy s kresd samozřejmě existují a tady lze ilustrovat ten tradeoff – pokud bychom udržovali další větve, zbylo by méně času takové problémy řešit.

    S analytikem a programátory jste mě pobavil... celkově to zní, že jste měl představu velkého týmu, ale celý projekt má jen pár lidí. No možná jste nemyslel výhradního analytika. Každopádně, kód bez rozmyslu nepíšeme, ovšem takové základy jistě nemá smysl tady diskutovat.

  • 23. 5. 2020 9:06

    Danny

    Jenze vy jste puvodne napsali, ze pouziti patche nedoporucujete. Ted ale otacite a jen rikate, ze to jenom nebylo testovano. To je ale dost podstatny a zasadni rozdil. Spatne to bylo formulovano uz od vas, neotacejte to na spatne pochopeni ze strany ctenare takoveho sdeleni.

  • 23. 5. 2020 9:36

    Vladimír Čunát

    Já otáčím? Evidentně je tu nedorozumění co to "nedoporučujeme" mělo znamenat. Nezkoumali jsme jestli by patch fungoval dobře s jinými verzemi, a proto jeho použití na jiných verzí nedoporučujeme.

    Je to prostý důsledek celkového stavu, že podporu zdarma v tuto chvíli děláme v podstatě jen pro nejnovější verzi (což chápu že některým chybí). Přijde mi to normální – i jinde běžně vydá upstream patch pro jedinou verzi, jen neřeknou zda je určen i pro jiné.

    Samozřejmě, pokud to nějaké distro backportuje, je to na jeho odpovědnost a ani nemáme jak to "zakázat". Nestačí právě "otestovat". Máme hromady automatických testů, ty by pro nás bylo triviální pustit, kdybychom věděli na jakou verzi chce uživatel patch použít. Ale aby to byl kvalitní backport, je potřeba rozumět všemu kódu okolo který s tím souvisí (v konkrétní verzi), což je pro lidi co daný projekt neznají myslím dost těžké.

  • 23. 5. 2020 14:26

    Danny

    Resolve DNS names like it’s 2020... code programs like it's 1990 :-)

    Pokud je pro vas trivialni pustit sadu testu, pak mi unika duvod, proc je tak strasny problem vzit ciste jen ty bezpecnostni patche, aplikovat je na nektere starsi (odladenejsi) vetve a proste vydat jejich povysenou minor verzi... a vedle mit vyvojovou branch, kde honite cool&in featury. Pro produkcni nasazeni je vazne nepouzitelna politika vyvoje, kdy kazde dva-tri mesice vydate novou major verzi - s tim, ze na ostatni kolem i co do bezpecnosti kaslete a navic okorenene tim, ze ta major verze obvykle prinasi nejakou incompatible change. Viz to, co pisu uz v prvnim prispevku.

  • 23. 5. 2020 10:03

    Filip Jirsák

    Danny: Víte, to je rozdíl mezi zodpovědným vývojářem, který svůj program dobře zná, a běžným uživatelem – který o programu ví jenom to, co se někde dočte. A bohužel podlehl dojmu vytvářenému distribucemi, že záplatovaná stará verze je stejně bezpečná, jako aktuální verze.

    Zodpovědný vývojář vám k patchi na starou verzi řekne: Tady máte patch, ale nedoporučuju ho používat, doporučuju používat aktuální verzi. Přesně tohle je napsané i v tom odkazu, který linkujete – vy jste se sice snažil manipulativně přesvědčit čtenáře, že autoři Knot Resolveru nedoporučují aplikovat tento konkrétní patch a jakoby naznačovali, že kresd bez patche je pořád lepší, než s tímhle patchem. Jenže v tom e-mailu je trochu něco jiného:

    Minimal patch is attached but we generally do not recommend backporting.

    Obecně nedoporučujeme backportování. Přesně to, o čem tady celou dobu píšu.

    Asi je to problém komunikace od vývojářů k běžným uživatelům. Vývojářům totiž není nutné vysvětlovat, proč nedoporučujete backportování. Ale jak je vidět, běžní uživatelé to nechápou. (A není to úplně jejich vina – pokud jim distribuce celou dobu tvrdí, že změny v programech jsou nebezpečné, ale backporty jsou bezpečné, nemají důvod tomu nevěřit a třeba přemýšlet o tom, že backport není nic jiného než změna v programu).

    Stejné nedorozumění vzniklo třeba při ukončení vývoje TrueCryptu. Vývojáři také tehdy prohlásili „nepoužívejte TrueCrypt, od teď musí být považován za děravý“. Uživatelé z toho byli zmatení, spekulovali o tom, že autory někdo donutil ukončit vývoj, nebo že autoři vědí o nějaké vážné díře. Vývojářům to bylo jasné – v každém programu mohou být chyby, a pokud se o jeho vývoj nikdo nestará, chyby nemůže nalézat a už vůbec ne opravovat. Takže pokud chybu někdo najde, bude to někdo z venku a chybu už nikdo neopraví.

    Prostě je to rozdíl mezi vývojářem, který chce, aby se používala ta nejméně chybová verze a nejbezpečnější jeho programu, a uživatelem, pro kterého každá aktualizace znamená nějakou práci nebo alespoň riziko problémů – zatímco setrvat u současné verze je jenom riziko toho, že provozuje verzi s chybami a bezpečnostními problémy. Ale pořád je to jenom riziko, že…

    Pak se klidně může stát, že vývojář je zároveň i uživatelem, a provozuje starší verze cizích programů, protože tam je přeci jenom riziko chyb, jejichž podstatě pořádně nerozumí.

  • 23. 5. 2020 13:11

    Danny

    Vyvojar, kteremu jde o co mozna nejbezpecnejsi kod nechrli kazde dva mesice za kazdou nove verze kodu, kde v honbe za novymi funkcionalitami vnasi casto spoustu novych chyb - hlavne aby si asi splnil nejaka sva KPI. Ona kvantita (releasu) skutecne neimplikuje kvalitu vysledku - a ani vetsi bezpecnost. Ba prave naopak. Casto se honi release za kazdou cenu. A riziko - i bezpecnostni - chyby je pak proste vetsi. Ono take neni neobvykle, ze pred vydanim finalni verze se take vydaji nejake -RC, ktere si muzou zajemci otestovat driv, nez se naostro vypusti ta jedina oficialne podporovana verze. Vyvojovy model i u toho Unboundu je v tomto bode podstatne pricetnejsi, nez u Knot resolveru - a hlavne ani ty upgrade negeneruji nesmyslnou praci v podobe prepisovani konfiguraku, protoze se vyvojar rozhodl to pro svoji potechu cele buhviproc najednou ze dne na den prekopat. V tomto jsou ty posledni verze Knot resolveru aktualne proste v dlouhodobem pohledu nepouzitelne - nova major verze je ted venku vlastne kazde dva mesice a nikdy dopredu nevime, co se vlastne chysta - a co v te dalsi verzi bude zase jinak...

  • 23. 5. 2020 16:56

    Vladimír Čunát

    Ta nechápavost... "major" je to první číslo - ano, výraznější uživatelské změny (jako ty systemd sockety) se dělají jen při jeho změně. To nastalo za těch několik let zatím pětkrát (1 až 5), orientačně jednou ročně. Druhé číslo se nazývá "minor". Třetímu se obvykle říká "patch". To není můj výmysl.

    Oficiální releasy považujeme za vhodné do produkce a taky je tam nasazujeme (cz.nic ODVR). Pre-releasy jsme téměř nedělali a jste první kdo o ně projevil zájem (akorát to evidentně nebylo myšleno tak, že byste je použil).

    No, zkusil jsem to už příliš dlouho... bohužel nevidím zájem vnímat co píšu, spíše čím dál více jen chrlit kritiku. Věcnou kritiku mám rád, třeba to že vám chybí stabilní větve, ale pak se to zaplnilo různými překroucenými fakty, polopravdami, apod. Nechci spekulovat o tom, jestli je vytváříte záměrně nebo nevědomky. Výsledek je, že ta komunikace nikam nevede. Škoda. No třeba alespoň ostatní naleznou v odpovědích něco co je zajímalo.

  • 24. 5. 2020 9:48

    Danny

    Zmateni v pripade kresd vznika proto, ze nekompatibilni zmeny delate i v minor verzich. Dobre, takze to vezmem od zacatku:1.0.0 vysla 2016-05-30, po dvaceti mesicich - 2018-01-31, - vysla 2.0.0. A pak to zaclo: 3.0.0 vyslo 2018-08-20 - ani ne po sedmi mesicich, 4.0.0 - 2019-04-18 - po osmi mesich, 5.0.0 - 2020-01-27 - po deviti mesicich. Proste v kadenci maximalne trictvrte roku, v prumeru dve tretiny roku nova major, nejspis kvuli.. marketingu :-) Chrli se nove funkce i za tu cenu, ze ani nejsou poradne odladena veci existujici - nektere veci jsou otevrene a nevyresene jiz nekolik let a nechavaji se hnit.

    Nove ODVR spustene loni v dubnu taky neni zrovna idealni reference. 19.6.2019 se prepnuli uzivatele TurrisOS na nova ODVR na Knot-resolveru a od 23.6.2019 lze registrovat stiznosti na nefunkcnost ODVR a vraci se to i v zari. To se starym ODVR provozovanem na Unboundu nepamatuju. O pricinach vypadku novych ODVR na kresd se mlzi - nikdy se otevrene nepriznalo, co tam bylo za problem. Spekulovat muzeme jen na zaklade nekterych reportovanych chyb v gitu. Muzu se domnivat, ze ze pravdepodobne bojujete se vsim, co neprichazi po UDP [treba #551,#542,#489 atd] - a nektere problemy se asi snazite obejit tim, ze nektere funcionality byste radi odklidili do jineho procesu, tak aby to nevyhnivalo kompletne - kdyz majorita dotazu preci jen prijde po UDP - jenze to je taky metoda zametani prusvihu pod koberec, aby nebyly tak na ocich...

    Klidne si to berte jako jen kritiku. Ja s ni take nemusim ztracet debatou cas, odinstalovat kresd a nahodit roky provereny a hlavne skutecne spolehlivy Unbound je vcelku ultimatni reseni. Klid budeme mit oba :-) Je to sice smutne priznat, ze Holandani to umi lip nez Cesi, ale co se da delat ;-)

  • 22. 5. 2020 11:45

    Filip Jirsák

    A prosim nesmesujte vyvoj Knotu a Knot-resolveru.
    Myslím, že byste si mohl ty průhledné pokusy o manipulaci odpustit. Knot DNS Server nebyl zmíněn jako odvedení pozornosti od Knot Resolveru – demonstrovalo se na něm kritické nasazení aplikace. Která je dostupná přímo v upstreamu v aktuální a LTS verzi, a v tom kritickém nasazení se nepoužívá LTS verze, nýbrž ta aktuální.

    Vsimate si, ze u Knotu ten vyvoj proste neni tak divoky?
    Všiml jste si vy, že rekurzivní DNS resolver je komplikovanější software s větším množstvím bezpečnostních implikací, než autoritativní DNS server?

  • 22. 5. 2020 12:48

    Danny

    Ona ta aktualni major 2.9.x verze je tu taky jiz od rijna 2019 (takze v mezicase i hromada casu na otestovani) - a od te doby se jen opravuji drobnosti. To je trosku rozdil od verze 5.1.x, ktera tu s nami neni jeste ani mesic. Srovnate nesrovnatelne a jeste demonstrujete neschopnost prace s casovou osou ;-) Navic v ramci anycast instanci K-rootu se neprovozuje jen Knot2, oni tam v ramci diverzity maji i NSD4 nebo Bind9.14. Ono ani v RIPE nejsou takovi ostrostrelci, aby nasadili nejnovejsi verze vsude.