Příspěvky

2431

Vývoj / Re:GitHub: fork vs. vlastní branch

« kdy: 06. 06. 2019, 08:08:30 »

K tomuto je tedy prosím určen fork?

Mimo jiné je určen i k tomuto, na GitHubu takhle najdete spoustu projektů, které už se v původním repository nevyvíjí, ale pokračuje nějaký jejich fork.

Na GitHubu se fork používá i v případech, kdy chcete do jiného projektu jenom přispívat – uděláte si fork projektu u sebe, tam vyvíjíte a když to máte připravené, dáte pull request na přetažení vašich změn do původního repository.

A pokud ano, půjde do něj namergovat nějaký ten bugfix z původní větve ?

Ano, půjde. Forky na GitHubu jsou standardní klony repository. Takže ve svém lokálním repository můžete mít jako vzdálené repository připojený svůj fork i původní repository, a commity, patche, branche atd. mezi nimi přetahovat, jak chcete.

Zvážil bych ale domluvu s původním autorem, že vám dá práva zápisu do svého repository, abyste mohl správu jeho projektu postupně převzít. U toho projektu mohou být otevřená issue, wiki, vedou na něj odkazy – vždy je lepší pokračovat v tom původním projektu, než dělat fork. Fork se dělá v případě, kdy původního správce nejde kontaktovat, nebo když se s ním nedá domluvit.

2432

Windows a jiné systémy / Re:Windows OEM licence - lze přeprodávat?

« kdy: 06. 06. 2019, 08:01:23 »

OEM licence je vázaná na počítač, se kterým je prodaná. Pokud nakoupíte samostatně OEM licenci v e-shopu, měl byste dostat licenci pro stavitele počítačů podle podmínek Microsoft OEM System Builder. Na základě toho pak přidáte licenci k vlastnímu počítači a ten počítač spolu s licencí jako celek prodáte koncovému zákazníkovi. Pak je vše v pořádku.

2433

Odkladiště / Re:mají E-Občanky revokační certifikát?

« kdy: 04. 06. 2019, 13:09:04 »

Záleží na tom, čemu říkáte „revokační certifikát“ – je to váš termín, který se nikde jinde nepoužívá.

Pokud myslíte možnost revokace certifikátu, to není vlastností certifikátu, ale certifikační autority. Každá certifikační autorita, která má být brána alespoň trochu vážně, vydává seznam revokovaných certifikátů.

Na české e-občanky si můžete nahrát komerční a kvalifikované certifikáty certifikačních autorit certifikovaných podle eIDASu, ty seznamy revokovaných certifikátů samozřejmě vydávají. Pak je na e-občance ještě identifikační certifikát, ten slouží jenom pro interní potřeby Ministerstva vnitra, takže tam existence veřejného seznamu odvolaných certifikátů není zajímavá.

2434

Server / Re:Ubuntu NTP: východ a západ slunce

« kdy: 03. 06. 2019, 11:59:52 »

Pro to zjištění v 1:00 použijte cron a pro naplánování spuštění příkazu použijte at – je to jednodušší a systémovější, než upravovat cron.

2435

Odkladiště / Re:Perfect Forward Secrecy i pro „asynchronní komunikaci“?

« kdy: 03. 06. 2019, 08:05:11 »

Neni to samozrejme Perfect Forward Secrecy, ale je to urcite zajimavy koncept toho, jak 'znahodnit' zpravu tak, aby stejny obsah, ktery je sifrovan pro stejneho prijemce vypadal po kazde jinak.

To je ale něco jiného, než PFS. I u běžného šifrování zpráv (např. e-mailů) pomocí PKI je zašifrovaná zpráva pokaždé jiná. Šifruje symetrickou šifrou s náhodně vygenerovaným klíčem, ke zprávě se připojí i ten klíč a jenom ten se zašifruje asymetrickou šifrou. Tím, že je šifrovací klíč náhodně generovaný, bude i identická zpráva zašifrována pokaždé jinak. A podle popisu ECIES mi připadá, že používá přesně stejné schéma šifrování, tj. pokud útočník získá privátní klíč příjemce, dokáže dešifrovat dříve přenesené zprávy.

Potkal jsem systemy zalozene na ECIES (napr. C-ITS pro car-to-car komunikaci), ktere dosahuji podobneho stavu jako u PFS tim, ze maji hodne agresivni rotaci klicu, tzn. prijemce ma nekolik paru klicu, ty se rotuji v ramci minut, takze pokud nekdo disponuje zachycenymi zpravami a ukradl vam nejake klice, tak dokaze desifrovat pouze velmi maly usek prenasenych dat.

