Libelektra: les tests génèrent un nombre illimité d'agents gpg

Merci d'avoir signalé le problème!

@ petermax2 Est-il possible que les commandes gpg pendant les tests engendrent des gpg-agents?

Oups, je pensais que gpg se connecterait toujours au même agent. Je vais me renseigner.

@ markus2330 c'est aussi la raison pour laquelle il y a tant d'agents gpg sur v2 signalés avec votre userid, car le conteneur docker fonctionne avec 1000: 1000.

mais le problème ne se limite pas à docker: debian-stretch-minimal en a aussi> 250

certains nœuds ne sont pas affectés car ils sont configurés pour générer un gpg-agent pour jenkins qui est utilisé par les tests (probablement, doivent confirmer)

Merci à tous les deux d'avoir examiné cela!

certains nœuds ne sont pas affectés car ils sont configurés pour générer un gpg-agent pour jenkins qui est utilisé par les tests (probablement, doivent confirmer)

Si nous ne pouvons pas trouver un moyen de tuer les agents que nous démarrons, nous pouvons simplement exiger que l'environnement ait déjà un gpg-agent (# 1888).

Peut-être que l'agent gpg n'est pas du tout requis pour démarrer et que nous pouvons le supprimer pendant les tests. Mais je dois y jeter un œil le soir.

mh généralement GPG_AGENT_INFO devrait être défini quand on est démarré, dans le passé, nous avons nettoyé les variables d'environnement afin que cela ait pu expliquer les multiples démarrages dans le passé. Je ne sais pas pourquoi cela se produit encore en ce moment ...

@ petermax2 les tests qui nécessitent gpg-agent (trouvés en renommant gpg-agent en gpg-agent.bak;)):

• testmod_fcrypt
• testmod_crypto_openssl
• testmod_crypto_gcrypt

testmod_crypto_botan doit s'exécuter exactement comme testmod_crypto_gcrypt et testmod_crypto_openssl . Le test Botan est-il en cours d'exécution sur le serveur?

@ petermax2 probablement oui. dans l'environnement où j'ai testé il n'y avait pas de botanique installé. il fonctionne cependant ici et probablement aussi des agents de frai.

Ce n'est pas aussi simple. J'ai essayé d'appeler gpg avec l'argument --no-autostart pendant les tests unitaires, mais gpg démarre toujours l'agent. --no-use-agent est drôle. La page de manuel se lit comme suit:

--no-use-agent 
              This is dummy option. gpg2 always requires the agent.

Si nous ne pouvons pas trouver un moyen de tuer les agents que nous démarrons, nous pouvons simplement exiger que l'environnement ait déjà un gpg-agent (# 1888).

Pouvons-nous tenter le coup?

Ou avoir un travail cron comme

pgrep gpg-agent | xargs -d "\n" kill

ou quelque chose de similaire sur les serveurs / conteneurs de construction?

Je ferais vérifier si un agent est disponible, sinon le démarrer et le conserver. dans le test de nettoyage, arrêtez l'agent. tout le reste est un hack.

Vous avez raison, la seule question est de savoir où le démarrage et l'arrêt doivent avoir lieu. Faire cela au sein de nos agents / dockers semble être plus facile que dans nos tests unitaires écrits en C.

Voici ce que j'ai appris jusqu'à présent:

Il est possible de supprimer le démarrage automatique du gpg-agent avec l'option --no-autostart , si elle est systématiquement utilisée avec tous les appels gpg . Cependant, sans gpg-agent gpg2 ne peut pas effectuer d'opérations, qui nécessitent la clé privée (c'est-à-dire le décryptage, les signatures).

Il est également possible de fork gpg-agent --server mais alors gpg2 ne peut pas se connecter à l'agent. La variable d'environnement GPG_AGENT_INFO est obsolète et n'est plus considérée par gpg2 .

Je vais essayer de fork et d'execv gpg-agent --daemon . J'ai juste besoin d'un moyen de trouver le PID du gpg-agent commencé afin que je puisse SIGTERM lorsque les tests sont effectués.

Faire cela au sein de nos agents / dockers semble être plus facile que dans nos tests unitaires écrits en C.

Beaucoup plus facile, je suppose :-)

Je pense que votre décision était juste d'utiliser simplement la méthode par défaut de gpg pour vous connecter aux agents.

