Příspěvky

1

Hardware / Re:Chování nabídky napětí USB-C nabíječky s PD

« kdy: Dnes v 08:01:56 »

S nabíječkama z IKEA za pár stovek tu asi budu vypadat trošku posh, ale oproti těm z Alíku mám větší důvěru, že nevyhořím, i že budou fungovat.

Ad 5V v USB C – upřesním: Je naprosto OK, že těch 5V bude na samci, který není k ničemu připojen. (To je běžná situace u USB A-C kabelů.) Ale toto napětí nesmí být na samici, dokud si to protistrana nevyjedná. Důvod je jednoduchý – představte si propojení dvou USB C zdrojů kabelem, případně totéž u USB A a USB C zdroje. Pokud na USB C samici bude 5V (±5%), pak se oba zdroje propojí. Ne vždy to bude problém, ale může tu být rozdíl až 0.5V, pak silnější zdroj bude zkoušet krmit ten slabší.

Krmit z USB něco bez vyjednání proudu je problém, zvlášť pokud jsme nad 5V 0.1A. Zdroj může omezit proud a koncové zařízení by to mělo respektovat.

2

Vývoj / Re:Framework vs. čistý kód

« kdy: 17. 08. 2025, 15:23:11 »

Pokud framework vnucuje styl chybně, jde o chybně vybraný framework.

3

Hardware / Re:Doplnění ECC RAM do stávající sestavy HP Z440

« kdy: 10. 08. 2025, 17:55:49 »

Otázka je, jak zásadní je výkon:

1. Nejjednodušší je mít přesně stejné modely.
2. Když už to nejsou stejné modely, je dobré mít stejné parametry. Zejména frekvenci a tři čísla u časování (CL). Pokud se parametry liší, jede se podle slabší RAM. Takže přidat slabší RAM znamená zpomalit ostatní, přidat silnější RAM nemá význam.
3. Když už parametry nejsou stejné, je fajn, když aspoň nejsou horší. Trošku tricky to je u různých frekvencí – se snížením frekvence se změní i časování, zhruba nepřímo úměrně. Ideální je si to vyčíst třeba z dokumentace. Důvod je, že to časování se uvádí v počtu taktů, takže při nižší frekvenci stejný čas uplyne za méně taktů.
4. Když se swapuje, i neoptimální kombinace může být lepší než nic. Já si nějakou neoptimální kombinaci vyzkoušel dočasně kvůli reklamaci, a holt pomalejší RAM byla mnohem menší zlo než swap.

4

Software / Re:Stažené soubory s nesedícím md5

« kdy: 06. 08. 2025, 09:50:44 »

Pokud si tu knihovnu stáhne v binární podobě bez další kontroly, a autor té knihovny (nebo někdo po cestě, třeba CI) se snaží udělat útok, je to problém i s řádnou kontrolou hashů.

Pokud si tu knihovnu kompiluje NextCloud nebo pokud má reproducible build, je zase těžší tam něco smysluplného podstrčit, aniž by to ve zdrojových kódech vypadalo divně. Upravit zdrojový kód tak, aby z kompilátoru vypadla zvolená sekvence dat (pro útočníka v podstatě náhodný blob) na vhodné pozici, není úplně sranda. Nejlépe by to šlo asi nějakým stringem, ale pak nemusí být úplně sranda jeho přítomnost nějak rozumně obhájit. Proto mi obrázky a další data přijdou pro útočníka příhodnější.

5

Software / Re:Stažené soubory s nesedícím md5

« kdy: 06. 08. 2025, 08:44:00 »

A k pre-image útokům na MD5 jsem našel pár let starou informaci, že jsou zatím prakticky neproveditelné, nejlepší známá možnost je vlastně méně než 25* méně složitá než hrubá síla: https://security.stackexchange.com/a/261417

Reálné útoky se tedy spíš soustředí na to, aby nebylo potřeba najít jiný pre-image, ale jen obyčejnou kolizi. Nevím, jestli je k tomu prakticky použitelná samotná knihovna třetí strany, spíše nějaká binární data jako třeba obrázek. Nebo něco, kam lze skrýt vhodná metadata, aniž by to bylo někomu divné.

6

Software / Re:Stažené soubory s nesedícím md5

« kdy: 06. 08. 2025, 08:21:35 »

Podstatnym kvalitativnim ukazatelem dobreho hashe je, ze i pri zmene byt jednoho bitu, bude cely hash vypada uplne jinak Takze nezalezi na delce.. zmena bude patrna uz z prvnich (ci poslednich) cislic. (ostatne to je princip i zkracovani u git commit hashe)

