GPG/GPGME problem

[Marcus Brinkmann]

At Fri, 05 Aug 2005 19:07:54 +0200,
harry_b at mm.st wrote:
> I am pretty confused about a problem with gpg and gpgme. I am working on
> an encryption program and for this I wrote some test sequences which now
> give me a hard time. Every 1000 runs or so, the following steps produce
> a  weird error which even gpg itself messes up. :-/
> 
> I am on Debian unstable and use GPG 1.4.1 and gpgme 1.0.2.
> 
> My test runs these steps:
>    1. Create some random XML data file
>    2. gzip this file (as my application does using zlib)
>       $ gzip -9 FILE_A
>    3. encode it with a testkey
>       $  echo "1234567890" | GNUPGHOME=./tests GPG_AGENT_INFO= gpg
>       --no-tty --recipient="TESTKEY" --passphrase-fd 0 --armour --sign
>       --encrypt --output="FILE_B" "FILE_A"
>    4. run my application and see if it can decrypt the file and write
>       the same data again
>    5. compare the gpg file with my own file
> 
> The problem now is, that even gpg can't decrypt it's own file FILE_B. I
> tried this with several keys and it happens with all of my keys. :-(

You may try to keep debug logs of the gpg runs in step 3, so that you
can catch the failing case and at least have some information about
it.  Then check if it is reproducible with the same data set (ie, run
only step 3 on the same data a couple thousand times).

> I get these two errors:
>    - gpg reports:  gpg: [don't know]: invalid packet (ctb=14)
>    - gpgme reports: Unexpected signature summary: 0x800

The GPGME output may itself be a bit problematic if GPGME doesn't cope
with the error output of gpg very well (that may be the case, we can
look at this individually, for example if you send me the broken file
so I can reproduce it).  But of course if your step 3 above creates an
invalid file, then the problem must be GPG or the way you are using it
(although the command line looks basically OK to me).

> The weird thing is, that it seems to depend on the data which I create
> pretty randomly with a little perl script.

If it depends on the data, that would be good, because then step 3
would be reproducible.  If it fails sometimes and works some other
times on the same data set, then this points to a completely different
class of bugs, which can be harder to track down.
 
> Any ideas what I can do about this very weird thing?

A better (ie more isolated, more specific) test case would be good.

> PS: Some of these buggy files are in the attached tar.gz file.
> [2 buggy-files.tar.gz <application/x-gzip (base64)>]

I get EOF on all of them, not even invalid packet...

Thanks,
Marcus