Názory k článku Knot Resolver a soukromí: méně úniků informací z DNS dotazů
-
MartinX (neregistrovaný)
Jedna poznamka:
V repozitari Ubuntu 16.04 LTS je knot-resolver v prastarej verzii 1.0.0-beta3 (aktualna je 2.2.0), ktora pravdepodobne DNS-over-TLS este nepodporuje, pretoze po pridani prislusnej policy sluzba nechce odstartovat (cert-bundle som nastavil na . /etc/ssl/certs/ca-certificates.crt ) -
Máte pravdu, Unbuntu i Debian stále dodávají velmi staré balíčky, které ani nemají opravené bezpečnostní chyby. Doporučujeme nepoužívat balíčky dodávané distribucemi Ubuntu a Debian.
Doporučuji stáhnout si nové balíčky z pro vaši distribuci https://www.knot-resolver.cz/download/ , respektive https://software.opensuse.org//download.html?project=home%3ACZ-NIC%3Aknot-resolver-latest&package=knot-resolver.
V článku je v příkladu konfigurace chyba, prosím použijte následující příklad:
policy.add(policy.all(policy.TLS_FORWARD({{
'1.1.1.1',
hostname='cloudflare-dns.com',
ca_file='/etc/pki/tls/certs/ca-bundle.crt'
}})))S další konfigurací vám rádi pomůžeme na našem mailing listu:
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-resolver-users -
https://packages.debian.org/search?keywords=knot&searchon=names&suite=all§ion=all
Mně to u Stretch-backports ukazuje verzi 2.6.5-3~bpo9+1
A že Debian neopravuje bezpečnostní chyby? Nemá to něco společného s upstream vývojáři?
-
No, přímo v Debianu teď cz.nic vlastního člověka nemá, ale knot-resolver tým úzce spolupracuje s jejich maintainery. Navíc nově nabízí(me) vlastní (nedistribuční) balíčky pro řadu distribucí: https://software.opensuse.org//download.html?project=home%3ACZ-NIC%3Aknot-resolver-latest&package=knot-resolver
-
O nich ja vim... ale zablesovani apt sources.list 3rd party repozitari nebyva z dlouhodobeho pohledu (mj. budouci dist-upgrady) zrovna stastne reseni - a cela rada uzivatelu ani neni ochotna ty "cizi" repozitare pouzivat. Mit aktualni verze v sid/testing a nasledne je tlacit do oficialnich backportu ci updates je myslim rozumnejsi cesta.
-
Porad chodime kolem horke kase a pritom je to tak jednoduche - proc sam CZNIC (resp. lide z nej) se nestanou maintainery balicku u software, ktere vyviji? Tech projektu je prece uz pomerne dost, ze by to stalo za systemove reseni pro vsechny projekty...
-
Děkujeme za oživený zájem o Debianí balíčky! Budeme pokračovat ve spolupráci se současnými maintainery a když to bude potřeba, tak se tam taky zkusíme dostat.
Stát se maintainerem není zas tak jednoduché, https://wiki.debian.org/DebianMaintainer#Advocating_a_Debian_Maintainer má slušnou řádku požadavků, takže to chce čas.
-
Nenazyval bych to oziveny. To spis puvodni repozitar pomalinku odumira a prestava byt aktualizovany, tak jak z labsu vychazi nove verze - ktere se tam uz neobjevuji. Aktualni reseni je postavene na "presuneme to jinam" - coz ale uzivatele puvodniho repozitare nemusi nutne zaregistrovat. Nehlede na to, ze na puvodnim miste ani neni zminka o tom, ze by bylo obsoletni, je vybavene firemnim logem a cast jeho administratoru s CZ.NIC neco spolecneho ma...
Nikdo nerekl ze to je "jednoduche" - na druhou stranu lze ale predpokladat, ze autor daneho software bude mit tu podporu vyrazne snazsi v porovnani s nahodnym kolemjdoucim. Zvlast v pripade organizace typu CZ.NIC.
-
Petr Špaček (neregistrovaný)
Děkujeme za upozornění, upravili jsme popis repozitáře https://launchpad.net/~cz.nic-labs/+archive/ubuntu/knot-resolver tak, aby bylo jasné, že již není udržovaný a vyčistili ho.
Pokud používáte Knot Resolver, tak vám silně doporučujeme přihlásit se na mailing list
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-resolver-users
kam zasíláme upozornění na podobné změny.Přeji vám pěkný den.
-
Uznejte sam, ze kdyby se mel uzivatel prihlasit na mailing-listy ke vsem kouskum software, ktere pouziva, tak se z toho zakonite musi zblaznit ;-) A je otazkou, kolik lidi vubec bude ochotno neco takoveho udelat. Pochopte, ze ja se nebavim o reseni "pro sebe" - ja si poradit umim. Ale pokud jde CZ.NICu skutecne o vetsi rozsireni vlastniho produktu, tak podle meho nazoru tudy (pres repozitare nekde mimo distribuci, ktere tu a tam navic nekam presune) cesta nevede. Tou se vyda spis jen par nadsencu...
A je smutne pozorovat, jak uzkoprofilove resite jen svuj projekt. Mnou popsany problem v odkazovanem repozitari se netyka jen knot-resolveru, ale i dalsich projektu vyvijenych CZ.NIC. Ten problem je systemoveho razu a reseni bohuzel systemove neni.
-
Rozhodně se neřeší jen náš projekt; balíčkování se mění u více cz.nic labs projektů, zrovna včera proběhla naplánovaná široká interní diskuse. Řada projektů začala nebo plánuje používat OpenBuildService, což má i tu výhodu, že to je jednotnější způsob jak vytvářet "binární repozitáře" pro více distribucí najednou (přijde mi to celkem "systémové" řešení). Ale není to "big bang" přechod a nemá to reálně vliv na případné downstream balíčky.
-
A v ramci one systemovosti pujde o on-premise reseni (tzn. provozovane primo CZ.NIC; podobne jako gitlab labsu), nebo chcete spolehat na nejakeho tretiho poskytovatele sluzby? Aktualni reseni spoleha na treti stranu (soude napr. dle knot-resolveru) - a historie zna mnoho pripadu, kdy nejaka bohuliba sluzba po case ukoncila svuj provoz a pak z pohledu uzivatele opet nastava problem - opet ma neaktualizovany software, musi hledat noveho repozitare atd... a ja si skutecne nemyslim, ze by CZ.NIC nemel kapacity na to, aby svym projektum zajistil slusne a stabilni zazemi ;-)
-
On-premises řešení může skončit úplně stejně, jako skončí SaaS řešení. Ostatně SaaS vzniklo právě proto, že je většinou výhodnější a stabilnější, když se o to nemusí starat někdo zevnitř. „Nikdo to nedělá tak dobře, jak bychom to mohli dělat my, kdyby bylo vše ideální a měli bychom neomezené zdroje“ (známý též ve variantě NIH) je hrozný syndrom…
-
Knot DNS (neregistrovaný)
Ano, některé projekty nejsou aktualizované, ale za Knot DNS mohu říci, že tam aktualizace dáváme a budeme dávat ještě všechny verze řady 2.6! Zatím není rozhodnuto, za jakých podmínek se tam objeví budoucí verze 2.7.0, protože někteří uživatelé nemusí chtít hned takový skok. Mohu vás ujistit, že otázku balíčkování intenzivně řešíme, ale opravdu to není tak triviální a požadavky jsou často protichůdné. Z místních diskuzí je ale zřejmé, že se stejně nikdy nezavděčíme každému :-/
-
Reseni, ktere se objevuje u nekterych balicku je v podobe meta-balicku se zavislosti na binarni balik s konkretni verzi v jeho nazvu. Pak vcelku nic nebrani mit meta balicek odkazujici stale na starsi verzi/train, binarni balik se starsi verzi a soucasne nabizet i druhy binarni balik s verzi novou. Teprve, kdyz je dostatecna duvera v novou verzi a odladeny chyby vznikle implementaci novych funkcionalit se posune zavislost i v onom meta-baliku k nove verzi. Zas tak slozite to podle me neni ;-)
-
Knot DNS (neregistrovaný)
Díky za zajímavý tip. Složitost je v tom, že my vyrábíme balíčky pro Debian, Ubuntu, Fedoru/CentOS a další a rádi bychom to řešili nějak systematicky a nezbláznili se z toho a po pravdě s OBS je to značně pohodlnější. Např. pro budoucí Knot DNS se snažíme mít v repozitáři i metadata pro balíčkování, se snahou o co nejmenší diverzitu napříč distribucemi (https://gitlab.labs.nic.cz/knot/knot-dns/tree/master/distro). Včera jsem třeba také řešil problém, že po úklidu balíčkování v oficiálním repozitáři Debianu je díky přechodu na novější verzi debhelperu nemožné vytvořit v PPA balíčky pro starší verze než 18.04.
-
Palo M. (neregistrovaný)
Debian ma svoje dovody, preco nemeni cisla verzii v stable verzii (a podla mnohych su to VELMI dobre dovody). Ked Debian stretch zacal s knot-resolver verziou 1.2.0, tak uz tam bude verzia 1.2.0 nastalo, to je pomerne znama skutocnost.
Natiska sa otazka, preco pre tuto verziu nie su bezpecnostne aktualizacie? Pre vacsinu balikov v stable Debiane bezpecnostne aktualizacie chodia, preco nie aj pre knot-resolver? A vydava CZ.NIC vobec bezpecnostne aktualizacie pre tuto verziu? Ak ano, tak za absenciu aktualizacii moze maintainer debianich balickov. Ak CZ.NIC uz aktualizacie pre danu verziu nevydava, tak by ste moc nemali argumentovat tym, ze v distribucii opravy nie su, pretoze v tom pripade maintainer akosi nema co updatovat.
Ked pozeram na Debian stable-backports, testing a unstable, tam vidim nove verzie. Podla toho to vyzera, ze maintainer sa o balicek stara.Tak ako to vlastne je?
-
Ne, my (knot-resolver tým) neudržujeme bezpečnostní aktualizace pro 1.2.0 a jsou tam známé závažné chyby (třeba CVE-2018-1000002). Pro drtivou většinu z těch tisíců balíčků tohle upstream nedělá, protože řadu chyb s bezpečnostním rizikem prostě nejde opravit jednořádkovým patchem a kód po tom roce už vypadá hodně jinak, takže údržba každé stabilní verze pak stojí hodně práce navíc.
-
Dobrý den,
začnu tím nejdůležitějším:
CZ.NIC udržuje jednu stabilní verzi v řadách 1.y a 2.y. V řádu měsíců (až Turris OS přejde na řadu 2.y) ukončíme podporu řady 1.y, která je již dnes zastaralá a postrádá důležité funkce jako např. agresivní cache (RFC 8198), která chrání před některými typy útoků na DNS.Máte pravdu, že distribuce jako Debian a RHEL/CentOS mají ve zvyku jednorázově importovat konkrétní verzi software a tu potom patchovat, což je jejich politické rozhodnutí. To samozřejmě klade zvýšené nároky na maintainery balíčků, kteří pak musí být v kontaktu s vývojáři software a řešit backport oprav z novějších verzí. CZ.NIC se snaží maintainerům vyjít vstříc a jsme např. v kontaktu s maintanerem v Debianu (tj. dkg). Po společné debatě s dkg jsme došli k závěru, že nedává smysl dále udržovat zastaralou verzi 1.2.0, takže se ve stretch-backports objevila verze z řady 2.y.
K otázce ohledně "bussiness linuxu":
Bussiness/enterprise distribuce se prodávají kvůli podpoře od výrobce dané distribuce, takže je zcela na výrobci distribuce, aby rozhodl (opět obchodní politika!) jaké balíčky do ní zařadí a jak dlouho je bude podporovat. Je proto možné, že nějaká jiná firma může podporovat Knot Resolver 1.2.0Všem uživatelů CZ.NIC nabízí nejnovější stabilní balíčky (v řádu hodin po vydání nové verze) pro CentOS/Debian/Fedoru/Ubuntu, ty jsou k dispozici v repozitářích projektu Knot Resolver odkazovaných z https://www.knot-resolver.cz/download/ .
Pro "bussiness" zákazníky CZ.NIC nabízí placenou podporu pro poslední verzi Knot Resolveru, tj. tato podpora není nijak vázána na verzi balíčku v distribuci.
Snad se mi podařilo vyjasnit situaci.
-
vfhhhcc (neregistrovaný)
Typický vývojář dnešní konzumní doby. Jen dokola chrlit nový a nový kód. Ten starý udržovat a opravovat už ale nechce. Životní cyklus předem deklarovaný není. Prostě dnes vstanu a rozhodnu se, že na starší verzi kašlu. Vývoj v podání CZ.NIC je horší, než u Microsoftu. Tam aspoň vím, kdy mi podpora končí.
-
Lol Phirae (neregistrovaný)
Vývoj v podání CZ.NIC je horší, než u Microsoftu. Tam aspoň vím, kdy mi podpora končí.
Tak určitě...
https://www.petri.com/microsofts-making-changes-windows-10-lifecycle-extended-support-versions
https://rcpmag.com/articles/2018/02/02/microsoft-support-windows-10-office.aspx -
Lol Phirae (neregistrovaný)
Nech si to přeložit, zjevně ses minul s textem. A pak si třeba zagoogli, kolikrát se měnila podporu u W10. Včetně toho, že LTSB (nyní LTSC, ještě možná snad) sice podporována bude, ale pouze na HW, který se v tu dobu prodával. Na novějším už ne. To je firmám opravdu hodně platné.
-
Petr Špaček (neregistrovaný)
Prosím pamatujme na to, že DNS resolver je ve velmi specializovaná věc a proto srovnání např. s kancelářským balíkem nebo obecným operačním systémem není 1:1. Ekonomické faktory jsou u DNS software velmi odlišné.
Podporu "na míru" s garantovanou podporou můžete získat za podmínek nastíněných na https://www.knot-resolver.cz/support/ .
-
Knot DNS (neregistrovaný)
Na základě čeho soudíte, že jsou projekty jako Knot Resolver ekonomicky nevýhodné? Samozřejmě na počátku byla nezbytná vstupní investice, ale dnes již přinejmenším část nákladů (v závislosti na druhu projektu) pokrývají příjmy z placené podpory. Vývoj serveru Knot DNS má navíc i strategický význam, neboť se používá k provozu samotné domény .cz.
-
DNS guru (neregistrovaný)
Knot DNS (tedy autoritativní část) není totéž co Knot resolver (rekurzor), který se vyvíjí odděleně. Autoritativní DNS strategický význam jistěže má kvůli diverzitě software nutného pro obsluhu .cz domény. Rekurzor pro chod top level domény strategicky k ničemu potřeba fakt není. Je to jen další hračka, bez otevřeného DNS se NICCZ taky obejde a peníze to jen žere. Ekonomickou výhodnost projektu nemáte jak doložit.
-
Knot DNS (neregistrovaný)
Vzhledem k tomu, že jsem zodpovědný za vývoj a podporu k projektu Knot DNS a mám po ruce smlouvy s platícími zákazníky (překvapivě žádný z České republiky), tak mě prosím nepoučujte o ekonomických nemožnostech takového projektu. Nepřísluší mi zveřejňovat podrobnosti, ale možná to půjde částečně rozklíčovat z výroční zprávy sdružení. Knot Resolver je úzce spojen se samotným Knot DNS a jde o mladší projekt, nicméně i ten má nezanedbatelné příjmy od zahraničních uživatelů. Kdybyste si článek k této diskuzi přečetl, tak byste si mohl udělat představu o našich zákaznících. Možná vás překvapí, že konkurenční DNS projekty (Bind, PowerDNS,..) vyvíjejí organizace, které ani nemají příjmy ze správy domén a musí se uživit. Projekt Bird, který také není přímo nezbytný k provozu domény .cz, je v černých číslech. Pokud vám leží v žaludku jiné projekty, tak prosím spamujte diskuze k jiným článkům. Děkuji
-
Palo M. (neregistrovaný)
OK, chapem, ale z toho mi vyplyva, ze verzia 1.2.0 (a pravdepodobne vsetky 1.x verzie?) bola len taka vyvojova (prechodna) verzia. V takom pripade ale bolo chybou nieco take do Debianu vobec davat (maximalne tak do experimental, ale rozhodne uz nie do testing a stable). Otazkou je, ci v tom case, ked sa verzia 1.2.0 do Debianu dostala, bolo zrejme, ze bezpecnostne updaty nebudu a cele sa to prekope (teda backporting oprav by vyzadoval take brutalne usilie, ze to za to jednoducho nestoji)?
Bud bolo od zaciatku planovane, ze az verzia 2 bude rozumne udrzovana, v takom pripade to malo byt viditelne kazdemu (a do Debianu stable sa verzia 1 nemala nikdy dostat)... alebo to povodne jasne nebolo, a az v priebehu casu CZ.NIC hodil cez palubu verziu 1 (a s nou aj vsetkych, ktori ju pouzivali) a vrhli sa na verziu 2?
Po mojich skusenostiach s Omniou mam tendenciu verit skor tej druhej moznosti. Teda ze nieco je prezentovane ako "hotove a funkcne, moze sa to nasadit", ale v skutocnosti to je na ostre nasadenie vysoko nevhodne. Pri Omnii sa to deje vo velkej miere a je to pre mna velke sklamanie (myslim, ze zrovna s kresd tam bol problem, ktory zasiahol vela uzivatelov Omnie, ked tam v ramci updatu pristala verzia, ktora sa spravala inak nez predosla a s istymi, pomerne casto pouzivanymi konfiguraciami to odstavilo cele DNS a potom bolo treba zmenit konfiguraciu aby sa to zase spravalo po starom - a nebolo to ojedinele, naposledy myslim mali ludia problem s honeypotom - ale v pripade vypadku DNS resolvera je to obzvlast brutalne).
Bud je to tym, ze v CZ.NIC zamerne "taktne pomlcia" o tom, ze veci sa budu prekopavat (a de-facto vmanipuluju do pouzivania aj takych ludi, ktori by to nepouzivali keby si toho vsetkeho boli vedomi), alebo skratka ziadne dlhodobe plany neexistuju, vyvoj je viac-menej zivelny a ked obcas nastane situacia, ze veci treba zmenit, tak sa CZ.NIC velmi netrapi s tym, ake problemy sposobia uzivatelom daneho softveru. Ako samozrejme, vsade je disclaimer "pouzivaj na vlastne riziko, my za nic nerucime", takze je to vlasne legalne.ALE! Ked sa CZ.NIC tolko snazi zlepsit bezpecnost na internete, mal by predsa len zobrat do uvahy aj to, ako sa uzivatelia (a admini) na taku vec budu pozerat. Pretoze takto sa sami pripravujete o kredibilitu.
Akokolvek som fanusikom knot-resolvera, na svojich debianich strojoch este dlho budem pouzivat len bind, pretoze aj ked ten ma vselijake problemy, je velky, nemotorny, atakdalej... ale bezpecnostne updaty nan stale chodia a nic sa pri nich nerozbije, skratka funguje predvidatelne.
(A ten repozitar z opensuse.org nemienim pouzit na taku dolezitu systemovu vec, ako je DNS resolver - hlavne preto, ze tam hocikedy moze pristat novsia verzia, ktora nebude fungovat s mojou konfiguraciou a odstavi mi cele DNS, a to naozaj nepotrebujem riskovat.)Skratka by ste mohli v CZ.NIC trochu zvazit ten vas pristup k novym verziam a updatom. Pretoze pri sucasnom pristupe je vysledkom, ze ludia zakazuju updaty na Omnii (pripadne hadzu Omniu nazad do krabice a davaju naspat srackovy lacny, ale pre nich fungujuci router), a na inych strojoch radsej pouzivaju bind nez kresd. A to pravdepodobne nie je zrovna taky posun v internetovej bezpecnosti, aky by ste si predstavovali...
-
OK, chapem, ale z toho mi vyplyva, ze verzia 1.2.0 (a pravdepodobne vsetky 1.x verzie?) bola len taka vyvojova (prechodna) verzia.
To je vlastnost drtivé většiny softwaru, že se průběžně vyvíjí. Nikdo není dokonalý a nenapíše dokonalý software na první pokus. Ostatně, i sám Debian vydává nové verze, Debian 7 i 8 byly jen takové vývojové (přechodné) verze…V takom pripade ale bolo chybou nieco take do Debianu vobec davat
Stejnou chybou bylo vydávat Debian 2 až 8, když to byly jenom přechodné vývojové verze a teď je aktuální devítka. A vsadím se, že ani s tou nebudou správci spokojeni, taky bude jen přechodná a po ní budou následovat další verze.Otazkou je, ci v tom case, ked sa verzia 1.2.0 do Debianu dostala, bolo zrejme, ze bezpecnostne updaty nebudu a cele sa to prekope (teda backporting oprav by vyzadoval take brutalne usilie, ze to za to jednoducho nestoji)?
Ano, bylo to zřejmé. Plyne to už ze samotného principu vývoje software.Bud bolo od zaciatku planovane, ze az verzia 2 bude rozumne udrzovana
Verze 1 i 2 jsou udržované stejně a jsou udržované rozumně. Knot DNS používá sémantické verzování, první číslo je hlavní verze, kde se dělají velké zpětně nekompatibilní změny. Druhé číslo verze jsou vedlejší verze, kde se přidávají nové funkce, ale nemělo by se měnit nic zásadního. Třetí číslo by mělo být vyhrazené pro opravy. Tohle je všeobecně přijímaný model verzování softwaru. V některých případech se akorát nerozlišují hlavní a vedlejší verze, protože pokud je těch změn hodně, je ta hranice subjektivní.
Rozumně udržovaná verze je nesmysl. Rozumně udržovaný je program, což znamená, že jsou vydávány nové verze s opravami a novými vlastnostmi. Udržovat paralelně vedle sebe několik verzí programu je nesmysl, od kterého všichni opouštějí, protože to jen zvětšuje komplexnost a zvyšuje množství chyb. Jediný velký protipříklad, který mne napadá, je Linuxové jádro – kde je to opět dané tlakem distributorů a vzniklo to tak, že když už si tedy udržujete staré verze a snažíte se je nějak podporovat, alespoň se shodněte na to, které verze to budou. A mimochodem i u toho linuxového jádra je to spousta práce, jejíž výsledek je velmi nejistý. Předpokládám, že i tam bude tlak na to udržování starých verzí eliminovat, zvlášť když se v linuxu extrémně dbá na to, aby se nerozbil uživatelský prostor.az v priebehu casu CZ.NIC hodil cez palubu verziu 1 (a s nou aj vsetkych, ktori ju pouzivali) a vrhli sa na verziu 2?
Takhle funguje vývoj. Staré věci se přestávají používat a místo nich se používají nové. Knot DNS verze 1.x nikdo přes palubu nehodil, místo ní tu máte Knot DNS 2.x, která ji plně nahrazuje a je lepší.Teda ze nieco je prezentovane ako "hotove a funkcne, moze sa to nasadit", ale v skutocnosti to je na ostre nasadenie vysoko nevhodne.
Smiřte se s tím, že software se vyvíjí. To, že po Debianu 8 následoval Debian 9 neznamená, že Debian 8 nebyl hotový a funkční a neměl se nasazovat.Ked sa CZ.NIC tolko snazi zlepsit bezpecnost na internete, mal by predsa len zobrat do uvahy aj to, ako sa uzivatelia (a admini) na taku vec budu pozerat.
Jedním ze způsobů, jak výrazně zvýšit bezpečnost na internetu, je odnaučit uživatele a admini ten nesmyslný zlozvyk používat staré verze programů. -
To je vlastnost drtivé většiny softwaru, že se průběžně vyvíjí. Nikdo není dokonalý a nenapíše dokonalý software na první pokus. Ostatně, i sám Debian vydává nové verze, Debian 7 i 8 byly jen takové vývojové (přechodné) verze…
Až na to že debian 7 i debian 8(*) byly stabilní verze Debianu. Knot resolver 1 mi v době, kdy jsem ho zkoušel a byl prezentován jako stabilní, segfaultoval po pár dotazech. Rozhodně mi tehdy přišel jako ve fázi hlavního vývoje - more features to come. To není stav v jakém by se měl dávat balíček do distribuce která zmrazí verzi na další dva roky.
*) Debian 8 zas az tak stabilní nebyl protože zprasené systemd service files. Respektive software byl stabilní, ale když šlo o to ho restartovat (nebo autorestartovat) tak se systemd rozcházel se skutečným stavem služby více než předchozí sys-v init skripty. Tohle je v Debian 9 částečně opravné.
-
Knot resolver 1 mi v době, kdy jsem ho zkoušel a byl prezentován jako stabilní, segfaultoval po pár dotazech.
To je takový výkřik do tmy… Navíc nijak nesouvisí s předchozí diskusí.Rozhodně mi tehdy přišel jako ve fázi hlavního vývoje - more features to come.
Asi máme každý jiné představy o rozvoji software. Mně vyhovuje software, který přidává nové funkce a reaguje na měnící se svět. Mrtvému software, který se nijak nevyvíjí a postupně zastarává, se snažím vyhýbat.To není stav v jakém by se měl dávat balíček do distribuce která zmrazí verzi na další dva roky.
Zmražení verze je problém čistě té distribuce, nikoho jiného. Marně přemýšlím nad tím, co je tak báječného na tom, že distribuce zmražená před měsícem příští dva roky nebude podporovat TLS 1.3, distribuce zmražená před půlrokem by nikdy neměla dostat záplaty na Spectre a Meltdown (protože to rozhodně nejsou drobné opravy zjevných chyb, které nemohou nic rozbít). A taky přemýšlím, proč když je to zmražení na dva roky tak výborná věc, proč se toho sám Debian nedrží a porušuje to. -
Debian ma svoje dovody, preco nemeni cisla verzii v stable verzii (a podla mnohych su to VELMI dobre dovody).
Podle mne ty důvody, proč to tak dělat, jsou jen zbožná přání a ne důvody. Ta představa, že existují dva druhy úprav programů – jedno je přidávání nových funkcí a nebo oprava chyb, a druhé jsou opravy bezpečnostních chyb – je sice hezká, ale nemá vůbec nic společného s realitou. Často může bezpečnostní chybu opravit nějaká „běžná“ oprava, protože si nikdo ani neuvědomil, že daná chyba má dopad na bezpečnost. Často může bezpečnostní chybu opravit nová funkce nebo jen refaktoring – a opět to nemusí být záměr. A často oprava bezpečnostní chyby nespočívá v opravě jednoho řádku, ale musí se opravit logika fungování aplikace – protože ta bezpečnostní chyba není v kódu, ale v té logice. Dobrým příkladem jsou internetové protokoly – když něco přenášíte nešifrovaným protokolem FTP, není to žádná chyba v kódu programu, ale jediná možná oprava je taková, že prostě změníte logiku a použijete jiný protokol. Méně extrémní příklad jsou šifrovací protokoly – když jsou známy slabiny TLS 1.0 a TLS 1.1, nespravíte to žádnou úpravou kódu beze změny logiky, ale prostě musíte přejít na TLS 1.2.Navíc ty backporty záplat často dělá správce balíčku, který tomu kódu nemusí moc rozumět, čímž se ještě zvyšuje pravděpodobnost vzniku nějaké nové chyby. Takže ono se sice o tom systému říká, že jsou to stabilní a ověřené verze plus bezpečnostní patche. Jenže ve skutečnosti jsou to unikátní prakticky netestované verze, které používá jenom ta verze distribuce a nikdo jiný. Což je asi jediný skutečný přínos těchhle distribučních patchů – že u méně používaného softwaru pak tu unikátní verzi s unikátní chybou používá tak málo uživatelů, že se nikomu nevyplatí na to útočit. Ale to je security through obscurity.
Ak CZ.NIC uz aktualizacie pre danu verziu nevydava, tak by ste moc nemali argumentovat tym, ze v distribucii opravy nie su, pretoze v tom pripade maintainer akosi nema co updatovat.
Ale ony tam ty opravy skutečně nejsou zatímco v upstreamu jsou. To, že se bude držet staré verze, je rozhodnutí distribuce a ne upstreamu. A upřímně řečeno mne překvapuje, že si to upstream (obecně) stále nechává líbit, že distribuce pod jeho jménem vydávají jakési vlastní splácaniny. Jsou výjimky – pokud vím, Mozilla trvá na tom, že za Firefox může být označováno jen to, co vydají oni. Kdokoli může vzít zdrojáky a poskládat si z nich něco svého, ale pak už to nesmí nazývat Firefox.Pak se nedivte, že si autoři softwaru raději udržují vlastní repository, kde mají pořád nejnovější verze, když v oficiálním distribučním repository je sto let stará verze s bůhvíjakými záplatami. A pak se nedivte, že se tolik rozšiřuje použití Dockeru jen jako způsobu distribuce softwaru, nebo že má software vlastní instalátory a všechny závislosti si přitáhne sám.
Tahle politika distribučních patchů měla být opuštěna nejpozději v roce 2008 po známém debianím „vylepšení“ generátoru náhodných čísel v OpenSSL – nejpozději tenkrát mělo každému dojít, že ten chybný patch byl jen dílčí problém, ale chyba že je především v tom systému distribučních patchů. Distribuční patch by měl být nouzové řešení do vydání příští verze, ne něco, co se považuje za samozřejmost.
-
ja (neregistrovaný)
Nema celkom pravdu: projekty vydavaju nielen bleeding edge verzie, ale backportuju patche do starsich verzii. Napriklad aj spominana Mozilla ma ESR release (aktualne 52), kam backportuju vsetky fixy.
Distribucie si tiez nechcu vyrabat zbytocnu robotu, aj pre nich je fajn, ked ma projekt LTS verziu, a z prace na maintenance maju uzitok vsetci.
Neviem si predstavit, ze by som sa mal starat o system, ktory ma fungovat cca 10 rokov, s tym, ze autor kazdeho komponentu sa hocikedy moze rozhodnut urobit zmeny, ktore pre mna znamenaju rekonfiguraciu systemu. A nevyhne sa tomu ani Redhat, napriklad zavedenie gssproxy v 7.4 a ja mam z toho hlavybol, preco nefunguje SPNEGO v aplikaciach. Riesit take nieco po kazdom update, tak taky system vyhodim.
-
Nějakou formu LTS dělá opravdu jen relativně malé procento balíčků, třeba kernel, gcc, openssl, ...
Knot-resolver (téma tohoto článku) je produkčně použitelný jen velmi malé jednotky let a má trochu specifickou množinu uživatelů. Drtivá většina updatů nepotřebuje vůbec žádný zásah do konfigurace a náš NEWS obsahuje sekce pro takové nekompatibilní změny.
-
Projekty vydavaju – ne, jen velmi malé množství projektů to dělá. A i když to nějaký projekt dělá, je otázka, jak kvalitní ty backportované verze jsou. Ano, distribuce jsou za LTS verze rády, ale to ještě neznamená, že LTS verze jsou to, co se od nich čeká. Možná to tak mohlo fungovat dříve, i když osobně si myslím, že dříve akorát ty problémy nebyly tak viditelné.
Že vám bude 10 let fungovat systém jenom s backportováním bezpečnostních oprav je iluze. Která verze TLS bude podle vás za 10 let považována za bezpečnou? Které šifrovací a hashovací algoritmy? Pokud to nevíte, jak je chcete mít dnes implementované v systému, ve kterém pak jen budete opravovat chyby?
Nikdo netvrdí, že se má každá aplikace po každém updatu rozbít. Ale z vaší strany je to lež – nebo jste se snad setkal s nějakou distribucí, kde by každý update každého programu něco rozbil a znamenal rekonfiguraci systému?
Stejně tak je lež, že bezpečnostní záplata není update a nemůže nic rozbít. Je to update, něco rozbít může úplně stejně, jako jakýkoli jiný update, ale navíc je to update, který je mnohem méně vyzkoušený, než běžná nová verze programu. A to i když tu LTS verzi udržuje přímo upstream. Třeba tu Mozillu ESR určitě netestuje tolik lidí, kolik testuje aktuální verze.
Ta teorie o backportování pouze oprav, které nic nerozbijou, je sice hezká, ale nemá oporu v realitě. O čemž svědčí i to, že je obhajována tak zjevnými nesmysly, jako že každý update každé aplikace znamená rekonfiguraci systému, nebo že backport patche není update.
-
Uz davno neni Debian az tak striktni. Napriklad u Firefoxu se normalne instaluji aktualni verze (ktery ve stretchi z 52.2.0esr dosel k dnesni 52.7.3esr). I tam, kde je zadouci se drzet "zpet" ma uzivatel moznost pouzivat dnes jiz oficialni updates (pripadne backports) repozitare, kde se novejsi verze bezne objevuji.
Ve stretch-backports je aktualne verze 2.1.1 knot-resolveru, posledni je 2.2.0. Ale je pravda, ze situace kolem knot-resolveru je (z pohledu aktualizaci) veselejsi, nez treba kolem birdu nebo datovky, kde to balickovani drhne vic...
-
Mimochodem, když už jste zmínil datovku, i ta má nově k dispozici repozitář s polední verzí:
https://software.opensuse.org//download.html?project=home%3ACZ-NIC%3Adatovka-latest&package=datovkaV případě datovky je jedná o experiment a pokud bude OpenSUSE build service fungovat dobře, tak se z tohoto repozitáře snad stane ten oficiální, stejně jako tomu je u Knot Resolveru.
-
Palo M. (neregistrovaný)
FF je samozrejme znamy pripad (vo Wheezy dokonca prebehol update major verzie), ale je to skor vynimka potvrdzujuca pravidlo:
- stara sa on cely tim
- upgrady medzi ESR verziami ma osetrene uz Mozilla a FF samotny sa nerozbija (ked sa niekomu rozbije profil, vzdy moze vytvorit novy cisty, ktory sa na browsovanie da pouzit, teda samotny balik firefoxu rozbity nie je)
- keby nahodou aj uplne cely firefox prestal po update fungovat, nie je to az take tragickeNic z toho neplati pre knot-resolver. Je to skratka specificke pre FF. Take vynimky sa davaju naozaj len zriedka, takze by som tym v tomto pripade neargumentoval.
Ten backports znie lakavejsie, ale len v pripade, ze z oldstable prechadzas vzdy co najskor na nove stable (a oldoldstable nikdy nemas). Pretoze backporty pre oldoldstable updaty vacsinou tiez nedostavaju (vo wheezy-backports je stale jadro 3.16 vo verzii zranitelnej na Meltdown napriklad - tu opravu som si musel backportovat z jessie sam, ale ani s tym nebolo vela roboty).
-
Proc by to nemelo platit pro knot-resolver? Predpokladam, ze jeho vyvojari s kazdou verzi neprekopavaji celou konfiguraci tak, ze po upgrade to uz ani nenabehne... a i kdyz se nekdy deji "zasadnejsi" zmeny, spousta veci je osetritelna nejakym post-install scriptem (kde opet vyvojari nejlepe vedi, co kde zmenili - tudiz jsou ti nejpovolanejsi pro tvorbu takoveho migracniho scriptu).
Navic zrovna LTS pro wheezy konci v kvetnu 2018 - takze za mesic, s tim dnes uz vazne nema smysl moc ztracet cas (nehlede na to, ze zrovna ve wheezy/security je CVE-2017-5754 fixnute). Ale kdyz uz padla rec na Meltdown, tak tam tech problemu je podstatne vic, zeano - a dotykaji se i novejsich vydani Debianu - na nekterych platformach...
-
Palo M. (neregistrovaný)
Ked sa updatom rozbije FF (nepamatam si, ze by sa tak stalo), tak jednoducho vratim predoslu verziu. Alebo pouzijem iny browser.
Ked sa updatom znefunkcni DNS resolution (a pamatam sa, ze v Omnii sa tak pri kresd stalo), tak sa uz na masinu mozno ani nedostanem, mozno bude dost dlho trvat, kym vobec zistim ze je s tym problem, lebo kvoli nefunkcnemu DNS mi ani nepride mailova notifikacia napriklad - a teda predoslu verziu alebo iny resolver nenahodim az tak jednoducho. A nechodi mi plno inych veci, ktore DNS potrebuju k svojmu fungovaniu. To je dost diametralny rozdiel.Keby Debian stable (a oldstable a oldoldstable) dokazal v rozumnej miere otestovat, ze update lubovolneho balika na vyssiu verziu nesposobi ziadne problemy, tak by to iste tak robili, boli by aj v stable najnovsie verzie a vsetko by vsetkym fungovalo a vsetci by sme boli happy. Ale ked sa pozrieme, kolko to trva od freeze testingu do vydania noveho stable, tak je jasne ze to asi az tak jednoducho nepojde.
Ono to nie je nic tragicke, zaujmy upstream vyvojarov sa vo vacsine pripadov nekryju so zaujmami distribucii, takze distribucia si to zariadi ako vie/potrebuje. V pripade FF spravil Debian vynimku, pravidlom sa to nestalo.
Meltdown fix sa objavil zaciatkom januara. Ale nie pre wheezy-backports. Vo wheezy je jadro 3.2, to opravu dostalo. V jessie je jadro 3.16, to opravu dostalo tiez. Pre wheezy-backports (backportovane jadro 3.16 z jessie) oprava nebola, nie je, a uz ani nebude (a nebolo to tym, ze do konca zivotnosti zostavalo vtedy uz len necelych 5 mesiacov, kedze s este starsim jadrom 3.2 si tu pracu dali). Takze ti, co z nejakeho dovodu zostavali na wheezym a zaroven pouzivali backportovane jadro (napriklad kvoli podpore nejakeho HW im nestacio jadro 3.2 a potrebovali 3.16), tak ti opravu pre Meltdown z distribucie nedostali. Fakt viem o com hovorim, pretoze som si vtedy musel linux-image-3.16.0-0.bpo.5-amd64 vyrobit sam (nastastie z tej verzie co je v jessie to bolo trivialne, backportovaci virtual uz som mal spojazdneny kvoli inym balikom z minulosti).
O Meltdown samotny teraz nejde, tymto konkretnym prikladom som chcel len ukazat na to, ze pouzivanie backports ma tiez svoje uskalia. Ono sa tak trochu predpoklada, ze ten, co chce novsiu verziu a da si ju z backports, nebude zostavat na oldoldstable dokedy sa to len da, ale pravdepodobne sa posnazi upgradovat co najskor. Takze aj v pripade knot-resolveru, ak si nejaky entuziasta chce dat tu verziu 2.1.1 v stretch-backports, tak by si mal tiez planovat co najskorsi prechod na buster. Inak bude riskovat, ze mu v stretch-backports prestanu chodit bezpecnostne updaty, a to je uz potom naozaj lepsie zostat s nejakym "nemodernejsim" resolverom, ktory bezpecnostne updaty dostavat bude.
Skratka ked sa povie A (mozes si dat verziu z backports), treba zaroven povedat aj B (ale potom radsej upgraduj co najskor akonahle vyjde novy stable). Ked uz si tu takto radime na forach...
-
Nikdo vás přece nenutí updatovat. Nainstalujete si Debian a pak ho můžete provozovat několik let bez jediného updatu. Sice tam budete mít plno známých bezpečnostních děr, ale nebudete riskovat, že se updatem něco rozbije. Bezpečnostní update je také update a také u něj riskujete, že se něco rozbije. Naopak to riziko je ještě větší, protože novou verzi v upstreamu typicky dělá a testuje několik vývojářů, testerů a případně i betatesterů, navíc prochází automatizovaným testováním – naproti tomu distribuční patch bude připravovat správce balíčku v dané distribuci, který vnitřnímu fungování té aplikace a kódu nemusí moc rozumět, a testovat se to pak bude také mnohem méně.
Ta představa, že se vydá stabilní verze distribuce, a pak už se tam nic nemění, jenom se opravují chyby, je sice hezká, ale neodpovídá realitě. Protože každá oprava chyby je změna.
-
Keby Debian dokazal v rozumnej miere otestovat ...tady je zaklad chyby celeho pohledu. To musi otestovat maintaner balicku a fundovane rict, ze update problemy nezpusobi. A v tomhle pohledu se obloukem vracime k tomu, ze nejlepsim maintainerem by byl samotny tvurce daneho software. Je pochopitelne, ze velke projekty se distribucim prizpusobovat nebudou - ale ty mensi, zvlast chteji-li se vice prosadit holt nejsou v pozici, aby si jeste diktovali nejake podminky. To, ze vyvojari nejsou ochotni prevzit zodpovednost za svuj produkt je vec jina.
Jak uz jsem uvedl, diskutovat v dubnu o pet let starem wheezym - kteremu v kvetnu definitivne skonci podpora - je jen ztrata casu :) Navic LTS maji jiny druh podpory - nestara se o ne standardni security team, ale jina banda dobrovolniku. Uzivatel LTS verze jednoduse musi byt smireny s tim, ze tam budou nejaka omezeni. Ale to se vi od zacatku. V pripade kernelu se navic bavime o tom, ze nektere aktualni opravy vyzaduji novejsi verze prekladacu - neni to tak jednoduche.
A meltdown ukazal i jinou vec - ze rychly update komplexniho bezpecnostniho problemu muze nadelat vic skody nez uzitku. V lednu 2018 vsichni vesele instalovali nove mikrokody, aby se pak "slavne" vraceli zpet k tem z listopadu 2017 - ty lednove se stahly zpet….. a nove mikrokody Intel uvolnil az 12.brezna - a do te doby byli vsichni odkazani na vyrobce sveho HW, jina cesta nez BIOS update k novemu mikrokodu nevedla. A i na urovni samotneho kernelu se ty opravy stale doladuji. A na to nelze zapominat. Nejde o problem, ktery vyresi jedna zaplata.
-
Lol Phirae (neregistrovaný)
rychly update komplexniho bezpecnostniho problemu muze nadelat vic skody nez uzitku. V lednu 2018 vsichni vesele instalovali nove mikrokody, aby se pak "slavne" vraceli zpet k tem z listopadu 2017 - ty lednove se stahly zpet….. a nove mikrokody Intel uvolnil az 12.brezna
Neremcej, to ještě není nic proti odborníkům z Microsoftu, kterým se v rámci "opravy" povedlo meltdown zpřístupnit i úplným blbcům a urychlit o ~6 řádů... :-D
-
ze rychly update komplexniho bezpecnostniho problemu muze nadelat vic skody nez uzitku
To je snad všeobecně známá věc. Každý update může situaci zlepšit i zhoršit. Všichni se snaží, aby to bylo to první, ale někdy se to nepovede. A v tak komplexním prostředí se bohužel nedá dosáhnout toho, aby se to vždy kompletně ověřilo předem. Proto se v praxi řeší způsoby, jak updaty nasazovat postupně, ověřovat, že fungují, a v případě problémů je vracet zpět. Ve světě cloudových aplikací je tohle standardní postup, že se aktualizace nasadí jen menšímu množství uživatelů, monitoruje se a počet uživatelů se postupně zvětšuje. Na nižších úrovních (aplikace, operační systémy, mikrokódy procesorů) se ty cesty teprve hledají, protože na rozdíl od cloudu tam není jeden provozovatel, který by měl pod palcem všechno.
ČLÁNKY DO MAILU