Få de daglige nyheder fra Version2 og Ingeniøren. Læs mere om nyhedsbrevene her.

close
Ved at tilmelde dig accepterer du vores Brugerbetingelser, og du accepterer, at Teknologiens Mediehus og IDA-gruppen lejlighedsvis kan kontakte dig om arrangementer, analyser, nyheder, job og tilbud m.m. via telefon og e-mail. I nyhedsbreve, e-mails fra Teknologiens Mediehus kan der forefindes markedsføring fra samarbejdspartnere.
phloggen

Er programmører klaphatte ?

En trofast læser sendte i anledning af "Heartbleed" fejlen i OpenSSL kryptografi-kodebiblioteket en email med et antal gode og relevante spørgsmål, men gav mig som alternativ at jeg blot kunne svare på det umiddelbare spørgsmål i overskriften.

Svaret er "nej og ja".

Nej i den forstand at verden er fyldt med ultrakompetente programmører.

Tag f.eks Aage Melbye:

Illustration: Privatfoto

Her sidder han og læser valgresultater direkte på en hulstrimmel, fordi DASK ikke vil levere det endelige valgresultat d. 15 november 1960.

Men ja i den forstand at det skyldes noget så simpelt som en "N-1" fejl: DASK ventede på ét valgresultat mere end der fandtes valgsteder i landet.

Maurice Wilkes, en af de allerførste personer der faktisk kørte et program på en rigtig computer, udtrykte det på denne måde:

"As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs."

Programfejl er et grundvilkår.

Den bedste kode der nogen sinde er skrevet er formodentlig koden i de fem computere i NASAs rumfærge, her regner man med at der er ca. 1 fejl per 100.000 linier kildetekst.

Deres nettoproduktivitet er ca. 1 linie kode per medarbejder per dag og medarbejderne er vellønnede folk med nærmest tjenestemandslignende ansættelsesvilkår, eget kontor og rigtig, rigtig mange års erfaring.

Koden blive læst af dusinvis af programmører, inden den nogensinde bliver udført på en computer og den lever og holdes levende i årtier.

Et omfattende system af formelle reviews og tests holder øje med kvaliteten og det opfattes som et proceduresvigt hvis en fejl først opdages sent i processen.

Koden designes således at den kan bringe sig selv tilbage på sporet, næsten uanset hvad der måtte gå galt undervejs.

Til gengæld er det aldrig kedeligt når der endelig slipper en fejl igennem alle nåleøjerne.

Højkvalitetskode, kode der kan slå folk ihjel på en måde hvor et stort firma kan blive dømt til at betale erstatning i USA. Fejlraten ligger i området med ca. 1 fejl per 10.000 linier kode og vi taler om kode i cockpittet i fly, i atomkraftværker, i våbensystemer og på det niveau.

Medarbejderne er vellønnede i faste jobs, en testafdeling sikrer at koden passerer de aftalte tests og er der fejl ryger den tilbage til programmøren, men vi har meget lidt brugbare data om deres produktivtet.

Koden vil typisk gennemgå et til tre kollegiale reviews, men disse har ofte form af ritualer der skal gennemføres, fordi de er ritualer der skal gennemføres. Levetiden af koden er ofte op imod 10-12 år, men den opdateres kun sjældent efter 8 år.

Koden designes defensivt og robust, indenfor de økonomiske og tidsmæssige rammer der er udstukket.

Normal god kode har omkring 1 fejl per 1000 linier kode. Her taler vi om operativsystemer som Windows, Android eller OS/X, microcontrolleren i dit naturgasfyr eller din bil, eller i medinsk diagnostisk udstyr.

Medarbejderne arbejder for et eller andet firma der leverer både hardware og software og der skal tjenes penge, så der er en grænse for hvor mange penge og hvor meget tid man kan bruge på kvalitetssikring og kvalitetssikringen er ofte uformel og mere eller mindre op til den enkelte programmør at definere og gennemføre.

I nogle tilfælde udgør automatiske analyser der chekder om kildeteksten indeholder nogen forbudte "tricks" en slags "go/nogo" kontrol, f.eks "MISRA" kriterierne for indlejret software i biler men oftest er det dem der skal skrive manualen der finder problemerne fordi de, som de første, skal ud i alle kroge. Om fejlene rettes eller bare dokumenteres handler mest om hvad der er hurtigst og billigst.

Leverandøren laver sjældent ny opdateringer mere end 3-4 år efter lancering.

Rutinekode, sådan noget der kører i firmaers bogføring, programmer til PC'er osv ligger ofte omkring 1 fejl per 100 linier kode og har aldrig været igennem nogen egentligt kvalitetssikringsprocess. En eller anden medarbejder, muligvis en konsulent, skrev et program og besluttede sig til at det var godt nok. Måske kørte nogen i firmaet det i "test" i en periode, måske ikke. Der findes ofte ingen dokumentation overhovedet.

