Názory k článku
Rocky Linux a AlmaLinux reagují na omezení přístupu ke zdrojovým kódům RHEL

Jak už jsem psal včera pod jinou zprávičku, nevím. Včera poslala vysvětlení (z toho techničtějšího pohledu) do mailing listu Fedory Alexandra Fedorova.

"Vysvětlení" pobavilo. Jdu si zas pustit to video o sedmi navzájem kolmých červených přímkách nakreslených zeleným a průhledným inkoustem.

Zdrojaky musi spristupnit, neni receno jak.
Kdyz budou zdrojaky posilat postou na 200 disketach, tak splni literu zakona. Mozna by slo to i vytisknout a poslat v baliku. Cena nula-nula-nic a realne to zabrani distribuci.

Mýlíte se, je řečeno jak a váš postup by licenci v dnešní době nevyhověl.

Nejsem právník, ale kdysi jsem na nějakém fóru narazil diskuzi o GPL. Když si stáhnu pod GPL nějaký zdrojový kód a upravím ho pro svoji potřebu, tak musím ty úpravy zveřejnit? Užívám ho jen já a nikdo jiný. Je asi jedno, jestli je to jednotlivec, nebo firma. Takže asi zveřejnit nemusím. O aplikaci je zájem a já se rozhodnu to distribuovat pomocí podpory toho softu. Zákazník neplatí za ten software, ale za službu. Kdo bude platit službu, tak dostane zdrojový kód. Ostatní to přeci nepoužívají a já jsem splnil GPL licenci pro své zákazníky. Jestli někdo ze zákazníků bude distribuavat tento software dál, vypovím mu službu a má po aktualizacích. Zůstane mu aktualní soft. Já zatím udělám pár update, ale to je přeci vývojová verze a já nemůžu riskovat, že někdo dojde k nějaké ztrátě a zažaluje mě. Nehledě na to, jestli to musím zveřejnit hned, za den, za měsíc, nebo půl roku. Za půl roku, nebo rok zveřejním zdrojový kód mého softu, ale můj soft už je jinde. Vlk se nažral a koza zůstala celá. Z mé hlavy to není, ale jak jsem psal výše, někde jsem to četl v diskuzi.

Když si stáhnu pod GPL nějaký zdrojový kód a upravím ho pro svoji potřebu, tak musím ty úpravy zveřejnit? Užívám ho jen já a nikdo jiný.

Ne, nemusíte, to je jen takový hojně rozšířený omyl. Zjednodušeně řečeno je to tak, že tomu, komu dáte k dispozici binárky, musíte dát k dispozici i odpovídající zdrojáky. Dokonce ani to ne proaktivně, ale jen pokud si je vyžádá. V praxi je samozřejmě nejrozumnější, pokud jde o klasické zveřejnění, zveřejnit rovnou i zdrojáky, pokud možno na stejném místě. Ale pokud upravený software používáte jen vy sám, nemusíte zdroják dávat vůbec nikomu.

Podobně pokud je to úprava na zakázku pro jednoho konkrétního zákazníka, má právo na zdrojáky jen ten jeden konkrétní zákazník, který to od vás dostal, nikdo jiný. Jestli se pak rozhodne je šířit dál, je už čistě na jeho uvážení. Opět ale platí, že komu poskytne binárky, ten má právo po něm požadovat i zdrojáky. (Zdůrazňuji "po něm", tedy ne po vás, po vás má právo je chtít jen ten, kdo má od vás binárky.)

Zákazník neplatí za ten software, ale za službu. Kdo bude platit službu, tak dostane zdrojový kód.
Když software budete provozovat přes síť, tj. zákazník žádné binárky nedostane, nemusíte mu zpřístupňovat ani zdrojové kódy (bavíme se o GNU GPL).

Jestli někdo ze zákazníků bude distribuavat tento software dál, vypovím mu službu a má po aktualizacích.
V případě, že jste to poskytoval jako službu (ne jako software), tj. zákazníkům jste zdrojáky poskytoval dobrovolně, udělat to můžete. Ale nemá to nic společného s GPL. Pokud byste ale zákazníkům poskytoval binárky, povinnost zpřístupnit jim zdrojáky máte z GPL, a tato povinnost nesmí být ničím dalším omezována. Tedy ani tím, že přestanete poskytovat podporu.

Nehledě na to, jestli to musím zveřejnit hned, za den, za měsíc, nebo půl roku.
Když poskytujete software jako službu, GPL vás nenutí dávat k tomu i zdrojáky. Když poskytujete přímo software (binárku), musíte umožnit získat zdrojáky hned, když distribuujete tu binárku.

Treba s tim, ze oprava kriticke chyby se do centos stream dostane treba xx dnu po oprave v RHEL? Stejny repozitar, jine casove okno. Ja samozrejme rozumim tomu proc to RH dela.

Oprava v RHEL se uskuteční v době informačního embarga na zranitelnost. Lze to jen díky tomu, že členové RHEL týmu jsou placení za práci na bezpečnostních incidentech a věnují se jim komerčně (tj. nikoliv jen v době, kdy mají čas a náladu). Pokud za RHEL zaplatíte, přispějete jim na plat a samozřejmě máte nárok na výsledky jejich práce.

Pokud neplatíte, máte nárok až po zveřejnění zranitelnosti. Ale jako bonus máte k dispozici hotovou záplatu, což je více než královský benefit.

Pokud s tímto systémem nesouhlasíte, pak byste asi byl radši, kdyby nejprve byla veřejně publikována zranitelnost (bez podrobného zkoumání a přípravy nápravy), aby měli útočníci možnost útočit na kohokoliv bez adekvátní ochrany. Mně by se to nelíbilo, protože v případě že mi o bezpečnost tolik jde, pak jsem ochoten si připlatit. Chápete?

Měl jsem dojem, že takovéhole základní logické principy chápe každý. Ale asi jsem se mýlil... škoda. Ale rád vám to vysvětlím.

> Pokud neplatíte, máte nárok až po zveřejnění zranitelnosti.
Možná tady je ten "zakopany pes".
Opravdu budou opravy a úpravy dostupné ?
PS: Rozhodně nijak nerozporuji "až po zveřejnění zranitelnosti" - i když je to myslím nepřesné - přesněji by to mělo být "po vydání balíčku s opravou"

24. 6. 2023, 08:46 editováno autorem komentáře

Jaké kritické chyby máte na mysli? Proces aktualizací v RHELu je takový, že první se dělá build ve Streamu a až potom pro RHEL. Jen u bezpečnostních oprav to je naopak. Protože tam může být s ostatními aktéry smluvený termín zveřejnění třeba za několik dní, aby to všichni stihli opravit, a během té doby to nesmí nikdo propálit, což by se posláním buildu do veřejného repozitáře Streamu přesně stalo. Ale ta oprava během embarga nejde ani zákazníkům, protože tím by se to taky propálilo. Leží v embargu na serverech Red Hatu, dokud nepřijde čas, kdy bylo dohodnuté, že to může jít ven. V tu dobu už míří oprava i do Streamu. Tady opravdu zásadní výhoda RHELu oproti Streamu není.

Tak to fakt neviem o com hovoris, ale mam CentOS Stream 8 aj AlmaLinux 8. Alma ma bezpecnostne aktualizacie napr. na httpd a php uz davno, CentOS Stream stale nie. Neide tu o nejakych trapnych 14 dni, ale dlhodobo. Vid. posledne aktualizacie:

almalinux-release-8.8-1.el8.x86_64
httpd-2.4.37-56.module_el8­.8.0+3560+c8e5­e57e.6.x86_64
php-7.4.33-1.module_el8.8­.0+3477+f828cbb0­.x86_64

centos-stream-release-8.6-1.el8.noarch
httpd-2.4.37-54.module_el8­.8.0+1256+e159­8b50.x86_64
php-7.4.30-1.module_el8.7­.0+1190+d11b935a­.x86_64

