GnuPG Security Disaster?

[Bernard]

Hi Bernd,

Many thanks for your interesting reply.

It always feels like I am almost getting there!

On Thu, 3 Jan 2002 15:23:07 +0100, you wrote:

>On Thu, Jan 03, 2002 at 10:00:55PM +1300, Bernard wrote:
>> 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.
>
>You need one for stdin as well. The reason for this is, that java is not
>good (does not do) in async IO, and non blocking io with bussy polling is
>out of the question.

I tried this today. I was very excited to see the result but I was
disappointed. It did not work.

Before I answer your interesting questions below, let me suggest a
plan in case further efforts are fruitless.

The purpose of the plan is to increase the likelyhood of success
without draining our resources unnecessarily.
I have before our correspondence submitted to Sun a collection of test
cases they can use to verify their new JDK 1.4 Process API fixes.

2 of these cases include GnuPG execution, 1 is identical with what I
am struggling with.
I guess that nobody has the complete picture because the problem
crosses too many boundaries.

It would not suprise me if Sun did not accept my testcase as relevant
to them because they might think there is a bug in GnuPG.

I personally think that the window of opportunity for external process
encryption from within Java is limited because some time in the future
pure Java implementations will be powerful enough.

But while the Java-GnuPG opportunity exists, it could be used to
improve both systems simultaneously.

4 sources of errors could be considered in the following sequence:
1) Java application code
2) GnuPG code
3) Sun Java code
4) Microsoft Windows code (bad if we get here)

I could try to improve my code until it works. If it doesn't then I
could send you the code so that you can test GnuPG against it.
If that doesn't work then it's probably time for a compact C program
testcase that simulates the GnuPG behaviour in a way that is easy to
study foor Sun engineers. It should be submitted to Sun as a bug,
alongside with the Java test code.
What do you think?


>What kind of Streams do you use for the FDs?

In effect I use:

InputStreamReader stdout = new InputStreamReader(new
BufferedInputStream(process.getInputStream()));

InputStreamReader stderr = new InputStreamReader(new
BufferedInputStream(process.getErrorStream()));

PrintStream stdin = new PrintStream(process.getOutputStream());

Why is a separate thread needed under Java for the gpg stdin?

When I write to it from within the main thread then it never blocks;
it returns instantly.

In comparison I do understand why stdout and stderr are blocking. I
have seen them blocking and I am reading them byte-by-byte instead of
using readLine() to avoid blocking on a 2-character line break
sequences e.g. CR+LF.

>And which
>command line do you execute? Are us using javaw.exe?

I am using java.exe. Interesting that you mention this. There is a
very popular bug record on Sun's bug parade about the DOS box that
can't be hidden with external processes. I was concerned that fixing
this could create follow-on problems such as the one I have now.

>
>BTW: returning to your java experience with Cryptix: did you measured the
>time to start java and then encrypt? in that case you should do the same
>with your java GPG wrapper, and I dont think you see much speed difference
>for small files like "hello".
I ran this from within a servlet engine so there was no startup
overhead. Things might have improved since then.

Kind Regards,
Bernard