Skript pro automatickou aktualizaci aplikací (FireFox atp.) (diskuse)

[Max]

Zajímalo by mně, proč neoperuješ s https, ale používáš nešifrovanou komunikaci?
Také by mně zajímalo, k čemu je to dobré? Když chci udržovat nějakou aktuálnější verzi na více PC, tak si přeci rozjedu vlastní repo a řeším to systémově přes něj.
Zdar Max

[joshua]

Dělá ti dobře shazovat práci jiných ? Rači bys měl udělit tučňáka.

[Fuky]

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?

[smazáno]

Promin, ale v Linuxu fakt jedine pres balickovaci system. Rozbalovat tarbally nekam do /opt je fakt prasarna :-/. Uvidis sam.

Ale chapu, ze potrebujes nejnovejsi verze programu, ktere ti jeste nikdo nezbalil, a dokonce se to snazis poresit i ciste (kontrola klicu atd.) - kouknul ses treba na buildservice? Ono pokud by se ti povedlo toto zautomatizovat a hezky propojit s balickama, tak by to bylo mnohem uzitecnejsi.

[smazáno]

ad1. Pravda, ale ten klic v kroku "Prvni Spusteni" by si pres https stahnout mel, i kdyz pravda ze https v dnesnim pojeti, kdy se ve vychozim stavu duveruje stovkam CA, je uz pomalu security theatre.

[Fuky]

Souhlasím, proto si myslím, že je třeba věnovat získání správného klíče více energie a ověřit si ho případně na více nezávislých místech.

[Max]

ad 1) narážel jsem hlavně na stažení toho klíče přes http
ad 2) to jsem si také řekl, že by to mohl být dobrý začátek pro automatické buildování, ale osobně bych vždy buildoval a nenasazoval to za zády balíčkovacího systému (za předpokladu, že to budu používat na distribuci s balíčkovacím systémem)

[EPO]

Je takovy system odolny vuci replay attack ? Overuje se nekde, ze nainstalovana verze je nejnovejsi ?

[Fuky]

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ší.

[R]

http://mozilla.debian.net/

[ivan]

Tak to nie je moc aktualna foxka 24.5 ked teraz je 29.0.1.

Foxku si davam stabilnu do debianu, normalne ju rozbalim malym skriptikom, nac to komplikovat:

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

[Fuky]

Neověřuješ kdo je autorem balíčku, takže ti klidně někdo může podvrhnout svojí verzi, která si bude dělat v systému co chce.

[R]

Pre Wheezy je tam 29.0.1... Staci pridat do sources.list.d a uz len cez aptitude upgradovat ako ostatne baliky.

[R]

Bonus pre paranoikov: kluc k archivu sa nemusi overovat, staci nainstalovat balik pkg-mozilla-archive-keyring, ktory je sucastou stable Debianu.

[Petr Tomášek]

$ wget http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/latest/KEY
$ gpg --import KEY

nasrat

[Fuky]

Stáhneme a ověříme veřejný klíč...

[Petr Tomášek]

A to provedeme pomocí wget jak?

[Fuky]

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í.

[David Watzke]

Zrovna v dnešní době, kdy mají lidi nakradené openssl klíče a můžou udělat MITM, je to jedno

[Bystroushaak]

Ty jo. To je automatický script na rozbíjení všech doplňků? Málokdy jsem aktualizoval FF dřív, než pár týdnů po vydání nové verze, aby autoři stihli opravit co mozilla zase rozbila.

[pavlix]

V článku podle mě chybí nejdůležitější věc, tedy motivace. Už se nad tím pozastavilo několik lidí v diskuzi, dokonce tu padl i nějaký ten alternativní přístup a minimálně jeden pádný důvod, proč to nedělat.

[Fuky]

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á Debian
• uživatelé nevyužívají doplňky, takže jejich případné rozbití v nové verzi pro mě není podstatné
• skript lze použít i v jiné distribuci než je Debian, případně i pro úplně jiný SW, po menší modifikaci, např. pro děravý Flash, ale na to je v Debianu balíček flashplugin-nonfree

[pavlix]

nejčerstvější verze by měla mít bezpěčnostní aktualizace rychleji než verze ESR, ze které čerpá Debian

Je 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.

[Fuky]

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.

[pavlix]

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?

[Fuky]

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ší...

[pavlix]

Hmm, to zní jako zdroj. A skutečně se to týká několika málo balíků včetně Firefoxu. Pokud jde o oldstable, pokud to jde řešit takto jednoduše, je otázka zda by nestálo za to se přihlásit s tím, že máš řešení, a doladit skript od té míry, aby z něj padal výstup použitelný pro buildy pro Debian oldstable.

Nicméně, vzhledem k tomu, že se Firefox aktivně vyvíjí, tak bych viděl problém v tom, že tam může přibývat security problémů s každým updatem a není tam žádný prostor na stabilizaci. Takový software je podle mě potřeba považovat apriori za rizikový a podle toho se k němu chovat. Rychlá aktualizace je super, ale hlavní problém to podle mě neřeší, nicméně už alespoň chápu, o co se snažíš.