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 - Jan Ťulák

Stran: 1 2 [3] 4 5 ... 41
31
Server / Re:Google, Seznam vs. domácí server
« kdy: 02. 02. 2023, 22:09:17 »
Google a Seznam požadují pro přihlášení do svých služeb čím dál tím více údajů, jako jsou telefon, datum narození, v budoucnu možná bydliště atd. Jaké jsou alternativy a nebylo by lepší si pořídit jednoduchý domácí server na vlastní doméně?

Jaký máte na to názor?

nm

Jestli ti jde akorát o maily a kalendář, baví tě se v tom hrabat, nevadí ti, že občas prostě budeš mít ten server pár hodin nedostupný, a rád děláš doma technickou podporu, tak klidně.

Ale z hlediska soukromí si stejně moc nepomůžeš, protože většina mailů ti stejně bude chodit přes servery těch velkých hráčů, na sledování nepotřebují, abys tam měl účet, a odhadovat pro reklamu užitečné údaje jde na základě chování, zařízení, atd. A snahy o větší anonymitu naopak můžou vést k anonymitě menší - protože místo splynutí s davem najednou budeš vyčnívat. Těch lidí s vypnutým javascriptem moc není a ještě k tomu ti půlka webů ti přestane fungovat.

32
Server / Re:Dvě verze souběžně v rámci jednoho serveru
« kdy: 30. 01. 2023, 18:20:07 »
Tohle je záležitost balíčkovacího systému/distribuce a nastavení. Některé (například Gentoo, nebo do jisté míry Archlinux a Fedora) to umožňují. Jiné (Debian-based distra s APT) jsou optimalizované na happy path s jedinou verzí. Ono totiž nejde jen o verzi jednoho programu, ale o všechny knihovny a další závislosti, které v tu chvíli jako pavouka musíš také držet ve více verzích, a místo relativně jednoduchého stromu závislostí máš najednou těch stromů několik, musíš je nějak držet oddělené, a prostě je to hromada práce, která pro většinu uživatelů nemá smysl.

Koukám, že Almalinux má kořeny v RHEL. Máš tam dostupný balíčkovač dnf místo yum? Pokud ano, mělo by to jít, jen budeš muset dělat nějakou manuální práci: https://unix.stackexchange.com/questions/723298/can-i-install-multiple-versions-of-the-same-package-using-dnf

33
Hardware / Re:Externí šifrovaný disk
« kdy: 29. 01. 2023, 19:57:23 »
Takových už tu také pár bylo…
Jééé, já si právě vzpomněl na Hlodač. Až mi nostalgická slza ukápla.

34
Hardware / Re:Externí šifrovaný disk
« kdy: 29. 01. 2023, 19:00:07 »
Ovšem záleží i na tom k čemu to hledáš, protože např. do některých států (Čína, ale třeba i USA) žádný takto šifrovaný média se vozit nesmí, resp. imigrační tě donutí k dešifrování a kontrole dat.
Pokud tě zrovna vyhmátnou. A umí si dělat kopie disků, když se jim něco nezdá, nebo chtějí zrovna buzerovat. V minulé práci byla firemní politika "plně spolupracovat, nechat je dělat, co chtějí, a pak za hraniční kontrolou okamžitě zavolat na firemní security."

Takže řešení pro takovéhle situace je před cestou citlivá data někam nahrát, lokálně je smazat, a za hranicí si to zase stáhnout ze serveru a dešifrovat. Nebo se bez nich po dobu cestování obejít.


proc se tyhle diskuse  vzdy takhle arogantne zvrhnou v akademickou masturbaci?
a vzdy to konci stejne, protoze bezne zamky lze specialnim naradim otevrit, nema smysl dvere na ulici ani zavirat.

Protože otázky zase často jsou ve stylu "chci kouzelné dveře, co nepustí dovnitř nikoho, kromě mě, a lidí, které znám, ale nechci používat žádný klíč a nesmí to nic stát, jo a musí to fungovat bez elektriky a odolat i jadernému výbuchu." A pak se ukáže, že nakonec mu stačí obyčejný korálkový závěs. Ne vždycky, ale často jo.

