Profil OpenVPN w Git: co usunąć przed commitem

Profile służą dwóm celom naraz: zapisują ustawienia połączenia i przenoszą działający zestaw danych uwierzytelniających. Rozszerzenie pliku nic nie mówi o tym, który z tych dwóch trzymasz w ręku. Przeczytaj zawartość, zanim uznasz, że należy do repozytorium.

Poniższe kroki zakładają, że rozważany jest szablon klienta do kontroli wersji. Wykonaj je po kolei i zatrzymaj się, zanim zatwierdzisz cokolwiek, czego nie możesz unieważnić.

Przeczytaj plik, który zamierzasz dodać do indeksu

Zacznij od rzeczywistych bajtów, bo profil odwołujący się do osobnych plików wygląda zupełnie inaczej niż ten, który je osadza. Szukaj znaczników bloku PEM oraz osadzonych tagów o nazwach ca, cert, key, tls-auth i tls-crypt, a to samo przeszukanie pokaże oba przypadki. Zaszyfrowany klucz prywatny nadal liczy się jako materiał wrażliwy, a współdzielony klucz tls-auth lub tls-crypt jest poświadczeniem, nawet jeśli nie jest tożsamością użytkownika. Zastosuj tę samą kontrolę do wszystkiego, co trafia do indeksu razem z profilem, w tym do archiwów i skryptów instalacyjnych odwołujących się do pliku poświadczeń.

Potem patrz na zestaw w indeksie, a nie na drzewo robocze. git diff --cached pokazuje, co commit będzie naprawdę zawierał, i to jest jedyna wersja istotna dla tej decyzji.

Zdecyduj, co repozytorium może udostępniać

Szablon może przenosić wspólne, przejrzane ustawienia i nazwane symbole zastępcze dla wszystkiego, co osoba otrzymuje przy rejestracji. Nie może natomiast przenosić użytecznej tożsamości, bo repozytorium jest udostępniane wszystkim, którzy mogą je czytać, w tym automatyzacji. Prywatne repozytorium zawęża odbiorców, ale nie zmienia pytania, czy każdy czytelnik jest uprawniony do tego poświadczenia.

Reguła ignorowania zapobiega przyszłym dodatkom i nic nie robi z tym, co już zapisano. Tę asymetrię warto przyswoić przed pierwszym commitem, a nie po dziesiątym. Nazwy i adresy infrastruktury to osobna ocena: nie są tajemnicami uwierzytelniania, ale mogą ujawnić więcej, niż zespół zamierza opublikować. Podejmij tę decyzję wprost, zamiast klasyfikować każdą linię jako hasło albo publiczne.

Jeśli materiał jest już w historii

Usunięcie linii w nowym commicie pozostawia starą wersję nietkniętą dla każdego, kto ją pobierze. Traktuj ekspozycję jako realną: ustal typ poświadczenia, a potem znajdź organ, który może je unieważnić. Certyfikat klienta zostaje unieważniony, a lista unieważnień generowana od nowa; współdzielony klucz kanału sterującego jest wymieniany na serwerze i na każdym kliencie, który go używa.

Oba mają bardzo różny zasięg skutków, a plan powinien przed rozpoczęciem wskazać, który wykonujesz. Znajdź commit, który wprowadził materiał, wyszukiwaniem typu git log --all -S 'BEGIN PRIVATE KEY', żeby zakres sprzątania był znany, a nie zgadywany. Klon kolegi lub fork może już zawierać stary obiekt, dlatego unieważnienie idzie pierwsze, a sprzątanie drugie.

Sprzątaj dopiero po opanowaniu sytuacji

Przepisanie historii zmienia każdy commit po tym, który edytujesz, więc najpierw potrzebna jest zgoda właściciela repozytorium i ludzi w nim pracujących. Wymuszony push nie jest naprawą; to zdarzenie koordynacyjne z własnym ryzykiem wycofania. Zaplanuj je, zrób kopię zapasową i powiedz zespołowi, kiedy się odbędzie.

Potem sprawdź bieżące drzewo i pozostałą historię, zamiast ufać podsumowaniu narzędzia.

Zachowaj wynik jako dwa artefakty: szablon, który jest bezpieczny do udostępnienia, oraz wykaz poświadczeń wydanych w procesie rejestracji. Żaden z nich nie wymaga, by w repozytorium żyła użyteczna tożsamość.

Ten podział jest prawdziwym rozwiązaniem i przetrwa kolejną osobę, która zechce zatwierdzić profil.