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

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.

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.

Příště doporučuji dočíst až do konce komentář, na který chcete reagovat. Nebo to API nekonzumují moduly?

Melete tam pak uz jen neco o Dockeru, asi to bude nejaky vas svaty gral :-) Ale tu dokumentaci kresd API jste zjevne ani neotevrel.

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.

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áří.

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.

Kolik je těch modulů, které mají problém s novějšími verzemi? Opravdu chcete takové moduly používat?

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.

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í.

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.

Ř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.

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).

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 ;-)

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.

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 :-)

> 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.

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šší.

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ší?

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.

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.

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é.

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 :-)

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.

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.

TL;DR: Vyse mate potvrzeno, ze odstraneni systemd socketu s bezpecnosti nijak nesouviselo. Mame dokonce ozdrojovano, ze chlapcum se to jen zdalo slozite pro nastaveni. Nic vic, nic min.

@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.

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.

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?

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.

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.

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.

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

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.

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... ;-)

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.

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í.

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...

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.

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.

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.

"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.

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.

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í.

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.

@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,...

Ok, chápu Vaši tezi.

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.

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...

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.

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.

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).

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.

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.

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.

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.

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.

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í).

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...?

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.

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.

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é.

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.

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í.

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...

Danny: Vidím, že už řešíte jenom své dojmy.

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.

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 ;-)

Danny: Zdá se, že počítáte s tím, že si ty vaše odkazy nikdo neotevře, a nepozná tak, jak moc mlžíte a překrucujete. To je ale chybný předpoklad.