Linux-kernel verhuist tijdelijk naar Github

Linus Torvalds heeft aangekondigd dat hij de Linux-kernel voorlopig via Github zal distribueren. Het besluit van de Linux-voorman volgt op de recente aanval op Kernel.org. Het is niet duidelijk hoelang Github gebruikt zal worden als thuisbasis.

Onlangs werd bekend dat hackers in augustus toegang hebben verkregen tot de servers die worden ingezet om de Linux-kernel te verspreiden. De aanvallers wisten op in ieder geval één server van Kernel.org een trojan te plaatsen, terwijl er ook gerommeld werd met openssh-bestanden. Direct nadat de hack werd opgemerkt, hebben de systeembeheerders de site offline gehaald.

Omdat het updateproces van kernel.org nog niet is voltooid en ook de broncode nog wordt geverifieerd op mogelijke manipulaties, heeft Linus Torvalds besloten om voorlopig uit te wijken naar Github. Inmiddels heeft hij de git repositories van Linux-kernel 3.1-rc5 op de servers van Github geplaatst zodat er doorgewerkt kan worden aan de opensource-kernel. Torvalds meldt dat het hosten van de kernel bij Github tijdelijk is, maar hoelang de terugkeer naar Kernel.org op zich zal laten wachten is onduidelijk.

Reacties (41)

[Joseph]

Waarom geen Sourceforge? Maarja, ik weet niet of het een goede beslissing is.

GitHub is veel groter, en daarom ook veel eerder doelwit. Bovendien weten de hackers nu dat ze bang zijn dat ze nog lekken hebben die een herhaling mogelijk maken, en ik vrees dat juist dat extra stimulatie voor hackers is om nu GitHub op de pijnbank te leggen.

Ik vind trouwens wel dat het één grote chaos begint te worden, en ik krijg het vermoeden dat er weinig echte expertise lijkt te zijn om systemen goed te beveiligen. Maar dat is een verhaal apart.

[Verwijderd]

Waarom geen Sourceforge? Maarja, ik weet niet of het een goede beslissing is.

Ik denk niet dat SourceForge de traffic goed aankan, SF staat nu eenmaal niet bekend om zijn snelle websites. Ook heeft SF SSh toegang tot projecten (Github heeft dit niet) en ik neem aan dat je dit momenteel even niet wilt.

Het zou mij niets verbazen dat github en speciale server hiervoor gaat opzetten, het is tenslotte uitermate mooie reclame voor github...

Bovendien weten de hackers nu dat ze bang zijn dat ze nog lekken hebben die een herhaling mogelijk maken..

Dit heeft niets met Bang te maken, immers git zit dusdanig in elkaar dat als je de juiste hash weet, je heel simpel kunt bekijken of de source is aangepast in een bepaalde repo. Dus bang kwa 'help de source is aangepast.... of misschien niet' is er totaal niet bij.

Ik vind trouwens wel dat het één grote chaos begint te worden,

Kwa chaos valt het wel mee denk ik, er is in het verleden altijd aangenomen dat open source projecten minder snel of zelfs niet worden aangevallen, want we hebben tenslotte een soort 'Gentleman agreement' rondom dit, je gaat geen open source project hacken als je zelf gebruikt maakt van die open source.....

Het is dus nu meer een kwestie van betere afspraken maken tussen ontwikkelaars, geen SSH keys zonder wachtwoord, betere wachtwoorden en beter updaten, dat soort zaken...

[quote]
en ik krijg het vermoeden dat er weinig echte expertise lijkt te zijn om systemen goed te beveiligen. Maar dat is een verhaal apart.
[/quote]
Nu zal dat wel niet echt voor de Linux kernel gelden, maar vergeet niet dat een hele hoop open source projecten vrijwilligers werk is, en je hebt nu eenmaal beperkte tijd, avonden en weekenden dus. Kwa beveiliging doe je je best, maar je kunt niet tot het 'gaatje' doorgaan todat het perfect is.

[mindcrash]

Het zou mij niets verbazen dat github en speciale server hiervoor gaat opzetten, het is tenslotte uitermate mooie reclame voor github...

Volgens mij moet jij eens even dit verhaal lezen of deze video bekijken, want dan kun je zien dat ze aan "een speciale server" niets maar dan ook niets gaan hebben ...

Zoals je kunt zien/horen/lezen hebben ze daar inmiddels een behoorlijk forse setup staan bestaande uit onder meer een gevirtualiseerde load balancer (gebaseerd op Xen gebruikmakende van ldirectord), een viertal baremetal frontend webservers voor HTTP verkeer (gebaseerd op Nginx, Rails en Unicorn), twee dikke baremetal database servers voor MySQL en Redis, en (als ik het goed heb begrepen) 8 dikke filleservers waar de git repositories worden opgeslagen.

