Why Operating Systems don't always upgrade GnuPG

[Werner Koch]

On Mon, 19 Feb 2018 19:45, dkg at fifthhorseman.net said:

> GnuPG is under active development, and it has never had a fully-featured
> stable API (Application Programming Interface).  What i mean is, there
> are some capabilities that are only available from the user interface
> (UI), and are not in the stable API.  GnuPG's UI has been constantly

You probably expected that I need to dissent: Modulo a few bugs there
has always been a stable API in GnuPG and we have taken great caution to
not break it.  Granted some parts of the API are not easy to use but
nevertheless, they are stable.  For example the --edit-key interactor
requires the use a state machine to stay compatible with future versions
of GnuPG.  This has been remarked over and over in the last ~20 years.
Unfortunately some folks reject to read manuals, examples and
description on proper use and just go ahead and do what seems to work.
Actually this is not just a gpg thing: I have seen too many scripts and
programs which neglect to use LC_ALL=C and break as soon as they are
running under a different locale.

To avoid such breakage but keeping friendly to the command line user,
gpg provide a machine interface (--with-colons, --batch, --command-fd)
to make automation easy.

> improving; sometimes that means that older (worse) UI gets deprecated,
> removed, or has its semantics change.

Deprecated, okay.  But I am not aware of semantic changes except for
rare corner cases.

> certain behaviors and features of GnuPG's internal storage (e.g. what
> goes on in ~/.gnupg/), which has never been explicitly part of its API
> (confusingly, there are some exceptions where GnuPG upstream *has*
> encouraged other tools to programmatically interact with some elements

I can't count how often I wrote that the only defined way to access the
content of keyrings are my means of the --export and --import commands.  

Please give examples.

> Simply upgrading GnuPG to the latest available version on a server that
> also ships other complex software is likely to lead to breakage
> elsewhere in the OS because of these brittle assumptions and
> dependencies around GnuPG's UI and internal storage.

Right.  However, this is not due to changing APIs of GnuPG but due to
the wrong use of the API.  Much like we have seen that grep and sed
started to fail on localized systems.

And even today, we see hackers who are breaking working integration of
gpg by replacing the (correct) use of the machine interface by the
supposed easier to use human interface of gpg.  And then encountering
problems with newer versions of gpg.  :-(

> are not part of an explicit, documented API, the ecosystem apparently
> *does* try to manipulate them anyway, with all the attendant brittleness
> that you can imagine.

Right.  That is a bad idea and that is why it took many years to get a
modern version in widespread use.

> that many other projects have taken is to define their core programmatic
> functionality into a library with a strict interface guarantees, and

Library interfaces are as much abused as command line interfaces.  This
is not really the point.  A library may have the advantage that it
exposes only a smaller set of interfaces and thus lessens the risk of
wrong usage.

> have explicitly deprecated other use.  The closest that GnuPG comes to
> this technique is GPGME, which is not feature-complete (as compared to

That is on purpose; see above.

> developers find useful.  Perhaps GnuPG could also itself try to detect
> when it is being used programmatically in an unstable way and produce

Those tools won't notice these warnings because they hide away the
actual output of gpg. 

> Yet another complementary approach might be to aggressively police the
> ecosystem by finding other software that deends on GnuPG in any of the
> aforementioned brittle ways, and either ask those developers to stop

That is what our plan for the time after 2.2 was.  Unfortunately, this
seems to be a boring job for some hackers and thus some of them opted to
leave gnupg to work on cool new stuff instead.  Nevertheless, this is
still high on my task list.

> machines to the latest version of GnuPG doesn't appreciate the scope of
> the problem involved with software maintenance in an active and
> interdependent ecosystem.

Well said.


Salam-Shalom,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180220/7a806cff/attachment.sig>