Samba (Wikipedie), svobodná implementace SMB a Active Directory, byla vydána ve verzi 4.23.0. Počínaje verzí Samba 4.23 jsou unixová rozšíření SMB3 ve výchozím nastavení povolena. Přidána byla podpora SMB3 přes QUIC. Nová utilita smb_prometheus_endpoint exportuje metriky ve formátu Prometheus.
Správcovský tým repozitáře F-Droid pro Android sdílí doporučení, jak řešit žádosti o odstranění nelegálního obsahu. Základem je mít nastavené formální procesy, vyhrazenou e-mailovou adresu a být transparentní. Zdůrazňují také důležitost volby jurisdikce (F-Droid je v Nizozemsku).
Byly publikovány informace o další zranitelnosti v procesorech. Nejnovější zranitelnost byla pojmenována VMScape (CVE-2025-40300, GitHub) a v upstream Linuxech je již opravena. Jedná se o variantu Spectre. KVM host může číst data z uživatelského prostoru hypervizoru, např. QEMU.
V červenci loňského roku organizace Apache Software Foundation (ASF) oznámila, že se částečně přestane dopouštět kulturní apropriace a změní své logo. Dnes bylo nové logo představeno. "Indiánské pírko" bylo nahrazeno dubovým listem a text Apache Software Foundation zkratkou ASF. Slovo Apache se bude "zatím" dál používat. Oficiální název organizace zůstává Apache Software Foundation, stejně jako názvy projektů, například Apache HTTP Server.
Byla vydána (𝕏) srpnová aktualizace aneb nová verze 1.104 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.104 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Spotify spustilo přehrávání v bezztrátové kvalitě. V předplatném Spotify Premium.
Spoluzakladatel a předseda správní rady americké softwarové společnosti Oracle Larry Ellison vystřídal spoluzakladatele automobilky Tesla a dalších firem Elona Muska na postu nejbohatšího člověka světa. Hodnota Ellisonova majetku díky dnešnímu prudkému posílení ceny akcií Oraclu odpoledne vykazovala nárůst o více než 100 miliard dolarů a dosáhla 393 miliard USD (zhruba 8,2 bilionu Kč). Hodnota Muskova majetku činila zhruba 385 miliard dolarů.
Bylo vydáno Eclipse IDE 2025-09 aneb Eclipse 4.37. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
T-Mobile od 15. září zpřístupňuje RCS (Rich Communication Services) zprávy i pro iPhone.
Společnost ARM představila platformu Arm Lumex s Arm C1 CPU Cluster a Arm Mali G1-Ultra GPU pro vlajkové chytré telefony a počítače nové generace.
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: