Why Operating Systems don't always upgrade GnuPG [was: Re: How can we utilize latest GPG from RPM repository?]

[Ben McGinnes]

On Mon, Feb 19, 2018 at 10:45:52AM -0800, Daniel Kahn Gillmor wrote:
> 
> How can GnuPG contribute to fixing this problem?  The traditional way
> that many other projects have taken is to define their core programmatic
> functionality into a library with a strict interface guarantees, and
> have explicitly deprecated other use.  The closest that GnuPG comes to
> this technique is GPGME, which is not feature-complete (as compared to
> the gpg executable), and has its own history of both difficult upgrades
> and unclear/surprising semantics.

True, but what it does have available still covers a *lot* of what
people do mainly want to access programmatically.  My trusty key
counter is now done that way (it takes a while to run, but that's due
to the size of the keybox, not due to GPGME).

> It also doesn't have bindings in many popular programming languages.

There is a cunning plan which may provide a bridge to at least in part
address that.

> When programmers in those language want to use GnuPG, their shortest
> path to "something that works" often involves shelling out to gpg,
> rather than binding to GPGME. :/

Yes....

> Another thing that would help would be to explicitly and succinctly
> document the preferred ways of interacting with GnuPG in ways that other
> developers find useful.

That would be brilliant, but it requires convincing developers to not
simply document their work, but to actually step back from their
focussed POV and abstract what they're intending to do so we can
determine what will actually be useful to procide all developers.
Otherwise we'll just end up with a bunch of feature requests specific
to the problem each developer happens to be working on at the time
they notify us.

If you can work out a way to get engineers to understand why that's
important ... you'll become very rich shortly thereafter.  ;)

> Perhaps GnuPG could also itself try to detect when it is being used
> programmatically in an unstable way and produce warnings?

Most of the worst of those examples are in bash, how're you going to
tell the difference between that and a user?

> 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 using GnuPG entirely, or to provide them with stable,
> well-supported ways to do what they're looking to do.

And people accuse me of being combative!  Wow ... you're brave ...

Moreseriously, though, let's besure we've got an alternative method to
replace whatever their pet project's method is first.

Arguably gpgme-tool might already do that, but we'll see.

> I welcome discussion/suggestions on how we can improve this situation,
> and i *definitely* welcome help in doing the kind of
> ecosystem-perspective work necessary to make it easier to maintain an
> up-to-date branch of GnuPG.

I'm already laying the groundwork on the API side of things, as well
as working on doumentation.

> But shrugging and suggesting it's uncontroversial to upgrade arbitrary
> 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.

Indeed.  I didn't check your buglist ... but I did recall that one of
the dependencies of GMIME is GPGME.  Pretty sure that'll affect a few
packages and libgcrypt & libgpg-error are a dependencies for lots things.

It's exactly this sort of thing which led to the popularity of
installing things the users wanted in /usr/local or /opt or wherever
specifically to prevent the end user use case adversely affecting the
system's use case.


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-users/attachments/20180221/e276a5e0/attachment.sig>