To je pak ale FS zajištěna tou rychlou rotací klíčových dvojic, ne šifrovacím schématem. A mimochodem na tu rychlou rotaci klíčů bude potřeba dost entropie.

2436

Vývoj / Re:SW pro náhradu kódu

« kdy: 01. 06. 2019, 10:28:37 »

Refaktoring by to byl pouze v případě, kdy by se neměnila funkcionalita. Ta se však mění.

Že se mění funkcionalita kódu je vaše spekulace. Navíc ty nástroje se dají použít pro oba dva případy, protože mezi nimi neexistuje ostrá hranice – to, zda v daném případě jde nebo nejde o změnu funkcionality je věcí názoru. Kód má různé nezamýšlené vedlejší efekty (třeba už jenom to, jak dlouho se ve kterých situacích provádí). Nebo změníte chování v situaci, pro kterou funkce nebyla definována – a něco tím rozbijete, protože někdo na to nedefinované chování spoléhal.

2437

Vývoj / Re:SW pro náhradu kódu

« kdy: 01. 06. 2019, 08:52:21 »

Říká se tomu refaktoring a umí to každé lepší IDE. Nenapsal jste, o jaký jazyk jde, ale JetBrains mají IDE pro spoustu jazyků a patří ke špičce.

2438

Odkladiště / Re:Perfect Forward Secrecy i pro „asynchronní komunikaci“?

« kdy: 31. 05. 2019, 12:44:29 »

Tohle je ten zakopaný pes. Asi jen z historických důvodů mě zajímá, jestli tehdy bez PFC samotné šifrování probíhalo přímo asymetricky(klíčem byl přímo priv.klíč) a nebo symetrickou šifrou(která byla nějak dohodnuta  jinak pomocí Diffí Hellmana a  tudíž šla odvodit z zaznamenané komunikace.)

Samotná komunikace byla vždy šifrovaná symetricky.

-asymetrická šifra( RSA / Eliptické křivky), aby klient mohl ověřit autenticitu serveru

Autenticita serveru se ověřuje na základě podpisu certifikátu a toho, že server podá důkaz vlastnictví privátního klíče příslušejícího k certifikátu. Sice podpisy a šifrování fungují na podobných principech, ale doporučuju to nemíchat.

-algoritmus  pro vyjednání (tajného + volatilního ) šifrovacího klíče- Diffí Hellman (RSA / EC)

Bez PFS si kleint a server nešifrovaným kanálem vymění náhodná čísla a klient pošle serveru před-klíč zašifrovaný veřejným klíčem serveru. Z toho se pak vyrobí skutečný šifrovací klíč použitý pro (symetrické) šifrování komunikace. Pokud někdo šifrovanou komunikaci odposlechne a zaznamená, a později získá privátní klíč serveru, dokáže rozšifrovat ten před-klíč poslaný klientem a tím pádem má všechny informace, které měly k dispozici klient i server, dokáže odvodit použitý šifrovací klíč a komunikaci rozšifrovat.

Algoritmus D-H výměny klíčů je založený na tom, že během výměny klíčů pořád zůstává část, kterou zná jenom klient nebo jenom server a není to privátní klíč serveru. Takže i když si útočník komunikaci uloží a později získá privátní klíč serveru, pořád nemá dostatek informací, aby dokázal zrekonstruovat šifrovací klíč použitý pro šifrování komunikace.

- nějaká symetrická šifra (AES,RC4 slabá?) pro vlastní obsah

Těch variant je spousta, ještě se liší podle velikostí klíčů. Je to jeden z parametrů komunikace, který si na začátku dohadují klient se serverem. A taky jedno z potenciálních míst útoku, když se útočníkovi podaří některé nabízené algoritmy z komunikace odstranit a donutí tak obě strany, aby se dohodly na nějaké slabé šifře, kterou umí útočník zlomit.

druhý příspěvek sem nepatřil. Ptal jsem se i na " obyčejné forward secrecy".

Nic takového neexistuje. Resp. někdy se to používá jako synonymum pro PFS.

Není to jednoduché pochopit, co je zač, když to člověk nezná, navíc když je tam "popis šifry" 3x a a navíc Eliptická může být šifra i DH výměna, různé přípony způsobu řetězení bloků CEC,XTS. V chromu vidím zase kulový. Dřív to ukazovalo tohle, ale není to vidět ani v konzoli-Security ani u zámečku.

Pokud vás zajímá, jak funguje TLS, doporučuju The Illustrated TLS Connection.

