Příspěvky

136

Odkladiště / Re:Proč bitcoin?

« kdy: 09. 11. 2015, 22:15:09 »

Můžou ale, pokud vím, dělat kejkle s adresami, od kterých klíč vlastní.

A co by s nimi jako měly dělat?

Ano, napsal jsem to špatně, omlouvám se. Nejde o staré bitcoiny, ale o transakce, čili spíš "nové bitcoiny". Pokud vznikne zmatek, co jsou "platné" transakce v "platném" blockchainu (což byl předpoklad, ze kterého jsem vycházel), uskuteční se nutně ve "špatném" blockchainu transakce, které nebudou mít žádný dopad. Čili pokud budu mít za to, že A je ten správný blockchain, prodám motorku za BTC a transakce se objeví v blockchainu A, ale nakonec zvítězí blockchain B, tak potom si můžu ty BTC v A okuřovat na tom oltáříčku.

Proto se v síti čeká na určitý počet potvrzení. Takových 6 bloků v novém blockchainu je dostatečnou jistotou, že žádný paralelní blockchain neexistuje. Pokud máte podezření, počkejte déle. třeba 20 potvrzení.

To ano, ale vesměs všude se dá v takovém případě dopad nějak eliminovat. Nehrozí, že by např. člověk přišel o peníze v bance. Přinejhorším by se prostě přešlo na papírové knihy jak to bylo dřív U BTC tohle jednak z principu nepřipadá v úvahu, jednak není žádná autorita ani proces, kterým by se dalo rozhodnout, jak postupovat dál.

Na rozhodnutí nemusí být žádná autorita. Stačí jeden člověk s dobrým nápadem, který ostatní uznají a začnou se jim řídit.

A to by třeba docela stálo za průzkum, kolik lidí používá BTC takhle "správně"

Drtivá většina peněženek to už tak dávno dělá, díky vynálezu deterministických klíčů, kde jedna peněženka může deterministicky dopočítat až 4 mld adres na jeden účet. A díky chytrým lidem jako je Slush, který sepsal a zrealizoval patřičné BIPy to už dneska dělají všechny peněženky stejně a uživatel to nemusí řešit, jen si udělá zálohu v podobě počátečního seedu. Bitcoin Core to dělá od začátku, dále máme Electrum, Multibit HD, Mycelium, dokonce i klasický androidí Bitcoin Wallet tuším že přešel na deterministické peněženky, no a samozřejmě HW peněženky, jako Trezor. Myslím si, že s tímhle arzenálem je obtížné používat bitcoiny na jedné adrese "postaru"

Bavíme se o hypotetických rizicích na úrovni zlodějské měnové reformy. Čili ne o něčem, co známe, ale o něčem, co si v nejhorší noční můře umíme představit, že by mohlo nastat.

Třeba že zemi rozdrtí meteorit. Hypoteticky.

Jde o to, jaký chaos je možné v BTC síti vyvolat. Že by se to časem nějak ustálilo, o tom není pochyb. Jde o to, že na momentáním chaosu by se mohl slušně napakovat ten, kdy by ho uměl vyvolat, očekávat a byl připravený ho využít.

Takovejch chaosů už bylo a minera nic nerozhází. Ten má svých 25 BTC za blok jistejch.  To by bylo sakra drahé aby se něco začlo dít.

137

Server / Re:Protokol mezi proxy a backendem

« kdy: 08. 11. 2015, 15:12:05 »

Navazování nového spojení pro každý požadavek je zbytečné i v serverovně, i když je to rychlejší než od klienta k proxy serveru. Proxy server ale může mít to jedno spojení k backend serveru otevřené mnohem déle, klidně celý den. Navíc přenášet víc požadavků jedním spojením umožňoval už protokol HTTP/1.1, HTTP/2.0 k tomu přidává „jen“ paralelizaci.

To už právě funguje teď i na HTTP/1.1. Samozřejmě není problém mít keepalive on a otevřeno třeba 10, 20 nebo 100 spojení... Ona ta výhoda HTTP/2.0 v paralelizaci je dost diskutabilní, a funguje jen díky praktickým, často umělým, problémům. Jinak si myslím, že TCP zvládá paralelizaci lépe. On si to uvědomuje i Google, když přichází i s UDP verzí HTTP, kdy si implementuje i celý vlastní stack. To se ukazuje, že pro rychlé HTTP se nehodí ani samotné TCP zejména díky struktuře síťové komunikace.

To že paralelizace funguje v HTTP/2.0 za to můžou dva faktory. První je umělý limit na počet HTTP/1.1 spojení per klient doména. Mám pocit, že se to ustálilo na hodnotě 2 (bývalo to i 11). Dalším problémem je slowstart na TCP při navázání nového spojení. To se děje celkem často jak prohlížeče šetří otevřené konekce.

Chtěl jsem poradit zda neexistuje jednoduché řešení spojení proxy = backend. Protože já vidím hlavní výhodu právě v proxy, která dělá SSL a tu paralelizaci z různých zdrojů poskládáných nejen ze statických souborů, ale třeba i z vícero backendů současně. Navíc dělá load balancing. Zatím jsem řešení nenašel ani na google. Nginx nabízí v zásadě jen fastcgi a proxypass. Leda si napsat vlastni modul do nginx, ale to mi prijde moc prace.

138

Server / Re:Protokol mezi proxy a backendem

« kdy: 08. 11. 2015, 11:40:00 »

Protokol HTTP/2.0 nemá povinné šifrování. Pokud mezi proxy a backendem je bezpečná síť, je to jeden z mála případů, kdy dává smysl použít nešifrované HTTP.

Jinak je samozřejmě lepší mezi proxy a backendem použít HTTP/2.0 – jednak tak můžete využít novinky HTTP/2.0 i pro komunikaci s klientem (třeba server push – je lepší to řešit na backend serveru, než přidávat logiku na proxy), jednak z toho mohou těžit i HTTP/1.1 klienti (díky server push může mít proxy server příslušný soubor už v cache, až o něj klient požádá).

No mě na tom nesedí jakou má to mít výhodu HTTP/2.0 je primárně multiplexovaný a optimalizovaný na přenosy po dlouhé lince a mnoha souborů naráz. Je nutné si představit, že uspořádání v serverovně asi takhle vypadat nebude. Zpravidla na každou konekci bude zároveň jedna konekce na backend a spoustu statického obsahu. Vidím tu výhodu, pokud multiplexování bude provádět proxy (nginx), která to v zásadě musí umět.

