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 - alexfa

Stran: [1]
1
V pripade YubiKey, smart card (PKCS#11 / PIV atd. obecne) se jedna o tzv. hardwarovy klic. Jeho vyhoda spociva v nemoznosti poridit si kopii klice. Tuto garanci v pripade USB neziskavate.

Zde jsou dva typicke pripady, kdy je rozdil mezi HW a SW klicem videt:

1) Zamestnanec/administrator pristupuje na servery napr. pomoci SSH, klice ma YubiKey vs. na USB.
V pripade ukonceni pracovniho pomeru odevzda YubiKey a tim mate jistotu, ze jiz nema pristup ke klici. V pripade USB flashky si mohl poridit kopii a tato jistota neexistuje

2) Neverite uplne celemu softwarovemu vybaveni vaseho PC a presto chcete pristupovat ke chranenemu zdroji. V pripade YubiKey mate jistotu, ze zadny malware vam klic z YubiKey nezcizi a nikam neodesle, USB flashka tuto jistotu neposkytuje

Disclaimers:

Priklady jsou ilustrativni a nejsou (kompletnim) popisem reality.

Popis je samozrejme mirne zjednoduseni, Security Officer (SO) si diky svym opravnenim muze klic odzalohovat napr. pro pripad ztraky klicenky.

Softwarovy klic muze byt chranen heslem - pak je ale treba chapat, ze sila klice neni urcena jeho bitovou delkou ale silou hesla, ktere ho chrani.

2
Vývoj / Re:Použití Python Flask v komerční sféře
« kdy: 27. 06. 2019, 20:00:09 »
V asynchronnim svete tu otazku musite polozit jinak: ktera SQL databaze je schopna obsluhovat 10k pripojenych klientu.

to znamena co? I v asynchronnim svete coroutiny sdili nejaky connection pool, ktery je urcite mensi nez 10k spojeni, typicky radove desitky. Bottleneck je databaze, ne aplikace.

Presne tak, takze je uplne zbytecne, aby vam databaze (nebo cokoliv jineho, pomaleho) blokovalo process/threadu, kdyz se vlastne jen ceka.
Pekne jste si odpovedel, proc je asyncio dobre i pro komunikaci s databazi :-)

vykon aplikace je omezen databazi. je jedno jestli cekani na vysledek dotazu blokuje aplikacni proces, protoze databaze by stejne vic nezvladla.
Já se async v Pythonu zatím vyhýbám, kde můžu, ale proč by pak někdo dělal asynchronní knihovnu jako tato:
https://github.com/MagicStack/asyncpg ?

https://github.com/aio-libs ... tohle je soubor relativne dobre vyzralych asyncio knihoven (vcetne postgres).

3
Vývoj / Re:Použití Python Flask v komerční sféře
« kdy: 27. 06. 2019, 19:58:41 »
Ako napisal gill, taky hello world do prehliadaca je tusim na 3 riadky kodu. Zaklad Flask-u sa da pochopit za jeden den, mozno potom este chvilku trva, kym clovek dobre pochopi kontexty a pracu s nimi (Application context, Request context), ale je to naozaj jednoduche. Sqlalchemy sa s Flaskom moze, ale nemusi pouzivat, ale stoji za to s nim vediet pracovat. Dnes si uz neviem predstavit zlozitejsiu databazovu aplikaciu bez tohoto ORM.

Naopak orm se hodi na nejake primitivni weby, nedokazu si predstavit slozitejsi databazovou aplikaci s orm. To proste nikdy nefunguje. Par takovych zoufalych firem znam co to zkusilo, pak jsou radi, ze jsou schopni zaplatit nekoho, kdo je z toho bordelu vyseka.

No, uz jsem tady byl za kacire v jednom tematu, tak budu i v tomhle: ORM je iluze, ktera na zacatku vypada, jako dobry napad a na konci je to katastrofa ... bez vyjimky - a pisu to z vlastni zkusenosti, psal jsem vlastni ORM 2 roky.
Duvod, ktery to zpusobuje, je fakt, ze objektovy a relacni model nemaji 1:1 preklad. Je to jako preklad mezi anglictinou a cinstinou. Kdyz se to vezme slovo od slova, tak to "tak nejak" bude fungovat, ale drive ci pozdeji narazite na to, ze to nejde automaticky a musite mit nejakeho prekladatele, ktery chape vyssi vyznam (tj. sikovneho programatora).

