gpgme_op_delete() does not work with gpg 2.x

[Ben McGinnes]

On Wed, Jan 02, 2019 at 05:34:31PM -0500, brent s. wrote:
> On 1/2/19 4:17 PM, Jeroen Ooms wrote:
> >> I'm not sure how much this will help you, but deleting a private key
> >> works in the Python bindings if I use the abstracted method but not the
> >> direct gpgme method (see attached POC).
> > 
> > So which C function does the latter use then? I don't use python but
> > to me it looks like both those methods are different syntax for the
> > same thing? Why would they show different behavior?
> > 
> 
> I don't know much about the bindings themselves other than they're
> generated (mostly?) automatically via SWIG[0]. However, the former
> method (gpgme.gpgme_op_delete()) is, I believe, the direct SWIG
> method.

Yes, SWIG generates methods to match every correspondingly named
method, function, call and constant in GPGME itself.  So everything
which starts with "gpgme_op_" is generated by SWIG.  Those methods
behave as close as possible to the C originals.

Then there's a more Pythonic layer above that which has been added
manually.  It doesn't do everything GPGME does, but it probably does
most of the things most developers would want.  In many cases the
opportunity has been taken to simplify certain things (e.g. to make it
unnecessary for devs to need to memorise or reference check mode or
status values in the constants, as can be seen with the key exporting
code).

Inevitably some people ask, why use SWIG.  Aside from historical
reasons stemming from PyME; SWIG can generate bindings in a form which
is complete and which certain other popular methods simply can't do
(e.g. CFFI, ctypes, etc.).  GPGME is somewhat larger than many people
realise and every time it's compiled, SWIG generates somewhere in the
vicinity of a couple of thousand bindings.

That number is increasing with each release, albeit gradually — it's
currently a little over 2,070 functions across GPGME's calls, methods
and constants.  That's with duplicates, Python specific bits and SWIG
specific bits removed from the count.

Still, those bindings will often be somewhat confusing to developers
with no experience dealing with C at all.  Between that issue and the
intention of being able to make a consistent Pythonic interface,
regardless of what happens under the hood; there was more than good
enough reasons for writing that Pythonic layer of essential functions.

Most of that is in gpg.core; then components are imported from core to
the parent module.  This includes the Context() and Data() methods,
amongst other things.  The actual SWIG bindings can be accessed via
either or both of gpg._gpgme or gpg.core.gpgme; but I don't recommend
it unless there's something you *really* need and which isn't
accessible via the Context() directly.

> SWIG does support R, it looks like[1] so you may be able to create the R
> bindings in much the same way (while even reusing many of the parts for
> python[2]).

It can probably be done, just as long as one is familiar with SWIG's
own syntax and can adapt it between languages.

> Based on git commit history, I'd try to see if you can get in touch
> with Ben McGinnes[3]; he should be able to answer your question with
> much more clarity, I'd imagine. Sorry I wasn't much more help!

Well, to answer that question:

gpgme_op_delete is in src/delete.c in the GPGME repo or any source
release.  The auto-generated GPGME documentation entry for that and
related calls is here:

https://gnupg.org/documentation/manuals/gpgme/Deleting-Keys.html

That documentation, however, is rather sparse.  It's better used as a
reference than an instruction manual.

The Python bindings, however, do have a more readable documentation
set' that being the HOWTO it ships with.

> [0] http://www.swig.org/
> [1] http://www.swig.org/Doc1.3/R.html
> [2]
> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=tree;f=lang/python
> [3] You can get his email address by cloning the gpgme git repo and running:
> 
>   git shortlog -nes -- lang/python

That's one way, to be sure.  It's also at the top of the Python
bindings HOWTO doc.  That address will also be effectively filtered so
things don't get lost amidst the many thousands of things that come to
this address.

> or just getting it from the gitweb interface.

That too.

> (not pasting the email addresses here in case there are harvesting
> spiders for spammers)

Appreciated, but I've had this domain for about twenty years.  Spam
harvesting from lists is something I stopped worrying about a *long*
time ago.  ;)


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/20190214/32b195c7/attachment.sig>