Nylig noen mennesker la merke til en merkelig endring i kildekoden til Linux-kjernen, deretter når du går gjennom kjernekoden på GitHub De la merke til at endringer som ble gjort av tredjeparter (de som klonet eller gafflet denne), så merkelig ut i hovedregisteret.
Dette fanget oppmerksomheten til noen på GitHub-grensesnittet da en interessant funksjon ble avslørt som lar deg presentere eventuelle tredjepartsendringer som en endring som allerede er inkludert i hovedprosjektet.
For eksempel begynte i dag i sosiale nettverk en referanse til en endring i det offisielle speilet til det viktigste Linux-kjernelageret å spre seg, noe som indikerer erstatning av en bakdør i HID-Samsung-driveren.
GitHub quirk alarmerte kerneutviklere
Stilt overfor denne konflikten noen begynte å sjekke kjernekoden, spesielt i Samsung-driveren i tillegg til å prøve å verifisere om sikkerheten til kjernen hadde blitt kompromittert.
En analyse av situasjonen viste det GitHub, for å optimalisere lagring og minimere duplisering av data på serverne, lagrer alle objekter fra hovedregisteret og gafler assosiert med det, og deler logisk eierskap av forpliktelser.
hvorpå Denne lagringsplassen tillater alle som surfer i koden for å se en bekreftelse fra en hvilken som helst gaffel i et tilknyttet lager, og angir eksplisitt hash i URL-en.
For eksempel, i tilfelle en bakdørdemo, opprettet en av brukerne en gaffel med hoved Linux-kjernelageret i GitHub-grensesnittet, og la deretter til en forpliktelse med bakdørlignende kode i gaffelen.
Etter det dannet det en lenke der SHA1-identifikatoren for den eksterne endringen ble erstattet i URL-en til hovedregisteret.
Når en lignende kobling åpnes, vises en ekstern forpliktelse i GitHub-grensesnittet i sammenheng med hovedregisteret, selv om det ble gjort på gaffelen og ikke har noe å gjøre med hovedregisteret, og det er ingen slik forpliktelse i det.
Videre I GitHub-grensesnittet, når du viser endringsloggen for individuelle filer, viser hovedlageret også tredjepartsforpliktelser, noe som skaper mye forvirring.
Dette skremte noen fordi de trodde at det var et hack og at de hadde introdusert ondsinnet kode til kildekoden til Linux-kjernen.
Vel, som vi kan se på bildet med det blotte øye, ser det ut til at den innsatte koden er en del av det som er lagret i hoved Linux Kernel repository.
Og at det først ikke refererer til de eksterne arkivene der modifikasjonene ble gjort.
Det hele var en falsk alarm
Denne "feilen" bekymret (for å si det så mange) fordi de foreløpig ikke visste om de allerede hadde noen risiko eller at integriteten til kjernen var blitt kompromittert.
Jeg bruker lite tid slik at de ville innse at når tredjepart ekstraheres eller kloning av et arkiv ved hjelp av git-kommandoer, manglet tredjepartsendringene i det resulterende depotet.
GitHub presenterte ganske enkelt endringene med et øyeblikk når det i virkeligheten ikke er det.
Foreløpig det er ikke kjent mer om det, og om folket i Github (Microsoft) har tenkt å gi en løsning på dette, som ikke direkte påvirker utviklingen, langt mindre når du skaffer kjernekildekoden.
Men hva om det kan forvirre mange som velger å gjennomgå noen deler av prosjektene som er lagret på Github.
Vel, det er ikke noe som vises direkte i Linux-kjernekoden, men det vil også vises i gafler eller gafler i andre prosjekter.
Så det er mulig at mange utviklere eller brukere av denne plattformen allerede har sendt noen e-poster til folket på GitHub.
Hvis du vil vite litt mer om dette emnetdu kan besøke følgende lenke der koden som dannet denne situasjonen fremdeles vises, og også kommentarene til den om det her.