OpenVPN-profil i Git: vad som ska tas bort före commit

Profiler tjänar två syften samtidigt: de registrerar anslutningsinställningarna och de bär ett fungerande paket med inloggningsuppgifter. Filändelsen säger ingenting om vilket av de två du håller i handen. Läs innehållet innan du bestämmer att det hör hemma i ett arkiv.

Stegen nedan förutsätter att en klientmall övervägs för versionshantering. Kör dem i ordning och stanna innan du committar något du inte kan återkalla.

Läs filen du ska lägga i indexet

Börja med de faktiska byten, för en profil som hänvisar till separata filer ser helt annorlunda ut än en som bäddar in dem. Sök efter PEM-blockmarkeringarna och de inbäddade taggarna som heter ca, cert, key, tls-auth och tls-crypt, och samma genomgång visar dig båda fallen. En krypterad privat nyckel räknas fortfarande som känsligt material, och en delad tls-auth- eller tls-crypt-nyckel är en inloggningsuppgift även om den inte är en användares identitet. Tillämpa samma granskning på allt som läggs i indexet tillsammans med profilen, inklusive arkiv och installationsskript som hänvisar till en inloggningsfil.

Titta sedan på det indexerade setet i stället för arbetskatalogen. git diff --cached visar vad commiten faktiskt kommer att innehålla, och det är den enda version som spelar roll för det här beslutet.

Avgör vad arkivet får distribuera

En mall kan bära de delade, granskade inställningarna och namngivna platshållare för allt en person får vid registreringen. Det den inte kan bära är en användbar identitet, eftersom ett arkiv distribueras till alla som kan läsa det, automatisering inräknad. Ett privat arkiv minskar publiken utan att ändra frågan om varje läsare är behörig för den inloggningsuppgiften.

En ignoreringsregel hindrar framtida tillägg och gör ingenting åt det som redan är registrerat. Den asymmetrin är värd att internalisera före den första commiten och inte efter den tionde. Infrastrukturens namn och adresser är en egen bedömning: de är inte autentiseringshemligheter, men de kan avslöja mer än ett team tänker publicera. Fatta det beslutet uttryckligen i stället för att sortera varje rad i lösenord eller offentligt.

Om materialet redan finns i historiken

Att ta bort raden i en ny commit lämnar den gamla versionen orörd för alla som hämtar den. Behandla exponeringen som verklig: identifiera typen av inloggningsuppgift och hitta sedan den instans som kan ogiltigförklara den. Ett klientcertifikat återkallas och återkallningslistan genereras om; en delad nyckel för kontrollkanalen byts ut på servern och på varje klient som använder den.

De två har mycket olika skadeomfång, och planen bör ange vilket du utför innan du börjar. Hitta commiten som införde materialet med en sökning av typen git log --all -S 'BEGIN PRIVATE KEY', så att städningens omfattning är känd och inte gissad. En kollegas klon eller en fork kan redan hålla det gamla objektet, därför kommer återkallelsen först och städningen sedan.

Städa först efter att det har begränsats

Omskrivning av historiken ändrar varje commit efter den du redigerar, så den behöver först samtycke från arkivets ägare och människorna som arbetar i det. En påtvingad push är ingen reparation; det är en samordningshändelse med sin egen risk för återställning. Planera den, ta en säkerhetskopia och berätta för teamet när den sker.

Verifiera därefter det aktuella trädet och den återstående historiken i stället för att lita på verktygets sammanfattning.

Spara resultatet som två artefakter: mallen som är säker att dela och förteckningen över inloggningsuppgifter som utfärdats genom registreringsprocessen. Ingen av dem kräver att en användbar identitet bor i arkivet.

Den uppdelningen är den egentliga lösningen, och den överlever nästa person som vill committa en profil.