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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Reply via email to