Frem for at vedligeholde og fejlrette kørende versioner, produceres "nye forbedrede" versioner, dvs. versioner med nyere og anderledes fejl. Efter to år er det eneste svar man får på en fejlrapport: "Opdater til den ny udgave, salg@ har muligvis stadig en god pris for gamle kunder."

Skodkode, tilfældige "apps" til smartphones, kollegers regnearksmakroer og den slags, har ofte op i mod 1 fejl per 10 linier kode og mere er der ikke at sige om det.

Det er virkeligheden i softwareverdenen i runde tal.

Det siger sig selv at der er stor usikkerhed, ikke mindst fordi det stort set kun er de to første kategorier der ser nogen værdi i at holde regnskab med deres fejl og lave statistik på dem.

Jeg er også sikker på at 95% af alle programmører mener at de gør det bedre end jeg her udmaler det.

Problemet er bare, at hver gang nogen har undersøgt det til bunds, sådan videnskabeligt og statisktisk kompetent, finder de ud af at billedet er ca. som jeg har beskrevet det.

Så kan man naturligvis give sig til at diskutere om en fejl der ikke får et træ til at vælte skal tælles med i skoven af fejl osv. men det er bare at snakke udenom: I bund og grund er en fejl en fejl og det er lidt ligegyldigt om det er en "vigtig fejl" man opdager, fordi programmøren ikke vælger om det skal være en "vigtig fejl" når han laven den, han laver den bare.

Hvor passer OpenSSL ind i det billede ?

Taget i betragtning at det er en kritisk sikkerhedskomponent i rigtig mange følsomme anvendelser, et af de steder "Heartbleed" fejlen blev udnyttet var til at hente en masse oplysninger om skatteborgere fra det Canadiske Skattevæsen, tror jeg de fleste instinktivt ville forvente at det var i kategorien med "højkvalitetskode".

Lyder rimeligt logisk, ikke sandt ?

I bedste fald, i aboslut bedste fald, er det "normal god kode", men der er rigtig mange ting der trækker nedaf fra selv den kategorisering.

Rent resourcemæssigt er OpenSSL i praksis et to- eller tremands fritidsprojekt på 300-500.000 linier kode, lidt afhængig af hvordan man tæller, og alene det sætter en fysisk begrænsning for hvor meget review og formel kvalitetssikring der er mulighed for at implementere.

Det fortæller os også at der formodentlig er 300-5000 fejl i koden stadigvæk.

Det kunne være hvad det være ville, hvis det bare var et program der fyldte nogle data i en fil der hvor cursor'en nu stod på skærmen.

Men det er det ikke.

OpenSSL implementerer et stort antal mildest talt syrede matematiske tankespin og protokoller og selvom man kan se de data man propper ind i OpenSSL kommer uskadte på en computer i den anden ende af en "sikret forbindelse" af den slags som viser en lukket hængelås i jeres browser, er der i realiteten ingen der kan se om det der bliver sendt imellem de to computere indeholder en fejl, for disse "beskyttede" bits er totalt umulige at skelne fra tilfældige bits -- Det er ligesom det der er hele ideen i krypteringen.

For det ikke skal være løgn, er mange af disse matematiske konstruktioner i OpenSSL optimeret på Formel-1 niveau, med anvendelse af underlige tricks, direkte assemblerkode samt specialinstruktion og -hardware på computere der har dem, altsammen på bekostning af læsbarhed og simpelhed i kildeteksten.

Og guddødemig om der ikke også indgår nogle gamle barokke protokoller som "X.509" fra dengang KTAS troede at de var guds salvede velsignelse til al datakommunikation fra evighed til evigned.

Men OpenSSL er da Open Source, ikke sandt ?

Hvorfor er der ikke nogen der har gjort noget ved det, alle havde jo kildeteksten ?

Svaret er at folk er bange for OpenSSL kildeteksten: Den er et monster på alle måder man kan forestille sig som programmør.

Jeg har spurgt forskellige folk jeg kender som ville være kompetente til det; "Hvad ville det koste at få dig til at renovere OpenSSL ?"

Over halvdelen svarer "Intet kan få mig til det."

Mediansvaret er noget i stil med: En million kroner i årsløn, et temmelig veludstyret edbrum og fem til ti kompetente assistenter til den nødvendige kvalitetssikring -- lad os kalde det 10 millioner om året, i mindst 10 år.

Frederick P. Brooks skriver i sin udødelige "The Mythical Man-Month" om forskellen på at lave "et program" og "et programprodukt": Ca en faktor tre i udgifter.

Skal vi op på "et systemprogramprodukt" skal der ganges med tre igen og jeg tror roligt at vi kan tilføje at for "et kryptografisk systemprogramprodukt" skal der ganges med tre igen.

