UMN is een Microsoft bolwerk ( https://it.umn.edu/services-technologies/resources/office Het zal mij niet verbazen als dit z.g. onderzoek door MS ook is gesponsered. Op zwarte lijst houden. Bijdragen komen toch alleen van technische universiteiten.

Wat een onzin, UMN is juist een Linux bolwerk (https://it.umn.edu/services-technologies/fully-managed-linux-hosting). Met andere woorden, wat bewijst één link nou over de IT strategie van een hele universiteit?

Waarom helemaal niets over het feit dat Greg Kroah-Hartman al heeft aangegeven dat die excuses niet voldoende zijn?

Als ik die gasten was dan zou ik mij in een hoekje heel diep gaan zitten schamen voor dat puberale gedrag om expres Linux proberen te vernagelen. Gewoon, omdat het kan, voor de lol.
Alleen om te kijken of iemand het door had. Sodemieter toch op, oplichters.

Hoezo oplichters? Het geeft wel aan dat te veel mensen toegang hebben tot de source code en er teveel vertrouwen is in andermans eerlijkheid en er dus niet kritisch gekeken wordt naar de toevoegingen van anderen. Als een boze medewerker wil, kan hij dus kwaadaardige code toevoegen.

Gelukkig wordt er dus wel kritisch naar gekeken.
Anders waren ze nooit betrapt.
En ja, de Linux gemeenschap is er 1 die op een stukje vertrouwen gebaseerd is om de boel draaiende te houden.
En het staat iedereen vrij om zich aan te melden, als je denkt kennis genoeg te hebben, om daar aan deel te nemen.
Linux is gratis, er bestaat geen Linux kantoor waar geld verdienen een prioriteit is.
En elke boze medewerker kan altijd overal bewust de boel saboteren, in elke firma of bedrijf.
Dan zou je ook niemand meer kunnen vertrouwen binnen je firma of bedrijf als je daar van uit moet gaan.

Maar hoe kritisch moet je kijken naar iemand die beweert ergens iets te kunnen verbeteren door een uitbreiding en dit instuurt als oplossing.
Als je op een loonlijst staat kan je er ook bewust een zooitje van maken, alleen ben je dan je baan kwijt.
Alleen door dat te testen komen ze er ook achter of het ook de moeite waard was, ook goed werkt en of je bewust de boel besodemietert.

Helemaal mee eens. Security through obscurity en open source gaan niet samen. Bovendien; als het niet in de openheid gedaan wordt, wordt het wel door anderen geprobeerd. En die zullen daar uiteindelijk in slagen.

Klinkt me als een gevalletje "don't shoot the messenger" (UMN als messenger van een kwetsbaarheid) . Bij UMN is er twijfel over de veiligheid van kernel updates:
- men doet een onderzoek en publiceert de resultaten
- men geeft de reden aan waarom de kernel maintainers niet zijn ingelicht (beinvloeding van de resultaten)

Met het onderzoek is aangetoond dat het mogelijk is om via een goed gecoördineerde aanval (denk bv. aan statelijke actoren) kwetsbaarheden in de kernel te introduceren. Lijkt mij van belang.
UMN krijgt als "dank" de mededeling dat men niets meer mag bijdragen.

Je gaat je dan afvragen: is het ego van de maintainers (en de gehele Linux community?) dan zo groot dat men zich afzet tegen het onderzoek, in plaats van een discussie aan te gaan hoe dit soort stealth attacks te blokkeren?

Q

Grappig, jouw reactie is de manier waarop gevestigde bedrijven reageren naar onderzoekers die kwetsbaarheden in hun software ontdekken en hun daarover informeren: kwaad spreken en excuses eisen, ipv. de problemen oplossen...

Ik weet het niet precies zeker, maar bestaat het hele synaptic pakket niet uit allemaal kleine stukje van die open source code waar Linux uit bestaat en op gebouwd is.
Dus iedereen die Linux draait heeft dan al inzicht in die open source code als je synaptic er bij zet uit het software centrum of via je terminal.
Je kan in dat gedeelte soms iets verbeteren of de hele boel laten vast lopen waardoor er niks meer werkt.
Als je er geen verstand van heb, dan moet je vooral daar helemaal bij weg blijven.

Ik snap de reactie van de community en ook van de beheerders.
Maar aan de andere kant denk ik toch wel dat deze studenten nu net iets hebben gedaan wat mogelijk is.
Maw. hun project is in mijn opinie geslaagd. Even ter zijde dat hun acties onverantwoord zijn om dit zo te testen zeker door het wijd gebruik van linux in zakelijke wereld. Maar zoals aangekaart legt dit wel iets fundamenteel bloot.
Dat men dus kwetsbaarheden kan introduceren door deze commits en dat de beheerders ook niet alles gaan spotten.

Op zich is dit logisch dat dit kan maar men kan niet anders dan toegeven dat dit een zwakte is van een opensource project waarbij enorm veel mensen samen werken. Alles steunt op vertrouwen maar vertrouwen kan vlug omslaan naar jaloezie of wraak. Klikt wat dramatisch maar ik zie niet dat deze zo moeten worden afgerekend op hun acties.

In elk geval toont dit nogmaals dat hun project hun doel hebben bereikt.
Abrupt wakker schudden van de community dat dergelijk praktijken effectief of mogelijks gebruikt kunnen worden.
En in plaats van straffen zouden ze op zijn minst wat erkenning mogen krijgen om dit bloot te leggen.

Ik denk wel dat ze nu wel moeten meewerken om hun bad commits ongedaan te maken.

" Grappig, jouw reactie is de manier waarop gevestigde bedrijven reageren naar onderzoekers die kwetsbaarheden in hun software ontdekken en hun daarover informeren: kwaad spreken en excuses eisen, ipv. de problemen oplossen.. "

Er is geen kwetsbaarheid ontdekt in hun software. Die klopte verder wel.
Tenslotte waren ze zelf die onderzoekers die het naar buiten gedragen hebben, niemand van buiten heeft ze hier attent op hoeven maken.
Maar er waren bewust saboteurs bezig met zogezegd goede bedoelingen om de boel te vernagelen die ze gelukkig op tijd door hadden.
Waarna de problemen opgelost zijn door deze oplichters uit te sluiten van deelname aan de linux gemeenschap.

Waar jij het over hebt en waarschijnlijk bedoeld is dat het in eerste instantie ontkent zou worden dat er kwetsbaarheden in hun software bestaat, maar wel degelijk bestaat en waar ze dan verontwaardigt over gaan zitten doen.
En aangegeven door buitenstaanders, een onderzoeker.
Hier is in dit geval geen sprake van.

Als *nix-fan denk ik dat de Linux-gemeenschap goed heeft gereageerd.

Ze wilden weten hoe the community reageert op een dergelijke attack? Het antwoord hebben ze gekregen.

Dergelijke aanvallen - als proof of concept - worden ook gedaan op de App-Store en andere distributie kanalen. Dit is volledig legitiem als white-hat attacker.

Aan de jongens/meisjes hier, beetje over de lijntjes pissen kan nooit kwaad. Dat houdt de boel scherp. Niet zo duf doen!

Scriptkiddies blacklisted: Opgelost. Schooltje zegt nu sorry.
En evt. copycats bij deze ook gewaarschuwd.

Er is een kwetsbaarheid ontdekt in het software voorbrengingsproces.

En als UMN het kan (de "oplichters" volgens jou, volgens mij goedwillende onderzoekers), kunnen andere, echt kwaadwillenden, echte oplichters, het ook. Er zijn voldoende voorbeelden waarbij na jarenlange voorbereiding bewust software fouten zijn geïntroduceerd. En dan alleen op een incident reageren (gooi de "oplichters" eruit!) is dus geen oplossing. De vraag moet niet zijn "hoe houd ik onderzoekers buiten" maar die moet zijn: hoe gaat de community voorkomen dat echte kwaadwillenden hetzelfde doen, hoe gaan we dit oplossen?

Best wel een interessante vraag, want, zoals eerder hierboven is aangegeven, er is niet één hoofdverantwoordelijke (zoals in een "gewoon bedrijf". Het probleem is daarnaast dat de kernel met al haar toevoegingen ondertussen zo groot is dat je de eindverantwoordelijkheid niet bij één persoon kan neerleggen: er is niemand die de impact van alle wijzigingen kan overzien.

Maar goed, zodra men erkent dat het voortbrengproces een flaw heeft, weet ik zeker dat er ook oplossingen voor komen, dat is het leuke van Open Source community gedreven projecten: er is altijd wel weer iemand in de wereld met een slim idee. Dat is juist de kracht.

Synaptic is een package manager. Als je de broncode van de Linux kernel zelf (www.kernel.org) of de vele packages wilt zien, dan zul je een paar abstractie niveau's dieper in het systeem moeten kijken. Hier vind je meer tekst en uitleg:

https://www.debian.org/doc/manuals/debian-handbook/sect.apt-frontends.en.html


Als je het handboek en howto's van je gekozen favoriete Linux distributie goed bestudeerd dan kan er weinig mis gaan.

50 kleuren Grey hat zullen we het maar noemen.

Maar de recidive deed natuurlijk de deur dicht. Dat begrijp ik dan wel weer.

Synaptic is een grafische schil om een package manager heen, Dit heeft niets te maken met waar het hier over gaat.
Het gaat hier om Linux (de Linux Kernel) en niet de packages die een GNU/Linux distibutie (Distro) maken en met een package manager beheerd worden.

kwetsbaarheden ontdekken is anders dan kwetsbaarheden toevoegen!
Dat je dat niet snapt.

bad commits zegt helemaal niets. De code moet uiteindelijk ge-merged worden en dat doet een maintainer na een review etc. Niemand merged zo maar code blind en al helemaal niet van een onbekende! Dat is juist een sterk punt.

Je bagatelliseert. Dit is niet over een lijntje pissen maar een zoektocht naar aandacht. Van een universiteit verwacht je geen sabotage poginig.

Iedereen in de wereld kan commits doen (en gebeurd dus ook vaak) maar niet deze commits mergen! Elke module heeft een eigenaar. Daarnaast gaan alle kernelwijzigingen door de handen van LInus Torvalds die dan ook regelmatig mensen de huid vol scheldt over hun drovige bijdragen. Veel verwijnt ook in de bitemmer als crap.
Daarnaast is de linuxkernel het meest bestudeerde (door securityspecialisten) stukje software wat er is. Bad code ongezien achterlaten is een hele uitdaging want je zult ook moeten aantonen wat het doet. Het is in die 30 jaar eigenlijk nog nooit naar voren gekomen met een incident. M.a.w. Git is een Zeer goed werkend stukje softwareontwikkeling. Microsoft gebruikt tegenwoordig niet voor niets hetzelfde Git.

Git heeft zich al 16 jaar bewezen als het beste software ontwikkel gereedschap dat er bestaat. https://en.wikipedia.org/wiki/Git en dat zal nog wel een tijdje zo blijven. iedereen kan commits doen maar alleen verantwoordelijke personen kunnen code mergen. Als deze module eigenaar een onbekende bijdrage niet vertrouwt na het bestuderen van de code/review/test wordt het weggegooid en dat gebeurd natuurlijk regelmatig. Daarnaast gaat alles ook nog eens door de handen van Linus voordat hij een nieuwe 5 kernel released. https://www.kernel.org/
Zelfs Microsoft gebruikt het tegenwoordig voor haar eigen kernelontwikkeling. Dan moet het wel goed zijn :)

Een wereldcrisis maakt kennelijk het slechtste in de mens wakker. Er zijn al scammers en spammers,
die online een oplossing aanbieden, die volledig het probleem ransomware uit de wereld zou kunnen helpen.

Ze zijn developer en willen graag aan het werk. Ze hebben het panacee, de gouden oplossing.
Helemaal matjeklap, zulke gasten. Je weet toch al niet meer wat je meemaakt tegenwoordig op forums.
Ik verbaas me inmiddels echt nergens meer over. We leven in de wereld van dystopie in extremis.

Neen, we moeten niet zoals de laatste tijd zo vaak maar G*ds water over G*ds akker laten lopen.
Er wordt al bijna niet meer analoog en digitaal opgetreden, toch?

We leven in de tijd van de afbraak voor men kan starten met het eigen gewenste "build, back, better".
In het kader daarvan zullen we dit heus online nog wel aan den lijve gaan ondervinden.

Let maar op, dat wordt binnenkort niet leuk meer.
Stay secure both online and offline, dat wenst u allen,

#sockpuppet

Lees wat men in het kader van het experiment heeft gedaan:
" "Dit experiment is op veilige wijze uitgevoerd. We hebben geen kwetsbaarheden in de Linux-kernel geïntroduceerd en waren dit ook niet van plan. Alle patches met kwetsbaarheden bleven beperkt tot e-mailuitwisselingen, zonder dat ze aan een Linux-branch zijn toegevoegd." (letterlijk uit het stuk https://www.security.nl/posting/700284/Universiteit+staakt+onderzoek+met+opzettelijk+kwetsbare+Linux-patches

Dat je dat niet gelezen hebt!

hihi

Het klopt dat niemand zelf kan mergen .
Maar inderdaad kun je je afvragen hoe scherp de maintainers zijn en blijven op patches die claimen - en ogen - een heel kleine bug of waarschuwing te fixen.
En zeker als ze afkomstig zijn van een bron die misschien eerder wel echte bugfixes gedaan heeft .

Er zit allerlei 'ruis' in de kernel - dingen waar de compiler over klaagt, of over klaagt bij hogere warning niveaus , stukken code die niet volgens de kernel 'code style' geschreven zijn , noem maar op.
Sommige mensen die willen beginnen met bijdragen sturen daar patches voor in .

En daarin zou je inderdaad subtiele security holes kunnen introduceren . Misschien zelfs verspreid over meerdere patches.
Er ligt best een verantwoordelijkheid bij de maintainers - en niemand is perfect .

Er was ooit een competitie om ogenschijnlijk onschuldige C code met subtiele holes te maken :

https://en.wikipedia.org/wiki/Underhanded_C_Contest

Wel even lezen waar de reactie op slaat hoor! namelijk "onderzoekers die kwetsbaarheden in hun software ontdekken en hun daarover informeren"
Zo moeilijk is het allemaal niet.

Dat probeert men regelmatig. Probleem met het plaatsen van een achterdeur is dat het een oplossing moet zijn voor een probleem. Dat is al 29 jaar niet gelukt. De kernel wordt uitstekend (ook onbetaald) gereviewed door mensen met passie. Dat is echt iets anders dan software betaald bijdragen voor een multinational. Software in userspace is een heel ander verhaal (dat boeit de kernel ontwikkelaars ook niet zo). Daarnaast doet Redhat ook een review van elke kernel code change die zij gebruiken.
Ik zie meer een probleem opdoemen als Linus Torvalds van het toneel is verdwenen. Gelukkig is er tegenwoordig ook nog een non-profit consortium (Linux Foundation)

Merci voor de info.
Nu het wil niet zeggen dat het in 29 jaar niet gelukt is dat het nooit zal lukken of dat ze niet bezig zijn.
Ik twijfel niet aan de ogen van een community en ook niet aan de strikte manier hoe de merger plaatsvind.
Maar zoals ik het nu begrijp zijn ze er toch wel in geslaagd bogus patches erdoor te krijgen?
Of zie ik dit verkeerd?

"Please stop submitting known-invalid patches. Your professor is playing around with the review process in order to achieve a paper in some strange and bizarre way.
This is not ok, it is wasting our time, and we will have to report this, AGAIN, to your university…"
"Our community does not appreciate being experimented on, and being 'tested' by submitting known patches that either do nothing on purpose, or introduce bugs on purpose," wrote Greg Kroah-Hartman, leading Linux kernel maintainer, in a post to a Linux kernel mailing list on Wednesday.
"If you wish to do work like this, I suggest you find a different community to run your experiments on, you are not welcome here."
De buggy patches zijn trouwens verstuurd via email en hebben niet geleid tot een git commit in een Linux branch. maar hij heeft blijkbaar wel wat verwijderd (uit mijn hoofd betrof het ongeveer 200 files)
Nog een aardige reactie:
You, and your group, have publicly admitted to sending known-buggy patches to see how the kernel community would react to them, and published a paper based on that work.
Now you submit a new series of obviously-incorrect patches again, so what am I supposed to think of such a thing? […]
Because of this, I will now have to ban all future contributions from your University and rip out your previous contributions as they were obviously submitted in bad-faith with the intent to cause problems.
*plonk*
https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbmcZzwnX@kroah.com/

Jammer je bewijst zo enkel dat niemand er naar serieus naar kijkt en dat we inmiddels een soort heel kwetsbare monocultuur hebben omdat iedereen gelooft dat het zo hoort. En nee Git is zeker niet het beste gereedschap, het past totaal niet in de aanpak dat code gegenereerd wordt en niet handmatig ingeklopt wordt. Die omslag in ontwikkeling daar zitten we midden in.

[Torvals wordt dik betaald door de grote commerciëlen welke hun producten zo duur verkocht gebundeld doorzetten.

Als dat waar is dan zijn we sinds de Morris worm niets opgeschoten https://en.wikipedia.org/wiki/Morris_worm Kwetsbare software waar iemand met kennis hoe het echt zit de boel plat kan leggen, zelfs per ongeluk.

Kernel code wordt gegenereerd door mensen geen aliens! Feestje gehad?
Torvalds (je kan niet eens zijn naam spellen zo veel weet je er van) werkt voor de Linux Foundation (een non-profit technology consortium) en is niet zo jaloers op welgestelden zoals karma4

Die worm toonde al in 1988 aan hoe je met een buffer overflow de boel kon platleggen. Er is 1 specifiek consumenten OS (veel gebruikt als desktop) dat hier anno 2021 nog steeds vatbaar voor is , getuigen de vele malware incidenten..

Zo lang de invoer voor een codegenerator in een tekstformaat is weer te geven kan die invoer als sourcecode beheerd worden in een SCM, en dan is Git een prima keuze.

Welke codegenerators heb jij in gedachten, in welke vorm worden de specificaties die die gebruiken bewaard en beheerd, en met welke tools wordt versiebeheer daarvan gedaan?

De reactie van de maintainers is de enig goede.

Stel je voor:

Er is een vertrouwens relatie tussen de kernel maintainers en de developpers
Het vertrouwen wordt geschaad En dan krijg je een "sorry om betrapt te worden" bericht.
Er is geen andere keuze om nu alle andere
Dus jij denk dat het een goed idee is om iemand te vetrouwen die jouw probeert te belazeren en pas als hij betrapt wordt zegt dat er geen security vulnerabilities ingevoerd werden?

Je kan die persoon gewoonweg niet meer vertrouwen.

Als iemand in jouw computer inbreekt, betrapt wordt en dan zegt: "Oei, sorry hoor, ik bedoelde het niet slecht, ik heb echt geen bestanden gekopieerd of aangepast".

Denk je dat het dan een goed idee is om dat zomaar te geloven? Of denk je dat de betere reactie is om geld en tijd te stoppen in een analyse van logs en de dataintegriteit te verifiëren met een vorige backup; etc...?

Er is een reden waarom dergelijk zaken veel kosten, ook al is er "niets" gebeurd.
Je kan alleen maar vaststellen dat er daadwerkelijk niets gebeurd is, nadat je dat geverifieerd hebt.

Er is een groot verschil tussen kwetsbaarheden ontdekken en dan melden, en dit gedrag: Dit is kwetsbaarheden proberen uit te buiten voor eigen gewin.

Het gaat hier over actief misbruik met als doel een paper te kunnen publiceren met hun naam erop, niet over een "analyse" en "melding" van kwetsbaarheden.

Van zodra een onderzoeker kwetsbaarheden zelf misbruikt, gaat het niet meer over white hat hacking, maar black hat hacking en de huidige reactie van de Kernel community is terecht.

Vertrouwen is belangrijk in het leven. Iemand kocht misschien een VW en vertrouwde op de verbruiksdata. Als blijkt dat VW actief manipulaties uitvoert in een stukje code, dan weet je niet waar er elders eventueel ook gemanipuleerd werd.

Ik vind dit veel lijken op een actie uit mijn verleden. Daar was ik een mail-server binnengewandeld van HetNet met root:1234. Toen ik daar wat van zei tegen HetNet, werd ik kompleet van hun systemen verwijderd en was ik op zoek naar een andere internet provider.

Ik heb NOOIT meer iets gemeld. Nergens!

Ik hoop dat ze hun zin nu hebben.

Je hebt meerdere types van codegeneratoren.
1/ het genereerd vanuit een metadata structuur iets in een taal zoals cobol java of wat dan ook.
In dit geval is de metadatastructuur een database met de object/artifact relaties het werkelijke bronsysteem
Wat links: https://erwin.com/products/erwin-data-modeler/
https://www.astera.com/type/blog/data-warehouse-automation-a-complete-guide/

De gegenereerde code in een source repository opnemen omdat het kan is vrij onzinnig je kan er weinig mee ander dan een backup/restore.

2. De ML AI omgevingen gaan een stap verder. De training data is de werkelijke broncode. denk een aan 10Gb of veel meer. De algoritmes spuwen er rustig gegenereerde code uit van 100Mb of veel meer. Veel succes met je code beheer en het ethische in de processen brengen als gebruik van git de opgelegde eis is. Dan ligt de focus totaal verkeerd hoe je verantwoord met gegevensverwerking omgaat.

Je verhaal is meer dan offtopic. Ga je eerst eens inlezen wat kernelontwikkeling is. Een Linuxkernel (of windows) is geen datawarehouse.

Ik heb met een codegenerator gewerkt die de specificaties voor de gegenereerde code als commentaar voorin de source opnam. Een SCM levert ook een gedetailleerde audit trail op, faciliteert parallelle projecten die dezelfde broncode raken, het is veel meer dan alleen opslag of backup/restore. Het sluit inderdaad niet goed aan bij data die in een DBMS zijn opgeslagen.

Als je code genereert vanuit een datamodel heb je echt niet alles te pakken wat er in een programma moet gebeuren. Als je software het niveau van geautomatiseerde kaartenbakjes overstijgt moeten er ook nog ouderwets algoritmes geïmplementeerd worden voor dingen die niet in een datamodel te vatten zijn of die niet of niet direct aan een datamodel gerelateerd zijn. Er blijft dus wel degelijk ouderwets programmeerwerk over dat gebaat is bij een goed SCM.

Als ik te maken zou krijgen met een hybride systeem waarin code voor een deel uit een DBMS gegenereerd werd en voor een deel handwerk was, dan zou ik het verdomd belangrijk vinden om de werking van het systeem van wijziging tot wijziging vastgelegd te hebben op een manier die het mogelijk maakt om achteraf te kunnen nagaan hoe het systeem zich gedragen heeft. Je zal maar met een schadeclaim zitten die correspondeert met een versie van de gegenereerde code die je niet meer hebt en die je niet meer met zekerheid kan reproduceren omdat de codegenerator inmiddels een of meer versies verder is en/of het datamodel inmiddels is aangepast. Je moet in dat soort situaties zeker weten welke code op welk moment gebruikt werd. Banken moeten, als ik me goed herinner uit de tijd dat ik als onwikkelaar voor een bank werkte, tot in detail minstens tien jaar terug kunnen in de tijd. Vanuit zulke eisen zou ik bij elke wijziging zowel de gegenereerde broncode als de gegevens van waaruit die gegenereerd is vastgelegd willen hebben in een SCM. Het is absoluut niet onzinnig om dat te doen.

En het artikel waarop we reageren gaat over de Linux-kernel. Je kan echt niet met zoiets als de erwin Data Modeler process scheduling opzetten, een hardware device driver schrijven of een journaling file system implementeren. Je hebt het over specifieke toepassingsgebieden waar een deel van de broncode gegenereerd kan worden, maar daarmee dek je lang niet alles wat. De overgang waarvan je zegt dat die gaande is dekt dus ook echt niet alles.

De trainingdata zijn geen broncode. Het ML-systeem dat die data verwerkt is geprogrammeerd en daar is broncode van, waarvoor een goed SCM net zo belangrijk is als voor andere softwareprojecten.

Die trainingsdata kan binaire data als afbeeldingen en video's bevatten, afhankelijk van de toepassing. Git is niet in staat om daar diffs van aan te maken, in dat opzicht is het tekstgebaseerd, maar het is prima in staat om binaire data op te slaan. Als het nodig is om de ontwikkelgeschiedenis van die trainingsdata te bewaren en als diffs voor specifieke binaire bestandsformaten daar sowieso geen rol in spelen dan kan software als git daar wel degelijk voor ingezet worden.

Ik heb voor de grap een directorystructuur met 20GB aan foto's onder git gebracht, verdeeld over dertien commits, en dat leverde een git-repository van 19GB op (er staan wat comprimeerbare bestanden tussen). Op een bescheiden computertje met een consumentenlaptopschijfje kostte een checkout van de volledige 20GB me zojuist een kleine 10 minuten. Checkouts die niet alles veranderen in de werkdirectory gaan aanzienlijk sneller - checkouts van alle commits in chronologische volgorde kosten bij elkaar ruim 10 minuten op hetzelfde systeem. Als je niet aan de lopende band moet wisselen tussen versies van de dataset kan dat heel werkbaar zijn.

Ik beweer hiermee niet dat git per se het ideale hulpmiddel is voor dit soort datasets, maar schuif het ook niet bij voorbaat aan de kant omdat het primair voor broncode bedoeld is. Het kan je nog steeds een nauwkeurige vastlegging van de ontwikkelingsgeschiedenis van zo'n dataset opleveren, met vastlegging van wie wat heeft gewijzigd op welk moment, en het stelt je net als bij source code in staat aan parallelle ontwikkeling te doen en de resultaten daarvan weer samen te voegen, met behoud van die audit trail van wie wat op welk moment heeft gedaan. Als dat soort vastleggingen ertoe doen voor een toepassing dan hebben dergelijke SCM-tools nog steeds zeer interessante eigenschappen.

Veel herhaling van "als iemand iets probeert kan je ze niet vertrouwen".
Ik begrijp dat men zich bedonderd voelt, dat is niet de vraag.
De vraag moet zijn: Als UMN dit kan, hebben we dan potentieel een flaw in het proces, en zouden anderen het ook kunnen?
Ik vind daarom het gesprek aan gaan met UMN en kijken hoe dit opgelost kan worden een betere reactie (maar wie ben ik).

Maar dan nu de vraag aan jou: hoe had UMN dit volgens jou moeten aanpakken? Niet? En dan wachten tot een statelijke actor dit gebruikt en niet ontdekt wordt?

Lees je eerst eens in. De hele wereld kan code aanleveren. Dat is het mooie van open source. Je zult alleen de maintainer moeten overtuigen voor wat voor probleem het een oplossing is. Een reputatie helpt daar wel bij. Zie linkjes hierboven over de mailuitwisseling. Bij gesloten software wordt alles per definitie afgewezen en is een backdoor ook niet te vinden (zie Solarwinds problemen). Linus Torvalds zou ze verrot gescholden hebben, maar zo ver is het niet gekomen. Proces werkt prima. Al 29 jaar lang maar geen garantie voor de toekomst as usual.

Lees eens een tijdje mee in de kernel mailing list .

Er worden ook best veel heel kleine probleempjes opgelost door 'drive by' bugfix submitters,
Kleine warnings bij het compileren. coding style fixes .

Soms tot irritatie van een maintainer - "je moet zeker punten scoren voor je CV door een kernel patch op je naam te hebben" .

En natuurlijk de onvermijdelijke aanwas van drivers . Ook closed-source drivers - nVidia ...

Hier zien we een revert van UMN

https://lore.kernel.org/lkml/20210422093505.00006f77@Huawei.com/

Deze was wel correct, zo lezen we.

Hier een umn.edu commit :

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd4af432cc71b5fbfe4833510359a6ad3ada250d

Het hoeven echt geen kilobytes aan code te zijn die "out of the blue" aangeboden worden met een vage reden waarom het in de kernel moet.

En bij _al_ die dingen moet een maintainer scherp zijn .

Ja - het gaat goed. Voor zo ver we weten zijn de bugs met security impact echte bugs - vergissingen - geweest .

Maar het zijn geen onfeilbare supermensen , maintainers . En er zijn altijd dingen die beter kunnen of moeten.
Er is /was het kernel janitors project/website : kleine klusjes voor mensen die willen beginnen .

De maintainers doen niet aan closed source drivers. Logisch. Goed dat dat allemaal modulair is opgezet.