Som gammal Ada-utvecklare kan jag inte annat än att hålla med. Sällan man hade några slarvfel som slank igenom kompilatorn utan de fel man fick var mer av karakären logiska fel. Alltså sådana som det skulle behövas en kompilator som klarat Turing-testet och lite till för att upptäcka… Extra trevligt är ju såklart det inte trådstödet som gör synkronisering mellan trådar till en barnlek. Visst är man fortfarande tvungen att säkra data via protected objects eller dylikt men det är hursomhelst mycket enklare och säkrare när det finns inbyggt i språket. Och det var Ada95. Ada2005 tar ju saker och ting ytterligare ett steg framåt!

Synd bara att Ada är relativt ovanligt att se i kompilatorer för DSP:er och inbyggda system. Antar att det är enklare att skriva en högoptimerande kompilator för ett enklare språk som C än för t ex Ada.

Extreme Programming, Test Driven Development och Keep It Simple Stupid fungerade alldeles utmärkt ihop med Ada 95 och aUnit för enhetstester och drog ner antalet fel ytterligare. Kräver dock dedikerade programmerare med någorlunda samma attityd till kodningen…
Så visst är processer viktigt!

Ett annat generellt problem är i min mening att man drar objektorienting lite för långt. Jag tycker om att modellera objektorienterat men när man väl skall implementera så håller jag det så funktionellt som möjligt. Att låta hundratals objekt ha sin egna tillstånd och sidoeffekter åt både höger, vänster, uppåt och neråt är att be om problem.
Skriver man funktionellt så kan man ju utan större problem matematiskt bevisa att koden uppfyller sina specifikationer.

Om man använder .NET eller Mono så har ju MS släppt en beta för F# i höstas. Tankade ner det och testade lite i julas och det var en inte helt oangenäm upplevelse. Ett funktionellt programspråk i skrivbordsmiljö. Trodde man inte när man fick sina första religiösa upplevelser i ML i början av 90-talet!
F#: http://research.microsoft.com/fsharp/fsharp.aspx

Inte testat TBB men ett intressant initiativ! Är dock ganska säker på att jag skulle klara av att skjuta mig i foten ändå…;-)

Björn: Rubriken ändrad och paranteser borttagna. Du har rätt i att folk behöver uppmärksammas på att det finns andra språk. Vidare har du rätt i att det inte räcker med att hoppas på att trenden skall gå mot säkrare språk.

Men jag tror tyvärr att vi kommer att se stor användning av C och C++ i många, många år framöver. Vi pratar inte om att byta språk i nästa projekt eller ens nästnästa. Detta då även dessa språk med stor sannolikhet bygger på tidigare kodbas.

Metodik och processer för att skrivare allt säkrar kod. Användning av bibliotek som hjälper till att lösa problem och verktyg för att analysera koden och inte minst verktyg för att hjälpa till att migrera kodbasen tror jag på.

Är det någon som tittat på Intels Threading Building Blocks? Ger det ett bra stöd för att skriva multitrådat utan att automatiskt skjuta sig själv i foten från fler håll samtidigt?

Intel TBB:
http://www.intel.com/cd/software/products/asmo-na/eng/294797.htm

“Även Java har ett flertal mekanismer som gör dess kod säkrare och minskar risken för fel.”
Det är sant. Man slipper åtminstone buffertspill. Den allra största defekten i C har dock javas konstruktörer omsorgsfullt kopierat: if(a=b).

“Kodbasen som i dag finns i C, C++ samt antalet SW-utvecklare som kodar i C och C++ är så stor att det för många inte går att byta språk.”
Jag menar inte att alla ska sätta sig och översätta all sin befintliga C-kod till ada. Först och främst vill jag att folk ska sluta välja C när de startar nya projekt. Argumentet att det finns många utvecklare som kodar i C och C++ förstår jag inte. Det är ju just de som behöver övertalas att välja ett säkrare språk till nästa projekt.

“Att få in säkerhetstänkande i metodik och utvecklingsprocessen.”
Det är jag helt med på, men valet av språk är en viktig del av säkerhetstänkandet.

“Sedan kan man hoppas på att världen rör sig mot språk som är bättre lämpade.”
Jag nöjer mig inte med att hoppas. Jag försöker driva på. Därför tar jag vara på sådana här tillfällen att påpeka att det finns välkonstruerade språk och illa konstruerade språk.

Blaufish:
Jag har inte försökt påstå att ada löser alla problem i världen. Joachim skrev en artikel om att koda säkert i C och C++, och jag påpekade att kodar säkert gör man bättre i andra språk. Det stämmer att de tio reglerna är allmängiltiga, men Joachims artikel är likafullt inriktad på C och C++, och därför tyckte jag att språkaspekten behövde belysas.

