![\"Kees](\"\/wp-content\/uploads\/2021\/08\/3e472a24f4fd9a6b434c706b3dfe3a35.png\")
<\/center>Zgjidhja m\u00eb optimale do t\u00eb ishte t\u00eb transferoheshin vet\u00ebm korrigjimet dhe dob\u00ebsit\u00eb m\u00eb t\u00eb r\u00ebnd\u00ebsishme, por p\u00ebrzgjedhja e k\u00ebtyre gabimeve nga fluksi i p\u00ebrgjithsh\u00ebm \u00ebsht\u00eb problemi kryesor. Numri m\u00eb i madh i problemeve q\u00eb shfaqen \u00ebsht\u00eb pasoj\u00eb e p\u00ebrdorimit t\u00eb gjuh\u00ebs C, e cila k\u00ebrkon sakt\u00ebsi t\u00eb madhe gjat\u00eb pun\u00ebs me memorjen dhe treguesit. Situat\u00ebn e r\u00ebndon fakti se shum\u00eb nga korrigjimet e mundshme t\u00eb dob\u00ebsive nuk p\u00ebrfshijn\u00eb identifikues CVE ose e marrin nj\u00eb t\u00eb till\u00eb pas nj\u00eb koh\u00eb pas publikimit t\u00eb korrigjimit. N\u00ebn k\u00ebto kushte, prodhuesve u \u00ebsht\u00eb shum\u00eb e v\u00ebshtir\u00eb t\u00eb ndajn\u00eb korrigjimet dyt\u00ebsore nga problemet e r\u00ebnd\u00ebsishme q\u00eb ndikojn\u00eb n\u00eb siguri. Sipas statistikave, mbi 40% e dob\u00ebsive zgjidhen para se t'u jepet nj\u00eb CVE dhe mesatarisht, vonesa midis publikimit t\u00eb korrigjimeve dhe ndarjes s\u00eb CVE \u00ebsht\u00eb tre muaj (dmth, n\u00eb fillim korrigjimi perceptohet si nj\u00eb gabim i zakonsh\u00ebm, por vet\u00ebm pas disa muajsh b\u00ebhet e qart\u00eb se kishte t\u00eb b\u00ebnte me nj\u00eb dob\u00ebsi).<\/p>\nN\u00eb p\u00ebrfundim, pa nj\u00eb deg\u00eb t\u00eb ve\u00e7ant\u00eb me korrigjime p\u00ebr dob\u00ebsit\u00eb dhe pa marr\u00eb informacionin mbi lidhjen me sigurin\u00eb e \u00e7\u00ebshtjeve t\u00eb caktuara, prodhuesve t\u00eb produkteve t\u00eb bazuara n\u00eb kernelin Linux u mbetet t\u00eb vazhdojn\u00eb t\u00eb transferojn\u00eb t\u00eb gjitha korrigjimet nga deg\u00ebt e reja stabile. Por ky punim k\u00ebrkon p\u00ebrpjekje t\u00eb m\u00ebdha dhe has n\u00eb rezistenc\u00eb n\u00eb kompanit\u00eb p\u00ebr shkak t\u00eb frik\u00ebs p\u00ebr shfaqjen e ndryshimeve regresive q\u00eb mund t\u00eb d\u00ebmtojn\u00eb funksionimin normal t\u00eb produktit.<\/p>\n
T\u00eb kujtojm\u00eb se sipas mendimit t\u00eb Linus Torvalds, t\u00eb gjitha gabimet jan\u00eb t\u00eb r\u00ebnd\u00ebsishme dhe dob\u00ebsit\u00eb nuk duhet t\u00eb ndahen nga lloje t\u00eb tjera gabimesh dhe t\u00eb ve\u00e7ohen n\u00eb nj\u00eb kategori m\u00eb prioritet. Ky mendim shpjegohet me faktin se p\u00ebr nj\u00eb zhvillues t\u00eb zakonsh\u00ebm, q\u00eb nuk specializohet n\u00eb \u00e7\u00ebshtjet e siguris\u00eb, lidhja e korrigjimit me nj\u00eb dob\u00ebsi t\u00eb mundshme nuk \u00ebsht\u00eb e qart\u00eb (p\u00ebr shum\u00eb korrigjime, vet\u00ebm realizimi i nj\u00eb auditi t\u00eb ve\u00e7ant\u00eb mund t\u00eb tregoj\u00eb se ato kan\u00eb t\u00eb b\u00ebjn\u00eb me sigurin\u00eb). Sipas Linus, specializuesit e siguris\u00eb nga ekipet q\u00eb p\u00ebrgjigjen p\u00ebr mb\u00ebshtetje t\u00eb paketave me kernelin n\u00eb distribucione t\u00eb Linux duhet t\u00eb merren me ndarjen e dob\u00ebsive t\u00eb mundshme nga fluksi i p\u00ebrgjithsh\u00ebm i ndryshimeve.<\/p>\n
Kis Cook beson se zgjidhja e vetme p\u00ebr t\u00eb ruajtur sigurin\u00eb e kernelit me kostot e arsyeshme afatgjata \u00ebsht\u00eb t\u00eb transferohen ingjinier\u00ebt e kompanive q\u00eb punojn\u00eb p\u00ebr portimin e korrigjimeve n\u00eb nd\u00ebrtimet lokale t\u00eb kernelit n\u00eb nj\u00eb pun\u00eb t\u00eb p\u00ebrbashk\u00ebt dhe t\u00eb koordinuar p\u00ebr mb\u00ebshtetje t\u00eb korrigjimeve dhe dob\u00ebsive n\u00eb kernelin kryesor (upstream). N\u00eb form\u00ebn aktuale, shum\u00eb prodhues p\u00ebrdorin n\u00eb produktet e tyre versione t\u00eb kernelit q\u00eb nuk jan\u00eb m\u00eb t\u00eb reja dhe portojn\u00eb korrigjimet me forcat e tyre, dmth, ingjinier\u00ebt e kompanive t\u00eb ndryshme po p\u00ebrs\u00ebrisin pun\u00ebn e nj\u00ebri-tjetrit, duke zgjidhur t\u00eb nj\u00ebjtin problem.<\/p>\n
P\u00ebr shembull, n\u00ebse 10 kompani, nj\u00eb inxhinier n\u00eb secil\u00ebn prej t\u00eb cilave merret me riparimin e t\u00eb nj\u00ebjtave gabime, do t'i drejtonin k\u00ebta inxhinier\u00eb p\u00ebr t\u00eb korrigjuar gabimet n\u00eb upstream, ata n\u00eb vend se t\u00eb portonin nj\u00eb korrigjim, do t\u00eb ishin n\u00eb gjendje t\u00eb riparonin 10 gabime t\u00eb ndryshme p\u00ebr dobin\u00eb e p\u00ebrgjithshme ose t\u00eb angazhoheshin n\u00eb rishikimin e ndryshimeve t\u00eb propozuara dhe t\u00eb parandalonin p\u00ebrfshirjen e kodit me gabime n\u00eb b\u00ebrtham\u00eb. Burimet gjithashtu mund t\u00eb drejtoheshin n\u00eb krijimin e mjeteve t\u00eb reja p\u00ebr testimin dhe analiz\u00ebn e kodit, t\u00eb cilat do t\u00eb lejonin identifikimin automatik t\u00eb klasave tipike t\u00eb gabimeve q\u00eb shfaqen vazhdimisht n\u00eb fazat e hershme.<\/p>\n
Kees Cook gjithashtu ofron q\u00eb t\u00eb p\u00ebrdoren m\u00eb aktivisht testimi automatizuar dhe fuzzing direkt n\u00eb procesin e zhvillimit t\u00eb b\u00ebrtham\u00ebs, t\u00eb aplikohen sisteme t\u00eb integrimit t\u00eb vazhduesh\u00ebm dhe t\u00eb largohet menaxhimi arkaik i zhvillimit p\u00ebrmes emailit. Aktualisht, testi efektiv pengohet nga fakti se proceset kryesore t\u00eb testimit jan\u00eb t\u00eb ndara nga zhvillimi dhe ndodhin pas formimit t\u00eb l\u00ebshimeve. Kees gjithashtu rekomandoi q\u00eb p\u00ebr t\u00eb ulur numrin e gabimeve, t\u00eb aplikohen gjat\u00eb zhvillimit gjuh\u00eb q\u00eb ofrojn\u00eb m\u00eb shum\u00eb nj\u00eb nivel t\u00eb lart\u00eb sigurie<\/a>, si Rust.<\/p>\n