Gpgme_op_sign(...,GPGME_SIG_MODE_CLEAR) output limited to ~20757 with callback data buffers.

[Uldis.Ansmits at tieto.com]

> Uldis.Ansmits at tieto.com wrote:
> > Gpgme-1.2.0
> >
> > I noticed an unexpected signing behaviour for large files
> when using plain and crypto callback buffers.
> > This happens only in GPGME_SIG_MODE_CLEAR mode. All other
> operations work fine.
> > The same problem also with gpgme_op_sign_start/wait.
> >
> > It looks like write callback is called after all reading is
> done. But only part of clearsign data is written. Depending
> on OS I got 2 - 7 write callbacks (different PIPE_BUF sizes)
> with total 20751 - 20757 written.
> > Tested on x86_64, IA64, powerpc, sparc. GCC42 was used everywhere.
> >
> > To reproduce:
> > * plain and crypto callback data buffers must be used
> > * only signing opration in GPGME_SIG_MODE_CLEAR mode
> > * plain data more than 20757 bytes
>
> Hi,
>
> thanks for the report.  It would help me a lot if you could send me an
> isolated test case, that means a small C program and a data
> set that, for
> which you can see the bug.  Then I can very quickly see if I
> can reproduce it
> and if yes, I should be able to figure out the problem quickly.
>
> Also, independent of that, sending a GPGME_DEBUG=9 output
> file that shows the
> bug could be helpful.
>
> Thanks,
> Marcus
>

I modified an existing gpgme test. See patch file.
Is look like it is important to sign highly compressible data.

Uldis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gpgme_debug.log.gz
Type: application/x-gzip
Size: 9763 bytes
Desc: gpgme_debug.log.gz
URL: </pipermail/attachments/20100222/a0c32416/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gpgme_op_sign_test.patch
Type: application/octet-stream
Size: 1424 bytes
Desc: gpgme_op_sign_test.patch
URL: </pipermail/attachments/20100222/a0c32416/attachment-0001.obj>