Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Ovrscout

Stran: 1 2 3 [4] 5
46
Vývoj / Re:Obdoba RCS $Log$ v gitu
« kdy: 17. 03. 2017, 18:09:42 »
K radám ostatních připojím že by mohlo dobré použít ty git hooks, aby po commitu/checkoutu vytvořili soubor který bude obsahovat hash commitu, případně název větve. Ten soubor by nebyl přímo součástí commitu (.gitignore), a případně by ho bylo možno includovat z těch skriptů pokud bys to potřeboval vypsat skriptem. Mělo by to být jednodušší něž použití filtrů a s obdobným výsledkem.

Len ci bude git commit hook naozaj jednoduchsi ako tieto dva smudge/clean filtre?

Filtre menia placeholder @VER@ na @VER: 4987f2d@ tak, ze sa vypali priamo do skriptu pri checkout-e.
(Navyse clean filter sa da vynechat, pokial bude repo na jednotlivych strojoch namiesto fast-forward mergu hard resetovane na remote tracking upstream, t.j. git fetch && git reset --hard @{u} && git checkout -f)
Kód: [Vybrat]
$ echo "Zaciatok definicie filtrov"
Zaciatok definicie filtrov
$ git config filter.verzia.smudge 'sed -e "/@VER@/{ s/@VER@/@VER: %h@/g; s/.*/git log --pretty=\"&\" -1/e }"'
$ git config filter.verzia.clean 'sed -e "s/@VER: [[:alnum:]]\{7\}@/@VER@/g"'
$ echo "*.py filter=verzia" >> .gitattributes
$ echo "Koniec definicie filtrov"
Koniec definicie filtrov
Overenie funkcnosti
Kód: [Vybrat]
$ echo -e "# Verzia @VER@\nprint 'Tato verzia je @VER@'" > example.py
$ git add .
$ git commit -m 'Pridane filtre pre python'
$ rm example.py
$ git checkout example.py
$ python example.py
Tato verzia je @VER: 4987f2d@
$ cat example.py
# Verzia @VER: 4987f2d@
print 'Tato verzia je @VER: 4987f2d@'
$ git status -s
$ echo "Clean filter funguje"
Clean filter funguje

moc pěkné a jednodušší něž bych čekal :)

47
Vývoj / Re:Obdoba RCS $Log$ v gitu
« kdy: 16. 03. 2017, 22:52:04 »
K radám ostatních připojím že by mohlo dobré použít ty git hooks, aby po commitu/checkoutu vytvořili soubor který bude obsahovat hash commitu, případně název větve. Ten soubor by nebyl přímo součástí commitu (.gitignore), a případně by ho bylo možno includovat z těch skriptů pokud bys to potřeboval vypsat skriptem. Mělo by to být jednodušší něž použití filtrů a s obdobným výsledkem.

Taky by šlo použít pro deployment samotný git (případně ve spolupráci s hook scripty) a zjišťovat příkazem (viz trupik).

Případně se dá použít opačná logika. Ve chvíli kdy se rozhodneš uvolnit verzi tak spustíš nějaký vlastní skript s případným "pěkným" číslem verze jako parametrem  - nebo si na to napíšeš logiku do skriptu. Zkontroluje se že je workingdir čistý, a číslo verze se přilepí jako štítek k commitu, pak se vytvoří se balíček pro deployment. Součástí přípravy může být právě "vypálení" označení verze včetně hashe do některého ze souborů. Balíček se uloží někam bokem, a případně se rozdistribuje kam je potřeba. Je mi jasné že na menší věci je to tak trochu kanón na vrabce. Ale zase se to může hodit pokud jsou v pracovním adresáři i nějaké "pomocné" či konfigurační soubory které by se neměli dostat ven, nebo naopak pro deploy je potřeba je nahradit jinými. A mít pěkně připravené balíčky(třeba zip soubory) má něco do sebe.

48
Vývoj / Re:Obdoba RCS $Log$ v gitu
« kdy: 16. 03. 2017, 21:22:13 »
Pokud se chces priucit git doporucuju publikaci progit, je tam celkem srozumitelne vysvetleno jak to funguje a co od toho lze čekat (hlavně kapitola 1.3). Git tak trochu mění pohled na verzování místo verzování souborů, na verzování projektu. Možná z počátku to zní podivně, ale díky nástrojům které má se s tím pracuje dobře, např "blame" a velmi silná práce s větvemi. Číslování verzí je ale tak trochu vyjímka :)

Dobrá ale trochu starší verze knihy v češtině (s některými, .. trochu zvláštními překlady pojmů) https://knihy.nic.cz/
Nebo v originale(novejsi) https://www.git-scm.com/book/en/v2

