| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| dkg | gotcha -- not sure why it needs a temporary homedir, but then i definitely don't understand the system architecture | 00:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:14 |
| 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:16 |
| cjwatson | Unless xenial's can be made minimally acceptable | 00:17 |
| 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 :/ | 00:20 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!