Jinak u reálné komunikace zrovna webové prohlížeče do toho vstupuje ještě fakt, že (s HTTP/1.1) má prohlížeč typicky otevřených spojení několik, klíče rotuje docela často a navíc tak, aby je měl předem připravené – takže když má nějaký důvod komunikovat se serverem, používá starý klíč ale zároveň si bokem dohodne se serverem nový klíč, který použije příště. Což je zase umožněné díky tomu, že si klient se serverem mohou dohodnuté klíče uložit bokem a použít je při navazování dalšího TLS spojení, čímž se přeskočí úvodní handshake, který trvá docela dlouho. Takže když máte webový prohlížeč a snažíte se analyzovat jeho TLS provoz, není to vůbec jednoduché se v tom zorientovat.

2439

Odkladiště / Re:Perfect Forward Secrecy i pro „asynchronní komunikaci“?

« kdy: 30. 05. 2019, 11:48:01 »

SSL/TLS komunikace vždy používá pro šifrování přenášených dat symetrickou šifru. Klíče se vyměňují na začátku spojení a případně může později v rámci probíhajícího spojení dojít k výměně nových klíčů.

Předpokládám, že se ptáte na perfect forward secrecy. Standardní TLS komunikace je taková, že pokud si někdo uloží obsah šifrované komunikace a následně by se mu podařilo získat privátní klíč serveru, dokáže zpětně komunikaci rozšifrovat. PFC znamená, že když teď zaznamenáte tu šifrovanou komunikaci, bude chráněná i v budoucnosti, konkrétně v případě úniku privátního klíče serveru.

Princip PFC spočívá v tom, že se obě komunikující strany dohodnou na tajném klíči, které znají obě strany ale nedá se (ani se znalostí privátního klíče serveru) z té komunikace získat. Teoreticky byste to mohl použít i u asynchronní komunikace – obě strany by si nejprve vyměnily informace, aby mohly ustavit ten tajný klíč. Ale v praxi se to nepoužívá, není k tomu důvod. Privátní klíč, kterým dešifrujete e-maily, byste měl být schopen chránit mnohem lépe, než jak je chráněn privátní klíč třeba webového serveru. Server potřebuje ten privátní klíč při každém navázání TLS spojení, takže tam nemůže někdo sedět a pokaždé zadávat PIN, například.

DNSSEC s tím nijak nesouvisí, tam se nijak nešifruje, jenom podepisuje.

2440

Software / Re:Jak ignorovat NET::ERR_CERT_DATE_INVALID (tolerance data)?

« kdy: 30. 05. 2019, 11:26:18 »

O jaké DNSSEC klienty jde?

O všechny.

Ale chci mít možnost, aby to fungovalo i takto a ne že, když budu mít jiné datum, tak v rámci bezpečnosti "nenavážu ani bajt".

Že považujete za dobrý nápad střelit se do vlastní nohy, to je vaše věc. Ale nečekejte, že budou ostatní vymýšlet, jak byste to měl nejlépe udělat. Pokud chcete dělat hlouposti, musíte si na to přijít sám, jak je dělat.

je na to nějaký flag jako výše?

Nedá se vyloučit, že se to nějakému vývojáři hodilo pro nějaké jiné účely, tak si to pro sebe implementoval. Ale moc bych na to nespoléhal. Platí, co jsem napsal výše – když chcete dělat hlouposti, budete si to muset odpracovat sám.

2441

Vývoj / Re:Sběr dat, databáze

« kdy: 29. 05. 2019, 08:21:53 »

ja by som na to nesiel cez databazu. zbytocne citat z databazy kazdych par sekund z klientov je IT porno.
nedavno tu bol pekny serial o message brokeroch a neviem si predstavit lepsi priklad pouzitia ako toto.
zdroj dat to sype do topicu, 5 subscriberov to cita realtime a jeden subscriber to pise do DB.

To by ale mělo smysl jedině v případě, kdy klienti ta data mají zobrazovat neustále a více než jeden. Pokud je způsob použití jeden uživatel a „teď se chci na data podívat“ a pak „teď se na data chci zase podívat, ale sedím u jiného počítače“, budou se data v poměru k zápisům číst jen velice málo kdy.

2442

Vývoj / Re:Sběr dat, databáze

« kdy: 28. 05. 2019, 21:23:16 »

Dva a půl milionu záznamů za měsíc zvládne s prstem v nose jakákoli SQL databáze hodná toho názvu. Nicméně nepíšete tam nic o tom, že byste použil nějakých vlastností relačních databází, takže použít na to relační databázi bude nejspíš plýtvání zdroji – vhodná NoSQL databáze by asi to samé zvládla s nižšími náklady.

2443

Software / Re:Jak ignorovat NET::ERR_CERT_DATE_INVALID (tolerance data)?

« kdy: 27. 05. 2019, 08:37:51 »

