About using GPGME, etc.

[Dashamir Hoxha]

Hi,

A couple of years ago I was suggested that using GPGME
for implementing EasyGnuPG would be better than using
the command `gpg` directly. And indeed I thought that it was
a good idea, but I couldn't give it a try because I didn't know
Python and I had no more free time left.

A couple of months ago I started a GSoC project about this,
and now it is almost finished. You can see the changes here:
https://github.com/EasyGnuPG/pgpg/pull/84/files?utf8=%E2%9C%93&diff=unified&w=1
(green lines are the original code, and red lines are the new
code which replaces the command `gpg` with Python code
and GPGME, it is a reverse diff).

Now that I look at it, I think that the original code is better,
and it is not worth replacing `gpg` by GPGME calls.
However I would like to know your opinion as well.

The reasons that I think so are these:

- `gpg` calls are more compact than the corresponding GPGME code.
   Basically we are replacing a single line of Bash code with about
   20-30 lines of Python code. It can expand even further if all the edge
   cases are handled properly (right now they are not handled).
   In my opinion this increases the complexity of the code, makes it more
   difficult to understand and maintain, and is unnecessary.

- Not everything that can be done by the command `gpg` can be
  achieved through GPGME. So, we still have to rely on `gpg`
  for some parts of the program. See:
  https://lists.gnupg.org/pipermail/gnupg-devel/2018-July/033829.html

- Even those things that can be achieved by GPGME are not done
  easier than doing them from `gpg`. For example those actions
  that need interactivity. My hope was that there would be a better
  way for doing them in GPGME, but I was disappointed. Either there
  is no better way, or there is no way at all.

- One of the advantages of using GPGME would be that the programmer
   has better control over the output. Since `gpg` output is meant for the
   humans, it is difficult to be parsed by the programs, and it is
difficult to
   customize. With GPGME we have better control over the output.

   However the aim of `egpg` has never been to replace `gpg`, but
   to make it easier for the users. One of the design goals of `egpg`
   is that it tries to integrate seamlessly with `gpg`, so that the users
   can switch to `gpg` easily if they find that the assumptions and
   the simplified interface of `egpg` restricts them somehow.
   So, displaying the original messages from `gpg` in this case
   is actually a god thing, not a bad thing, since it helps the users
   to get familiar with the `gpg` itself, although they are using `egpg`.

In general, I find GPGME an incomplete programming interface (API).
For some applications it may be sufficient, but there are certainly cases
that it cannot handle. I think that GPGME may become complete only
when the `gpg` command itself is built on top of it.

I also find odd and not quite suitable for programming the interactive
interface. It could have been better if GPGME used a RESTful API
for communicating with the GnuPG engine (similar to what most
of the web services use nowadays). For example GPGME can send
to the server (GnuPG engine in this case) an action and the parameters
(the data) needed to perform this action, and then get an answer with
a status of the result, the result itself, any error messages, etc.

The GPGME (or at least the Python implementation) can also build
and present to the applications a higher level of abstraction, for example
an object-oriented representation of the data and the actions performed
on them. This could make easier to build applications that are based
on GPGME.

However all these changes for improving GPGME maybe need
another GSoC project, or a project wider than that.

On the other hand, the `gpg` command itself can try to make easier
the life of programmers by:
1 - Trying to offer a batch mode for any action that currently can be done
      only through interactivity.
2 - Trying to offer a more programmer friendly output. One of the
      problems with trying to call `gpg` directly on applications is that
      its output is meant for humans, so it is difficult to be parsed by
      applications. However the situation would be better if there was
      an option or an environment variable to tell it to output programming
      friendly output instead. The format of this output can be JSON,
      or XML, or whatever can be parsed easily by the applications.
      It may also be configurable.

Implementing these improvements to `gpg` seems to be a big project
as well, and it may also be interwoven with the project of improving
GPGME.

These are my thoughts about building GnuPG based applications.
Any opinions would be welcome, especially from other people who
have used or are trying to use GPGME on their applications.

Regards,
Dashamir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180710/62950c20/attachment.html>