Pisząc jakiś czas temu poradnik na temat budowania paczek .deb dla dystrybucji linux'a Debian, poruszyłem w nim kwestię związaną z aktualizacją paczki, która zawierała projekt utrzymywany w systemie kontroli wersji (CVS), np. git. Rozchodzi się tutaj o format źródeł. Do niedawna myślałem, że są w zasadzie dwa formaty (tych, z których się zwykle korzysta): 3.0 (native) oraz 3.0 (quilt) . Wszystkie moje pakiety budowane do tej pory miały ten drugi format. Podglądając ostatnio kilka paczek .deb , natrafiłem w jednej z nich na format źródeł 3.0 (git) . Okazuje się, że ten format jest w stanie bardzo łatwo ogarnąć projekty hostowane w takich serwisach jak GitHub, czy GitLab i można za jego sprawą nieco ułatwić sobie życie. Wypadałoby zatem rzucić na niego okiem i ocenić go pod kątem przydatności przy budowaniu pakietów dla Debiana.

Połączenie z internetem, z którego ostatnio przyszło mi korzystać, nie należało zbytnio do tych najbardziej wydajnych pod względem prędkości przesyłu danych. O ile szybkość transferu można by jeszcze przemilczeć, to owe łącze nie należało też do tych najstabilniejszych i czasem kontakt ze światem był zwyczajnie zrywany. Krótko rzecz ujmując, ten net nadawał się chyba jedynie do przeglądania stron WWW. Pech jednak chciał, że potrzebowałem zassać na takim połączeniu repozytorium git'a z patch'ami Debiana nakładanymi na kernel linux'a. To repozytorium nie należy do największych ale też do małych ono się nie zalicza -- waży około 2 GiB. Oczywiście można by zrobić jedynie płytki klon takiego repo za sprawą git clone --depth=1 , co skutkowałoby pobraniem plików w wersji z ostatniego commit'a, co z kolei zredukowałoby w znacznym stopniu wielkość pobieranych danych (parę-paręnaście MiB). Co jednak zrobić w przypadku, gdy musimy sklonować sporych rozmiarów repozytorium git, a dysponujemy przy tym dość wolnym połączeniem sieciowym? Czy jest to w ogóle możliwe, bo przecież git nie ma zaimplementowanej opcji wznawiania przerwanej synchronizacji i każde zakłócenie tego procesu skutkować będzie tym, że całe repozytorium trzeba będzie pobrać jeszcze raz i to bez względu na to, czy proces się zawiesi zaraz na początku, czy też pod koniec operacji.

Github to serwis, w którym użytkownicy mogą pracować wspólnie nad różnymi projektami utrzymywanymi w systemie kontroli wersji GIT. Konto w w/w serwisie może być łakomym kąskiem dla przestępców, zwłaszcza gdy uczestniczymy w dość rozbudowanych projektach i przyczyniamy się do ich tworzenia w dużym stopniu. Z tego powodu github implementuje rozwiązania, które mają na celu poprawić bezpieczeństwo naszej pracy. Mamy już uwierzytelnianie dwuetapowe, obsługę kluczy SSH ale nadal brakowało odpornego systemu, który by uwierzytelnił osoby współdziałające z nami. Chodzi o to, że wszelkie zmiany w repozytorium GIT muszą być przez kogoś poczynione. Każdy commit ma zatem swojego właściciela ale my nigdy nie mamy pewności co do tego, kto tak naprawdę tej zmiany dokonał. Dlatego też github umożliwił ostatnio podpisywanie tagów i commit'ów przy pomocy kluczy GPG. To właśnie temu tematowi będzie poświęcony niniejszy wpis.

