Webový prohlížeč Dillo (Wikipedie) byl vydán ve verzi 3.1.0. Po devíti letech od vydání předchozí verze 3.0.5. Doména dillo.org již nepatří vývojářům Dilla.
O víkendu probíhá v Bostonu, a také virtuálně, konference LibrePlanet 2024 organizovaná nadací Free Software Foundation (FSF).
Nová vývojová verze Wine 9.8 řeší mimo jiné chybu #3689 při instalaci Microsoft Office 97 nahlášenou v roce 2005.
Coppwr, tj. GUI nástroj pro nízkoúrovňové ovládání PipeWire, byl vydán v nové verzi 1.6.0. Zdrojové kódy jsou k dispozici na GitHubu. Instalovat lze také z Flathubu.
Byla vydána dubnová aktualizace aneb nová verze 1.89 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Vypíchnout lze, že v terminálu lze nově povolit vkládání kopírovaného textu stisknutím středního tlačítka myši. Ve verzi 1.89 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Proton, tj. fork Wine integrovaný v Steam Play a umožňující v Linuxu přímo ze Steamu hrát hry určené pouze pro Windows, byl vydán ve verzi 9.0-1 (𝕏). Přehled novinek se seznamem nově podporovaných her na GitHubu. Aktuální přehled her pro Windows běžících díky Protonu také na Linuxu na stránkách ProtonDB.
Byla vydána verze 1.78.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání na GitHubu. Vyzkoušet Rust lze například na stránce Rust by Example.
Služba Dropbox Sign (původně HelloSign) pro elektronické podepisování smluv byla hacknuta.
Byla vydána nová major verze 8.0 textového editoru GNU nano (Wikipedie). Podrobný přehled novinek a oprav v oznámení v diskusním listu info-nano nebo v souboru ChangeLog na Savannah. Volbou --modernbindings (-/) lze povolit "moderní" klávesové zkratky: ^C kopírování, ^V vložení, ^Z vrácení zpět, … Tato volba je aktivována také pokud binárka s nano nebo link na ni začíná písmenem "e".
Před 60 lety, 1. května 1964, byl představen programovací jazyk BASIC (Beginners' All-purpose Symbolic Instruction Code).
Od vydání stabilní verze 1.6 vyšly dvě vývojové verze. První je 1.7.0, která vyšla 2. srpna 2013 s těmito změnami:
Wine 1.7.1 vyšlo 30. srpna 2013 s těmito změnami:
Kvalitní podpora Direct3D je pro nemálo uživatelů Linuxu důležitá, protože vývojáři her z různých důvodů místo OpenGL, které funguje téměř všude, dávají stále přednost Direct3D (a později často portování na OpenGL musejí řešit dodatečně). Před skoro dvěma měsíci se objevil Direct3D 9 state tracker pro Gallium, který takto poskytuje Direct3D jako plnohodnotně podporované API, tedy bez emulace přes OpenGL a s vyšším výkonem. Vyžaduje jisté úpravy ve Wine a stav zatím zůstává nejistý, protože tyto úpravy zatím začleněny nebyly. Navíc se mohou z tohoto state trackeru radovat jen ti, kdo používají open source ovladače.
Stefan Dösinger mezitím pracoval na jiných vylepšeních výkonu Direct3D ve Wine, ze kterých se ale mohou radovat všichni, a protože se jedná o jednoho z významných vývojářů Wine, dá se očekávat, že se patch ve Wine brzy objeví:
V uplynulých měsících jsem pracoval na pracovním vlákně / vlákně pro proud povelů [command stream; CS] pro wined3d. Přesouvá většinu volání OpenGL do odděleného vlákna s cílem navýšit výkon (bug 11674) a opravit chyby, které je jinak těžké opravovat (24684).
Přiložené patche můžete otestovat jejich aplikováním (git am cesta/k/patchům/*) a nastavením HKCU/Software/Wine/Direct3D/CSMT = „enabled“. Ujistěte se, že jste zakázali StrictDrawOrdering. S těmito patchi už není potřeba a odstranilo by veškeré výkonnostní výhody. (Může se ale hodit při ladění.) Patche fungují s Wine 1.7.1.
Prosím, ozkoušejte tyto patche na svých hrách. Zajímá mě jakýkoliv úspěch nebo selhání a výkonnostní rozdíly. Uvítal bych čísla s výkonem s obyčejným Wine 1.7.1, tímto patchem s CSMT vypnutým a zapnutým a s Wine 1.7.1 + přílohou bugu #44420 a __GL_THREADED_OPTIMIZATIONS.
Poznámky pro ty, co nejsou vývojáři:
Poznámky k implementaci:
Stefan dále popisoval, jaké regrese lze očekávat v testech; konkrétně které je nutné vyřešit a které jsou spíš planý poplach. Na mailing listu zatím Stefanova zpráva nevyvolala žádný ohlas – proto stahujte Wine 1.7.1 a testujte!
Andrew Church se na mailing listu Wine dotazoval, jaký je správný postup pro hlášení bezpečnostních problémů. Dostalo se mu odpovědi, že žádný, ale že může napsat přímo nejvyššímu, tedy Alexandru Julliardovi. Andrew ale nakonec narazil na již známý problém:
[...] Ukázalo se, že je to známý problém (unixfs umožňuje plný přístup k systému souborů přes API Windows, i když není v dosdevices žádný odkaz, co by to umožňoval – nahlášeno jako #22450), takže jsem jen k bugu přidal komentář.
Unixfs, neboli přístup ke kořenovému adresáři v systému, se automaticky objevuje jako jednotka s písmenem Z. Odkazovaný bug spočívá v tom, že unixfs je sice možné zakázat odstraněním klíče z registru, při aktualizaci na novější verzi Wine se ale tento klíč obnoví a Z: se znovu objeví. Zásadní otázkou ale je, čeho chce člověk zakázáním unixfs vlastně dosáhnout. Marcus Meissner:
V závislosti na typu útoku, o který ti jde, nemusí zákaz unixfs stačit.
Pokud chceš spuštěnému malwaru zabránit v přístupu k unixovému filesystému, tak máš smůlu, protože malware by mohl dělat systémová volání na vlastní pěst (int 0x80 na x86, kupříkladu).
Tazatel si je ale toho, že Wine není sandbox, naštěstí dobře vědom:
Jo, toho si jsem vědom – pokud budu spouštět potenciálně zákeřný kód, tak to udělám ve VM . Jde mi spíš o situace, kdy jinak dobře vychovaný program pasivně hlásí vzdálenému serveru to, co vidí, třeba listuje adresáře přes rozhraní shellu – ideálně bych rád omezil to, co vidí, bez režie spojené s během celého VM.
Dále poznamenal, že zákaz unixfs není nikde dobře zdokumentován. Navrhl, aby součástí takové dokumentace bylo upozornění, že zákaz unixfs není nástroj pro obranu proti malwaru.
Nástroje: Tisk bez diskuse
Tiskni Sdílej:
Získal moje heslá na FaceBook, G+, do emailu, k účtu, fotografiám mojej milenky, ale nenainštaluje mi tam Tetris!
a ne někde pod / kam standardně směřuje jednotka ZNo ale přes
Z:\home\jenda
se dostaneš do ~, ne?
Dost často jim nezáleží na ničení dat uživatele, ale spíš pomaloučku, potichoučku monitorovat, odesílat, popř. se zapojovat do botnetů apod. A k tomu všemu stačí jen uživatelská práva ...Souhlasím, také si to myslím. Navíc to klidně může dělat i nativní aplikace - sám jsem používal mírně modifikovaného Linuxového trojana z knihy "Bezpečnost v Linuxu" pro testování některých nastavení - proto mě udivuje, že ho víc trápí relativně "neškodná" jednotka Z, místo toho aby se zaměřil na zabezpečení proti těmto věcem. Případnou podporu antivirů (zmohli by něco pod wine), nebo třeba propojení ClamAV s wine. Prostě používat aplikace z nedůvěryhodných zdrojů, stahovat a instalovat všechno co na mě kde vyskočí je VŽDY riskantní, bez ohledu na který os je to mířené. To platí pro i wine, nebo klidně i Dosbox ...
Navíc to klidně může dělat i nativní aplikace - sám jsem používal mírně modifikovaného Linuxového trojana z knihy "Bezpečnost v Linuxu"Samozřejmě, ale člověk by čekal, že Wine bude po odstranění Z: alespoň trochu sandboxovat… Že to jde obejít přes ruční systémová volání mě nenapadlo - jak se to vlastně dělá?
Případnou podporu antivirů (zmohli by něco pod wine)Antiviry nefungují a ani nemůžou fungovat, by-design.
Že to jde obejít přes ruční systémová volání mě nenapadlo - jak se to vlastně dělá?Hello world v assembleru
Dost často jim nezáleží na ničení dat uživatele, ale spíš pomaloučku, potichoučku monitorovat, odesílat, popř. se zapojovat do botnetů apodJenze s uzivatelskymi pravy jsou takove programy trivialne odhalitelne, zatimco s rootovskymi maji moznosti se takrka dokonale maskovat.
trivialneJak kdy. Třeba když ti to patchne extension ve Firefoxu a zabydlí se to v ní, tak se to bude hledat dost blbě. A i toho roota může získat brzo a snadno - aliasem na su/sudo.
v ohrožení je hlavně (a pravděpodobně pouze) domovský adresář daného uživateleJinými slovy to nejdůležitější, co na běžném osobním/jednouživatelském desktopu je.