web-dev-qa-db-fra.com

debuild - clé secrète non disponible (clé elses)

J'essaie de construire le Caire avec debuild.

J'arrive à la fin et à ce message:

gpg: skipped "Robert Ancell <[email protected]>": secret key not available

Puisque je ne suis pas Robert Ancell, cela a du sens - comment puis-je lui faire utiliser ma propre clé?

gpg --list-key outputs:
$ gpg --list-key /home/stu/.gnupg/pubring.gpg
 ----------------------------
pub   1024R/2ADA7053 2009-05-04 uid                  Launchpad PPA for Aleksander Morgado

pub   2048R/17F35B46 2015-01-28 uid                  Stuart Axon
<[email protected]> uid                  Launchpad PPA for Stuart
Axon <[email protected]> sub   2048R/B8E8ED59 2015-01-28

et j'ai env var:

DEBSIGN_KEYID=17F35B46
aptdpkggnupgdebuild
7
Stuart Axon

debuild demande la clé du dernier utilisateur qui a édité le journal des modifications. Si vous téléchargez sur un PPA, votre paquet doit être différent de son équivalent actuellement dans les référentiels et vous devez donc avoir modifié le journal des modifications.

Utilisez dch pour mettre à jour la version et le journal des modifications, puis reconstruisez-le. debuild vous demandera votre clé. (Si vous n'êtes pas sûr des numéros de version à utiliser, jetez un œil à dans la documentation d'aide du Launchpad. )

8
Seth

J'utilise actuellement XUbuntu 16.04 "Xenial Xerus" et je rencontrais le même problème: debuild et debsign renvoyaient cette clé secrète non disponible , bien que j’ai créé une clé locale et que, d’ailleurs, je l’ai téléchargée sur le buntu Keyserver ,.

J'avais déjà essayé de définir manuellement ma clé en utilisant l'option -k. J'ai également défini ma clé comme clé par défaut et j'ai également édité le fichier debian/changelog, parmi BEAUCOUP d'autres choses, mais rien n'a fonctionné: je recevais toujours la même erreur.

... alors j'ai réalisé que j'avais créé ma clé avec gpg2 au lieu de gpg . Devine ce que j'ai fait?

  • Tout d'abord, j'ai ouvert une fenêtre de terminal Shell et renommé le binaire gpg:

    Sudo mv /usr/bin/gpg /usr/bin/gpg.bak

  • Ensuite, j'ai créé un lien symbolique gpg pointant vers le binaire gpg2:

    Sudo ln -s /usr/bin/gpg2 /usr/bin/gpg

Après cela, des commandes telles que debuild -S -sa, debsign some-file_source.changes et cetera ont finalement fonctionné.

Je ne sais pas ce qui ne va pas avec debuild, debsign, dpkg-buildpackage et cetera, mais j'ai l'impression qu'ils envoient des paramètres à gpg bien que seul gpg2 peut analyser ("comprendre") de tels paramètres. Par conséquent, créer un lien symbolique (afin de créer un faux binaire gpg exécutant le binaire gpg2) résout le problème.

Il existe cependant des manières plus élégantes de forcer debsign à utiliser gpg2:

  • Définissez l'option -pgpg2 de debsign.
  • Définissez DEBSIGN_PROGRAM=gpg2 dans /etc/devscripts.conf ou ~/.devscripts.
6
Yuri Sucupira

Utilisez l’option -k pour indiquer à debuild la touche à utiliser, par exemple.

debuild -kB57F5641

Notez qu'il n'y a pas d'espace alloué entre -k et l'ID de clé.

5
Florian Diesch

Tout d'abord, avec chaque révision de paquet, vous devez éditer le journal des modifications. Ceci est obligatoire si vous apportez des modifications au package. vous pouvez ajouter de tels changelogs avec dch, comme le suggère Seth.

Cependant, si vous essayez simplement de produire un paquet qui n'a pas de modifications supplémentaires, vous pouvez donc simplement installer le paquet, vous n'avez pas besoin de modifier le journal des modifications, vous devez simplement résoudre la signature. problème clé.

Je ne crois pas qu'aucune des réponses ne soit complète à 100%. Par conséquent, je vais voler un peu des deux, mais ajouter ma propre suggestion et solution ici, comme je le fais avec le paquet nginx qui fusionne assez souvent.

Pour citer Seth, debuild déterminera la clé en fonction du dernier éditeur de journal des modifications. Ceci est automatique et vous devrez mettre à jour le journal des modifications pour pouvoir utiliser vos informations d'identification à la fin de la dernière entrée du journal des modifications.

Cependant, comme Florian l’a déclaré, vous pouvez également utiliser l’option -kKEYIDNUM pour debuild lui indiquer la clé à signer et appliquer l’utilisation de cette clé.

Et maintenant, ma solution aux deux problèmes, pour faire signer automatiquement les choses avec la clé, je veux signer avec ...

Pendant très longtemps, je me suis heurté à ce problème chaque fois que mes anciens disques durs sont morts sur mon ancien système. Je ne voulais vraiment pas éditer la changelog à chaque fois, ni vraiment passer manuellement l'option -k à debuild.

Enfin, les MOTU m'ont aidé à résoudre le problème en spécifiant explicitement la clé avec laquelle signer, en me présentant .devscripts, qui debuild et d'autres font appel à des variables d'environnement contenant des éléments définis; cela m'a permis d'ajouter des options que dpkg-buildpackage, qui appelle debuild, sera toujours ajouté.

Donc, pour que l'option -k fonctionne automatiquement pour chaque debuild que vous exécutez, vous pouvez l'ajouter à votre fichier ~/.devscripts et ajouter automatiquement l'option -k, comme ceci :

DEBUILD_DPKG_BUILDPACKAGE_OPTS="-kABCD1234"

Cela le rendra ajouté de manière persistante aux options debuild; C'est également un moyen de faire en sorte que votre clé soit toujours utilisée pour la signature.

Cela m'aide à la fois pour les envois Ubuntu, mais aussi pour les envois PPA.

3
Thomas Ward