Google Chrome 140 byl prohlášen za stabilní. Nejnovější stabilní verze 140.0.7339.80 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 6 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
LeoCAD (Wikipedie) je svobodná multiplatformní aplikace umožňující také na Linuxu vytvářet virtuální 3D modely z kostek lega. Vydána byla verze 25.09. Zdrojové kódy a AppImage jsou k dispozici na GitHubu. Instalovat lze také z Flathubu.
RubyMine, tj. IDE pro Ruby a Rails od společnosti JetBrains, je nově zdarma pro nekomerční použití.
Český LibreOffice tým vydává překlad příručky LibreOffice Calc 25.2. Calc je tabulkový procesor kancelářského balíku LibreOffice. Příručka je ke stažení na stránce dokumentace.
Byla vydána (Mastodon, 𝕏) vývojová verze 3.1.4 příští stabilní verze 3.2 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání.
Zakladatel ChimeraOS představil další linuxovou distribuci zaměřenou na hráče počítačových her. Kazeta je linuxová distribuce inspirována herními konzolemi z 90. let. Pro hraní hry je potřeba vložit paměťové médium s danou hrou. Doporučeny jsou SD karty.
Komunita kolem Linuxu From Scratch (LFS) vydala Linux From Scratch 12.4 a Linux From Scratch 12.4 se systemd. Nové verze knih s návody na instalaci vlastního linuxového systému ze zdrojových kódů přichází s Glibc 2.42, Binutils 2.45 a Linuxem 6.15.1. Současně bylo oznámeno vydání verze 12.4 knih Beyond Linux From Scratch (BLFS) a Beyond Linux From Scratch se systemd.
Organizátoři konference LinuxDays ukončili veřejné přihlašování přednášek. Teď je na vás, abyste vybrali nejlepší témata, která na letošní konferenci zaznějí. Hlasovat můžete do neděle 7. září. Poté podle výsledků hlasování organizátoři sestaví program pro letošní ročník. Konference proběhne 4. a 5. října v Praze.
Byla vydána verze 11.0.0 vizuálního programovacího jazyka Snap! (Wikipedie) inspirovaného jazykem Scratch (Wikipedie). Přehled novinek na GitHubu.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma. Vypíchnout lze, že v Plasmě byl implementován 22letý požadavek. Historie schránky nově umožňuje ohvězdičkovat vybrané položky a mít k ním trvalý a snadný přístup.
Zdá se že používají jiný port, právě ten 587.To jsem pochopil. Jen mě překvapuje, že to řeší takto, protože SSL/TLS na samostatném portu je spíš historický relikt (z dob, kdy nebylo rozšíření SMTP pro TLS), než aby mělo smysl to dnes používat (tím spíš na nestandardním portu - port 587 je sice podle RFC 2476 určen pro Message Submission, ale když už se používá 25, pak by se měl používat port 465).
protoze potom se pouzije i pro s2s komunikaci a pokud nemate certifikaty podepsane duveryhodnou autoritou, tak prestanou maily chodit.Tohle je pravda jen ve dvou případech - buď když je TLS povinné, nebo když je odesílající server blbě nakonfigurován (případně s hodně starou verzí nějakého MTA, kde když selže TLS, tak se na doručení zcela rezignuje). Navíc by to neměl být případ Googlu, pro něj snad není problém mít důvěryhodný certifikát.
Prave proto je tam dalsi port, ktery je urcen pro c2s komunikaci a dava mnohem vetsi moznosti vyhrat si s konfiugraci.Pak by se měl ale používat i pro běžné (nešifrované) odesílání, jinak se do toho zanáší bordel a komplikuje se nastavování klientů (tedy ono už vůbec použití jiného portu než 25 komplikuje konfiguraci).
Tohle je pravda jen ve dvou případech - buď když je TLS povinné, nebo když je odesílající server blbě nakonfigurován (případně s hodně starou verzí nějakého MTA, kde když selže TLS, tak se na doručení zcela rezignuje).Tohle je slozita filozoficka otazka. Mam na protistranu, ktera je schopna dolozit svou identitu a dolozi ji umyslne spatne hledet stejne jako na takovou, ktera to neumi? A jak to mam udelat, mam resetnout SSL spojeni a otevrit nove plain text a nebo mam jet dal po tom SSL?
Pak by se měl ale používat i pro běžné (nešifrované) odesílání, jinak se do toho zanáší bordel a komplikuje se nastavování klientů (tedy ono už vůbec použití jiného portu než 25 komplikuje konfiguraci).Myslel jsem 587, 465 je fakt artefakt. Na 587 zvladne starttls i ten outlook.
Tohle je slozita filozoficka otazka. Mam na protistranu, ktera je schopna dolozit svou identitu a dolozi ji umyslne spatne hledet stejne jako na takovou, ktera to neumi? A jak to mam udelat, mam resetnout SSL spojeni a otevrit nove plain text a nebo mam jet dal po tom SSL?Z hlediska bezpečnosti by bylo o něco lepší jet dál po nedůvěryhodném SSL (protože to může zabránit aspoň odposlechu na trase), ale na druhou stranu by to teoreticky mohlo někoho "ukolébat", že se použilo šifrování a všechno tedy musí být v pořádku. Např. Postfix to standardně řeší tak, že když se po STARTTLS objeví problém (ať už kvůli certifikátu nebo z jiných důvodů), tak to zkusí znovu v plain textu, čili to převede na situaci, jako kdyby cílový server TLS vůbec nepodporoval.
Myslel jsem 587, 465 je fakt artefakt.Ale pak není potřeba z tohoto ohledu port 25 vůbec řešit a pro MUA nechat jen 587.
Na 587 zvladne starttls i ten outlook.To ano, ale musí se tam to číslo portu nastavit.
Ale pak není potřeba z tohoto ohledu port 25 vůbec řešit a pro MUA nechat jen 587.Ano a tak je to asi i spravne. Nevim jestli v dobe, kdy se navrhoval design SMTP nekdo pocital s tim, ze klient neco posle pres port 25, tehdy se na to pouzival prikaz sendmail, ktery komunikoval s lokalnim sendmail demonem tak, ze injektoval zpravu do fronty, takze 25 mohla byt od zacatku zamyslena jen pro s2s a klientum to holt zapomeli rict
Jinak rozhodne konfigurovat SASL a podobne vychytavky mi prijde mnohem cisti na 587To asi ano, ale SSL by bylo žádoucí používat i pro S2S komunikaci - čím méně "uší", tím lépe. Nic to samozřejmě nezaručuje (odposlouchávat se dá i na serveru, resp. je to ten častější případ), ale i tak.
Zadouci by to bylo, ale doba na to jeste nenazrala.Spíš to vypadá, že zraje doba na to (nebo spíše dávno nazrála), aby se šifrovaly samotné zprávy, aby se cizí uši nastražené kdekoli na celé trase nedostaly k obsahu zpráv.
A Verisign se na tom uzasne napakujeNaštěstí existují i levnější, a přitom dostatečně důvěryhodné certifikační autority (jejichž kořenové certifikáty jsou součástí instalací většiny MTA a MUA). Jen aby to pak ale neskončilo tak, že certifikát podepsaný od Verisignu bude mít méně bodů než ty ostatní autority
Spíš to vypadá, že zraje doba na to (nebo spíše dávno nazrála), aby se šifrovaly samotné zprávy, aby se cizí uši nastražené kdekoli na celé trase nedostaly k obsahu zpráv.Kazde z tech reseni je urcene pro mirne odlisny okruh problemu. SMTPS teoreticky zajisti duvernost prenesene zpravy i v pripade, ze uzivatele nemeli moznost vymenit si klice a nebo v pripade, ze email je poslan na 1000 adres soucasne a nebylo by prakticke sifrovat kazdou z tech kopii zvlast.
Naštěstí existují i levnější, a přitom dostatečně důvěryhodné certifikační autority (jejichž kořenové certifikáty jsou součástí instalací většiny MTA a MUA). Jen aby to pak ale neskončilo tak, že certifikát podepsaný od Verisignu bude mít méně bodů než ty ostatní autorityBavime se jiste o tech vlastnenych Verisignem
Umí nějaký klient seskupovat přijaté i odeslané zprávy do jedné „konverzace“ tak jak to dělá gmail? Snažím se přestat používat webmail ale takovéhle věci mi chybí.Kmail to umí. Stačí se podívat do Složka/Vlastnosti.
Thunderbird umí něco podobného - stromová vláknaAle AFAIK jen v rámci složky.
Podle mne to dělá google pěkně blbě, protože to dělá podle subject.Ale fuj, to snad ne!
Tiskni
Sdílej: