Byly zveřejněny informace o kritické zranitelnosti CVE-2026-64600 pojmenované RefluXFS (technické detaily) v XFS. Je tam již od verze Linuxu 4.11, tj. rok 2017. Jedná se o lokální eskalaci práv. Neprivilegovaný uživatel může editovat libovolný soubor, například klidně zrušit rootovské heslo v /etc/passwd. Videoukázka na Vimeo. V upstreamu je zranitelnost opravena.
OpenAI / ChatGPT má dnes výpadky (OpenAI Status, DownDetector).
Poskytovatel hostingu svobodných/open-source projektů Codeberg po hlasování na valné hromadě vydal stanovisko k využívání LLM. Kvůli vytěžování infrastruktury a rostoucím cenám hardwaru, ale také hrozbám pro spolupráci v komunitě se k LLM staví kriticky. Nebude poskytovat hosting projektů vytvářených LLM agenty.
Jack Dorsey představil (𝕏) open source týmovou komunikační platformu Buzz (GitHub) s cílem snížit závislost na Slacku a GitHubu.
Poštovní klient Thunderbird byl vydán v nové verzi 153 s kódovým názvem Meadow. Jedná se o ESR (Extended Support Release) vydání. Přehled novinek v poznámkách k vydání. Vylepšuje OAuth. Thundermail lze používat bez instalace doplňku.
AI tento rok naplno vtrhla do vývoje softwaru a výrazně ovlivňuje také open source projekty. Jiří Eischmann v příspěvku Jak mění AI open source na svém blogu rozebírá několik trendů, které v open source v poslední době v souvislosti s AI pozoruje, a jak tyto trendy svět otevřeného softwaru mění (Inflace projektů, Zahlcení kontroly, Klesající motivace zveřejňovat kód).
Evropská komise (EK) vyměřila americké internetové společnosti Google pokutu 890 milionů eur (21,5 miliardy Kč) za porušení unijního nařízení o digitálních trzích (DMA). Firma se podle unijní exekutivy provinila tím, že ve vyhledávači Google Search upřednostňovala vlastní služby a že podnikům ukládala omezení, která jim bránila nasměrovat spotřebitele k alternativním, často levnějším nákupním kanálům na platformě Google Play.
… více »Samsung na akci Galaxy Unpacked July 2026 (YouTube) představil své nové telefony Galaxy Z Fold8 Ultra, Fold8 a Flip8, hodinky Galaxy Watch Ultra2 a Watch9 a chytré brýle ve spolupráci s Gentle Monster a Warby Parker.
Po pěti letech vývoje vyšla česká počítačová hra Scarlet Deer Inn (ProtonDB). Scarlet Deer Inn je vyšívaná temná středověká pohádka. Zatímco život ve zdánlivě obyčejné vesnici se točí kolem běžných povinností a sousedských drbů, v podzemí se skrývají zlověstná tajemství.
Představen byl Raspberry Pi Touch Display 2 s uhlopříčkou 10 palců a rozlišením 1200 × 1920 pixelů. Cena je 80 dolarů.
Jooo? No ale nechceš toho trochu moc?
To, co popisuješ, uměl Microsoft NetMeeting, když jsem ho kdysi používal, ale to je closed-source, že jo...
Je několik jabberových serverů, které něco podobného umí, ale má to hned dva háčky. Zaprvé, který klient to podporuje? Zadruhé, něco velkého podruhé instalovat by mě zabilo. (Grrr...)
Pokud narážíš na fakt, že Skype tohle všechno má, máš sice pravdu, ale ani to jeho oblibu u mě příliš nezvyšuje. Mnohem raději použiji Ekigu s otevřeným protokolem (když chci videokonferenci) nebo SIP (Twinkle) (když chci telefonovat, včetně příchozího čísla a běžných telefonních sítí). Kromě toho, pokud vím, zatímco GnomeMeeting (Ekiga) podporuje videokonference odjakživa, Skype (beta!) s touto vymožeností pro Linux přišel teprve nedávno. U Skype mi (kromě jiného) chybí například možnost vybrat si kodek. Často je vybrán nevhodně a kvalita je bídná.
ICQ raději nechávám stranou. Podle mého názoru je to buggy šmejd, který prý má všechno možné, ale nic z toho ve skutečnosti nefunguje.
Pokud jde čistě o instant messaging, vůbec bych to s tím Jabberem neviděl tak černě...
Takže situace je asi opravdu taková, jak jsem se obával. Kdekdo Jabber vychvaluje, ale otázka je, k čemu jsou servery bez klientů. Existuje víc než 6 (více či méně kompletních) implementací serveru, zatímco použitelných klientů je jako šafránu..
Když už jsem Qt 4 musel zkompilovat kvůli Psi, rád vyzkouším i tohle. Proč ne, třeba to bude použitelné.
Tak to já teď zrovna kompiluju PyQt 4 a k tomu navíc ještě „legacy“ PyQt 3, aby to všechno mohlo v mém počítači spolubydlet.
To jsem zvědavý, či to bude stát za to úsilí. 
Python sice neumím, ale tento projekt je sám o sobě vynalézavý až dost. Líbí se mi, že to má hodně rychlou odezvu. Fungovalo to na první pokus, i s podporou starttls. Každopádně díky za dobrý tip. Už jsem Jabbim přidal do seznamu vyhovujících klientů v mém blogu.
No právě kvůli nim jsem chtěl starttls. V plain textu se zaručeně neposílá nic. Stačí jen zakázat jakýkoliv nešifrovaný přístup a hotovo.
<!-- Require STARTTLS. If this is enabled, clients must do STARTTLS
before they can authenticate. Until the stream is encrypted,
all packets will be dropped. -->
<require-starttls/>
Jasně, o tom nepochybuju.
Šlo ale hlavně o tu klasickou otázku, zda se plaintextem posílá heslo.
Proč flame? Vždyť je to pravda. Ano, heslo je v databázi uloženo nešifrovaně a existuje spousta (více či méně legálních) možností, jak ho odtamtud získat.
Výhodu zase vidím v tom, že se nedá odchytit ani login. Ten sice není určen k utajení, ale neznalost loginů velmi ztěžuje možnost slovníkového útoku.
Já se nepřu o výhodách/nevýhodách té které technologie. Například jabberd2 může bez problému využít tentýž certifikát pro SSL i TLS. Faktem ovšem je, že SSL spojení začíná být postupem času „deprecated“ a je vytlačováno TLS. (To samozřejmě platí výhradně pro Jabber, nikoliv pro ostatní internetové technologie.) Tento trend je vidět například v dokumentaci k serveru jabberd2 nebo ke klientům Gajim, Pidgin, Jabbim a Psi. Spojení přes SSL tam bývá často nazýváno legacy a podobně.
To je hlavní důvod, proč jsem přednostně zprovoznil pouze TLS. Dalším důvodem je fakt, že bez SSL má člověk v iptables o jeden povolený port méně. 
Šifrování na samostatném portu není popsáno/standardizováno jako součást XMPP, na úkor starttls. Proto je „deprecated“.No, tak to jsem nevedel, takze samozrejme v tom pripade akceptuju vyber TLS.
Navic v SSL se k tobe nepripoji ne-SSL klient, cili se nemuze stat ani nahodou, ze by klient omylem poslal auth udaje nesifrovany a server mu pak odpovedel, ze musi prihlasovaci udaje sifrovat (napr. IMAPem poslu login user password a uz je pozde na vynuceni sifrovani) - z toho duvodu mam radsi SSL.To ho máš radši z naprosto hloupého pseudodůvodu, protože se starttls samozřejmě můžeš dosáhnout toho samého. Například v Psi 0.11 lze nastavit, aby vyžadovalo šifrování (i na standardním portu). Je to jen blbost klienta, pokud neumí vyžadovat šifrování, nikoli chyba návrhu starttls.
Eee, rekl bych, ze jsi me spatne pochopil - jde mi o to, ze kdyz bude spatne nastavenej klient, tak muze poslat auth udaje nesifrovany, pokud server bude podporovat TLS v ramci plain-text spojeni (ted fakt netusim, jestli muze starttls vynutit i server, takze o tom se prit nebudu a klidne to akceptuju, pokud nekdo rekne, ze to server umoznuje). Uvedu na prikladu: Klient je spatne nakonfigurovanej a nespusti starttls. Klient, napr. IMAP jak jsem psal, se pripoji k serveru a posle logovaci udaje, napr. hned prvni prikaz budeNavic v SSL se k tobe nepripoji ne-SSL klient, cili se nemuze stat ani nahodou, ze by klient omylem poslal auth udaje nesifrovany a server mu pak odpovedel, ze musi prihlasovaci udaje sifrovat (napr. IMAPem poslu login user password a uz je pozde na vynuceni sifrovani) - z toho duvodu mam radsi SSL.To ho máš radši z naprosto hloupého pseudodůvodu, protože se starttls samozřejmě můžeš dosáhnout toho samého. Například v Psi 0.11 lze nastavit, aby vyžadovalo šifrování (i na standardním portu). Je to jen blbost klienta, pokud neumí vyžadovat šifrování, nikoli chyba návrhu starttls.
a0 login USER PASSWORD. Server na to muze klidne odpoved neco ve smyslu, ze pro prihlaseni pozaduje TLS, ale bohuzel - heslo uz slo siti nesifrovany. V pripade POP3 nebo SMTP a mozna i dalsich se nejdrive posle USERNAME a server muze reagovat zamitave.
Pokud se ale klient pripoji pres SSL (a pripojeni pres plain-text zakazu), mam zajisteny, ze logovani pujde ihned pres sifrovanej kanal.
To jsem mel na mysli, ale jak jsem uz psal, tohle plati pro IMAP a nevim pro ktere dalsi protokoly. Jinak samozrejme kazdej normalni klient provede nejaky otestovani prikazu, pripadne se dotaze, jestli muze autentizovat a server muze odpovedet, ze bez sifrovani ne. Napr. ldapsearch pri pripojeni s autentizaci na port 389 (nesifrovany a bez TLS) od serveru (pokud je tak nastavenej) obdrzi hlasku "confidentality required", ale netusim, jestli to dostane jako odpoved na pozadavek autentizace nebo az po zaslani hesla.
Je to jen blbost klienta, pokud neumí vyžadovat šifrování, nikoli chyba návrhu starttls.A jeste jsem zapomnel dodat. To mas sice pravdu, ale pak je muj problem, kdyz se mi nekdo dostane na server, protoze si nekdo spatne nastavil klienta, kterej posla ID udaje plain-textem a nejakej zaskodnik to odchytnul a zneuzil.
Navíc starttls je systematičtější.... přidává šifrování do protokolu... zatímco klasický TLS/SSL od začátku vytváří jakoby druhý protokol.Zas tak černobíle bych to neviděl. Je to jen o tom, kde to bude složitější. Pokud použiju SSL, bude v komunikaci o vrstvu více. Pokud TLS, bude jedna vrstva složitější. Takže je to jen o tom, co se u toho či onoho vyplatí. Já upřednostňuju SSL – prostě mám radši víc jednodušších věcí. A co se DNS týče... kdo říká, že nešifrovaná varianta musí být k disposici? (Pokud to není kvůli kompatibilitě.)
Je toho hodne k vyzkouseni ...
Tiskni
Sdílej: