Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
Databáze DuckDB (Wikipedie) byla vydána ve verzi 2.0.0 LTS. S kódovým názvem Cinnamon Teal (čírka skořicová). S vyladěným protokolem Quack.
V implementaci Broadcom 802.11 byla zjištěna chyba ve zpracování WPS/EAP, týká se to SDK od roku 2010. Broadcom podle výzkumníka Quentina Kaisera odmítl CVE přidělit. Modemy Huawei a Technicolor jsou používány i v ČR, v LTE routerech, běžných domácích routerech a firemních přístupových bodech, jejich současný počet a zranitelnost konkrétních verzí však zatím neznáme. Více detailů a demo. GitHub / Broadcom 802.11 SDK Detection Toolkit.
Byla vydána nová verze 10.8 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Přibyl balíček DietPi WireGuard.
Oslavte vydání openSUSE Leap 16.1 s námi v Praze! Ve středu 4. listopadu 2026 (den po vydání Leapu 16.1) vás zveme na malou oslavu vydání openSUSE Leap 16.1 do pražské kanceláře SUSE. Připravili jsme pro vás dvě krátké přednášky: … více »
Dle plánu bylo PHP vydáno v nových verzích 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Opraveny jsou kritické zranitelnosti CVE-2026-109618 a CVE-2026-109619 aneb PHP2Shell.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch 24.04-2.1 a 24.04-1.5. S opravou kritických zranitelností.
První přihlášení Na naše weby se pomocí mojeID nebo OpenID přihlašujete poprvé. Při té příležitosti potřebujeme, abyste si tady založili místní účet, nebo své přihlášení propojili s již existujícím účtem. Je to jednoduché.Fajn, je naprosto pochopitelné, že chtějí registrovat místní účet a případně doplnit nějaké další údaje, které se přes OpenID sdílet nedají. Ale to nejhorší teprve přijde:
Možnost 1: založení nového účtu Klepněte na tlačítko a vyplňte formulář. Stačí, když si v něm zvolíte přezdívku a heslo. Podívejte se ale i na další možnosti, kterými můžete svůj zdejší profil vylepšit.Proboha proč si asi myslíte, že OpenID používám? Proto, abych musel vymýšlet další heslo na další službu? Ještěže se na živě.cz přihlašuju jen proto, že jsem chtěl zkusit, jestli jim OpenID opravdu funguje. Takže, milá Mladá fronto a.s., díky, ale takhle si dobře odvedenou práci nepředstavuju.
Tiskni
Sdílej:
Misto remcani na diskuzich bys mel poslat bugreport jako spravnej uhrouslinuxak! Tak.Asi tedy nejsem správnej uhrouslinuxak :).
protoze jsi jen vysiracHlavně, že ty jsi king.
Však tam můžeš nakopírovat náhodný řetězec a hned ho zapomenout. Pokud se budeš hlásit _pokaždé_ přes OpenID, tak to heslo nebudeš potřebovat.Myslím, že jejich server je vhodnější ke generování náhodných řetězců, než uživatel.
Po pravdě: jsme trochu rádi, že jsme to celé stihli v termínu. Místnímu účtu se nevyhneme, na tom jsou naše weby postavenéNutnost založení místního účtu je každého věc, to nekritizuju.
Zatím stačí vymyslet si libovolné heslo, už ho stejně nebudete muset nikdy použít, ale uznávám, že to je zbytečný krok. Zkusíme s tím něco udělat.Popravdě jste mě příjemně překvapili, nečekal jsem vůbec žádnou reakci, natož nápravu.
Spíš jsem čekal, že nám někdo dá sežrat, že se na naše weby nedá přihlásit účtem Googlu, který svým způsobem OpenID taky podporuje. Jenže bohužel svým způsobem.Co je na jejich způsobu tak odlišného? Nezkoumal jsem to.
https://www.google.com/accounts/o8/id probehne presmerovani na google a tam se prihlasis jako obvykle, pote probehne presmerovnai z5 na puvodni web a pokracovani v integraci uctu/prihlaseni...
)
Very poor article, spreading FUD (fear, uncertainty, and doubt). Google in fact is a perfectly legit OpenID 2.0 implementation. The email address logging in is a natural fallout of a good OpenID 2.0 RP implementation and works on lots of RPs already for any email provider that also uses the OpenID directed identity feature. No OpenID extension is even required. (Andrew Arnott)
Ne že bych o to stál, jen jsem to zkoušel, když už se tu o tom píše. Ono by stačilo tam v takovém případě umožnit adresu zadat ručně. Prostě abych to zkrátil - shoduju se s původním článkem, že váš způsob implementace je podle mě poněkud... nešťastný. Ale nepláču pro to, stejně bych tam nechodil. Doufejme, že tam, kde by mi to skutečně vadilo, budou případně méně zvědaví na věci, do kterých jim podle mého soudu nic není...
Dobře, tak jinak: OpenID obvykle umožňuje uživateli vybrat, které informace z účtu chce dát dál a které ne.Naproti tomu zase v tom OpenID požadavku jsou specifikované věci povinné a věci volitelné. Pokud uživatel odmítá sdělit svůj email, který je uvedený jako vyžadovaný, tak holt musí počítat s tím, že se nepřihlásí. Nejsem si jist, jestli duplikování profilových informací na každém serveru v to nevnese ještě větší zmatek - to je snad lepší křičet za to, aby email nebyl u OpenID identit vyžadován...
OpenID používány jen pro předvyplnění případných registračních údajů, takže šly změnit a zbytek se kdyžtak vyplňoval ručně. To je podle mého správný postup, protože nikdy nemáte zaručeno, že vám server pošle vše, co požadujete.No jo, jenže pokud to pak jen uloží u sebe a už se OpenID na nic neptají, tak je to zase řešení napikaču :) Jedna z velkých výhod OpenID zmizí - jednotná identita. Když si pak nechám změnit jméno nebo si uvědomím, že jsem se narodil o rok dříve, tak si sice hezky upravím identitu u OpenID providera, ale pak budu muset navštěvovat zase tyhle weby a upravovat to tam samé, ikdyž si to mohlo z OpenID líznout samo...
Když si pak nechám změnit jméno nebo si uvědomím, že jsem se narodil o rok dříve, tak si sice hezky upravím identitu u OpenID providera, ale pak budu muset navštěvovat zase tyhle weby a upravovat to tam samé, ikdyž si to mohlo z OpenID líznout samo...Kolikrát už se ti to stalo? :)
Ale vždyť se serveru dotázat můžou - ale měli by počítat s tím, že tu informaci holt nedostanou. Podpora rozšíření, pokud se nepletu, není povinná ani v OpenID 2.0 (opravte mě, jestli se mýlím, ale ať do té specifikace koukám, jak koukám, nikde o povinně implementovaných extensions nic nevidím), v základu prostě musí server umět ověřit identitu a pokud zvládá něco navíc, je to jen jeho dobrá vůle. Pokud si implementuju vlastní OpenID server zvládající jen ověřit heslo a nic víc, je to stále podle specifikace a přitom z něj nic dalšího než ověření identity nedostanete, protože to jednoduše neumí.No, pak se může slovíčkařit o tom, jestli je přihlášení podporováno pomocí OpenID nebo pomocí OpenID s rozšířením :) Každopádně když už to provider umí a uživatel nechá poslat jenom některé údaje a to ne všechny povinné... no, každopádně mi přišlo trochu těžkopádné, aby se pak každý záznam, který uživatel zrovna neposlal, duplikoval a zadával ručně...
Jinak ty údaje se duplikují tak jako tak. I to Živě si mailovou adresu ukládá. A pokud jim OpenID server tuhle informaci pošle (čili uživatel to povolí a server to umí), můžou si jí automaticky aktualizovat podle libosti...Pokud si to aspoň při přihlášení aktualizujou, tak to celkem jde... ale obávám se, že to většina těch serverů dělat nebude. Což mi přijde strašně škoda - udělat podporu pro OpenID vč. rozšíření a pak to použít jenom k tomu, aby se ty údaje při vytvoření účtu zkopírovali...
Každopádně když už to provider umí a uživatel nechá poslat jenom některé údaje a to ne všechny povinné... no, každopádně mi přišlo trochu těžkopádné, aby se pak každý záznam, který uživatel zrovna neposlal, duplikoval a zadával ručně...Hmm, zdá se, že jsme se zacyklili. Zrovna na linuxovém serveru bych čekal, že bude důležité hlavně jestli daná věc odpovídá specifikaci. Vynucování implementace konkrétních rozšíření může taky skončit tím, že se nepůjde přihlásit, pokud nebude provider implementovat JedinouSprávnouExetensiontm dostupnou jako placený patentově chráněný ISAPI modul pro IIS8...
))
. Toho sem si ještě nevšiml.
. Je tu tak dva roky...