Po eksperymentah z repozytorium git na github'ie postanowiłem zrobić drobną ściągawkę na temat obsługi tego mechanizmu z poziomu linii poleceń. Oczywiście, tutaj będą przedstawione jedynie podstawy, tj. jak zacząć tworzyć takie repozytorium. Bardziej zaawansowane rzeczy, np. implementacja kluczy SSH na github'ie, czy też podpisywanie swojej pracy przy pomocy kluczy GPG zostały opisane w osobnych wpisach, bo lekko wykraczają poza tematykę tego artykułu. Oczywiście te dwie rzeczy nie są wymagane do pracy z git'em ale trzeba rozważyć ich wdrożenie jeśli faktycznie zamierzamy zacząć korzystać z tego VCS'a. W każdym razie, tutaj zajmę się podstawowymi operacjami, które człowiek zwykle przeprowadza, gdy przychodzi mu korzystać z git'a. Zdaję sobie sprawę, że są różne nakładki graficzne na narzędzie git ale, jak się okaże po przeczytaniu tego wpisu, operowanie na tekstowym git nie jest takie straszne, choć sama dokumentacja może przerazić, bo jest tego dość sporo i raczej wszystkiego od razu nie ogarniemy.

Debian posiada bardzo rozbudowany system robienia pakietów. Generalnie rzecz biorąc, to wszystkie z nich musiały przejść przez ten proces zanim trafiły do głównego repozytorium dystrybucji. Dzięki takiemu stanu rzeczy, nie musimy ręcznie powielać pracy szeregu innych osób i odpada nam własnoręczna kompilacja pakietów, a wszyscy wiemy, że zajmuje ona cenny czas i zasoby. Paczki .deb są tworzone ze źródeł i instalowane przy pomocy menadżera pakietów aptitude/apt/dpkg . Nic jednak nie stoi na przeszkodzie by daną aplikację skompilować sobie ręcznie i zainstalować ją przy pomocy make install . Problem w tym, że w taki sposób robi się śmietnik w naszym systemie i śledzenie wszystkich zainstalowanych w ten sposób pakietów w pewnym momencie stanie się wręcz niemożliwe. Dlatego też przydałby nam się mechanizm, który ułatwiłby nam nieco to zadanie. Debian udostępnia szereg narzędzi, które są w stanie w pełni zautomatyzować cały ten proces budowy pakietów. Ten poradnik zaś ma na celu zebranie wszystkich istotniejszych informacji związanych z obsługą narzędzi takich jak dh_make , dpkg-buildpackage , pbuilder , quilt czy lintian , tak by tworzyć pakiety w prosty sposób i przy tym równając do najwyższych standardów debiana.

W tym artykule zostanie przedstawiony sposób na wykorzystanie kluczy GPG w przypadku przeprowadzanych działań w repozytorium GIT. Będziemy w ten sposób w stanie podpisać swoje commit'y czy tagi, by było wiadomo, że zmiany, które zostały poczynione pochodzą naprawdę od konkretnego użytkownika. Oczywiście to może się wydać przesadą dla wielu ludzi ale skoro mamy udostępnioną możliwość wykorzystania kluczy GPG, to czemu z tej opcji nie skorzystać? Potrzebne będą nam tylko klucze GPG. Sposób ich tworzenia jak i konfiguracja zdefiniowana w pliku gpg.conf nie zostaną tutaj opisane. Zamiast tego skupimy się jedynie na implementacji samych kluczy GPG.

W końcu przyszedł czas na eksperymenty z serwisem GitHub. Jakby nie patrzeć, do tej pory jedyne co potrafiłem zrobić w przypadku samego gita, to wydać jedno polecenie, którym było git clone . Wszelkie inne rzeczy, choć nie było ich wcale tak dużo, robiłem via panel www, co trochę było upierdliwe. Postanowiłem nauczyć się obsługi gita i nieco uprościć sobie życie. Jeśli chodzi o samą naukę, to tutaj jest dostępny dość obszerny pdf (prawie 500 stron). Nie będę tutaj przerabiał wyżej podlinkowanej książki, bo w sumie jeszcze jej nie przeczytałem, tylko zajmę się ciekawym tematem jakim jest implementacja kluczy SSH, tak by operować na gicie bez zbędnych haseł.