Mailing List Archive

gpgme_op_delete() does not work with gpg 2.x
A user of the R bindings has reported (and I have confirmed) that
deleting secret keys in gpgme does not work with gnupg2. We call (on
an existing key):

gpgme_op_delete(ctx, key, 1)

This returns success if the key exists, and when we are running with
GnuPG 1.4 the key is deleted. However when running gpg2 it returns
success but the key is still there.

Downstream issue: https://github.com/jeroen/gpg/issues/3

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: gpgme_op_delete() does not work with gpg 2.x [ In reply to ]
On 12/29/18 9:01 AM, Jeroen Ooms wrote:
> A user of the R bindings has reported (and I have confirmed) that
> deleting secret keys in gpgme does not work with gnupg2. We call (on
> an existing key):
>
> gpgme_op_delete(ctx, key, 1)
>
> This returns success if the key exists, and when we are running with
> GnuPG 1.4 the key is deleted. However when running gpg2 it returns
> success but the key is still there.
>
> Downstream issue: https://github.com/jeroen/gpg/issues/3
>
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>

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).

Haven't taken a look at the R bindings; is there a similar
context-specific method there?

--
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info
Re: gpgme_op_delete() does not work with gpg 2.x [ In reply to ]
On Sat, Dec 29, 2018 at 5:01 PM brent s. <bts@square-r00t.net> wrote:
>
> On 12/29/18 9:01 AM, Jeroen Ooms wrote:
> > A user of the R bindings has reported (and I have confirmed) that
> > deleting secret keys in gpgme does not work with gnupg2. We call (on
> > an existing key):
> >
> > gpgme_op_delete(ctx, key, 1)
> >
> > This returns success if the key exists, and when we are running with
> > GnuPG 1.4 the key is deleted. However when running gpg2 it returns
> > success but the key is still there.
> >
> > Downstream issue: https://github.com/jeroen/gpg/issues/3
> >
> > _______________________________________________
> > Gnupg-devel mailing list
> > Gnupg-devel@gnupg.org
> > http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> >
>
> 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?


> Haven't taken a look at the R bindings; is there a similar
> context-specific method there?

I maintain these bindings so I can add it a working implementation if
I know which C API to call.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: gpgme_op_delete() does not work with gpg 2.x [ In reply to ]
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
and the latter Context class method (gpg.Context().op_delete()) is
inherited somehow from it (as I don't see an actual separate
.op_delete() method defined anywhere in the library).

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]).


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!




[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

or just getting it from the gitweb interface.

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

--
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info
Re: gpgme_op_delete() does not work with gpg 2.x [ In reply to ]
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