Ked pozriem changelog pre httpd, tak httpd-2.4.37-56 bol releasnuty niekedy v januari, riesil 3 CVE, neskor sa riesili dalsie 2. Takze update meska 5 mesiacov!!!

Tym padom teda vobec nie je pravda, ze tie aktualizacie idu do CentOS stream.

Povodne som myslel, ze mi centos-stream vobec nevadi, ze vsetky servery upgradnem z centos na centos stream. Sice je tam nevyhoda, ze stream ma pomerne kratku podporu oproti RHEL alebo klonom, ale to by mi ties nevadilo. Ale to, ze uz som tam odvtedy postrehol asi 3 problemy funkcnosti a hlavne ze pre neho nevychadzaju aktualizacie, tak to je fakt onicom.

Tak to budto maju v buildsysteme centos-streamu nejaky problem, alebo to robia zamerne. Ale naco mi je "upstream" distribucia centos-stream, ked niekolko mesiacov vobec neriesia bezpecnostne aktualizacie?

Nepozeral som na ostatne balicky, ale minimalne tieto 2 maju dost vazny bezpecnostny problem, ktore nik neriesi.

Neviem, naco sa Red Hat alebo IBM hraju, ale takto znicia celkom solidnu distribuciu a ked to teda takto pojde dalej a ukonci sa AlmaLinux, tak Red Hat predpokladam, ze kopec prispievatelov do Fedory prejde na inu distribuciu a teda stratia prispevky komunity, to bude podla mna ich zaciatok konca.

Napríklad https://nobaraproject.org/download-nobara/

Treba to redhat backportoval. Napis CVE, docela me zajiam o co jde a jak to je

Tak to asi tazko to mohol niekto backportovat, pretoze posledna hlaska v changelog toho httpd z centos-stream je:

* Št dec 08 2022 Luboš Uhliarik <luhliari@red­hat.com> - 2.4.37-54
- Resolves: #2095650 - Dependency from mod_http2 on httpd broken

Hlasky z almalinux:

* Št apr 27 2023 Luboš Uhliarik <luhliari@red­hat.com> - 2.4.37-56.6
- Resolves: #2190133 - mod_rewrite regression with CVE-2023-25690

* So mar 18 2023 Luboš Uhliarik <luhliari@red­hat.com> - 2.4.37-56.4
- Resolves: #2177748 - CVE-2023-25690 httpd:2.4/httpd: HTTP request splitting
with mod_rewrite and mod_proxy

* Ut jan 31 2023 Luboš Uhliarik <luhliari@red­hat.com> - 2.4.37-56
- Resolves: #2162499 - CVE-2006-20001 httpd: mod_dav: out-of-bounds read/write
of zero byte
- Resolves: #2162485 - CVE-2022-37436 httpd: mod_proxy: HTTP response splitting
- Resolves: #2162509 - CVE-2022-36760 httpd: mod_proxy_ajp: Possible request
smuggling

* Št jan 26 2023 Luboš Uhliarik <luhliari@red­hat.com> - 2.4.37-55
- Resolves: #2155961 - prevent sscg creating /dhparams.pem

* Št dec 08 2022 Luboš Uhliarik <luhliari@red­hat.com> - 2.4.37-54

Kedze posledny build je z minuleho roka, tak asi tazko mohol niekto backportovat tohorocne CVE.

Vid. aj buildy httpd pre centos-stream:

https://koji.mbox.centos.org/koji/packageinfo?packageID=583

Ziaden build httpd od februara.

Podobne som minule nahanal buildy pre php, kde boli dost kriticke veci opravovane. Tak na ziadost cez bugzillu to minule skompilovali, ale zas preco to ja mam ziadat take veci? Ked uz to mam takto riesit, urobim si tie aktualizacie rovno sam.

Ako keby v Red Hate nevedeli, co robi jeden team a co druhy. Podobne je to s btrfs, ktory bol v centos 7 ako preview, vo fedore medzitym presiel do stavu vychodzieho fileystemu, ale v centos 8 ho opacne uplne odstranili. Ako keby Red Hat mal 3 uplne nezavisle teamy, RHEL, CentOS stream a Fedora, pricom ani jeden z nich nevie co robi ten druhy. A potom vraj je upstream Fedora -> CentOS Stream -> RHEL.

