Během tradiční ceremonie k oslavě Dne vzniku samostatného československého státu (28. října) byl vyznamenán medailí Za zásluhy (o stát v oblasti hospodářské) vývojář 3D tiskáren Josef Průša. Letos byly uděleny pouze dvě medaile Za zásluhy o stát v oblasti hospodářské, druhou dostal informatik a manažer Ondřej Felix, který se zabývá digitalizací státní správy.
Tor Browser, tj. fork webového prohlížeče Mozilla Firefox s integrovaným klientem sítě Tor přednastavený tak, aby přes tuto síť bezpečně komunikoval, byl vydán ve verzi 15.0. Postaven je na Firefoxu ESR 140.
Bylo oznámeno (cs) vydání Fedora Linuxu 43. Ve finální verzi vychází šest oficiálních edic: Fedora Workstation a Fedora KDE Plasma Desktop pro desktopové, Fedora Server pro serverové, Fedora IoT pro internet věcí, Fedora Cloud pro cloudové nasazení a Fedora CoreOS pro ty, kteří preferují neměnné systémy. Vedle nich jsou k dispozici také další atomické desktopy, spiny a laby. Podrobný přehled novinek v samostatných článcích na stránkách Fedora Magazinu: Fedora Workstation, Fedora KDE Plasma Desktop, Fedora Silverblue a Fedora Atomic Desktops.
Elon Musk oznámil (𝕏) spuštění internetové encyklopedie Grokipedia (Wikipedia). Zatím ve verzi 0.1. Verze 1.0 prý bude 10x lepší, ale i ve verzi 0.1 je podle Elona Muska již lepší než Wikipedia.
PSF (Python Software Foundation) po mnoha měsících práce získala grant ve výši 1,5 milionu dolarů od americké vládní NSF (National Science Foundation) v rámci programu "Bezpečnost, ochrana a soukromí open source ekosystémů" na zvýšení bezpečnosti Pythonu a PyPI. PSF ale nesouhlasí s předloženou podmínkou grantu, že během trvání finanční podpory nebude žádným způsobem podporovat diverzitu, rovnost a inkluzi (DEI). PSF má diverzitu přímo ve svém poslání (Mission) a proto grant odmítla.
Balík nástrojů Rust Coreutils / uutils coreutils, tj. nástrojů z GNU Coreutils napsaných v programovacím jazyce Rust, byl vydán ve verzi 0.3.0. Z 634 testů kompatibility Rust Coreutils s GNU Coreutils bylo úspěšných 532, tj. 83,91 %. V Ubuntu 25.10 se již používá Rust Coreutils místo GNU Coreutils, což může přinášet problémy, viz například nefunkční automatická aktualizace.
Od 3. listopadu 2025 budou muset nová rozšíření Firefoxu specifikovat, zda shromažďují nebo sdílejí osobní údaje. Po všech rozšířeních to bude vyžadováno někdy v první polovině roku 2026. Tyto informace se zobrazí uživateli, když začne instalovat rozšíření, spolu s veškerými oprávněními, která rozšíření požaduje.
Jste nuceni pracovat s Linuxem? Chybí vám pohodlí, které vám poskytoval Microsoft, když vás špehoval a sledoval všechno, co děláte? Nebojte se. Recall for Linux vám vrátí všechny skvělé funkce Windows Recall, které vám chyběly.
Společnost Fre(i)e Software oznámila, že má budget na práci na Debianu pro tablety s cílem jeho vyžívání pro vzdělávací účely. Jako uživatelské prostředí bude použito Lomiri.
Proběhla hackerská soutěž Pwn2Own Ireland 2025. Celkově bylo vyplaceno 1 024 750 dolarů za 73 unikátních zranitelností nultého dne (0-day). Vítězný Summoning Team si odnesl 187 500 dolarů. Shrnutí po jednotlivých dnech na blogu Zero Day Initiative (1. den, 2. den a 3. den) a na YouTube.
Nešifrované HTTP
| by mělo zmizet |
|
4% (260) |
| je postačující, dokud nejsou přenášena důvěrná data |
|
96% (6819) |
Celkem 7079 hlasů
Vytvořeno: 23.4.2015 11:44
Tiskni
Sdílej:
23.4.2015 11:45
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
23.4.2015 23:39
Petr Tomášek | skóre: 39
| blog: Vejšplechty
jednocipy niesu taky problem, ARMy s linuxom uz vobec a ked pouzivas nieco ako ESP8266, tak si ho preproxujes a zasifrujes cez domaci router, aj tak vacsinou nema to male zariadenie ani verejnu IP...
9.5.2015 19:47
Petr Tomášek | skóre: 39
| blog: Vejšplechty
7.5.2015 23:04
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
23.4.2015 13:29
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
...jen nevím, ze kterého roku ty vánoce byly zamýšleny.
8.9.2015 09:34
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
Chtělo by to checkboxy.
Zmizení nešifrovaného HTTP by bylo pěkné, ale zatím to není proveditelné, zejména z toho důvodu, že HTTPS není o moc bezpečnější. Problém je v tom, jakým certifikátem je možné komunikaci zabezpečit – v prohlížečích jsou i podivné CA a každá autorita může podepsat cokoliv.
Navíc většina browserů křičí při self-signed certifikátu a u některých (zrovna u Mozilly) není úplně jednoduché povolit spojení se serverem, kterému certifikát např. vypršel. Takže majitel webu musí solit a starat se.
7.5.2015 23:10
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Takže majitel webu musí solit a starat se.Majitelé webů, a to i těch hodně navštěvovaných, se často nestarají
Zmizet úplně nemusí, ale je třeba si uvědomit, že spousta informací, které samy o sobě důvěrné nejsou, v agregované podobě už nebezpečí představují – proto má smysl chránit i zdánlivé banality jako, o čem si člověk čte, co hledá na mapě, jaké si hledá spojení v jízdním řádu atd.
1.5.2015 01:18
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
To je pravda. V případě třeba nejaky-protistatni-blog.wordpress.com to hraje celkem velkou roli. Ale v případě Wikipedie, zpravodajských serverů nebo portálů se širším zaměřením se šmírák nic podstatného nedozví. Zatímco v případě nešifrovaného HTTP vidí, které konkrétní články si čteš a co zadáváš do vyhledávače.
7.5.2015 23:11
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
16.5.2015 22:33
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Hlavně by to chtělo změnit chování prohlížečů – zatímco samopodepsané HTTPS vypadá strašidelně a běžný uživatel se k takovému obsahu jen tak nedostane1, zatímco u nešifrovaného HTTP prohlížeč žádné varování nezobrazí2 a uživatel má pocit, že je všechno v pohodě – i když je to ve skutečnosti horší než to samopodepsané HTTPS, které odstaví alespoň pasivní3 odposlouchávače (třeba na WiFi nebo když si nějaký síťař pustí tcpdump, nachytaná data uloží a pak se povalují různě na discích nebo dále šíří),
[1] v horším případě si vytvoří návyk, že je potřeba kliknout tady a potom támhle, a bude to dělat kdykoli na něj ta hláška vyskočí – i třeba při přístupu do banky nebo k e-mailu
[2] kdysi se možná zobrazovalo varování při prvním odeslání formuláře přes HTTP, že data můžou být odposlechnuta
[3] nezasahují do komunikace a nedělají MITM
Hlavně by to chtělo změnit chování prohlížečů – zatímco samopodepsané HTTPS vypadá strašidelně a běžný uživatel se k takovému obsahu jen tak nedostane, zatímco u nešifrovaného HTTP prohlížeč žádné varování nezobrazíSes posral, ne? To by pak Mozilla nemohla inkasovat úplatky od důvěryhodných čínských soudruhů.
3.5.2015 10:06
Václav "Darm" Novák | skóre: 26
| blog: Darmovy_kecy
| Bechyně / Praha
4.5.2015 17:22
⧠ A = 0 | skóre: 11
| blog: Technokratovo_zrcadlo
| Helsinki
Přijatelná alternativa k heslům moc neexistuje.
Takže bych začal tím, že aplikace1, do které uživatel zadává heslo2, se k němu nebude distribuovat nezabezpečenou cestou3.
[1] u webů typicky JavaScript
[2] které se klidně na klientovi může zahashovat a server se ho za normálních okolností – pokud aplikaci cestou nikdo nepozmění – nedozví
[3] nešifrované/nedůvěryhodné HTTP
Přijatelná alternativa k heslům moc neexistuje.Challenge-response auth. Asymetrická kryptografie.
).[1] když už tu důvěryhodnost nedokáže posoudit uživatel, tak aspoň důvěryhodný z pohledu provozovatele služby/aplikace – který má přístup k datům uživatelů, a ti mu tudíž musí věřit tak jako tak
nebo můžou mít zase heslo, ze kterého se odvodí klíčPřesně tak. Rozdíl je v tom, že se to heslo neposílá na server - takže není možné aby nastal ten populární případ údivu „jé, já jsem serveru poslal své heslo a on ho teď zná, to je ale zlý server!“
Jak víš, že se to heslo neposílá na server nebo někam jinam, když ti ten JavaScript přišel po HTTP a kdykoli se ti mohla nainstalovat nová verze (takže i když jsi tu starou četl, je ti to celkem na nic)?
V čem je rozdíl jestli pošlu seed nebo hash?Záleží na tom jak ten seed/hash počítáš…
Replay tím stejně neodstraním a pokud tam je sůl nebo čas, tak už je to celkem běžná forma challenge/response.No vždyť o to mi jde.
protože nemáme uživatelsky příjemný a univerzální způsob jak pracovat s heslem chráněnýma čipovkamaI RSA/ECDSA odvozené z hesla je mnohem lepší než současný způsob.
Vzpomínám si, že jsem četl o protokolu na přihlášení přes nezabezpečený kanál, kde server nikdy nedostal heslo v čitelné formě (ani v db, ani při přihlášení), ale už si nevzpomínám jak se ten protokol jmenoval.SCRAM, ale ten mi přijde překomplikovaný. Jsou jednodušší cesty.
9.5.2015 20:07
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Vzpomínám si, že jsem četl o protokolu na přihlášení přes nezabezpečený kanál, kde server nikdy nedostal heslo v čitelné formě (ani v db, ani při přihlášení), ale už si nevzpomínám jak se ten protokol jmenoval.
Ono by úplně stačilo upravil HTML standard tak, aby se přidal nový typ formulářového pole který by heslo hashoval v prohlížeči, který by případně dostal za parametr "sůl" a na server by to posílalo jen čistý hash. Něco ve stylu:
<form> <input type="hashed-password" hash-method="sha512" hash-encoding="base64" salt="GxzoEm+ce3s8z2VLpQzz4CSh5awdC0xc07fJ0o/r"> <input type="submit"> </form>
To je pravda – součástí soli by měla být i doména serveru a jméno uživatele případně i název služby (na doméně jich může být víc).
10.5.2015 14:39
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Co když si na svém ďábelském webu nastavím stejnou sůl jako mi vrátí AbcLinuxu a získaný hash prostě použiju?
V tom případě by Abclinuxu bylo opravdu debilní, kdyby si poslanou sůl nepoznamenalo do databáze (nejlíp s dalším identifikátorem, např. IP adresou klienta nebo tak něco) a nechalo si vnutit sůl jinou...
A taky to neřeší replay a přihlášení uloženým hashem z uniklé databáze.
Replay to řeší, pokud se zajistí pokaždé jiná sůl, viz výše.
V tom případě by Abclinuxu bylo opravdu debilní, kdyby si poslanou sůl nepoznamenalo do databáze (nejlíp s dalším identifikátorem, např. IP adresou klienta nebo tak něco) a nechalo si vnutit sůl jinou...Jak to pomůže?
Replay to řeší, pokud se zajistí pokaždé jiná sůl, viz výše.A jak pak budeš na serveru porovnávat jestli je to heslo správné? Při registraci dostaneš hash(mojeheslo+666), při dalším přihlášení hash(mojeheslo+999), úplně jiné hodnoty, neporovnatelné.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
7.5.2015 07:27
24.4.2015 13:15
6.5.2015 20:38
25.4.2015 00:06
25.4.2015 16:20
6.5.2015 15:02
"login:realm:heslo", takže server sice zná hash který by mohl zneužít k přihlášení jménem uživatele na jiný server, ale jen pokud ten server bude mít totožný realm.
Nejlepší na tom je, že webové prohlížeče i webové servery Digest podporují - stačí použít ne-basic .htpasswd autentizaci Apache - AuthType Digest.
viz podrobný (praktický) popis
.
Nešifrované HTTP by bylo svým způsobem OK, kdyby bylo aspoň kryptograficky podepisované, aby koncový uživatel mohl ověřit, že skutečně čte původní informace zveřejněné na nějakém webu. Dnešní nešifrované HTTP bohužel znamená, že se s informacemi může stát cestou cokoliv a koncový uživatel nemá možnost na to přijít.
17.7.2015 21:48
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
25.8.2015 12:28