setting up the component architecture overwrites $GNUPGHOME due to gpghandler isolating itself

[Michael Hudson-Doyle]

Observe:

>>> from canonical.launchpad.scripts import execute_zcml_for_scripts
>>> import os
>>> os.environ.get("GNUPGHOME")
>>> execute_zcml_for_scripts()
>>> os.environ.get("GNUPGHOME")
'/tmp/gpg-L49Hue'

This does not seem like a feature.

This is because canonical.launchpad.utilities.gpghandler.GPGHandler is a registered utility, and registering a utility instantiates the class being registered and GPGHandler.__init__ is what sets $GNUPGHOME. I don't know what gpghandler is intended for so I can't really say how this might be fixed, and it's not that hard to work around. But it's still horrid.

[Celso Providelo (cprov)]

Hi Michael, the GNUPGHOME is set on initialization because it needs to point to a special configuration file prepared for LP needs (for instance, it uses auto-key-retrieve option). So, it is indeed a feature, although, I admit it's not explicitly documented in any of the related tests. So, if it's only about documentation, feel free to edit the description and tag the bug appropriately.

[Francis J. Lacoste (flacoste)]

Another solution was that the GNUPGHOME environment be set and reset to its original value in all methods in the utility. (So only when GPG calls requiring the special configuration be made). This could be easily implemented using a method decorator which sets the env variable before calling the method and resettting it afterwards.

[Celso Providelo (cprov)]

I like the decorator idea as in +0, I don't see much point in dereferencing a environment variable if the component using it is still alive. I mean, something is wrong if you have to decorate all methods of a class to make them work, right ? Moreover what would be the point of reseting that is not used anywhere, since GPGHandler can't and shouldn't be parallelized ?

[Francis J. Lacoste (flacoste)]

The idea here is that the existence of the utility shouldn't affect the global setting that is GNUPGHOME.

Using that pattern would make the utility more robust. If code changes GNUPGHOME for whatever legitimate reasons, it actually breaks the utility.

[Celso Providelo (cprov)]

Right, I see you point now, a decorator that sets GNUPGHOME env var to the utility value, run the method and restore it's original value.

That's indeed more robust. Thanks for the explanation and sorry for the noise.

[Michael Hudson-Doyle (mwhudson)]

Why was this marked invalid? It still happens.