Co tu padli otazky na ucel, tak ten je jednoduchy - chcem aby vyvojari mali ulozene zdrojaky na zasifrovanom disku a pracovali iba na nom. Takze nemusia riesi sifrovanie vo svojom systeme ani sa s tym nijako zaoberat.
Dole je odkaz na možné řešení, ale... tohle mi nepřijde jako dobrý nápad. Co třeba cache toho IDE? Nebo vývojář, kterému se ten externí disk zdá pomalý, a tak si to zkopíruje lokálně? Co uložené přihlášení do firemních systémů v prohlížeči, nemůže se přes to útočník dostat do repozitáře a ten kód si stáhnout? Nebo udělat mnohem víc škody nějak jinak třeba ukradnutím databáze zákazníků? Atd.

Plus, stejného výsledku dosáhneš i vytvořením jednoho šifrovaného adresáře/kontejneru přímo na systémovém disku, a odpadnou problémy s připojováním něčeho do USB. Pokud máte nějaký set-up skript, co připravuje vývojářské prostředí (instalace závislostí pro vývoj, konfigurace cest...), tak je možné to tam přidat a vývojáři nemusí řešit vůbec nic, kromě hesla.

Mimochodem, je potřeba, aby se firma mohla dostat do toho šifrovaného disku i bez spolupráce toho vývojáře?

Len si nakonfigurovat cestu v editore/ide na externy disk a to je cele. Keby sa disk pri ceste stratil niekde(v kaviarni, mhd, zlodej na ulici vytrhne tasku s ntb..) tak data su zasifrovane a nic sa nedeje, netreba panikarit a riesit teraz invalidaciu pristupov pre vsetkych ludi a stroje, vygenerovane kluce, tokeny a cojaviem co. Davnejsie v praci po nas chceli zasifrovanie vlastnych pc(ntb) kvoli klientskym kodom, takze tam som videl ze to je nedobre pre ludi takto riesit a zasahovat im do systemu a prostredia
Jak píšu nahoře, těch důvodů, proč šifrovat, je hromada. Víc než jen uložené zdrojáky, a platí to i pro osobní stroj. Při instalaci systému je to typicky otázka pár kliknutí (pokud to někdy není už i výchozí volba.) Ale chápu, že je nechceš nutit přeinstalovávat si soukromé stroje.
a preto externy disk(opakujem disk, neviem co su stale omielate usb kluce).
Klíčenka, aka přívěsek na klíče, ne klíč. USB flashdisk s vlastní bezpečností, jako https://www.czc.cz/kingston-usb-datatraveler-dt2000-32gb/184121/produkt - nepřipojí se to jako úložiště, dokud to nedostane správný pin.

A neviem co je nezrozumitelne na otazke. Jasne som napsial ze chcem hardeverove sifrovanie a plug-and-play funkcionalitu. Ci uz clovek raz pri spusteni zada heslo, alebo naskenuje odtlacok prsta je mi jedno. Ci to ma aplikaciu alebo nie je mi jedno len nech to ide na kazdom OS.

Ale pořád nevíme, jestli jde o pár MB, jednotky GB, nebo ta data s databázovými dumpy a podobně mají stovky GB. Je požadavek na velkou propustnost toho úložiště? Pokud je to klasická flashka, ať s vlastním šifrováním, nebo přes aplikaci, tak to bude hodně trpět na časté přepisy a náhodně umírat.

35
Software / Re:Doporučte multiplatformního správce hesel
« kdy: 26. 01. 2023, 08:10:47 »
Přidávám se k Bitwardenu, nahradil jsem jím LastPass. Jako alternativu jsem ještě zvažoval 1Password.

KeepAssXC na desktopu a KeepAssDX na mobilu
Dekuji, nevidim nikde ale aplikaci pro iOS.

Keepass má otevřený formát. Pro iOS těch aplikací, co ho podporují, existuje spousta. Osobně používám Strongbox.


OT:
Nic si nevymýšlím, nemám důvod. Dělali to servery seznamu asi v letech 19-22. Potvrzené těmi uživateli co jsem od nich dostával ty "jejich" emaily z ešopů.

Znak + a raději i - nemá v mailu co dělat. Normálním uživatelům je to naprosto k ničemu a implementované je to nekonzistentně, takže neni naprosto žádný důvod tuhle hloupost používat a propagovat.

Písmenka a tečky taky nemají v mailu co dělat. Kolik emailů už jsem viděl, co měly být poslané na adresu jako foo.bar@něco, ale skončily ve schránce foo@něco... Jestli on ten problém nebude někde jinde, než v tom plusku.

36
Studium a uplatnění / Re:Přiměřeně lehká IT VŠ
« kdy: 25. 01. 2023, 12:45:09 »
Předměty samy se lehčími nestanou, ale pokud člověk potřebuje prostě víc času na studium, protože mu to nejde (nebo na to nemá tolik času kvůli práci...), tak snížení počtu předmětů (a zkoušek) v semestru o 1/3 může pomoct.

37
Vývoj / Re:Maximální délka e-mailové adresy při registraci
« kdy: 15. 01. 2023, 16:43:04 »
Nevymýšlel bych kolo a použil knihovní funkce pro sanity check emailu. Jinak se stane, že ta registrace s vlastní validací pustí skrz třeba escape sekvence, což (afaik) není povolené. A zatím co v obecném textovém řetězci nejspíš nevadí, u mailu, který se pak předá nějakým dalším knihovnám, to může vést k nějaké zranitelnosti, zatím co délka je zbytečně zkrácená a háže potenciálním uživatelům klacky pod nohy.

A emailová adresa je podobný standard, jako většina dalších věcí na internetu. Nějaké to RFC a k tomu zažité konvence.

38
Server / Re:VPS hosting pro minecraft server
« kdy: 15. 01. 2023, 10:49:07 »
Záleží na verzi.

Minecraft Java Edition (tj. klasický Minecraft) server poběží všude, kde běží Java. Což je pomalu i každý druhý toustovač. Bedrock edition je v tomhle asi horší, ten je (myslím) v C++ a nemá tedy výhodu běhu v JVM; Podpora konkrétní architektury musí být přímo v něm. A co jsem rychle kouknul, tak Bedrock edition nemá podporu pro ARM.

Koukám ale, že existuje https://geysermc.org jako bridge mezi Bedrock klientem a Java serverem. Takže možná to půjde nějak propojit, pokud máš opravdu Bedrock verzi, ale chceš server na ARMu.

39
Hardware / Re:Jablotron bez originální SIM karty
« kdy: 12. 01. 2023, 09:47:49 »
Kamery obecně mohou odradit nějaké ty malé zlodějíčky, co pak jdou raději o dům vedle. Tam k tomu účelu poslouží prakticky jakákoli kamera.
To asi i věrná maketa/vyřazená nefunkční kamera.

40
Může to být závislost něčeho dalšího. Koukni se, jestli na těch balíčcích něco nezávisí. Alternativně mohly být nějak označeny při manuální instalaci jako frozen, či tak něco, pokud to apt umí.

41
Hardware / Re:Jablotron bez originální SIM karty
« kdy: 11. 01. 2023, 09:13:20 »
Nejde ani tak o ten certifikát, jako o rozdíl mezi kamerou, co funguje jak má, a kamerou, kterou si zloděj před vstupem na dálku vypne. Nebo, u těch telefonů, zaplátovaným a relativně bezpečným systémem versus hromada čínského malwaru předinstalovaná už z fabriky.

42
Software / Re:Náhodné pořadí grep stdout +stderr
« kdy: 09. 01. 2023, 11:58:35 »
Celé je to jen otázka paralelismu.

Jednotlivé příkazy spojené přes rouru běží paralelně, přesně jak píše Jano. A v tomhle případě nečekají na uzavření vstupu - grep to bere, jak to přijde a hned posílá dál. Což ale přidá latenci, a když stderr jde mimo grep, tak bude záležet na náhodě, jak se to načasuje.

