Příspěvky

4921

Software / Re:Alternativa TrueCryptu

« kdy: 02. 01. 2015, 08:49:41 »

skor, ci neskor v neudrzanom SW sa objavia bezpecnostne chyby...

Pořád to píšete, jako by to objevení bezpečnostní chyby záviselo na tom, zda je software udržovaný nebo neudržovaný. To ale není pravda, jenom tím, že někdo prohlásí, že ten software udržuje, bezpečnostní chyby nezmizí. Ve skutečnosti tam ale případná bezpečnostní chyba buď je, nebo není, nezávisle na tom, zda je software udržován. Teprve pokud tu chybu někdo objeví, projeví se rozdíl – v případě udržovaného softwaru ji nejspíš někdo opraví, v případě neudržovaného asi ne. Ještě je drobný rozdíl v tom, že v případě udržovaného softwaru je vyšší pravděpodobnost, že chybu odhalí autor, který tu chybu bude chtít spíš opravit než zneužít.

takze by som TrueCrypt uz nepouzival z dovodu skrytych chyb, ktore po objaveni uz nikto neopravi...

Kolik takových chyb už v TrueCryptu bylo? Jakou máte náhradu za TrueCrypt?

Dokud totiž tu chybu nikdo neobjeví, je bezpečné TrueCrypt používat. A pokud nemáte odpovídající náhradu, proč ho hned teď přestat používat kvůli potenciálním problémům v budoucnosti? To byste ho mohl zavrhnout rovnou na začátku, i když ještě byl udržován – protože co když jednou přestane být udržován a bude v něm nalezena chyba, kterou nikdo neopraví?

4922

Software / Re:Alternativa TrueCryptu

« kdy: 01. 01. 2015, 15:29:00 »

Jsou podstatne aktivnejsi co se tyce komunikace s uzivateli.

To tomu projektu nějak pomůže? Myslím, že problém TC nebyl nedostatek uživatelů.

Cele to ukonceni vyvoje TC je zarnym prikladem otresneho amaterskeho pristupu (ani neuvedli, proc skoncili; radsi doporucili zcela neadekvatni MS reseni [troll.png]).

Já myslím, že ukončení vývoje a údržby TC naprosto přesně odpovídá tomu, jak k TC přistupovali uživatelé. Já zvláštní, jak kde kdo důvěřuje autorům TC ohledně jeho bezpečnosti, ale když autoři doporučí řešení od MS, najednou na to zapomenou a tváří se, že autoři TC bezpečnosti vůbec nerozumí.

A jak se lisi ten fork od ostatnich free SW produktu?

Například od Linuxu, OpenOffice nebo LibreOffice, Chromia a mnoha dalších se liší v tom, že za ním nestojí velké firmy, které by platily vývoj. Od OpenSSH se liší v tom, že v něm snad nejsou školácké programátorské chyby.

Takto bych mohl kazde doporuceni smest ze stolu a rict, ze budto hrozi bezpecnostni riziko, protoze uzavreny kod, nebo free produkt, ktery umre. Ma tedy cenu hledat alternativu, kdyz podle teto logiky vlastne zadna (dlouhodobe) neexistuje?

Já nevěřím tomu, že se bezpečný bezpečnostní software dá dělat tak, že tam budou přispívat kousky kódu náhodní programátoři a nebude tam silný lídr, který na bezpečnost dohlédne. Zároveň nevěřím tomu, že to silný lídr dokáže dělat delší dobu jenom jako koníčka. To, jestli má ten produkt uzavřený nebo otevřený kód, podle mne není z hlediska jeho trvání podstatné.

Mozna by vice vyvojaru prispelo kodem, kdyby TC nemelo specialni licenci a TC tym (vice) komunikoval.

Jenže příspěvky kódu jsou podle mne přesně to, co TC vůbec nescházelo. Právě proto si myslím, že forky TC moc dlouho nepřežijí, protože řeší právě jen ty příspěvky kódy, v čemž ale žádný problém nebyl.

Myslim si, ze by se naslo dost lidi ochotnych prispet.

Myslíte si to hezky, ale ti lidé se nenašli.

Asi se jen chteli zbavit pet projektu, tak zvolili nejjednodussi reseni - utekli.

Podle mne zvolili z pohledu odborníků na počítačovou bezpečnost nejlepší možné řešení - nepokusili se rozmělnit svou odpovědnost a hodit to na někoho jiného a férově řekli uživatelům, jaká je situace. Po předchozích opakovaných zkušenostech neměli důvod si myslet, že by se někomu podařilo ten projekt zachránit. Navíc když několikrát dali najevo, že projekt potřebuje pomoc, a nic se nestalo, proč by měli brát nějaké ohledy na uživatele? Uživatelé utekli jako první, autoři až po nich...

