New: MilkyTracker (Feb 22, 2024), Platform 29.1.1 (Feb 08, 2024)
1,000+ portable packages, 1.1 billion downloads, Please donate.
Now Accepting Wire Transfers, Testing Ad Placements
Due to a significant change in methodology a new thread was started here
Sorry for any confusion.
If a mod could lock this thread I would appreciate it. Thank you.
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'
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.
My current design
FooPortable.exe calls GnuPGPortable.exe
GnuPortable Spawns no children and hence any environment variables are not inherited by anything.
I did it this way so that FooPortable is still responsible for launching foo.exe to maintain the working directory. If FooPortable.exe calls GnuPGPortable.exe with "x:\PortableApps\FooPortable\App\Foo\Foo.exe" so that GnuPG may spawn it and thereby have foo inherit the environment variable then foo.exe is in the working directory of GnuPGPortable instead of FooPortable. Which would reek havoc with inis and plugins and data etc.
Soooooooo...... Registry can be set by GnuPGPortable and Environment vars must be set by FooPortable. Perhaps I make a create a GnuPGPortable.nsh to just include into any FooPortable.exe project. Cover as many bases as possible.
Gotta run home right now. I will post what I currently have packaged in about 2 hours time.
Key ID: 0xDAE3095F
Fingerprint: 5D98 65D2 1844 21A5 76C1 F0F6 4BE6 D689 DAE3 095F
You're doing it exactly backwards from the way I was talking about, and at first thought it appears overly complex to me. Instead of inserting the environment at the beginning or root of the inheritance tree, you are trying to insert it into each branch that needs it at the leaf nodes.
If the GNUPGHOME environment variable will work with the various tools, it is much simpler and safer to set it at the beginning and let things inherit, rather than twiddle with the registry. As I mentioned, if GNUPGHOME is in the environment, then gpg.exe only reads (and ignores) the registry, so the registry could remain set pointing to a local key file. If the power fails, the environment variable technique requires no cleanup.
If you can identify a tool or application that can't or won't use GNUPGHOME, then maybe the more complex method you outline is justified. (It is clever.) On the other hand, if 9 launchers could set GNUPGHOME and have everything work, while the tenth needed your program to initialize the registry, it would still be simpler to use GNUPGHOME in the other cases.
What I have uploaded was what I wrote before I was aware of any standardization of GNUPGHOME. I agree that the method I devised at the time is a little complex .
So if I understand you correctly you are suggesting that each fooPortable sets up the path and GNUPGHOME for itself?
Or, with respect to the environment variables, do portable apps launchers inherit from the PAM (or whatever other menu)? In which case setting the Env there would be cleanest but fails to care for the case that someone launches an app without going through PAM (or whatever launcher)
Well, WinPT in its current incarnation is breaking all the rules for Portability. So to portablize it we'll need to do some work.
But I'm finding (hoping) that other things can work with things like environment variables and such.
As for where they get set: I'd like them to be set at the startup of Portable Apps, so everything has the same starting place. John would have to decide on that. But each fooPortable could go through the steps of figuring out the paths on its own, starting with reading GNUPGHOME and seeing if gpg.conf or secring.gpg are present, and go from there. (I'm thinking we'd check GNUPGHOME, ThunderbirdPortable\Data\gpg, CommonFiles\Data\GnuPG, and fooPortable\Data\GnuPG, in that order.) If the startup app has set GNUPGHOME and the others, the check will go pretty quickly. And we could always have a way to override it with an INI.
Well, that would work if the environment is set up by PAM, but until that gets straightened out, we'd probably have to skip reading the environment, in case the host computer set it. But the launcher could still SET the environment it passes along to foo.exe, after validating it and fixing it up, so even if the host has it set to something local, when foo runs it would have the portable version.
If something comes along and doesn't honor the GNUPGHOME or path and starts messing with the registry or appdata (like WinPT, sigh), that won't bother the portable apps that do honor them, since they ignore the registry. Something might come along that is in yet another category, which is why I think we should catalog apps that are likely to use GPG and start checking them out.
I've got the link on the main post now. As detrimental as an affectionate cat is to laptop computing, an affectionate pit bull is even worse!
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.
ok, So I've looked at the GnuPG install script and I don't see any environment variables being set (path or GNUPGHOME), just the reg keys. I Did find this thread regarding reg vs env. And while I have not yet found if this became official it would seem that Both Reg and Env sets would be needed to ensure max compatibility with all possible apps. I too will continue to investigate. Thank you for your help.
Well, my testing seems to indicate that the registry is read, but that GNUPGHOME is honored in the current version. I suppose I could have missed some combination. We'd probably have to go delving into the source code and change log to be sure.
We'd only have to pre-set the Registry if we come across a program that doesn't honor the environment variable and can't cope without the Registry.
Note that setting the Registry so fooP.exe can find gpg.exe, or gpg.conf, is a slightly different case from where foo.exe writes files all over the hard drive and puts its own settings into the registry, though both need to be cleaned up by the launcher. (When are we going to get our own wrapper that intercepts Registry reads and writes and can replace them with Portablized values...)
I'm not surprised that GnuPG doesn't modify the PATH or set GNUPGHOME. I do know that GPG4WIN adds its "wrapper" versions (gnupg\pub) to the path, which mess up some command line programs that are expecting the real gpg.exe and not a wrapper with the same name. At any rate, most users wouldn't know to set GNUPGHOME or need to add GPG.EXE to the PATH.