Libelektra: Tests erzeugen unbegrenzt viele GPG-Agenten

Vielen Dank, dass Sie das Problem gemeldet haben!

@ petermax2 Ist es möglich, dass die gpg-Befehle während der Tests gpg-Agenten

Hoppla, ich dachte, dass gpg immer eine Verbindung zu demselben Agenten herstellen würde. Ich werde ermitteln.

@ markus2330 Dies ist auch der Grund, warum in

Das Problem ist jedoch nicht auf Docker beschränkt: Debian-Stretch-Minimal hat auch> 250 davon

Einige Knoten sind nicht betroffen, da sie so eingerichtet sind, dass sie einen GPG-Agenten für Jenkins erzeugen, der von den Tests verwendet wird (müssen wahrscheinlich bestätigt werden).

Vielen Dank, dass Sie sich damit befasst haben!

Einige Knoten sind nicht betroffen, da sie so eingerichtet sind, dass sie einen GPG-Agenten für Jenkins erzeugen, der von den Tests verwendet wird (müssen wahrscheinlich bestätigt werden).

Wenn wir keinen Weg finden, die von uns gestarteten Agenten zu töten, können wir einfach verlangen, dass die Umgebung bereits einen GPG-Agenten hat (# 1888).

Möglicherweise muss der GPG-Agent überhaupt nicht starten, und wir können ihn während der Tests unterdrücken. Aber ich muss es mir abends ansehen.

mh normalerweise sollte GPG_AGENT_INFO werden, wenn einer gestartet wird. In der Vergangenheit haben wir Umgebungsvariablen bereinigt, damit die mehrfachen Starts in der Vergangenheit erklärt wurden. Keine Ahnung, warum es gerade noch passiert ...

@ petermax2 die Tests, die gpg-agent erfordern (gefunden durch Umbenennen von gpg-agent in gpg-agent.bak;)):

• testmod_fcrypt
• testmod_crypto_openssl
• testmod_crypto_gcrypt

testmod_crypto_botan sollte genau wie testmod_crypto_gcrypt und testmod_crypto_openssl laufen. Läuft der Botan-Test auf dem Server?

@ petermax2 wahrscheinlich ja. In der Umgebung, in der ich getestet habe, war kein Botan installiert. es läuft aber hier und wahrscheinlich auch laichmittel.

Es ist nicht so einfach. Ich habe versucht, gpg mit dem Argument --no-autostart während der Komponententests aufzurufen, aber gpg startet den Agenten immer noch. --no-use-agent ist lustig. Die Manpage lautet:

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

Wenn wir keinen Weg finden, die von uns gestarteten Agenten zu töten, können wir einfach verlangen, dass die Umgebung bereits einen GPG-Agenten hat (# 1888).

Könnten wir das mal ausprobieren?

Oder einen Cron-Job wie haben

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

oder ähnliches auf den Build Servern / Containern?

Ich würde den Test überprüfen lassen, ob ein Agent verfügbar ist, wenn nicht, ihn starten und seine PID beibehalten. Stoppen Sie bei der Testbereinigung den Agenten. Alles andere ist ein Hack.

Sie haben Recht, die einzige Frage ist, wo Start und Stopp stattfinden sollen. Dies innerhalb unserer Agenten / Docker zu tun scheint einfacher zu sein als in unseren in C geschriebenen Unit-Tests.

Folgendes habe ich bisher gelernt:

Es ist möglich, den automatischen Start von gpg-agent mit der Option --no-autostart zu unterdrücken, wenn dies bei allen gpg -Anrufen konsistent verwendet wird. Ohne gpg-agent gpg2 können jedoch keine Vorgänge ausgeführt werden, für die der private Schlüssel erforderlich ist (dh Entschlüsselung, Signaturen).

Es ist auch möglich, gpg-agent --server aber dann kann gpg2 keine Verbindung zum Agenten herstellen. Die Umgebungsvariable GPG_AGENT_INFO ist veraltet und wird von gpg2 nicht mehr berücksichtigt.

Ich werde versuchen, gpg-agent --daemon teilen und auszuführen. Ich brauche nur eine Möglichkeit, die PID der gestarteten gpg-agent herauszufinden, damit ich SIGTERM wenn die Tests abgeschlossen sind.

Dies innerhalb unserer Agenten / Docker zu tun scheint einfacher zu sein als in unseren in C geschriebenen Unit-Tests.

Viel einfacher, denke ich :-)

Ich denke, Ihre Entscheidung war richtig, einfach die Standardmethode von gpg zu verwenden, um eine Verbindung zu Agenten herzustellen.

Alternativ zum Starten / Stoppen von gpg-agent können wir auch den "use-agent" in .gnupg / gpg.conf deaktivieren

