Na czym się skupić gdy wychodzisz ze swoim kodem na świat.
Krok po kroku
Decyzja o udostępnieniu oprogramowania na zasadach wolnego oprogramowania to ważny krok. Rozważyłeś zalety i wady takiego rozwiązania i uważasz, że skorzysta ono na kwitnącym ekosystemie i społeczności open source. Jedyne, co pozostaje do zrobienia, to umieścić go na platformie publicznej i gotowe, prawda? Może, ale powinniśmy przejść przez kilka kroków, żeby nie wylać dziecka z kąpielą.
Jest kilka podstawowych kwestii, na których należy się skupić przed utworzeniem projektu typu open source:
- Przeskanuj repozytorium w poszukiwaniu danych nie-do-upublicznienia, takich jak np. hasła
- Zastąp nazwy wewnętrzne i adresy e-mail danymi publicznymi
- Napisz wytyczne dotyczące wkładu w projekt (CONTRIBUTING.md)
- Napisz szablon raportu o błędzie
- Wybierz swoją licencję (LICENSE.md) – może TGPPL będzie ok?
- Napisz swoją politykę bezpieczeństwa (SECURITY.md)
- Napisz wprowadzenie do projektu (README.md)
- Jeszcze raz przeskanuj repozytorium w poszukiwaniu danych, które nie powinny zostać upublicznione.
Skupmy się tu na dwóch pierwszych (i ostatniej) kwestiach gdyż są one najważniejsze z punktu widzenia bezpieczeństwa Twojego projektu.
Lepiej za dużo nie pokazać
Jedną z pierwszych rzeczy, które powinieneś zrobić przed upublicznieniem repozytorium, jest sprawdzenie, czy w historii git i w samych plikach projektu nie ma żadnych rzeczy, które nie powinny wyjść na światło dzienne. Pamiętaj, że w przypadku gita publikujesz nie tylko aktualną wersję projektu. Upubliczniasz także każdą zmianę i iterację, która kiedykolwiek została dokonana.
Zresztą zacznijmy od tego, że nie powinno się przechowywać sekretów nawet w repozytoriach wewnętrznych. Idea, że repozytorium wewnętrzne jest prywatne i kryje się za uwierzytelnianiem, może zwieść Cię na manowce i prowadzić do fałszywego poczucia bezpieczeństwa.
GitGuardian
Jeśli korzystasz z wewnętrznego monitorowania GitGuardian, możesz łatwo przeskanować całą historię repozytorium kiedy tylko chcesz. A jeśli Twoje repozytorium znajduje się na platformie niemonitorowanej przez GitGuardian lub chcesz przeskanować lokalną gałąź projektu, to w tym celu możesz posłużyć się GitGuardian Shield. Umożliwia on skanowanie różnych typów danych przy użyciu publicznego interfejsu API GitGuardian.
Po zainstalowaniu GitGuardian Shield wystarczy wydać polecenie skanowania repozytorium, na przykład: ggshield scan repo https://github.com/moj_projekt/nazwa_projektu.git. A jeśli chcesz przeskanować lokalne repozytorium wchodzisz do katalogu repozytorium, wybierasz właściwą gałąź i włączasz skanowanie. Na przykład tak:
cd nazwa_projektu
git checkout main-secrets
ggshield scan repo .
Zastępowanie nazw wewnętrznych i adresów e-mail danymi publicznymi
Chociaż nie jest to kwestia bezpieczeństwa sensu stricte (security by obscurity jest uważane za bezpieczeństwo w szerszym znaczeniu), możesz chcieć zastąpić niektóre informacje w historii repozytorium aby nie zdradzić niektórych współautorów albo nie powiązać konkretnych zmian z konkretnym programistą. Te informacje mogą stanowić na przykład:
- Wewnętrzne adresy e-mail używane podczas programowania, niezgodne z publicznymi adresami e-mail autorów na publicznej platformie hostingowej (GitHub, GitLab).
- Wewnętrzne nazwy produktów, które nie pasują do nazw publicznych.
- Domeny wewnętrzne używane w testach.
