OpenSLL/Heartbleed-buggen

Lite old news men jag vill höra ur C-programmerare ser på detta.
Heartbleed-buggen i OpenSSL orsakades ju av ett pyttelitet programmeringsfel i hur de allokerade och hanterade minnet. Troligen hade en sådan bugg aldrig kunnat uppstå i Java eller .NET där man inte allokerar [x] bytes i minnet för att returnera ett svar från en tjänst. Man låter String-objektet ta hand om det problemet. Därför menar jag att äldre språk som C borde fasas ut, kanske t.o.m förbjudas i de flesta organisationer. De mikroskopiska prestandafördelarna som man kan få är inte värda de risker och de buggar som uppstår, inkl episka säkerhetshål som Heartbleed.

Visst har du en poäng i det du säger. C är dock mycket viktigt för inbyggda system och kanske till och med det största språket inom den industrin. Så att fasa ut C är orimligt. Men man väljer så klart språk efter tillämpning och inte tvärt om.

Episkt, ja. Men det gör inte C sämre eller för den delen Java bättre (som i sin tur nyligen hade sin beskärda del av säkerhetsproblem).

Mikroskopiska fördelar växer lavinartat i stora system, varje skruv och mutter gör sitt.

Sedan är det kanske lite fel att kalla ett programeringsspråk gammalt om det uppdateras och följer utvecklingen.

Debugging är A och O och hanterar man minnesallokering skall man ta ansvar för det. MS var/är rätt slarviga med det...

Man kan koda C säkert, och när man väl gör det så är det en av de mest flexibla språken. Visst har du en poäng i det du säger, men kunskapen om de olika sårbarheterna är mer kända nu än de var förut.

Förbjuda kan man ju inte göra, bara för att vissa programspåk ökat abstraktionsnivån betyder ju inta att någonstans på vägen måste en allokering ske, eller menar du förbjuda för programmerare men tillåta för ingenjörer?

Nej. Jag skrev att "äldre språk som C borde fasas ut, kanske t.o.m förbjudas i de flesta organisationer". Om jag vore IT-chef i en stor organisation skulle jag se till att väldigt riskfyllda språk och teknologier avskaffades i förmån för nyare och säkrare teknologier.

Ja, men det kostade ju en massa användares lösenord och andra hemliga uppgifter. Var det värt besväret för att uppnå en optimal minneshantering? (Den var ju långt ifrån optimal men syftet med koden och teknikvalen var väl bl.a. det).

Jag menar bara att allt är ju relativt, tänk om VM till C# eller Java på en plattform tex innehåller en allokeringsbug som personerna som skrev dessa råkade få med, då riskerar ju den buggen att smitta samtliga program som utför den allokeringen "under ytan".

Någonstans måste ju kod för allokering skrivits och då finns ju möjligheterna att en bugg smyger in där också.

Fast koden till C# och Java granskas och testas väl av miljoner människor?

Man kan programmera säkert i C, men när inte ens folk som skriver nåt så viktigt som OpenSSL gör det, kanske vi behöver skydda oss från oss själva.

Visst är det så, jag ville bara påpeka att inget system är idiotsäkert, det skulle ju räcka med en svårkläckt bugg i en .NET uppdatering .
Buggar kommar alltid uppstå och jag tror inte heller att C skulle utgöra en större risk än något annat språk, där är man ju i alla fall medveten om riskerna medan man i Java eller C# mer eller mindre litar på att systemen är rätt från början

Bortsett från faktorer som att företaget kan vara beroende av, och därmed till en större eller mindre del bunden till, redan skriven kod, och att programmerarna inom företaget kanske endast besitter kunskap om just det språk som tidigare alltid använts, så använder man ju det språk som bäst tillgodoser ändamålet. Hur mycket du än vill så kan du till exempel inte koda kärnan till ett operativsystem i Java. Inte utan en underliggande JVM som först måste laddas in, vilken i sin tur exekverar kärnan. Denna JVM kan du inte heller koda i Java.

Som det redan har påpekats så finns det ju inget system som är helt säkert. En C programmerare har dock ett större ansvar än en som programmerar i Java eller C# just när det gäller minneshanteringen, men Java och C# programmerare är ju som sagt beroende av att JVM respektive .NET-ramverket är felfria.

Huruvida koden bakom olika JVM och .NET-ramverk granskas och mer eller mindre än koden till OpenSSL låter jag vara osagt. Men vill man kunna lita helt och hållet på koden som körs, och inte litar på någon annan än sig själv, så är det utan tvekan C som gäller.