Pokud jsi pročet alespoň pár prvních kapitol tak už asi odpovědi znáš :) ,ale :
Commit je určen tzv hashem, jeho zkrácená podoba se dá použít pro určení verze. Ke commitu (vlastně k tomu hashi) se dá přilepit pěkné číslo verze pomocí štítku - "tag". Ale automatické číslování souborů ve smyslu 1.1,1.2 atd se tu moc nepoužívá. Je to hlavně proto že git je hodně silný v používání větví "branch" a to i dočasných, kde je pak s automatickým číslováním poměrně problém.

Nicméně, pokud je to potřeba git umožnuje spouštět skripty při různých příležitostech, commit, checkout,.. a je tak možné provádět různá kouzla(Git Hooks).



49
Server / Re:RapidSSL a Android
« kdy: 13. 01. 2017, 13:32:48 »
Dobře se tychle věci testují přes tuhle stránku: https://www.ssllabs.com/ssltest/analyze.html?d=www.max24.cz&latest
"Chain issuess: Incomplete" - Tj, bude to tak jak psal Filip Jirsák:
Těžko říct, když jste nedal odkaz na ten váš web. RapidSSL používá intermediate certifikáty podepsané CA GeoTrust, ta v Androidu je. Předpokládám, že váš server posílá jen samotný certifikát, bez intermediate certifikátu CA a Android ten intermediate certifikát nemá, takže nedokáře najít cestu k tomu důvěryhodnému kořenovému certifikátu. Prohlížeče mají i ten intermediate certifikát, takže si cestu najdou.

50
Když jde o SD karty, je třeba dohledat pořádné pdf. Pokud karta má alespoň nějaký wearleveling, tak se tam výrobce nezapomene pochlubit - alespoň heslovitě. Pokud pdf není, tak to karta pravděpodobně neumí, hlavně bacha na to že výrobci mají více řad karet a ne všechny mají stejné parametry :)
Alespoň základní Pdf se dají překvapivě sehnat u výrobců, případně v některých eshopech(farnel třeba).

Druhá věc je, že jednou za čas je potřeba data obnovit. U hloupých karet je třeba přepis, u lepších stačí data přečíst a karta si to případně obnoví sama. Samostatně to umí jen některé karty.
U všech je ale potřeba aby karta byla zapnutá. Pokud je karta rok vypnutá, tak je(v závislosti na počtu přepisů) velká šance že se nějaká data poškodí.

Obecně SLC vydrží víc, ale schopné MLC je levnější a pokud je zařízení trvale zapnuté a trochu se poladí, tak také postačí.

51
Jistě, paranoia je jeden z důvodů proč o tom přemýšlet :)
Já ale nad tím přemýšlím spíše pro zhodnocení poměru cena/výkon. Přeci jen je fyzický "token" pro používání trochu nepohodlný. A pokud jeho používání není výrazným přínosem k zabezpečení - v porovnání s ověřením přes SMS které mám teď. Tak není důvod na něj přecházet.


52
Chapu, kam tim miris, bohuzel ta myslenka ma zasadni nedostatek. Token je offline a dost hloupe zarizeni (na urovni obycejne kalkulacky). Pro vstup (PIN) generuje hash (jednorazovy kod) a tento kod musis rucne prepsat do bankovnictvi.

Pripadny utocnik i kdyby vygeneroval transakci, musel by uhadnout kod ktery server prijme a ten bez znalosti pinu a pouzite hashovaci funkce neuhadne.

Mno nevim jestli ti úplně rozumím ale takto jak to popisujes jsem si to představoval původně než mně tu pánové opravili.

tj:
Zadám pin, vygeneruje se nějaké jednorázové heslo které se zada do web formulare. Tam to prevezme malware(v prohlížeči/PC), a misto transakce kterou mi ukazuje odesle transakci podvodnou. A je vymalováno.
(To je v podstatě stejné jako při použití SMS , tam ale musí být mallware jak na PC, tak na mobilu, což je o fous těžší a tudíž i o fous bezpečnější)

Alternativně s tokenem - ala čipová karta, mallware(v prohlížeči/PC) sice zobrazuje co uzivatel zadal ale pri odeslani k podpisu do tokenu/karty předhodí podvodnou transakci, to už uživatel nikde nemůže vidět protože ten token/čipová karta nemá žádný displej, takže jen zadá pin a tím to podpíše. Následně malware dokončí falešnou transakci. A je vymalováno.

