Help with python library

[Marcel Fest]

> 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
Hey Ben,

Sorry that I replied offlist, but I am not that used to mailinglists.

I now use a combination of the gpgme python bindings for decryption and
for encryption I use PGPy, because I need a dedicated keyring and gpgme,
does not create one for me, like the gpg cli does it. To get the keys
from the KeyServers I use a customized version of a github project which
speaks to defined KeyServers with requests.

All in all I have now a working version of my CLI completely without
subprocess bindings.

python-gnupg is good but only a cli wrapper for the gpg cli via subprocess.

PGPy has also the support for getting issuers out of encrypted files.

Best Regards

Marcel Fest

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180308/d21a1b2a/attachment.sig>