Process hängt
Jan Uebernickel
Ich habe ein kleines Problem, und zwar schreibe ich eine GUI (Java
Swing) für gpg (GNU Version zu PGP).
Bei gpg kann man mit gpg --edit-key keyname ein Dialog Programm starten.
Wenn ich das aus Java heraus mit
Process p = Runtime.getRuntime().exec("gpg --edit-key keyname") mache
und danach mit p.getInputStream... ...OutputStream... ...ErrorStream...
umlenke kriege ich trotzdem die stdin Ausgaben des Programms auf die
Konsole (stderr nicht!) und das Java Programm hält an.
Als workarround habe ich versucht das in einem Thread zu starten um das
Hauptprogramm vorm einfrieren zu bewaren, aber dann hält der thread an
und das wars dann, es ist keine Kommunikation mit dem dialogProgramm
möglich.
Irgendjemand eine Idee, warum das Programm so reagiert?
Gruß,
Jan
Tobias Vogele
Jan Uebernickel wrote:
>
> Process p = Runtime.getRuntime().exec("gpg --edit-key keyname") mache
> und danach mit p.getInputStream... ...OutputStream... ...ErrorStream...
> umlenke kriege ich trotzdem die stdin Ausgaben des Programms auf die
> Konsole (stderr nicht!) und das Java Programm hält an.
Wo genau hält das Java-Programm an? Kannst Du ein paar Zeilen code dazu
posten?
Liest Du stderr und stdout von dem GPG-Prozess aus? Wenn nicht, kann es
sein, daß gpg blockiert, weil der Puffer eines dieser Streams voll ist,
und das Java-Programm wartet dann vielleicht auf gpg.
Vielleicht hilft es auch, gpg mit --batch zu starten, allerdings weiß
ich nicht, was dadurch genau anders ist.
Grüße,
tobi
Jan Uebernickel
Tobias Vogele wrote:
> Wo genau hält das Java-Programm an? Kannst Du ein paar Zeilen code dazu
> posten?
> Liest Du stderr und stdout von dem GPG-Prozess aus? Wenn nicht, kann es
> sein, daß gpg blockiert, weil der Puffer eines dieser Streams voll ist,
> und das Java-Programm wartet dann vielleicht auf gpg.
Mache ich eigentlich, aber stdin und stdout wurden nicht umgeleitet, die
Ausgabe landet auf der Konsole und die Eingabe wird auch von dort
entgegengenommen.
>
> Vielleicht hilft es auch, gpg mit --batch zu starten, allerdings weiß
> ich nicht, was dadurch genau anders ist.
hmm... damit habe ihc mich noch nicht beschäftigt, werde es mir aber
gleich mal anschauen
Ansonsten die beiden Threads die in eine großere Klasse eingebunden sind
(die Punkte wo er anhält habe ich markiert):
private class ReadThread extends Thread
{
private String line;
public ReadThread()
{
line = new String();
setPriority(6);
}
public void run()
{
try
{
while(!goon) // wartet auf den anderen Prozess
sleep(100);
System.out.println("\nGooing on..."); // Kontrolle
sleep(1000); // Kontrolle
System.out.println("\nwoke up..."); // Kontrolle
// ========= hiernach kommt gar nichts mehr ==========
}
catch(InterruptedException ex)
{
System.out.println();
}
try
{
do
{
line = dataIn.readLine();
System.out.println("> "+line);
sleep(1000);
}while(line == null);
}
catch(IOException ex)
{
System.out.println(ex);
}
catch(InterruptedException ex)
{
System.out.println();
}
System.out.println("\nReadThread finished...");
}
}
private class GPG_Thread extends Thread
{
private String cmd;
public GPG_Thread()
{
cmd = new String();
setPriority(4);
}
public void run()
{
cmd = path + " --edit-key " + eMail;
try
{
Process p = Runtime.getRuntime().exec(cmd);
dataIn = new BufferedReader(new
InputStreamReader(p.getInputStream()));
dataOut = new BufferedWriter(new
OutputStreamWriter(p.getOutputStream()));
errorIn = new BufferedReader(new
InputStreamReader(p.getErrorStream()));
System.out.println("\nProcess " + cmd + " gestartet!");
goon = true;
// Steht hier wie gewünscht, Input und OutputStream sind aber auf der
Konsole!!
p.waitFor();
System.out.println("\nProcess " + cmd + " beendet!");
}
catch(IOException ex)
{
System.out.println(ex);
}
catch(InterruptedException ex)
{
System.out.println(ex);
}
}
}
Raymund Achner
> Process p = Runtime.getRuntime().exec("gpg --edit-key keyname") mache
> und danach mit p.getInputStream... ...OutputStream... ...ErrorStream...
> umlenke kriege ich trotzdem die stdin Ausgaben des Programms auf die
> Konsole (stderr nicht!) und das Java Programm hält an.
ich tippe ganz stark darauf, daß gpg noch auf irgendeine Eingabe wartet und
sie nicht bekommt. Und solange wartet gpg eben...
ray
Jan Uebernickel
Raymund Achner wrote:
> ich tippe ganz stark darauf, daß gpg noch auf irgendeine Eingabe wartet und
> sie nicht bekommt. Und solange wartet gpg eben...
Ja, wartet er, ist ja ein Dialogprogramm, deshalb hole ich mir ja den
Input und OutputStream um das Programm mit den entsprechenden Eingaben
zu füttern. Siehe dazu meine Antwort an Tobias, dort habe ich den code
gepostet.
Aber wiso gehts auf die Konsole und nicht in die Streams?
Gruß,
Jan
Tobias Vogele
Kann es sein, daß Du stderr nicht ausliest? Zumindest in dem geposteten
Code ist das nicht der Fall.
Andererseits liegt vermutlich das Problem darin, das ja auch stdin von
der Konsole kommt und nicht aus dem Java-Programm. Ich würde mal
vermuten, daß man das mit --batch abschalten kann. Damit wäre das auch
ein gpg-spezifisches Problem (bzw. Feature).
Ich hab mal daheim ein Perl-skript geschrieben, daß GPG fernsteuert,
allerdings ist das eben zuhauese und nicht hier in der Uni. Wenn es heut
abend nocht nicht geklappt hat, kann ich mal schauen, wie ich das da
gemacht hab.
Grüße,
tobi
Jan Uebernickel
> Kann es sein, daß Du stderr nicht ausliest? Zumindest in dem geposteten
> Code ist das nicht der Fall.
Das ist richtig, werde ich auch noch probieren, da müßte die Information
über verwende Version dann drin stehen. Ich habe die Umleitung nur
eingebaut, weil ich irgendwo gelesen habe, das Prozesse machmal nicht
asynchron ausgeführt werden wenn nicht alle drei Kanäle umgeleitet
werden. Gebracht hats aber nichts... Das mit stderr werde ich sehen.
> Andererseits liegt vermutlich das Problem darin, das ja auch stdin von
> der Konsole kommt und nicht aus dem Java-Programm. Ich würde mal
> vermuten, daß man das mit --batch abschalten kann. Damit wäre das auch
> ein gpg-spezifisches Problem (bzw. Feature).
Hmm... kann ein Programm die Umlenkung von stdin und stdout verhindern?
Das sind doch Filedeskriptoren vom Betriebsystem... 0,1,2... In C würde
ich erst fork(), dann die Kanäle umlenken und dann exec machen... Das
die Reihenfolge in Java anders ist verstehe ich sowieso nicht,
vielleicht resultiert daher das Problem? das Programm ist ja schon
gestartet wenn ich die Kanäle umlenke?
>
> Ich hab mal daheim ein Perl-skript geschrieben, daß GPG fernsteuert,
> allerdings ist das eben zuhauese und nicht hier in der Uni. Wenn es heut
> abend nocht nicht geklappt hat, kann ich mal schauen, wie ich das da
> gemacht hab.
Das währe klasse!
Danke,
Jan
Tobias Vogele
Jan Uebernickel wrote:
> Das ist richtig, werde ich auch noch probieren, da müßte die Information
> über verwende Version dann drin stehen. Ich habe die Umleitung nur
> eingebaut, weil ich irgendwo gelesen habe, das Prozesse machmal nicht
> asynchron ausgeführt werden wenn nicht alle drei Kanäle umgeleitet
> werden. Gebracht hats aber nichts... Das mit stderr werde ich sehen.
Naja, umgeleitet wird es wohl schon von der VM. Du holst Dir dadurch nur
noch die Stream-Objekte. Wichtig ist vielmehr, daß Du diese Streams auch
ausliest, denn sonst kann der Puffer vollaufen, und das Programm kann
nichts mehr rausschreiben und blockiert dadurch.
> Hmm... kann ein Programm die Umlenkung von stdin und stdout verhindern?
> Das sind doch Filedeskriptoren vom Betriebsystem... 0,1,2... In C würde
> ich erst fork(), dann die Kanäle umlenken und dann exec machen... Das
> die Reihenfolge in Java anders ist verstehe ich sowieso nicht,
> vielleicht resultiert daher das Problem? das Programm ist ja schon
> gestartet wenn ich die Kanäle umlenke?
Wie gesagt, ich vermute eher, daß diese Umlenkung schon vor dem Starten
oder dabei von der VM erledigt wird.
Wie GPG trotzdem noch auf die Konsole zugreift? Keine Ahnung. ;-) Aber
irgendwie gehts wohl.
Grüße,
tobi
Raymund Achner
> Hi!
>
> Raymund Achner wrote:
>> ich tippe ganz stark darauf, daß gpg noch auf irgendeine Eingabe wartet
>> und sie nicht bekommt. Und solange wartet gpg eben...
>
> Ja, wartet er, ist ja ein Dialogprogramm, deshalb hole ich mir ja den
> Input und OutputStream um das Programm mit den entsprechenden Eingaben
> zu füttern. Siehe dazu meine Antwort an Tobias, dort habe ich den code
> gepostet.
Ich meinte, daß er trotz der Eingaben auf NOCH etwas wartet. Starte doch gpg
mal mit "1>dateiStdOut 2>dateiErrOut", vielleicht siehst Du da mehr?
> Aber wiso gehts auf die Konsole und nicht in die Streams?
gute Frage. Du mußt doch nur das Paßwort/Paßphrase eingeben, oder? Schließe
doch danach seinen Inputstream, vielleicht bekommt er das Ende der Eingabe
nicht mit???
ray
Jan Uebernickel
Raymund Achner wrote:
>>Aber wiso gehts auf die Konsole und nicht in die Streams?
> gute Frage. Du mußt doch nur das Paßwort/Paßphrase eingeben, oder? Schließe
> doch danach seinen Inputstream, vielleicht bekommt er das Ende der Eingabe
> nicht mit???
Nein, bei gpg --edit-key wird ein dialogprogramm gestartet, wo man
verschiedene Sachen machen kann, trust, sign, lsign..... und vieles mehr.
Ich habe jetzt herausgefunden, das wenn man z.B.
gpg --edit-key ad...@eMail.com quit
aufruft, wird der edit-key dialog gestartet und der Befehl quit wird
ausgeführt.
So weit so gut, gibt man aber jetzt z.B.
gpg --edit-key ad...@eMail.com trust 4 quit
ein - und jetzt kommst - wird der "trust" Befehl ausgeführt, danach
sollte er 4 auswählen (trust marginally) und dann beenden.
Aber der Dialog hängt nach trust und erwartet eine Eingabe vom User. ist
die erfolgt versucht er den Befehl "4" auszuführen, was nicht geht,
danach "quit" und er beendet.
Nach diesem Verhalten habe ich das Gefühl, das das irgendwie nicht am
Java Programm liegt, ein Test mit einem C Programm von mir verhielt
sicht nämlich so wie man das erwarten sollte.
gpg scheint den argv an andere Programme weiterzugeben, oder er
forkt...oder was weiß ich, auf jedenfall befreit er sich so wohl auch
von den Ein und Ausgabeströmen des Hauptprogrammes. Offentsichtlich ist
das umleiten der VM ws anderes als das schliesen und öffnen der
filedeskriptoren 0,1 und 2.
Falls jemand tiefergehen Kenntnisse von gpg hat und mir dabei helfen
könnte würde ich ihn bitten sich per mail bei mir zu melden, da die von
mir und einem Bekannten geschriebene GUI eigentlich den vollen Umfang
der sign and trust Möglichkeiten nutzen soll, was wie wir bisher gesehen
habe die wenigsten GUIs tuen.
Das ganze läuft Programmiertechnisch als Semesterprojekt fürs Studium,
aber ich denke ab Mitte August ist das beendet, falls dann interesse an
einer OpenSource Java GUI für gpg besteht könnte ich die entsprechende
Webseite freigeben, inkl. CVS.
Jan
--
There are only 10 types of people in the world:
Those who understand binary, and those who don't
Tobias Vogele
Tobias Vogele spoke:
> Ich hab mal daheim ein Perl-skript geschrieben, daß GPG fernsteuert,
> allerdings ist das eben zuhauese und nicht hier in der Uni. Wenn es heut
> abend nocht nicht geklappt hat, kann ich mal schauen, wie ich das da
> gemacht hab.
Hat leider 3 Tage gedauert, sorry, habs etwas verpennt.
Naja, aber jetzt hab ich das skript nochmal rausgekramt, und dort ist das
ausgeführte Kommando folgendes:
"$exe -d -o - -q --no-tty --passphrase-fd 0 --no-secmem-warning $file"
wobei $exe eben /usr/bin/gpg ist.
Anscheinend ist hier die entscheidende Option nicht --batch, sondern
"--no-tty" und "--passphrase-fd 0", wodurch die Passphrase vom
Filedeskriptor 0 erwartet wird, was stdin entspricht. Analog gibt es noch
andere "...-fd"-Optionen. Genaueres zu diesen Optionen steht in der
Manpage.
So kann ich jedenfalls die Passphrase über den stdin an gpg (also das, was
man in Java mit Process.getOutputstream() bekommt) übergeben und die
entschlüsselte Datei aus dem stdout von gpg lesen.
Mein Skript kann aber nur Dateien entschlüsseln und verschlüsseln+signieren
(und dazwischen kann man den Text editieren, ohne das der unverschlüsselte
Text jemals auf die Festplatte geschrieben wird), aber nicht andere
gpg-Kommandos ausführen, aber vielleicht hilft Dir der Ansatz schon mal
weiter.
Grüße,
tobi
--
URL: http://www.wartmal.de Email: ne...@wartmal.de
Jan Uebernickel
Tobias Vogele wrote:
> Hat leider 3 Tage gedauert, sorry, habs etwas verpennt.
> Naja, aber jetzt hab ich das skript nochmal rausgekramt, und dort ist das
> ausgeführte Kommando folgendes:
>
> "$exe -d -o - -q --no-tty --passphrase-fd 0 --no-secmem-warning $file"
Danke erstmal, ich werde das am WE ausprobieren, dann gebe ich nochmal
bescheid!
Gruß,
Jan Uebernickel
Tobias Vogele wrote:
> Hat leider 3 Tage gedauert, sorry, habs etwas verpennt.
> Naja, aber jetzt hab ich das skript nochmal rausgekramt, und dort ist das
> ausgeführte Kommando folgendes:
>
> "$exe -d -o - -q --no-tty --passphrase-fd 0 --no-secmem-warning $file"
>
> Anscheinend ist hier die entscheidende Option nicht --batch, sondern
> "--no-tty" und "--passphrase-fd 0", wodurch die Passphrase vom
> Filedeskriptor 0 erwartet wird, was stdin entspricht. Analog gibt es noch
> andere "...-fd"-Optionen. Genaueres zu diesen Optionen steht in der
> Manpage.
> So kann ich jedenfalls die Passphrase über den stdin an gpg (also das, was
> man in Java mit Process.getOutputstream() bekommt) übergeben und die
> entschlüsselte Datei aus dem stdout von gpg lesen.
Habe das inzwischen ausprobiert und auch die anderen -fd Optionen
gefunden. Ich hatte ja nun explizit Probleme mit "gpg --edit-key" dabei
landet der stdout einfach nicht im BufferedReader sondern auf der
Konsole. Die status Ausgaben etc.landen dort wo ich sie mit den
entsprechenden Optionen hinschicke, aber ich brauche den stdout...
Ich weiß echt nicht weiter, andere teile des gpg, z.B. gpg --list-keys
funktionieren ohne Probleme und schreiben ihre Sachen in den stdout den
man sich auch holen kann.
Ein auf Ideen hoffender
Bernd Eckenfels
> gpg scheint den argv an andere Programme weiterzugeben, oder er
> forkt...oder was weiß ich, auf jedenfall befreit er sich so wohl auch
> von den Ein und Ausgabeströmen des Hauptprogrammes. Offentsichtlich ist
> das umleiten der VM ws anderes als das schliesen und öffnen der
> filedeskriptoren 0,1 und 2.
naja, er benutzt halt absichtlich das tty device.
Ich nehme mal an bei edit key musste noch ein paar mehr optionen verwenden,
schau doch einfach wie es gpgme macht.
Gruss
Bernd
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
Jan Uebernickel
Bernd Eckenfels wrote:
> naja, er benutzt halt absichtlich das tty device.
> Ich nehme mal an bei edit key musste noch ein paar mehr optionen verwenden,
> schau doch einfach wie es gpgme macht.
Habes es mit gpgme versucht, aber noch durchschaue ich das noch nicht
ganz...
Könnte man nicht mittels der Enviroment dem gpg Programm das was direkt
nach tty geschrieben wird entreissen?
Muß aber unter Windows und Linux laufen.
Bernd Eckenfels
> Könnte man nicht mittels der Enviroment dem gpg Programm das was direkt
> nach tty geschrieben wird entreissen?
du kannst "--batch" oder "--no-tty" angeben, dann schreibt er es nicht auf das tty.
Problem ist, dass er auch keine interaktiven commands mehr zulaesst,
deswegen musst du auch mit status und command FDs arbeiten:
> gpg --batch --edit-key test trust
pub 1024D/2A357909 created: 2001-09-14 expires: never trust: -/-
sub 1024g/8373F8A6 created: 2001-09-14 expires: never
(1). Test User <te...@test.de>
pub 1024D/2A357909 created: 2001-09-14 expires: never trust: -/-
sub 1024g/8373F8A6 created: 2001-09-14 expires: never
(1). Test User <te...@test.de>
Please decide how far you trust this user to correctly
verify other users' keys (by looking at passports,
checking fingerprints from different sources...)?
1 = Don't know
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately
m = back to the main menu
gpg: Sorry, we are in batchmode - can't get input
> echo 1 | gpg --command-fd 0 --batch --edit-key LSK trust quit
Secret key is available.
pub 768R/BFEAD2CD created: 1996-05-22 expires: never trust: f/f
(1). Bernd Eckenfels <ec...@debian.org>
(2) Bernd Eckenfels <ec...@lina.inka.de> LSK
(3) Bernd Eckenfels (Jabber ID) <ec...@jabber.org>
pub 768R/BFEAD2CD created: 1996-05-22 expires: never trust: f/f
(1). Bernd Eckenfels <ec...@debian.org>
(2) Bernd Eckenfels <ec...@lina.inka.de> LSK
(3) Bernd Eckenfels (Jabber ID) <ec...@jabber.org>
Please decide how far you trust this user to correctly
verify other users' keys (by looking at passports,
checking fingerprints from different sources...)?
1 = Don't know
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately
m = back to the main menu
pub 768R/BFEAD2CD created: 1996-05-22 expires: never trust: q/f
(1). Bernd Eckenfels <ec...@debian.org>
(2) Bernd Eckenfels <ec...@lina.inka.de> LSK
(3) Bernd Eckenfels (Jabber ID) <ec...@jabber.org>
Please note that the shown key validity is not necessarily correct
unless you restart the program.
>
Und siehe da, es tut. Ich sag ja du sollst in die GPGME sourcen schauen,
oder auf der gpg-dev liste fragen. --no-tty ist besser als --batch, dann
solltest du aber "--status-fd 1" benutzen:
> echo 1 | gpg --command-fd 0 --no-tty --status-fd 1 --edit-key LSK trust quit
[GNUPG:] GET_LINE edit_ownertrust.value
[GNUPG:] GOT_IT
>
cool, oder?
Jan Uebernickel
Bernd Eckenfels wrote:
> Jan Uebernickel <jan...@gmx.de> wrote:
>
> du kannst "--batch" oder "--no-tty" angeben, dann schreibt er es nicht auf das tty.
> Problem ist, dass er auch keine interaktiven commands mehr zulaesst,
> deswegen musst du auch mit status und command FDs arbeiten:
> ---
> Und siehe da, es tut. Ich sag ja du sollst in die GPGME sourcen schauen,
> oder auf der gpg-dev liste fragen. --no-tty ist besser als --batch, dann
> solltest du aber "--status-fd 1" benutzen:
> ---
> echo 1 | gpg --command-fd 0 --no-tty --status-fd 1 --edit-key LSK trust quit
>
> [GNUPG:] GET_LINE edit_ownertrust.value
> [GNUPG:] GOT_IT
>
Ja, das ist mir schon alles klar offentsichtlich ist nicht deutlich
gewoerden was ich will. Verstehe mich nicht falsch, das steuern kriege
ich schon hin, mein Problem ist aber, das ich folgende Information:
pub 1024D/A7AF0DB5 created: 2003-01-15 expires: never trust: -/u
sub 4096g/D2319E80 created: 2003-01-15 expires: never
(1). Jan Uebernickel (Master Key) <jan.ueb...@gmx.net>
besonders das oben rechts "trust: -/u" haben möchte, und das schreibt er
aufs tty, als kurzer Test:
jan@omega:~$ gpg --edit-key jan.ueb...@gmx.net 1>test1 2>test2
Secret key is available.
pub 1024D/A7AF0DB5 created: 2003-01-15 expires: never trust: -/u
sub 4096g/D2319E80 created: 2003-01-15 expires: never
(1). Jan Uebernickel (Master Key) <jan.ueb...@gmx.net>
Command> quit
jan@omega:~$ cat test1
jan@omega:~$ cat test2
gpg (GnuPG) 1.0.6; Copyright (C) 2001 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
Wie man hier sehen kann, werden zwar die Fehler Ausgaben
rausgeschrieben, aber die Ausgabe die die wirkliche information enthält
nicht.
Mit --no-tty unterdrückt man sehr gut die entsprechende Ausgabe und kann
mit --status-fd=1 die Speziellen Ausgaben zum steuern bekommen, aber die
beinhalten nur ob etwas funktioniert hat.
Das würde mich noch wirklich interessieren, ob man nicht dem Process
eine environ mitgeben kann, in der tty mit stdout verknüpft wird oder
irgendwie direkt ein BufferedReader...
Gruß,
Bernd Eckenfels
> besonders das oben rechts "trust: -/u" haben möchte, und das schreibt er
> aufs tty,
nurt wenn du nicht --batch verwendest, hab ich doch grade geschrieben?!!
Ausserdem solltest du die Key info mittels "--with-colons" und "--list-keys"
und "--charset utf8" abfragen.
Jan Uebernickel
Bernd Eckenfels wrote:
> Jan Uebernickel <jan...@gmx.de> wrote:
>
>>besonders das oben rechts "trust: -/u" haben möchte, und das schreibt er
>>aufs tty,
>
> nur wenn du nicht --batch verwendest, hab ich doch grade geschrieben?!!
Ich glaube wir reden aneinander vorbei, nach den ganzen Antworten sieht
mein Aufruf folgendermassen aus:
gpg --no-tty --logger-fd=2 --status-fd=1 --command-fd=0
--passphrase-fd=0 --no-greeting --edit-key jan...@gmx.de
Danach kann ich alles wunderbar steuern, es kommen keine Ausgaben aufs tty.
So, ich wollte aber ganz gerne die trust Informationen als erstes
einlesen. Jetzt mache ich das mit einem neuem Aufruf der genau das macht
was du forgeschlagen hast und lese die antwort ein.
> Ausserdem solltest du die Key info mittels "--with-colons" und "--list-keys"
> und "--charset utf8" abfragen.
Das funktioniert soweit.
Jetzt rufe ich aber zweimal gpg auf. Die ursprüngliche Uberlegung war es
nur gpg --edit-key ..... aufzurufen da er dort ja das trust
Verhältniss ausgibt. Leider geht diese Ausgabe ins tty und nichts was
ich bisher gefunden habe kann sie so umleiten, dass ich sie in einen
BufferedReader bekommen. Bei meiner gpg Version auch nicht --batch.
Ein bisher echt dankbarer
Bernd Eckenfels
> Jetzt rufe ich aber zweimal gpg auf. Die ursprüngliche Uberlegung war es
> nur gpg --edit-key ..... aufzurufen da er dort ja das trust
> Verhältniss ausgibt. Leider geht diese Ausgabe ins tty und nichts was
> ich bisher gefunden habe kann sie so umleiten, dass ich sie in einen
> BufferedReader bekommen. Bei meiner gpg Version auch nicht --batch.
wenn du --with-colons angibst, dann schreibt er das nicht auf das tty, auch
nicht bei --edit-key