Så det lyder absolut ikke usandsynligt at det vil koste omkring 100 mio kroner at renovere OpenSSL op på den nødvendige kvalitet i forhold til de værdier, ikke mindst i privatliv, koden idag beskytter.

OpenSSL projektet modtager normalt kun omkring $2000 i donationer om året. Folkene tjener til dagen og vejen ved at lave konsulentarbejde -- for firmaer der frygter OpenSSL monsteret.

Men der er mere endnu.

Hvis du med din browser går ind på konfigurationsskærmen af din hjemme-router, dit wireless access-point eller din solcelle-inverter, er der meget stor sandsynlighed for at det er OpenSSL der beskytter forbindelsen og at der derfor er problemer med sikkerheden.

Desværre for dig modtog du sammen med dimsen en eller anden "licensaftale" som gjorde det klart at det ikke var nogens problem og helt specifikt ihvertfald ikke leverandørens problem eller ansvar, hvis der er noget galt med softwaren.

Derfor er der formodentlig over en million indlejrede computere der nu kan bringes til at "bløde" alle deres hemmeligheder, heruder passwords og kryptografiske certifikater, ud til enhver blot nogenlunde moderat kompetent angriber -- og der er ingen der kan eller vil gøre noget ved det.

Heartbleed er simpelthen fejlen der burde få os til at stoppe op og overveje om det vi har gang i lige nu svarer til at tage Holmekollen med en ordentlig ski' på, for det er store og helt fundamentale problemstillinger Heartbleed udstiller vores manglende svar på:

  • Hvem har produktansvaret for softwaren i "Internet of Things" ?

  • Hvem har erstatningsansvaret når "Big Data" lækker ud over det hele ?

  • Hvem har aben med Privatlivsbeskyttelse af folk der ikke har en phd i kryptografi ?

  • Hvor sårbar er vores samfunds infrastruktur og hvordan ved vi at vi ved svaret er præcist ?

  • Hvem skal godkende at kode er god nok, når der står menneskeliv på spil ?

Der er folk der stille de rigtige kloge spørgsmål, folk som Bruce Schneier, Steve Bellowin og Dan Geer.

Men i det store hele behandler de fleste programmører Heartbleed som "just another patch tuesday".

Så ja: Programmører er faktisk nogle klaphatte.

phk

Emner : It-sikkerhed
Poul-Henning Kamp er selvstændig open source-softwareudvikler. Han skriver blandt andet om politik, hysteri, spin, monopoler, frihedskampe gør-det-selv-teknologi og humor.
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først

Jeg har læst meget dårligt om OpenSSL koden, men har aldrig selv kiggede på det. Måske er det for sent, men jeg har valgt at donere penge til dem. Men er det ikke endnu mere skræmmede at ingen af de store virksomheder har støttet dette projekt med penge elller tid?

  • 3
  • 0

OpenSSL er en meget vigtig del af vores fælles infrastruktur. Det kan undre mig hvor organisationer som W3C m.fl. er i dette spørgsmål.

Under alle omstændigheder er det ikke noget der kan løses af markedet, de enkelte programmører - eller af en indsamling.

  • 2
  • 0

> Men i det store hele behandler de fleste programmører Heartbleed som "just another patch tuesday".*

Det tror jeg nu ikke.
Jeg tror ret mange dev/ops folk rundt omkring stadig går rundt i tænkeboks over hvad deres holdning skal være fremover.

Jeg dykkede lidt ned i historien bag fejlen og hvorfor den var mulig.
http://www.version2.dk/blog/heartbleed-fej...

...Og det har ihvertfald fået mig til at ændre mit syn på OpenSSL kraftigt.
Den her bug måtte simpelthen ikke ske. De har eksplicit i standardiseringsprocessen for den feature behandlet at den længde-angivelse skulle checkes.
Alligevel har med-forfatteren på RFC'et undladt at gøre det i den submittede kode og intet code-review har fanget den.
Sådan kan et projekt af vigtighed som OpenSSL simpelthen ikke forvaltes.
Jeg bebrejder som sådan ikke de 2-3 folk, der ikke får løn for det, men det er klart at det er en uholdbar situation som det kører nu.

  • 0
  • 0

til de kriminelle, og oplys alle dine personlige data, interesser og hemmeligheder til samtlige producenter af vare og service ydelser.

Så kan vi slippe for at bruge så meget energi på at beskytte os mod tyveri, bedrageri, identitets tyveri og afpresning.
Hvis vi lover at bruge en time hverdag på at se koncentreret strøm af reklamer, kan vi slippe for at forstyrres af reklamer de resterende 23 timer i døgnet.

Jeg er nok sortseer, men jeg tror det tog kørte for lang tid siden. Et højhastigheds tog der ikke en gang har tændt raket motorerne endnu.

  • 0
  • 4

