Rukověť baliče RPM - VII (Podepisování, verze)

30. 6. 2005 | David Nečas | Návody | 6316×

Podepisování balíčků. Vedlejší balíčky vytvořené z hlavního zdrojového balíku. Verze, epochy a algoritmus řazení verzí.

Podepisování

RPM balíčky lze pro ověření autorství a integrity digitálně podepisovat pomocí PGP či GnuPG. S gpg tedy můžeme podepsat jakýkoli soubor, ale protože je tato funkce důležitá, RPM digitální podpisy přímo podporuje. Měli bychom podepisovat všechny balíčky, které publikujeme, neboť že nejste paranoidní, ještě neznamená, že po vás nejdou.

Konfigurace

Předpokládám, že klíč pro podepisování balíčků už máme. Používáme-li GnuPGP, nakonfigurujeme rpm pro gpg. Do ~/.rpmmacros napíšeme

%_signature gpg
%_gpg_path ~/.gnupg
%_gpg_name David Necas (Yeti) <yeti@trific.ath.cx>
%__gpg /opt/gnupg/bin/gpg

Makro %_signature určuje styl podpisu, možné honoty jsou: gpg pro GnuPG, pgp pro PGP, pgp5 pro staré PGP a implicitní hodnota none pro vypnutí podpisů.

Makro %_gpg_name určuje identitu, kterou budeme balíčky podepisovat. Makro %_gpg_path definuje cestu k souboru klíčů (keyring). A konečně %__gpg cestu k programu gpg, nevyhovuje-li nám implicitní hodnota (typicky /usr/bin/gpg). Používáme-li PGP, nahradíme v názvech maker gpg za pgp.

Podepisování

Hotový balíček podepíšeme volbou --addsign (rpm se zeptá na passphrase):

rpm --addsign lobster-1.10-1.x86_64.rpm lobster-1.10-1.src.rpm
Enter pass phrase:
Pass phrase is good.
/home/yeti/lobster-1.10-1.x86_64.rpm
/home/yeti/lobster-1.10-1.src.rpm

Jak je vidět z příkladu, můžeme pohodlně podepsat několik balíčků jedním příkazem, což řeší jednu z nejotravnějších vlastností GnuPG. Namísto --addsign bychom mohli použít i --resign, jež dělá přesně totéž. Ve starších verzích RPM se lišily, ale dnes obě podepíší balíček, rušíce přitom všechny předešlé podpisy.

Také můžeme použít volbu --sign přímo při kompilaci

rpmbuild -bb --sign lobster.spec

a při úspěšném zabalení se balíček podepíše.

Vedlejší balíčky

Jeden zdrojový balíček může po kompilaci dát vzniknout několika binárním. Kompilací lobster-1.10-1.src.rpm může kupříkladu vzniknout lobster-1.10-1.i686.rpm, lobster-devel-1.10-1.i686.rpm a lobster-perl-1.10-1.i686.rpm. Z toho mimo jiné plyne, že většina z toho, co jsem napsal o struktuře spec souboru, není ve skutečnosti tak jednoduchá…

Doposud jsme se zabývali spec soubory, které popisovaly jen jeden, hlavní balíček (main package). Vedle něj může spec soubor ovšem popisovat libovolný počet dalších, vedlejších balíčků (subpackages), které se kompilují z těchže zdrojových souborů – například z fedořího zdrojového rpm kde-i18n vznikne po kompilaci 68 binárních balíčků. Jak tedy vypadá struktura spec souboru s vedlejšími balíčky?

Sekce %package

Předně se ve spec souboru objevují nové sekce: %package. Ty obsahují hlavičky jednotlivých vedlejších balíčků. Popisné položky jako URL se dědí z hlavního balíčku, pročež hlavičky vedlejších balíčků typicky obsahují jen Summary, Group (ty jsou povinné), Requires, a případně další položky týkající se závislostí.

Sekce %package má jeden argument, a to doplňující jméno vedlejšího balíčku. Připojuje se za jméno hlavního balíčku s pomlčkou. Deklarace vedlejšího balíčku lobster-devel tak může vypadat:

%package devel
Summary: Lobster development libraries and header files.
Group: Development/Libraries
Requires: %{name} = %{version}, libsandals-devel >= 1.2

Někdy bychom ovšem rádi, aby se vedlejší balíček jmenoval úplně jinak než hlavní. To lze zařídit volbou -n, které dáme jako argument plné jméno:

%package -n perl-Fun-Lobster

Ostatní změny

