Open source er usikkert

Hvis du har læst Eric Raymonds essay Katedralen og basaren kender du ganske givet til Linus' lov: 'Med nok øjne er alle fejl banale?.

Med udgangspunkt i Linus? lov mener mange, at open source-programmer er mere sikre, fordi klidekoden er åben, så enhver har mulighed for at finde fejl i koden.

Måske mener du også, at fordi Microsoft historisk har haft en lang række sikkerhedsproblemer i deres produkter, og fordi Microsoft udvikler closed source-programmer, så er open source-programmer mere sikre

Jeg vil vove den påstand, at et programs sikkerhedsniveau ikke har noget at gøre med, hvilken udviklingsmodel der anvendes. Sikkerhed er som regel et designproblem, og det kommer før beslutningen om at åbne eller lukke koden.

Microsoft har haft mange problemer, fordi de fokuserede på funktionalitet og ikke på sikkerhed. Og fordi der er en fremherskende monokultur, der gør det oplagt at skrive angrebskode til MS-platformen. Hvis situationen var omvendt, og Linux i stedet var lige så udbredt, som Windows er nu, så ville vi formentlig også se en lang række problemer i Linux-kernen.

Selvfølgelig er der en fordel i, at koden er åben og tilgængelig for koderevision, men det er jo desværre ikke ensbetydende med, at der rent faktisk foregår koderevision. Open source er desværre ikke en silver bullet, hvad angår sikkerhed. Der findes god og dårlig kode både i open og closed source-verdenen.

Desuden er problemet med at finde fejl i kode, at det er så forbandet vanskeligt.

Hvor lang tid tager det dig fx at finde en fejl i denne kode?

while (c == '\t' || c = ' ' || c == '\n')

C = getc(f);

(Ja ja, Poul-Henning, men nu er det jo læserne, jeg spørger.)

Ok, måske tog det ikke så længe. Det var jo også kun to isolerede linjer, hvor du vidste, at der var en fejl. Men hvis jeg nu fortæller dig, at koden er fra Andrew Konigs bog C Traps and Pitfalls (1988) samt at tusinder af kvalificerede programmører læste koden, før der var én, som opdagede fejlen?

Et af de store problemer med at finde fejl i kode er selvfølgelig, den sjældent er så åbenlys som ovenstående eksempel. Og selv om den er så åbenlys, så forsvinder fejlen ofte i mængden af kode. Desuden forværres sikkerhedsproblemer af et højt kompleksitetsniveau i løsningen, som gør det overordentligt vanskeligt at overskue konsekvenserne af beslutninger.

Sikkerhed handler i langt højere grad om design, design og atter design, end det handler om udviklingsmodeller.

Derfor er open source software i gennemsnit præcis lige så usikker som alt andet software.

Kommentarer (21)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Poul-Henning Kamp Blogger

Jesper,

Netop fordi programmering er svært, ihvertfald hvis det skal være korrekte programmer der kommer ud af det, er der brug for at så mange som muligt kigger på kildeteksten.

Jeg har altid argumenteret for at der er tre software modeller:

Closed source

Open Source (Read Only)

Open Source (FOSS)

I gamle dage var det faktisk den midderste model der galt, man kunne i næsten alle tilfælde få kildeteksten til sit operativsystem på microfilm hvis man ville.

Copyright reglerne betyder at Microsoft godt kunne frigive Windows kildeteksten under en licens der kun tillod folk at læse den (som en bog) men ikke at kompilere den eller kopiere den.

Jeg er sikker på at de ville få bedre og flere fejlrapporter på den måde.

Men det kræver selvfølgelig at man ikke skammer sig over sin kildetekst :-)

Poul-Henning

PS: der er to fejl :-)

  • 0
  • 0
#2 Helge Svendsen

"Derfor er open source software i gennemsnit præcis lige så usikker som alt andet software."

Når man taler om usikkerhed og fejl så tror jeg du har ret. Det er givetvis ikke den store forskel på antal fejl.