Du trykkede lige på en af mine knapper: Specifikationerne. Der er masser af RFC'er hvor man kan finde hjørner at undre sig over og hvor RFC'en ikke giver nogen hjælp. Der er formentlig også mindst en fejl pr 10 linier i RFC'erne :-(

Jeg er enig med PHK i alt hvad han skriver i artiklen. Desværre.

Vi lever med skodkode i biler, dvd-afspillere, digitale billedrammer osv fordi skodkoden ikke kan tilgås udefra og/eller konsekvenserne/gevinsten ved at angribe dem er relativt ringe. Heartbleed udstiller klart at skodkode ikke er godt nok, når det kommer i nærheden af cpr-registeret, netbanker osv
På den anden side er der nok ingen, der har lyst til at betale 10K kr for et trådløst accesspunkt til det lille hjem? Eller måske 100K kr hvis vi skal højere op i kvalitetskode.

Jeg tror også at nissen flytter med, selv hvis/når vi bliver bedre til fx at skrive openssl i mere læselig, mere højniveauprogrammeringssprog. Jeg var til et foredrag med Stroustrup, hvor han sammenlignede performance af c++ og c programmer på forskellige hardwareplatforme. Han var blevet ubehageligt overrasket over hvor meget implementeringen af standardbibliotekerne betød...

  • 1
  • 0

Programmørerne gør, hvad de kan for at programmere rigtigt. Når det alligevel går galt, så skyldes det måske, at de ikke selv er programmeret rigtigt!

Den dag, de får maskinen til at le af sig selv, da tager jeg klaphatten af, også selv om den rette kopi af den bedste programmør nok ville kalde et sådant resultat for en simpel fejl.

  • 0
  • 4

Jeg vil nu mene at mange programmører er nogle klaphatte fordi de ikke forstår at kapitalisere på deres produktivitet, og at "just another patch tuesday" er ideen bag Open Source.
Problemerne i dette tilfælde er ikke hos programmørerne, med der hvor beslutninger om følsom infrastruktur tages.
Ellers et udmærket skriv.

  • 0
  • 5

Jeg vil også godt pege fingeren mod at brugerne i dag er forvænt med at software skal enten være gratis eller det må ikke koste ret meget. Jeg kender utallige der vil gå med til mange problemer, for at slippe for at betale licens. De køber en dyr mac book, men vil fx ikke betale for licensen til photoshop.
Kvalitet og pris hænger ofte sammen. Så hvis det ikke var fordi der er så mange der er ivrige efter at give software væk, ville vi måske også have bedre kvalitet.
Det andet problem er at brugerne i høj grad er vænnet til at det "bare virker nogenlunde fordi det er jo gratis" og det var måske ok før hele infrastrukturen blev afhængig af det.
Så derfor: Tag penge for dit arbejde.

  • 2
  • 4

Det andet problem er at brugerne i høj grad er vænnet til at det "bare virker nogenlunde fordi det er jo gratis" og det var måske ok før hele infrastrukturen blev afhængig af det.
Så derfor: Tag penge for dit arbejde.

Faktisk, så ser jeg det mere omvendt:
Man ser utroligt meget software, som bliver regnet for noget, bare fordi det koster mange penge.
Det er jo næsten blevet en sportsgren for nogle software firmaer at sælge dyre produkter til det offentlige, som aldrig kommer til at virke efter hensigten.

De absolut største viruskatastrofer i historien er da skabt af fejl i kommerciel software. F.eks. Melissa:
http://www.rbs2.com/cvirus.htm#anchor222222

Faktisk har open source software i høj grad drevet konkurrencen. Kommercielle firmaer laver kun kode lige præcis så godt, at det kan sælges. Jeg sidder pt. ved en Linux Mint laptop. Mit tekstbehandlings program hedder Libre Office, min telefon kører Android, min browser er Firefox.
Det gør jeg da ikke fordi det er gratis. Det er fordi det er bedre end det jeg kan købe mig til.

  • 17
  • 3

Det der undrer mig er, at vi altid har hørt at Open Source nærmest var garant for kvalitet og sikkerhed. Argumentet lød, at når alle kunne se koden ville evt. problemer hurtigt blive opdaget og rettet. Kun med fuld åbenhed kunne man sikre kvaliteten.

Er virkeligheden i stedet den, at for mange kokke fordærver maden? Eller at man i virkeligheden bare får hvad man betaler for. Kan man overhovedet tillade sig at stille nogen som helst krav til noget, der laves på frivillig basis og gives væk gratis?

Jeg spørger fordi jeg er nysgerrig - ikke for at hænge open source-tilhængere ud.

  • 0
  • 0

Men er det ikke endnu mere skræmmede at ingen af de store virksomheder har støttet dette projekt med penge elller tid?

Min teori da jeg læste din kommentar i morges var at de, ligesom de fleste andre, regnede med at alt var i skønneste orden. Og se nu her:

http://www.linuxfoundation.org/programs/co...