Hodne lidi/firem nerozumi tomu, ze vetsina uloh, ktere resi ve svem software NENI relacni problem.
A presto si jako svoji databazi zvoli SQL ... protoze se to tak dela. Misto racionalni uvahy, jaka databaze je vhodna pro reseni konkretniho problemu, se automaticky saha po SQL. Kdysi jsem cetl zajimavou uvahu o tom, ze volba SQL do aplikace je necastejsi architektonicka chyba dnesni doby (single biggest mistake of software architecture).
Aby se tomu nasadila koruna, tak se obratem saha po ORM (object-to-relation mapper), coz je vlastne narovnavak na ohybak chybne vybraneho storage schematu.
Vyvijena aplikace nakoupi zeleznou kouli hned prvni den a vyvojari jsou zpomalovani prelezanim objektovo/relacni linie uprostred aplikace (aka prekladanim svych konceptu z anglictiny do cinstiny a zpet).

Volte takove databaze, ktere jsou vhodne pro vase problemy.
Pokud to nedokazete odhadnout, tak vezte, ze vas problem je objektovy, takze potrebujete objektovou databazi.
A ne, nedaji se v ni delat joiny, stejne tak, jako nedelate joiny se svymi objekty :-)

4
Vývoj / Re:Použití Python Flask v komerční sféře
« kdy: 26. 06. 2019, 08:56:28 »
V asynchronnim svete tu otazku musite polozit jinak: ktera SQL databaze je schopna obsluhovat 10k pripojenych klientu.

to znamena co? I v asynchronnim svete coroutiny sdili nejaky connection pool, ktery je urcite mensi nez 10k spojeni, typicky radove desitky. Bottleneck je databaze, ne aplikace.

Presne tak, takze je uplne zbytecne, aby vam databaze (nebo cokoliv jineho, pomaleho) blokovalo process/threadu, kdyz se vlastne jen ceka.
Pekne jste si odpovedel, proc je asyncio dobre i pro komunikaci s databazi :-)

5
Vývoj / Re:Použití Python Flask v komerční sféře
« kdy: 25. 06. 2019, 09:14:55 »
Znate C10k problem?

ktera SQL databaze dokaze soucasne obsluhovat 10k spojeni?

V asynchronnim svete tu otazku musite polozit jinak: ktera SQL databaze je schopna obsluhovat 10k pripojenych klientu.
Spojeni bude radove mene. A odpoved je, ze napr. PostgreSQL.

Zrovna ted resime jeden "brownfield" projekt, ktera byla puvodne napsana v synchronnim paradigmatu. Jeden pozadavek od klienta = jedno spojeni = jedno vlakno (process) = jedno spojeni do PostgreSQL databaze. Samozrejme toto prestalo skalovat, neprekvapive kdyz se priblizila hranice 10k pripojenych klientu. Cely kod je v podstate na vyhozeni (je to Java).
Resime to prepisem do Python/asyncio, prave protoze pak neplati vyse uvedena spojka.
V asynchronnim svete muzete mit klidne 10k spojeni, 16 procesu/vlaken (protoze mate treba 16 CPU jader), k tomu pak napr. 64 spojeni na databazi (zde mate argument proc async je pro databaze vhodny) a cela aplikace bezi paradne.
Je to, protoze webove aplikace jsou v dnesni dobe I/O bound ( https://en.wikipedia.org/wiki/I/O_bound ) a tudiz nema smysl pro ne blokovat cely proces potazmo CPU vlakno.
A proto si stale myslim (prakticky overeno), ze pro webove aplikace je synci pristup prekonany.

6
Vývoj / Re:Použití Python Flask v komerční sféře
« kdy: 24. 06. 2019, 20:36:30 »
Python se dle meho nazoru posunuje smerem k asynchronim aplikacim.
Flask je z tohoto pohledu jiz prekonanym konceptem, takze doporucuji se take podivat na asyncio alternativy k Flasku.

Asynchronni alternativa nikdy nebude stejne robustni jako oddeleny proces na request. Asynchronni komunikace s SQL je navic zbytecna. Vetsinou jsem se setkal s resenim flask + asynchronni server pro websocketova spojeni.

Znate C10k problem?
https://en.wikipedia.org/wiki/C10k_problem

Par let jsem stavel server na presne stejnem konstruktu, ktery zde uvadite "... nebude stejne robustni jako oddeleny proces na request ...".
Neni to pravda. Viz treba Apache vs NGINX.

7
Vývoj / Re:Použití Python Flask v komerční sféře
« kdy: 23. 06. 2019, 20:11:00 »
Python se dle meho nazoru posunuje smerem k asynchronim aplikacim.
Flask je z tohoto pohledu jiz prekonanym konceptem, takze doporucuji se take podivat na asyncio alternativy k Flasku.


8
Zminil bych zde ECIES - https://cs.wikipedia.org/wiki/ECIES - coz je kryptosystem, ktery je zamereny na ochranu payloadu, nikoliv transportni vrstvy (aka kontrast k TLS/SSL).
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.

Samozrejme hodne zjednodusuji.

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.

9
Odkladiště / Re:Vlastní předtěžená kryptoměna
« kdy: 19. 12. 2018, 00:24:49 »
https://github.com/TeskaLabs/coingame

... vyrobeno pro team retreat behem tohoto roku - je to primitivni cryptomena v Pythonu ...

10
Software / Re:Offline blog generator
« kdy: 19. 12. 2017, 14:11:24 »
Jojo, myslím, že tohle všechno ten lektor splňuje, ale první commit má December 2015 :-)

