Byla vydána nová verze 1.26 programovacího jazyka Go (Wikipedie). Přehled novinek v poznámkách k vydání.
CrossOver, komerční produkt založený na Wine, byl vydán ve verzi 26. Přehled novinek v ChangeLogu. CrossOver 26 vychází z Wine 11.0, D3DMetal 3.0, DXMT 0.72, Wine Mono 10.4.1 a vkd3d 1.18. Do 17. února lze koupit CrossOver+ se slevou 26 %.
KiCad je nově k dispozici také jako balíček ve formátu AppImage. Stačí jej stáhnout, nastavit právo na spouštění a spustit [Mastodon, 𝕏].
Šenčenská firma Seeed Studio představila projekt levného robotického ramena reBot Arm B601, primárně coby pomůcky pro studenty a výzkumníky. Paže má 6 stupňů volnosti, dosah 650 mm a nosnost 1,5 kilogramu, podporované platformy mají být ROS1, ROS2, LeRobot, Pinocchio a Isaac Sim, krom toho bude k dispozici vlastní SDK napsané v Pythonu. Kompletní seznam součástek, videonávody a nejspíš i cena budou zveřejněny až koncem tohoto měsíce.
… více »Byla vydána nová verze 36.0, tj. první stabilní verze nové řady 36, svobodného multimediálního centra MythTV (Wikipedie). Přehled novinek a vylepšení v poznámkách k vydání.
Byl vydán LineageOS 23.2 (Mastodon). LineageOS (Wikipedie) je svobodný operační systém pro chytré telefony, tablety a set-top boxy založený na Androidu. Jedná se o nástupce CyanogenModu.
Od března budou mít uživatelé Discordu bez ověření věku pouze minimální práva vhodná pro teenagery.
Evropská komise (EK) předběžně shledala čínskou sociální síť pro sdílení krátkých videí TikTok návykovým designem v rozporu s unijním nařízením o digitálních službách (DSA). Komise, která je exekutivním orgánem Evropské unie a má rozsáhlé pravomoci, o tom informovala v tiskovém sdělení. TikTok v reakci uvedl, že EK o platformě vykreslila podle něj zcela nepravdivý obraz, a proto se bude bránit.… více »
Offpunk byl vydán ve verzi 3.0. Jedná se o webový prohlížeč běžící v terminálu a podporující také protokoly Gemini, Gopher a RSS. Přibyl nástroj xkcdpunk pro zobrazení XKCD v terminálu.
Promethee je projekt, který implementuje UEFI (Unified Extensible Firmware Interface) bindingy pro JavaScript. Z bootovacího média načítá a spouští soubor 'script.js', který může používat UEFI služby. Cílem je vytvořit zavaděč, který lze přizpůsobit pomocí HTML/CSS/JS. Repozitář se zdrojovými kódy je na Codebergu.
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
Tiskni
Sdílej:
25.8.2015 12:28