Derimod er det meget lettere selv at gøre noget for at finde omtalte, og meget meget lettere at patche det hurtigt i kritiske systemer.

Prøv at sammenligne IIS med apache og lad være med at kigge på antal fejl. Prøv i stedet at kigge på, hvor længe en fejl er om at blive rettet.

  • 0
  • 0
#3 Død Profil

Jeg vil så vove den påstand at der i større OpenSource projekter (kritiske systemet som Nikolaj skriver) som minimum er den samme mængde kode-review som i closed-source projekter.

Det er et yndet eksempel at trække Stallman op af hatten fordi han er en "purist" indenfor OpenSource.

De få Java OpenSource projekter jeg har deltaget i, har alle været sponsorerede af organisationer hvor der, ligesom ved "normale" projektforløb, blev afsat tid og penge til QA. Jeg forestiller mig at det er det samme for andre større OpenSource projekter.

Forskellen er så at der potentielt er mange flere der kan lave kode-review.

Mvh, Søren

(PS: Jeg ser kun minimum en fejl, resten kommer vel an på kontekst af den lille snippet? :-) )

  • 0
  • 0
#4 Poul-Henning Kamp Blogger

Lad os lige prøve at holde ting ude fra hinanden.

I har foreløbigt blandet mindst fire forskellige ting sammen i en pærevælling:

  1. Hvor professionelt software udvikles, om der bruges code reviews etc. Det afhænger mest af programmørens alder og erfaring.

  2. Hvor mange fejl der er i software. Det afhænger, BLANDT ANDET af punkt 1, men f.eks også af om opgaven er forstået korrekt. Tænk på hovedspejlet i Hubble: Verdens mest præcist forkerte spejl.

  3. Om kildeteksten kan inspiceres af udenforståenden eller ej.

  4. Om kildeteksten frigives under en FOSS licens så andre kan bruge den til deres egne projekter eller produkter.

Nu fremstår det for håbentlig tydeligt at Jespers argument svarer til at ringe til brandvæsnet om et cykeltyveri.

Hvis man kan læse kildeteksten (via punkt 3 eller 4) kan se om det er skrevet af et LSD vrag eller en Wagnersk Heldenprogrammer og dermed danne sig et indtryk af punkt 1.

Den mulighed har man ikke med closed source, som derfor, per definition, altid er katten i sækken.

Det jesper i virkeligehden prøvede at sige er:

"Software udviklet af professionelle programmører er bedre end software udviklet af lallende amatører, og de fleste professionelle er ansat i closed source firmaer".

Til hvilket jeg kun kan sige: Hvis de er så gode, hvorfor så ikke lade os se beviset i form af noget Copyright beskyttet kildetekst ?

Poul-Henning

fejl 1: '=' vs '==' fejl 2: 'c' vs 'C'

  • 0
  • 0
#5 Helge Svendsen

"Software udviklet af professionelle programmører er bedre end software udviklet af lallende amatører, og de fleste professionelle er ansat i closed source firmaer".

Det tror jeg lidt du tager fejl i. Det der blev konkluderet var vist:

"Derfor er open source software i gennemsnit præcis lige så usikker som alt andet software."

Ikke mere eller mindre, men i snit lige så usikkert.

Og det var så mit input at det har Jesper sikkert ret i.

Min tilføjelse var så, at man bør kigge på den tid det tager / de penge det koster at få lavet et fix til en sikkerhedsbrist og/eller en fejl i stedet for blindt at kigge på antal fejl.

  • 0
  • 0
#6 Jesper Laisen

Fejl nummer to 'c' vs 'C', formoder jeg, stammer fra en Word autokorrektur. 1. ord i en linje bliver automatisk rettet til stort begyndelsesbogstav.

Det beklager jeg, men det bliver faktisk til en rigtig god pointe. Jeg har nemlig tjekket afskriften flere gange, og jeg har alligevel ikke opdaget den.