En aangezien GitHub op dit moment al prima de traffic trekt van ruim 3 miljoen andere projecten waaronder grote bekende OSS projecten zoals Sinatra, Rails, Redis, jQuery, Memcached, Ruby, PhpBB en Node to name a few denk ik niet dat de traffic die ze er nu bij krijgen omdat de kernel developers tijdelijk naar Github uitwijken de site compleet plat trekken; en als ze merken dat ze toch in de problemen komen dan is het slechts een kwestie van wat nieuwe servers in het frontend en backend segment prikken, de automatische configuratie software zijn werk laten doen en er staat weer wat extra capaciteit klaar om het extra IO verkeer op te vangen.

[Reactie gewijzigd door mindcrash op 23 juli 2024 05:02]

[elmuerte]

Dat is juist de grap van git (en veel andere DVCS), de load op een systeem is een stuk lager omdat iedereen z'n eigen speeltuin heeft. Het kost wat meer metadata werk, maar dat is licht vergeleken met het echte revisie control.

[Verwijderd]

Ik lees helaas en gelukkig nooit alles wat in de IT wereld omgaat,
dankt voor de link, ga ik zeker even doorlezen.

Ik 'dacht' dit omdat guthub voor bedrijven eigen github server kans plaaten binnen je eigen firewall. Het leek mij in eerste instantie dus een logische stap dat ze dit voor de lInux kernel ook zouden doen.

[RielN]

Wordt die linuxkernel dan zoveel weggetrokken??

[Gertjan]

immers git zit dusdanig in elkaar dat als je de juiste hash weet, je heel simpel kunt bekijken of de source is aangepast in een bepaalde repo. Dus bang kwa 'help de source is aangepast.... of misschien niet' is er totaal niet bij.

'totaal niet' is wellicht een beetje te sterk uitgedrukt

[ILUsion]

Totaal niet is inderdaad misschien de sterk uitgedrukt, het is en blijft spelen met kansrekening. De SHA1-hash is dan wel redelijk veilig (helemaal veilig is hij ook niet meer), maar je behoudt bij om het even welke hash steeds de mogelijkheid op een collision, waarbij er dus content verloren gaat of mogelijk zelfs gecorrumpeerd wordt.

Maar als we eerlijk zijn: zelfs voor SHA1 is dat een moeilijke opgave: je moet immers niet enkel een stukje broncode maken die voldoet aan een bepaalde hash, maar die broncode moet ook nog eens zinvol zijn. Enerzijds moet je oorspronkelijke functionaliteit erin zitten (anders werkt de rest niet meer en krijg je dus problemen met allerhande unit tests) en je moet er een exploit in steken die je kan uitbuiten. Zelfs zonder de theoretische cryptografische veiligheid van SHA1 (want die is immers al gebroken), is het nog aartsmoeilijk om iets kwaadaardig met dat alles te beginnen.

Git maakt het voor de inbrekers dus heel wat moeilijker dan bijna elk ander versiecontrolesysteem op de markt, waar je ook al tegen die functionele constraints aanwerkt. Het nadeel dat dergelijke open source wel heeft is dat men alles op voorhand kan klaarstomen, je moet dus niet inbreken, dan een geschikte plaats voor een exploit zoeken tussen al die code, die exploit schrijven en vervolgens een collision proberen te vinden die aan al je eisen voldoet om nadien die exploit te injecteren (wat er dus waarschijnlijk op neerkomt dat je een tweede maal moet inbreken, dus met extra risico dat je ontdekt wordt).

[indigo79]

Op zich vraagt het aanpassen van de broncode zonder dat de SHA1 hash verandert alleen veel (heel veel) rekenkracht.

Je past de broncode aan, en je krijgt een andere hash. Het 'enige' wat je dan nog moet doen is een combinatie van niet-functionele wijzigingen zoeken die dezelfde hash code genereert. Je kan in C code zowat overal spaties toevoegen en op heel veel plaatsen ook verwijderen, dus een bepaalde combinatie van toegevoegde of verwijderde spaties zal wel dezelfde hash geven.

Theoretisch is het perfect mogelijk en zelfs absoluut niet moeilijk; in de praktijk vraagt het enorm veel rekenkracht...

[Verwijderd]

Git's hash wordt ook bepaald aan de bestands grote, om deze reden kun je geen lege directories aan git toevoegen.

