Byla vydána nová verze 1.4 svobodného multiplatformního vektorového grafického editoru Inkscape. Podrobný přehled novinek i s náhledy a animovanými gify v poznámkách k vydání.
Softwarový KVM Input Leap (dříve Barrier) byl vydán ve verzi 3.0.0 (a následně pár opravných). Přidává podporu Waylandu a Qt6. Jde o první vydání od přesunu z projektu Barrier v roce 2021. Barrier vznikl jako fork Synergy, jehož verze 2 byla částečně proprietární a její bezplatná open-source verze měla umělá omezení.
Na čem aktuálně pracují vývojáři GNOME a KDE? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE.
Přímý přenos (YouTube) z konference LinuxDays 2024, jež probíhá tento víkend v Praze v prostorách Fakulty informačních technologií Českého vysokého učení v Praze (FIT ČVUT). Na programu je spousta zajímavých přednášek.
Elon Musk na akci We, Robot (YouTube, 𝕏) představil Robotaxi, Robovan a vylepšeného Tesla Bota (Optimus).
Internet Archive je offline (𝕏, Bluesky, Mastodon). Unikly údaje 31 milionů uživatelů. Probíhal / probíhá na něj DDoS útok.
Alyssa Rosenzweig se v příspěvku na svém blogu rozepsala o hraní AAA her na Asahi Linuxu. Na YouTube je záznam její včerejší přednášky na XDC 2024 (X.Org Developer's Conference).
Vláda schválila Národní polovodičovou strategii: Česká republika má velký potenciál stát se významným hráčem v oblasti výroby čipů, zejména v evropském měřítku. Využít tento potenciál je cílem Národní polovodičové strategie, kterou připravilo Ministerstvo průmyslu a obchodu ve spolupráci s experty, a která navazuje na evropský Akt o čipech.
V lete vyšiel Aeonwave 4.0, ktorý niekoľkonásobne menej vyťažuje procesor pri interpretácií priestorového zvuku než OpenAL Soft. Autor hľadá prispievateľov do knižnice libaaxopenal za účelom pridania ALC_EXT_EFX rozšírení využívaných napr. v hre Doom 3 cez port Dhewm3 v Linuxe.
Linuxová distribuce Ubuntu 24.10 „Oracular Oriole“ byla vydána. Jde o průběžné vydání s podporou 9 měsíců. Obsahuje mj. Linux 6.11 či GNOME 47 s několika odkazy na první vydání Ubuntu (4.10 „Warty Warthog“) před 20 lety. K dispozici jsou také oficiální deriváty s odlišnými výchozími desktopovými prostředími anebo balíky aplikací.
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: