Please remove MacGPG from gnupg.org due to serious security concerns

Tue Feb 17 17:00:50 CET 2015

I’ve had some concerns about GPGTools for months now. For some time I've disliked the way the project is being run, the communication of what they are planning and the way they have been doing their development for example. Months went by when their Yosemite betas were not available in source at all and development was happening in a separate repository closed from the public [1].

GPGTools makes an installer, GPG Suite, which provides the following:

- GPGMail (plugin for Apple Mail)
- GPG Keychain (GUI tool for generating and managing keys)
- GPGServices (OS X Services menu tools for OpenPGP actions)
- GPGPreferences (OS X preferences GUI for some options (gpg.conf)
- MacGPG2 (Fork of GnuPG 2.0.26)

I happen to use Mail so for a long time I’ve been using the GPGMail plugin with a brewed[2] upstream GnuPG. I.e. *just one of the things in the GPG Suite*. I’ve talked about this setup before in the thread [3]. If one doesn’t use Apple Mail there is no reason to use GPGTools at all.

I’ve been planning on writing a request to http://support.gpgtools.org for downsizing / pivoting the project. I just haven’t gotten around to it yet.

MacGPG: Years back there was no easy way of getting upstream GnuPG working on a Mac. As I recall there were a couple of ports making a working Mac version and MacGPG was / evolved from one of them. Today the situation is very much different. Anyone can easily install either 1.x or 2.0.x via brew or another preferred method of installing their command line tools. *I think there is no more reason to develop MacGPG*, i.e. a port, anymore. Let the port die.

Instead they should use upstream and contribute the minimal amount of wrappers or fixes upstream. Case in point: Has the fix for gpg-agent / scdaemon hang been discussed upstream at all [4], [5]? In MacGPG there is still ../libexec/gnupg-pcsc-wrapper which has been modified in commit f4c3e1bb to fix the issues of scdaemon hanging in Yosemite [6]. GnuPG proper has removed it in bc6b45 [7]. How would one go about fixing this issue for upstream? Has GPGTools contributed anything regarding this other than the initial discussion[8] about the issue? Upstream still does have the issue which now seems to have been fixed in the fork but in a binary removed from upstream…

Many times when a new version of OS X comes out GPGTools has been a little late in getting a compatible version out. GPGTools are planning to move to a paid release of GPG Suite [9]. Whether it’s paid or not, my suggestion for GPGTools is to drop MacGPG and start using an upstream version in the Suite.

There are a lot of users out there that will not fiddle with command lines, brew or otherwise. And for them there needs to be a GUI package. Quoting from GPGTools support regarding paid support [10], "non-power-users that were partially even surprised, that email does not imply webmail”. "I hope you are aware of the social responsibility that comes with running the official website for gpg on OS X.”.

So, *"official website for gpg on OS X"* according to this user critical of making discontinuation of a free version.

There is a real problem here in that whatever GPGTools does, affects a large population of Mac users as the "official GPG on Mac”.

There is a history of problems regarding GPGTools and MacGPG. This is not the first time that project or decisions of its developers has been questioned [11]. Here’s one:

1. Modify source code to allow non-sensical 8192 bit keys [12].
2. Have users wonder, at gnupg-users, years later why things don’t quite seem right [13].

Another: GPGTools support site has a certificate mismatch [14]. WTF is a *.tenderapp.com cert doing here?

GnuPG provides a GUI for Windows in addition to the set of command line tools. On *NIX official builds are command line only. I think the GUI tooling of not only Mac but other *NIX systems to be quite an important factor in getting wider use for encryption. Such tools must be from a respectable source and properly implemented just as much as the underlying engine. I would argue GnuPG should take the responsibility of such tooling where there isn’t a good option. Other *NIX systems are doing fairly well already so I suppose a Mac GUI would really be the urgent one.

And I’m willing to put my time and effort where my mouth is. I would be happy to participate such a project.

Links:

[1]: http://support.gpgtools.org/discussions/problems/24976-how-to-build-yosemite-branch
[2]: http://brew.sh
[3]: http://lists.gnupg.org/pipermail/gnupg-users/2014-August/050677.html
[4]: http://support.gpgtools.org/discussions/problems/28634-gpg-agent-stops-working-after-osx-upgrade-to-yosemite
[5]: https://gpgtools.lighthouseapp.com/projects/66001/tickets/140-gpg-agent-stops-working-after-osx-upgrade-to-yosemite
[6]: https://github.com/GPGTools/MacGPG2/commit/f4c3e1bbf1c96cf03ad33a364ec10365f68bf63f
[7]: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=bc6b452129178658da7241903ca2174c79281752
[8]: http://lists.gnupg.org/pipermail/gnupg-devel/2015-January/029345.html
[9]: http://web.archive.org/web/20150206164802/https://gpgtools.org/news
[10]: http://support.gpgtools.org/discussions/beta-feedback/640-discontinuation-of-free-version-for-yosemite
[11]: https://lists.gnupg.org/pipermail/gnupg-users/2014-July/050321.html
[12]: http://lists.gnupg.org/pipermail/gnupg-users/2011-February/040655.html
[13]: http://lists.gnupg.org/pipermail/gnupg-users/2015-January/052141.html
[14]: https://www.dropbox.com/s/crsg7ofrqb0l7ri/Screen%20Shot%202015-02-17%20at%2014.39.10.png?dl=0

--
Ville

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20150217/03fe97eb/attachment-0001.sig>