En fond til at betale udviklere af kritisk infrastruktur, støttet af de store virksomheder og inspireret af Heartbleed. :)

  • 1
  • 0

Jeg har ikke skrevet at det ikke skal være open source? Open Source er fint med mig og absolut en god ting, men at du får medleveret source koden, betyder jo ikke at det skal være gratis.
Forresten er det naivt at tro at Android og Firefox er "open source" i gængs forstand. De er fuldstændig styret af google, der også financierer begge dele. Og hvis du syntes at Android er super i forhold til Objective-C og iOS, så er det fordi du ikke har prøvet at lave noget i det. Det er et totalt umodnet produkt.
Java er totalt ejet af Oracle, der suverænt styrer udviklingen af det.
Ubuntu laves stort set af Canonical og det er også et kommercielt foretagende, hvilket vel er OK.
Libre office? Jeg kender det ikke, men da jeg med OSx alligevel får Pages, Keynote og Numbers gratis, what is the point. Og når jeg for 70 kr om måneden får 5 stk office 365 licenser inkl. plads på one drive og konstante opgraderinger til sidste version og inkl. web versioner, gider jeg ikke rode med libre office til resten af familien.
Men igen jeg er totalt for open source, men det betyder ikke at brugerene ikke skal betale for softwaren i min optik. Og iøvrigt er langt de fleste Open Source projekter totalt afhængige af de store software leverandører såsom google, IBM, Microsoft, Oracle (mysql), etc. eller store statslige institutioner som universiteter eller NASA. Selv PHK tror jeg gerne vil have penge for sin tid og sine produkter.

  • 4
  • 0

Jeg tror ikke at det er et spørgsmål om "for mange kokke fordærver maden", men blot at skidtet er blevet for kompliceret. Jeg ser en generel tendens til, at store monolitiske systemer skaber flere problemer for mig, end små moduler jeg så kan koble sammen efter behov.

Ting som objektorienteret programmering og hurtigere CPU'er har gjort det til en leg at skabe uhyre store programmer, i forhold til hvad der havde været menneskeligt muligt i f.eks. 80'erne.

Klassiske eksempler er, når en eller anden offentlig instans bestiller "et system der skal kunne det hele" og derfor betaler et astronomiske beløb for det. Jeg tror ofte de havde været bedre stillet, hvis de bad om små simple løsninger på deres forskellige problemer - ét af gangen.

Jeg ved godt, det ikke altid vil kunne lade sig gøre, men jeg mener vi bør prøve at stræbe i retning af enkelthed. Man kunne måske se verdens software-udvikling lidt som når et barn bliver voksent: Først skal man lære at tale... siden skal man lære at holde igen, og skære ned på mængden af ord.

  • 5
  • 0

Det der undrer mig er, at vi altid har hørt at Open Source nærmest var garant for kvalitet og sikkerhed. Argumentet lød, at når alle kunne se koden ville evt. problemer hurtigt blive opdaget og rettet. Kun med fuld åbenhed kunne man sikre kvaliteten.


For mig har det meget lidt med kvalitet at gøre og meget mere med den konservative holdning der opstår i et open source community. De laver ikke om på noget, med mindre de selv synes det er værd at løbe efter.
Hvis man hægter sig på de store centralt styrede i branchen, så får man Unity, Metro og Ribbon interfaces og andet finere design spam kastet i hovedet i et væk. Det gider jeg ikke slås med.

  • 0
  • 0

... men blot at skidtet er blevet for kompliceret. Jeg ser en generel tendens til, at store monolitiske systemer skaber flere problemer for mig, end små moduler jeg så kan koble sammen efter behov.

... hvilket man netop principielt burde kunne betragte OpenSSL som.

Jeg har tidligere argumentere med at man ikke kunne sige OpenSSL var dårligt blot fordi det havde mange linier kode. Det mener jeg sådanset stadigvæk. Det er andre argumenter, der gør at man kan sige OpenSSL er dårligt.
Den aktuelle fejl var skam heller ikke noget "kompliceret". Der var ikke engang kryptografi involveret.
Og de havde allerede regnet ud da de lavede standarden at man skulle checke for netop den fejl... de gjorde det bare ikke.

Problemet med OpenSSL (ihvertfald her) var at ingen gad checke om de ting man havde aftalt skulle checkes faktisk var blevet det. ... det er sjusk. Men sikkert sjusk, der kommer af at ingen får penge for det ja.

  • 1
  • 3

I COOP optjener man point, som i perioder kan bruges til at betale med. En uge inde i sidste periode fik jeg en mail med oplysning om, at jeg kunne bruge point til at betale med. Dernæst stod der, at jeg nu havde: 0 point - jeg havde jo allerede brugt mine point. Hvor svært er det at køre et program om natten, hvor der sendes en sådan mail til medlemmer if point>0 - eller hvad det nu hedder i sproget (jeg er gammel SAS programmør).