Ich habe kein Problem mit einem Autostart eines Agenten (und habe es sogar ausgeführt). Ich habe ein Problem mit nachfolgenden Tests, die einen neuen starten

Ich denke, Ihre Entscheidung war richtig, einfach die Standardmethode von gpg zu verwenden, um eine Verbindung zu Agenten herzustellen.

In einer Produktionsumgebung ist dies die bessere Option. Auf meinem Computer stellen crypto und fcrypt immer eine Verbindung zum selben Agenten her und die Integration mit meinem Yubikey funktioniert sehr gut.

In unseren Testumgebungen müssen wir eine einzelne Instanz des Agenten betriebsbereit halten, bevor wir mit den Tests beginnen. Ich denke, das Problem ist, dass wir die Umgebung löschen, wie

Ich denke, das Problem ist, dass wir die Umwelt räumen

wir sollten nicht mehr. aber das Problem bleibt bestehen

Wenn gpg-agent versucht, über eine Umgebung zu kommunizieren, kann dies offensichtlich nicht funktionieren. Beim nächsten Testlauf wird die Umgebung niemals durch einen Testlauf zuvor festgelegt.

Am besten gefallen mir zwei Optionen:

1. Wir starten / stoppen einen GPG-Agenten ordnungsgemäß in den Containern und dokumentieren in TESTING.md, dass der GPG-Agent ausgeführt werden muss (siehe # 1888).
2. Wir deaktivieren den Start von gpg-Agenten (deaktivieren Sie den "use-agent" in .gnupg / gpg.conf sollte funktionieren, haben ihn jedoch nicht getestet) und dokumentieren dies in TESTING.md (siehe # 1888).

Ein Setup, bei dem Daemons bei Bedarf gestartet werden, ohne dass global festgestellt werden kann, ob der Daemon bereits gestartet wurde (und env-Variablen nicht global, sondern prozessspezifisch sind), scheint fehlerhaft zu sein. Wir sollten nicht versuchen, dies innerhalb der Tests zu beheben.

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

Der Grund, warum Sie viele Agenten erzeugen, ist das unterschiedliche Home-Verzeichnis mit der Option --homedir, andernfalls wäre ein einziges verwendet worden. Ab GnuPG 2.1 erfolgt die gesamte Kommunikation mit dem Agenten über einen Socket im GnuPG-Homedirectory.

Wir verwenden die Option homedir nicht. Und https://dev.gnupg.org/T3218 beschreibt die Problemumgehung von Stackoverflow als "eine (sehr umständliche) Problemumgehung".

Vielleicht ist das einfache Starten des gpg-Agenten die zukunftssicherste Variante (auf kontrollierte Weise in unserer Umgebung). Scheint, als ob in neueren Versionen der Start von gpg-agent nicht mehr optional ist. (was meine Option 2. oben unsinnig macht)

Wir verwenden die Option homedir nicht.

Ja, ich habe nicht gefunden, woher es kommt, aber es passt zum Problem (siehe op), da alle Agenten mit einem anderen hervorgebracht haben.

Es war ein guter Hinweis, ich habe gelernt, dass der Start von gpg-agent nicht mehr optional ist.

Das macht sehr deutlich, dass wir es starten und stoppen müssen. Und nicht versuchen, den Start zu vermeiden.

Wir verwenden die Option homedir nicht.

Ja, ich habe nicht gefunden, woher es kommt, aber es passt zum Problem (siehe op)

Wir verwenden die Option --home-dir explizit, aber ps -ef schwelgt darin, dass gpg irgendwie irgendwie setzt.

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

$ GNUPGHOME wird von GnuPG verwendet, um auf das Verzeichnis zu verweisen, in dem die Konfigurationsdateien gespeichert sind. Standardmäßig ist $ GNUPGHOME nicht festgelegt und stattdessen wird $ HOME verwendet. Daher finden Sie direkt nach der Installation ein ~ / .gnupg-Verzeichnis.
Um den Standardspeicherort zu ändern, führen Sie entweder gpg auf diese Weise aus: $ gpg --homedir path / to / file oder legen Sie die Umgebungsvariable GNUPGHOME fest.
`` `
@ petermax2 können Sie überprüfen, ob HOME in Ihrer Testsuite verfügbar ist?

auch interessant https://www.gnupg.org/documentation/manuals/gnupg/Ephemeral-home-directories.html :

Erstellen Sie ein temporäres Verzeichnis, erstellen (oder kopieren) Sie eine Konfiguration, die Ihren Anforderungen entspricht, und lassen Sie gpg dieses Verzeichnis entweder mit der Umgebungsvariablen GNUPGHOME oder mit der Option --homedir verwenden. GPGME unterstützt dies auch auf Kontextbasis, indem die Engine-Informationen von Kontexten geändert werden. Führen Sie nun einen beliebigen Vorgang aus, importieren und exportieren Sie nach Bedarf Schlüsselmaterial. Sobald Sie fertig sind, können Sie das Verzeichnis löschen. Alle gestarteten GnuPG-Backend-Dienste erkennen dies und werden heruntergefahren

Testete dies in meinem Container und es bereinigte den Prozess automatisch wie versprochen.

@ petermax2 können Sie überprüfen, ob HOME in Ihrer Testsuite verfügbar ist?

Ja, HOME ist verfügbar:

HOME = /tmp/elektra-test.3vLR4L

OK, also etwas in der Testsuite überschreibt HOME in ein tmp-Verzeichnis (was gut ist). Wenn dies während der Bereinigung noch verfügbar ist, sollte es nur entfernt werden, um den Agenten zu stoppen. Das wäre eine ideale Lösung.

Wenn wir einfach GNUPGHOME nur eine Instanz von gpg-agent . GNUPGHOME wird vor Beginn des Tests nicht überschrieben.

Wenn GNUPGHOME festgelegt ist, wird nach mehreren Testläufen nur ein einziges gpg-agent ausgeführt.

Ich denke, das ist die einfachste Lösung.

Beachten Sie, dass Sie Tests möglicherweise nicht parallel ausführen können, wenn Sie Ihr Home-Verzeichnis freigeben.
Und Sie müssten GNUPGHOME danach immer noch löschen (Sie möchten nicht, dass ein verweilender pgp-Agent Anrufe für den angemeldeten Benutzer beantwortet, oder?).

Und was würde passieren, wenn das Zielsystem auf GNUPGHOME weiterleitet, sodass Sie die vorhandene Umgebung speichern und nach den Tests manuell wiederherstellen müssten.

Ich würde mich freuen, wenn wir einen Schritt zurücktreten und untersuchen könnten, wie diese Tests Benutzercomputer beeinflussen könnten, nicht nur die Testserverumgebung.

Möglicherweise können Sie Tests nicht parallel ausführen.

Ich habe das Skript ausgeführt:

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

ohne Probleme. GPG sollte das Sperren usw. übernehmen.

Sie möchten nicht, dass ein verweilender PGP-Agent Anrufe für den angemeldeten Benutzer beantwortet, oder?

So wurde gpg-agent entworfen: Es läuft für immer, bis die Benutzersitzung endet. Es schreibt seine PID nicht an eine Stelle, es gibt keine Befehle zum Beenden. Es reagiert nur auf SIGTERM .

Ich habe versucht, fork die gpg-agent aus dem Unit-Test mit der Option --server herauszuholen, damit wir danach eine PID von kill . Aber dann öffnet gpg-agent die erforderlichen Sockets nicht bei $GNUPGHOME und die Komponententests öffnen erneut eine andere Instanz des Agenten (die im Modus --daemon ). Es gibt auch keine Möglichkeit, gpg-agent zu bringen, Sockets zu öffnen, wenn Sie sich im --server -Modus befinden (ich habe dies mit dem Quellcode von gpg-agent überprüft).

gpg-agent ist schwer zu kontrollieren und kaum dokumentiert. Ich habe sogar den Quellcode von gpg-agent gelesen. Unser Anwendungsfall wird nicht behandelt. Die einzige Option ist SIGTERM .

Parallelität

Ich habe mehr darüber nachgedacht, dass Sie GPG-Agenten trennen möchten, die sich nicht gegenseitig beeinflussen sollten. Das heißt, Sie möchten nur, dass Agent a den Schlüssel für Test a und Agent b den Schlüssel für Test b hat. Wenn das nicht benötigt wird, ist ein fest codiertes tmp-Haus in Ordnung.

gpg-agent töten

Als ich das Problem zum ersten Mal untersuchte, stieß ich auf eine Website (oben verlinkt), auf der angegeben wurde, dass der erwartete Weg zum Herunterfahren eines temporären GPG-Agenten darin besteht, sein GPG-Ausgangsverzeichnis zu löschen.

Wenn Sie also GNUPGHOME auf /tmp/elektra_tests/gpg und während der Testbereinigung dieses tmp-Verzeichnis löschen, sollte dies in Ordnung sein.

Wenn Sie also GNUPGHOME auf / tmp / elektra_tests / gpg setzen und während der Testbereinigung dieses tmp-Verzeichnis löschen, sollte dies in Ordnung sein.

Es klappt! Ich werde dieses Update in die Testfälle crypto und fcrypt . Danke für den Tipp!

Ich habe einen funktionierenden Prototyp. PR kommt morgen.

Sollte mit # 2056 behoben werden. Bitte öffnen Sie erneut, wenn das Problem weiterhin auftritt.