OpenVPN-profilo en Git: kion forigi antaŭ ol enmeti

Profiloj servas al du celoj samtempe: ili registras la konektajn agordojn, kaj ili portas funkciantan pakaĵon da akreditiloj. La dosiera etendo diras al vi nenion pri tio, kiun el la du vi tenas. Legu la enhavon antaŭ ol decidi, ke ĝi apartenas al deponejo.

La sekvaj paŝoj supozas, ke klienta ŝablono estas pripensata por versikontrolo. Plenumu ilin laŭvice, kaj haltu antaŭ ol enmeti ion, kion vi ne povas revoki.

Legu la dosieron, kiun vi preparos

Komencu per la efektivaj bajtoj, ĉar profilo, kiu referencas apartajn dosierojn, aspektas tute alie ol tiu, kiu enigas ilin. Serĉu la PEM-blokmarkilojn kaj la enigitajn etikedojn nomatajn ca, cert, key, tls-auth kaj tls-crypt, kaj la sama trairo montros al vi ambaŭ kazojn. Ĉifrita privata ŝlosilo ankoraŭ validas kiel sentema materialo, kaj komuna ŝlosilo tls-auth aŭ tls-crypt estas akreditilo eĉ se ĝi ne estas la identeco de uzanto. Apliku la saman revizion al ĉio, kio estas preparata apud la profilo, inkluzive de arkivoj kaj instalaj skriptoj, kiuj referencas akreditilan dosieron.

Poste rigardu la preparitan aron anstataŭ la laborkopion. git diff --cached montras, kion la enmeto efektive enhavos, kaj tio estas la sola versio, kiu gravas por ĉi tiu decido.

Decidu, kion la deponejo rajtas disdoni

Ŝablono povas porti la komunajn, reviziitajn agordojn kaj nomitajn lokokupilojn por ĉio, kion persono ricevas ĉe aliĝo. Tion, kion ĝi ne povas porti, estas uzebla identeco, ĉar deponejo disdonas al ĉiuj, kiuj povas legi ĝin, inkluzive de aŭtomatigo. Privata deponejo mallarĝigas la publikon sen ŝanĝi la demandon, ĉu ĉiu leganto rajtas por tiu akreditilo.

Ignora regulo malhelpas estontajn aldonojn kaj faras nenion pri tio, kio jam estas registrita. Tiu malekvilibro indas esti internigita antaŭ la unua enmeto, ne post la deka. Nomoj kaj adresoj de infrastrukturo estas aparta juĝo: ili ne estas aŭtentigaj sekretoj, sed ili povas malkaŝi pli ol teamo intencas publikigi. Faru tiun decidon eksplicite anstataŭ ordigi ĉiun linion en pasvorton aŭ publikaĵon.

Se la materialo jam estas en la historio

Forigo de la linio en nova enmeto lasas la malnovan version netuŝita por iu ajn, kiu elŝutas ĝin. Traktu la elmontron kiel realan: identigu la tipon de akreditilo, poste trovu la aŭtoritaton, kiu povas nuligi ĝin. Klienta atestilo estas revokata kaj la revoklisto estas regenerata; komuna ŝlosilo de la rega kanalo estas anstataŭigata sur la servilo kaj sur ĉiu kliento, kiu uzas ĝin.

La du havas tre malsamajn efikradiusojn, kaj la plano devus deklari, kiun vi plenumas antaŭ ol komenci. Trovi la enmeton, kiu enkondukis la materialon, per serĉo de la tipo git log --all -S 'BEGIN PRIVATE KEY', por ke la amplekso de la purigo estu konata, ne divenita. Klono de kolego aŭ forko eble jam tenas la malnovan objekton, tial revoko venas unua kaj purigo dua.

Purigu nur post limigo

Reverkado de la historio ŝanĝas ĉiun enmeton post la redaktata, do ĝi unue bezonas interkonsenton de la posedanto de la deponejo kaj de la homoj, kiuj laboras en ĝi. Trudita puŝo ne estas riparo; ĝi estas kunordiga okazaĵo kun propra risko de retroigo. Planu ĝin, faru sekurkopion, kaj diru al la teamo, kiam ĝi okazos.

Poste kontrolu la nunan arbon kaj la restantan historion anstataŭ fidi la resumon de la ilo.

Konservu la rezulton kiel du artefaktojn: la ŝablonon, kiu estas sekura por kunhavigi, kaj la inventaron de akreditiloj eldonitaj per la aliĝprocezo. Neniu el ili postulas, ke uzebla identeco vivu en la deponejo.

Tiu disigo estas la vera solvo, kaj ĝi postvivos la sekvan personon, kiu volos enmeti profilon.