Een reparatie na de discussie

ZCode heeft op 19 september versie 3.14.0 uitgebracht met een reparatie voor abnormale uploads bij de repositorywiki. Dat staat in het officiële wijzigingsoverzicht van de AI-programmeerapp. De korte melding vertelt niet welke bestanden eerder zijn verstuurd, hoeveel gebruikers betrokken waren of hoe gegevens op servers zijn behandeld. Wel maakt ze duidelijk dat de discussie over eerdere versies inmiddels een nieuwe fase heeft bereikt. In dezelfde release is een optie om updates te controleren aan het Help-menu toegevoegd. Controleer dus welke versie je daadwerkelijk gebruikt voordat je conclusies uit oudere meldingen op jouw installatie toepast.

Wat is er werkelijk verstuurd?

Onderzoeker Ferstar beschreef op 18 september dat ZCode projectkopieën met Git-geschiedenis inpakte voor upload. Zijn aanvulling van 19 september maakt een cruciaal onderscheid. De ongeveer 313 MB grote kopie van zijn commerciële project bleef in de wachtrij staan: die upload mislukte. Een afzonderlijke, kleine openbare repository met 538 bestanden werd volgens de vastgelegde status wél door de server geaccepteerd. Het onderzoek betreft bij de oorspronkelijke vondst versie 3.12.3. In 3.14.0 constateert Ferstar dat de uploadcode is verwijderd en lokale herstelpunten overblijven. Of eerder ontvangen kopieën daadwerkelijk op servers zijn gewist, kon hij niet onafhankelijk vaststellen. Nxt heeft deze inspectie niet zelf herhaald. De beschreven waarnemingen rechtvaardigen daarom geen claim dat alle privéprojecten van alle gebruikers zijn uitgelekt.

Versleuteld betekent niet onleesbaar voor de ontvanger

Een afzonderlijke analyse van Silencestar beschrijft hoe onderzochte ZCode-code uit versie 3.10.1 werkbestanden en de map .git apart verzamelde. Daardoor kon Git-inhoud buiten de controles op gevoelige bestandsnamen vallen. Die code-inspectie moet volgens de auteur worden onderscheiden van oudere, lokaal aangetroffen projectkopieën. Bij enkele kleine openbare projecten ondersteunden statusbestanden een voltooide upload; bij het beschreven privéproject niet. De pakketten waren versleuteld, maar de sleutel werd verpakt met een publieke sleutel van de server. Wie de bijbehorende privésleutel bezit, kan volgens dat ontwerp de inhoud ontsluiten. Encryptie tijdens opslag of verzending bewijst dus niet dat de leverancier zelf niets kan lezen. Deze lokale analyse geeft geen uitsluitsel over later bewaren of gebruik voor modeltraining.

Wat ZCode zelf heeft verklaard

In een verklaring die IT Home op 18 september met een screenshot publiceerde, bood ZCode excuses aan. Het bedrijf koppelde de kwestie aan het indexeren van repositories en het genereren van een Repo Wiki in de cloud. Die functie kon volgens de verklaring repositorygegevens uploaden en stond aanvankelijk standaard aan. ZCode stelde dat geüploade gegevens direct na het maken van de wiki worden vernietigd en niet worden bewaard. Dat is een verklaring van de leverancier, geen onafhankelijk gecontroleerd verwijderingsbewijs. Het bedrijf beloofde bovendien de code openbaar te maken en een externe beoordeling te laten uitvoeren. Zo’n toezegging is nog geen gepubliceerd onderzoeksresultaat waarmee gebruikers de afhandeling zelf kunnen controleren.

Waarom geschiedenis meer bevat dan je huidige map

Git bewaart de ontwikkeling van een project in objecten. De officiële Pro Git-uitleg laat zien hoe meerdere versies van dezelfde inhoud naast elkaar in de objectdatabase kunnen blijven bestaan. Andere objecten leggen mapstructuren en opeenvolgende commits vast. Een bestand uit je werkmap verwijderen betekent daardoor niet dat de eerdere inhoud uit het projectgeheugen verdwijnt. Dat is precies waarom je oude wijzigingen kunt terugzoeken en herstellen. Voor een studentenproject of stageopdracht is het verschil praktisch: de bestanden die vandaag zichtbaar zijn, vertellen niet alles over wat eerder is vastgelegd. Een kopie van de Git-opslag kan dus meer bevatten dan een kopie van uitsluitend de huidige bronbestanden. Dat zegt op zichzelf niets over succesvolle verzending.

Een negeerlijst is geen toegangsbeveiliging

Ook .gitignore heeft een beperktere taak dan de naam soms suggereert. Volgens de Git-handleiding beschrijft het bestand welke nog niet gevolgde bestanden Git moet negeren. Bestanden die Git al volgt, worden er niet door geraakt. Wie een configuratiebestand eerst toevoegt en pas later op de negeerlijst zet, heeft daarmee dus niet automatisch de eerdere registratie ongedaan gemaakt. Zo’n lijst is een afspraak voor programma’s die de regels toepassen; ze versleutelt bestanden niet en ontneemt andere software geen leesrechten. Voor beginnende ontwikkelaars is dit een nuttig onderscheid tussen versiebeheer en toegangsbeheer. Controleer wat je vastlegt, maar behandel een regel in .gitignore niet als algemene toestemming of als blokkade voor elke andere toepassing op je computer.

Lokaal opgeslagen is niet noodzakelijk lokaal verwerkt

De huidige documentatie beschrijft Repo Wiki als een uitleg van je codebase, met verwijzingen naar bronbestanden. Het eindresultaat wordt lokaal in de gebruikersmap opgeslagen. Tijdens het maken ervan gaat relevante codecontext echter naar de gekozen modeldienst. De documentatie zegt nu dat een afzonderlijke leesomgeving onder meer .git, bepaalde genegeerde bestanden en vermoedelijk gevoelige configuratiebestanden uitsluit. Dat beschrijft de bedoelde huidige werking van deze wikifunctie; het bewijst niet hoe oudere versies zich gedroegen of hoe alle andere functies bestanden verwerken. Voor Nederlandse en Vlaamse gebruikers die met school- of werkgeverscode werken, is daarom een concrete vraag nuttiger dan alleen “staat de app op mijn laptop?”: welke inhoud mag naar welke modeldienst?

Een gelekte sleutel vraagt om een andere eerste stap

Als uit onderzoek blijkt dat een wachtwoord of toegangssleutel is blootgesteld, adviseert GitHub eerst die toegang in te trekken of de sleutel te vervangen. Alleen een bestand verwijderen maakt een nog geldige sleutel niet onbruikbaar. Daarna kan het nodig zijn de repositorygeschiedenis op te schonen, maar dat vraagt afstemming met medebouwers: hun bestaande kopieën kunnen de oude inhoud opnieuw binnenbrengen. Ook kopieën en forks verdwijnen niet vanzelf wanneer één centrale repository is aangepast. Voor een projectgroep betekent dit dat herstel zowel toegang als bestanden betreft. Spreek af wie de sleutel beheert, welke kopieën moeten worden onderzocht en hoe wijzigingen worden afgestemd. Bewaar voortaan geheimen buiten de broncode en controleer wat je klaarzet voor een commit.

Verder bij de bron

Lees zelf de onderzoeken, uitleg en aankondigingen achter dit verhaal.

Bronnen en werkwijze