tag:gpgtools.tenderapp.com,2011-11-04:/discussions/beta/920-macgpg2-beta6-and-enigmail-18GPGTools: Discussion 2015-11-05T22:45:38Ztag:gpgtools.tenderapp.com,2011-11-04:Comment/363613072015-03-28T20:08:15Z2015-03-28T20:08:15ZThunderbird and Enigmail in combination with MacGPG2 2.0.27 does not find gpg<div><p>Hi MacUser,</p>
<p>I tested this with 31.5.0 and Enigmail 1.8.1 and latest GPG
Suite beta6. Sending encrypted and signed mails worked as did
decrypting and verifying incoming mails.</p>
<p>Please post your versions. But basically this indeed would be a
bug you probably should report to enigmail: <a href="https://www.enigmail.net/support/index.php">https://www.enigmail.net/support/index.php</a></p>
<p>All the best,<br>
steve</p></div>Stevetag:gpgtools.tenderapp.com,2011-11-04:Comment/363613072015-04-03T19:15:36Z2015-04-03T19:15:37ZThunderbird and Enigmail in combination with MacGPG2 2.0.27 does not find gpg<div><p>I have same problem. I installed GPG2 beta 6 in response to
warning from Enigmail about having to upgrade from 1.4. Did so, but
it still complains.</p>
<p>Turns out, /usr/local/bin/gpg is still the 1.4 version. Found
GPG2 under /usr/local/MacGPG2 but it didn't remove the old version.
I assumed it would do so... do I need to uninstall version 1.4.7
somehow?</p></div>Philtag:gpgtools.tenderapp.com,2011-11-04:Comment/363613072015-04-04T08:25:45Z2015-04-04T08:25:46ZThunderbird and Enigmail in combination with MacGPG2 2.0.27 does not find gpg<div><p>No, you just need to update the enigmail preferences to point to
/usr/local/MacGPG2/bin/gpg2 instead. GPG 2.x has always been able
to be installed alongside 1.4.x.</p></div>Bentag:gpgtools.tenderapp.com,2011-11-04:Comment/363613072015-04-04T16:06:12Z2015-04-04T16:06:12ZThunderbird and Enigmail in combination with MacGPG2 2.0.27 does not find gpg<div><p>Tried that. It complained "Can't run GPG from there"</p>
<p>—<br>
Sent from my phone</p></div>Phil Watsontag:gpgtools.tenderapp.com,2011-11-04:Comment/363613072015-04-04T16:52:52Z2015-04-04T16:52:52ZThunderbird and Enigmail in combination with MacGPG2 2.0.27 does not find gpg<div><p>Then make a symbolic link to it in /usr/local and point to that,
so:</p>
<pre>
<code>ln -s /usr/local/MacGPG2/bin/gpg2 /usr/local/bin/gpg2</code>
</pre>
<p>Then point Enigmail to /usr/local/bin/gpg2 instead. If that
still<br>
doesn't work then replace the sym link with a bash script like
this:</p>
<pre>
<code>#!/bin/bash
exec /usr/local/MacGPG2/bin/gpg2 "$@"</code>
</pre>
<p>Then make it executable:</p>
<pre>
<code>chmod 755 /usr/local/bin/gpg2</code>
</pre>
<p>You might need to create the file somewhere else and copy it
into<br>
/usr/local/bin with the sudo command. You will definitely need to
use a text editor which adheres to POSIX file standards like Nano,
Vim or<br>
Emacs.</p>
<p>So the sym link will be easier, try that first.</p></div>Bentag:gpgtools.tenderapp.com,2011-11-04:Comment/363613072015-04-06T16:26:02Z2015-04-06T16:26:04ZThunderbird and Enigmail in combination with MacGPG2 2.0.27 does not find gpg<div><p>Ok,<br>
I was having the same problem, I tried this with the sym link and
that seemed to work.</p>
<p>I also assumed (just like Phil above) that the install would
have removed 1.4. AND, this is a minor nit to keep my email
secure.</p>
<p>Thanks for all the hard work!</p></div>Darrentag:gpgtools.tenderapp.com,2011-11-04:Comment/363613072015-04-06T18:47:07Z2015-04-06T18:47:07ZThunderbird and Enigmail in combination with MacGPG2 2.0.27 does not find gpg<div><p>Version 1.4.19 is still quite secure, just as secure as 2.0.27
in fact.<br>
It does not, however, utilise gpg-agent and pinentry at all so
there's no native caching of passphrases. It has also been more
easily utilised<br>
by servers for various purposes (most commonly package management
or<br>
operating remailers). Since the binaries produced when compiling it
do<br>
not clash with the names of any produced by 2.0 and above or
their<br>
dependencies, there is no reason to require its removal and so
many<br>
people operate both.</p>
<p>My current configuration, for example, utilises both, albeit
with a bit<br>
of customisation:</p>
<ul>
<li>Customised source of GPG 1.4.19 compiled to /usr/local/bin and
renamed gpg binary<br></li>
<li>Bash script of /usr/local/bin/gpg1 to call GPG 1.4.19 with an
explicitly set alternative home directory at ~/.gnupg1<br></li>
<li>GPG Suite beta installed to /usr/local/MacGPG2 as normal for it
<-- largely unused, primarily retained for running training
sessions<br></li>
<li>GPG 2.1.2 and dependencies in custom directory
/usr/local/gnupg-2.1 for testing alternative configurations <--
not live, has a tendency to break<br></li>
<li>GPG 1.4.19 installed from standard source via MacPorts in order
to maintain library dependencies within /opt/local<br></li>
<li>GPG 2.1.2 and dependencies installed from source via MacPorts,
binary at /opt/local/bin/gpg2<br></li>
<li>Bash script of /usr/local/bin/gpg to call GPG 2.1.2 with an
explicitly set alternative home directory at ~/.gnupg2<br></li>
<li>Bash script of /usr/local/bin/gpg2 to call GPG 2.1.2 with an
explicitly set alternative home directory at ~/.gnupg2 and also
restart<br>
dirmngr so it can be launched with proxychains to direct all
keyserver<br>
requests through a proxy server (this sends it all through Tor
to<br>
prevent traffic analysis to determine whose keys I'm
requesting)<br></li>
<li>A symbolic link of the default home directory location pointing
to the current for 2.1: ln -s $HOME/.gnupg2 $HOME/.gnupg</li>
</ul>
<p>Additional things dependent on the above:</p>
<ul>
<li>Thunderbird + Enigmail with Enigmail configured to call the
shell script at /usr/local/bin/gpg (no need to reset dirmngr each
time, just<br>
long as I tweak its launch status with each login)<br></li>
<li>The source of GPG 2.1.2 was modified in a manner similar-ish to
1.4.19 prior to the final build.<br></li>
<li>Due to a problem with the way 2.1.2 performs network
connections, the keyservers are presently limited to accessing
ipv4.pool.sks-keyservers.net<br></li>
<li>$HOME/.gnupg2 was originally a copy of the first (and for a
long time only) ~/.gnupg directory, they're kept separate to
prevent unexpected<br>
conflicts from changes in file types with key storage.</li>
</ul>
<p>So let's see, that's two installations of the 1.4 series,
one<br>
installation of 2.0, one (working) installation of 2.1, a sandbox
for<br>
playing with things and none of it conflicts with the rest.</p>
<p>Obviously that type of configuration goes way above and beyond
the needs<br>
of many users, but it does illustrate how readily the different
series<br>
can work together. It's unlikely to be a permanent scenario anyway.
I<br>
expect it will only be another 5 to 10 years before everyone
has<br>
migrated to 2.1 as it is the only series to reliably support ECC
keys<br>
and that shift will start relatively soon. Hell, I'm only waiting
until<br>
there's a non-NIST, non-Brainpool curve which provides encryption
as<br>
well as signing. Though I am quite happy with my current
RSA/RSA/ELG key.</p></div>Bentag:gpgtools.tenderapp.com,2011-11-04:Comment/363613072015-06-25T11:12:16Z2015-06-25T11:12:16ZThunderbird and Enigmail in combination with MacGPG2 2.0.27 does not find gpg<div><p>We won't remove existing user installations for good reasons.
Also as explained by Ben, gnupg 1 and 2.0 can peacefully
co-exist.</p>
<p>Thanks Ben for your input on this one!</p>
<p>Is anybody still having issues with this or can I close this
discussion?</p>
<p>All the best,<br>
steve</p></div>Steve