W jaki sposób rpm weryfikuje podpisy pakietów?

[Adam Osuchowski]

Tomasz Pala wrote:
> Dla mnie również jest to ważne, ale w realnym świecie dzisiaj rozwiązuje
> się to inaczej. Znam przynajmniej 3 metody, żadna nie tak wygodna, ale
> Jeff wielokrotnie mówił, że repackage w rpm5 też jest skopane, bo nie
> potrafi wycofać zmian zrobionych triggerami, a poza tym nie zgadzają się
> sumy kontrolne w takim repakietowanym archiwum:
> 
> 1. zachowując kopię instalowanych pakietów podczas ich pobierania,

Musiałoby to być robione automatycznie podczas instalacji paczki, żeby
było wygodne. Bo mirrorowanie wszystkich pakietów we wszystkich możliwych
wersjach wyszło mi już kiedyś bokiem. Poza tym, tak jak sam zauważyłeś,
brak tu jest zachowania lokalnych zmian, co dla mnie jest sporą wadą, bo
jak coś modyfikuję, to po to, żeby tak właśnie było, a nie, żeby to było
nadpisane. No i nie tylko pliki z /etc się modyfikuje, czasami trzeba
i co innego, żeby dopasować.

> 2. używając snapshotów na poziomie systemu plików,

Łoo... to jest zdecydowany overkill. Trzeba mieć LVMa albo jakiś btrfs
(tudzież inny fs ze wsparciem do snapshotów), a to w czasach powszechnej
wirtualizacji i zewnętrznego storage'u często jest zbędnym balastem. Poza
tym nie potrzeba mi robić snapshota z całości systemu tylko z pakietu
i wracanie z tym jest praktycznie niewykonalne. To nie tak powinno się
robić, możliwość rollbacku powinna być zaimplementowana możliwie
najbliżej samego mechanizmu zarządzania pakietami.

> 3. używając zewnętrznych narzędzi do wyłuskania plików i złożenia z nich
> nowego rpma.

To jest najsensowniejsze z rozwiązań bo jest najbliższe temu, co robi
teraz repackage tylko za pomocą zewnętrznego narzędzia. W sumie to nawet
jest już takie narzędzie -- rpmrebuild. Nie używałem go od lat więc nie
wiem na ile jeszcze robi to co repackage, ale jeśli robi, to jest to
światełko w tunelu. Jedyne co, to potrzeba, żeby to było uruchamiane
automatycznie przy usuwaniu/podmianie pakietu, bo ręczne grzebanie się
z tym jest, co najmniej, podatne na ludzkie błędy (a to się zapomni
tego zrobić, a to się skasuje zrobioną paczkę, itp.).
Wiesz może na ile mozliwe jest, żeby to zautomatyzować w przypadku rpm4
i na ile sensowne (dające się potem zainstalować i działające) paczki
robi rpmrebuild?

> Wreszcie metoda 4 - skorzystanie z backupu jako podstawy do 2+3.

W przypadku pakietów to jest wyjście ostatniej szansy bo dostajesz
wyłącznie gołe pliki, a nie instalowalny pakiet. Przydaje się to w
przypadku totalnej katastrofy, gdy priorytetem jest ponowne uruchomienie
systemu/usługi/whatever, a nie eleganckie popaczkowanie softu.

> Dla mnie osobiście istotną cechą repackage było zachowanie zmian, jakie
> wprowadziłem lokalnie (np. w plikach konfiguracyjnych albo wprost
> podmieniając jakiekolwiek inne).

True. Absolutnie się z tym zgadzam.

> Chyba, że nie zachowuje się całkiem stabilnie i np. rozsypie się db.
> Albo w jakiś pokraczny sposób "radzi" sobie z --root cośtam.

Od dłuższego czasu mi się to już nie zdarzyło, ale ok, nie będę
polemizował, bo też miewałem tak, że coś tylko u mnie się posypało,
a nikt inny nie miał problemów.

> > i w zasadzie jedyne co, to teraz mnie tylko zaskoczył tym kompletnym
> > brakiem wsparcia do weryfikacji podpisów paczek.
> 
> Czyli mamy niebezpieczne pakiety,

No, to jest coś co mnie przeraziło biorąc pod uwagę, że rpm5 jest od
ładnych paru lat i prawdopodobnie od początku był z tym problem. Pluję
sobie w brodę, bo trzeba było to już dawno sprawdzić, a nie naiwnie
zakładać, że jak zaimportuję rpmowi klucze publiczne, a w poldku ustawię
"signed = yes" to będzie bezpiecznie. Coś ewidentnie z tym trzeba zrobić,
niezależnie od wersji rpma, która będzie w przyszłości w PLD.

> masy własnych pakietów, a mimo to używamy jako podstawy całej
> dystrybucji pakietu rozwijanego przez jedną osobę z jakimś aspergerowym
> syndromem w kontrze do reszty świata - nie widzisz tu problemu o wadze,
> odważę się stwierdzić, egzystencjalnej?

No, to prawda, z tym człowiekiem ciężko się komunikuje...

> Fajnie, że daliśmy mu szansę, ale minęły LATA i zapaść się pogłębia.
> Osobiście nie jestem w stanie budować wszystkich pakietów, jakich
> potrzebuję - posiłkuję się innymi dystrybucjami w nspawnie albo
> dockerem, ale tak również długo się nie da. Wolałbym na żywca próbować
> instalować obce pakiety poldkiem, choćby z jakimś wydzielonym --root.
> Szczególnie, gdy jest to jakiś prosty lib, który mi blokuje możliwość
> zbudowania pakietu (a łańcuszek zerwanych zależności skutecznie
> zniechęca do pracy). Nawet Debian wdrożył systemd - my będziemy się
> bardziej kurczowo niż oni trzymać ślepej drogi ewolucji?

Ok, tylko musi być jakaś alternatywa. Jeżeli jesteśmy w stanie aktualne
ficzery rpma 5 (albo przynajmniej te istotne, jak repackage) ogarnąć w
rpm 4 to ok, ale jeżeli to ma być upadek z deszczu pod rynnę, to nie
opłaca się ta cała zabawa z migracją bo będziemy tak samo w dupie, tylko
może w innym jej zakątku.