Profil OpenVPN în Git: ce trebuie eliminat înainte de commit

Profilurile servesc două scopuri simultan: înregistrează setările conexiunii și poartă un set funcțional de acreditări. Extensia fișierului nu vă spune nimic despre care dintre ele se află în mână. Citiți conținutul înainte de a decide că aparține unui depozit.

Pașii de mai jos presupun că se ia în considerare un șablon de client pentru controlul versiunilor. Executați-i în ordine și opriți-vă înainte de a face commit la ceva ce nu puteți revoca.

Citiți fișierul pe care urmează să îl indexați

Începeți cu octeții reali, pentru că un profil care trimite la fișiere separate arată complet diferit de unul care le încorporează. Căutați marcajele blocului PEM și etichetele inline numite ca, cert, key, tls-auth și tls-crypt, iar aceeași trecere vă va arăta ambele cazuri. O cheie privată criptată contează în continuare ca material sensibil, iar o cheie tls-auth sau tls-crypt partajată este o acreditare chiar dacă nu este identitatea unui utilizator. Aplicați aceeași verificare la tot ce este indexat împreună cu profilul, inclusiv arhive și scripturi de instalare care trimit la un fișier de acreditări.

Apoi priviți setul indexat, nu arborele de lucru. git diff --cached arată ce va conține de fapt commit-ul, iar aceasta este singura versiune care contează pentru această decizie.

Decideți ce poate depozitul să distribuie

Un șablon poate purta setările partajate și revizuite și substituenți cu nume pentru tot ce primește o persoană la înscriere. Ceea ce nu poate purta este o identitate utilizabilă, pentru că un depozit este distribuit tuturor celor care îl pot citi, inclusiv automatizării. Un depozit privat restrânge publicul fără a schimba întrebarea dacă fiecare cititor este autorizat pentru acea acreditare.

O regulă de ignorare împiedică adăugările viitoare și nu face nimic în privința a ceea ce este deja înregistrat. Merită să interiorizați această asimetrie înainte de primul commit, nu după al zecelea. Numele și adresele de infrastructură sunt o judecată separată: nu sunt secrete de autentificare, dar pot dezvălui mai mult decât intenționează o echipă să publice. Luați această decizie explicit, în loc să încadrați fiecare linie la parolă sau public.

Dacă materialul este deja în istoric

Eliminarea liniei într-un commit nou lasă versiunea veche intactă pentru oricine o descarcă. Tratați expunerea ca reală: identificați tipul acreditării, apoi găsiți autoritatea care o poate invalida. Certificatul de client este revocat și lista de revocare este regenerată; o cheie partajată a canalului de control este înlocuită pe server și pe fiecare client care o folosește.

Cele două au raze de impact foarte diferite, iar planul ar trebui să spună pe care o executați înainte de a începe. Găsiți commit-ul care a introdus materialul cu o căutare de tipul git log --all -S 'BEGIN PRIVATE KEY', astfel încât amploarea curățării să fie cunoscută, nu ghicită. Clona unui coleg sau un fork poate deține deja obiectul vechi, de aceea revocarea vine prima, iar curățarea a doua.

Curățați doar după limitare

Rescrierea istoricului schimbă fiecare commit de după cel pe care îl editați, așa că mai întâi este nevoie de acordul proprietarului depozitului și al oamenilor care lucrează în el. Un push forțat nu este o reparație; este un eveniment de coordonare cu propriul risc de revenire. Programați-l, faceți o copie de siguranță și spuneți echipei când se va întâmpla.

După aceea, verificați arborele curent și istoricul rămas în loc să vă bazați pe rezumatul instrumentului.

Păstrați rezultatul ca două artefacte: șablonul care este sigur de partajat și inventarul acreditărilor emise în timpul procesului de înscriere. Niciunul nu necesită ca o identitate utilizabilă să locuiască în depozit.

Această separare este adevărata soluție și supraviețuiește următoarei persoane care va dori să facă commit la un profil.