OpenVPN-profiel in Git: wat je moet verwijderen voor je commit

Profielen dienen twee doelen tegelijk: ze leggen de verbindingsinstellingen vast en ze dragen een werkende set inloggegevens. De bestandsextensie zegt je niets over welke van de twee je in handen hebt. Lees de inhoud voordat je besluit dat het in een repository thuishoort.

De stappen hieronder gaan ervan uit dat een clientsjabloon voor versiebeheer wordt overwogen. Voer ze in volgorde uit en stop voordat je iets commit dat je niet kunt intrekken.

Lees het bestand dat je wilt indexeren

Begin bij de werkelijke bytes, want een profiel dat naar aparte bestanden verwijst ziet er heel anders uit dan een dat ze inbedt. Zoek de PEM-blokmarkeringen en de inline tags met de namen ca, cert, key, tls-auth en tls-crypt, en dezelfde controle toont je beide gevallen. Een versleutelde privésleutel geldt nog steeds als gevoelig materiaal, en een gedeelde tls-auth- of tls-crypt-sleutel is een inloggegeven ook al is het niet de identiteit van een gebruiker. Pas dezelfde beoordeling toe op alles wat samen met het profiel wordt geïndexeerd, inclusief archieven en installatiescripts die naar een inloggegevensbestand verwijzen.

Kijk daarna naar de geïndexeerde set in plaats van de werkboom. git diff --cached laat zien wat de commit werkelijk zal bevatten, en dat is de enige versie die voor deze beslissing telt.

Beslis wat de repository mag verspreiden

Een sjabloon kan de gedeelde, beoordeelde instellingen dragen en benoemde plaatsaanduidingen voor alles wat iemand bij inschrijving ontvangt. Wat het niet kan dragen is een bruikbare identiteit, omdat een repository wordt verspreid naar iedereen die hem kan lezen, automatisering inbegrepen. Een particuliere repository verkleint het publiek zonder de vraag te veranderen of elke lezer voor dat inloggegeven bevoegd is.

Een negeerregel voorkomt toekomstige toevoegingen en doet niets aan wat al is vastgelegd. Die asymmetrie is het waard om je eigen te maken voor de eerste commit en niet na de tiende. Namen en adressen van infrastructuur zijn een aparte afweging: het zijn geen authenticatiegeheimen, maar ze kunnen meer onthullen dan een team van plan is te publiceren. Neem die beslissing uitdrukkelijk in plaats van elke regel in wachtwoord of openbaar in te delen.

Als het materiaal al in de geschiedenis staat

De regel in een nieuwe commit verwijderen laat de oude versie intact voor iedereen die hem ophaalt. Behandel de blootstelling als echt: bepaal het type inloggegeven en zoek vervolgens de instantie die het ongeldig kan maken. Een clientcertificaat wordt ingetrokken en de intrekkingslijst wordt opnieuw gegenereerd; een gedeelde sleutel van het besturingskanaal wordt vervangen op de server en op elke client die hem gebruikt.

De twee hebben heel verschillende werkingsradii, en het plan moet vooraf aangeven welke je uitvoert. Vind de commit die het materiaal heeft binnengebracht met een zoekopdracht van het type git log --all -S 'BEGIN PRIVATE KEY', zodat de omvang van de opruiming bekend is en niet geraden. Een kloon van een collega of een fork kan het oude object al bevatten, daarom komt intrekking eerst en opruiming daarna.

Ruim pas op na indamming

Het herschrijven van de geschiedenis verandert elke commit na degene die je bewerkt, dus eerst is instemming nodig van de eigenaar van de repository en de mensen die erin werken. Een geforceerde push is geen reparatie; het is een coördinatiegebeurtenis met zijn eigen terugdraairisico. Plan hem, maak een back-up en vertel het team wanneer hij plaatsvindt.

Controleer daarna de huidige boom en de resterende geschiedenis in plaats van de samenvatting van het gereedschap te vertrouwen.

Bewaar het resultaat als twee artefacten: het sjabloon dat veilig te delen is, en de inventaris van inloggegevens die tijdens het inschrijvingsproces zijn uitgegeven. Geen van beide vereist dat een bruikbare identiteit in de repository woont.

Die scheiding is de echte oplossing, en zij overleeft de volgende persoon die een profiel wil committen.