Showing signatures for exported/unimported keys using the Python GPGME bindings

Paul Boddie paul at boddie.org.uk
Thu Aug 22 21:18:01 CEST 2024


Hello,

I have recently been investigating the Python GPGME bindings, available as 
python3-gpg in Debian, and translating code that previously invoked the gpg 
executable directly. Having managed to successfully find my way around the 
API, I think I have discovered a shortcoming with the bindings.

When processing an exported key held in a file, if I use the context's keylist 
operation, indicating the source as "data" as opposed to the keychain, the 
operation does not yield signature information for each key. For example, with 
file f and generator result g:

  g = context.keylist(source=f)

For operations involving the keychain, it is possible to set the mode in order 
to return signature details, but it does not seem to be possible to set the 
mode of the operation when a source is indicated.

Indeed, the source code for the bindings appears to discard the mode where a 
source is involved. Here is code from Context.keylist in gpg/core.py:

        if not source:
            self.set_keylist_mode(mode)
            self.op_keylist_start(pattern, secret)
        else:
            # ...
            if not isinstance(source, Data):
                source = Data(file=source)
            self.op_keylist_from_data_start(source, 0)

However, changing this code to set the mode even with a source indicated 
(specifying the SIGS and/or SIG_NOTATIONS flags) does not cause the operation 
to yield signature information.

Oddly, the gpg executable will produce this information. For example:

gpg --show-keys --with-sig-list keyfile

This shows signature details for each of the keys.

I tried to search for any previous reports of this behaviour but only found 
the following discussion thread:

"python GPGME bindings and key signatures"
https://lists.gnupg.org/pipermail/gnupg-devel/2018-November/034023.html

This discusses the retrieval of signature information for keys on the 
keychain, not from unimported keys residing in files.

I wonder if this is a known shortcoming of the API or whether it was a 
deliberate decision or consequence of some other choice. The discrepancy 
between the API and gpg itself seems peculiar.

Paul

P.S. Some kind of quick reference mapping gpg operations to the API would be 
rather helpful. I see that examples are provided with the bindings, but they 
are not particularly comprehensive.





More information about the Gnupg-devel mailing list