Homebrew, správce balíčků nejen pro macOS, byl vydán ve verzi 6.0.0 (seznam změn). Hlavními novinkami jsou bezpečnostní mechanismus tap trust kvůli důvěryhodnosti závislostí, vylepšení sandboxingu na Linuxu, interní JSON API nebo zlepšení výkonu.
Byla nalezena a 9. června opravena kritická zranitelnost ve FreeBSD v Kernel TLS (KTLS). Pojmenována byla Bumsrakete (FreeBSD-SA-26:26.ktls, CVE-2026-45257). Lokální neprivilegovaný uživatel může přepisovat soubory, ke kterým má právo pouze pro čtení. Přepsáním setuid binárky a jejím spuštěním může získat roota. Na všech verzích od verze 13.0 vydané v dubnu 2021.
Vývojáři open source operačního systému ReactOS (Wikipedie), jehož cílem je kompletní binární kompatibilita s aplikacemi a ovladači pro Windows, se na síti 𝕏 pochlubili, že ReactOS zvládne počítačovou hru Half-Life.
Byla vydána nová verze 4.8 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Využíván je Free Pascal Compiler (FPC) 3.2.2.
Apple container dospěl do verze 1.0.0. Jedná se o open source nástroj pro spouštění linuxových kontejnerů na macOS postavený nad containerization. Napsaný je v programovacím jazyce Swift a optimalizovaný pro Apple silicon.
Bylo vydáno Eclipse IDE 2026-06 aneb Eclipse 4.40. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Asterinas (GitHub) je v Rustu napsané jádro operačního systému poskytující s jádrem Linux kompatibilní ABI. Vydána byla verze 0.18.0. První distribucí postavenou nad jádrem Asterinas je Asterinas NixOS. Nejedná se o oficiální projekt NixOS a nemá nic společného s NixOS Foundation.
Podrobně byla rozebrána kritická zranitelnost v nf_tables (CVE-2026-23111). Další lokální eskalace práv na Linuxu. V upstreamu byla zranitelnost již v únoru opravena. Ve zdrojovém kódu stačilo odstranit 1 vykřičník.
Evropská komise (EK) nařídila americké společnosti Meta, že musí znovu umožnit bezplatný přístup konkurenčním obecně zaměřeným asistentům umělé inteligence (AI) k WhatsAppu a tento přístup musí zachovat až do ukončení antimonopolního šetření. Opatření je dočasné a má zabránit vážnému a nevratnému poškození konkurence na rychle rostoucím trhu s obecnými AI asistenty. Meta uvedla, že se proti rozhodnutí odvolá.
Společnost Anthropic představila AI modely Claude Fable 5 a Claude Mythos 5. Claude Fable 5 je první model třídy Mythos určený pro běžné použití.
Různé drobnosti a užitečnosti na které narazím nebo sám vytvořím. Primárně se zaměřuji na věci, které mohou být zajímavé a užitečné pro ostatní uživatele GNU/Linuxu či typografického systému TeX, občas se tu ale určitě vyskytne i něco z úplně jiného soudku, např. z oblasti bezpečnosti apod.
Před chvílí jsem objevil zajímavé nové rozšíření pro Firefox – HTTPS Everywhere. Jedná se o iniciativu Tor Projektu a Electronic Frontier Foundation. Cílem tohoto rozšíření je řešit problém zabezpečeného přístupu k webům, které sice jsou přístupné přes zabezpečené připojení (HTTPS), ale občas je problém se na tomto spojení udržet. Může to být např. proto, že implicitně je poskytována jejich nezabezpečená varianta, na web se dostane přes odkaz (např. z vyhledávače) vedoucí na HTTP místo HTTPS URL, odkazy ve stránce vedou z HTTPS na HTTP, anebo o zabezpečené variantě webu ani nevíte (já např. dodnes netušil, že přes SSL se dá na Wikipedii přistupovat na adrese ve tvaru https://secure.wikimedia.org/wikipedia/en/wiki/Transport_Layer_Security).
Princip práce tohoto rozšíření je prostý – v XML souborech s velmi jednoduchou strukturou jsou definována pravidla (regulární výrazy) pro přepis adres. Např. sada pravidel pro Wikipedii v souboru Wikipedia.xml dodávaném s rozšířením vypadá takto:
<ruleset name="Wikipedia"> <exclusion pattern="^http://www\.wik(ipedia|inews|isource|ibooks|iquote|iversity)\.org/" /> <rule from="^http://([^@:/]+)\.wik(ipedia|inews|isource|ibooks|iquote|iversity|tionary)\.org/wiki/" to="https://secure.wikimedia.org/wik$2/$1/wiki/" /> <rule from="^http://([^@:/]+)\.wik(ipedia|inews|isource|ibooks|iquote|iversity|tionary)\.org/?$" to="https://secure.wikimedia.org/wik$2/$1/wiki/" /> </ruleset>
Z uvedeného ovšem vyplývá, že někdo musí pravidla pro všechny možné i nemožné weby vytvořit. A zatím jich v základní instalaci není moc, což se ale dá pochopit vzhledem k tomu, že rozšíření je momentálně dostupné ve verzi 0.1.1 – vývoj je tedy na samém počátku.
Nic vám samozřejmě nebrání vytvořit si pravidla vlastní. A doufám, že tak učiní co nejvíce uživatelů, a že své výtvory po odladění poskytnou EFF, aby se mohla sada s rozšířením distribuovaných pravidel co nejrychleji rozšiřovat.
Abych přispěl svou troškou do mlýna, taky jsou pravidla pro HTTPS přístup sem na AbcLinuxu:
-------8<-------------8<------ AbcLinuxu.xml -------8<-------------8<------- <ruleset name="AbcLinuxu"> <rule from="^http://(www\.)?abclinuxu\.cz" to="https://www.abclinuxu.cz"/> </ruleset> -------8<-------------8<-------------8<-------------8<-------------8<-------
Po instalaci doplňku stačí soubor AbcLinuxu.xml zkopírovat do adresáře HTTPSEverywhereUserRules/ v uživatelově profilu Firefoxu a restartovat prohlížeč.
Vývoj rozšíření je na začátku a určitě bude potřebovat vylepšení. Kromě rozšíření množiny pravidel by to možná chtělo nějakou indikaci pro uživatele, že byl (a odkud) rozšířením přesměrován (případně s možností rozšíření dočasně snadno vypnout – tlačítko na toolbar?). Při propašování zákeřných pravidel do výchozí instalace (což by nemuselo být nemožné, pokud bude přispěvatelů hodně) by toto rozšíření určitě mohlo být zneužito k nějakým nekalostem. Na druhou stranu, bez velké sady pokrytých webů v základní instalaci bude užitná hodnota rozšíření výrazně omezená.
Pravidla bude také potřeba důkladně ladit. Připravit pravidla pro složitější webové aplikace by nemuselo být vůbec jednoduché. Otázkou je, co se stane, když nějaká stránka náhle změní strukturu svých adres. Úprava pravidel bude vyžadovat nějaký čas, než si je následně uživatelé updatují také chvíli potrvá.
Nechám se překvapit, jak vývoj bude pokračovat. Myslím, že by to mohlo být užitečné rozšíření, příjemný doplněk např. k Certificate Patrol hlídajícímu změny SSL certifikátů (všechny změny, i ty, kdy je nový certifikát podepsaný „důvěryhodnou certifikační autoritou“ – ve všech prohlížečích je jich v základní instalaci fůra), SSL Blacklist hlídajícímu vadné serverové certifikáty vygenerované chybným OpenSSL z Debianu, BetterPrivacy pro kontrolu flashových cookies, anebo jen prostému obarvení adresního řádku Firefoxu.
Tiskni
Sdílej:
To bude nejspíš problém s mixem zašifrovaného a nezašifrovaného obsahu, ne? Např. reklamní bannery stahované do stránky přímo ze serverů reklamních společností se většinou netahají přes HTTPS, i když ke stránce samotné se přistupuje přes šifrovaný kanál. (BTW, ví někdo, jak se to bude chovat, když by nějaký obsah byl také stahovaný přes SSL, ale z jiného serveru s jiným certifikátem vydaným na jiného poskytovatele a podepsaným jinou („důvěryhodnou“) certifikační autoritou?)
Po kliknutí na ikonu zámku vpravo dole na status baru je v okně, které se objeví, důvod popsán. Já mám nastavené různé barvičky u adresního řádku, abych různé režimy snadno a rychle poznal.
Mixování zabezpečeného a nezabezpečeného obsahu je ale samozřejmě dost problém, protože v zobrazené stránce asi není možné rozumně rozlišit, co šifrované bylo a co ne.
Mixování zabezpečeného a nezabezpečeného obsahu je ale samozřejmě dost problém, protože v zobrazené stránce asi není možné rozumně rozlišit, co šifrované bylo a co ne.A taky tohle.
.
Teoreticky by to rozšíření mohlo chránit i proti útoku s přesměrováním na nehttps login formulář.
<ruleset name="AbcLinuxu">
<rule from="^http://(www.)?abclinuxu.cz" to="https://www.abclinuxu.cz"/>
</ruleset>
<ruleset name="Minimarket Beránek">
<rule from="^http://(www.)?minimarketberanek.cz" to="https://www.minimarketberanek.cz:444"/>
</ruleset>
<ruleset name="Kinderporno">
<rule from="^http://(www\.)?kinderporno\.cz" to="https://kinderporno.cz:1443"/>
</ruleset>
<ruleset name="Microsoft">
<rule from="^http://(www\.)?microsoft.com" to="https://www.microsoft.com"/>
</ruleset>
<ruleset name="Nika Chrastava, výrobna lahůdek">
<rule from="^http://(www.)?nikachrastava.cz" to="https://$1.nikachrastava.cz:444"/>
</ruleset>
<ruleset name="Seznam">
<rule from="^http://seznam.cz" to="https://seznam.cz"/>
<rule from="^http://www.seznam.cz" to="https://www.seznam.cz"/>
<rule from="^http://login.szn.cz" to="https://login.szn.cz"/>
<rule from="^http://email.seznam.cz" to="https://email.seznam.cz"/>
<!-- Novinky HTTPS zřejmě neumí -->
<!-- TODO: Rozšířit na další služby Seznamu. Nepoužívám je, takže nemůžu otestovat. -->
</ruleset>
<ruleset name="Česká spořitelna, internetbanking">
<rule from="^http://(www\.)?servis24.cz" to="https://www.servis24.cz"/>
</ruleset>
<ruleset name="Česká spořitelna">
<rule from="^http://(www\.)?csas.cz" to="https://www.csas.cz"/>
</ruleset>
<ruleset name="Datové sránky">
<rule from="^http://(www\.)?datoveschranky\.info" to="https://www.datoveschranky.info"/>
<rule from="^http://(www\.)?mojedatovaschranka.cz" to="https://www.mojedatovaschranka.cz"/>
</ruleset>
(testováno jen velmi zběžně)
Nj, ale jak chces resit (tvym zpusobem) preklad treba takovyho kinderporna?Tohle zrovna se vyřeší přechodem na IPv6
. Horší to bude s weby typu Wikipedie, které mají tu zabezpečenou URL ještě složitější.
Jenže tohle provést není tak jednoduché. Nakonec je to myslím zmíněno i někde na stránce toho rozšíření. Jak automatizované ověřovat, že HTTPS verze webu odpovídá tomu, co by uživatel obdržel přes HTTP? A proč se vlastně párat s načínám HTTPS, když na ten web nejdříve stejně přistoupíte pro kontrolu přes HTTP?