Mvh Jesper

  • 0
  • 0
#8 Thomas Lønskov Luther

Konklusionen er at man ikke bør bruge Word til noget som helst teknisk... jeg har den særdeles tvivlsomme fornøjelse at skrive teknisk dokumentation i Word, og hold da helt ferie hvor kan man blive sur på dens autokorrektur del... konsekvent gør den det forkert, og konsekvent gætter den forkert hvad jeg vil og ikke vil have... Specielt store og små bogstaver egner den sig ikke til.... (medmindre man som minimum slår det helt fra). Nåh, det var vist lidt OT... men hvorfor egentlig skrive i word når man bare vil publicere noget på en blog?

  • 0
  • 0
#9 Karsten Nyblad

Tja, jeg er enig med dig.

Spørgsmålet er, om ikke open source software udviklingsmodelen er bedre til at sikre, at de bedste kommer til at kode på de krittiske dele. Man skal have et CV, hvor man har demonstreret, at man kan skrive kode god kode, før man kan komme i betragtning til et job hos et OSS firma. De har mange ansøgere, og de kan nøjes med at vælge mellem dem, der har bidraget med kode af overbevisende kvalitet til projektet. CSS virsomheder bliver nødt til at stole på ansøgernes CV og referencer, og de kan ikke undgå at ansætte distanceblændere en gang i mellem.

I en CSS virksomhed opstår der let ejerskab til koden. Team Alfa tager sig af program a, b og c. Team Beta tager sige af program d og h, osv. Det gør, at det er vanskeligt at komme igennem med forbedringer, der angår programmer "ejet" af et andet team. Lad os antage, at en programmør synes, at der er en dårlig brugergrænseflade til et andet teams program. I de fleste tilfælde bliver han nødt til at holde en lav profil. Han kan evt. komme med forslag til det andet team, men han risikerer, at det andet team bliver sure, og i praksis gør han nok klogest i at holde sin kæft. I open source verdenen kan han bare skrive en anden brugergrænseflade.

  • 0
  • 0
#11 Hans Schou

Werner Koch fortalte at der engang var en fejl i GnuPG, og at den havde været der i to år - uden nogen havde opdaget den. Han var mildt sagt skuffet.

Var det ikke meningen med fri software at fejlene lissom skulle findes?

Så bare fordi at man har muligheden for at kigge koden igennem, er det ikke ensbetydende med at nogen gør det. Heller ikke når det gælder software hvor det kan være meget kritisk, hvis der er fejl i.

For dem der ikke lige ved det, så bruges GnuPG kryptografisk til at sikre at afsender er den han er. Dette gælder både email og download af software.

  • 0
  • 0
#12 Jesper Stein Sandal

Problemet er vel, at fejlene ikke er fejl som '=' der skulle have '==', men i stedet eksempelvis mangelfuld håndtering af exceptions og inputvalidering. Slåfejlene finder man vel, når programmet ikke kører, som forventet - ikke mindst fordi de står i selve koden. Den anden type fejl står til gengæld ikke i koden, så læseren af kildekoden skal i stedet være opmærksom på det, der mangler.

Nu har jeg ikke selv bidraget til open source-projekter, men jeg kan ikke forestille mig, at man sætter sig ned og siger 'nu vil jeg skrive en hel ny exception-handling til hele programmet'. Det mest naturlige er vel at give sig i kast med at udvide eller forbedre funktionaliteten - i hvert fald indtil projektet har nået en vis modenhed eller 'skønhedsfejlene' bliver et problem. Og så afhænger det selvfølgelig også af projektets størrelse, antallet af udviklere, og hvordan det er organiseret.

Man har så selvfølgelig slet ikke den samme mulighed i lukket kode, hvor opgaven med at skrive en ny exception-håndtering nok i stedet havner hos en underleverandør i Indien, hvis kunderne er heldige og ikke bliver spist af med, at opgaven overlades en overbebyrdet udvikler, som i går skrev under på en kontrakt hos konkurrenten.

  • 0
  • 0