Je moet dus een sha1 genereren voor eens file die nog steeds iets zinvols produceert waarbij de bestand grote gelijk blijft.

Als de bestand grote met ook maar een byte veranderd, dan worden alle commits ook kwa sha1 veranderd.

Volgen smij is het nog steeds niet mogelijk om een commit binnen git te veranderen, juist om deze reden.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 05:02]

[Verwijderd]

Wat dacht je van comments? Die zou ik gebruiken om een hash te maken.

[s.stok]

De comments of commit messages zijn ook onderdeel van hash voor die commit.
Dat is ook de reden waarom ze je (met uitzondering van de laatste, via ament) niet meer kan aanpassen. Dit zou immers de commit zekerheid omver kunnen gooien.

[BumEyes]

Ook met amend pas je de commit niet echt aan. Amend gooit je laatste commit weg en maakt een nieuwe met diezelfde inhoud plus de wijzigingen die jij aangeeft.

Een commit die al gepushed is kan je dus ook niet zomaar amenden zonder later conflicten te krijgen.

[OddesE]

Waarom geen Sourceforge?

Linus Torvalds heeft Git zelf geschreven.

Verder heeft hij, toen hij Git introduceerde, CVS en SVN (traditioneel de versiebeheer tools van SourceForge) flink afgekraakt (min of meer terecht imho). GitHub is dus een hele logische keus voor hem.

Ik zie het wel gebeuren dat de repository op GitHub zometeen zo populair wordt dat Kernel.org er voortaan gewoon heen linked...

[s.stok]

Ik begrijp überhaupt niet waarom ze niet op Github zijn overgestapt.

Pull request zijn veel makkelijker dan de ander patches en puls mailen.
En je kan direct reageren.

Plus, de ander kan gewoon een pull doen van jouw repository.
Ook als je computer niet aan staat.

Over de naam Git en Torvalds.

Linus Torvalds has quipped about the name "git", which is British English slang for a stupid or unpleasant person:[4] "I'm an egotistical bastard, and I name all my projects after myself. First Linux, now git."[5][6] he said humorously.

Bron: http://en.wikipedia.org/wiki/Git_%28software%29

[Carharttguy]

Git is ontworpen door Linus himself, lijkt me logisch dat hij zijn eigen systeem gebruikt.

[elmuerte]

sf.net heeft ook git (naast cvs, svn, hg, bzr)

Linus koos voor github voor de Linux kernel omdat Linus al een github account had.

sf.net heeft trouwnes jaren lang as primary mirror gedient voor de linux kernel.

[mvdejong]

Het is erg lastig om je te beveiligen tegen lekken die nog niemand (behalve de hackers) ontdekt heeft. Terwijl de meeste lekken tegenwoordig wel in het review-proces op tijd worden gezien, zullen er altijd nieuwe lekken blijven opduiken, en dan bestaat de kans dat de kwaden dat eerder opmerken dan de goeden, en dus de aanval inzetten voordat het probleem bekend is, geanalyseerd is, en opgelost is.

[Ellos]

Omdat hij zo de bestaande eigen git repositories binnen een paar klikken had overgezet naar GitHub

[siepeltjuh]

Van GitHub kan ik zo geen succesvolle hacks vinden. Sourceforge is echter al een aantal keren het slachtoffer geweest van een hack: http://sourceforge.net/blog/sourceforge-attack-full-report/

Het zou natuurlijk helemaal slechte pr zijn om na het uitwijken opnieuw gehacked te worden, hoe weinig Linu(s/x) er ook zelf aan kan doen bij een externe partij.

[CH4OS]

Waarom geen Sourceforge? Maarja, ik weet niet of het een goede beslissing is.

GitHub is veel groter, en daarom ook veel eerder doelwit. Bovendien weten de hackers nu dat ze bang zijn dat ze nog lekken hebben die een herhaling mogelijk maken, en ik vrees dat juist dat extra stimulatie voor hackers is om nu GitHub op de pijnbank te leggen.

Ik vind trouwens wel dat het één grote chaos begint te worden, en ik krijg het vermoeden dat er weinig echte expertise lijkt te zijn om systemen goed te beveiligen. Maar dat is een verhaal apart.

Als je zo bang bent voor nieuwe aanvallen, dan sluit je de server(s) toch af van het internet? Ja, dan is de site en alles er omheen voor de buitenwereld ook niet te bereiken, maar dan kan er wel in alle rust gewerkt worden aan de mogelijke gaten en fouten.

[killingdjef]

Vanuit een iets meer algemener perspectief, erg lastig als bedrijf als je met een dergelijke hack te maken krijgt. Iedere keuze die je dan als bedrijf kan maken is slecht voor de naam van je bedrijf.

