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

[Tomasz Pala]

On Mon, Oct 15, 2018 at 20:28:42 +0200, Adam Osuchowski wrote:

> Dla mnie repackage to jest bardzo fajna i ważna funkcjonalność i
> rozwiązuje mi to często realne problemy w PLD, kiedy po upgradzie
> coś jednak nie działa i trzeba się cofnąć. Jak to ogarnąć w rpm4?
> Da się w ogóle zrobić sensownie rollback nie posiadając oryginalnej
> paczki z poprzednią wersją?

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,
2. używając snapshotów na poziomie systemu plików,
3. używając zewnętrznych narzędzi do wyłuskania plików i złożenia z nich
nowego rpma.

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). Wadą samego rpma było to, że nie
potrafił zrobić weryfikacji sum kontrolnych w repakietowanym archiwum
(tj. "pokaż mi, co tam miałem pozmieniane względem oryginału"). I tak:

ad. 1 - nie masz zachowanych lokalnych zmian (wada/zaleta); ale do plików
konfiguracyjnych używa się np. etckeepera, a pozostałe zmiany są
dostępne w metodzie 2,
ad. 2 - nie da się cofnąć tak o do poprzedniej wersji, bo jednocześnie
cofniemy zmiany w reszcie systemu (co jest abstrakcją choćby po
tygodniu, nawet przy dobrze poseparowanych systemach plików, z osobnym
/home i /var), lecz użyte razem z metodą 1 lub 3 pozwala sobie jakoś
ręcznie poradzić po fakcie,
ad. 3 - pozwala sobie poradzić, gdy nie dysponujemy ani kopią
oryginalnych pakietów, ani nie mamy snapshotujących systemów plików.

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

> Mnie rpm5 już przestał wkurzać i uważam, że jest ok. Owszem, na

Jak to się mówi - problem nie jest to, że jesteśmy w dupie, tylko że
zaczynamy się tam urządzać.

> początku było z nim kiepsko ale teraz zachowuje się w całkiem stabilnie

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.

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

Czyli mamy niebezpieczne pakiety, mamy niebezpieczną zawartość (SUID-y),
jesteśmy niekompatybilni z resztą świata, a potrzebujemy jej z braku
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?

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?

-- 
Tomasz Pala <gotar at pld-linux.org>