Enigmail / Forum / Enigmail Support: gpg 2.1 for OSX - is it in production (stable) phase or still a kind of beta?

owl77 - 2016-03-12

Hello!

I have issue which is discussed here: https://sourceforge.net/p/enigmail/forum/support/thread/25451a30/#f1e1
Apperantly the issue is caused by the fact that I have both GPGTools and gpg 2.1.11-002 installed on my OSX system. And now I'm trying to decide which one I shall keep and which to uninstall.

My question is - the Modern version of GPG for OSX, available at http://sourceforge.net/projects/gpgosx/ -- is it stable, suitable for "production" environment, or still a kind of experimental, more on development side?

If it's stable I'd keep gpg 2.1. Enigmail contains almost all front-end functionality needed. And it's being maintained much more actively.

Thanks!

Last edit: owl77 2016-03-12

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Rob - 2016-03-12
  
  My question is - the Modern version of GPG, available on
  http://sourceforge.net/projects/gpgosx/ -- is it stable, suitable for
  "production" environment, or still a kind of experimental, more on
  development side?
  
  Given the guy putting together those packages is also the lead developer
  on Enigmail, I think the answer is pretty obvious. :)
  
  I personally use the GPGOSX package on my El Capitan box. Works fine
  for me.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Patrick Brunschwig - 2016-03-13

Gpg for OSX is only a distribution of GnuPG. It is as stable as the underlying GnuPG version. The question is therefore not whether Gpg for OSX is stable or not, but whether GnuPG 2.1.x is stable.

As you say, Gnupg 2.1 is maintained much more actively than Gnupg 2.0. But on the other hand, GnuPG 2.1 is the current development tree, with heavy changes between versions. Almost every new version brings new features - and breaks something. GnuPG 2.0 is less modified because it is stable and works fine.

I personally don't consider GnuPG 2.1 stable enough for regular end users, which is why the Enigmail Setup Wizard still downloads GPGTools.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

owl77 - 2016-03-13

Thank you for your answers!

Maintance activity is the thing that keeps me considering. It's understood that 2.0 is more conservative and though does not need to be updated as frequently as 2.1 with all the modern features. But GPGTools adds extra lag to that. It takes a month or two after new update of gpg 2.0 or libcrypt is published on www.gnupg.org for this update to be included into GPGTools. To support this - 2.0.29 is the current stable version on gnupg.org but 2.0.28 is what's inside current GPGTools. The latter was updated in September 2015, some 6 months ago...

It would be ideal solution for me (and may I suggest - not for me only?) if there's just the same kind of minimalistic package for gpg 2.0 for OSX (with no front end and other utils) as there's available for gpg 2.1. Given it follows gnupg.org team updates released for gpg 2.0 as closely as gpg 2.1 for OSX does - this would be the best choice.

In the absence of such in my personal view it's probably safer to rely on modern 2.1 than on stable GPGTools but with it's long gaps between updates...

Thanks!

Last edit: owl77 2016-03-13

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

owl77 - 2016-03-14

I deleted gpg for OSX 2.1.11 files and symlinks and reinstalled GPGTools. Rebooted. But sadly the problem still persist with the same symtoms! Here's the recommended test commands output:

Last login: Mon Mar 14 23:00:22 on console
aak-mbp:~ aak$ pinentry <<EOT

SETDESC Hello World
CONFIRM
EOT
-bash: pinentry: command not found

aak-mbp:~ aak$ gpg-connect-agent <<EOT

GETINFO version
EOT
D 2.0.28
OK

aak-mbp:~ aak$ gpg-connect-agent <<EOT

GET_CONFIRMATION Hello
EOT
OK
aak-mbp:~ aak$

I'd really appreciate some help. Thanks!

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Olav Seyfarth - 2016-03-14

Apparently, the uninstaller did not remove everything and the installer found some remnants and didn't do the full-fledged install either.

Do I assume right that you don't get any GUI popup from these commands (since "pinenty" is not found)? Please search your drive for pinentry and if there's just a pinentry-gtk (and you may call that from anywhere), then it should be enough to create a symlink "pinentry" to point to that file. Alternatively, put the absolute path to your specific pinentry into .gpg-agent (in GPGHOME).

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

owl77 - 2016-03-14

Thanks! But:
1) the forst test fails but the tird one does open pinentry window;
2) I have full and absolute path to pinentry in .gpg-agent:
pinentry-program /usr/local/MacGPG2/libexec/pinentry-mac.app/Contents/MacOS/pinentry-mac
3) I created symbolic link to pinentry program with command:

sudo ln -s pinentry-program /usr/local/MacGPG2/libexec/pinentry-mac.app/Contents/MacOS/pinentry-mac /usr/local/bin/pinentry

it executed without error and the symlink was created. After that I run the first test again:
pinentry <<EOT
SETDESC Hello World
CONFIRM
EOT

and got a new type of allert:
"Someone tampered with your installation of pinentry-mac! To keep you safe, pinentry-mac exit now!"

the further - the more interesting!

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ludwig Hügelschäfer - 2016-03-14

