OpenVPN-profil i Git: kva som må fjernast før du committar
Les fila for innebygde nøklar, avgjer kva eit depot kan distribuere, og trekk tilbake før du skriv om historia.
Profilar tener to føremål samstundes: dei registrerer tilkoplingsinnstillingane, og dei ber eit fungerande sett med påloggingsdetaljar. Filendninga fortel deg ingenting om kva av dei to du held i handa. Les innhaldet før du avgjer at det høyrer heime i eit depot.
Stega nedanfor føreset at ein klientmal vert vurdert for versjonskontroll. Køyr dei i rekkjefølgje, og stopp før du committar noko du ikkje kan trekkje tilbake.
Les fila du er i ferd med å indeksere
Start med dei faktiske byta, for ein profil som viser til separate filer ser heilt annleis ut enn ein som byggjer dei inn. Søk etter PEM-blokkmerka og dei innebygde taggane som heiter ca, cert, key, tls-auth og tls-crypt, og same gjennomgangen viser deg begge tilfella. Ein kryptert privatnøkkel vert framleis rekna som kjenslevart materiale, og ein delt tls-auth- eller tls-crypt-nøkkel er ein påloggingsdetalj sjølv om han ikkje er identiteten til ein brukar. Bruk same gjennomgangen på alt som vert indeksert saman med profilen, mellom anna arkiv og oppsettskript som viser til ei påloggingsfil.
Sjå deretter på det indekserte settet i staden for arbeidstreet. git diff --cached viser kva commiten faktisk vil innehalde, og det er den einaste versjonen som har noko å seie for denne avgjerda.
Avgjer kva depotet kan distribuere
Ein mal kan bere dei delte, gjennomgåtte innstillingane og namngjevne plasshaldarar for alt ein person får ved registrering. Det han ikkje kan bere, er ein brukande identitet, fordi eit depot vert distribuert til alle som kan lese det, automatisering inkludert. Eit privat depot snevrar inn publikum utan å endre spørsmålet om kvar lesar er autorisert for den påloggingsdetaljen.
Ein ignoreringsregel hindrar framtidige tillegg og gjer ingenting med det som alt er registrert. Den asymmetrien er det verd å gjere seg kjend med før den første commiten og ikkje etter den tiande. Namn og adresser til infrastruktur er ei eiga vurdering: dei er ikkje autentiseringsløyndomar, men dei kan avdekkje meir enn eit team har tenkt å publisere. Ta den avgjerda eksplisitt i staden for å sortere kvar linje i passord eller offentleg.
Viss materialet alt er i historia
Å fjerne linja i ein ny commit lèt den gamle versjonen vere intakt for alle som hentar han. Handsame eksponeringa som reell: identifiser typen påloggingsdetalj, og finn deretter myndigheita som kan gjere han ugyldig. Eit klientsertifikat vert trekt tilbake og tilbaketrekkingslista vert generert på nytt; ein delt nøkkel for kontrollkanalen vert erstatta på tenaren og på kvar klient som brukar han.
Dei to har svært ulikt skadeomfang, og planen bør seie kva for ein du gjennomfører før du byrjar. Finn commiten som førte inn materialet med eit søk av typen git log --all -S 'BEGIN PRIVATE KEY', slik at omfanget av oppryddinga er kjent og ikkje gjeta. Ein kollega sin klon eller ein fork kan alt ha det gamle objektet, og difor kjem tilbaketrekkinga først og oppryddinga etterpå.
Rydd berre etter at det er avgrensa
Omskriving av historia endrar kvar commit etter den du redigerer, så ho treng først semje frå eigaren av depotet og menneska som arbeider i det. Ein tvinga push er ikkje ein reparasjon; det er ei koordineringshending med sin eigen risiko for tilbakerulling. Planlegg han, ta ein tryggingskopi, og fortel teamet når han skjer.
Etterpå bør du stadfeste det gjeldande treet og den attverande historia i staden for å stole på oppsummeringa til verktøyet.
Ta vare på resultatet som to artefaktar: malen som er trygg å dele, og oversynet over påloggingsdetaljar som er gjevne ut gjennom registreringsprosessen. Ingen av dei krev at ein brukande identitet bur i depotet.
Den delinga er den eigentlege løysinga, og ho overlever den neste personen som vil committe ein profil.