GnuPGPortable

Since environment variables are inherited, they can be made (are) temporary for applications without "putting them back" or anything. The environment is only valid for programs called by the program (launcher) that sets the environment variable. No other program can see the environment. Setting an environment variable for one program does not set it for any other. It's inherently ephemeral and thus ideal for portable apps.

The issue is to figure out when the environment variable overrides less ephemeral things like registry entries. You'd think the developers would figure out that a registry entry (e.g. HKLM) is relatively "fixed", whereas an environment variable can be ephemeral, so the ephemeral would be used to override the fixed or default value; but sometimes the developers take a more fascist approach and say that the entry in the HKLM has to be correct and nothing can override it. (That makes a bit of sense if it is in the Policies section, but not otherwise.)

The same applies to program parameters or command line arguments. You'd think that they could be used to override registry entries, yet sometimes they don't.

You should also be able to figure out how the precedence is set up -- does a command line parameter take precedence over a registry entry or environment variable (or ini file, for that matter)? Some programs can use any of the four, but the issue is which one gets used if the others are there.

Last time I looked, GNUPGHOME is honored by Thunderbird/Enigmail.

In NSIS, the "launcher" (or whatever launches the launcher) could set an environment variable like this:

System::Call 'Kernel32::SetEnvironmentVariableA(t, t) i("GNUPGHOME", "$1\Data\GnuPG").r0'
System::Call 'Kernel32::SetEnvironmentVariableA(t, t) i("GTK_BASEPATH", "$1\GTK").r0'
ReadEnvStr $2 PATH
System::Call 'Kernel32::SetEnvironmentVariableA(t, t) i("PATH", "$1\GnuPG\app;$2").r0'
; etc
Exec `"$EXEDIR\App\SomeApp\SomeApp.exe"`

In that situation, SomeApp.exe will be able to "see" the environment variables, but nothing else on the machine will -- unless, for example, SomeApp.exe launches gpg.exe, in which case gpg will also be able to "see" those environment variables because it "inherits" the environment set up by the program that launched it.

The PATH variable is interesting too; if you prepend the GnuPG binary path to it, programs that don't have it "hard-wired" will let the operating system find it, and the OS will use the first one it comes to, namely the one you prepended. So even if another instance is present on the machine and/or on the path, it will find yours first.

Again, the PATH might be overridden by some other setting somewhere, so you have to experiment. And of course there might be Privileges needed to change the environment.

If you can't override the registry settings with either command line or Environment variables, then your strategy is required; but for any app that observes Environment variables, you wouldn't need to. In fact, it could be the case that an app that sees the environment variable set will figure out that there is no need to update or set or look at the registry; but that's probably too much to ask.

Edit 2: silly me, I didn't think they'd change it; it looks like it is now GNUPGHOME not GPG_HOME or GPGHOME or the other things I've seen. sigh.

Edit 3: I've been experimenting with GPG for a while this morning ... the latest one, I hope, since it behaves differently from a previous version I used ... but anyway, if GNUPGHOME is set, and you start GPG.EXE from a different directory than HKLM\Software\Gnu\GnuPG points to, GPG will read the registry entries, but as far as I can see it lets the environment override what it sees in the registry. If the HKLM or HKCU entries are not there, GPG goes along happily and doesn't create them (at least so far). Of course, that doesn't mean that any other program will be as well behaved finding gpg.exe -- if the program freaks if it can't find the registry entries for GPG, then I guess we'd have to make them. So I'd propose that the first task is to identify whether enigma or gpgwin and winpt and others will be able to function if the registry keys are missing, and if they will let the environment override if the keys are set.

Here's what I've found so far.

The GNUPGHOME environment variable, plus putting the right GPG.EXE program on the PATH, result in command line processing working, and Thunderbird working, including the keymanager. No entries seem to be written in the registry, and no files on the filesystem. I've tried a bunch of different combinations, but haven't done an exhasutive search; but so far, it seems well behaved.

All of the things from the gpg4win developers seem to insist on mucking in the registry and writing files in appdata. There is some discussion on their site about setting things up for removable drives, but they say they don't have the resources to do the work.

In other words, this isn't a GPG problem, it is a GPG4WIN problem, unless you know of other applications that use GPG but ignore environment variables or paths, and write data to the registry.

Thunderbird/Enigmail (for example) seems to ignore the registry when the path and environment variable are set, and don't write new settings there. So they wouldn't need to use the initialization scheme you describe.

On the other hand, if you have a handful of different utilities that, like gpg4win, may be run multiple times and write to registry and appdata, your scheme for registering and cleaning up may be required.

I thought I remembered going through this process some years ago with WinPT. WinPT is definitely behaving differently than I remember it. Or maybe I am just remembering it wrong. They say memory is the second thing to go, but I can't remember what the first one is.