4923

Odkladiště / Re:Registr veřejných zakázek?

« kdy: 01. 01. 2015, 14:33:49 »

Veřejné zakázky, které musí být vypisovány podle zákona o veřejných zakázkách, musí být zveřejňovány ve Věstníku veřejných zakázek.

4924

Software / Re:Alternativa TrueCryptu

« kdy: 01. 01. 2015, 13:10:09 »

Nebo je snad nejaky "problem" i s tim forkem?

Předpokládám, že s tím forkem bude úplně stejný problém, jaký byl s původním TC, a proč TC s pravděpodobností hraničící s jistotou skončil - kde kdo ho bude chtít používat, ale skoro nikdo nebude ochoten přispět na vývoj a údržbu. (Rovnou dodávám, že pár řádek zdrojového kódu v tomto případě není relevantní příspěvek.)

4925

Distribuce / Re:Rozdíl ARM vs x86 Debian

« kdy: 31. 12. 2014, 17:10:23 »

Fakt si někdo myslí, že je sebemenší šance, že to na jedno jádrovém ARMv5 s půl gigem RAMky jakkoliv smysluplně poběží?

Procesor by vadit neměl, mělo by to být jen pomalejší, což nemusí být při občasném používání problém. Ale to půl giga RAM je problém, pokud ta aplikace potřebuje víc.

Tedy pokud se to tedy vůbec rozběhne, v těch požadavcích totiž několikrát stojí procesor Intel, AMD nebo kompatibilní.

Vzhledem k tomu, že je to Java, je celkem jedno, jaký pod tím běží procesor.

4926

Software / Re:Alternativa TrueCryptu

« kdy: 31. 12. 2014, 09:42:58 »

Takže zabezpeční truecryptem je v ČR minimálně na 5 - 10 let naprosto v pohodě.

To bych netvrdil. Zítra může někdo objevit bezpečnostní díru, kterou už nikdo neopraví. Takže dnes je v pohodě, ale nejde předpovídat, zda bude v pohodě i za měsíc.

4927

Software / Re:Alternativa TrueCryptu

« kdy: 30. 12. 2014, 21:15:09 »

Pravda je taková, že Truecrypt není bezpečný a neměl by se používat. Je to mrtvá záležitost.

Není udržován, tudíž nemusí být bezpečný. Zda by se neměl používat, to je otázka - pokud máte něco lepšího, určitě je lepší to používat. Ale pokud nic lepšího nemáte, zatím není důvod TrueCrypt přestat používat, protože zatím žádná známá bezpečnostní chyba objevena nebyla (teda až na tu, kterou si nejspíš vymyslel Bonifác).

4928

Software / Re:Alternativa TrueCryptu

« kdy: 30. 12. 2014, 19:12:03 »

WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues

viz: http://truecrypt.sourceforge.net/

Tohle samozřejmě všichni znají, ale tam není nic o tom, že by TrueCrypt byl prolomen.

4929

Software / Re:Alternativa TrueCryptu

« kdy: 30. 12. 2014, 18:50:56 »

Truecrypt byl prolomený

Umíte tuhle senzační a unikátní informaci nějak doložit? Nečekám odkaz - když jste první, kdo s tou informací přišel, nikde jinde o tom samozřejmě ještě napsáno nebude - ale nějaké bližší informace, třeba kdo to prolomil, jakým způsobem, kdy to oficiálně zveřejní, jestli to bude nějak demonstrovat... Nebo jste si to prostě jenom vymyslel?

4930

Distribuce / Re:rozdíl ARM vs x86 Debian

« kdy: 29. 12. 2014, 17:48:59 »

Distribuce může být stejná, ale některé balíčky nemusí být pro danou platformu dostupné.

Pro FlexiBee snad ale grafické rozhraní nepotřebujete, ne? Jestli si dobře pamatuju, FlexiBee je napsané v Javě. Ta je pro ARM dostupná ve variantě Java SE Embedded, je potřeba ověřit, zda tam FlexiBee nebude něco chybět. Databáze PostgreSQL by také měla na architektuře ARM fungovat.

Nevím, jak to má Zyxel, Synology má balíčky pro PostgreSQL i Javu, takže tam se dá vše potřebné nainstalovat přímo do jejich systému a pak už by zbývalo jen tam zprovoznit FlexiBee (což také nemusí být jednoduché – nevím, zda to distribuují jako archiv, který jen rozbalíte, nastavíte cesty a spustíte, nebo zda je instalace složitější).

