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 - Vít Šesták (v6ak)

Stran: 1 2 [3] 4 5 ... 17
31
Software / Re:OpenSCAD vs. dxf soubor s filletovanými tvary
« kdy: 18. 06. 2020, 23:43:22 »
Pro $fn v OpenScadu platí že čím větší, tím detailnější. Neznám přesnou definici, ale nejspíš to bude něco ve smyslu: Kružnice se předvede na pravidelný $fn-úhelník.

A AFAIK technicky vzato $fn uplatní hned, ne až při exportu. Dokonce je možné mít pro různé části objektu různé $fn, případně kreslit pravidelné n-úhelníky apod. nastavením vhodného $fn.

32
Software / Re:OpenSCAD vs. dxf soubor s filletovanými tvary
« kdy: 18. 06. 2020, 22:01:24 »
To už skoro zní jako problém v samotném DXF, ale těžko soudit, když nemám ten soubor a vím o něm jen omezeně. Pokud je to mnohoúhelník už v DXF, $fn nemá jak pomoct.

33
Software / Re:OpenSCAD vs. dxf soubor s filletovanými tvary
« kdy: 18. 06. 2020, 08:07:39 »
$fn by to mělo vyřešit, pokud není problém už v DXF. Je to potřeba řešit i u circle/sphere/cylinder.

Tolerance – nezkoušel jsem, ale transformace offset vypadá použitelně. Nebo lze použít Minkowski, ale trvá to a na zmenšování jsou potřeba inverze.

34
Software / Re:Šifrované zálohování na cloud
« kdy: 14. 05. 2020, 11:00:40 »
EncFS slouží k šifrování general purpose filesystému, což je poněkud obecnější a tedy náročnější úkol než šifrování záloh. A náročnější úkol znamená vyšší riziko chyby a možná i zbytečně více tradeoffů – napadá mě třeba riziko replay attacku.

Konkrétně u EncFS není riziko chyby jen teoretické, byl tu kdysi audit, který našel hromadu chyb: https://defuse.ca/audits/encfs.htm Bohužel jsem nikde neviděl informaci o tom, že by to opravili. Což může být se zachováním zpětné kompatibility možná i nemožné.

35
Odkladiště / Re:Sledování CVE
« kdy: 22. 04. 2020, 01:35:04 »
Chcete se přihlašovat ke každému produktu ručně? Pokud ne, tak se bude hodit nějaký scanner, který identifikuje komponenty a pokusí se k nim dohledat známé zranitelnosti.

A konkrétní nástroj? Záleží na platformě. A situace se může lišit u zranitelností aplikací nainstalovaných v OS a u zranitelností 3rd party knihoven ve Vámi vyvíjené aplikaci.

Ale celkem univerzální je OWASP Dependency Check, případně asi i OWASP Dependency Track. (Navzdory podobnému názvu spolu až tolik společného uvnitř zřejmě nemají.) A teď je otázka i nasazení. Domácí použití? Správa tisíců počítačů? CI server?

36
Windows a jiné systémy / Re:Android - privacy app
« kdy: 12. 04. 2020, 23:05:31 »
Těžko data uchráníte, když zákeřná aplikace k nim bude mít přístup. Můžete se snažit zabránit exfiltraci dat, ale nejspíš taháte za celkem krátký konec provazu.

Ve Vašem případě se snažíte zabránit přístupu k Internetu jen někdy. Jenže každá rozumně napsaná aplikace bude nejspíš schopna taková data prostě uložit a odeslat později. A to se bavíme o aplikaci, která ani není psána s vědomím podobné „ochrany“ a autor aplikace se ji nesnaží nijak přímo obejít. Samozřejmě podobná ochrana může ve specifických případech pomoci, zejména pokud je potřeba data chránit jen krátkou chvíli, ale tady nečekám masový zájem.

A pokud připustíme, že se autor aplikace bude snažit podobná omezení obejít, nemusí pomoct ani aplikaci úplně odstřihnout od Internetu:

* Může se pokoušet data exfiltrovar třeba otevřením webové stránky ve výchozím prohlížeči, data předá do GET parametrů.
* Může napsat dvě zdánlivě nesouvisející aplikace, které si ve skutečnosti budou předávat data. Jedna bude mít přístup k citlivým datům, druhá k Internetu. Spolu to zvládnou…
* Různé covert channels. Když bude útočník ve vhodný okamžit fyzicky dostatečně blízko, může se snažit data exfiltrovat i neslyšitelným zvukem…
* Odesílat data lze někdy i alternativním způsobem. Aplikace s přístupem ke kalendáři může dát data do události a nastavit sdílení.

Ano, je to komplikovanější. Ale pokud chcete opravdu zabránit zneužití nějakých dat, v první řadě by je útočník neměl dostat. Zabránit exfiltraci může být náročnější, než to na první pohled vypadá.

37
Případně lze použít sudo a nastavit ho tak, aby šlo použít (třeba omezeně) bez hesla.

Bezpečnostní dopad je otázkou, ale oproti přímému použití roota se nejspíš nic nezhorší.

Koncepčně vidím problém v tom, že ta aplikace vypadá jako takový kočkopes. Pokud to dobře chápu, skládá se ze serveru (ten má běžet furt) a GUI (to se spustí až po přihlášení), ale ve skutečnosti jde o jeden proces, který se snaží obojí obsloužit zároveň. Jenže server by měl startovat co nejdříve a klient až po přihlášení, což dohromady nejde.

38
Software / Re:Kde najít přesnou formu spuštěného programu?
« kdy: 04. 04. 2020, 10:13:17 »
Ta varianta s xargs -0 a print "%q " je asi to nejpřesnější, co dostanete z běžícího procesu. Escapuje to parametry pro bash, ale samozřejmě to nezná přesnou původní formu ("foo bar" vs. 'foo bar' vs. foo\ bar). Nebudou tam různá přesměrování do/ze souboru (i když, to by se možná taky dalo nějak dohledat).

Například z příkazu:

tail ~/something | grep foo > bar

uvidíte zvlášť tail (s expandovaným ~) a zvlášť grep foo. Přesměrování do souboru bar by možná šlo dohledat jinde, v cmdline to nebude.

39
/dev/null / Re:Proč mapy.cz chtějí polohu?
« kdy: 03. 04. 2020, 09:33:22 »
V podstatě ze dvou důvodů.

1. Aby věděli, koho mají upozornit, když nahlásíte, že jste nakažen COVID-19.
2. Aby vás mohli upozornit, když někdo, s kým jste se potkal a měl také zapnuté sledování, nahlásí Seznamu, že měl COVID-19.

Samozřejmě na to nelze spolehnout ze spousty důvodů (omezené testování, omezené množství sdílí polohu, případy bez symptomů, nákaza se může přenášet přes kliky a poprskané obaly zboží v supermarketu, atd.). Rozhodně bych to nepovažoval za to nejdůležitější opatření, nejspíš i ta nejhorší rouška udělá větší službu. A je to (dobrovolný) zásah do soukromí. Ale pokud se s tím smíříte a nebudete z té aplikace vyvozovat přehnané závěry, tak když to nepomůže, nemělo by to uškodit.

40
Vývoj / Re:Segmentation fault
« kdy: 02. 04. 2020, 08:55:54 »
Dvě hypotézy:

a. Problém se týká práce se stackem, což Valgrind AFAIR nedetekuje. (Ono to ani není snadné u zkompilovaného programu. V případě heapu může nahradit dynamicky linkované funkce pro práci s pamětí, v případě stacku to asi nebude tak jednoduché.)
b. Problém se projeví jen pří souběhu více vláken. AFAIR Valgrind dost omezuje souběžnost vláken.

Zmíněný Helgrind může pomoci na kontrolu problémů se souběžností.

Kontrolu problémů na stacku by moho jít udělat pomocí managed implementace LLVM v GraalVM EE: https://medium.com/graalvm/safe-and-sandboxed-execution-of-native-code-f6096b35c360
* Vyžádá si to ale zkompilovat stejným způsobem i použité knihovny. Nedovedu od stolu vyhodnotit, jak jednoduché nebo náročné to bude v tomto případě.
* Samozřejmě se odchylujete od produkčního prostředí. To není ideální, ale asi se tomu úplně nevyhnete.
* Enterprise Edition je zdarma za určitých podmínek, možná by se tam vešel i tento případ. Rozhodně ale nejsem právník a tento komentář píšu sám za sebe, ne za svého zaměstnavatele.

41
Distribuce / Re:ZFS a Linux
« kdy: 22. 03. 2020, 20:09:00 »
Myslím, že není potřeba přelicencovat zdrojáky Linuxu. Co si vzpomínám, existují legálně moduly kernelu, které nejsou pod GPL, a dokonce jsou uzavřené. Má to tuším jakési omezení, co mohou non-GPL moduly volat, a co už ne. Důvod – pokud si dobře vzpomínám – spočívá v tom, že kernelový modul využívající tu omezenou podmnožinu funkcí je jistou analogií k procesu, který taky může (omezeně) volat některé funkce kernelu, aniž by musel být pod GPL.