Comme alternative au démarrage / arrêt de gpg-agent, nous pouvons également désactiver le "use-agent" dans .gnupg / gpg.conf

Je n'ai aucun problème avec le démarrage automatique d'un agent (et même le faire fonctionner). J'ai un problème avec les tests suivants en commençant un nouveau

Je pense que votre décision était juste d'utiliser simplement la méthode par défaut de gpg pour vous connecter aux agents.

Dans un environnement de production, c'est la meilleure option. Sur ma machine, crypto et fcrypt connectent toujours au même agent et l'intégration avec mon Yubikey fonctionne très bien.

dans nos environnements de test, nous devons garder une seule instance de l'agent opérationnel avant de démarrer les tests. Je pense que le problème est que nous nettoyons l'environnement, comme

Je pense que le problème est que nous effaçons l'environnement

nous ne devrions plus. mais le problème persiste

Si gpg-agent essaie de communiquer via un environnement, il ne peut évidemment pas fonctionner, le prochain test n'obtiendra jamais l'environnement défini par un test avant.

J'aime mieux suivre deux options:

1. nous démarrons / arrêtons correctement un agent gpg dans les conteneurs et documentons dans TESTING.md que l'agent gpg doit être en cours d'exécution (voir # 1888).
2. nous désactivons le démarrage des agents gpg (désactivez le "use-agent" dans .gnupg / gpg.conf devrait fonctionner, mais ne l'avons pas testé) et documentons ceci dans TESTING.md (voir # 1888).

Une configuration, où les démons démarrent à la demande sans moyen global de savoir si le démon a déjà été démarré (et les variables d'environnement ne sont pas globales mais spécifiques au processus), semble être interrompue. Nous ne devons pas essayer de résoudre ce problème dans les tests.

https://stackoverflow.com/questions/27459869/how-to-stop-gpg-2-1-spawning-many-agents-for-unit-testing

La raison pour laquelle vous créez de nombreux agents est le répertoire de base différent utilisant l'option --homedir, sinon un seul aurait été utilisé. Depuis GnuPG 2.1, toutes les communications avec l'agent sont effectuées via une socket dans le répertoire d'accueil de GnuPG.

Nous n'utilisons pas l'option homedir. Et https://dev.gnupg.org/T3218 décrit la solution de contournement du stackoverflow comme "une solution de contournement (très maladroite)".

Peut-être que le simple démarrage de gpg-agent est la variante la plus évolutive (de manière contrôlée dans notre environnement). On dirait que dans les versions récentes, le démarrage de gpg-agent n'est plus facultatif. (ce qui rend mon option 2. ci-dessus absurde)

Nous n'utilisons pas l'option homedir.

Ouais, je n'ai pas trouvé d'où ça vient mais ça correspond au problème (voir op) car tous les agents sont apparus avec un autre.

C'était un bon indice, j'ai appris que le démarrage de gpg-agent n'est plus optionnel.

Ce qui montre clairement que nous devons le démarrer et l'arrêter. Et n'essayez pas d'éviter le démarrage.

Nous n'utilisons pas l'option homedir.

Ouais je n'ai pas trouvé d'où ça vient mais ça correspond au problème (voir op)

Nous n'utilisons pas explicitement l'option --home-dir , mais ps -ef révèle que gpg définit quand même.

https://wiki.archlinux.org/index.php/GnuPG

$ GNUPGHOME est utilisé par GnuPG pour pointer vers le répertoire où ses fichiers de configuration sont stockés. Par défaut, $ GNUPGHOME n'est pas défini et votre $ HOME est utilisé à la place; ainsi, vous trouverez un répertoire ~ / .gnupg juste après l'installation.
Pour changer l'emplacement par défaut, exécutez gpg de cette façon $ gpg --homedir chemin / vers / fichier ou définissez la variable d'environnement GNUPGHOME.
''
@ petermax2 pouvez-vous vérifier si HOME est disponible dans votre suite de tests?

également intéressant https://www.gnupg.org/documentation/manuals/gnupg/Ephemeral-home-directories.html :

Créez un répertoire temporaire, créez (ou copiez) une configuration qui répond à vos besoins, faites utiliser ce répertoire par gpg soit en utilisant la variable d'environnement GNUPGHOME, soit l'option --homedir. GPGME prend également en charge cela au niveau du contexte, en modifiant les informations du moteur des contextes. Maintenant, exécutez l'opération de votre choix, importez et exportez le matériel clé si nécessaire. Une fois terminé, vous pouvez supprimer le répertoire. Tous les services de backend GnuPG qui ont été démarrés le détectent et s'arrêtent

J'ai testé cela dans mon conteneur et il a nettoyé le processus automatiquement comme promis.

@ petermax2 pouvez-vous vérifier si HOME est disponible dans votre suite de tests?

Oui, HOME est disponible:

HOME = /tmp/elektra-test.3vLR4L

OK donc quelque chose dans la suite de tests écrase HOME dans un répertoire tmp (ce qui est bien). Si cela est toujours disponible pendant le nettoyage, il doit simplement être supprimé pour arrêter l'agent. Ce serait une solution idéale.

Si nous définissons simplement GNUPGHOME une seule instance de gpg-agent est générée. GNUPGHOME n'est pas écrasé avant le début du test.

Avec GNUPGHOME set, un seul gpg-agent est en cours d'exécution après plusieurs tests.

Je pense que c'est la solution la plus simple.

gardez à l'esprit que si vous partagez votre répertoire personnel, vous ne pourrez peut-être pas exécuter de tests en parallèle.
Et vous devrez toujours supprimer GNUPGHOME par la suite (vous ne voulez pas qu'un agent pgp persistant réponde aux appels de l'utilisateur connecté, n'est-ce pas?).

Et que se passerait-il si le système cible relais sur GNUPGHOME, vous auriez donc besoin de sauvegarder l'environnement existant et de le restaurer manuellement après les tests.

J'apprécierais que nous puissions prendre du recul et voir comment ces tests pourraient influencer les machines des utilisateurs, pas seulement l'environnement du serveur de test.

vous ne pourrez peut-être pas exécuter des tests en parallèle.

J'ai exécuté le script:

#!/bin/bash
mkdir /tmp/x
export GNUPGHOME=/tmp/x
for run in {1..1000000}
do
    ctest -R crypto_openssl &
done

sans aucun problème. GPG doit gérer le verrouillage, etc.

vous ne voulez pas qu'un agent pgp réponde aux appels de l'utilisateur connecté, n'est-ce pas?

C'est ainsi que gpg-agent été conçu: il s'exécute pour toujours jusqu'à la fin de la session utilisateur. Il n'écrit pas son PID à un endroit quelconque, il n'y a aucune commande pour le quitter. Il ne réagit qu'à SIGTERM .

J'ai essayé de fork le gpg-agent partir du test unitaire avec l'option --server , donc nous aurions un PID à kill par la suite. Mais alors gpg-agent n'ouvre pas les sockets requises à $GNUPGHOME et les tests unitaires rouvrent une autre instance de l'agent (qui s'exécute en mode --daemon ). De plus, il n'y a aucun moyen de faire gpg-agent ouvrir des sockets en mode --server (j'ai vérifié cela avec le code source de gpg-agent ).

gpg-agent est difficile à contrôler et peu documenté. Je lisais même le code source de gpg-agent . Notre cas d'utilisation n'est pas couvert. La seule option est SIGTERM .

parallélisme

Je pensais plus à ce que vous vouliez séparer les agents gpg qui ne devraient pas s'influencer mutuellement. c'est-à-dire que vous voulez seulement que l'agent a ait la clé du test a et que l'agent b ait la clé du test b. Si cela n'est pas nécessaire, un home tmp codé en dur est correct.

tuer gpg-agent

Lors de la première enquête sur le problème, je suis tombé sur un site Web (lié ci-dessus) qui indiquait que la façon attendue d'arrêter un gpg-agent temporaire est de supprimer son répertoire de base gpg.

Donc, si vous définissez GNUPGHOME sur /tmp/elektra_tests/gpg et pendant le nettoyage du test, supprimez ce répertoire tmp, cela devrait aller.

Donc, si vous définissez GNUPGHOME sur / tmp / elektra_tests / gpg et pendant le nettoyage du test, supprimez ce répertoire tmp, cela devrait aller.

Ça marche! J'intégrerai ce correctif dans les cas de test crypto et fcrypt . Merci pour le tuyau!

J'ai un prototype fonctionnel. PR arrive demain.

Doit être corrigé avec # 2056. Veuillez rouvrir si le problème persiste.