Oktoberföredrag: Daniel Stenberg, haxx.se

Daniel Stenberg inledde kvällens seminarier genom att berätta om cURL eller mer specifikt libcurl som han leder utvecklingen av.

Produkten libcurl
Libcurl (fri mjukvara) är ett kommandobaserat verktyg för filöverföring enligt en drös med protokoll (FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP, TELNET, DICT, LDAP ...). De har flera hundra på utvecklarlistan men en kärna på en handfull dedikerade utvecklare.
Libcurl (alltså bilbioteksvarianten), används i en massa mjukvaruprodukter och operativsystem, proprietära såväl som öppna eller fria. Och då snackar vi de stora drakarna. En stor och krävande användarbas med andra ord. Allt distribueras som källkod för att slippa underhålla femtioelva distributioner och byggen.

Rapportering av säkerhetsfel
När det gäller hantering av säkerhetsfel så är inrapporteringen sluten för att ge utvecklarna en chans att komma med en patch. De har haft åtta sådana incidenter. En del av rapporterna har kommit den rätta vägen och tillåtit en veckas arbete med en patch. Andra rapporter har gått parallellt till både utvecklarna och någon publik lista. Tyvärr finns det också incidenter som bara gått till någon publik lista varpå Daniel hört det ryktesvägen. Inte en särskilt seriös variant av full disclosure enligt mig.

En intressant poäng var att många av dem som använder libcurl gör så kallad statisk länkning. De bygger alltså in biblioteket i binären. Det gör att en opatchad version av libcurl kan överleva länge inuti applikationer.

Frågan om dynamisk versus statisk länkning är ju intressant tycker jag. I det dynamiska fallet är det enklare att patcha (till och med slutanvändaren kan göra det) medan det i det statiska fallet är enklare att ha kontroll på vad ens applikation kör för kod. Det är ju en läskig attackvektor att injicera sårbar kod via libbar ...

Bidrag från communityn
Daniel kommenterade the many eyeballs som att det oftast bara är några få som bryr sig. Han granskar själv alla bidrag från communityn. Gällande så kallade copyright assignments så använde Daniel inte såna förutom för riktigt stora commits. Det är helt enkelt för mycket jobb för att göra det jämt.

Daniels tips för säker kod
Utan att presentera någon magi så tydliggjorde Daniel vilka principer han tycker leder till säkrare kod:
• Enkel kod - förstår du inte koden så skriv om den
• Manuell granskning - tar tid men ger kvalitet
• Förbjudna funktioner - vissa C-funktioner får helt enkelt inte användas i cURL
• Små funktioner - har att göra med enkel kod - 10 rader är bra, 100 rader är dåligt

/John