V Londýně probíhá dvoudenní Ubuntu Summit 25.10. Na programu je řada zajímavých přednášek. Zhlédnout je lze také na YouTube (23. 10. a 24. 10.).
Gemini CLI umožňuje používání AI Gemini přímo v terminálu. Vydána byla verze 0.10.0.
Konference OpenAlt 2025 proběhne již příští víkend 1. a 2. listopadu v Brně. Nabídne přibližně 80 přednášek a workshopů rozdělených do 7 tematických tracků. Program se může ještě mírně měnit až do samotné konference, a to s ohledem na opožděné úpravy abstraktů i případné podzimní virózy. Díky partnerům je vstup na konferenci zdarma. Registrace není nutná. Vyplnění formuláře však pomůže s lepším plánováním dalších ročníků konference.
Samsung představil headset Galaxy XR se 4K Micro-OLED displeji, procesorem Snapdragon XR2+ Gen 2, 16 GB RAM, 256 GB úložištěm, operačním systémem Android XR a Gemini AI.
Před konferencí Next.js Conf 2025 bylo oznámeno vydání nové verze 16 open source frameworku Next.js (Wikipedie) pro psaní webových aplikací v Reactu. Přehled novinek v příspěvku na blogu.
Sovereign Tech Fund oznámil finanční podporu následujících open source projektů: Scala, SDCC, Let's Encrypt, Servo, chatmail, Drupal, Fedify, openprinting, PHP, Apache Arrow, OpenSSL, R Project, Open Web Docs, conda, systemd a phpseclib.
Bylo vydáno OpenBSD 7.8. S předběžnou podporou Raspberry Pi 5. Opět bez písničky.
Valkey (Wikipedie) byl vydán v nové major verzi 9.0. Valkey je fork Redisu.
Byly publikovány informace o kritické zranitelnosti v knihovně pro Rust async-tar a jejích forcích tokio-tar, krata-tokio-tar a astral-tokio-tar. Jedná se o zranitelnost CVE-2025-62518 s CVSS 8.1. Nálezci je pojmenovali TARmageddon.
AlmaLinux přinese s verzí 10.1 podporu btrfs. XFS bude stále jako výchozí filesystém, ale instalátor nabídne i btrfs. Více informací naleznete v oficiálním oznámení.
ad 1. Je jedno zda-li stáhnu archív přes http nebo https, pokud mám správný veřejný klíč, tak mám i ověřeno, že archív pochází od majitele klíče privátního. Co by podle tebe přineslo https?
ad 2. Mě osobně napadá hned několik použití. Server, který poskytuje systém přes NFS X bezdiskovým PC (v tomto případě je vlastní repozitář zbytečný, využíval by ho pouze tento server). Binárky pro balíček ve vlastním repozitáři musím také někde stáhnout, což zařídí právě tento skript, pak už není problém automaticky vygenerovat a podepsat balíček. Jak by jsi to udělal bez něj?
ad 1. Dle mého názoru je nejvíce kritické místo získání veřejného klíče. Pakliže není tento klíč podvržený a autorům není odcizen klíč privátní, tak nevidím příliš prostoru pro to, aby někdo podvrhu vlastní verzi archívu, případně využil "replay attack".
ad 2. Vycházím z předpokladu, že se na http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/latest nachází vždy nejnovější verze. Je tedy pravda, že by útočník mohl podvrhnout sice oficiální verzi od Mozilla Foundation, ale mohla by to být verze starší, která obsahuje více známých a snadněji zneužitelných bezpečnostních chyb. Tento problém vyřeším tak, že ještě před instalací budu kontrolovat verzi přímo v archívu firefox/platform.ini a nebudu porovnávat verze jako řetězce, ale jako sekvenci čísel, s tím, že nově instalovaná musí být větší.
cat firefox-update.sh if [[ $# -eq 0 ]] ; then echo 'Argument je meno stiahnuteho suboru firefoxu v tvare firefox-29.0.1.tar.bz2' exit 1 fi rm /usr/lib/firefox/ -fr cd /usr/lib/ tar xvjf /home/jj/Downloads/$1 rm /usr/bin/firefox ln -s /usr/lib/firefox/firefox /usr/bin/firefox
$ wget http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/latest/KEY $ gpg --import KEY
nasrat
Ano, věta "Stáhneme a ověříme veřejný klíč" není jednoznačná, upřesním jí tedy. Milý uživateli Petře, stáhni si veřejný klíč, klidně pomocí "wget http://" a ověř si jeho pravost jak jsi zvyklý, podle svého nejlepšího vědomí a svědomí.
Každý jsme totiž jinak paranoidní. Někdo důvěřuje certifikátu podepsanému od DigiCert Inc, někdo i certifikátu podepsanému od DigiCert Sdn. Bhd. Další zase věří, že se mirroru nemůže nikdo zmocnit. A někdo zase pro změnu kontroluje fingerprint veřejného klíče na více nezávislých místech. Rozebírat to by vydalo na článek.
Bude fajn, když se s námi podělíš o informace jak to řešíš ty, kde vidíš potencionální nebezpečí a co už je podle tebe příliš paranoidní.
Z mé strany je motivace následující:
nejčerstvější verze by měla mít bezpěčnostní aktualizace rychleji než verze ESR, ze které čerpá DebianJe vcelku běžné, že distribuce implementují bezpečnostní opravy ve stejnou dobu jako upstream, takže toto zdůvodnění nelze aplikovat bez analýzy bezpečnostních problému konkrétního software v konkrétní distribuci. Často může být tento přístup naopak kontraproduktivní kvůli zanesení bezpečnostních chyb ještě před jejich odhalením. Ostatní body nepovažuju za motivaci, nýbrž obhajobu.
Pokud mám správné informace, tak momentálně by to mělo fungovat tak, že se udělá nejprve aktualizace nejnovější verze FireFoxu, posléze se udělá backport do verze ESR a ten převezme i tým Debianu. S časem bude aktuální verze FireFoxu vzdálena verzi ESR víc a víc. Takže předpokládám, že nejvíce úsilí se zaměřuje právě na aktuální verzi.
Není to obhajoba, snažil jsem se reagovat na "minimálně jeden pádný důvod, proč to nedělat" a "alternativní přístup", jen jsem se snažil uhádnout co konkrétně jsi měl na mysli.
Pokud mám správné informace, tak momentálně by to mělo fungovat tak, že se udělá nejprve aktualizace nejnovější verze FireFoxu, posléze se udělá backport do verze ESR a ten převezme i tým Debianu.Chceš říct, že má Firefox v Debianu výjimku a jeho bezpečnostní problémy se ve stable řeší čekáním na opravu v ESR? Máš pro to nějaký relevantní zdroj?
Mrkni se na iceweasel - several vulnerabilities. Mmj. je pro mě důležité mít FireFox s opravovanými chybami i v oldstable, ale na to nemá Debian kapacity, skript to opět řeší...
Tiskni
Sdílej: