pdf.js je ale samostatna komponenta, co je do browseru jen prilepena. A nic vam nebrani tu komponentu proste zakazat.
tak si tam zkus dát jinou verzi pdf.js, zjistíš, že vlastně či FF je open source, tak způsob jak připravit pdf.js, jak to otestovat už open source není.
Na cestě toolkit/components/pdfjs není snapshot z pdf.js repa, ale odvozený kód a prostě se do toho musíš ponořit, prozkoumat, porovnat a ručně upravit. Tohle určitě nejde označit jako samostatnou část, stříliš od boku aniž bys tuhle reálii znal.
Samostatnou komponentou je neco, co se z toho prohlizece da klidne i komplet vyhodit a nebude to k ujme, co se tyce zakladni fukncionality od prohlizece ocekavane. A tady je proste pdf.js doplnek, bez ktereho prohlizec fungovat bude. To, ze si to interne Mozilla v ramci Firefoxu priohne je zhruba tak stejne, jako vselimozne lokalni patche v distribucich - kdy pro zachovani nekterych funkci musite nejak pracovat i s tim distribucnim patchem - a nestaci vzit jen kod z upstreamu. A mimoto, tady to zas takova cerna magie neni.
pokud pdf.js smažeš z repositáře a spustíš build FF, selže ti, musíš upravit i build skripty, tohle jako samostatný doplněk opravdu není.
V těch distribucích mají aspoň všecho veřejně, změny mají v patch souborech. Update script je fajn, ale už v něm nejsou ty kroky navíc, které tam dělají. Ve FF se pdf.js používá tak trochu hardcoded, aktualizace není jen o stažení aktuální verze z repa, to je první krok. Před pár měsíci jsem tam potřeboval propašovat změny, aby se řádně zobrazovaly interní podepsaná pdf a sranda to není. Samostatný doplněk vypadá jinak.
Aky svincik?
Co je na tom zvlastne/nenormalne/nove a ako to kontrastuje s sshd?
To si mali napisat vlastny pdf prehliadac? Aj keby, tak by to nic neriesolo, lebo aj v tam moze byt chyba, ktora moze ostat nezaplatana. To riziko je tam vecsie ako pri siroko pouzivanych kniznic/komponent.
A da sa to vypnut.
Já to pochopil tak, že "integrovaný svinčík" je obecný povzdech nad ElectronJS aplikacemi potažmo i třeba hotovými kontejnery z nějakých veřejných repozitářů (Flathub, Dockerhub). A kde všude tahle knihovna zůstane ve zneužitelné verzi bez záplaty. Tyhle aplikační bundly pak dává do kontrastu s démonem sshd, který dělá víceméně "jednu věc" a ještě se má dál dělit kvůli lepší privilege separation.
Já tenhle sentiment úplně nesdílím, protože jak aplikační bundly, tak kontejnery jsou v určitých situacích fajn a zodpovědný správce podobné zranitelnosti musí řešit tak jako tak, ať už je původ software z distribuce, od vendora aplikace nebo nějakého veřejného repozitáře. Ale to už je jiná věc.
21. 5. 2024, 11:46 editováno autorem komentáře
Spravce nic resit nemuze, protoze nema jak. V 99% jsou presne takovyhle svinstva na tema "fungujte to s verzi 1.24.78.787.4.7778.7777 ... a zadnou jinou".
Ovsem v tomhle pripade je to specielni svinstvo, ktere jednak nema v browseru co pohledavat, druhak stejne nefunguje, a zatreti se jeste navic userum vnucuje jako default, takze je to jen a pouze dira.
Spravce nic resit nemuze, protoze nema jak.
Podle zprávičky, odkazovaného článku i CVE toho může udělat docela dost.
Pokud jde jen o Firefox, tak by měl mít na stanicích aktualizované verze 126, resp. ESRko 115.11. Vzhledem k tomu, je to zveřejněné asi dva týdny po opravě, tak by to mělo být ve všech distribucích, resp. aktualizačních kanálech na Windows a MacOS. Ve většině případu si myslím, že už se to stalo, aniž by to někdo řešil.
Pokud je ta JS knihovna používaná mimo Firefox v nějakých webových aplikacích, o které se stará (typicky CMS, self-hostované *Cloud servery s pluginy pro PDF prohlížení atp.), tak by si měl zkontrolovat, jestli má verzi komponenty PDF.js aspoň 4.2.67, nebo jestli se to používá s vypnutou volbou isEvalSupported.
https://github.com/mozilla/pdf.js/security/advisories/GHSA-wgrm-67xf-hhpq
Pokud používá a nasazuje hotové věci (aplikační bundly na bázi Electronu, hotové kontejnery), tak by si v základu měl zkontrolovat, jestli autor/dodavatel/vývojový tým ve firmě udělal nějakou aktualizaci v posledních dvou týdnech.
Případně si ještě prozkoumat changelogy, manifesty, yaml soubory s konfigurací dockeru, které bývají u mnoha projektů dostupné atp. Může si samozřejmě také dohledat soubory v docker image, flatpaku a případně sám zkusit použít to magické PDFko z článku.
Když nepochodí s opravou, tak by si měl nějak vyhodnotit riziko a např. dočasně vypnout konkrétní plugin, informovat uživatele atp.
V 99% jsou presne takovyhle svinstva na tema "fungujte to s verzi 1.24.78.787.4.7778.7777 ... a zadnou jinou".
Nevím, tady je jasně napsaná verze knihovny a FF, od které je to opravené - všechny předtím jsou postižené. Nebo můžete ve web aplikaci použít workaround, příp. backportovat opravu, jestli opravdu nutně chcete mít starší verzi PDF.js.
Když si půjčím vaší konstantu, myslím si naopak že pro 99% aplikací a autorů bude minimální problém konkrétní bundle, nebo kontejner aktualizovat tak aby z NPM použil nejnovější fixnutou verzi knihovny, aniž by jim to cokoliv dalšího rozbilo.
Ten zbytek s těmi svinstvy v porhlížeči je subjektivní pohled, který bude nejspíš trochu odlišný od většiny uživatelů webu, u kterých to vypadá, že naopak ocení, když nemusí každé PDFko stahovat na disk, aby si ho prohlédli - proto je to default. A samozřejmě vám konkrétně nic nebráni nastavit si, jak se váš prohlížeč bude chovat s "application/pdf" MIME typem, jestli máte jiné preference.
Jiste, uzivatel vzdy oceni nejvic, kdyz se mu treba prave to pdfko otevira v necem, co pdfka zobrazit neumi. Coz je presne to, co je v browserech.
Na widlich mam tuhle kravinu zakazanou GPOckem v chomakovi, GPOckem v ve foxovi (tam kde jeste jsou pozustatky, protoze sem ho vetsinou vsude zlikvidoval kvuli hromade dalsich krasnych vlastnosti, jako je napriklad nekonecny vytvareni kopii user profilu) ... ovsem chromej edge to s klidem ignoruje, a cas od casu zresetuje uzivatelum preference na sebe ze?
A samozrejme se to nijak nastavit neda.
A az mi budou vasnosti tvrdit, ze da, tak chci priklad zcela konkretne jak nastavim GPOckem asociaci souboru. Samozrejme tak, aby to nerozbilo nic dalsiho a fungovalo aspon 1/2 roku. Budu se tesit, a semnou dalsi miliony spravcu.
O tom, jak vypadaji dodavky SW zjevne neraceji tusit vubec nic. Dodavatel doda blob, a tak jak ho dodal se to i musi pouzivat. Aktualizace typicky znamena ze se to po 10 letech vsechno nainstaluje znova. Tedy pokud dodavatel jeste existuje.
Mam tu treba zalohovac, nikoli levny (licence v radu MKc) a je tam vyslovene zakaz aktualizovat system pod tim (v tomhle pripade nejaky centos).
Už výrazně odbíháme od PDF.js a Firefoxu, který je v celé věci z pohledu správce a řešení té bezpečnostní chyby ten nejmenší problém - stačí jej standardní cestou zaktualizovat.
Jiste, uzivatel vzdy oceni nejvic, kdyz se mu treba prave to pdfko otevira v necem, co pdfka zobrazit neumi. Coz je presne to, co je v browserech.
Jasně, vzhledem k tomu jak dlouho je to default, tak si klidně tipnu, že uživatelé browserů napříč si zobrazí klidně vyšší desítky milionů nejrůznějších PDFek denně, a to naprosto uspokojivým způsobem pro většinu použití. Ale váš závěr z toho je, že to obecně neumí zobrazovat PDFka :))
Beru, že má někdo osobně jinou preferenci. Stejně jako si dovedu představit, že ve firmě, kde většinově pracují s PDFky obsahující formuláře a skripty a nebo mají postavené document workflow na proprietární fíčurách od Adobe (schvalování, sdílené poznámky atp.), tak řeší deploy Adobe Readeru nebo plného Acrobatu.
Tam kde tahle speciální PDFka nejsou úplně dominantní, a věříte v inteligenci uživatelů, tak ten Reader bohatě stačí nainstalovat jako fallback. Tím mají zachované rychlé, progresivní načítání a zobrazování přímo z prohlížeče nebo mailu, což je většinou "good enough", a pokud už narazí na nějaký formulář, nebo mají třeba velký dokument, kde využijí lepšího vyhledávání, tak si to stáhnou na disk a otevřou v Readeru. Přesně tohle jsou zkušenosti mé zkušenosti jak z menších i větších firem (cca 2k stanic).
Stran té asociace souborů přes GPO, nejsem na rozdíl od kolegů specialista na AD (spíš Linux, MacOS atd.), ale když koukám na jeden server, co tam řeší v šabloně, tak je to v podstatě tohle..
https://techcommunity.microsoft.com/t5/ask-the-performance-team/how-to-configure-file-associations-for-it-pros/ba-p/1313151
Tzn. XMLko s definicí přiřazení na sdílené složce, plus ty volby v článku dole (vypnuté notifikace o nové aplikaci, vypnuté hledání aplikace pro otevření na internetu a ve store...).
Dovedu si představit, že kdybych z nějakého důvodu chtěl mít jistotu, že to použije vždycky ta systémová přiřazení, tak to ještě doplním nějakým powershellem, co rekurzivně projede existující uživatele v systému a odmázne pro konkrétní přípony klíč UserChoice v HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts
Což může být samozřejmě super invazivní, pokud si tam už něco sám nastavil.
Nicméně jak jsem předesílal, není to můj denní chleba. A konkrétně ten MS Edge vypadá, že je super agresivní v revertování nastavení, ignorování existujících politik a spousta věcí a jeho chování se mění mezi jeho různými buildy, aspoň co jsem slyšel. Takže jestli pak něco vydrží déle jak půl roku je otázka :)
O tom, jak vypadaji dodavky SW zjevne neraceji tusit vubec nic. Dodavatel doda blob, a tak jak ho dodal se to i musi pouzivat. Aktualizace typicky znamena ze se to po 10 letech vsechno nainstaluje znova. Tedy pokud dodavatel jeste existuje.
Ale samozřejmě že tuším.. proto jsem psal, že správce (resp. bezpečák) by měl zhodnotit riziko. Ať zůstaneme u tématu, asi bude rozdíl, jestli máte třeba starý Firefox a distribuci na serveru v nějakém izolovaném systému v segmentované síti s jasně danými přístupy a prostupy, nebo PDF.js v nějaké webové aplikaci/kontejneru, co přímo využívají třeba tísícovky uživatelů.
Nicméně rozhodně to není tak, že takovéhle peklo, co jste popsal, je vždycky. Chápu, že někdy řadový správce není nutně v nějakém rozhodovacím procesu, nemá nejspíš vliv na výši investic ani prostředků na rozvoj. Ale někdy ta potenciální frustrace může vést i k zásadnějším rozhodnutím, kdy si člověk vyhodnotí, že než zdegenderovat na takového toho strejdu Nejdeto, co akorát pi*uje v kantýně, a valí před sebou čím dál větší kuličku, tak u toho taky nemusí být a otevře se mu spousty dalších možností :)
Desne se to chova porad a typicky presne to, co lidi vazne potrebujou === vsemozny formulare, dotazniky a dalsi strasne dulezite chojoviny ... statni spravy, v tom nefungujou vubec.
Ale nejen to, v par poslednich mesicich sem nekolikrat resil, ze "to pdfko nejde vytisknout" a bylo to prave a vyhradne tim (v ruznych variantach, od toho ze to vubec neslo na tiskarnu poslat pres ze to tisklo prazdny papir po ze to tisklo cast objektu a dalsi cast ne).
Libovolnej svepravnej soft to samozrejme vytiskl bez problemu cele.
No jo, to bude konkurenční výhoda jak noha.
PDF je naprosto běžný formát na webu a když mi to nezobrazí aplikace rovnou (Firefox, Thunderbird), tak je to otrava. Stačí, když jdete na nějaký web, který nemá správně content-type nebo něco a PDF se po kliknutí uloží - pak to najít, otevřít, to je luxus.
Můžete si vybrat: na webu bude to, co prohlížeč umí, nebo prohlížeč bude umět to, co lidi na web dávají.
Můj první browser byl NCSA Mosaic, který uměl obrázky jen v BMP. Jsem rád, že prohlížeče poněkud pokročily a běžný obsah rovnou zobrazí, i když jen v náhledu.
Ale to je problem taky firefoxu a jeho systemu prace se stazenymi soubory (ktery mi nikdy nevyhovoval). Treba vivaldi nabizi dialog stahnout ci otevrit vzdy, nezavisle na tom co webova stranka tvrdi, a operacni system vidi ze samotny soubor zacina %PDF a otevre to prirazenym programem.
No a vzhledem k tomu, ze integrovany webovy prohlizec pdf je strasne nekomfortni, tak si kazde pdf otviram okularem z KDE.
Na co všechno by se prohlížeč měl ptát? Není jednodušší nastavit jako výchozí volbu všem to, co lidé používají nejčastěji, a ten, kdo to chce jinak, si to změní?
Mimochodem, v době, kdy PDF.js vznikal, byl „klasický přístup k otvírání PDF“ otevřít to v Adobe Readeru, což se zdaleka ne vždy podařilo (proto vznikl PDF.js), ale hlavně těch chyb v tehdejším Adobe Readeru byla spousta a podstatně závažnějších, než je teď v PDF.js.
To, že se začaly používat ve webových prohlížečích vestavěné prohlížeče PDF dokumentů, znamenalo, že se PDF stala na webu normálně použitelná bez zdlouhavého vývoje.
Jistě dokážete dát odkaz na nějaké PDF, které Adobe Reader zobrazí a PDF.js ne.
Jinak když se to PDF jenom stáhne (což je typicky případ, když prohlížeč nemá vestavěný PDF prohlížeč) a uživatel neví, kam se mu soubory stahují (což není zas tak ojedinělé), zobrazí se takovému uživateli v Adobe Readeru přesně 0 % PDF. Pro takového uživatele je samozřejmě vestavěný PDF prohlížeč podstatně lepší, protože mu zobrazí drtivou většinu PDF.
Hele, ano, souhlasím s tebou. Jsou PDF, která se nedají zobrazit jinde, než v acroreadu. Ale jsou tu dva body, které potřebuji zmínit:
1) já osobně jsem se s takovým PDF už velmi dlouho nesetkal. Je to ale moje zkušenost a nerozporuji zkušenost ostatních, hlavně co se týče komunikace se státní správou. Jsou to sice ta nejdůležitější PDFka, ale je jich naprosté minimum v celkovém objemu.
2) Adobe prosadilo spoustu rozšíření PDF formátu, která ale nejsou otevřená. Navíc je to funkcionalita z „vyšší dívčí“, takže se s ní člověk v běžných PDF nesetká (výjimka viz bod 1).
Osobně používám na většinu PDF Okular, jsem s ním spokojený více než dost s jedinou malou výjimkou - editování formulářů a diakritika. V tom případě PDF otevřu ve vestavěném prohlížeči PDF ve Firefoxu a mám vyřešeno.
Takže se vyhrazuji proti tvrzení, že 90% PDF se jinde než v acroreadu nezobrazí správně. Tento dojem může vzniknout jen u člověka, který většinou neustále otevírá těch pár rozbitých PDF od pos*nych úřadů.
Navrhuju, abyste přestal psát nesmysly. Když někdo píše, že se něco děje v 90 % případů, a já se ptám na konkrétní příklady (k čemuž stačí poslat odkazy na poslední 3 ze 4 posledních PDF, které jste na internetu potkal), nedává smysl na to odpovídat tak, že nepošlete žádný odkaz, ale napíšete, že to není žádná výjimka.
Já jsem nedávno potkal PDFka na insolvenčním rejstříku (náhodně vybraný "Jan Novák"), ty "Vedlejší dokumenty" mi nefungují a v patičce je napsáno "Upozorňujeme uživatele, že vedlejší dokumenty (PDF portfolia) již nelze otevřít v internetovém prohlížeči MS Edge, Google Chrome aj.. ".
Jestli to chápu správně, je to "PDF portfolio", což je nějaký způsob jak použít PDF jako kontejner na soubory. Linuxový Okular mi z toho vybalí PDFka a ta pak jdou normálně otevřít. Ale nevím jestli tam jsou i nějaké další věci, které jdou jen v Adobe.
24. 5. 2024, 18:51 editováno autorem komentáře
Taková PDF fakt jsou, na úřadě např. od ECO COM hlášení, nebo IZF žádosti, ale chápu to tak, že jsou to formulářová PDF. Onj e ani nezobrazí viewer W10 v exploreru. Prostě pak Adobe. Ale často bojujeme i s pouhým tiskem, kdy jedině Adobe dá možnost tisku, jak to chceme, např. FF nedávno nechtěl ukazovat duplex tisk a měřítko (pro BFU, expert umí). Ale chápu, že use case (zobrazení už v prohlížeči) jde správným směrem, jen jsem chtěl říci, že některé oblasti spíš BFU zmatou.
U těch formulářů je to ale vlastnost, kterou jen Adobe špatně (nebo možná naopak dobře, záleží na úhlu pohledu) prodává. Ty formuláře jsou totiž dělané tak, že je to proprietární technologie Adobe, k jejímuž využití potřebujete „velký“ Adobe Acrobat. Ale Adobe umožňuje poskytnout licenci ostatním k vyplňování – a aby k tomu nepotřebovali speciální program, je ta funkcionalita vyplňování náhodou vestavěná do Adobe Readeru.
Že některé funkcionality uživatele zmatou chápu. Nicméně dřívější stav byl takový, že uživatel často PDF vůbec neodkázal otevřít, a když už ho dokázal otevřít, nedokázal ho vytisknout. Stav, kdy někdy nejde vytisknout tak, jak bych chtěl, je výrazný posun vpřed.
(Já jsem to kdysi implementoval tak, že se v prohlížeči odchytila a zrušila událost tisku, a místo ní se zavolal skript v PDF, který vyvolal tiskový dialog pro PDF soubor. Vývojáři PDF.js se pak po letech divili, že je něco takového s PDF možné…)