V jádře Linux byla nalezena a v upstreamu již byla opravena kritická zranitelnost GhostLock aneb CVE-2026-43499. Lokálnímu uživateli umožňuje získat práva roota a také obejít kontejnerovou izolaci. Zranitelnost existovala v Linuxu 15 let, tj. od roku 2011, od Linuxu verze 2.6.39.
Evropská komise předběžně shledala, že návykový design aplikací Instagram a Facebook od americké společnosti Meta porušuje unijní nařízení o digitálních službách (DSA). Návykový design zahrnuje například takzvané nekonečné posouvání, automatické přehrávání videí, tzv. push notifikace, kdy aplikace uživatele vybízí k návratu do jejího prostředí, či vysoce personalizovaný algoritmus, který rychle pozná, co uživatele baví a snaží
… více »Byla vydána verze 1.97.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Švýcarská společnost Punkt. má nově v nabídce telefon Punkt. MC03. Telefon byl navržen ve Švýcarsku s důrazem na soukromí a digitální suverenitu a vyroben v Německu. V telefonu běží operační systém AphyOS (Apostrophy OS) založený na AOSP (Android Open Source Project) 15. Cena telefonu je 745 eur.
TypeScript (Wikipedie), tj. JavaScript rozšířený o statické typování a další atributy, byl vydán v nové verzi 7.0. Kompilátor byl kvůli výkonu přepsán z TypeScriptu do Go.
Europarlament podpořil pozměněnou verzi výjimky známé jako „chat control 1.0“ umožňující firmám skenovat soukromou komunikaci na internetu kvůli ochraně dětí před zneužitím. Pozměňovací návrhy přijaté europoslanci však počítají s tím, že z výjimky bude vyřazena šifrovaná komunikace. Výjimka přestala platit začátkem dubna poté, co se Evropský parlament a Rada EU nedokázaly shodnout na jejím prodloužení. Rada následně přijala
… více »Nejnovější X.Org X server 21.1.24 a Xwayland 24.1.13 řeší 2 bezpečnostní chyby.
Clement "Clem" Lefebvre publikoval souhrn dění v Linux Mintu za červen 2026. Vypíchnuta je vylepšená podpora Waylandu. Už není považována za experimentální. V příští verzi Linux Mintu, plánována je na Vánoce, bude běh Cinnamonu plně podporován na X11 i Waylandu. V květnu na vývoj Linux Mintu přispělo 611 dárců celkovou částkou 19 612 dolarů. Dalších 2 326 patronů přispělo na Patreonu celkovou částkou 5 334 dolarů.
V Linuxu v KVM byla nalezena a v upstreamu již byla opravena kritická zranitelnost Januscape aneb CVE-2026-53359. Root na hostovaném počítači (virtuální stroj) může obejít izolaci a získat plnou kontrolu nad hostitelským systémem (DoS útok nebo vzdálené spuštění kódu s právy roota). Na obou hlavních architekturách – Intel i AMD. Zranitelnost v Linuxu existovala téměř 16 let (od srpna 2010 do června 2026).
Tribunál Soudního dvora Evropské unie dnes zamítl několik žalob, v nichž se americká společnost Apple ohrazovala proti pravidlům fungování velkých technologických společností na unijním trhu. Applu se nelíbilo, že jeho obchod s aplikacemi a operační systém iOS mají podléhat přísnějším povinnostem jen proto, že Brusel firmu považuje za takzvaného gatekeepera, tedy strážce přístupu.
Já bych použil: JAVA + SSL Tutorial (server and client examples).
Jak by podle Tebe někdo získal klíč? BTW: Jinak ve výše uvedeném příkladu se využívá i heslo, které případně můžeš zakompilovat přímo do Java clienta.
Ten priklad poznam, ale sluzi skor na zabezpecenie komunikacie nez na autentifikaciu klienta. V tom priklade ma klient pristup k verejnemu klucu, ale na zaklade verejneho kluca neviem rozlisit klienta :( Problem je aj v tom, ze aj keby som to heslo, ktore oni pouzivaju pre pristup ku verejnemu klucu dal do zdrojakov, nie je az tak velky problem deasemblovat class subory a ziskat to z nich...
Ja skor potrebujem nieco na zaklade coho server bude vediet, ze komunikuje s pravym klientom a nie z nejakym "falosnym"
Ja skor potrebujem nieco na zaklade coho server bude vediet, ze komunikuje s pravym klientom a nie z nejakym "falosnym"
Tak to podle mě potřebuješ něco nereplikovatelné ... čili buď nějakou znalost uživatele (login/heslo pár) a nebo případně hardwarový klíč který provede nějakou netriviální operaci s daty zaslanými serverem klientské aplikaci která je následně pošle zpět (hw klíč je imho příšerné řešení).
Pokud jde o pouhé rozlišení toho jestli klient nebyl pozměněn (a ne o konkrétní počítač/člověka) pak se jedná o zajímavý oříšek, neboť jak říkáš tak je možné disasemblovat a upravit jakékoliv kódovací rutiny.java.util.prefs.Preferences
) uložit nějakou informaci (např. číslo), které budete mít spojené s tímto uživatelem. Je pak na odpovědnosti uživatele, že tuto uloženou informaci nikdo nezneužije – a pokud by ji někdo zneužil, bude pracovat pod identitou uživatele.
Pokud to má být způsob autorizace – tj. víte, že váš program neumožní udělat něco „zlého“, ale pokud by jej např. někdo upravil, už by něco takového (např. smazat celou databázi) udělat mohl, pak na to jdete špatným způsobem – tohle zabezpečení vždy musí být na serveru. Na klientovi můžete dělat nějaké kontroly navíc, které třeba umožní uživatele informovat dřív, než se data odešlou na server, ale vše je vždy nutné kontrolovat i na serveru, na klienta se nemůžete spoléhat.
Bez toho, aniž byste měl ověřenou funkčnost všech zařízení od klienta až po server a věděl, že tam nikdo nepodstrčí žádného falešného klienta,Omlouvám se, tohle je nesmysl, stačí mít ověřené to zařízení, které zajišťuje autentizaci – tedy např. hardwarový klíč, jak už někdo napsal výš. Data pro ověření tím zařízením už je možné přenášet po nezabezpečeném spojení.
No nieco take som si myslel :( ulozenie hesla/kluca na strane klienta nie je bezbecne. Asi by som to naozaj potreboval nieco ako DRM, ale do toho sa mi velmi nechce... DRM a Javu som nasiel len v suvislosti s "mobile devices" a neviem ci by som bol schobny naimplementovat spravne nieco take sam (skor isto nie:)
Skor som rozmyslal o tom, ze clienta budem distribuovat v podpisanom jar a zo serveru overoval ci to co bezi je z podpisaneho zdroja. Ale to by vyzadovalo nejake prepojenie JVM klenta a serveru, kedze sa nemozem spolahnut ze klient sa overi sam. Alebo mat nieco ako "opacne" RMI, teda zeby sa ku klientovi stahoval objekt ktory by autentifikoval clienta cez proxy u serveru:)
Asi by som to naozaj potreboval nieco ako DRM, ale do toho sa mi velmi nechce... DRM a Javu som nasiel len v suvislosti s "mobile devices" a neviem ci by som bol schobny naimplementovat spravne nieco take sam (skor isto nie:)Naimplementovat DRM ale neznamená „něco napsat v Javě“. Naimplementovat DRM by znamenalo naimplementovat celé příslušné zařízení – tedy buď hardwarový klíč, nebo operační systém a příslušné počítačové komponenty. Aby bylo DRM technicky účinné, musí to znamenat, že vám zařízení neumožní nějak snadno se dostat k např. chráněnému klíči. Proto se používá hardwarový klíč (ze kterého ten klíč budete těžko dostávat). Jakmile máte ten klíč někde v PC, dostanete se k němu snadno.
Skor som rozmyslal o tom, ze clienta budem distribuovat v podpisanom jar a zo serveru overoval ci to co bezi je z podpisaneho zdroja. Ale to by vyzadovalo nejake prepojenie JVM klenta a serveru, kedze sa nemozem spolahnut ze klient sa overi sam. Alebo mat nieco ako "opacne" RMI, teda zeby sa ku klientovi stahoval objekt ktory by autentifikoval clienta cez proxy u serveru:)Není nic jednoduššího, než si tu komunikaci odposlechnout a zopakovat vám jí z falešného klienta. Pokud bude šifrovaná, najdete si v klientské aplikaci klíč a dešifrujete ji. Je zbytečné uvažovat dál tímto směrem, je to jako kdybyste dumal nad tím, že nechcete sestrojit perpetuum mobile, ale jenom stroj, který bude neustále konat práci bez dodání energie.
Je zbytečné uvažovat dál tímto směrem, je to jako kdybyste dumal nad tím, že nechcete sestrojit perpetuum mobile, ale jenom stroj, který bude neustále konat práci bez dodání energie.
Ok:) chapem, ze to nikam neviedie. Len som sa potreboval uistit, ci nie je nejaky jednoduchy sposob ako to zabezpecit a ja som ho prehliadol :)
Tak dakujem vsetkym za radu
Tiskni
Sdílej: