GPG/GPGME problem

[harry_b at mm.st]

Hi Marcus,

I can reproduce this weird behavior with gpg each time - even without my 
own program when I use one of the buggy data file.
The problem only occurs, when I encrypt and sign the file - encryption or 
signing only does not have this problem and works like expected.

Wgen I run 'gpg --debug-all --decrypt BUGGYFILE' I get this debug output 
before it terminates:

[...]
gpg: DBG: iobuf-14.0: close `file_filter(fd)'
gpg: DBG: /home/harry/.gnupg/pubring.gpg: close fd 6
gpg: DBG: fd_cache_close (/home/harry/.gnupg/pubring.gpg) used existing slot
gpg: DBG: finish_lookup: checking key XXXXXXXX (all)(req_usage=0)
gpg: DBG:       using key XXXXXXXX
gpg: DBG: cache_user_id: already in cache
gpg: DBG: iobuf-13.0: close `file_filter(fd)'
gpg: DBG: /home/harry/.gnupg/pubring.gpg: close fd 7
gpg: DBG: fd_cache_close (/home/harry/.gnupg/pubring.gpg) used existing slot
gpg: Good signature from "my key <mail at address>"
gpg: DBG: free_packet() type=6
gpg: DBG: mpi_free
[...]
gpg: DBG: dummy m_size called
gpg: DBG: mpi_free_limb_space of size 0
gpg: DBG: free_packet() type=8
gpg: [don't know]: invalid packet (ctb=14)
gpg: DBG: free_packet() type=18
gpg: DBG: iobuf-1.2: underflow: req=8192
gpg: DBG: iobuf-1.2: underflow: got=0 rc=-1
gpg: DBG: iobuf-1.2: pop `(null)' in underflow (!len)
gpg: DBG: iobuf chain: 1.0 `file_filter(fd)' filter_eof=0 start=4675 
len=4675
gpg: DBG: iobuf-1.0: underflow: eof
gpg: DBG: iobuf-1.0: close `file_filter(fd)'
gpg: DBG: check-data-410-1.data.gpg: close fd 3
gpg: DBG: fd_cache_close (check-data-410-1.data.gpg) new slot created
random usage: poolsize=600 mixed=4 polls=0/28 added=140/2464
              outmix=0 getlvl1=0/0 getlvl2=0/0
secmem usage: 1408/3968 bytes in 2/9 blocks of pool 5472/32768

I could send you my program and a detailted description to run my tests - 
it basically is just a configure, make, make test scenario so maybe you can 
reproduce this on your side.

Unfortunately I have access to Debian unstable machines and there it 
continually behaves this weird. I am not sure if it's the case on other 
Linux' as well. :-/

Is there anything I can do to track this further down?

Harry


--On Thursday, August 11, 2005 11:41:05 PM +0200 Marcus Brinkmann 
<marcus.brinkmann at ruhr-uni-bochum.de> wrote:

> 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...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20050901/06eed909/attachment.pgp