OpenVPN-profil i Git: hvad der skal fjernes før du committer

Profiler tjener to formål på én gang: de registrerer forbindelsesindstillinger, og de bærer en fungerende samling af legitimationsoplysninger. Filendelsen fortæller dig intet om, hvilken af de to du holder i hånden. Læs indholdet, før du beslutter, at det hører til i et repository.

Trinnene nedenfor forudsætter, at en klientskabelon overvejes til versionsstyring. Kør dem i rækkefølge, og stop før du committer noget, du ikke kan tilbagekalde.

Læs den fil, du er ved at sætte i indeks

Start med de faktiske bytes, for en profil, der refererer til separate filer, ser helt anderledes ud end en, der indlejrer dem. Søg efter PEM-blokmarkørerne og efter de indlejrede tags med navnene ca, cert, key, tls-auth og tls-crypt, og samme gennemgang viser dig begge tilfælde. En krypteret privat nøgle tæller stadig som følsomt materiale, og en delt tls-auth- eller tls-crypt-nøgle er en legitimationsoplysning, selv om den ikke er en brugers identitet. Anvend samme gennemgang på alt, der sættes i indeks sammen med profilen, herunder arkiver og opsætningsscripts, der refererer til en legitimationsfil.

Se derefter på det indekserede sæt i stedet for arbejdstræet. git diff --cached viser, hvad commiten faktisk vil indeholde, og det er den eneste version, der betyder noget for denne beslutning.

Afgør hvad repositoryet må distribuere

En skabelon kan bære de delte, gennemgåede indstillinger og navngivne pladsholdere for alt, hvad en person modtager ved tilmelding. Det, den ikke kan bære, er en brugbar identitet, fordi et repository distribuerer til alle, der kan læse det, automatisering inkluderet. Et privat repository indsnævrer publikum uden at ændre spørgsmålet om, hvorvidt hver læser er autoriseret til den legitimationsoplysning.

En ignoreringsregel forhindrer fremtidige tilføjelser og gør intet ved det, der allerede er registreret. Den asymmetri er værd at internalisere før den første commit og ikke efter den tiende. Infrastrukturnavne og adresser er en særskilt vurdering: de er ikke autentificeringshemmeligheder, men de kan afsløre mere, end et team har tænkt sig at offentliggøre. Træf den beslutning eksplicit i stedet for at sortere hver linje i adgangskode eller offentlig.

Hvis materialet allerede er i historikken

At fjerne linjen i en ny commit efterlader den gamle version intakt for enhver, der henter den. Behandl eksponeringen som reel: identificér legitimationsoplysningens type, og find derefter den myndighed, der kan ugyldiggøre den. Et klientcertifikat tilbagekaldes, og tilbagekaldelseslisten genereres igen; en delt kontrolkanalnøgle udskiftes på serveren og på hver klient, der bruger den.

De to har meget forskellige skadesradier, og planen bør angive, hvilken du udfører, før du begynder. Find den commit, der indførte materialet, med en søgning af typen git log --all -S 'BEGIN PRIVATE KEY', så oprydningens omfang er kendt og ikke gættet. En kollegas klon eller et fork kan allerede have det gamle objekt, og derfor kommer tilbagekaldelsen først og oprydningen bagefter.

Ryd kun op efter inddæmning

Omskrivning af historikken ændrer hver commit efter den, du redigerer, så den kræver først enighed fra repositoryets ejer og de mennesker, der arbejder i det. Et tvunget push er ikke en reparation; det er en koordinationsbegivenhed med sin egen tilbagerulningsrisiko. Planlæg det, tag en sikkerhedskopi, og fortæl teamet, hvornår det sker.

Bagefter skal du verificere det nuværende træ og den resterende historik i stedet for at stole på værktøjets resumé.

Gem resultatet som to artefakter: skabelonen, der er sikker at dele, og fortegnelsen over legitimationsoplysninger udstedt gennem tilmeldingsprocessen. Ingen af dem kræver, at en brugbar identitet lever i repositoryet.

Den opdeling er den egentlige løsning, og den overlever den næste person, der vil committe en profil.