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 - Filip Jirsák

Stran: 1 ... 291 292 [293] 294 295 ... 375
4381
Vývoj / Re:Náhrada C# něčím multiplatformním
« kdy: 07. 07. 2016, 17:12:43 »
A ano, na problém se zpětnou kompatibilitou jsem narazil, bohužel jsem to nezdokumentoval.
To už si ani nepamatujete, jaký typ problému to byl? Aplikace přeložená se starším JDK neběžela pod novějším, nebo nešla pod novějším JDK přeložit?

I když... zajímal by mě váš názor... Třeba na ten Benchmark Universal, který umí porovnat výsledky windows i linux stanice:
Názor na co? Tedy, především jsem nepochopil, co to má vlastně testovat – výkon JVM, konfiguraci JVM, něco jiného?

4382
Vývoj / Re:Náhrada C# něčím multiplatformním
« kdy: 07. 07. 2016, 13:26:56 »
JavaFX  ;)
Ovšem v porovnání c sharpem je javafx na tom trochu časově hůř. To znamená, že projekt trvá v Javě cca 5x déle než v C sharp. […] musíme předělávat ze swift na fx. […] Ještě jsem zvědavý na jednu poslední věc... zda je Java zpětně kompatibilní.
Opravdu by mne zajímalo, jestli to je myšlené vážně, nebo to měla být parodie Zelenáče. Nejdřív napsat takhle konkrétní srovnání, to si čtenář říká „pane jo, ten musí mít zkušeností, když dokáže nejrůznější typy projektů shrnout do jediného ‚5× déle‘“. A pak z něj vypadne, že vlastně o Javě prakticky nic neví a že to „5× déle“ je prostě jen hausnumero vycucané z prstu.