Hi,

you got the "ln" command wrong - you supplied 3 arguments, but it only requires 2.

GPGTools package doesn't need a link, as it has the standard location of pinentry-mac built in.

Your wrong "ln" command probably modified the internal structure of the code-signed package of pinentry, this is why you get the "tampered" error.

To clear things up, please do the following:

Uninstall the MacGPG package

Clear up fallout from the wrong "ln" command

Reboot

Install MacGPG package again

Test again. Omit the first test, as it will always fail because pinentry binary isn't covered by the path-environment variable, but this is harmless (compared to Linux).

After that: Do you still get the warning in Enigmail?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ludwig Hügelschäfer - 2016-03-14

Addendum: If you still get the warning, please supply the following command:

gpg-connect-agent

and type in the following commands:

/subst /serverpid /echo pid: ${get serverpid} /bye

Which output do you get?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

owl77 - 2016-03-15

Thanks! I did all as advised. Result: the two tests run fine, but Enigmail alert message stays with me. Below is the commands output:

Last login: Tue Mar 15 09:59:12 on ttys000

aak-mbp:~ aak$ gpg2 --version
gpg (GnuPG/MacGPG2) 2.0.28
libgcrypt 1.6.3
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA, RSA, ELG, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

aak-mbp:~ aak$ gpg-connect-agent <<EOT

GETINFO version
EOT
D 2.0.28
OK

aak-mbp:~ aak$ gpg-connect-agent <<EOT

GET_CONFIRMATION Hello
EOT
OK

aak-mbp:~ aak$ gpg-connect-agent

/subst
/serverpid
/echo pid: ${get serverpid}
pid: 846
/bye

aak-mbp:~ aak$

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ludwig Hügelschäfer - 2016-03-15

Ok. Would you please repeat the last step and please record the output number of "pid:". Afterwards, please issue the following:

ps -o comm -p <number from pid>

What's the output?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

owl77 - 2016-03-16

sure, it's done:

aak-mbp:~ aak$ gpg-connect-agent

/subst
/serverpid
/echo pid: ${get serverpid}
pid: 699
/bye

aak-mbp:~ aak$ ps -o comm -p 699
COMM
/usr/local/MacGPG2/bin/gpg-agent
aak-mbp:~ aak$

Last edit: owl77 2016-03-16

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ludwig Hügelschäfer - 2016-03-17

So far, this looks good from command line accessible commands. Now let's see what Enigmail detects. Would you please restart Enigmail, open the preferences, then save the Debug log and send it to me? Thanks!

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

owl77 - 2016-03-17

done! I've sent you the logfile by email. Thanks!

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ludwig Hügelschäfer - 2016-03-19

I can now reproduce your behaviour. Will tell more later.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

owl77 - 2016-03-20

great! very keen to follow down the quest :) thanks!

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ludwig Hügelschäfer - 2016-03-20

Well, the problem is an concatenation of two things: First part: MacGPG doesn't create links for gpg-connect-agent and gpgconf in /usr/local/bin pointing to their binaries in /usr/local/MacGPG2/bin, it relies on extending the PATH environment variable. Second part: For reasons I don't know yet, Thunderbird (and thus Enigmail) doesn't receive this extended path, but the "standard" path (/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin).

As a result Enigmail cannot use gpg-connect-agent and gpgconf and says "Cannot connect to gpg-agent".

If you create symlinks in /usr/local/bin, everything works as expected:

cd /usr/local/bin sudo ln -s /usr/local/MacGPG2/bin/gpg-connect-agent gpg-connect-agent sudo ln -s /usr/local/MacGPG2/bin/gpgconf gpgconf sudo ln -s /usr/local/MacGPG2/libexec/scdaemon scdaemon

The third line is for completeness: You don't need it if you don't have an OpenPGP Smartcard.

Thanks for the patience!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

owl77 - 2016-04-02

Hi! I added the symlinks as you advised and the problem did go away. Thank you for your help!

What steps would be reasonable to ensure this problem will not appear on fresh installations of future versions? the GPGTools installer could create these symlinks automatically. shall I report to GPGTools project or do something else?

Thank you again,
Best regards and cheers!

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ludwig Hügelschäfer - 2016-04-03

Repairing the work of external installers is nothing Enigmail could or should do. Yes, please file a bug at GPGTools.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

gpg 2.1 for OSX - is it in production (stable) phase or still a kind of beta?

OpenPGP addon for Mozilla Thunderbird

Forums

Help

gpg 2.1 for OSX - is it in production (stable) phase or still a kind of beta?

gpg 2.1 for OSX - is it in production (stable) phase or still a kind of beta?

OpenPGP addon for Mozilla Thunderbird

Forums

Help

gpg 2.1 for OSX - is it in production (stable) phase or still a kind of beta? document.SUBSCRIPTION_OPTIONS = { "thing": "topic", "subscribed": false, "url": "subscribe", "icon": { "css": "fa fa-envelope-o" } };

gpg 2.1 for OSX - is it in production (stable) phase or still a kind of beta?