![\"Kees](\"\/wp-content\/uploads\/2021\/08\/3e472a24f4fd9a6b434c706b3dfe3a35.png\")
<\/center>Nj\u00eb zgjidhje optimale do t\u00eb ishte transferimi vet\u00ebm i korrigjimeve dhe dob\u00ebsive m\u00eb t\u00eb r\u00ebnd\u00ebsishme, por gjetja e k\u00ebtyre problemeve mes nj\u00eb morie tjet\u00ebr \u00ebsht\u00eb problemi kryesor. Numri m\u00eb i madh i problemeve t\u00eb papritura \u00ebsht\u00eb pasoj\u00eb e p\u00ebrdorimit t\u00eb gjuh\u00ebs C, e cila k\u00ebrkon kujdes t\u00eb madh kur punoni me memorien dhe treguesit. E p\u00ebrkeq\u00ebson situat\u00ebn fakti se shum\u00eb korrigjime t\u00eb mundshme t\u00eb dob\u00ebsive nuk shoq\u00ebrohen me identifikuesit CVE ose i fitojn\u00eb k\u00ebto identifikues pas nj\u00eb kohe t\u00eb caktuar nga publikimi i korrigjimit. N\u00eb k\u00ebto kushte, prodhuesve u \u00ebsht\u00eb shum\u00eb e v\u00ebshtir\u00eb t\u00eb ndajn\u00eb korrigjimet e zakonshme nga problemet e r\u00ebnd\u00ebsishme q\u00eb ndikojn\u00eb n\u00eb siguri. Sipas statistikave, m\u00eb shum\u00eb se 40% e dob\u00ebsive zgjidhen para se t'i jepet nj\u00eb CVE dhe, mesatarisht, vonesa midis publikimit t\u00eb korrigjimit dhe caktimit t\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 ishte nj\u00eb korrigjim i nj\u00eb dob\u00ebsie).<\/p>\nSi rezultat, duke mos pasur nj\u00eb deg\u00eb t\u00eb ve\u00e7ant\u00eb p\u00ebr korrigjimet e dob\u00ebsive dhe duke mos marr\u00eb informacione lidhur me sigurin\u00eb e ndonj\u00eb problemi, prodhuesve t\u00eb produkteve mbi kernelin Linux u mbetet t\u00eb transferojn\u00eb vazhdimisht t\u00eb gjitha korrigjimet nga deg\u00ebt stabile t\u00eb fundit. Por kjo pun\u00eb k\u00ebrkon shum\u00eb burime dhe p\u00ebrballet me rezistenc\u00eb nga kompanit\u00eb p\u00ebr shkak t\u00eb frik\u00ebs nga ndryshimet regresive q\u00eb mund t\u00eb prisnin funksionimin normal t\u00eb produktit.<\/p>\n
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 klasifikohen n\u00eb nj\u00eb kategori m\u00eb prioritar. 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 nj\u00eb korrigjimi me nj\u00eb dob\u00ebsi t\u00eb mundshme nuk \u00ebsht\u00eb e dukshme (p\u00ebr shum\u00eb korrigjime, vet\u00ebm kalimi n\u00eb nj\u00eb auditi t\u00eb ve\u00e7ant\u00eb lejon t\u00eb kuptohet se ato lidhen me sigurin\u00eb). Sipas Linus, specialist\u00ebt e siguris\u00eb nga ekipet p\u00ebrgjegj\u00ebse p\u00ebr mb\u00ebshtetje t\u00eb pakove me kernel n\u00eb shp\u00ebrndarjet Linux duhet t\u00eb merren me identifikimin e dob\u00ebsive t\u00eb mundshme nga rrjedha e zakonshme e korrigjimeve.<\/p>\n
Kis Kuk mendon se zgjidhja e vetme p\u00ebr t\u00eb mbajtur sigurin\u00eb e kernelit me kostot e arsyeshme afatgjata \u00ebsht\u00eb transferimi i inxhinier\u00ebve t\u00eb kompanive, t\u00eb angazhuar n\u00eb portimin e rregullimeve 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 dhe rregullime t\u00eb dob\u00ebsive n\u00eb kernelin kryesor (upstream). N\u00eb form\u00ebn e tanishme, shum\u00eb prodhues p\u00ebrdorin n\u00eb produktet e tyre versione t\u00eb vjetra t\u00eb kernelit dhe b\u00ebjn\u00eb backport-e t\u00eb rregullimeve me forcat e tyre, duke e b\u00ebr\u00eb q\u00eb inxhinier\u00ebt n\u00eb kompani t\u00eb ndryshme t\u00eb kopjojn\u00eb pun\u00ebn e nj\u00ebri-tjetrit duke zgjidhur t\u00eb nj\u00ebjt\u00ebn problem.<\/p>\n
P\u00ebr shembull, n\u00ebse 10 kompani, secila prej t\u00eb cilave ka nj\u00eb inxhinier t\u00eb angazhuar n\u00eb backport-in e t\u00eb nj\u00ebjtave rregullime, do t'i ri-orientonin k\u00ebta inxhinier\u00eb n\u00eb rregullimin e gabimeve n\u00eb upstream, ata n\u00eb vend q\u00eb t\u00eb portonin nj\u00eb rregullim mund t\u00eb rregullonin 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 kernel. 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 t\u00eb identifikonin automatikisht, n\u00eb nj\u00eb faz\u00eb t\u00eb hershme, klasat tipike t\u00eb gabimeve q\u00eb shfaqen p\u00ebrher\u00eb e m\u00eb shum\u00eb.<\/p>\n
Kis Kuk gjithashtu propozon t\u00eb p\u00ebrdoret m\u00eb aktivisht testimi i automatizuar dhe fuzzing-testi direkt n\u00eb procesin e zhvillimit t\u00eb kernelit, t\u00eb aplikohet sisteme t\u00eb integrimit t\u00eb vazhduesh\u00ebm dhe t\u00eb braktiset menaxhimi arkaik i zhvillimit p\u00ebrmes email-it. Aktualisht, testi efikas pengohet nga fakti se proceset kryesore t\u00eb testimit jan\u00eb t\u00eb ndara nga zhvillimi dhe ndodhin pas formimit t\u00eb l\u00ebshimeve. Kis gjithashtu ka rekomanduar q\u00eb p\u00ebr t\u00eb reduktuar numrin e gabimeve t\u00eb p\u00ebrdoren gjuh\u00eb q\u00eb ofrojn\u00eb m\u00eb shum\u00eb nivel i lart\u00eb sigurie<\/a>, si Rust.<\/p>\n