Pokud jde ale o situaci tak jak ji popsali Filip Jirsák a Pako, kde jde o token v podobě extra krabičky s displejem/klávesnicí takže uživatel nezávisle na  potenciálně zavirovaném PC vidí a/nebo zadává údaje o transakci. A z toho se teprve generuje jednorázový kód. Tak je to úpně jiná situace, a něco takového považuju za mnohem bezpečnější než SMS.

Možná bude čas na změnu banky :) , nějaké další typy kromně RB a eBank?

53
Pletete se. Ten "token" od RB vypadá jako kalkulačka, vy tam zadáte číslo svého účtu, číslo protiúčtu, částku, měnu a specifický symbol, token k tomu přidá aktuální čas a z toho vygeneruje jednorázový kód, který zobrazí a vy ho přepíšete do online bankovnictví. Nevýhoda je, že token musíte mít u sebe a musíte tam všechny ty údaje zadat. Výhoda je, že nehrozí, že někdo odchytí SMS po cestě (což ještě řeší šifrovaná SMS), a také nehrozí, že ty platební údaje ze SMS nezkontrolujete. Je to tedy bezpečnější než SMS.
Já jsem se zatím setkal jen s klasickými čipovými kartami a generátory číselných kódů jako RSA Secur ID.
Tohle vypadá jako věc, hodna prozkoumání.
Velmi děkuji za info.

54
Další cestou může být dvoufaktorové přihlašování přes token, údajně to u nás už podporuje Reiffeisen.

Hmm, opravte mne někdo jestli se pletu, ale potenciální problém s použitím tokenu je to, že na něm není vidět jakou transakci povoluje/potvrzuje. V hypotetickém případě tak malware provede mitm a předhodí tokenu pro podepsání něco jiného než si uživatel "odkliknul" na webu(tj, místo požadovaného zaplacení faktury z eshopu, vám přesunou všechny peníze jinam).

Naproti tomu v SMS je napsáno kolik a komu se má poslat. Ale zas to předpokládá že nemáte ten samý malware i v mobilu, to pak samozřejmně se nedá spolehnout ani na SMS.

Z mého pohledu je tak SMS o trošičku(ale ne velkou) lepší, protože je potřeba aby se mallware dostal na oba stroje.
Ale ve výsledku, pokud se na to nepoužívá "dumbfone" je to skoro jedno.


55
Sítě / Re:SYN-ACK-RST
« kdy: 22. 11. 2016, 18:16:25 »
Přes netstat nebo nějakou takovou utilitu můžeš kouknout jaká tam máš spojení, případně v jakém visí stavu.
Na wiki je celkem slušný popis stavů https://en.wikipedia.org/wiki/Transmission_Control_Protocol .
Na http://www.isi.edu/touch/pubs/infocomm99/infocomm99-web/ je docela dobrý popis oblíbeného "problému" s TIME_WAIT.

Pokud je to mozne, doporucuju nahodit wireshark/pcap na obě strany komunikace (ehm,ale radej ne na ostrý server) a porovnat jestli to co vidí server je to samé co vidí klient a nepokazí se to někde cestou. A také se podívat že ani jedna ze stran se nepokouší vyjednávat nějaké nekompatibilní rozšíření pro to spojení. S trochou štěstí budou ve wiresharku vyznačené i případné chyby, nebo aspoň bude vidět co kdo jak a kdy posílá a kdy a jak to přiijde na druhou stranu.

Pokud najdeš co se skutečně děje, můžeš začít študovat a ptát se co stím. Ale nastavovat parametry tcp skusmo moc nedoporučuju(zejména v systémové konfiguraci, na socketu se dá ale také ledacos nastavit). Na některé problémy s TCP se dá třeba nasadit proxy která umí spojení killnout pokud je neaktivní, případně umí vložit keepalive atp, ale zas to může způsobovat jiné potíže. Každopádně je třeba být opatrný.

56
Sítě / Re:Jde nějak konvertovat IPv6 -> IPv4?
« kdy: 04. 11. 2016, 11:25:43 »
Ehm, pochopil jsem správně že chcete do internetu otevřít NAS a kamery? To mi nezní jako nejlepší nápad.

Dovolím si navrhnout aby jste popřemýšlel o VPN, ta by mohla běžet klidně na IPV6 ale uvitř budou fungovat lokální IPV4 adresy takže se dostanete na NAS i kamery jako z místní sítě a zároveň to bude aspoň trochu zabezpečené.

57
Vývoj / Re:Netbeans - základy ladění v Javě
« kdy: 24. 10. 2016, 16:19:36 »
Kite, opravdu ti přeju že pracuješ s lidmi, pro lidi, a na projektech kde můžeš díky TDD ignorovat ostatní prostředky jako třeba debuger. Přeju ti abys debuger nemusel použít a věřím že to i dokážeš. Protože debuger opravdu většinou není nenahraditelný, obzvlášť pokud si všechen kód píšeš sám.