No jasne, jen je to CMS a nikoliv blog.
A btw - 21 March 2014 je prvni commit v nasem Gitu.

11
Software / Re:Offline blog generator
« kdy: 19. 12. 2017, 12:59:40 »
Rozumím tomu, že reklama je potřebná, koukal jsem taky na uvedený web a nevypadá špatně, ale mohl byste blíže specifikovat, co myslíte tím nezabraly? Ono totiž na offline generátorech není moc co vymýšlet, jeden jako druhý. Mnohem důležitější je nabídka templatů nebo rozšiřujících modulů okolo. Jinak váš příspěvek vypadá jen jako plácnutí do vody.

Cele se to sebehlo tak, ze pred vice nez dvemi lety jsme se rozhodli, ze potrebujeme k nasemu staticky generovanemu webu (hyde) pridat i blog a to rovnez staticky generovany.
Pozadavky vypadaly asi takhle:

- staticky generovany blog (tzn. zadny Wordpress atd.)
- self-hosted (tzn. pobezi to na nasem serveru, budeme tomu rozumet aka Python, Bootstrap atd.)
- content musi byt v Gitu
- continuous deployment obsahu (tzn. kdyz nekdo vytvori content, ktery vlozi do gitu, tak se automaticky dostane na web)
- content se bude psat jako Markdown clanek s obrazky
- velka flexibilita (vedeli jsme, ze budeme s podobou blogu hodne cvicit, nez to trefime)

Zkouseli jsme to napasovavat na ruzne staticke generatory (pred dvema lety, svet uz muze byt jinde!) a vzdycky to nekde nebylo dobre. Problem, ktery jsme s tim meli byt ten, ze to jsou staticke generatory webu nikoliv blogu. Coz znamena, ze tvorba obsahu blogu byla prilis slozita, ve zkratce vyzadovala znalost HTML. Toto nebylo prijatelne, protoze clovicek, ktery mel blog na starosti, HTML moc nedaval. Bohuzel detaily si uz nepamatuji, ale v jednom okamziku bylo jasne, ze kdyz si na to sedneme, tak mame za den az dva jadro hotove.

Od te doby na tom blogujeme a jsme spokojeni, postupne jsme do toho pridavali dalsi funkce a pilovalo se to, aby to byl funkcni blog (testovano na lidech). Na toto tema jsem reagoval hlavne protoze se to seslo v case, na GitHub jsme to dali pred par dny. Je na tom jeste hodne prace stran opravdoveho zpristupneni lidem: dokumentace, mozna nejake pluginy, komunita. Nekde se ale zacit musi, ze.

12
Software / Re:Offline blog generator
« kdy: 19. 12. 2017, 04:06:12 »
Kolega pred par dny uvolnil offline blog generator - https://github.com/TeskaLabs/ArrayBelle
Pouzivame to uz pres dva roky, potom, co vyse uvedene SW nezabraly.

https://www.teskalabs.com/blog/ - tohle na tom bezi.

Stran: [1]