[MlMt] gpg2 path?

[Bill Cole]

On 21 Apr 2015, at 13:28, Christopher LILJENSTOLPE wrote:

> Greetings,
>
> 	I've moved off of GPGTools, and am running the current gpg2 tooling 
> from GNU (brew package, if anyone is interested).  However, it seems 
> as if the GPGTools path is stuck somewhere in the system for the path 
> for gpg2.  Any hidden variable where I can change that path?


[CAVEATS: I am not Benny.
           Everything below is conjecture based on a few minutes of 
investigation.
           My advice is worth every penny you've paid for it :)]

The Release Notes say that the path to gpg2 was originally hardcoded to 
/usr/local/bin/gpg2 and later the "default" was changed to 
/usr/local/MacGPG2/bin/gpg2 but there's nothing I can find anywhere 
documenting a way to change or override that default. However, a bit of 
grep work indicates that the places in /Application/MailMate.app/ where 
the strings MacGPG2 and gpg2 occur (in the main binary and the OakMIME 
framework library) are near the string MM_GPG, which appears to be used 
as a variable name based on its context, probably imported from the 
environment (quirky!) This suggests 3 possible approaches, if your 
homebrew binary is at /usr/local/bin/gpg2:

1. Symlink the hardcoded name to the working one:
      sudo mkdir -p /usr/local/MacGPG2/bin
      sudo ln -s /usr/local/bin/gpg2 /usr/local/MacGPG2/bin

2. Set the MM_GPG environment variable via launchctl. There are 2 ways 
to do this:
    a. Manually as needed, once per login session in a Terminal session:
         /bin/launchctl setenv MM_GPG /usr/local/bin/gpg2
    b. In a launchd .plist (in ~/Library/LaunchAgents/) which runs the 
command above every time you log in. The details for constructing a 
launchd .plist file are readily available via 'man launchd.plist'.

3. Set the MM_GPG variable for MailMate with defaults:
      sudo defaults write com.freron.MailMate MM_GPG -string 
"/usr/local/bin/gpg2"


Given the context around 'MM_GPG' in the 2 files it occurs in, my guess 
is that (2) will work but (3) will not. It is unlikely for them both to 
work. (1) will almost surely work, but it is inelegant.