Jinak při vývoji Javy se dbá na zpětnou kompatibilitu až extrémně, třeba třídy a metody označené jako zastaralé už ve verzi 1.1 jsou pořád součástí JDK. Programy napsané pod Javou 1.0 by měly jít pořád spustit pod současným JRE, samozřejmě pokud nepoužívají vlastnosti konkrétního JRE. I kód napsaný pod Javou 1.0 by měl jít přeložit současným kompilátorem a se současným JDK, jediný problém může být s přidáním metod do rozhraní, která ten kód implementuje. Vím o jediném takovém reálném problému, a to přidání podpory pro W3C DOM Level 3 v Javě 5. Java 8 pro tyhle případy zavedla default metody. Někdo tvrdí, že to udržování zpětné kompatibility je až na škodu, třeba generika kvůli tomu byla implementována hůř než by mohla být (což je důvod, proč je C# má lepší). První plánované rozbití zpětné kompatibility se plánuje do Javy 9 v rámci projektu Jigsaw, tj. zavedení modularity přímo jako součásti základního běhového prostředí. A to opět nebude znamenat, že staré programy pod novou Javou nepustíte, pouze bude nutné udělat nějaké úpravy v nových programech, pokud v nich budete chtít modularitu používat.

4383
Problém je snadno řešitelný tím, že se vysereš na nesmyslné expirace hesla.

Pokud nevíš proč je to tak nastaveno je zbytečné bez relevantní odpovědi reagovat.
Je to tak nastaveno, protože nikomu z lidí za to zodpovědných nevadí, že uživatelé budou mít snáze odhalitelná hesla, než kdyby to tak nastavené nebylo.

4384
Server / Re:Jaký autoritativní DNS server?
« kdy: 30. 06. 2016, 07:02:50 »
Podle mne je to jenom shromáždění několika patchů, které jsou různě po internetu, na jedno místo. Nenazval bych to ani „udržovaný“. Poslední stabilní verze z roku 2010, poslední změna 2013…

4385
Server / Re:Jaký autoritativní DNS server?
« kdy: 29. 06. 2016, 21:25:50 »
Já jsem djbdns používal v době, kdy nebylo nutné řešit IPv6 a DNSSEC. Z hlediska přístupu k DNS to je podle mne do dneška nepřekonaný DNS server – např. protože jeho autor prosazoval, že DNS má sloužit k překladu jmen a ne pro přenos souborů, na což máme lepší protokoly, nebo proto, že sadu záznamů je v konfiguračním souboru nejlepší reprezentovat jako sadu záznamů, a není potřeba používat unikátní formát souboru. Co server nejlépe zvládne sám (udržovat sériové číslo zóny, reverzní záznamy k „dopředným“ názvům), to dělá sám. Dodnes servery samy od sebe neumí ani takovou prkotinu, jako je automatické překlopení záznamu v určitý čas – do určeného okamžiku server posílá jeden záznam a zkracuje mu TTL, od toho okamžiku začne posílat jiný, takže se během pár desítek sekund všichni klienti překlopí na novou adresu.

Ale jako mu svéráz DJB umožnil napsat takhle novátorský DNS server, zároveň mu to brání přizpůsobovat ho současným požadavkům. DJB má jiný názor na to, jak by se mělo DNS zabezpečit, tak nebude implementovat DNSSEC. Nějakou základní podporu nových věcí tam zatím vždy někdo dolepí, ale DNS prostě není hotový protokol, který už se nebude vyvíjet a vylepšovat, dokonce mohou být nalezeny i chyby přímo v DNS protokolu (i když i na ten nedostatek, který už se našel a který sváděl k nebezpečným implementacím, DJB upozorňoval už dávno a djbdns byl proti té chybě odolný). A když autor toho software nemá zájem ho dál rozvíjet, nedá se čekat nic jiného, než že bude pomalu umírat.

4386
Vývoj / Re:Thread Safety a Lockovanie
« kdy: 27. 06. 2016, 19:13:48 »
Takhle to rozhodně funkční nenapíšete. Budete potřebovat nastudovat si programování ve vícevláknovém prostředí – to zdaleka není jenom otázka „jak velké části kódu zamykat“. Navíc konkurenční přístup se dost těžko testuje – při běžných testech na chyby nepřijdete, protože k chybám dochází náhodně. Můžete otestovat některé konkrétní případy souběhu, ale to musíte předem vědět, kde problém může nastat – jenže napsat takový test je složitější, než napsat správně ten samotný konkurenční kód, a navíc tím otestujete jenom pár vybraných případů.

Co vám zaručuje ConcurrentDictionary byste se měl dozvědět v dokumentaci. Vám ale asi nebude stačit, abyste měl konkurenčně bezpečný slovník – když si dvě různá vlákna vytáhnou ze slovníku bezpečně tu stejnou session, je to sice dobré, ale ta vlákna s tou session pak dál musí vícevláknově bezpečně pracovat.

Zamyká se vždy co nejmenší část kódu, kterou je nutné zamknout, a zamyká se tím nejméně agresivním způsobem – tj. pokud třeba ze slovníku může číst více vláken najednou, a pouze zápis musí mít exkluzivní přístup (nesmí číst ani zapisovat nikdo jiný), zamykají se čtecí části nevýlučným zámkem pro čtení a pouze zapisující části se zamykají výlučným zámkem pro zápis. Zároveň při zamykání musíte dávat pozor na uvolňování zámků (aby se uvolnily i v případě selhání operací prováděných pod zámkem). Zkrátka je toho potřeba znát mnohem víc, než jenom „jak velký kus kódu zamknout“.

4387
Software / Re:Synchronizace offline
« kdy: 23. 06. 2016, 07:09:17 »
cekal jsem spise ze mi nekdo poradi co to presne takhle dela jak to chci ja
Na to vám odpovědět můžu: nic.

A mimochodem, pokud dotaz zní: „Chci něco, co bude fungovat přesně tak, jak jsem si vymyslel,“ je „nic“ ta nejpravděpodobnější odpověď.

Pokud opravdu chcete vyřešit svůj problém, přestaňte popisovat, jak by to mělo fungovat, a popište, jaký problém řešíte.

4388
Server / Re:Kolik SSH klíčů u více serverů/klientů
« kdy: 22. 06. 2016, 17:27:34 »
utocnik sedi u stroje C
Mám pro vás daleko jednodušší řešení bezpečnosti. Prostě prohlašte, že útočník nemá přístup k internetu, a server máte v bezpečí.

4389
Server / Re:Kolik SSH klíčů u více serverů/klientů
« kdy: 22. 06. 2016, 17:06:54 »
A jak vy vite, ze na zminenem serveru vubec nejake aplilkace jsou? Co kdyz se tam jen zalohuje? Muze tam byt akorat ssh a rsync - takovych serveru musi byt hafo.
Ta aplikace, která tam zálohuje, to jméno uživatele nezná? A co ostatní uživatelé toho zálohovacího serveru, ty jména ostatních účtů také neznají?

4390
Server / Re:Kolik SSH klíčů u více serverů/klientů
« kdy: 22. 06. 2016, 16:20:20 »
Priznam, ze nevim, jak by mi takova aplikace sama od sebe mohla delat telefonni seznam se jmenem vsech uzivatelu.
Nikde nebylo řečeno, že vám ta aplikace dá telefonní seznam se jmény všech uživatelů. Pro útok, o kterém se tu bavíme, není nic takového potřeba.

Pokud neco takoveho mate, asi neco bude dost spatne nakonfigurovaneho.
Zatímco vy jste spokojen, protože vůbec netušíte, jestli něco takového vaše aplikace nedělají. Občas se říká „sladká nevědomost“, ale řídit se tím při zabezpečení…

4391
Server / Re:Kolik SSH klíčů u více serverů/klientů
« kdy: 22. 06. 2016, 15:25:07 »
Takže jste změnil názor z „IMO zakaz ssh pro roota neni bezpecnostni featura.“ na „Bezpečnosti to může pomoct, ale je to velmi nepravděpodobné“?
Ne, pořád trvám na tom, že to není bezpečnostní featura. Bezpečnosti může v jednom konkrétním případě pomoci ledacos, i věci, které obecně bezpečnost zhoršují. Teoreticky se klidně může stát, že by vás zachránilo prázdné heslo na roota, protože by útočník takovou hloupost neočekával. Takže i prázdné heslo na roota teoreticky někdy může bezpečnosti pomoci, což nic nemění na tom, že je to velmi nebezpečné.

i když mi přijde divné, že za nepravděpodobnou považujete chybu, která už se jednou objevila
Ano, pravděpodobnost není moc intuitivní. Ale když na kostce hodíte tři šestky za sebou, pravděpodobnost, že hodíte šestku po čtvrté, je 1/6. To co už se stalo zkrátka neovlivňuje pravděpodobnost budoucích událostí.

Z těch síťových webový server, poštovní server, FTP, IM, logovací server, monitoring…
Když se bavíme o uživateli, který se používá jen pro to su a nespouští se pod ním tyto služby?
Samozřejmě. Pořád nechápu, jak chcete posoudit, jestli některá aplikace nemůže prozradit uživatelská jména (která jsou veřejná, takže tohle autoři určitě nijak neřeší), když nevíte, co ty aplikace dělají.

4392
Ale i kdyby to bylo tak, jak popisujete, stejně by to bylo lajdáctví.
Jistě. Ale diskusemi na Rootu se to nespraví. Spraví se to, pokud použijete odkaz na podporu, který máte na té stránce uveden.

Pokud tam soudruzi odesilaji i heslo, tak to vzbuzuje otazku, nac to heslo potrebuji.
Jak jsem psal, nepotřebují ho na nic. Prostě si jenom někdo neuvědomil, že když do webové stránky vloží formulářový prvek, jeho obsah se odešle, bez ohledu na to, jestli ho k něčemu potřebujete nebo ne.

4393
Server / Re:Kolik SSH klíčů u více serverů/klientů
« kdy: 22. 06. 2016, 08:56:04 »
Jirsak, jestli mate na stejnem serveu FTP, web server, logovaci server a dalsi, ktere vam na Internet ventiluji /etc/passwd nebo co, tak vas asi bude nedostatecnost zabezpeceni pomoci pseudozabezpeceni neznamym jmenem uzivatele trapit ze vseho nejmene. To uz si tam pustte rovnou fingerd a pustte to na Internet take.
Nevím, jak chcete posoudit, zda z nějaké aplikace nemůže uniknout veřejné jméno uživatele, když ani nevíte, jakým způsobem by z těch aplikací jméno mohlo uniknout. Soubor /etc/passwd jsem opravdu nemyslel.

4394
Server / Re:Kolik SSH klíčů u více serverů/klientů
« kdy: 22. 06. 2016, 08:26:18 »
Take jsem napsal, ze dvoufaktorovou autentikaci nemuzu ve scenari 3 pouzit. Cili zabezpeceni klicem + pseudozabezpeceni mi porad pripada bezpecnejsi, nez jen samotny klic.
To je pořád dokola. Zabezpečení pouze klíčem vám připadá nedostatečné. Místo abyste vymyslel způsob, jak to skutečně lépe zabezpečit, přilepíte tam pseuodozabezpečení, o kterém sám víte, že to žádné pořádné zabezpečení není. Takže skončíte s nedostatečným zabezpečením, ale jste klidný, protože máte pocit, že jste udělal dost. Máte tedy horší zabezpečení, než jaké jste na začátku požadoval. To, jestli to nedostatečné zabezpečení je o malinko horší nebo lepší než jiné nedostatečné zabezpečení je irelevantní.

Ta vaše argumentace vypadá, jako kdybyste si objednal a zaplatil náklaďák s pískem, a za týden by přifrčel frajer ve škodovce s přívěsem, a z něj by vám písek vysypal. Vy byste se samozřejmě ohradil, že jste si objednal a zaplatil celou tatrovku, načež on by vzal lopatičku a trochu písku by přihodil. A pak by se zasekl na tom, že přece vozík a lopatka písku je nepochybně víc, než jenom vozík písku – a odmítal by pochopit, že když jste objednával fůru písku, nějaká lopatička písku více či méně je pod vaši rozlišovací schopnost.

Mohl byste mi napriklad vysvetlit, jak budete pouzivat dvoufaktorovou autentikaci v pripade automatickych spojeni, kde nehodlate opisovat nejake cislo, kdykoliv se probudi uloha z cronu?
Rozhodně nebudu úlohu z cronu přihlašovat účtem, který může udělat su na roota bez hesla. Úlohu z cronu budu spouštět tak, aby nemohla udělat nic jiného, než co má dělat – takže neoprávněné spuštění by nemělo způsobit žádnou škodu.

Napriklad ktere? Ten vycet aplikaci jste zretelne zapomne i vy. A jak vite, ze na danem serveru takove bezi?
Z těch síťových webový server, poštovní server, FTP, IM, logovací server, monitoring… Jestli na jednom konkrétním serveru nevím, ale pokud má někdo tak hloupý nápad, že bude uživatelské jméno používat místo hesla, neví to ani on. Protože kdyby se pustil do toho, že všechny aplikace ověří, hned by mu došlo, že bude mnohem jednodušší použít nějkaý jiný, skutečný způsob zabezpečení.

4395
Server / Re:Kolik SSH klíčů u více serverů/klientů
« kdy: 22. 06. 2016, 07:15:00 »
Scenar 3: Zabezpeceni klicem nepovazuji za dostatecne bezpecne, dvoufaktorovou autentikaci nemuzu pouzit. Pridam tedy pseudozabezpeceni pomoci neznameho a tezko uhadnutelneho jmena uctu. Nevidim, cim by to mohlo byt mene nebezpecne, nez pouziti klice primo na rootovi, nez dvoufaktorove autentikace. Pokud vas neco napada, dejte vedet.
Vždyť jste to sám napsal. Je to méně bezpečné v tom, že se spokojíte s pseudozabezpečením, místo abyste udělal skutečné zabezpečení.

K tomu těžko uhádnutelnému jménu účtu jste zapomněl napsat výčet aplikací, ze kterých může uniknout, všechna místa, kde je uložené, a všechny případy, kdy se někam zadává.

Takže kdybych tento argument použil v roce 2007, tak by byl validní?
Nebyl. V roce 2007 bych vám stejně jako dnes tvrdil, že jste si vybral jeden velmi nepravděpodobný scénář útoku, a přehlížíte tisíce dalších podobných scénářů. Rozdíl je v tom, že v roce 2007 byste pravděpodobnost toho scénáře nepodporoval tím, že už se to jednou stalo.

Stran: 1 ... 291 292 [293] 294 295 ... 375