Bavíme se o náhodné kolizi prvních/posledních pár bytů, nebo o cílené kolizi? Cílenou kolizi pár bytů uděláte hrubou silou. U sedmimístného git commit id máte 4*7 = 28 bitů, to je s brute force hračka, to spočítáte dnes snad i na hodinkách. Pokud můžete měnit něco na konci souboru, dokonce ani nemusíte pokaždé počítat hash od začátku, ale můžete podstatnou část výpočtu sdílet.

BTW, kdysi dávno (tak před 20 lety) jsem narazil na ffp (fuzzy fingerprints), což je nástroj, který generuje klíče, jejichž hashe vypadají vizuálně podobně: https://www.usenix.org/system/files/login/articles/105484-Gutmann.pdf

7

Vývoj / Re:Framework vs. čistý kód

« kdy: 26. 07. 2025, 22:09:25 »

Kit: Jenže tady mi přijde, že se od „Nepitřebuju framework“ dostáváme k „Vytvářím vlastní framework, protože existující mi nevyhovují.“. Nechám stranou výhodu vašeho/tvého přístupu oproti jiným frameworkům (to by tu už bylo asi hodně OT), podstatné je, že tomu bych pak neřekl vývoj bez frameworku.

BoneFlute: Tak ony budou existovat věci, kde framework smysl fakt nedává. Dělal jsem třeba skript, který podle nějakých kritérií řadí řádky na vstupu. Něco jako /usr/bin/sort, ale s jinými kritérii řazení. Nečte to nic z cmdline, jen ze stdin řádek po řádku. Framework by tu asi ničemu nepomohl.

Na druhou stranu, hranice, kdy se nějaký vhodný framework vyplatí, může být i docela nízko.

8

Vývoj / Re:Framework vs. čistý kód

« kdy: 26. 07. 2025, 12:24:47 »

No PHP toho má spoustu v základní výbavě. Ale pokud se něco nezměnilo, i u jednoduchých aplikací se framework hodí:

1. Jednoduchý formulář funkční bez JS, s validací. Když data nejsou validní, zobrazit formulář i s daty. Kontrolovat, jestli skutečně dostávám string, nebo třeba pole. Možná ještě řešit CSRF. Prostě takové základní věci. Bez frameworku to je opruz a náchylné na chybu.
2. OK, dnes bychom mohli akceptovat, že potřebujeme JS, a bez něj formulář fungovat nebude. Poslat můžeme třeba i JSON, vrátit můžeme též JSON. Opět ale validace dat (a případně řešení CSRF) je bez nějaké aspoň jednoduché knihovny opruz.

9

Vývoj / Re:Framework vs. čistý kód

« kdy: 22. 07. 2025, 11:40:59 »

Priority mohou být různé, například:

1. Co nejrychlejší start.
2. Co nejmenší velikost binárky
3. Co nejdříve mít prototyp, na základě kterého se rozhodne, zda bude další vývoj, a kam se má ubírat.

V prvních dvou případech se může hodit (zejména u jednoduchých věcí) framework nepoužít vůbec, případně použít něco fakt malého. Třeba i za cenu složitějšího vývoje a zevrubnější kontroly, že jsem nezapomněl na nic z toho, co by za mě mohl řešit framework. Asi jde o celkem specifické případy, ale nastat mohou.

Ve třetím případě se naopak nejspíš vyplatí to udělat jakkoli, možná použít nějaký framework bez pečlivého výběru, prototyp nějak narychlo naprasit, a až bude zpětná vazba, třeba to celé zahodit a udělat od nuly s většími znalostmi. Jasně, není to platné za všech okolností, ale někdy to může být (i s ohledem na dostupné informace) ideální postup.

10

Vývoj / Re:Framework vs. čistý kód

« kdy: 20. 07. 2025, 12:21:08 »

Podobne, ako ked potrebujes nejaku kriticku apku, tak ides cim nizsie, aby si minimalizoval chybovost.

To bych obecně netvrdil. Framework i u malých věcí může řešit spoustu věcí, které by bylo potřeba řešit ručně, a u kterých jde nadělat spoustu různých chyb. CSRF, clickjacking, různé injekce, DNS rebinding, …

Pravda, ne každý framework vyřeší všechno, je dobré i tady mít přehled. Ale řešit to sám nemusí zrovna situaci zlepšit.

11

