Page MenuHome GnuPG

gpgsm may insert debug-output into encrypted stream
Closed, ResolvedPublic

Description

Under some circumstances, gpgsm 2.0.3 inserts debug output into the
stream with the encrypted data. This results in emails that cannot be
decrypted because the format of the data is wrong. The attached file
allow-coredump-sample-mail.txt contains a such a mail. If you base64
decode the body you'll see that some debug output precedes the binary
encrypted data.

The following conditions are necessary AFAICT for the bug to occur:

  • ~/.gnupg/gpgsm.conf contains among other things:

    debug-allow-core-dump debug-level guru

    Without debug-allow-core-dump it doesn't happen at all. The debug level needs to be sufficiently high, so that the debug output that ends up in the encrypted stream is actually generated in the first place.
  • I've only been able to reproduce it when gpgsm is used from Kontact (using version proko2.1.6 from proko2 branch). I've not been able to reproduce it with gpgsm on the command line.
  • During the experiments I temporarily had set GPGME_DEBUG, bug while that was set, the problem didn't occur anymore. So *not* setting GPGME_DEBUG seems to be required too.

Details

Due Date
Aug 25 2007, 2:00 AM
Version
2.0.5

Event Timeline

bherzog added a subscriber: bherzog.

This is because the application that execed gpgsm did this with stderr closed.
Thus file descriptor 2 is free to be used by an open call and it happened that
this is the output stream. This is a common problem for applications not
setting up the environment correctly when calling exec. The Unix specs say that
all processes are invoked with valid file handles 0,1 and 2.

Not too long ago we added a workaround for gpg because too many PHP or whatever
hackers don't get it right and thus garbled keyrings (which might happen as well
as mixing data into the output). I expect people working with gpgsm to have a
better understanding of gpgsm and thus I won't add such a workaround to gpgsm.
If we start to do that we would consequently need to do this with almost all
Unix tools in an OS.

Anyway, while looking at the problem I realized that gpgsm did not register its
own logging handler with libgcrypt so that redirecting the log output won't
work. To solve this I fixed this in all modules and also made sure that fatal
errors from libgcrypt are as well handled by the usual gnupg logging subsystem

Please try whether SVN revision 4488 solves your problem.

werner set Due Date to Apr 25 2007, 2:00 AM.

Berhanrd: May we close this bug?

I tried to build rev. 4488 from SVN trunk, but compilation fails with:

gcc -DHAVE_CONFIG_H -I. -I.. -I../gl -I../common -I../intl
-DLOCALEDIR=\"/usr/local/share/locale\" -DGNUPG_BINDIR="\"/usr/local/bin\""
-DGNUPG_LIBEXECDIR="\"/usr/local/libexec\""
-DGNUPG_LIBDIR="\"/usr/local/lib/gnupg\""
-DGNUPG_DATADIR="\"/usr/local/share/gnupg\""
-DGNUPG_SYSCONFDIR="\"/usr/local/etc/gnupg\"" -g -O2 -Wall -Wcast-align
-Wshadow -Wstrict-prototypes -Wno-format-y2k -Wformat-security
-Wformat-nonliteral -Wno-pointer-sign -MT certcheck.o -MD -MP -MF
.deps/certcheck.Tpo -c -o certcheck.o certcheck.c
certcheck.c: In function 'do_encode_md':
certcheck.c:75: error: 'GCRY_PK_ECDSA' undeclared (first use in this function)
certcheck.c:75: error: (Each undeclared identifier is reported only once
certcheck.c:75: error: for each function it appears in.)
certcheck.c: In function 'pk_algo_from_sexp':
certcheck.c:214: error: 'GCRY_PK_ECDSA' undeclared (first use in this function)

Do I need a newer libgcrypt? If so, which one? The 1.2 branch doesn't seem to
have the GCRY_PK_ECDSA. It is in libgcrypt trunk, but does gnupg2 now depend on
a development version of libgcrypt?

bherzog removed a project: Restricted Project.Jul 25 2007, 7:24 PM

Tested again with gnupg 2.0.5. The problem is still there. The symptoms are
exactly the same as described in T787 (bherzog on Apr 19 2007, 08:44 PM / Roundup).

(updated version number and assigned to werner, if this is okay)

bernhard added a project: S/MIME.
bernhard changed Version from 2.0.3 to 2.0.5.
werner changed Due Date from Apr 25 2007, 2:00 AM to Aug 25 2007, 2:00 AM.Aug 20 2007, 10:55 PM
werner added a project: Too Old.

2.0.5 is too old. Feel free to reopne if thatt problems is still in 2.0.19 or
later.