Pokud ten řetězec "flow entries have been shown" má být na konci a po spojení stdout a stderr ho to dává někam doprostřed, tak to bude asi způsobené tím, že conntrack flushne stdout až úplně na konci svého běhu, a pro velké množství textu to vyprázdnění cache nějakou dobu trvá. Zatímco stderr se flushne synchronně hned (a nebo je prostě jen málo dat v stderr cache a tak to doběhne hned). A tím pádem se to promíchá.

43
Vývoj / Re:Ověřené postupy pro logování
« kdy: 28. 12. 2022, 08:00:19 »
Souhlas s tím, co napsal Tomas-T.

U logů platí “raději více, než méně.” Jen v případě dat, která by mohla i z dálky smrdět osobním údajem, je třeba hodnoty obfuskovat ještě před zápisem. A vyplatí se mít nástroje na filtrování a prohledávání. Třeba ten Elastic + Kibana, na které tady na Rootu bývá reklama.

Jestli logy dělit do tříd podle závažnosti, a do kolika, to je už případ od případu. Detekujete ve watchdogu chyby podle objevení se libovolného error logu, nebo podle konkrétní zprávy, nebo si aplikace hlídá zdraví sama a watchdog se jen ptá nějakého health API? Kolik lidí na tom pracuje, dokážete vůbec uhlídat konzistenci těch úrovní?

44
Hardware / Re:Firemní počítač na soukromé použití
« kdy: 28. 12. 2022, 07:43:14 »
Velký korporát. Jako dev mám admin práva, možnost používat Win, Mac i Linux. Nicméně ve firemní síti je veškerý provoz MITMnutý a některé weby nedostupné z vnitřní sítě (LastPass třeba), nainstalovaný SW, šifrovaný disk, atd. se skenuje a hlídá bloatwarem. I když je to asi hlavně kvůli licencím, nevím o tom, že by se jakkoliv řešily oficiálně zakázané aplikace, dokud není průser. Procesně je asi možné mít notebook i pro nepracovní využití, ale musí se to nějak schválit.

Ale! Tohle je záležitost konkrétní business unit.  Stejná budova, jiné patro a jiná BU a jiné politiky. U velkých korporátů můžou být v rámci formy obří rozdíly, jak v politikách, tak v mentalitě. Však je to, koneckonců, hromada podniků pod jedním jménem. :D

45
Server / Re:Provoz po HTTPS v produkci
« kdy: 14. 12. 2022, 13:41:37 »
Manuální obnovování certifikátů je peklo, kvůli kterému jsem v dobách před Let's Encrypt vůbec HTTPS nenasazoval. Vede to k chybám a pokud máte stovky webů, tak se z toho zblázníte. Automatizace je cesta, která to celé řeší stylem „nasaď a zapomeň“. Není potřeba nic vyvíjet, všechno je hotové, připravené k nasazení. Já na produkci používám ACME.sh, nasazení je jednoduché, dá se krásně automatizovat.

To vse je hotove a da se krasne automatizovat funguje tak maximalne, pokud mate dany certifikat na jednom serveru/sluzbe. Co v pripade, kdy certifikat je na X serverech? To uz to nasazeni neni tak jednoduche, ze?

A proč by to někdo dělal? To dává smysl při ruční obnově certifkátu, kdy je stejný certifikát všude proto, aby stačilo generovat jeden a pak se to jen rozkopíruje. Teď každý server může sám nechat vystavit svůj vlastní unikátní certifikát.

A pokud máte nějaké velké komplikované prostředí, kde to sdílení z nějakého důvodu fakt potřeba je, a kde se to nedá řešit interní CA + proxy, co to přebalí, jak to většinou dělají velké firmy... no, pak si můžete tu automatizaci upravit. Protože to už pak asi není garážová firmička se dvěma zaměstnanci.

Plus, vždycky je tu možnost vrátit se do starých časů, vytáhnout šekovou knížku a zaplatit si za certifikát s dvouletou platností a ruční správou. Let's Encrypt není jediný zdroj certifikátů.

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