Software / Re:Stažené soubory s nesedícím md5

« kdy: 24. 06. 2025, 09:29:11 »

S vyloučením vlivu je to komplikovanější. Jendou jsem takto řešil náhodné restarty. Zkoušel jsem jiný zdroj, jinou MoBo a další. Nic nepomáhalo, indicie směřovaly k SSD a GPU (společný jmenovatel je napájení a PCIe komunikace, proti zdroj MoBo, a zvažoval jsem i CPU), pořád se nedařilo odhalit příčinu. Nakonec byl problém jak v SSD, tak v GPU. Někdy se prostě sejde více vadných věcí.

12

Vývoj / Re:If bez curly brackets?

« kdy: 22. 06. 2025, 15:22:45 »

Já mám ve zvyku používat složené závorky (bloky podle odsazení, jako má třeba Python nebo Scala, nechávám stranou) na explicitní vymezení bloku prakticky vždy. Výjimku může tvořit situace, kdy jde o zmíněný oneliner.

Dříve jsem to nedělal, kdysi dávno (dlouho před goto fail) mě to vypeklo, kdy při přidání dalšího příkazu (který možná jen dumpoval stav) omylem změnilo chování, protože jsem si neuvědomil chybějící {…}. (Pro přesnost: byl to Pascal, takže šlo o begin/end, nikoli o {…}, ale princip zůstává.)

Na druhou stranu podobné problémy může jít řešit i jinou cestou. Máme nástroje, které zformátují kód. Tytéž nástroje lze použít i ke kontrole, jestli formátování kódu odpovídá. Máme CI, které tyto nástroje může spouštět automaticky a kontrolovat kód po každém pushi. (A v některých případech ty problémy lze odhalit i zdánlivě nesouvisejícími nástroji, v případě goto fail tím vznikl unreachable code, nicméně to není univerzální řešení.) Lze obhájit nepoužívání {…} tím, že máme tyto nástroje? Možná, ale:

1. Pokud člověk jen bez kontroly zformátuje kód, mohlo by to projít. Pravda, u pull requestu by to mohlo bît do očí, a i pokud by to prošlo, nejspíš by to bylo odhaleno dříve.
2. Ač obvykle nechci nabádat k davovému chování, tady mi přijde praktičtější se davu držet a psát {…}, protože novému programátorovi to bude zjevnější. Naopak ve vynechávání nevidím moc výhodu.

Samozřejmě záleží na projektu. Například u one-man-show bez ambicí na dalšího vývojáře je větší prostor pro vystoupení z davu.

13

Software / Re:Stažené soubory s nesedícím md5

« kdy: 17. 06. 2025, 10:51:37 »

Pro porovnání dvou binárních souborů stejné délky tu je vbindiff. (U různé délky tuším padal.)

14

Hardware / Re:USB-C zdroj pro tři notebooky zároveň

« kdy: 17. 06. 2025, 08:39:50 »

Adaptér nikam nic netlačí

Jak se to vezme. Když dodá dostatečné napětí, může něco někam protlačit. Pokud se ale vše chová v souladu se specifikací, neměl by silnější adaptér vadit.

Ale baterie si bere "cucá", a adaptér to pouze omezuje podle nějaké nabíjecí křivky.

Adaptéru je nabíjecí křivka i baterie celkem ukradená. Ten prostě napájí na dohodnutém napětí a měl by schopen dodat dohodnutý proud bez přílišného poklesu napětí atd. Samotné nabíjení řeší pak až obvody připojeného zařízení.

Proto řešit nabíjení více podobných zařízení z jednoho adaptéru je systémový nesmysl.

Proč? Pokud bude takový adaptér zvládat 20 V na všech třech portech, zařízení dostanou, co potřebují. Pravda, takový adaptér bude dost možná mít tři separátní transformátory, aby byl schopen dodat různá napětí, a společné elektroniky pro všechny porty moc nebude.

Kromě toho USB-C je díky čipu dost chytré, ale s tímto zapojením specifikace nepočítá.

S čím přesně nepočítá?

15

Hardware / Re:USB-C zdroj pro tři notebooky zároveň

« kdy: 17. 06. 2025, 07:44:02 »

Bacha na jednu věc. Tyto víceportové zdroje schopné fungovat na více napětích (notebook asi nebudete krmit z 5 V) jsou komplikovanější a typicky při připojení nebo odpojení zařízení udělají restart. Pokud zařízení má funkční baterii, ustojí to, ale u starých notebooků v ľahu nevím.