Onder het tapijt vegen? Ooit komt er iemand wel achter. (Diginotar)
Openlijk zeggen dat je gehackt ben? Vertrouwen komt te voet en gaat te paard en hoe dan ook, ook schadelijk.

Terwijl er binnen ieder bedrijf wel fouten gemaakt worden, soms buiten iemands macht om.

Nu is kernel.org een soort stichting/organisatie die gesponsored wordt.. maar in het geval van een commericeel bedrijf, wat zou een goede aanpak zijn in een soortgelijke situatie?

[ILUsion]

Volgens mij is de enige zinvolle reactie om open te zijn daarover. Als je kijkt hoe lang ze het al wisten bij DigiNotar, dat is gewoonweg onverantwoord. Dergelijk bedrijf kán je niet meer vertrouwen omdat je al bevestiging gehad hebt dat ze je niet inlichten als er gevaarlijke situaties voorkomen.

Dat er fouten gemaakt kunnen worden, dat is nu eenmaal zo. Als je een goede relatie hebt met een bedrijf/klant/partner, kan een klein foutje zo nu en dan wel eens. Persoonlijk heb ik er geen probleem mee dat een bedrijf niet 100% veilig is, maar er moet openheid zijn, zodat je zelf beslissingen kan nemen: vertrouw je het bedrijf nog genoeg om die informatie voor je te beheren of niet. Als je je partners niet inlicht, laat dat in mijn ogen zien dat je hen niet als partner aanschouwt, maar als een bron van inkomsten; dan gaat het niet om goede dienstverlening willen leveren (en in ruil daarvoor betaald te worden en winst te maken). Want dat is eigenlijk wat een klant nodig heeft: een betrouwbare en kwalitatieve dienst afnemen, daarvoor moeten betalen is een noodzakelijk "kwaad". Openheid is in mijn ogen gewoon een teken van wederzijds respect en de betrachting om een bepaalde relatie steeds op de status "win-win" te houden, zodat geen van beide partijen de relatie wilt stopzetten. (Maar niet alle partnerships zijn van dat utopische kaliber).

[mvdejong]

Altijd open zijn. Natuurlijk zijn er klanten die weglopen als je direct open kaart speelt, maar hoe lang denk je dat DigiNotar nog zal bestaan ? Ik denk niet dat de Kamer accepteert dat die nog iets voor de overheid mogen doen, hoeveel steun ze van de politieke achterkamertjes en de bevriende ambtenaren ook gaan krijgen.

[daft_dutch]

voor DigiNotar is het einde oefening. Internet Integriteit authenticatie is niet iets wat je als bedrijfje er bij doet zo iets is core business. (Niemand haalt een ssl certificaat bij de groenteboer) Integriteit is het bestaansrecht zo'n bedrijf. Iedereen weet nu dat de Integriteit van DigiNotar ergens diep diep onder NAP is. Omdat de zelfs de meest beperkte vorm van kwaliteit "hoe diep in de shit zitten we nu eigenlijk?" niet eens in volledigheid beantwoordt kan worden.

(edit: Transparant wat een woord wat een woord)
@Rudy:(hier onder) Je kan als bedrijf alleen transparant zijn als je transparant bent. Je kan niet zo maar als er een probleem optreed plotseling transparant zijn. Zo iets moet van zelf sprekend zijn anders heb je nooit de reactiesnelheid die bij transparantie vereist is.
Het is dus wel leuk typen "Transparantie vind ik persoonlijk altijd nog de beste manier van damage control." Maar je moet als bedrijf dan eigenlijk transparant zijn voordat die transparantie van het publiek vereist is. Zo iets kost tijd en geld. dus veel geld. Zonder dat er een enkele "return on investment" calculatie mogelijk is. maar ach doen als of is wel makkelijk en prima op te lossen door de marketing departement

[Reactie gewijzigd door daft_dutch op 23 juli 2024 05:02]

[reinouts]

Welke bevriende ambtenaren heb je het over? Als ik nu ambtenaar zou zijn die mijn vertrouwen in DigiNotar gesteld had zou ik me flink genaaid voelen.

[Rudy]

Transparantie vind ik persoonlijk altijd nog de beste manier van damage control. Bij een commercieel bedrijf is het een kwestie van je verliezen accepteren en proberen er het beste van te maken.

Als je dit niet kan zul je het eerder onder het tapijt vegen, of helaas kopje onder gaan. Maar als commerciele instantie hoor je ook bewust te zijn van deze risico's en je hier tegen (proberen) te beschermen.