Pokud ale toto myslíš vážně, a nepsalo to nějaké tvoje dvojče:
Tak jako kladivo není univerzálním nářadím, tak ani TDD se nedá univerzálně aplikovat na všechno. Každý vývojář používá určitou kombinaci metodik, které poznal a které se mu osvědčily. Některým dává větší váhu, jiným menší, ale nikdy nepoužívá jen jednu.
Tak nechápu tvůj, snad až odpor k debugeru. Možná je nadužívaný, možná že ty se nedostáváš do situací kdy by jsi ho s výhodou použil, ale tvářit se že je obecně k ničemu a deklasovat ho na pouhé krokování, to mi přijde na někoho s tvou reputací a zkušenostmi příliš zjednodušující, a promiň, až "hloupé".

Možná bys mohl napsat nějaký blog nebo tak něco a v něm, nejen pro sebe, utřídit důvody pro a proti používání  debugeru.Jistě by pod ním byla také zajímavá diskuze.
Ten bys pak mohl přidávat do svých odpovědí na dotazy, na místo ostentativních výkřiků typu:
BTW: K čemu je dobré krokování programu? To se používalo v assembleru.
:(

Věřím že by se tak v mnoha diskuzních vláknech kam přispíváš, uvolnil nejen prostor, ale i zbytečné napětí. A dost možná by to bylo i konstruktivnější a užitečnější mít to na samostatné stránce a né jako offtopic v různých vláknech na různých serverech.

58
Vývoj / Re:UDP server nechyta vsechny pakety jako sniffer
« kdy: 23. 10. 2016, 20:06:55 »
Mno bez dalsich informaci budu taky hadat, chtelo by to videt zdrojak a taky pustit informaci kolik a jak velkych packetu zhruba chodi za jednu vteřinu/minutu.

Hadam ze nacitani i ukladani se dela v jedne smycce(vlaknu) a protoze ukladani trva moc dlouho tak se nestiha dostatecne rychle prijimat data.
Muzete zkusit zvesit buffer pro socket aby udrzel vice dat nez je aplikace stihne vycist.
Take by asi stalo za to vyzkouset jen bez ukladani na disk a pocitat kolik prislo packetu za nejakou dobu a pri ukonceni to vypsat a porovnat s wiresharkem.

Pokud je tech packetů a dat v nich hodně, bude mozna potreba oddelit prijem dat a ukladani do souboru, tak aby na sobe nebyli primo zavisle. Napr mít to v jiných vlaknech a data si predavat pres thread safe buffer. Např nějaká varianta double bufferu s velikosti nekolika MB (je treba vyzkouset-zmerit nebo odhadnout z velikosti datoveho toku)

Ukladani na disk dost dlouho trva, ale obecne je rychlejsi jednim zapisem ulozit 1MB, nez udelat 1M zapisu o velikosti 1Byte. Takze vyhradit na buffery dostatek RAM. Nekdy muze byt vyhodne u souboru vypnout standardni bufferovani pokud uz se buffruje v aplikaci.

P.S. take pozor na to ze pokud se kazdy packet vypisuje na konzoli(printf je v mnoha prikladech) tak to taky pekne zdrzuje.

59
Studium a uplatnění / Re:Metody vyvoja SW (ebook)
« kdy: 01. 08. 2016, 08:45:49 »
Pod metody vývoje  a "procesy" si spíše představím https://cs.wikipedia.org/wiki/Metodika_v%C3%BDvoje_softwaru / https://en.wikipedia.org/wiki/Software_development_process.
Případně až řízení projektu.

Pár knížek vyšlo i u nás, ale na ebooky ale žádný typ nemám.

60
Sítě / Re:Dokumentace sítě
« kdy: 24. 06. 2016, 10:22:35 »
Radite pekne, ale naprd ... omalovanky jsou totiz naprosto knicemu, musel by je neustale nekdo udrzovat. Proto se pouzivaj softy, kery si sit osahaj, najdou vse co tam je pripojeny, a to se tak maximalne umisti na nejaky pudorys.  Kdyz neco pribude/zmeni se, je to videt hned a ne ze si za 10 let nekdo vsimne, ze to davno vede nekam jinam.
ehm, to právě je asi ten důvod proč se tazatel ptal. Mně by to také zajímalo, můžete nějaké prozradit? ideálně i s tím prokreslením na půdorys.

Stran: 1 2 3 [4] 5