Däremot är ju åtminstone 9 av 10 regler boken föreslår direkt tillämpbara på ALL programmering, oberoende av programmeringsspråk. Och om någon tror att Ada/C#/Java löser alla problem, ja då bör man snarast läsa in sig på bl.a. Injection attacker, XSS/CSRF/JsHijacking/… attacker, directory traversal. Glöm dessutom inte alla applikationsspecifika problem, de som är helt unika och skapade av programmerna, de som bara finns i detta program. Problemen idag är snarare att utvecklarna gör bort sig på nivåerna ovanför, än att man har problem med B.O… Att diskutera säkerhet utifrån B.O. känns väldigt mycket som gammalt 1990-tal.

Problemet är precis som Jochim säger - att få in säkerhet i metodik, utveckling och personalutbildning. Visst gör Ada/C#/Java att man slipper en viss delmängd av problematiken, men det grundläggande problemet - utvecklarnas kunskaper och den tid de kan lägga på att arbeta med säkerhet, det löser inget programspråk.

Speciellt fel med “lita (blint) på programspråket / verktyget” filosofin är att man helt missar allt som inte täcks upp av detta, och man har ingen som helst chans att hitta de applikationsspecifika problem som inget automatiskt verktyg i hela världen kan hitta.

Att säkerhet kräver enormt mycket av de som utvecklar kommer man aldrig ifrån. Det finns ingen enkel lösning, varken på en eller tre bokstäver.

Björn: Först, du noterade att jag skrev “säkra(re)”?

Sedan har du rätt i att det finns språk där mycket av problematiken med C och C++ inte ens finns. Ada, vilket jag tror du syftar på är ett sådant språk. Andra språk som inte alls kommer med samma uppsättning vårtor är språk som Erlang, Eiffel, Oberon etc. Även Java har ett flertal mekanismer som gör dess kod säkrare och minskar risken för fel.

*MEN* Det hjälper inte. Kodbasen som i dag finns i C, C++ samt antalet SW-utvecklare som kodar i C och C++ är så stor att det för många inte går att byta språk. Att då istället introducera kodningsregler, implementera granskningar med ex lclint, coverity, köra med fuzzing och metodik för att göra sin kod SÄKRARE tycker jag är ett bra sätt att arbeta. Att få in säkerhetstänkande i metodik och utvecklingsprocessen.

Sedan kan man hoppas på att världen rör sig mot språk som är bättre lämpade. Inte minst problemet med multitrådning och parallell programmering för att utnyttja multicores öppnar ju upp en hel lastpall med maskburkar.

Att koda säkert i C och C++ är svårt, att koda multitrådat säkert i C och C++, det är mycket värre.

Det finns ett programmeringsspråk som är konstruerat från grunden för att hjälpa programmeraren att göra koden så pålitlig som möjligt. Det konstruerades i slutet av 1970-talet, standardiserades första gången 1980, och blev ISO-standard 1983. Den senaste förbättringen färdigställdes 2005 och blev formellt ISO-standard 2007. Det är ett statiskt typat språk med ett typsystem som varken C eller C++ kommer i närheten av. Man kan definiera sina egna heltals- och flyttalstyper och precis vilka värden de ska kunna ha, och man får gränskontroll på såväl skalärer och uppräknade typer som vektorer, vilket gör stränghanteringen mycket behändig utan risk för buffertspill eller formatsträngsbuggar. Givetvis finns också arv, polymorfi och överlagring, allt som behövs för objektorienterad programmering.

Multitrådning finns inbyggt i språket, vilket gör att kompilatorn kan hjälpa till på ett helt annat sätt än när trådning läggs på som ett bibliotek. För det mesta programmerar man på en ganska hög nivå, men man kan också styra detaljer på en mycket låg nivå när man verkligen behöver. Man kan också gå förbi säkerhetsspärrarna när det är nödvändigt. Det går alldeles utmärkt att skjuta sig i foten – men först efter att man uttryckligen har talat om för kompilatorn att man faktiskt vill använda sin fot som måltavla.

Allt detta gör att misstag som skulle ha blivit säkerhetshål eller obegripliga krascher i ett C-program i stället upptäcks vid kompileringen och genast rättas till. Priset är att det tar litet längre tid att kompilera än C, eftersom kompilatorn gör så mycket mer. Eftersom språket kompileras till maskinkod så får man prestanda fullt jämförbara med vad andra kompilerade språk ger. Och ja, det finns en fri kompilator. Den heter GCC.

Någon som vill försöka gissa vad språket heter?