Har idag fået en bøde for en for sent afleveret bog, den kunne ikke fornyes via bibliotekets hjemmeside. det kunne den dog godt, indrømmede bibliotekaren, men IT-systemet fungerer ikke rigtigt!

Min restskat er ca. 24.000 kr, fordi mit hovedkort er brugt både på folkepension og pension. Det kan ikke lade sig gøre, men lidt Googling viser, at studerende med SU og studiejob er i samme situation. Hvor svært kan det være at klare den rent programmeringsmæssigt. Og ja, man er selv ansvarlig for at tingene er i orden, så der er ikke noget at komme efter.

Som folkepensionist kan man ikke få efterløn, alligevel blev jeg sidste år forskudsregistreret som efterlønner - skønt det står i mit CPR-nummer, at det ikke kan lade sig gøre.

Min konklusion: programmører programmeret det, de får besked på.

  • 4
  • 0

I andre brancher har man forskellige former for kvalitetskontrol, hvor uafhængige instanser tester alle eller nogle af de påstande som påhæftes produkter, og derefter sætte en eller anden form for kvalitetsstempel på produktet. Hvis produktet så ikke viser sig at holde de løfter kan kvalitetsstemplet fjernes eller i grove tilfælde kan produktet fjernes, eller der kan gives bødestraf mm.

Hvordan ser situationen ud på software området? Er branchen imod sådanne tiltag?

  • 0
  • 0

Der bruges store ressourcer på kvalitetssikring og review af kode. Er det den bedste måde, at lave kode som fungerer? Hvis programmørerne får givet noget kode - er så ikke stor risiko for, at de accepterer koden, eller lader sig styre af dens kommentarer, så de godkender noget, der ikke fungerer?

Jeg tror, at det bedste er at flere uafhængige hold, sættes til at udvikle koden, og at de ikke må bruge kode fra hinanden. Specifikationerne skrives, så det er muligt at sammenligne resultatet fra flere sideløbende programmer. Det kræver naturligvis større CPU-kræfter, at sammenligne resultaterne, og logge fejl, samt sortere fejl fra. Men er det ikke mere sikkert end kode review?

Når flere hold udvikler uafhængigt ens fungerende kode, så laver de samtidigt review på specifikationen. Mener de ikke, at den er entydig, og korrekt, så brokker de sig, og specifikationen rettes. Rapporterne, som de uafhængige hold skriver sammenlignes, og der opdages forskelle og fejl.

Jeg tror der er stor risiko for, at programmørerne hæver deres løn, uden at få rettet fejlene ved kode review. Laves flere fungerende softwareversioner, så er det ikke muligt at komme sovende til lønnen. Hver enkelt software version, skal naturligvis kunne bestå testvektorerne, og der er ikke muligt at programmørerne sover, eller ikke opdager noget. Det som ikke opdages, giver anledning til fejl, når det sammenlignes med de andres kode run-time. Der tages efter de programmer der svarer ens, men fejlene logges også, så de kan blive rettet, så alle programmer bliver korrekte med tiden.

Eneste problem er, hvis programmørerne stjæler, og ikke udvikler softwaren selv. Så sker ofte, at de stjæler samme kode, eller anvender kode, der bruger samme fejlagtige algoritme. Men det er stor sandsynlighed for at det opdages.

  • 0
  • 2

Man kan vælge 2 af følgende, men ikke få alle tre:

  1. Features.
  2. Kvalitet.
  3. Hurtig leveringstid.

Dem der bestemmer over programørerne vælger næsten altid 1 og 3.

Den største fordel ved code review er at folk sjusker mindre når de ved at de skal forsvare hver en linie ved et møde. (Min erfaring er dog at design review er mere effektivt end code review).

Computer science er en ret ny videnskab så der er stadig håb.

  • 1
  • 0

Det er mig en gåde at man i offentligt regi ikke har dette på dagsorden. Det er vel ikke kun internet-hastigheder overalt i landet, der er væsentligt for en stærk IT-infrastruktur. Sikkerheden burde da være oplagt.