#13 Poul-Henning Kamp Blogger

Jeg kan ikke se hvad levetiden for en fejl har med sagen at gøre ?

Pointen er om fejlen kunne opdages af andre end copyright holderen eller ej.

Når jeg ikke har kildeteksten til noget CSS så kan jeg aldrig finde fejl i det ved inspektion, uanset om det er uopfordret eller på begrundet mistanke.

aldrig divideret med 2 år er uendeligt, så Læsbar Source er altså uendelig meget bedre end Closed source på det her punkt.

Poul-Henning

  • 0
  • 0
#16 Kristian Larsen

Jeg er ikke udvikler, men kan da godt se pointen i bloggen. Det at designe sin kode til at være sikker fra starten fremfor at patche den til at være det må give bedre kodekvalitet.

Ligesom store projekter bliver mindre overskuelige end små projekter og derfor vil de være nemmere at finde fejl i.

Case in point, OOo er et kæmpeprojekt med underprojekter og dele, og det er meget meget få contributions projektet har fået grundet denne kompleksitet.

På linux (eller BSD'erne) er man vant til at lave små komponenter som de andre programmer kan bruge - det er derfor relativt nemmere at debugge den enkelte komponent end i et stort afhængighedskaos som OOo.

Windows udviklingen er skrækeksemplet hvor de måtte begynde på en komplet rewrite af Vista fordi den genbrugte kode fra tidligere simpelthen blev for kompleks og til sidst nærmest ubrugelig. Man kan så håbe windows er blevet mere komponentiseret [kan man sige sådan? :P] så det bliver bedre på den front i fremtiden.

Mao. min konklusion på bloggen er at design er vigtigere end udviklingsmodellen ift. sikkerheden, og den kan jeg godt købe.

  • 0
  • 0
#17 Poul-Henning Kamp Blogger

Jeg synes det er fodboldagtigt at udnæven en ting til vigtigere end andre. God software hænger på mindst tre væsentlige faktorer:

  1. At opgaven er velvalgt. Specielt er begrænsningens kunst er svær her. Second Systems Syndrome vinder alt for ofte.

  2. At designet får den opmærksomhed det skal have, både i tid og intelligens.

  3. At programmørene er dygtige og ansvarlige.

Det siger sig selv, at hvis der er urimelige tidsbegrænsninger, så lades alt håb om kvalitetssoftware ude.

Poul-Henning

  • 0
  • 0
#20 Lars Bauer Jørgensen

Jeg har flere gange i min professionelle karriere set at firmaer har købt closed source løsninger og at de firmaer som har solgt løsningerne er gået konkurs. Køberne af løsningerne kunne ikke på nogen måde redde deres investering (de havde ikke kildekoden). De var nødt til at specificere deres krav igen overfor et nyt softwarehus og de skulle begynde helt forfra. Havde de købt deres software som open source kunne de have fundet et andet software hus som så blot skulle vedligeholde og videreudvikle deres løsninger. Open source har helt sikkert sine fordele. PS. Opensource betyder ikke at man skal offentligtgøre sine kildetekster medmindre man giver løsningen til andre. Man kan såleders sagtens holde på sine forretnigshemmeligder (procedurer).

  • 0
  • 0
#21 Stefan Kreisberg

Jeg synes overskriften til dette indlæg er meget ringe. Hvorfor hedder det ikke: "Open source er ikke mere sikkert" eller "Open source ligeså usikkert som ..."

Det fremstår unægteligt i et andet lys en blot "Open source er usikkert" som er langt mere ladet (og som sikkert tiltrækker flere til artiklen). Men i selve indholdet siger du jo selv at det er "ligeså usikkert".

Det vil være dejligt med mindre meningsforstyrrende overskrifter i fremtiden.

  • 0
  • 0
Log ind eller Opret konto for at kommentere