Zaskoczył mnie on bardzo, bo wrzucając pracę na GitHuba nawet nie pomyślałem o tym, że przecież w projekcie służącym do stawiania serwisów na Azure jest sekcja konfiguracyjna zawierająca cały ConnectionString! Ot, każdy może się pomylić, nic wielkiego niby się nie stało, nawet gdyby ktoś dostał się na moje Azurowe konto, to jest ono i tak tylko do celów testowych – choć pewnie mógłby narobić problemów, gdyby udało mu się zmienić plan z darmowego na wyższy (choć nie spodziewam się tłumów odwiedzających witrynę GymBoostera i nabijających koszty 🙂 ).
Tak czy inaczej, sprawa wymagała działania. Najprostsza wydawałaby się podmiana pliku z wrażliwymi danymi, ale to nie wystarczy – repozytorium to przecież także historia.
Mail sugerował rozwiązanie opisane przez Scotta Hanselmana na jego blogu, ale przyznam szczerze, że nie mogłem go do końca rozgryźć, więc musiałem szukać czegoś innego.
To coś znalazłem bardzo szybko. Polecenie git filter-branch pozwala na bardzo szerokie modyfikacje repozytorium i jego historii. Na dodatek nie dość, że obszernie opisane w dokumentacji, to jeszcze i przez jednego z moich ulubionych bloggerów, Macieja Aniserowicza (tutaj). Niby wszystko fajnie, ale ja jestem bardzo windowsowy i nauka nowej funkcji gita połączona z wpisywaniem miliona parametrów, gdy „każda chwila jest cenna”, to raczej nie dla mnie. Jeszcze chwila szukania i znalazłem narzędzie o wszystko mówiącej nazwie: BFG Repo-Cleaner.
Dzięki opisowi na stronie projektu, dzięki jednemu poleceniu udało mi się nadpisać wszystkie pojawienia się wrażliwych danych i teraz plik, a raczej jego historia wygląda następująco:
Jak widać, narzędzie nadpisało poufny klucz zdefiniowanym ciągiem znaków w każdym commicie gałęzi master, co idealnie odpowiada moim potrzebom.
BFG potrafi wiele innych rzeczy, ale ogólnie jest to po prostu alternatywa dla git filter-branch i prawdopodobnie gitowi wymiatacze nie muszą sobie nim zawracać głowy – pozostałym lajkonikom polecam, tym bardziej że twórcy chwalą się jego szybkością (podobno od 10 do 720 razy szybszy od zwykłego filter-branch!).
Po dokonaniu zmian miałem jeszcze chwilę zabawy z dostępem do gita (zazwyczaj używam do pracy Smart Gita o kórym pewnie jeszcze opowiem, a tutaj musiałem męczyć się z konsolą), a gdy już się z tym uporałem, zaznaczyłem jeszcze plik, w którym siedzą feralne ConnectionStringi jako assume-unchanged tak, by od teraz git nie śledził zmian w nim dokonywanych – zapobiegnie to przypadkowemu ponownemu umieszczeniu stringów w repozytorium.
No i ostatnia rzecz, o której wspominał Steve w swoim mailu – czyli ponowne wygenerowanie kluczy w Azure. Na obrazku poniżej ścieżka, gdzie tego szukać
I to tyle – uważajcie na stringi, mówię wam… A panu, którego narzędzie wysłało do mnie maila, odpowiedziałem ciepłym mailem z podziękowaniami 🙂
