GnuPG Security Disaster?

[Bernard]

Hi Werner,

Many thanks for your help.
Please excuse my ignorance - my current GnuPG knowledge ends at the
command line interface.

On Thu, 03 Jan 2002 09:17:43 +0100, you wrote:

>On Thu, 03 Jan 2002 16:53:09 +1300, Bernard  said:
>
>> Do I have the slightest idea where the error is? No. I hope someone
>> will find out.
>
>For gpgme we had to use one thread for each pipe; otherwise the system
>blocks in certain cases.
I see. Did you use the command line interface to the gpg.exe?

How many threads do I need in case of
"gpg.exe  --homedir[homedir] --always-trust --no-secmem-warning
--batch --no-tty -r [recipient] -a -e" ?

In a batch file, this works well as
"echo [data]|gpg.exe --homedir[homedir] --always-trust
--no-secmem-warning --batch --no-tty -r [recipient] -a -e

In Java, it blocks even with 3 threads, 1 reader thread for stderr, 1
reader thread for stdout, 1 main thread.

The main thread executes the command, starts and connects the other 2
reader threads,  then writes to stdin and then waits for the command
to complete.

The main thread should get woken up to check both reader threads
whenever one of the 2 reader threads finishes but that does not appear
to happen even once.

So it hangs there forever.

The interesting part is that the above scenario in exactly the same
sequence works with the following command:
gpg.exe --yes --batch --armor --no-tty --passphrase-fd 0 -o [output
file] [input file]

>And you have to read all data after

>WaitForMultipleObjects indicated that there is some available for the
>pipe.
No idea what that translates into in the Java Process API.
>Whereas select(2) allows to read only part of the data and a
>second select(2) would immediately return if not all data has been
>read.

Is there anything in the command line interface that corresponds with
"WaitForMultipleObjects" and "select(2)"?

Does the difference between "WaitForMultipleObjects" and select(2)
translate into something distinguishable in the command line
interface?
e.g. is there a difference of handling requirements between
"--passphrase-fd 0" for the passphrase via stdin
and
default stdin for data as in the command example above?
>
>Timo should know the Windows issues better.
It would definitely be a breakthrough for me if I could get this
command line interface sorted out for at least the basic operations:
encrypting and decrypting through stdin and stdout thereby avoiding
the most visible explicit writing to disk files which could be spotted
as a security breach by almost anyone.

The next obvious question is:
How shall I provide 2 separate logical pieces of data, 1 passphrase
and 2 input data on stdin? I only have 1 stdin in the API - I cannot
generate additional file descriptors AFAIK. That is where I came from
in the beginning when I was looking for a passphrase _parameter_ as
available in pgp.

It looks complicated to me now because I haven't even managed the
level of complexity before that.

Many thanks,
Bernard