Na to httpd a php vám konkrétní odpověď dát nemůžu, já jsem z desktop týmu a nesleduju každou jednotlivou komponentu v RHELu. Nicméně není to systémová věc. Máme guidelines, podle kterých se normální aktualizace dělají do Streamu ještě před RHELem a bezpečnostní po jejich zveřejnění. Jestli na to nějaký vývojář kašle, je potřeba ho urgovat. Případně je možné na rozdíl od starého CentOSu tu opravu přímo navrhnout. Platící zákazník nám může před očima zamávat SLA. U komunitního distra je holt potřeba tlak komunity.

Jinak k tomu btrfs: náš storage tým došel k závěru, že na btrfs do budoucna sázet nebudeme. Na základě toho byl z RHELu odstraněný. Ve Fedoře si ho ale prosadila komunita. Red Hat má na Fedoru podstatný vliv, ale rozhodně neplatí, že Fedora rovná se Red Hat a že vše, co se ve Fedoře dělá, je 100% ve shodně s tím, co dělá a chce Red Hat. Ve Fedoře jsou stovky nezávislých dobrovolníků, plus do ní přispívají další významné firmy (Facebook - ten právě přechod na btrfs po technické stránce nejvíc táhnul, Amazon). Momentálně mají Fedora a Red Hat na výchozí souborový systém rozdílné názory a já v tom popravdě nevidím problém.

Pred vyse rokom som to riesil tiez. Az na moj podnet sa to skompilovalo:

https://bugzilla.redhat.com/show_bug.cgi?id=2042795

Ono vyhovorka, ze je to problem vyvojara sa da akceptovat pre EPEL, ale pre base komponenty, kde teda komunita nema pristup je to podla mna nespravne. Ak sa o tie balicky stara firma, tak ma aj dohliadnut na ich bezpecnost. Podla https://wiki.centos.org/About/Product ma CentOS Stream podporu, takze niekto by sa o aktualizacie mal starat. Podobny problem je s CentOS 7, kde je bezne napisane "Out of support scope" v errata, co teda tiez nechapem, ak je OS podporovany, tak preco sa tam na bezpecnostnu aktualizaciu kasle. Tieto problemy som si vsimol len odkedy IBM kupil Red Hat. Predtym podobne problemy neboli, aktualizacie CentOS sice par dni meskali, ale prisli. Urcite to neboli mesiace.

Podla toho, ze to reportujem len ja ten CentOS Stream asi ani nikto iny nepouziva pre realne nasadenie. Mozno tak na nejake testovanie.

A co sa btrfs tyka, tak OK, ako default to byt nemusi, ale aspon ten balicek hned nemuseli odstranit z distribucie a ponechat pouzivatelov, aby ho pouzili podla svojho uvazenia. A predtym bol len v technology preview, co kludne aj mohlo zostat.

A není to jen tím, že to hledáte ve staré instanci CentOS Koji? Protože když se podívám na kojihub.stream­.centos.org, tak tam mám nejnovější aktualizaci httpd z 13.6. Naopak když se podívám na koji.mbox.cen­tos.org, kde jste to hledal vy, úplně poslední buildy čehokoliv jsou tam z února.

Toto je uz trocha lepsie, posledny build je z 13 juna, ten ale este nepresiel do aktualizacii, pretoze pri kompletnom "yum update" mam stale staru verziu. Existuje nejaky testing repozitar, odkial sa to da nahodit?

Predosly build je httpd-2.4.37-54.module_el8+297+7­254e91c, z marca, ktoremu chyba kopec rieseni pre rozne CVE.

Pridal som aj 2 issue na tieto veci:

https://bugzilla.redhat.com/show_bug.cgi?id=2217408
https://bugzilla.redhat.com/show_bug.cgi?id=2217409