Og når man tænker på hvilke summer der spares ved at vælge open-source (fremfor tilsvarende kommercielle løsninger), burde dette vel være et fokus-punkt`

Måske der allerede bidrages forskellige steder, som jeg ikke har hørt om. Jeg tænker ikke på medarbejderes enkelte bidrag, men på formelle strukturer der sikrer at man bidrager til open-source udvikling.

  • 0
  • 0

Man kan jo kun komme sovende til sin løn, hvis ledelsen slet ikke har check på hvad produktet skal kunne. Og hvis der ikke er en kompetent ledelse, så kan hvadsomhelst jo slippe igennem (hvorfor kom jeg nu til at tænke på Windows ME :-)

Kode review burde være et relativt billig måde at finde fejl på. Det er meget dyrere at rette de fejl, som først bliver fundet sent i en testfase eller endnu værre af kunderne efter release. (Jeg mindes fx en sag, hvor sideairbags i volvoer ikke blev udløst korrekt. Om man så vil kalde lige det for en programmeringsfejl eller ej kan diskuteres, men det gælder jo generelt for embeddede programmer at det er lige meget om programmet er "korrekt" hvis det ikke virker ude i virkeligheden som en del af et produkt.)

  • 0
  • 0

Og ja, man er selv ansvarlig for at tingene er i orden, så der er ikke noget at komme efter.


Vi burde opfinde et begreb for det, jeg ville kalde det: "Downsourcing".

Downsourcing går ud på at man erstatter kostbar programmör- og CPU tid, som jo går på budgettet og er synlige, med usynlige gratis ressourcer som leveres af anvenderen af systemet.

For at göre det muligt, skal brugeren göres 100% personligt ansvarlig for at "IT-lösningen" indeholder korrekte data, at brugeren jävnligt kontrollerer disse og at brugeren hele tiden orienterer sig selv om ändringer og nye initiativer som vedrörer brugerens ansvar.

Det fungerer i Danmark fordi danskerne i grunden er autoritäre; "Vi" er ikke så interesserede om noget er retfärdigt eller rimeligt når bare det går mest ud over nogen som vi ikke kan lide. Når det går ud over os selv så brokker vi os en masse på Facebook, et.c., til gläde for de mange, der ikke kan lide "vores slags", men egentligt sker der aldrig noget konkret fordi danskerne tör ingenting når det kommer til stykket. Det er helt elendigt at se på.

Det er ikke så märkeligt at politikerne ikke har det mindste respekt for befolkningen - der er jo ingen grund til det, befolkningen respekterer ikke engang sig selv til at begynde med!

  • 0
  • 0

Hvor svært kan det være at klare den rent programmeringsmæssigt.


Det er ikke der problemet ligger! Problemet er at SKAT.dk meget länge har kört efter "provenuet helliger alt"-princippet og at SKATS ageren både er godkendt i finansministeriet og stöttet af folketinget (som ikke vil indrömme at finansministeriet har veto-ret over lovgivningen). Det er derfor at "fixet" på at "SKAT taber for mange sager" ikke er at undersöge om juraen eller administrationen af den er god nok, men at indskränke klagemulighederne og indföre mere brugerbetaling for klager.

Alle mine börn, som lever af SU - 100% simpelt & ligetil, havde underlige selvangivelser som ville have kostet dem alvorlige penge hvis de ikke havde fået det rettet fordi jeg blev ved med at insistere at de skal tjekke det selv om "der ikke (burde) väre noget at komme efter".

  • 1
  • 0

I andre brancher har man forskellige former for kvalitetskontrol, hvor uafhængige instanser tester alle eller nogle af de påstande som påhæftes produkter, og derefter sætte en eller anden form for kvalitetsstempel på produktet.

Problemet med software er at produktet i form af koden dels hurtig bliver ret stor (1000 sider af 40 linjer per side er vel kun et middelstørrelsesprodukt), dels at kompleksiteten ofte er høj (du kan ikke nøjes med at kigge på lokale dele af programmet for at afgøre korrekthed), dels at de alvorlige fejl ofte kan være ret subtile og dels at der ofte bliver ændret en del på koden konstant.

Så man vil godt kunne blackbox-teste produktet og finde nogle fejl, f.eks. også brugervenlighedsproblemer (som at produktet er ubrugeligt for 97% af målgruppen), men en egentlig uafhængig grundig kvalitetskontrol virker helt utopisk for de fleste produkters vedkommende.

For ikke-sikkerhedskritisk software er den etablerede fremgangsmåde i branchen at man forsøger at fange de værste ting internt, hvorefter nogle betatest-forsøgskaniner får til opgave at finde resten. Efter en passende betatestperiode ved man så empirisk at produktet fungerer så nogenlunde til de vigtigste opgaver det skal løse.

Som PHK påpeger så er vi vant til at finde os i det. Der er jo ikke nogen der ringer til deres internetudbyder selvom deres router højst sandsynligt kan hackes af enhver.

  • 1
  • 0

Grunden til at folk ikke ville rydde op i OpenSSL, var jo netop at alle kunne se at koden var så ringe, at det nok ville være hurtigere at starte fra bunden af. At vi så stadig brugte det, kan vi jo kun give os selv skylden for. Heartbleed er jo blot den seneste (og værste) i en lang række fejl forårsaget af slamkode i OpenSSL.

De nævnte fejlrater matcher både egne erfaringer og hvad jeg har læst andet steds, og det er både meget besværligt og meget dyrt at hæve kodekvaliteten i et projekt. En langt mere praktisk måde at reducere antallet af fejl er tilgengæld det at skrive færre linjers kode (og her mener jeg ikke at fjerne alle linjeskiftene fra sit C-program).

Èn måde at reducere antallet af kodelinjer er ved at fjerne features - det er det OpenBSD er i gang med lige nu i deres OpenSSL-fork. Der kan ikke være fejl i en feature, som ikke er dér.

Estimeret ud fra antallet af kodelinjer (frit fra Wikipedia) må PolarSSL (14k linjer) indeholder under en tiendedel så mange fejl som OpenSSL (159k), som igen kun har 40% så mange kodelinjer (og fejl?) som NSS (400k linjer!).

Men det er også værd at bide mærke i at PHK ikke nævnte noget om programmeringssprog, hvilket formentlig skyldes at der faktisk er forskning, som antyder at fejlraten per linje er ca. den samme, uanset om man skriver C++ eller assembler. En anden god måde at reducere antallet af kodelinjer (og dermed fejl) er derfor at skrive programmet om i et sprog med højere abstraktionsniveau. Og altså ikke C.

Målt på dette parameter virker Botan væsentligt mere interessant med sine 32k linjers C++.

For det er jo ikke kun OpenSSL der har ondt i C-koden... det samme gælder de to største konkurrenter, NSS og GnuTLS. Her er Moxie Marlinspike's DEFCON17 præsentation et (endda ikke alt for teknisk) must-see. Bonus-eksempel på at også dygtige C-programmører kan være nogen klaphatte (ft. OpenSSL!)

  • 4
  • 0

Som PHK påpeger så er vi vant til at finde os i det. Der er jo ikke nogen der ringer til deres internetudbyder selvom deres router højst sandsynligt kan hackes af enhver.

Ja netop. Vi er desværre vant til at der skal være uforklarlige problemer med IT teknologi. Har man fået et problem med sin PC, så tager man den med ned til IT afdelingen. Hvis de ikke lige kan løse problemet, så forsøger de med en genstart, og løser det ikke problemet, så bliver maskinen geninstalleret.
Hvad var problemet så?
Vi ved det ikke, men nu virker den igen...

  • 0
  • 0

Coverity's "Project Defect Density" (fundne "high-risk" og "medium-risk" fejl per 1000 linjer) er 0.59 udfra deres analyse givet i en rapport fra 24. april 2013 af 7,6 millioner linjer kode. I deres pressemeddelelse angiver de at Python har en defect density på 0.005 = 1 fejl per 200.000 linjer, altså over PHK's "Den bedste kode" angivelse, hvis vi tør oversætte Coverity's tal til egentlig fejl. Det er nok for optimistisk.

http://www.coverity.com/press-releases/cov...

  • 0
  • 0

Coverity har aldrig påstået at de kunne finde alle fejl.

Case in point, Coverity kunne ikke finde Hearbleed (omend de er på vej med en version der kan). (1)

  • 0
  • 0

lle mine börn, som lever af SU - 100% simpelt & ligetil, havde underlige selvangivelser som ville have kostet dem alvorlige penge hvis de ikke havde fået det rettet fordi jeg blev ved med at insistere at de skal tjekke det selv om "der ikke (burde) väre noget at komme efter".

Jeg var på SU for to år siden, da der efter sigende var knas hos Skat. Jeg havde også a-indkomst plus befordringsfradrag, men intet komplekst heller. Mine indtastninger blev rettet automatisk tre gange, alle tre gange til det rene vrøvl. Noget forskelligt hver gang.
Én af gangene var der fortrykt ~80.000 krs indtægt på internationalt farvand eller sådan noget sømands-halløj - helt i hegnet mand...!

Jeg modtog senere et brev fra Skat Indkrævning om at jeg fluks skulle betale dem ~7000 kr, som jeg angiveligt skyldte. En lille uge derpå kom endnu et brev, hvori der stod at jeg skulle se bort fra den tidligere skrivelse og i øvrigt have penge tilbage.

  • 0
  • 0

For det er jo ikke kun OpenSSL der har ondt i C-koden... det samme gælder de to største konkurrenter, NSS og GnuTLS. Her er Moxie Marlinspike's DEFCON17 præsentation et (endda ikke alt for teknisk) must-see. Bonus-eksempel på at også dygtige C-programmører kan være nogen klaphatte (ft. OpenSSL!)

Fantastisk præsentation med masser af indsigt. Hovedpointen er at den underliggende standard, X.509, er noget rod.

Man kan argumenterer for at Heart Bleed skulle have været fanget af en simpel unit test.

For at kunne lave et fungerende unit test suite skal man have en entydig specifikation og helst med moderat kompleksitet; Egenskaber X.509 ikke besidder.

At man nu skærer implementationerne ned i kompleksitet ved kun at implementere en delmængde af standarden er et fint første skridt, men man burde nok også se på at lave en ny standard indeholdende en veldefineret delmængde af X.509.

  • 0
  • 0
Bidrag med din viden – log ind og deltag i debatten