[00:00] fiddling with the innards of GNUPGHOME is pretty much a guaranteed way to make your test suite brittle across GnuPG upgrades [00:00] 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] OK, the GNUPGHOME removal thing only works from GnuPG 2.1.22 onward [00:01] So if we upgrade to 2 before upgrading to bionic then we'll need the gpgconf trick [00:01] 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] 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] I realise we only got away with this because GnuPG 1.x didn't change a whole lot [00:03] The state resetting business is only used in tests [00:03] like i said, GnuPG upstream has been pretty bad at defining a stable API [00:03] the reason 1.x didn't change a whole lot is that it doesn't see much attention from any developers :( [00:03] Sure [00:03] 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] 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] it only piles up if you have multiple homedirs [00:04] Each one creates a temporary homedir [00:04] if you have a single homedir that you use persistently then there's just one process [00:05] again, verifying uploads is *not* a secret key operation [00:05] Well OK, signing Release files then [00:05] That's also a cron job with similar properties [00:06] gotcha -- not sure why it needs a temporary homedir, but then i definitely don't understand the system architecture [00:07] (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] 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] At the moment we use gpgme [00:08] makes sense -- that's the one API that the GnuPG team has committed to (as idiosyncratic as it is) [00:08] Via the older pygpgme. I'd like to switch to python-gpg but haven't got to it yet [00:08] oh, pygpgme is not from upstream, i don't think. [00:09] 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] It was written by a Canonical employee [00:09] i'm still annoyed that python-gpg is using swig, which i think is basically a disaster, sigh :/ [00:09] Although the last two commits are from Werner [00:14] 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] 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] Unless xenial's can be made minimally acceptable [00:20] 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] 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 :/ === Eickmeyer[m] is now known as eickmeyer[m] === eickmeyer[m] is now known as Eickmeyer[m] === Eickmeyer[m] is now known as eickmeyer[m] === eickmeyer[m] is now known as Eickmeyer[m] === tomreyn_ is now known as tomreyn