Poslední příspěvky

Stran: [1] 2 3 ... 10
1
Server / Re:Certifikáty na souborovém systému jen ke čtení
« Poslední příspěvek od Filip Jirsák kdy Dnes v 13:56:23 »
Aka dlha byva tato doba? Je nejaky mechanizmus na query "je novy certifikat", alebo v sucasnosti sa spolieha na to, ze pocas tejto doby prebehne update, ktory ten novy certifikat ziska?
Obvykle je to několik měsíců, i přes rok. Ale ono je to dost různé, protože často je ta změna kořenového certifikátu důsledkem jiných změn.

Pokud je víc alternativních certifikačních cest (což je třeba případ výměny kořenového certifikátu), je možnost při vydávání certifikátu si zvolit, která cesta se má použít. Takže ty informace jsou dostupné přes API. A Let's Encrypt o tom také dopředu informuje, takže je dobré sledovat třeba jejich blog.
2
Server / Re:Certifikáty na souborovém systému jen ke čtení
« Poslední příspěvek od Filip Jirsák kdy Dnes v 13:48:50 »
Aktualne maju RSA root do 2030-06-04
To mají napsané v textu, nicméně ve skutečnosti je i ten RSA root vydaný s platností do 2035-06-04.

Moznost vlastnych certifikatov (ako pisu Petr Krcmar a Filip Jirsak vyssie) nastupuje az v pripade, ak zavrhnes povodnu ideu fungovat pod Let's Encrypt, pripadne budes chciet mat nejaku vlastnu zalohu napr. pre pripad ze LE skonci.
Nikoli, i DANE nebo používání stále stejného klíče je možné použít s certifikáty od Let's Encrypt. Ten HTTPS klient v zařízeních by sice používal DANE nebo by měl v sobě několik klíčů a bylo by mu jedno, že jsou ty certifikáty vystavené pomocí LE. Ale server by měl normálně uznávané certifikáty, takže kdyby se k serveru připojil někdo běžným webovým prohlížečem (třeba proto, že by ten server poskytoval i nějaké webové rozhraní), dostal by klasický certifikát od LE.

Na bezpecne fungovanie ale na klientovi tiez potrebujes to iste - nejake ulozisko certifikatov, kde vies novy certifikat pridat a stary zmazat.
Není to potřeba, pokud si budete věřit, že nedojde ke kompromitaci privátního klíče.

Tohle už se řeší snadno, do toho klienta se dá víc veřejných klíčů, kterým věří. Jeden soukromý klíč se pak nasadí na server a ostatní se nechají bezpečně v záloze. Když něco selže, vyndá se jeden ze záložních klíčů a jede se dál.
To je dobré řešení, ale pak je potřeba mít zajištěné, aby nemohlo dojít ke kompromitaci privátního klíče, tj. mít privátní klíč v HSM nebo aspoň nějakém USB tokenu.
3
Perl regex (-P) a extended regex (-E) jsou dvě různé implementace, rychlost je může dost lišit. A mají trochu jinou syntax. Mimochodem, -P -z je experimentální kombinace.

Co má být ".+?"? Nemá to být ".*"? (Z hlavy nevím priority.)

Bez -K se lze obejít použitím nástroje sed. Buď následně odstranit všechna http:// ze začátku řádku, případně se na greo vykašlat úplně a řešit to jen sedem.
4
Server / Re:Certifikáty na souborovém systému jen ke čtení
« Poslední příspěvek od majvan kdy Dnes v 13:32:31 »
@majvan - ak predpokladas, ze zariadenie ma fungovat dlhsie ako 5-6 rokov, tak urcite bude potrebovat neaky extra storage, kam vies nahrat nove root certifikaty Let's Encrypt. Aktualne maju RSA root do 2030-06-04 a ECDSA root do 2035-09-04, ale je sanca, ze jeden alebo aj oba budu rotovat aj skor.

Vdaka za odpoved. Pozeral som tiez nejake certifikaty a ISRG, ktory je root pre Let's Encrypt ma naozaj do 2035. Nakolko vsak tvrdite viaceri, ze budu rotovat skor, pozrel som si, ako to prebieha.

Ak spravne chapem, tak je tam nejaka perioda prekryvu, kedy je este platny stary certifikat a uz je platny aj novy certifikat. Pocas tejto periody prekryvu je potrebne patchovat operacne systemy (alebo prehliadace / systemy s vlastnym uloziskom root certifikatov).
Aka dlha byva tato doba? Je nejaky mechanizmus na query "je novy certifikat", alebo v sucasnosti sa spolieha na to, ze pocas tejto doby prebehne update, ktory ten novy certifikat ziska?
5
Server / Re:Certifikáty na souborovém systému jen ke čtení
« Poslední příspěvek od mark42 kdy Dnes v 12:48:21 »
@majvan - ak predpokladas, ze zariadenie ma fungovat dlhsie ako 5-6 rokov, tak urcite bude potrebovat neaky extra storage, kam vies nahrat nove root certifikaty Let's Encrypt. Aktualne maju RSA root do 2030-06-04 a ECDSA root do 2035-09-04, ale je sanca, ze jeden alebo aj oba budu rotovat aj skor.

Moznost vlastnych certifikatov (ako pisu Petr Krcmar a Filip Jirsak vyssie) nastupuje az v pripade, ak zavrhnes povodnu ideu fungovat pod Let's Encrypt, pripadne budes chciet mat nejaku vlastnu zalohu napr. pre pripad ze LE skonci. Na bezpecne fungovanie ale na klientovi tiez potrebujes to iste - nejake ulozisko certifikatov, kde vies novy certifikat pridat a stary zmazat.