Ještě doplním, že ověřování platnosti certifikátů (a tím pádem potřeba správného času) není jen záležitostí webových prohlížečů. Dnes spousta aplikací na pozadí komunikuje přes HTTPS, kde se zase ověřují certifikáty. Certifikáty se používají v DNSSEC, takže se zapnutou podporou DNSSEC a špatným časem se vám nebudou překládat domény používající DNSSEC. Certifikáty se používají pro podpis aplikací a ovladačů. Můžete je použít u SSH nebo VPN. Zkrátka mít na počítači nastavený špatný čas je špatný nápad a hlášky prohlížeče jsou jen vrcholek ledovce.

2444

Software / Re:jak ignorovat NET::ERR_CERT_DATE_INVALID (tolerance data)

« kdy: 26. 05. 2019, 11:17:20 »

Každý certifikát má nastavené nějaké období, během kterého je platný. Je to z důvodu větší bezpečnosti – bezpečnost certifikátů jednak závisí na tom, že neunikne privátní klíč, jednak na tom, že použitý algoritmus je dostatečně odolný. Jenže v algoritmech se nalézají chyby, a také neustále roste výkon počítačů, takže co bylo před pár lety nemožné louskat hrubou silou, dnes už je prakticky proveditelné. Proto se v počítačové kryptografii všude počítá s omezenou platností podpisů (a tím i certifikátů).

Další problém je, že u certifikátů se ověřuje, zda nebyly odvolány. A odvolání certifikátu je zase určené časem. Když si posunete čas dozadu, může se stát, že útočník získá privátní klíč, právoplatný majitel to zjistí a certifikát odvolá – váš prohlížeč by mu ale dál důvěřoval, protože k odvolání by podle něj mělo dojít až v budoucnosti.

Jedná se „jenom“ o varování klienta – klient při navázání spojení kontroluje, zda jde o platný a důvěryhodný certifikát. A certifikát je platný jenom v období, které je v něm nastavené – přičemž klient nemá lepší zdroj aktuálního času, než jsou hodiny počítače^*). Když potlačíte varování klienta o tom, že certifikát je mimo dobu platnosti, může vám útočník podstrčit starý certifikát, od kterého nějak získal privátní klíč – buď si na něj jeho vlastník nedával pozor, protože byl od starého certifikátu, nebo byl použitý nějaký slabý algoritmus, a útočník dokázal klíč upočítat. (Ta druhá varianta by v moderním prohlížeči neprošla, protože prohlížeče odmítají i certifikáty se slabými algoritmy). A nebo může nastat ta třetí nejhorší varianta – certifikát by byl ještě platný, ale byl odvolán, protože je podezření na únik privátního klíče – ale váš prohlížeč bude v klidu, protože k odvolání dojde až v budoucnosti.

Když dáte u wgetu --no-check-certificate, určitě se nekontroluje, zda je certifikát od důvěryhodné autority, je možné, že se nekontroluje ani datum platnosti certifikátu a nejspíš ani shoda jména na certifikátu se jménem serveru. Takže komunikace je sice šifrovaná, ale možná komunikujete hezky šifrovaně s útočníkem, protože vám podstrčil svůj certifikát.

Nevím, jestli jde tahle kontrola potlačit v Chromiu – ono to obecně není moc dobrý nápad umožnit neznalým uživatelům tyhle kontroly potlačovat, protože uživatel se chce hlavně dostat na web, tak odklikne cokoli, a je mu jedno, že se připojuje na web útočníka. Nejlepší je nehrát si se systémovým časem a mít ho seřízený podle skutečného přesného času.

*) Resp. jak je vidět z té hlášky, Chromium si asi v případě nesouladu ověří čas i odjinud, ale nedělá to pro každý certifikát, protože by to zpomalovalo načítání stránek. A ten čas zjištěný odjinud použije jen pro správnou formulaci chybové hlášky, nepřebije to systémový čas použitý pro validaci certifikátu.

2445

Vývoj / Re:Jak mam programovat v Node.js?

« kdy: 26. 05. 2019, 06:37:12 »

co vám vadí na js ekosystému v roce 2019? Podle mě se ten ekosystém už dávno stabilizoval. Je stejně stabilní, ale mnohem modernější než java ekosystém. npm už také funguje bez problémů.

Chtěl jsem vám to věřit, ale pak se mi v timelině objevilo toto: https://twitter.com/lukejacksonn/status/1131506699356037121

Jinak ale pokud někdo chce programovat jako v Javě, ať programuje v Javě – programovat jako v Javě v něčem jiném nedává smysl, to nemůže dopadnout jinak, než že bude dotyčný nespokojený. Výhoda existence více programovacích jazyků je právě v tom, že jsou různé, každý se hodí na něco jiného, jiný způsob práce a pro jiné programátory. Nedávalo by smysl mít dva jazyky, které budou stejné.