vermin.eu.org

Na podręcznym komputerze stoi debian we odmianie testing. Debian w wersji testing jest stabilny na tyle, że rozsądnie updatowany w zasadzie się nie wykłada, a ma nowe wersje oprogramowania. Żeby zwiększyć sobie poziom adrenaliny dość często aktualizuję komponenty bez wczytywania się co te zmiany właściwie wnoszą, (ok, wiem, że to tylko lekkie podniesienie ciśnienia - większe byłoby na unstable/experimental, ale ja naprawdę muszę pracować na tej maszynie ).
Ostatnio niestety, po aktualizacji ponowne wczytanie repozytoriów zakończyło się błędem

Przeniosłem się natychmiast na serwer, gdzie zaktualizowałem repozytoria bez problemu. Najpierw pomyślałem, że to wobec tego problem z transferem, jednak w momencie, gdy synaptic na podręcznym komputerze zapytał się mnie, czy jestem pewien, że chcę instalować niezweryfikowane oprogramowanie (WARNING: The following packages cannot be authenticated!), w głowie zaświeciła się lampa ‘you have been hacked!’. Oczywiście natchmiast przerwałem instalację aktualizacji i rozpocząłem poszukiwanie informacji o tym co się właściwie dzieje. (OK - wiem, że mogłem wpisać apt –allow-unauthenticated, ale to nie jest rozwiązanie, prawda?)
Problem jak się okazało leżał po stronie oprogramowania do zarządzania pakietami - apt. Otóż podczas pobierania danych o pakietach, apt/aptitude/synaptic pobierają plik Release, który zawiera sumy MD5 (a w przyszłości SHA1) pozostałych pobieranych plików, oraz plik Packages.gz, zawierający m.in. sumy kontrolne poszczególnych pakietów. System ten ma w swoich założeniach chronić instalacje pakietów przed zainstaowanie oprogramowania o niesprawdzonej sygnaturze. Oczywiście słabym punktem jest plik Release, zawierający sygnatury wyjściowe. W celu polepszenia bezpieczeństwa, dodany został plik Release.gpg, zawierający tzw. ascii-armored deteached gpg signature, czyli sygnaturę kryptograficzną gpg zapisaną znakami ascii. Pliku tego wymaga apt w wersji 0.6x w górę, co także oznacza, dlaczego wersja stable posiadająca starszego apt’a nie wykazywała tego błędu.

Cała sprawa polegała na tym, iż w momencie, gdy mu się nie zgodzi podpis elektroniczny, to zaczynają się wzmiankowane powyżej problemy. Podpisy dla ftp-master’a mają ważność jednego roku, co oznacza, że na początku roku wygasają. Co oznacza, że generowane są nowe podpisy i starym kluczem już nie sprawdzimy wiadomości (o szyfrowaniu kluczem asymetrycznym nie chce mi się tu rozwodzić).

Trzeba zdobyć teraz ten klucz (klucze można wylistować z pomocą polecenia apt-key list). W zasadzie rzecz jest banalna - mając zainstalowany pakiet gpg-rsca (czyli pakiet wirtualny instalujący gpg-pg) uruchamiamy w kontekście użytkownika aktualizującego system (podpowiem, chodzi zazwyczaj o root’a) gpg z następującymi przełącznikami:

Warto zauważyć, że ważne jest ostatnie 8 znaków klucza. Uzyskany w ten sposób klucz exportujemy w zrozumiałej formie z keyringa do apt-key

(możemy też bezpośrednio nakarmić nim apt’a). Jest jednak pewien problem - gpg, żeby pozyskać klucze łączy się z serwerami na porcie rzędu 11137, co oznacza, że niektórzy mogą mieć z tym problem (złapanie tego klucza z serwera WWW też wymaga połączenia na tym porcie). Rozwiązaniem jest ściągnięcie pliku http://ftp-master.debian.org/ziyi_key_2006.asc, gdzie 2006 to rok na który obowiązuje klucz a ziyi to jakaś chińska tancerka (?) i nakarmienie nim apt-key.
Voila! I po problemie.

Edit: w zasadzie, to pojawiła się nowa paczka, której instlacja sama rozwiąże problem - apt-get install debian-archive-keyring. Jak widać rozwiązanie z secure aptem musi się dotrzeć porządnie zanim będzie mogło przejść do testing, szczególnie, że to przełom roku pokaże sprawność działania infrastruktury…

Edit2: Pozdrawiam czytelników Linux news, którzy zawitali na te strony dzięki pewnej notce - zapraszam do komentarzy!

Powyższy tekst powstał na podstawie doświadczeń własnych oraz tekstu SecureApt, który choć ukazał się późno w stosunku do występującego problemu (niestety), to pozwolił mi usystematyzować wiedzę i który gorąco polecam wszystkim chcącym mocniej zgłębić temat.