[RHochstenbach]

Heeft Linus geen backup die hij kan terugzetten? Is het risico van gemanipuleerde code uitgesloten.

[Eloy]

Daar dacht ik ook al aan, het lijkt mij wel erg vreemd als er een backups zijn gemaakt van de kernel

edit:
En trouwens, als ze er naar zouden vragen heeft er vast nog wel iemand een ongemanipuleerde download staan.

[Reactie gewijzigd door Eloy op 23 juli 2024 05:02]

[RobertMe]

Backups? De "hele wereld" mirrort het toch al... (Linus zijn eigen woorden)

Theoretisch gezien hoeft Linus maar na elke wijziging op zijn repo. 40 karakters (sha1 hash) van de laatste commit op te schrijven. Daarna is elke repo. die een commit bevat met datzelfde commit id/diezelfde hash een volledige backup (+ misschien nieuwe toevoegingen). Dit omdat elke commit (en bestand) met zijn eigen sha1 hash wordt teruggevonden en alles op basis van deze hashes gelinkt is (files aan directories, directories onderling en commits aan een voledige directory tree). Doordat commits zelf weer een verwijzing bevatten naar hun voorgaande commit, ook weer op basis van de sha1 hash, is die ene sha1 hash dus voldoende om te controleren of de volledige repository nog geldig is tot die commit.

Praktisch zit dat misschien wat anders. Zie daarvoor de link van Gertjan hierboven.

[Antipater]

Heeft Linus geen backup die hij kan terugzetten? Is het risico van gemanipuleerde code uitgesloten.

Die heeft ie wel, en dankzij de het karakter van git hebben tienduizenden andere mensen dat ook. Het systeem van git versiebeheer zit daarnaast zo in elkaar dat het vrijwel onmogelijk is de code te manipuleren zonder dat mensen dit opmerken.

[elmuerte]

Dat is niet waar. Git is distributed, maar dat gaat betreft niet de revisie geschiedenis. Als Linus zijn master repo kwijt is dat is die niet meer terug te krijgen.
Maar, volgens mij heeft git wel de mogelijkheid voor niet-admins om de hele revisie te downloaden. Dus master mirrors zijn overal (waarschijnlijk).

[thechronic]

Huh? Dat is niet correct, als je een repo kloont heb je echt een volledige kopie inclusief volledige revisiegeschiedenis. Dat is heel het punt van git. Er is geen master.

[psyBSD]

Only wimps use tape backup: _real_ men just upload their important stuff
on ftp, and let the rest of the world mirror it

Linus

http://groups.google.com/...rnel/msg/76ae734d543e396d

edit:
Hmm... had eigenlijk een reply op RobertMe moeten zijn.

[Reactie gewijzigd door psyBSD op 23 juli 2024 05:02]

[BeosBeing]

Dat is een leuke.
Echter met klantgegevens, die dus vertrouwelijk zijn, ga je het dus niet zo doen.

[Stannieman]

Ik ben een android beginner en linux noob, en probeer wat met android momenteel.
Het commando "$ repo init -u git://android.git.kernel.org/platform/manifest.git" op deze pagina doet het niet, ondanks dat alle vorige stappen wel goed werkten zonder foutmelding.

Wil dat dan zeggen dat ook de android source nu van github gedownload moet worden?

[Verwijderd]

Het is jammer dat het moderatiesysteem het niet toestaat iemand op weg te helpen zonder karma te verliezen. Toch ga ik het doen Je kunt je vraag stellen op GoT, precies hier: Non-Windows Operating Systems of hier Google Android Smartphones

[Stannieman]

Heb het al opgelost gekregen ondertussen.
De android code kan inderdaad niet meer gedownload worden van kernel.org, heb hem nu van codeaurora.org.

[mainvoid]

het is goed dat er op zon moment nog alternatieve plekken zijn om de code e.d. te hosten. Het zou wat zijn als je alleen nog met een mogelijk nog geïnfecteerd systeem zou kunnen werken.

[BeosBeing]

Tja, ik ken een project/site dat gehost was bij een bedrijf dat falliet gegaan is zodat de serverprovider de boel heeft platgegooid. De sitebeheerders proberen nu de data via de serverprovider terug te krijgen, blijkbaar was er geen budget voor een goede backup-oplossing. Zoiets komt hard aan, ook al is het in dit geval slechts een site met themes.
(voor litestep http://www.ls-themes.org/)

[ReDi]

"zodat er doorgewerkt kan worden aan het opensource-OS"...
De Linux kernel is nog steeds geen OS en zal dat ook niet worden...