Merge ~cjwatson/launchpad:gpg-handle-preload into launchpad:master
Status: | Merged |
---|---|
Approved by: | Colin Watson |
Approved revision: | f7c5413a48179f688334c6f997c12fa6f2e303b9 |
Merge reported by: | Otto Co-Pilot |
Merged at revision: | not available |
Proposed branch: | ~cjwatson/launchpad:gpg-handle-preload |
Merge into: | launchpad:master |
Diff against target: |
306 lines (+91/-60) 4 files modified
lib/lp/services/gpg/handler.py (+11/-47) lib/lp/services/gpg/interfaces.py (+50/-1) lib/lp/services/gpg/tests/test_gpghandler.py (+15/-8) lib/lp/soyuz/tests/fakepackager.py (+15/-4) |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Jürgen Gmach | Approve | ||
Review via email: mp+441142@code.launchpad.net |
Commit message
Defer GnuPG home directory setup to support app preloading
Description of the change
The `launchpad-
There's certainly work we can do to make the behaviour of our `atexit` handlers less surprising with child processes in general, but in the meantime I think it makes sense to ensure that we have a separate GnuPG home directory for each child process even when using application preloading; I doubt GnuPG is completely robust against having multiple processes writing to the same home directory in parallel anyway. We achieve this by deferring setup of the GnuPG home directory until we need to perform an actual GnuPG operation.
I've always been uncomfortable with the way that `GPGHandler` sets `GNUPGHOME` in the process environment; it seems too much like implicit action at a distance. Most of the relevant tools now support passing this in some other way, either via a GPGME engine parameter or via a command-line option, so I've switched to that where possible. There are a couple of cases where this isn't possible, and in those cases I've arranged to set the environment variable in a more localized way.
LGTM with one question