Omarchy (Wikipedie) je linuxová distribuce s dlaždicovým správcem oken Hyprland. Založena je na Arch Linuxu. Vydána byla v nové verzi 4.5.0. Nově také pro Apple Silicon, konkrétně pro M1/M2/M3/Neo MacBooky.
Byla vydána nová stabilní verze 8.3 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 156 s bezpečnostními opravami z Chromia 157. Přehled novinek i s náhledy v příspěvku na blogu.
Multimediální přehrávač mpv byl vydán ve verzi 0.42.0. Jde o větší balík změn po bezmála roce. Mimo jiné se lépe integruje s Waylandem nebo rozšiřuje podporu DVD/Blu-ray, např. umožňuje přehrávat rovnou obrazy médií (soubory iso).
Desktopové prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklé sloučením projektů Razor-qt a LXDE bylo vydáno ve verzi 2.5.0. Přehled novinek v poznámkách k vydání.
Byla vydána (𝕏) nová verze 8.0 LTS open source monitorovacího systému Zabbix (Wikipedie). Přehled novinek v oznámení na webu, v poznámkách k vydání a v aktualizované dokumentaci.
Byla vydána verze R14.1.7 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
Bazzite (Wikipedie), tj. linuxová distribuce vycházející z Fedora Linuxu a optimalizována pro hraní počítačových her, byla vydána ve verzi 45. S Open Gaming Collective (OGC) jádrem a novým Easy Anti-Cheatem pro Linux (EAC Linux v2).
MikroTik zveřejnil vlastní bezpečnostní upozornění potvrzující, že zranitelnost linuxového jádra postihuje také RouterOS 7. Jde o use-after-free při zpracování IPv4 TCP spojení s IP options. Zranitelnost se týká provozu směřujícího na TCP službu samotného routeru, nikoli paketů, které router pouze přeposílá. Opraveno v long-term od 7.24.6, v stable od 7.25.1 a devel od 7.26beta5.
Ve správci balíčků APT, používaném v Debianu a odvozených distribucích, byla nalezena a opravena kritická zranitelnost CVE-2026-109518. Vzdálený útočník může obejít ověření stažených balíčků pomocí přesměrování a dočasných chyb HTTP serveru.
<ShareKeys/> v kasp.xml (to je předpokládám jediný způsob). Po vygenerování prvních tří domén (A, B, C) všechno vypadalo OK, Keytag KSK byl u všech stejný, automatická rotace ZSK taky probíhala bez problémů a obecně všechno fungovalo jak má.
V průběhu roku jsem přidal další dvě zóny (D, E) k podepisování, opět bez problémů.
Nicméně o víkendu nastal čas rotace KSK, když jsem zjistil, že jsem buď udělal něco špatně, nebo sdílení klíčů funguje jinak než jsem čekal. Moje představa byla taková, že ten sdílený klič je globálně jeden, s jednou platností a při jeho rotaci jen umístím novou verzi k registrátorovi, jednou zavolám ds-seen a na rok bude zase klid.
Ve skutečnosti se ale ukázalo, že rotace byla požadovaná jen pro ty tři nejstarší domény a pro každou zvlášť jsem musel zavolat ds-seen. Původní KSK jsem v keysetu u registrátora nechal, jen jsem přidal nový klíč, takže překlad všech domén pořád funguje, ale nevím, jestli je to správný postup. Například netuším, co se stane, až dojde na rotaci u těch dalších dvou domén. Použije se ten právě vytvořený KSK nebo se vygeneruje další?
Takže můj dotaz je: udělal jsem někde chybu, nebo je tohle normální průběh? Díky.
Přikládám výpis existujících klíčů (KSK 29793 byl původně jako KSK i u domén A, B a C):
# ods-ksmutil key list --verbose Keys: Zone: Keytype: State: Date of next transition: Keytag: domenaA ZSK retire 2016-06-02 19:38:55 58674 domenaA ZSK active 2016-06-25 06:38:55 25407 domenaA KSK active 2017-05-29 20:55:13 29133 domenaB ZSK retire 2016-06-02 19:38:55 58674 domenaB ZSK active 2016-06-25 06:38:55 25407 domenaB KSK active 2017-05-29 20:55:01 29133 domenaC ZSK retire 2016-06-02 19:38:56 58674 domenaC ZSK active 2016-06-25 06:38:56 25407 domenaC KSK active 2017-05-29 20:52:36 29133 domenaD KSK active 2016-08-14 08:51:22 29793 domenaD ZSK retire 2016-06-02 19:38:56 58674 domenaD ZSK active 2016-06-25 06:38:56 25407 domenaE KSK active 2016-11-13 09:41:35 29793 domenaE ZSK active 2016-06-10 13:41:45 58674
Řešení dotazu:
Tiskni
Sdílej: