Podpisywanie pakietów w Arch Linuksie, cz. 3: pacman

18 styczeń 2012

Wpis jest swobodnym tłumaczeniem Pacman Package Signing – 3: Pacman autorstwa Allana McRae, zajmującego się rozwijaniem pacmana i toolchainem w Arch Linuksie.

Nadszedł czas na ostatni element sagi podpiswania pakietów… Poprzednio opisałem podpisywanie pakietów oraz baz danych i zarządzanie bazą kluczy, niezbędne elementy weryfikowania podpisów w pacmanie.

Większość użytkowników nie zauważy procesu sprawdzania podpisów, dopóki nie pójdzie coś źle (nie licząc konfiguracji). Widoczny będzie stary komunikat checking package integrity podczas którego będą sprawdzane sumy kontrolne oraz weryfikowany podpis, jeżeli będzie taki dostępny. Implementacja tego wymagała znacznych zmian w libalpm, w tym dodaniu weryfikacji podpisów przy użyciu biblioteki gpgme, opcji konfiguracyjnych do kontrolowania weryfikacji repozytoriów i pakietów oraz sprawdzenia jak i kiedy baza repozytorium jest ładowana (dzięki czemu można wcześnie powiadomić użytkownika o wadliwym podpisie repo), a to dopiero początek listy. Większość z niej zostało zrobione przez Dana McGee, głównego programisty pacmana.

$ git shortlog -n -s --no-merges maint.. | head -n3
   296  Dan McGee
   128  Dave Reisner
   124  Allan McRae

(w tym 18 innych autorów z 11 commitami bądź mniej). Dan bez wątpienia jest autorem prawie połowy wszystkich commitów, poczas gdy o drugie miejsce trwała zaciekła rywalizacja.

Jakie są efekty naszej pracy? Moje zdanie jest lekko stronnicze, ale sądzę, że udało nam się stworzyć jedną z najbardziej kompletnych i elastycznych implementacji. Inne menadżery pakietów zwyczajnie wywołują gpgv, który ufa każdemu podpisowi z bazy kluczy. Dzięki bardziej skomplikowanemu rozwiązaniu z użyciem gpgme, pacman ma kompletną realizację sieci zaufania, pozwalającą na bardzo dokładnie zarządzanie kluczami. Nie tylko podpisujemy pakiety - bazy danych repozytoriów również. Co najważniejsze, można dodać czas wygaśnięcia do tych kluczy, dzięki czemu niegroźne są złośliwe mirrory ze starymi wersjami pakietów albo wcale wcale nie dostarczające aktualizacji. Dodatkowo, zabezpieczyliśmy użytkownika przed tzw. endless data attack, w którym atakujący wysyła niekończony strumień danych zamiast żądanego pliku. Wszystkie te rozwiązania pokrywają najczęściej zgłaszane i spotykane ataki na menadżery pakietów. (Wstrzymałem się od powiedzenie "wszystkie" - ktoś natymiast udowodnił by, że jestem w błędzie.)

Wracając do sprawdzania podpisów w pacmanie. Głównym ustawieniem jest dyrektywa SigLevel w pacman.conf, którą można ustawić globalnie i odrębnie dla każdego repozytorium. Przyjmuje trzy wartości:

  • Required, która wymusza sprawdzenie podpisu przed instalacją
  • Optional (domyślnie), która sprawdza podpis, jeżeli jest dostępny i akceptuje niepodpisane pakiety/bazy
  • Never, która wyłącza sprawdzanie podpisów

Bardziej szczegółowe ustawienia można uzyskać dodając prefiksy do powyższych wartości. Na przykład, posiadam repozytorium z podpisaną bazą, lecz nie wszystkie pakiety są podpisane. Używam więc SigLevel = Optional jako ustawienie domyślne oraz SigLevel = DatabaseRequired, aby wymusić weryfikowanie podpisu bazy. Alternatywnie mogę ustawić globalnie SigLevel = DatabaseRequired PackageOptional aby uzyskać dokładnie taki sam efekt. Można również określić wymagany poziom zaufania za pomocą opcji TrustedOnly (domyślnie) oraz TrustAll. Ten pierwszy akceptuje tylko klucze, które mają pełne zaufanie w bazie kluczy. Drugi wymaga tylko obecności klucza w bazie (tak jak gpgv).

Jak pisałem wcześniej, po konfiguracji z perspektywy użytkownika jest widoczna bardzo mała zmiana. Zauważalne jest to, że pacman pobiera podpis bazy danych, gdy SigLevel ma wartość Required i Optional.

# pacman -Syu
:: Synchronizing package databases...
 allanbrokeit           1464.0B  540.5K/s 00:00:00 [######################] 100%
 allanbrokeit.sig        287.0B    7.0M/s 00:00:00 [######################] 100%
...

Poza tym, sprawdzanie podpisu wykonywane jest w trakcie sprawdzania integralności paczki, więc prawdopodobnie zostanie to niezauważone, dopóki nie pójdzie coś źle. Jest to jednocześnie zaleta (w końcu lubimy pacmana ze względu na jego prostotę) i wada (duża część wykonywanych zadań jest niewidoczna dla użytkownika). Jeśli wszystko związane z podpisywaniem pakietów i baz danych działa, pamiętaj, by podziękować najbliższemu deweloperowi pacmana (a jeśli nie działa, to nie była nasza wina…).