Mimo toto neexistuje cesta, ako to moze bezpecne fungovat. Vastne ano, raz za cas vymenit cele zariadenie (resp. k update firmwaru nahrat aj nove root crertifikaty, ak to zariadenie umoznuje).
6
Software / Velmi pomalý grep
« Poslední příspěvek od mikesznovu kdy Dnes v 12:44:03 »
Mám problém u 3MB vstupního textu, pouštím na něj grep a vypisuje to na terminálu asi 4-8 výskytů za sekundu -což je tragédie.  (armv7l Cortex A53 38 BogoMips) víc jak 30s. asi Jak to urychlit?  Vtipný je ,že když místo patternu  změním https: za http: tak je to do 5s hotové i když tam ponechám  výraz, které je pro https: pomalý[^/]+. , neboli  to není triviální https:..............

to nejduležitější: Přepínače jsou -o a -P.  Výraz je
:   "https://\\K[^/]+"
Zkoušel jsem to downgradovat postupně, až jsem došel na na  grep -o https:................................. Což je dostatečně rychlé. Stejně rychlé jako  -o -E https:.{60}... To by šlo použít (a následně použít pípu s druhým grepem, což bude mnohem rychlejší na menším množstvím textu), ale má to jednu nevýhodu, že to vyřadí některé výskyty, kde se vyskytuje nový řádek ,což tedy nechci. A znak CR+LF se javascriptu vyskytuje ,že

Varianty:
odmazat \K
nahradit [^/]+ za .+?/ (funguje jeno s grep -P , zatímcto s grep -E to tiše funguje chybně)
nahradit za ....

Kód: [Vybrat]
curl "https://www.nytimes.com/fides/api/v1/privacy-experience?show_disabled=false&region=eea&component=overlay&has_notices=true&has_config=true&systems_applicable=true&include_gvl=true&include_meta=true" |grep -Eo ":\"https://.{45}" | grep
# je rychlé ale vyřadí to záznamy kde se vyskytuje newline po 45 znacích

Za další , zkusil jsem magický přepínač grep -z. ale s přepínačem -P je pomalý, -s E rychlý. proč?


https://www.nytimes.com/fides/api/v1/privacy-experience?show_disabled=false&region=eea&component=overlay&has_notices=true&has_config=true&systems_applicable=true&include_gvl=true&include_meta=true


Mimochodem doporučuji to  sosnout ,wgetnout  grepnout ,sortnout a uniqnout a uvidíte věci . (Je tam pár false positives)
7
Desktop / Re:Proč mi zabiják OOM zabil Chromium
« Poslední příspěvek od Jan Fikar kdy Dnes v 12:21:00 »
2GB RAM je na Chrome málo a ještě ji užírá swap v zram. To bych zrušil a udělal pořádný swap (4GB?) na nějakým SSD.  Pokud chcete, tak jde ten swap taky komprimovat:


echo 1 > /sys/module/zswap/parameters/enabled
echo 1 > /sys/module/zswap/parameters/same_filled_pages_enabled
echo zstd > /sys/module/zswap/parameters/compressor
echo z3fold > /sys/module/zswap/parameters/zpool

Celkem pomáhá zapnout LRU_GEN, jestli je jádro alespoň 6.1:

echo y > /sys/kernel/mm/lru_gen/enabled


8
Desktop / Re:Proč mi zabiják OOM zabil Chromium
« Poslední příspěvek od Vít Šesták (v6ak) kdy Dnes v 12:07:09 »
Defaultní hodnoty – to mi moc neřekne, když nevím, o jakou jde distribuci. A i kdybych věděl, asi to nechci dohledávat a doufat, že najdu aktuální informaci.

OK, pokud je plný swap, tak problém asi nebude ve swappiness.

ZRAM je problém v některých konfiguracích. Může mít sebelepší kompresní poměr, ale reálně jsem viděl situace, kdy chyběla RAM, kernel se snažil swapovat, ale nemohl  zapisovat, protože chyběla RAM. Nakonec to systém po záseku nějak vyřešil (možná OOM kill). Ale v takové situaci na kompresním poměru moc nesejde.

Ad 3.8 GiB – ono to nejde moc sčítat, když je swap v RAM…

Usnutí na disk – od toho je právě swap. Je možné mít druhý swap, který bude na disku (/ SSD / microSD / …) a bude mít menší prioritu. Nečekal bych od toho ale zázraky a pochybuju, že by kernel uměl nějak rozumně automaticky přelít obsah z ZRAM swapu do druhého swapu. A pokud tím úložištěm bude flashové úložiště bez rozumného wear levelingu, nečekal bych dlouhou životnost. Zejména u microSD může být problém. Možná u A1 a lepších bude rozumný controller (ale ani to bych nebral na 100 %), možná u průmyslových to bude lepší.
9
Sítě / Re:Výběr síťových prvků
« Poslední příspěvek od uwe.filter kdy Dnes v 11:57:02 »
Citace
Co se týče bezpečnosti, tak veškerá data jsou v cloudu u 3. stran, nic není uloženo na fyzickém úložišti v ordinacích.

No tak to potěš koště.
10
Hardware / Re:Nový monitor na práci vývojáře
« Poslední příspěvek od to_je_jedno kdy Dnes v 11:56:48 »
Dell Professional, 4k, velikost dle kvality oci.
Stran: [1] 2 3 ... 10