Desktopové prostředí Budgie bylo vydáno ve verzi 10.10. Dokončena byla migrace z X11 na Wayland. Budgie 10 vstupuje do režimu údržby. Vývoj se přesouvá k Budgie 11. Dlouho se řešilo, v čem bude nové Budgie napsáno. Budgie 10 je postaveno nad GTK 3. Přemýšlelo se také nad přepsáním z GTK do EFL. Budgie 11 bude nakonec postaveno nad Qt 6.
OpenChaos.dev je 'samovolně se vyvíjející open source projekt' s nedefinovaným cílem. Každý týden mohou lidé hlasovat o návrzích (pull requestech), přičemž vítězný návrh se integruje do kódu projektu (repozitář na GitHubu). Hlasováním je možné změnit téměř vše, včetně tohoto pravidla. Hlasování končí vždy v neděli v 9:00 UTC.
Byl vydán Debian 13.3, tj. třetí opravná verze Debianu 13 s kódovým názvem Trixie a Debian 12.13, tj. třináctá opravná verze Debianu 12 s kódovým názvem Bookworm. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 a Debianu 12 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
Na stránkách Evropské komise, na portálu Podělte se o svůj názor, se lze do 3. února podělit o názor k iniciativě Evropské otevřené digitální ekosystémy řešící přístup EU k otevřenému softwaru.
Společnost Kagi stojící za stejnojmenným placeným vyhledávačem vydala (𝕏) alfa verzi linuxové verze (flatpak) svého proprietárního webového prohlížeče Orion.
Firma Bose se po tlaku uživatelů rozhodla, že otevře API svých chytrých reproduktorů SoundTouch, což umožní pokračovat v jejich používání i po plánovaném ukončení podpory v letošním roce. Pro ovládání také bude stále možné využívat oficiální aplikaci, ale už pouze lokálně bez cloudových služeb. Dokumentace API dostupná zde (soubor PDF).
Jiří Eischmann se v příspěvku na svém blogu rozepsal o open source AdGuard Home jako domácí ochraně nejen před reklamou. Adguard Home není plnohodnotným DNS resolverem, funguje jako DNS forwarder s možností filtrování. To znamená, že když přijme DNS dotaz, sám na něj neodpoví, ale přepošle ho na vybraný DNS server a odpovědi zpracovává a filtruje dle nastavených pravidel a následně posílá zpět klientům. Dá se tedy používat k blokování reklamy a škodlivých stránek a k rodičovské kontrole na úrovni DNS.
AI Claude Code od Anthropicu lépe rozumí frameworku Nette, tj. open source frameworku pro tvorbu webových aplikací v PHP. David Grudl napsal plugin Nette pro Claude Code.
Byla vydána prosincová aktualizace aneb nová verze 1.108 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.108 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Na lasvegaském veletrhu elektroniky CES byl předveden prototyp notebooku chlazeného pomocí plazmových aktuátorů (DBD). Ačkoliv se nejedná o první nápad svého druhu, nepochybně to je první ukázka praktického použití tohoto způsobu chlazení v běžné elektronice. Co činí plazmové chladící akční členy technologickou výzvou je především vysoká produkce jedovatého ozonu, tu se prý podařilo firmě YPlasma zredukovat dielektrickou
… více »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: