Help with python library

[Ben McGinnes]

On Mon, Mar 05, 2018 at 04:36:47PM +0100, Werner Koch wrote:
> On Mon,  5 Mar 2018 00:05, ben at adversary.org said:
> 
>> However, gpg --list-packets is a debugging tool, so I'd need to
>> double-check whether there was a full implementation of that in the
>> API.
> 
> Right.  Note that there is a somewhat related feature request
> https://dev.gnupg.org/T3734 (Extract signature key ID with gpgme).

Interesting.  I'd definitely like to see a feature like that added to
GPGME.  Something which would passively (in the sense of not
performing any action on the data, as is the case with verifying a
signature or decryption) read an OpenPGP file (either binary or ASCII
armoured) and report the sort of things viewed with list-packets or
pgpdump.

It's already possible to get a lot of information about keys, for
instance, via gpg.Context().keylist(); but even that doesn't get quite
everything that list-packets does.  It doesn't for instance, obtain
the digest algorithm with which the key certified itself.

> For checking whether a file is correctly encrypted, I would suggest
> to simply try to decrypt it to /dev/null.  The result information
> lists the all keys; see gpgme/tests/run-decrypt.c for sample code.
> If needed we can add a --dry-run feature so that no passphrase is
> needed.

The OP replied to me offlist (which was foolish because it ended up in
a catchall, unlike posts to the list) indicating the use case was for
messages or files received from clients of his employer.

In which case he might or might not have access to the key the data is
encrypted to or supposed to be encrypted to, but still need to confirm
whether or not the customer has actually done what they were told to
do the right way.  In my experience that's rare enough in general
without the additional complication cryptography brings to the party.

That's definitely the sort of thing people use list-packets for fairly
often.  That being the case it's also the sort of thing which people
would want to access programmatically.  I can think of a bunch of
scenarios where a security conscious IT department might need to check
that employee generated keys all meet certain minimum key requirements
and, depending on the size of the organisation, they might not want to
do do that manually).

Obviously in the OP's use case there may be limitations to that if the
client used -R or -F instead of -r or -f (or if they used the
throw-keyids option), but most people don't even know those options
exist, let alone would choose to use them.


Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180307/870f4828/attachment.sig>