Fedora 14 Beitrag 2.)
Signieren von selbstgebauten rpm-Paketen
Ich will meine selbstgebauten rpm-Pakete signieren. Aber weil es sich um Pakete für die aktuelle Fedora-14 Distribution handelt, will ich auch einen Schlüssel verwenden, der genau so stark bzw. schwach ist, wie derjenige, den die Fedora Leute für eben dieses Fedora-14 verwenden. Zwar gibt es im Internet unter der URL http://fedoranews.org/tchung/gpg/ von Thomas Chung eine hervorragende Anleitung zu diesem Thema, doch wenn man sich streng an diese Anleitung hält, erhält man eine Signatur, die eben nicht äquivalent zu Fedora-14 ist, sondern nur zu älteren Fedora Versionen paßt. Ich weiß auch, daß das zwar eigentlich egal ist, hauptsache die Pakete sind überhaupt signiert, aber bei mir geht es immer auch ein bißchen um die Ästhetik.
Also, laßt uns der Ästhetik frönen:
Schritt 1: Wir basteln uns einen eigenen Schlüssel
Ich werde root (sofern ich es noch nicht bin) und begebe mich in das Heimatverzeichnis von root (sofern ich nicht schon da bin).
[seeburge@cs02 ~]$ su Passwort: mein_root_passwort [root@cs02 seeburge]# cd [root@cs02 ~]# pwd /root [root@cs02 ~]#
Sodann schaffe ich mir eine saubere Arbeitsumgebung. Hier ist dringend ein Wort der Warnung angebracht. Ich werde nämlich nun ein ganzes Verzeichnis löschen, das Sie - sofern Sie es nachmachen wollen - eventuell noch dringend brauchen werden. Ich empfehle daher allen anderen lieber ein "mv .gnupg .gnupg.backup" anstatt meinem "rm -rf .gnupg". Wie dem auch sei, Sie müssen selbst wissen was Sie tun.
[root@cs02 ~]# rm -rf .gnupg [root@cs02 ~]# gpg --list-keys gpg: Verzeichnis `/root/.gnupg' erzeugt gpg: Neue Konfigurationsdatei `/root/.gnupg/gpg.conf' erstellt gpg: WARNUNG: Optionen in `/root/.gnupg/gpg.conf' sind während dieses Laufes noch nicht wirksam gpg: Schlüsselbund `/root/.gnupg/pubring.gpg' erstellt gpg: /root/.gnupg/trustdb.gpg: trust-db erzeugt [root@cs02 ~]# cd .gnupg [root@cs02 .gnupg]# ls -al insgesamt 24 drwx------. 2 root root 4096 16. Dez 15:46 . dr-xr-x---. 8 root root 4096 16. Dez 15:46 .. -rw-------. 1 root root 9188 16. Dez 15:46 gpg.conf -rw-------. 1 root root 0 16. Dez 15:46 pubring.gpg -rw-------. 1 root root 40 16. Dez 15:46 trustdb.gpg [root@cs02 .gnupg]# cd [root@cs02 ~]#
Als Ergebnis haben wir eine druckfrische, noch unveränderte Konfigurationsdatei gpg.conf erhalten.
Nun kommt der entscheidende Schritt. Ich nehme nämlich Anpassungen an dieser Konfigurationsdatei vor, die dazu führen, daß wir am Ende der Schlüsselerzeugung einen ähnlichen Schlüssel haben wie die Fedora Leute. Im Einzelnen werde ich die Auskommentierung einer Zeile zurücknehmen und am Ende der Datei zwei Zeilen hinzufügen.
[root@cs02 ~]# vi /root/.gnupg/gpg.conf
So soll es aussehen. Ich zeige hier nur die entscheidenden Stellen der gpg.conf Datei:
. . . # require the older version 3 signatures. Setting this option forces # GnuPG to create version 3 signatures. force-v3-sigs # Because some mailers change lines starting with "From " to ">From " # it is good to handle such lines in a special way when creating . . . # Try CERT, then PKA, then LDAP, then hkp://subkeys.net: #auto-key-locate cert pka ldap hkp://subkeys.pgp.net personal-digest-preferences SHA256 cert-digest-algo SHA256
Nun weiß gpg wie der von mir gewünschte Schlüssel aussehen soll und ich kann mit der eigentlichen Schlüsselerzeugung beginnen:
[root@cs02 ~]# gpg --gen-key gpg (GnuPG) 1.4.11; Copyright (C) 2010 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. gpg: Schlüsselbund `/root/.gnupg/secring.gpg' erstellt Bitte wählen Sie, welche Art von Schlüssel Sie möchten: (1) RSA und RSA (voreingestellt) (2) DSA und Elgamal (3) DSA (nur unterschreiben/beglaubigen) (4) RSA (nur signieren/beglaubigen) Ihre Auswahl? 4 RSA-Schlüssel können zwischen 1024 und 4096 Bit lang sein. Welche Schlüssellänge wünschen Sie? (2048) 4096 Die verlangte Schlüssellänge beträgt 4096 Bit Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll. 0 = Schlüssel verfällt nie <n> = Schlüssel verfällt nach n Tagen <n>w = Schlüssel verfällt nach n Wochen <n>m = Schlüssel verfällt nach n Monaten <n>y = Schlüssel verfällt nach n Jahren Wie lange bleibt der Schlüssel gültig? (0) 0 Schlüssel verfällt nie Ist dies richtig? (j/N) j Sie benötigen eine User-ID, um Ihren Schlüssel eindeutig zu machen; das Programm baut diese User-ID aus Ihrem echten Namen, einem Kommentar und Ihrer Email-Adresse in dieser Form auf: "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>" Ihr Name ("Vorname Nachname"): mein_name Email-Adresse: meine_e-mail_addresse Kommentar: Sie haben diese User-ID gewählt: "mein_name <meine_e-mail_addresse>" Ändern: (N)ame, (K)ommentar, (E)-Mail oder (F)ertig/(B)eenden? F Sie benötigen eine Passphrase, um den geheimen Schlüssel zu schützen. Geben Sie die Passphrase ein: mein_gpg_passwort Geben Sie die Passphrase nochmal ein: mein_gpg_passwort Wir müssen eine ganze Menge Zufallswerte erzeugen. Sie können dies unterstützen, indem Sie z.B. in einem anderen Fenster/Konsole irgendetwas tippen, die Maus verwenden oder irgendwelche anderen Programme benutzen. Es sind nicht genügend Zufallswerte vorhanden. Bitte führen Sie andere Arbeiten durch, damit das Betriebssystem weitere Entropie sammeln kann! gpg: Schlüssel B78E038C ist als uneingeschränkt vertrauenswürdig gekennzeichnet Öffentlichen und geheimen Schlüssel erzeugt und signiert. gpg: "Trust-DB" wird überprüft gpg: 3 marginal-needed, 1 complete-needed, PGP Vertrauensmodell gpg: Tiefe: 0 gültig: 1 unterschrieben: 0 Vertrauen: 0-, 0q, 0n, 0m, 0f, 1u pub 4096R/B78E038C 2010-12-14 Schl.-Fingerabdruck = 9E82 9B7E 5A05 75BF CF12 7D81 317E CB28 B78E 038C uid mein_name <meine_e-mail_addresse> Bitte beachten Sie, daß dieser Schlüssel nicht zum Verschlüsseln benutzt werden kann. Sie können aber mit dem Befehl "--edit-key" einen Unterschlüssel für diesem Zweck erzeugen. [root@cs02 ~]#
Nun muß noch der öffentliche Teil des soeben erzeugten Schlüssels in eine eigene Datei exportieren werden. Diese Datei kann man dann später dritten Personen zur Verfügung stellen, damit diese die Gültigkeit des signierten Paketes prüfen können.
[root@cs02 ~]# gpg --export 'mein_name' > rpm-gpg-key.txt
[root@cs02 ~]#
So, jetzt haben wir einen eigenen Schlüssel erzeugt, mit dem wir fortan unsere selbstgemachten Pakete signieren können. Der gesamte Schlüssel befindet sich in dem Verzeichnis /root/.gnupg, weshalb es ratsam ist dieses Verzeichnis gut zu verwahren und wie seinen Augapfel zu hüten. Der öffentliche Teil unseres Schlüssels ist die Datei rpm-gpg-key.txt. Diese Datei kann auch schonmal verloren gehen, weil sie ja jederzeit wieder neu aus dem Verzeichnis /root/.gnupg generiert werden kann. Nur die Datei rpm-gpg-key.txt darf (und muß, sonst gelingt die Überprüfung nicht) veröffentlicht werden, das Verzeichnis /root/.gnupg auf keinen Fall.
Schritt 2: Vergleichen der Schlüssel
Nun kontrollieren wir ersteinmal ob der Fedora-14 Schlüssel auch so ähnlich aussieht, wie der soeben von uns erzeugte Schlüssel:
[root@cs02 ~]# gpg --quiet --with-fingerprint /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-14-primary pub 4096R/97A1071F 2010-07-23 Fedora (14) <fedora@fedoraproject.org> Schl.-Fingerabdruck = 235C 2936 B4B7 0E61 B373 A020 421C ADDB 97A1 071F [root@cs02 ~]# gpg --quiet --with-fingerprint /root/rpm-gpg-key.txt pub 4096R/B78E038C 2010-12-14 Oliver Seeburger <oliver.seeburger@sundermeier-werkzeugbau.de> Schl.-Fingerabdruck = 9E82 9B7E 5A05 75BF CF12 7D81 317E CB28 B78E 038C [root@cs02 ~]# ls -al /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-14-primary -rw-r--r--. 1 root root 1653 15. Okt 00:35 /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-14-primary [root@cs02 ~]# ls -al /root/rpm-gpg-key.txt -rw-r--r--. 1 root root 1691 14. Dez 15:19 /root/rpm-gpg-key.txt [root@cs02 ~]#
Natürlich unterscheiden sich die beiden Schlüssel in wesentlichen Bereichen. Sie sind unterschiedlich was das Datum, den Namen und insbesondere den Fingerabdruck angeht. Das muß ja auch so sein. Aber sie sind vergleichbar hinsichtlich der Länge (4096 = 4096Bit) und des Verschlüsselungsalgorithmuses (R = RSA). Auch die entstandenen Exportdateien haben eine vergleichbare Dateigröße, wie man am ls-Befehl sehen kann.
Schritt 3: Pakete signieren
Zweierlei müssen wir haben, damit wir unsere Pakete signieren können: Erstens unseren kompletten Schlüssel und zweitens eine Vorschrift die dem rpm-Paketmanager sagt, daß er genau diesen Schlüssel verwenden soll. Nun, das erste haben wir, nämlich das Verzeichnis /root/.gnupg. Das zweite müssen wir erst noch besorgen. Die Vorschrift befindet sich nämlich in der Datei /root/.rpmmacros, die wir zunächst noch um zwei Zeilen erweitern müssen.
[root@cs02 ~]# vi /root/.rpmmacros
So soll es aussehen:
%_topdir %(echo $HOME)/rpmbuild
%_smp_mflags %([ -z "$RPM_BUILD_NCPUS" ] \\\
&& RPM_BUILD_NCPUS="`/usr/bin/getconf _NPROCESSORS_ONLN`"; \\\
if [ "$RPM_BUILD_NCPUS" -gt 16 ]; then echo "-j16"; \\\
elif [ "$RPM_BUILD_NCPUS" -gt 3 ]; then echo "-j$RPM_BUILD_NCPUS"; \\\
else echo "-j3"; fi)
%__arch_install_post /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot
%_signature gpg
%_gpg_name mein_name
Nachdem das erledigt ist, kann der eigentliche Signierbefehl aufgerufen werden. Ab dieser Stelle gehe ich davon aus, daß sich in dem root-Heimatverzeichnis - also /root - zwei rpm-Dateien befinden. Und zwar einmal, zu Vergleichszwecken, ein original Fedora-14 Paket. Ich habe hier beispielsweise das Paket tar-1.23-7.fc14.x86_64.rpm genommen, es geht aber auch jedes andere Paket aus den original Fedora-14 Repositorys. Und zum Zweiten das von mir gepackte noch unsignierte Paket squidclamav-6.1-1.fc14.x86_64.rpm. Genau dieses Paket will ich nun signieren.
[root@cs02 ~]# rpm --addsign squidclamav-6.1-1.fc14.x86_64.rpm mein_gpg_passwort [root@cs02 ~]#
Das ist schon alles. Jetzt ist mein Paket endlich signiert.
Schritt 4: Vergleichen der Pakete
Zunächsteinmal möchte ich sehen, wie der Paketvergleich aussieht, wenn der Fedora-14 Schlüssel und mein eigener Schlüssel nicht an den rpm-Paketmanager bekanntgegeben wurden. Da der Fedora-14 Schlüssel aber höchswahrscheinlich schon in rpm importiert wurde, entlade ich ihn zunächst.
[root@cs02 ~]# rpm -q gpg-pubkey --qf '%{name}-%{version}-%{release} --> %{summary}\n' gpg-pubkey-97a1071f-4c49d6fe --> gpg(Fedora (14) <fedora@fedoraproject.org>) [root@cs02 ~]# rpm -e gpg-pubkey-97a1071f-4c49d6fe [root@cs02 ~]# rpm -q gpg-pubkey --qf '%{name}-%{version}-%{release} --> %{summary}\n' Das Paket gpg-pubkey ist nicht installiert [root@cs02 ~]#
Sobald diese Meldung erscheint, hat rpm alle Signaturen vergessen. Doch keine Angst, wir importieren gleich alle Schlüssel wieder. Nun vergleichen wir ein Muster-Paket aus dem Fedora-14 Repository mit meinem signierten Selbstbaupaket.
[root@cs02 ~]# rpm -K tar-1.23-7.fc14.x86_64.rpm tar-1.23-7.fc14.x86_64.rpm: RSA sha1 (MD5) PGP md5 NICHT OK [root@cs02 ~]# rpm -K squidclamav-6.1-1.fc14.x86_64.rpm squidclamav-6.1-1.fc14.x86_64.rpm: RSA sha1 (MD5) PGP md5 NICHT OK [root@cs02 ~]#
Oder etwas ausführlicher:
[root@cs02 ~]# rpm -vK tar-1.23-7.fc14.x86_64.rpm tar-1.23-7.fc14.x86_64.rpm: Header V3 RSA/SHA256 Signature, Schlüssel-ID 97a1071f: NOKEY SHA1-Kurzfassung des Headers: OK (76227a9418ad0dc47011871730383f41da6542a0) V3 RSA/SHA256 Signature, Schlüssel-ID 97a1071f: NOKEY MD5-Kurzfassung: OK (87622e06c2182a58c51dd6f168c6d977) [root@cs02 ~]# rpm -vK squidclamav-6.1-1.fc14.x86_64.rpm squidclamav-6.1-1.fc14.x86_64.rpm: Header V3 RSA/SHA256 Signature, Schlüssel-ID b78e038c: NOKEY SHA1-Kurzfassung des Headers: OK (bd12a997594fcc0b494ae535ee8179a7647e0d1b) V3 RSA/SHA256 Signature, Schlüssel-ID b78e038c: NOKEY MD5-Kurzfassung: OK (7fb29761172052f0dc8cae00e3035b17) [root@cs02 ~]#
Wer es noch ausführlicher wünscht, der kann statt rpm -vK auch rpm -vvK schreiben. Das Ergebnis bleibt aber das gleiche: Ein hohes Maß an Übereinstimmung. Beidesmal V3-Header und beidesmal RSA/SHA256 Signatur. Ich denke, das sieht sehr ordentlich aus.
Jetzt möchte ich aber wissen, wie das ganze aussieht wenn alle Schlüssel ordentlich importiert wurden. Dazu muß ich nun sowohl den Fedora-14 als auch meinen eigenen Schlüssel importieren.
[root@cs02 ~]# rpm -q gpg-pubkey --qf '%{name}-%{version}-%{release} --> %{summary}\n' Das Paket gpg-pubkey ist nicht installiert [root@cs02 ~]# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-14-primary [root@cs02 ~]# rpm --import /root/rpm-gpg-key.txt [root@cs02 ~]# rpm -q gpg-pubkey --qf '%{name}-%{version}-%{release} --> %{summary}\n' gpg-pubkey-97a1071f-4c49d6fe --> gpg(Fedora (14) <fedora@fedoraproject.org>) gpg-pubkey-b78e038c-4d077ccc --> gpg(Oliver Seeburger <oliver.seeburger@sundermeier-werkzeugbau.de>) [root@cs02 ~]#
Man sieht, alle Signaturen sind wieder da. Nun kann ich erneut die Pakete vergleichen.
[root@cs02 ~]# rpm -K tar-1.23-7.fc14.x86_64.rpm tar-1.23-7.fc14.x86_64.rpm: rsa sha1 (md5) pgp md5 OK [root@cs02 ~]# rpm -K squidclamav-6.1-1.fc14.x86_64.rpm squidclamav-6.1-1.fc14.x86_64.rpm: rsa sha1 (md5) pgp md5 OK [root@cs02 ~]#
Oder etwas ausführlicher:
[root@cs02 ~]# rpm -vK tar-1.23-7.fc14.x86_64.rpm tar-1.23-7.fc14.x86_64.rpm: Header V3 RSA/SHA256 Signature, Schlüssel-ID 97a1071f: OK SHA1-Kurzfassung des Headers: OK (76227a9418ad0dc47011871730383f41da6542a0) V3 RSA/SHA256 Signature, Schlüssel-ID 97a1071f: OK MD5-Kurzfassung: OK (87622e06c2182a58c51dd6f168c6d977) [root@cs02 ~]# rpm -vK squidclamav-6.1-1.fc14.x86_64.rpm squidclamav-6.1-1.fc14.x86_64.rpm: Header V3 RSA/SHA256 Signature, Schlüssel-ID b78e038c: OK SHA1-Kurzfassung des Headers: OK (bd12a997594fcc0b494ae535ee8179a7647e0d1b) V3 RSA/SHA256 Signature, Schlüssel-ID b78e038c: OK MD5-Kurzfassung: OK (7fb29761172052f0dc8cae00e3035b17) [root@cs02 ~]#
Auch hier kann man getrost anstatt -vK -vvK schreiben. So oder so, jetzt bin ich ganz und gar zufrieden. Meine eigene Paketsignatur ist auf gleicher Höhe wie die von Fedora. Genau das wollte ich ja auch erreichen.
