[00:00] <dkg> fiddling with the innards of GNUPGHOME is pretty much a guaranteed way to make your test suite brittle across GnuPG upgrades
[00:00] <dkg> GnuPG upstream is pretty bad about the fuzzy line between what's expected for machine use, and what bits are stable, on-disk representation
[00:00] <cjwatson> OK, the GNUPGHOME removal thing only works from GnuPG 2.1.22 onward
[00:01] <cjwatson> So if we upgrade to 2 before upgrading to bionic then we'll need the gpgconf trick
[00:01] <dkg> but the general rule of thumb is that aside from the *.conf files, you probably shouldn't expect *anything* in the GNUPGHOME to be stable.
[00:02] <dkg> you'll need to do it for the test suite, i guess.  i don't know enough about the deployed architecture to know whether you'll "need" it in production.
[00:02] <cjwatson> I realise we only got away with this because GnuPG 1.x didn't change a whole lot
[00:03] <cjwatson> The state resetting business is only used in tests
[00:03] <dkg> like i said, GnuPG upstream has been pretty bad at defining a stable API
[00:03] <dkg> the reason 1.x didn't change a whole lot is that it doesn't see much attention from any developers :(
[00:03] <cjwatson> Sure
[00:03] <cjwatson> Though it's possible we might need to make a slight adjustment for production; we do remove GNUPGHOME but on xenial we would need to explicitly kill agents or else they'll pile up indefinitely
[00:04] <cjwatson> There are some situations where we run gpg as part of frequent cron jobs (e.g. verifying uploads) and a gpg-agent process pileup would become a problem
[00:04] <dkg> it only piles up if you have multiple homedirs
[00:04] <cjwatson> Each one creates a temporary homedir
[00:04] <dkg> if you have a single homedir that you use persistently then there's just one process
[00:05] <dkg> again, verifying uploads is *not* a secret key operation
[00:05] <cjwatson> Well OK, signing Release files then
[00:05] <cjwatson> That's also a cron job with similar properties
[00:06] <dkg> gotcha -- not sure why it needs a temporary homedir, but then i definitely don't understand the system architecture
[00:07] <dkg> (fwiw, if you're manually handling all these invocations instead of using gpgme (or its python bindings, python3-gpg), i recommend sticking exclusively with gpgv for all tasks that involve signature verification)
[00:07] <cjwatson> It was a decision from well before my time, but I suspect we wanted to avoid the generic handler code piling up an unboundedly large number of public key files on disk as it verifies stuff
[00:07] <cjwatson> At the moment we use gpgme
[00:08] <dkg> makes sense -- that's the one API that the GnuPG team has committed to (as idiosyncratic as it is)
[00:08] <cjwatson> Via the older pygpgme.  I'd like to switch to python-gpg but haven't got to it yet
[00:08] <dkg> oh, pygpgme is not from upstream, i don't think.
[00:09] <dkg> none of those bindings are particularly pythonic, but the latest stuff from upstream has a bit more of a pythonic wrapper around it
[00:09] <cjwatson> It was written by a Canonical employee
[00:09] <dkg> i'm still annoyed that python-gpg is using swig, which i think is basically a disaster, sigh :/
[00:09] <cjwatson> Although the last two commits are from Werner
[00:14] <cjwatson> Anyway, I know pygpgme is unmaintained, but bear in mind this code has been around for about three times as long as python-gpg has existed :)
[00:16] <cjwatson> So one option is possibly to just get the codebase working with 2.x as an option but then keep forcing 1.x until we have a chance to organise a bionic upgrade
[00:17] <cjwatson> Unless xenial's can be made minimally acceptable
[00:20] <cjwatson> We *can* do independent backports for LP production, but I'm very reluctant to do that because it means we have to track security updates ourselves and we aren't super-good at that
[00:20] <dkg> i'd love to see xenial's GnuPG 2.1.x situation cleaned up, but i don't have the bandwidth to do it myself.  there are several unaddressed issues with the version there :/