42
Vývoj / Re:Segmentation fault
« kdy: 21. 03. 2020, 09:40:32 »
Chyba práce s pamětí může znamenat, že zapisujete do místa, na které zapisovat nemáte. Pokud máte štěští, nikdo jiný to míšto v paměti nepoužívá a bude to fungovat. Pokud máte smůlu, místo v paměti může používat i někdo jiný. To ale může vést ke kolizím, které nastanou poněkud později a v jiné části kódu, než kde je chyba. A na chování mohou mít vliv i víceméně nesouvisející změny, jako změna ze select na epoll – začne se používat jiný kus paměti, a najednou začne docházet ke kolizi třeba i ve funkci, která je na tom nevinně.

Valgrind toho umí najít spoustu, i když úplně neprůstřelný není. Ale takovéto nástroje jsou dobrým začátkem. Umí detekovat chyby často mnohem dříve, než by se reálně projevily. Často přímo na místě chyby.

Opatrnost na malloc – zase se to nesmí přehnat. Viděl jsem i kód, který slokoval data na stacku a předal pointer na ně. Pokud se ten předaný pointer používá i po návratu z funkce, která ho předala, je to problém. Bylo by věštěním z křišťálové koule, jestli je to Váš případ, ale může být.

43
Vývoj / Re:Jak funguje Java KeyStore?
« kdy: 21. 03. 2020, 09:20:59 »
JKS s prázdným heslem: Teoreticky to možné je, otázka je, jak to pobere která aplikace. Tuším, že to bere i hodnotu null pro JKS bez hesla. https://stackoverflow.com/q/23629246/228114

Private key je privátní klíč pro přihlášení. Ten nemůže být v truststore ale v keystore. Nejde o to náhodně převádět mezi sebou různé formáty souborů, ale musíte vědět, co (jaký obsah) kam patří.

+1

Navíc některé formáty (třeba zmíněný JKS) mohou obsahovat obojí. To pak ale tuplem znamená, že se nelze orientovat jen podle formátu.


Jinak pokud mas potiz s tim zadat cestu k JKS truststore, muzes ty svoje veci nacpat naprasaka do defaultni Java truststore, default heslo je "changeit"

To bych moc nedoporučoval, tím ovlivníte truststore i dalších aplikací. A s trochou nešikovnosti důvěřujete další certifikační „autoritě“.

A jeste je moznost, najdi si spoustec a pridej k jave commadline parametr -D se specifikaci techto properties:
javax.net.ssl.keyStore = /etc/myapp/keyStore
javax.net.ssl.keyStorePassword = 123456

* Asi spíš myslíte trustStore než keyStore, že?
* Přijde mi to jako menší zlo než globální trustStore, ale i tak to může mít vliv i na místech, kde nechcete. Záleží na situaci.

44
Software / Re:RDP na Linuxu s Wine - bude to fungovat?
« kdy: 20. 03. 2020, 18:20:48 »
Nejsem si úplně jist, jakou roli tam hraje to USB, ale je to asi to první, co bych ověřil. Když jsem to kdysi zjišťoval, Wine nemělo podporu USB, a obávám se, že stále nemá.

V případě Mono jsem zkoušel v rychlosti poGooglit, a našell jsem pár možností, jak tam rozjet USB, ale vypadá to, že jde spíše o specifické knihovny s jiným API, tedy ne něco, s čím by jela aplikace pro Windows bez úprav…

45
Hardware / Re:Malá popularita F2FS na flash pamětech
« kdy: 20. 03. 2020, 08:03:37 »
Něco jako TRIM jsem na microSD už viděl, jen se tomu říkalo nějak jinak. Ale s fstrim to fungovalo. Nečekal bych to na 10 let staré kartě, možná ani na 5 let staré kartě (i když z té doby už nějaké karty budou) a možná ani na té úplně nejlevnější dnešní kartě, ale třeba na A1 (a snad nejen tam) by to snad už mohlo být. Statistiku nemám, ale ani Vy žádnou u svého trvzení neodkazujete.

Proč se neprosadilo tolik F2FS – spekulace a vzpomínky na to, co jsem někde četl:

* Někde jsem četl, že to prý není tolik otestované, aby si to třeba výrobci telefonů troufli nasadit.
* Tuším, že tam po čase s fragmentací dost klesala rychlost čtení.
* S A1 asi klesla potřeba řešit F2FS.
* S podporou discardu taky.

Stran: 1 2 [3] 4 5 ... 17