PixiEditor byl vydán ve verzi 2.0. Jedná se o multiplatformní univerzální all-in-one 2D grafický editor. Zvládne rastrovou i vektorovou grafiku, pixel art, k tomu animace a efekty pomocí uzlového grafu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GNU LGPL 3.0.
Byly představeny novinky v Raspberry Pi Connect for Organisations. Vylepšen byl protokol auditu pro lepší zabezpečení. Raspberry Pi Connect je oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče. Verze pro organizace je placená. Cena je 0,50 dolaru za zařízení za měsíc.
CISA (Cybersecurity and Infrastructure Security Agency) oznámila veřejnou dostupnost škálovatelné a distribuované platformy Thorium pro automatizovanou analýzu malwaru. Zdrojové kódy jsou k dispozici na GitHubu.
Ubuntu nově pro testování nových verzí vydává měsíční snapshoty. Dnes vyšel 3. snapshot Ubuntu 25.10 (Questing Quokka).
Společnost Proton AG stojící za Proton Mailem a dalšími službami přidala do svého portfolia Proton Authenticator. S otevřeným zdrojovým kódem a k dispozici na všech zařízeních. Snadno a bezpečně synchronizujte a zálohujte své 2FA kódy. K používání nepotřebujete Proton Account.
Argentinec, který byl náhodně zachycen Google Street View kamerou, jak se zcela nahý prochází po svém dvorku, vysoudil od internetového giganta odškodné. Soud uznal, že jeho soukromí bylo opravdu porušeno – Google mu má vyplatit v přepočtu asi 12 500 dolarů.
Eben Upton, CEO Raspberry Pi Holdings, informuje o RP2350 A4, RP2354 a nové hackerské výzvě. Nový mikrokontrolér RP2350 A4 řeší chyby, i bezpečnostní, předchozího RP2350 A2. RP2354 je varianta RP2350 s 2 MB paměti. Vyhlášena byla nová hackerská výzva. Vyhrát lze 20 000 dolarů.
Představen byl notebook TUXEDO InfinityBook Pro 15 Gen10 s procesorem AMD Ryzen AI 300, integrovanou grafikou AMD Radeon 800M, 15,3 palcovým displejem s rozlišením 2560x1600 pixelů. V konfiguraci si lze vybrat až 128 GB RAM. Koupit jej lze s nainstalovaným TUXEDO OS nebo Ubuntu 24.04 LTS.
Po půl roce od vydání verze 2.41 byla vydána nová verze 2.42 knihovny glibc (GNU C Library). Přehled novinek v poznámkách k vydání a v souboru NEWS. Vypíchnout lze například podporu SFrame. Opraveny jsou zranitelnosti CVE-2025-0395, CVE-2025-5702, CVE-2025-5745 a CVE-2025-8058.
Byla vydána nová verze 9.15 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
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: