Am mai scris pe aici despre diversele probleme descoperite în suita openssl și despre problemele pe care software-ul scris de voluntari le poate avea, mai ales un software ca acesta, care necesită cunoștinte avansate de criptografie. De aceea pentru mine a fost o surpriză plăcută stirea că la cererea Core Infrastructure Initiative codul suitei de securitate va fi auditat.
Nu știu să fi existat vreun proiect similar ca anvergură: conform informațiilor statistice de pe openhub.net, vorbim de 447 247 de linii de cod și de 14 limbaje diferite ( totuși, majoritatea implementării propriu-zise este în C, restul sunt mai degrabă limbaje de scripting necesare pentru managementul pachetelor).
Acțiunea are atât o valoare tehnică ( vorbim de un cod destul de special, care implementează algoritmi sensibili) cât și publicitară. Episodul Heartbled a lăsat un gust amar în lumea partizanilor Open Source, dar nu numai a lor; este de ajuns să consultați lista sponsorilor Core Infrastructure Initiative ca să vă faceți o idee despre amploarea afacerilor care se bazează pe openSSL.
Într-un fel, am putea spune că suita a devenit un fel de „utilitate publică”: aproape orice serviciu care plimbă date prin Internet în zilele noastre are nevoie de criptare. Oricine a scris o aplicație care face indiferent ce a avut la dispoziție această suită pe care nu trebuia decât să o includă. O ofertă aproape irezistibilă, aș zice; alternativa era să se apuce el însuși să implementeze layer-ul de securitate.
Deci, de la comerț electronic la criptare de mail-uri sau VPN-uri, toată lumea folosește openSSL . Folosește și nu cercetează.
Problema calității codului este spinoasă în orice firmă de software. Este greu să menții un standard uniform când scrii zeci sau sute de mii de linii de cod; chiar și într-o societate comercială angajații se mai schimbă (IT-ul e un domeniu dinamic), și nu orice zi e cea mai bună zi pentru fiecare programator. Metodele pe care le are un QA la dispoziție sunt mai degrabă limitate, iar uneori timpul presează.
Dacă în general la modelul Open Source timpul nu e un factor de stress ( lucru de care nu putem fi totdeauna siguri, pentru că unele sunt dublate de un proiect „comercial”, altele încurajează donațiile pentru implementarea unor anumite feature-uri sau cine știe ce alt model de finanțare) în schimb există o altă problemă, cea a „contribuțiilor”. Cum oricine poate produce o bucată de cod sau un patch, se poate intâmpla, pentru că oricine poate contribui, să primești cod funcțional, scris aparent corect și îngrijit, care totuși să aibă probleme. Nimeni nu va sta prea mult să îl analizeze, atâta timp cât face ceea ce ar trebui să facă. Nu vorbim de angajați, deci nu vorbim de răspundere, de norme interne etc.
Pe de altă parte, nimănui nu-i place să facă QA ; toată lumea vrea să fie creativă în zilele noastre. În altă ordine de idei, singurul control de calitate pe care te poți baza în lumea Open Source este cel al autorului respectivului cod, care are o imagine publică de întreținut.
Ce mi s-a părut însă mai interesant este că, spre deosebire de procesele interne ale companiilor de software, aici vom avea un audit public al unei suite Open Source de anvergură. Auditul va găsi în mod sigur un număr de probleme în cod, dar probabil că vom afla lucruri interesante despre acest mod de a scrie soft: cât de frecvent se fac greșeli clasice de programare, inclusiv de către cine, cât timp pot persista în cod fără a fi descoperite, lucruri de acest fel. Pe care probabil că nu am fi avut ocazia să le vedem altfel; vom avea deci o disecție cu public, nu una de laborator.
Văd acest gen de audit extins la mai multe componente ale ecosistemului. În definitiv, e o întreagă lume care se sprijină pe aceste produse și care are nevoie să aibă încredere în ele. Auditul îmi pare că era veriga lipsă a mișcării Open Source; într-un fel aș spune că evenimentul marchează oarecum sfârșitul perioadei romantice.
Imi pare rau ca trebuie sa va trezesc la realitate, dar codul OpenSSL nu are nici a zecea parte din volumul pe care il mentionati. Daca va referiti la toate variantele de implementare pe toate platformele si tot nu are nici a zecea parte, dar de-a lungul vremii a adunat o mare cantitate de balast constand in variante obscure sau depasite pe care nu le-a sters nimeni pentru ca nu era interesat sa faca curatenie sau pentru a pastra compatibilitatea cu aplicatii de acum X ani. Daca unui developer nu ii place sa consume timp cu testarea (pentru care exista testeri, meserie diferita), in mod sigur nu ii place sa sape in cod scris de altii si sa faca curat. In special cand volumul e mare nimeni nu va putea sa stie si sa inteleaga tot ce contine, asa ca ajunge sa creasca entropic pana cand, din cand in cand, cineva se apuca si ia o foaie alba de hartie pe care incepe un proiect nou care sa il inlocuiasca pe cel vechi.
PS. Din aceeasi serie e interesant un mic articol despre OpenSSL si serverele de web folosite in OpenBSD, problema mentenantei codului sursa si a gunoiului din el: http://www.openbsd.org/papers/httpd-asiabsdcon2015.pdf
Perfect de acord, nimeni nu spus ca e cod util. Dealtfel parca 40% sunt comment-uri daca imi amintesc bine . Sunt cifrele statistice din repo -ul lor. Problema e ca atunci cand auditezi codul trebuie sa te uiti la tot, nu doar la cel activ, tocmai pentru ca nu poti lua de bun daca cineva a scris acolo „not used” sau „deprecated”. E o munca de Sisif sa faci ordine in el ( a nu se intelege ca in cel comercial ar fi mai simplu, as zice ca dimpotriva :) )
Cand scriu despre cod inactiv sau depasit ma refer foarte strict la proceduri si resurse care nu sunt comentate, dar nu sunt niciodata apelate sau variante pentru arhitecturi care nu mai sunt in uz, gen Dec Alpha sau PowerPC. Codul sursa pentru x86 / Windows, de pilda, are cel mult cateva mii de linii si se poate audita usor.
Si nu e primul software de securitate care e auditat, acum un an s-a facut audit si pentru TrueCrypt, de pilda. Si e normal sa se faca extern, e nevoie de cateva perechi de ochi noi care sa se uite prin sertare.
Articol bazat pe o perceptie „nostalgica”!
Diferenta e enorma intre hardul si softul anilor ’80 comparativ cu cele ale prezentului.
e cas si cum am compara felcerul ce scotea o masea cu „uneltele” epocii sale cu stomatologul zilelor noastre cand se serveste de radiografie, apoi de anestezie si aparatura ce nu mai sperie pacientul,ca pe vremea acelui „feroce” scotzator de masele! Ba mai mult, o data maseaua „stricata” scoasa, e inlocuita cu una care ca si aspect e cam ca si cea „naturala”; nu’i departe ((e’n laborator deja) reproducerea ei prin „celule recuperate din sternul pacientului”
Vorbim de „epoci” complet diferite !
Din fericire, stiinta si cei in serviciul ei demonteaza „vechiul” rudimentar, inlocuindu’l prin ceva „nou” mult mai performant (nu vorbim aici de incidenta „comerciala” asupra unui produs la un moment dat, ci de pura inovatie spre folosu eil ulterior pentru societatea umana)