Page MenuHome GnuPG
Create Task
Maniphest T706

gpgme does not report errors from gpg
Closed, ResolvedPublic
Actions

Description

Note: this bug report is for gpgme 1.0.2. I haven't checked it in 1.1.2, but I
want you to know anyway.

When gpg is misconfigured, like say

>grep XXX .gnupg/options
trusted-key XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

, gnupg does not handle this sanely but reports no error but just
returns no data.

The following code outputs "Huh?" in such situations
(with both the stable version and a vanilla unstable version
compiled on stable):

assert( gpgme_data_new_from_file(&sig, filename, 1) == 0 );
assert( gpgme_data_new(&plain) == 0);
if( gpgme_op_verify(context,sig,NULL,plain) == 0 ) {

plain_data = gpgme_data_release_and_get_mem(plain,&plain_len);
if( plain_data == NULL ) {
        fprintf(stderr, "Huh?");
}

}

(Debian bug #389235)

Event Timeline

jsogo added projects: Bug Report, gpgme.Sep 24 2006, 11:32 PM
jsogo added a subscriber: jsogo.
• werner assigned this task to marcus.Sep 25 2006, 10:56 AM
• werner added a subscriber: marcus.
marcus added a project: Stalled.Sep 25 2006, 4:29 PM

Thanks for reporting this. There are a couple such issues where gnupg does not
issue an error message, and thus the operation will silently fail in GPGME as
well. In the past there used to be some heuristics in place which tried to
catch such situations, but they were causing other problems, so they were not
much of an improvement, and for 1.x I removed most of them.

Also see the TODO file, under "Operations", for more of these kind of failures.

Setting the status to deferred, as there is little we can do about it until GPG
reports more errors.

marcus added a comment.Dec 10 2008, 6:21 PM

Actually, gpg can not do much if configuration options can't be parsed. GPGME
does not see the exit code due to the double-fork approach.

The best way to fix this, I guess, is to check the configuration's validity with
gpg-conf before doing anything else. Unfortunately, the gpg-conf interface in
GPGME probably does not handle error scenarios yet well, either. But
conceptually, gpg-conf is in a better position to handle this and report such
problems than gpg is.

marcus reassigned this task from marcus to • werner.May 30 2011, 3:07 PM
marcus added a subscriber: • werner.
• werner removed • werner as the assignee of this task.May 30 2011, 4:45 PM

The exit code alone is not sufficient to return a useful error status. Thus
Marcus is right that we can't do much and gpgconf should be used to validate the
configuration.

In theory it would be possible for gpgme to run gpg with --gpgconf-test to see
whether the gpg.conf is okay but it still won't catch all error cases.

• werner added a project: Too Old.May 22 2013, 2:54 PM
• werner closed this task as Resolved.Dec 11 2014, 11:58 AM
• werner claimed this task.
• werner removed a project: Stalled.