Eftersläpning av paketversioner - en säkerhetsrisk?

Ett vanligt argument för *nix är just att säkerhetsfixar går ut så snabbt (som du säger: ofta på någon dag, med få undantag åtminstone inom en vecka), så jag kan inte säga att jag tycker det är ett generellt problem. Vissa stora, ändå marknadsledande, andra produkter har en historia av att dröja månader för kritiska säkerhetsbrister, utan att detta för den sakens skull får samhällets infrastruktur att kollapsa.

Ifall distarna hade börjat slänga ut otillräckligt testade patchar till slutanvändare så hade det slutat i förskräckelse snabbt, speciellt som dessa system ofta används på platser med höga krav på stabilitet (inte bara "önskan om" som för en hemanvändare), så att det går en dag eller tre är snarare att föredra. Självklart finns specifika motexempel att finna, men i allmänhet tror jag inte det är en svårförsvarad åsikt. Fler ögon på patcharna leder till högre kvalité.

Man måste ju inte heller använda distributionens paket, så om du anser att hålet i Firefox är tillräckligt farligt för att inte våga använda browsern så kan du installera upstreamversionen så länge. Möjligheten att hålla koll på liknande säkerhetshändelser för de 10 000+ paket ingår i distributioner är ju dock obefintlig på personlig basis, så för bästa resultat så får man helt enkelt lita på att distributionen sköter sig. På samma sätt får man helt enkelt lita på att det eventuella företag som ligger bakom ens produkt sköter sig.

Har man extrema krav på stabilitet så kan man hålla sig till en långsam (med helt nya programvaruversioner, inte säkerhetsfixar) distribution som t ex Debian Stable, där liknande säkerhetshål som i Firefox 10 ofta undviks genom att bara köra väldigt mogna programvaruversioner som kontinuerligt får portade säkerhetsfixar.

Vill man ha en helt säker dator så kan man som första steg sluta använda den . Buggar och hål kommer alltid att finnas, så fort man vill ha någon som helst funktionalitet. Man ska jobba med att minimera risker, men att helt utesluta dem inkräktar för mycket på användningsområdena.

Det var OpenSSL och inte OpenSSH, men jo, Debian och alla dess derivat (vilket är rätt många). Var ett exempel på "för få ögon" på den patchen (till stor del pga att kommunikationen mellan Debianpakethandhavaren och OpenSSL mer eller mindre inte existerade); två kommenterade rader minskade entropin så pass mycket att brute-force-attacker på nycklar blev möjliga (vilket främst möjliggör man-in-the-middle-attacker och lättare att brute-force:a SSH-åtkomst om "endast nyckel"-inloggning var tillåten).

Det var ju dock inte ett känt säkerhetshål som existerade under lång tid. När det upptäcktes så blev en patch skriven och utrullad inom en dag. Nycklar behövde genereras om, så det ledde till användarkrångel, men hanteringen när väl sårbarheten blev känd var exemplarisk. Det var ingen som försökte mörka och säga att "det är inte så farligt" osv, snarare slogs det upp stort av Debian själva.

Ja så var det. Mindes inte detaljerna omkring det.

Men vem ska avgöra om det är "kritiskt" om inte just många ögon? Det går inte att dels säga att man vill ha en process där ändringar som träder i kraft är tillräckligt testade, samtidigt som man ger tillåtelse för att helt gå förbi dessa kontroller "då och då". Tiden ska givetvis vara så kort som möjligt (som sagt: dagar är bättre (och även i högriskfall godtagbart) än månader), men att tumma på kvalité för att minska tider är inte möjligt utan att kompromissa säkerheten i stort.

Återigen, vem ska bestämma vad som är säkerhetskritiskt? Det måste pakethanteraren (personen/gruppen, inte "programmet som sköter pakethanteringen") göra, om man inte vill ge full access till en distributions paketsystem för varenda extern mjukvaruutvecklare. Det vore ett säkerhetshål som heter duga.

Om du litar på Firefoxteamet så mycket att du vill låta dem göra liknande beslut för ditt system så kan du installera versionerna direkt från dem, men distributionen kan inte per automatik gå in och ge dessa rättigheter för alla slutanvändare. Det vore oansvarigt, då de inte kan garantera att de sett över/testat ändringarna innan de satt sin stämpel på det.

Microsoft jobbar med att ha mycket längre ledtider innan fixar rullas ut (de släpper öht bara patchar en viss veckodag). "En vecka" ses som en sorts drömtid i den kontexten.

MSRC senior program manager Steve Adegbite:

Samma tänk här: skulle de börja rusha ut fixar så skulle de få mångdubbelt större problem när någon halvbra patch går genom nätet och börjar orsaka oväntade problem.

Långa ledtider är givetvis inte bra i sig, men om de anser att det är vad som krävs för att deras process ska vara tillräckligt säker så får det ju vara så. Världen med öppen källkod (i vilken ju t ex Mozilla ingår) anser dock allmänt att just korta ledtider, inklusive tillräckliga kontroller av patchar, är en av deras stora fördelar. En större studie skulle dock behövas för att säkerställa detta samband kvantitativt, men personligen litar jag starkt på kompetensen hos de som sköter t ex Debianprojektet.