Teď jsem se díval, že W3C má nový atribut Link preload (http://w3c.github.io/preload/) i jako http hlavičku. Nginx v Http/2.0 ho umí rozpoznat a zařídit tak push. Což mi přijde jako celkem rozumný nápad - a samozřejmě to zvládne i nacachovat za předpokladu, že bych chtěl preloadovat dynamický obsah. Spíš ale vidím výhodu v preloadu statického obsahu (obrázky, styly, javascript)

Takže zatím to vypadá, že jsem si odpověděl sám.

139

Server / Protokol mezi proxy a backendem

« kdy: 07. 11. 2015, 21:48:32 »

Zdravím.

Řeším takovou otázku která mě možná začne trápit v blízké budoucnosti. Vzhledem k nastupujícímu trendu provozovat všude HTTP/2.0 a šifrování, řeším, jak dále vyvíjet mé backendy psané v C++. Doposud jsem používal uspořádání nginx -> proxypass -> backend(http/1.1). Je výhodné, zejména nginx řeší třeba SSL, zajišťuje jakousi izolaci, například ochranu proti různým exploitům typu slowloris, dále pak propojení statického obsahu s dynamickým a mapování cest a jinak do vlastní komunikace moc nekecá, hlavičky se předávají v zásadě 1:1, takže zbytek má v rukou sám backend.

Na co se mám připravit v případě http/2.0? Jasně, předpokládám, že nadále bude proxypass nějak emulován, takže s tím asi vydržím, ale neumím si tam představit nové featury, jako server push. Na druhou stranu mi nepřijde rozumné tu komunikaci provozovat plně na HTTP/2.0, jednak bych musel šifrovat, a pak nginx stále bude v roli míchání statického obsahu s dynamickým, takže 1:1 by to asi nešlo.

Jaké jsou další možnosti? Zkoumal jsem FastCGI, ale ten protokol mi přijde velice odporný, chybí mu jednoduchost běžného http Chystá se nějaká lepší alternativa?

140

Studium a uplatnění / Re:Seznam.cz - jaký je zaměstnavatel?

« kdy: 21. 10. 2015, 16:39:58 »

Docela to jde, a platěj včas.

Já tam byl jako vývojář z mého pohledu se admini věčně flákají, takže to asi musí být dobrá zašívárna 

141

Server / Re:Groupware na Linuxu s ActiveSync

« kdy: 21. 10. 2015, 16:34:34 »

Pouzivame Zentyal. Activesync chodi vyborne, desktopovy outlook trochu drhne, zvlast kdyz se do toho naimportuje obrovsky mailbox pres imap nebo ze stareho ost. Ale delaji na tom velice aktivne a zrovna zitra vychazi 4.2, do ktere slibuji velky pokrok v openchange (exchange konektor), tak jsem zvedav.

No vypadá to ideálně, ale není. Bohužel - doufám tedy, že nová verze bude nějak fungovat. Věnoval jsem tomu celé odpoledne. Nainstaloval jsem ve virtuálu přimo samotné iso i s Ubuntu. Virtuál jsem vystavil na naši lanku, takže má IP adresu, dokonce DNS záznam. Založil pár uživatelů, a vyzkoušel, že se ve Webmailu přihlásím. Potud ok. Jenže se neumím přihlásit Thunderbirdem na IMAP (ale na POP3 to jde - našel jsem na nějakém tracu rok starý ticket popisující stejný problém). Samozřejmě Android Outlook nefunguje, protože prý nastala nějaká chyba. Navíc je to celý strašně pomalý, celý virtual si sežral jedno celé jádro, na to, že tam nic není, a nic nedělá.

(Povzdech). Bohužel osud drtivé většiny open-source projektů. Nejsou production ready. Přitom na stránkách nabízí komernční verzi, to bych si dal.

142

Server / Groupware na Linuxu s ActiveSync

« kdy: 21. 10. 2015, 12:00:05 »

My linuxáci máme život jednoduchý, posíláme si maily z terminálu, kecáme na jabberu, občas si vystačíme s gmailem a tickety píšeme do tracu.

Jenže jakmile vám do vaši práce začnou mluvit obchodníci, chtějí svůj standard. Tedy ideálně outlook, kde si mohou navzájem posílat úkoly, pozvánky na schůzky, kalendář s programem na další tři měsíce, a podobně, znáte to.

Problém třeba je, že jsem jim to rozchodil přes google, ale bylo mi řešeno, že omalovánky gmailu jsou jak pro puberťáky, že tohle se nedá použít pro profesionální práci... chápejte, prostě outlook a synchronizace do všech zařízení, které obchodník má.

No a další požadavek  je, aby instalace byla stupid easy. Co jsem vyzkoušel (Zimbra, Sogo) tak je to na dlouhé zimní večery hrát si s konfigurákem. Navíc některé projekty chtějí úplně nesmyslné požadavky. Například už během instalace chce Zimbra nebo Kolab FQDN a MX záznamy v DNSku. Já to první chci vyzkoušet ve virtuálu, i kdybych měl do klienta psát číselné adresy. Nejsem admin, nemám po ruce pět šest fyzických strojů s pevnou IP adresou a DNS záznamem. Potřebuju najít řešení o jehož finální nasazení (alokace stroje, přístup k DNSkám, nastavení infrastruktury) se bude muset ještě rozhodnout na vyšších místech

Máte zkušenosti s něčím funkčním, co třeba používáte u vás ve firmě?

143

Vývoj / Re:Vizualizace kryptografického otisku (Hashe)

« kdy: 16. 10. 2015, 22:34:22 »

Mezi námi, zkonstruovat hash tak, aby se lišil v jednom bajtu nebo dokonce bitu je docela obtížné, nebo nemožné. Princip hashe by měl být, že malá změna způsobí že vyjde naprosto jiný hash, který se nepodobá ničemu.

Když to vezmu do důsledků pokud předložím uživateli dva hashe, které se liší v jednom písmenku, většina si toho nevšimne. Nikdo nebude kontrolovat, že jsou všechna písmenka stejná. Když kontroluju správnost bitcoinové adresy, koukám jen na první čtyři a poslední čtyři znaky. Taky hlavně proto, že spoléhám na interní checksum, který by překlep v jednom znaku měl  odhalit (on by měl odhalit i překlep ve více znacích, když má vyhrazeny celé 4 bajty)

Když budu dělat podepisování tajným klíčem v dedikovaném zařízení, třeba v mobilu, nebo v Trezoru, mohu na display zařízení zobrazit celou zprávu, kterou podepisuju. To funguje do té doby, dokud jde o krátkou zprávu. Jak podepíšu dokument ve Wordu?

Smyslem ochrany má být, že uživatel nahraje dokument, zobrazí se mu hash a adekvátní obrázek. Měl by si samozřejmě spočítat hash bokem a ten obrázek taky vygenerovat. Věří webové stránce, že to udělá správně. Pokud ale technika podpisu probíhá přes třetí stranu, chce mít uživatel pocit, že to so v zařízení odsouhlasí je skutečně ten dokument, který na stránku uploadoval. Bez zobrazení samotného dokumentu mu zbývá zobrazit otisk, tedy celý hash a porovnat jej s tím co mu vyšlo při vkládání dokumentu. Tak má jistotu, že nedošlo k pozměnění požadavku cestou. Má to pokrýt nejjednoduší způsoby hacknutí. Těžko někdo bude k právě vloženému dokumentu provádět hledání hodně podobného hashe, když je to mnohdy operace na několik let či staletí.

Mimochodem, když člověk nahrává dokument do nějakého systému veřejné nebo poloveřejné zprávy (třeba pojišťovna) mnohdy tam sedí Active X, podepisuje privátním klíčem certifikátu a zobrazuje SHA-1 Hash místo obsahu dokumentu a čeká, aby to uživatel odbouchnul. Tomu nic nezbude a doufá, že podepsal opravdu ten dokument, který chtěl podepsat,

144

Vývoj / Re:Vizualizace kryptografického otisku (Hashe)

« kdy: 16. 10. 2015, 17:18:44 »

QR kód hashe z hashe? Pokud ten telefon dokáže zobrazit "obrázek", tak má s největší pravděpodobností i foťák.

No právě že já nemám problém přenést ten hash do telefonu právě pomocí QR kodu. Ja to potřebuju proto, aby uživatel měl jistotu, že oskenoval správný kód, že tedy podepisuje (ano, jde o DSA, přesněji o ECDSA, napřiklad bitcoinovou transakci, nebo nějaký kritický příkaz na webové aplikaci, třeba smaž všechny fotky v galerii) to co vidí na obrazovce

145

Vývoj / Re:Vizualizace kryptografického otisku (Hashe)

« kdy: 16. 10. 2015, 17:00:35 »

Stromeček byl jen příklad. Já samozřejmě dál prohledávám googla a našel jsem popis toho, co je v ssh, tedy algoritmus "ožralého kněze" který generuje ty známé obrázky v SSH

Kód: [Vybrat]

+--[ RSA 2048]----+
|             o . |
|         . .o.o .|
|        . o .+.. |
|       .   ...=o+|
|        S  . .+B+|
|            oo+o.|
|           o  o. |
|          .      |
|           E     |
+-----------------+ 

Blbý je, že je to definované pro asciiart a já mám k dispozici víc, minimálně canvas v javascriptu. Ale dalo by se to použít. Nebo z toho vyjít. Beru to jako poslední možnost. (další věcí je, že já používam SHA256, která má 32 bajtů - ale mohl bych ji zahashovat ještě třeba MD5

Napadly mě nějaké fraktály, ale zrovna nemohu najít žádný rozumný. Taky je problém právě s tím, že by každý hash měl generovat opravdu jiný obrázek, na první pohled rozpoznatelný, že je jiný. A pokud to někde bude generovat podobné obrázky, aby nešly jednoduše forgnout, tedy aby útočník neměl možnost snadno vygenerovat takový otisk (třeba hrubou silou), který bude podobný tomu co uživatel vidí. Takže trošku i bezpečnostní problém

146

Vývoj / Vizualizace kryptografického otisku (Hashe)

« kdy: 16. 10. 2015, 16:19:12 »

Chtěl bych nějak vizualizovat kryptograficky otisk (hash) zprávy. Nějak pěkně graficky, aby uživatel snadno na první pohled dokázal porovnat dva otisky a snadno se přesvědčit, že jsou stejné. Neměl by někdo nějaký nápad? Třeba nějaké náhodné malování na canvas?

Příklad, když uživatel uvidí na obrazovce obrázek divného stromečku a na mobilu stejný obrázek divného stromečku (tedy vygenerovaný obrázek), pochopí, že na mobilu má stejný otisk jako na obrazovce počítače.

Ideálně by bylo, aby se jednalo o kresbu, nejlépe monochromatickou. S barvama je potíž, lidi bejvají barvoslepí.

Nějaké fraktály? Ale zase aby se to počítalo rychle, ideálně v JS

147

Odkladiště / Re:Proč bitcoin?

« kdy: 27. 08. 2015, 01:24:44 »

Protože pro bitcoin neplatí Systém částečných rezerv, chová se to jako Zlatý Standard

Systém částečných rezerv by mohl fungovat i se zlatem i s bitcoiny - prostě si do banky uložíš deset BTC, banka z nich jeden nechá v depozitu a devět půjčí.

Od zlata se BTC podstatně liší tím, že nemá tradici. Když za platidlo prohlásíš tebou posmrkaný kapesníky, tak jich sice taky bude omezený množství, ale přesto to "jako zlato" nebude. Stejně tak BTC. Podobnost se zlatem je spíš přání otcem myšlenky než realita.

Částečné rezervy nejsou největším problémem, to je jen statistický problém (pravděpodobnost, že se banka dostane do platební neschopnosti). Problém je multiplikace depozit, k níž ve zlatém (fyzickém, tj. s oběhem plnohodnotného platidla, nestačí platidlo kryté zlatem) ani bitcoinovém systému docházet nemůže. A v systému s omezeným množstvím oběživa (omezeným jinak než ekonomickými potřebami) je zásadní problém s úroky – chovají se jako Cimrmanův důlní výtah: po určité konečné době by se nutně všichni horníci postupně nahromadili v dole; stejně tak úroky by způsobily, že nakonec by veškerý majetek této planety po určité době skončil v rukách nějaké jedné megabanky. Proto taky v dobách, kdy se používala plnohodnotná platidla, byly úroky zakázány a přísně trestány.

Tahle podivná úvaha by platila jen v případě, že by si věřitel ty úroky nechával v nějakém trezoru kde by je hromadil. Jenže proč by to dělal? Věřitel půjčoval proto, aby vydělal na úrocích a ty peníze posléze použil k vylepšení svého života nebo socialního statutu. Takže všechny úroky použije k nákupu statků a služeb a ty peníze se zpět vrátí mezi dlužníky a oni mohou s nima znova zaplatit další úroky a tak dokola.

148

Windows a jiné systémy / Re:Svchost.exe vyžiera cpu (windows update) na Windows 7

« kdy: 15. 08. 2015, 17:27:30 »

Zkusil bych na systémovém disku zavolat cleanup utility (vyčistit disk), souhlasit s vyčištěním systému (UAC) a pak to někde nabídne odstranění starých aktualizací.

Jinak ten proces normálně zabít, on se spustí znovu.

149

Hardware / Re:Co se děje při přejmenování souboru?

« kdy: 15. 08. 2015, 12:33:39 »

Diky. Je to pro me trochu prekvapive. Myslel bych si, ze pri delsim novem nazvu nebo presunu do jineho adresare, dojde k preskupeni (realokaci) dat.

Jen bych jeste dodal, ze fyzicky se to vlastne nemaze.

V ext3 je soubor uložen pod číslem, a ne pod jménem. Říká se mu inode. Jméno není nic jiného, než záznam v adresáři, že se váže k nějakému inode. Přejmenování, či přesunutí v rámcí filesystému tedy neznamená nic jiného, než vytvoření nového záznamu se stejným odkazem na inode a smazání starého záznamu, přičemž soubor stále existuje pod stejným inode, tam se nic nemění.

Takhle to funguje i ve FAT. Tam je místo inode číslo prvního sektoru, kde se soubor fyzicky na disku nachází. Další číslo sektoru si pak OS odvodí právě z tabulky FAT, podle níž byl tento filesystem pojmenován.

Při přesunu na jiný filesystém je ovšem nutné soubor fyzicky zkopírovat a následně na původním místě smazat. Během této operace tedy soubor částečně existuje na dvou místech současně, což může být problém.

150

Sítě / Re:Reset IP koupeného AP

« kdy: 05. 08. 2015, 20:28:32 »

Křížený kabel je pitomost.

Nevím jak tento, ale některé routery mají zdířky označené LAN a WAN. LAN se připojuje nekřížený. U WAN se předpokládá, že se spojí s dalším routerem, takže jsou výstupy k tomu přizpůsobeny, tam by pak mělo smysl uvažovat o kříženém kabelu, pokud bych o připojoval k PC. Ale proč bych to dělal?

Normální je snad dneska to, že si to ty vstupní obvody u síťovek zjistí, ne?