CentOS Stream žádný updates testing repozitář nemá. Testování probíhá čistě interně. Ač někteří označují Stream za betu RHELu, ve skutečnosti musí každý Stream build projít kompletním RHEL testováním. Až pak se dostane do stabilních aktualizací. To může nějaký čas trvat. Do té doby je asi jediná možnost stáhnout konkrétní balíčky z Koji a nainstalovat je ručně.

Jinak říkal jsem o tom člověku, který má tým, který pracuje na httpd a php, na starosti. A říkal, že prověří, jestli jim tam nějaké bezpečnostní opravy nevisí.

Ještě k těm bezpečnostním updatům, hodně výstižný/popisný komentář na dané téma napsal (na už výše sdíleném vlákně) Michael Catanzaro.

Ohledně toho updatu pro CentOS Stream 8, asi bych jen opakoval, co tu už psal Jirka. Letmo jsem se podíval na CentOS Stream 9, který mi tu běží, a ten aktuální fixy má:

* Pá dub 14 2023 Luboš Uhliarik <luhliari@redhat.com> - 2.4.57-2
- Resolves: #2186645 - Fix issue found by covscan in httpd package
- Resolves: #2173295 - Include Apache httpd module mod_authnz_fcgi

* Út dub 11 2023 Luboš Uhliarik <luhliari@redhat.com> - 2.4.57-1
- Resolves: #2184403 - rebase httpd to 2.4.57
- Resolves: #2177753 - CVE-2023-25690 httpd: HTTP request splitting with
  mod_rewrite and mod_proxy

* Po led 30 2023 Luboš Uhliarik <luhliari@redhat.com> - 2.4.53-11
- Resolves: #2162500 - CVE-2006-20001 httpd: mod_dav: out-of-bounds read/write
  of zero byte
- Resolves: #2162486 - CVE-2022-37436 httpd: mod_proxy: HTTP response splitting
- Resolves: #2162510 - CVE-2022-36760 httpd: mod_proxy_ajp: Possible request
  smuggling

* Út led 24 2023 Luboš Uhliarik <luhliari@redhat.com> - 2.4.53-10
- Resolves: #2160667 - prevent sscg creating /dhparams.pem

* Čt pro 08 2022 Luboš Uhliarik <luhliari@redhat.com> - 2.4.53-9
- Resolves: #2143176 - Dependency from mod_http2 on httpd broken

Tím ani v nejmenším nechci nějak snižovat, co tu předtím padlo. Jde mi jen o to, že není žádná cílená potika ty fixy zadržovat a věřím, že i u toho CS8 se to rychle vyjasní.

Btrfs v RHEL 7 bylo jen Technology preview.

Upstream - downstream vztah přece neznamená, že všechno co je ve Fedoře bude i v RHELu (jako třeba právě btrfs).

Právě proto, že se to v RHELu musí komerčně podporovat a některé garance jsou pro tu technologii v danou chvíli nemožné (nebo moc drahé). Riskovat ztrátu dat u zákazníka nemůžete.

Ano, bol v technology preview, ale vykopli ho v strede letu. Keby ho nedali do dalsieho major release, pochopim, aj tak sa neda upgradovat z major na major, treba novu instalaciu a tam sa filesystem vyriesi. Ale pri minor update? Niekto spusti yum update a uz nenabootuje?

To preco myslis, ze sa major neda upgradovat? Ja som upgradoval servery z CentOS 6, postupne mi funguje update az na CentOS Stream 9. Co som porovnaval upgradnuty a reinstalovany system, tak je to skoro to iste. Ano, navyse mi tam ostane par konfiguracii, ktore mozem a nemusim dalej upravit. Ostane par balickov, ktore budu navyse, pretoze starsi centos mal nejake poziadavky navyse a neskor sa zmenilo. Ale inak funguje upgrade dobre. Akurat len CentOS tim s tym nic nechcel mat, nechcu to podporovat.

Protože taková jsou pravidla pro embargo u CVE. Kdyby to tak RH nedělal, tak ztratí sám přístup k informacím o nově objevených chybách.