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
signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users