Všechny ostatní sekce (včetně skriptíků) se dělí na společné pro hlavní balíček a všechny vedlejší a na specifické pro každý balíček. V první skupině jich mnoho není, společné jsou pouze kompilační fáze – zdrojový kód se překládá jen jednou a výsledek se rozdělí do balíčků. Konkrétně tedy %prep, %build, %install, %check a %clean. Společný je také záznam změn (%changelog); můžeme sice mít ve spec souboru samostatnou sekci pro každý balíček, ale při kompilaci se všechny sloučí do jednoho záznamu.

Zbylé sekce přijímají stejné argumenty jako %package, tedy dodatečné jméno nebo -n plné_jméno. Popis vedlejšího balíčku perl-Fun-Lobster tak bude vypadat (mimochodem, svůj popis musí mít každý vedlejší balíček):

%description -n perl-Fun-Lobster
Perl interface to lobster.

a spoušť balíčku lobster-perl aktivující se po instalaci perlu:

%triggerin perl -- perl
…

Verze a epocha

V úvodu jsem psal o položkách hlavičky Version a Release, nic ovšem není tak jednoduché, jak to napíši. Úplná verze, podle níž se balíčky porovnávají, má tvar

epocha:verze-vydání

kde verze a vydání jsou obecné řetězce, které jen nesmějí obsahovat pomlčku. Epocha je číslo s implicitní hodnotou nula a používá se, když se změní číslování verzí programu – díky své prioritě dokáže přebít každý autorův výmysl. Vydá-li kupříkladu verzi 1.0 po verzi 2005.3, musíme zvětšit epochu, protože bychom rpm asi nevysvětlili, že 2005 < 1:

Version: 1.0
Epoch: 1

Epocha je však krajní řešení, jehož bychom neměli zneužívat. Jeden problém je, že jakmile jednou epochu zavedeme, už se jí nikdy nezbavíme – balíček bez epochy, tj. s epochou 0, nebude pro rpm nikdy novější než balíček s kladnou epochou. Druhý problém je, že zatímco obyčejné verze jsou porovnatelné i mezi distribucemi, epochy nikdo nekoordinuje. Čísluje-li autor verze systematicky nepoužitelně, raději se je pokusíme převést na méně ztřeštěné.

Dříve se namísto Epoch používala hlavička Serial. Lze ji použít stále – jako synonymum pro Epoch.

O přesném algoritmu porovnávání verzí říká dokumentace RPM, že na jeho detaily nemáme spoléhat a raději číslovat verze rozumně. S tím nelze než souhlasit. Nicméně algoritmus vypadá přibližně tak, že se verze rozdělí na segmenty na nealfanumerických znacích a jednotlivé segmenty se pak porovnají zleva. Kratší verze je starší, tudíž

1.10 < 1.10a
1.10 < 1.10.0

Segmenty se porovnávají numericky, a proto

5.6 < 5.00503

protože 6 < 503. Písmena se porovnávají podle ASCII hodnoty (to je poněkud záludné), pročež

1.10B < 1.10a

       

Komentáře

[Michal Čihař]

můžeme pohodlně podepsat několik balíčků jedním příkazem, což řeší jednu z nejotravnějších vlastností GnuPG

Od čeho je gpg-agent? Nebo máš na mysli jinou otravnou vlastnost, která mi uniká?

[unchallenger]

Když jsem se naposledy díval, byl gpg-agent feature experimentální verze GnuGP.

Navíc často nechci -- na rozdíl do ssh-agenta -- aby běžel furt, chci aby bylo nutno zadat passphrase, ale mohl jsem podepsat několik souborů zároveň. To znamená dát agentovi passphrase, podepsat soubory (gpg se stále musí spustit na každý zvlášť, i když to samozřejmě udělá cyklus v shellu), zrušit agenta. Proč nemůže fungovat gpg -b * bez agentů?

[Michal Čihař]

No je to už dlouho feature stabilní verze, viz NEWS:

Noteworthy changes in version 1.0.5 (2001-04-29)
------------------------------------------------
...
    * New options: --ignore-crc-error, --no-sig-create-check,
      --no-sig-cache, --fixed_list_mode, --no-expensive-trust-checks,
      --enable-special-filenames and --use-agent.  See man page.

Ale nějak hrozně dlouho vyvíjeli toho agenta a ten je zatím jenom ve verzi 1.9.cosi.

Ad poslední dotaz: protože „gpg: --sign does not yet work with --multifile“, předpokládám, že za patch se vývojáři zlobit nebudou

[Michal Marek (twofish)]

5.6 < 5.00503

protože 5 < 503.

Tam má být asi 6 < 503. Ne že by 5 < 503 nebyla pravda, ale smysl mi to nedává

[unchallenger]

Jo, to je typo/thinko.

[Robert Krátký]

Opraveno.