4931

Vývoj / Re:Hashování hesla

« kdy: 23. 12. 2014, 15:37:47 »

Z toho vašeho zápisu není úplně zřejmé, co se bude provádět na klientovi a co bude uložené na serveru.

Pokud se na klientovi udělá jen SHA512 hesla a na serveru bude uložena sůl a výsledek funkce password_hash, pak pokud někdo získá přístup k uloženým údajům, dokáže se jménem uživatele přihlásit na váš web. Pokud někdo odchytí komunikaci, dokáže se také jménem uživatele přihlásit na váš web.

Pokud nechcete použít HTTP autentizaci a chcete hashovat heslo na klientovi (asi JavaScriptem), můžete přece použít alespoň schéma  HTTP Auth digest. Budete tam mít také dvojité hashování, ale aspoň zabráníte zneužití přihlašovacích údajů odchycených z nešifrované komunikace.

Já osobně řadím opakované hashování do kategorie pověr, protože to na útočníka zaměřeného na váš systém nemá významný vliv. Navíc se tím opakovaným hashováním pravděpodobně postupně zmenšuje prostor možných vstupních kombinací. U dobré hashovací funkce to  nebude mít žádný praktický vliv, ale pokud by byla v té hashovací funkci nalezena slabina, mohl by ten vysoký počet iterací útočníkovi výrazně pomoci.

4932

Vývoj / Re:Hashování hesla

« kdy: 23. 12. 2014, 14:30:30 »

Opravdu potřebujete vymýšlet vlastní autentizační schéma? Nebylo by lepší použít HTTP Auth Digest?

4933

Vývoj / Re:Rychlý a úsporný kód

« kdy: 18. 12. 2014, 20:14:39 »

Logik: řešení (ne)zamykání považuju za algoritmus. Distribuce práce je přesně ten případ, kdy se někdy vyplatí myslet na cache - někdy se vyplatí počkat na jádro, které už má data v cache, než práci nacpat prvnímu volnému procesorovému jádru.
Netvrdím, že o procesorové cache potřebuje vědět každý programátor, ale pokud už někdo chce optimalizovat kód na téhle úrovni, ve většině případů mu daleko víc pomůže optimalizace práce s cache než používání speciálních instrukcí a přepis do strojového kódu.

Latence UI je přesně to, co uživatel subjektivně vyhodnotí jako "pomalý program".

4934

Vývoj / Re:Rychlý a úsporný kód

« kdy: 18. 12. 2014, 06:54:16 »

Nevím, jak často programátoři programují násobení matic. Dost programátorů ale programuje webové aplikace, které jsou přirozeně vícevláknové, a kde může mít uspořádání sdílených dat vliv právě na to, jak se bude pracovat s cache.
Jinak bylo řečeno, že algoritmus je daleko podstatnější, než cache, na druhou stranu cache je většinou podstatnější, než použití speciálních instrukcí nebo než ruční optimalizace strojového kódu.

4935

Vývoj / Re:Rychlý a úsporný kód

« kdy: 17. 12. 2014, 21:20:20 »

Tak tady bych zatraceně nesouhlasil. Jestli je jedna věc, kterou by _každý_ programátor měl znát, tak je to funkce cache. Momentálně je to to nejužší hrdlo prakticky v _každém_ programu. V generování kódu překladač strčí do kapsy tak 90% programátorů, ale se zprasenýma datovýma strukturama neudělá ani ň. Tohle se navíc skvěle kombinuje s naivním přístupem k objektovému programováním, kdy se cache používá dost strašným způsobem.

Naprostý souhlas. Nejvíc se zoptimalizuje změnou způsobu práce, pak změnou algoritmu. A když už na tom není co vylepšovat, pokračoval bych právě optimalizací vzhledem k cache, speciální instrukce až potom, ty budou mít obvykle menší vliv. Pokud to není nějaký matematický výpočet, použije se těch speciálních instrukcí pár. Oproti tomu když v nějaké smyčce při každé iteraci budu muset data načítat z hlavní paměti místo z cache, promrhám tím mnohem víc času.
Kompilátor nějakého vysokoúrovňového jazyka by datové struktury teoreticky mohl optimalizovat, ale C kompilátor vám rozhodně nemůže přeskládat prvky ve struct, ze spojového seznamu udělat pole a z pole pointerů udělat pole struct.