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

Tue Feb 17 22:32:57 CET 2015

Hi all,

since we’ve only now subscribed to the gnupg-users list, unfortunately we can’t reply to the correct message in the thread.

First off we’d like to apologize for not reacting sooner to this issue. We only today became aware of it, when we received a message on our support platform (thanks Sandeep), and later a comment on Github (thanks Hugo) regarding the affected line of code.

While we’re responding to all mail and discussions opened on our support platform, we don’t keep track of Twitter regularly. Some  days we see everything going on there and respond immediately and other days we don't check Twitter at all, so unfortunately it's possible that important messages remain unseen.

The best way to reach us is either our support platform at https://gpgtools.tenderapp.com or team at gpgtools.org.

The code that checks out our GPGTools_Core repository is pretty old already and it’s certainly a stupid way to do it.
At  the time we assumed that it was safe to check it out via ssl from github, since curl would refuse to do so if there was a certificate error. Passing it directly to bash is definitely a bad idea.
We’ve discussed this internally and decided on removing the automated checkout completely.
By making it a manual task, everyone can checkout the code and verify that it’s in fact the code they wanted to checkout.
We will also look through our build system and check for similar code if there is.

To  address the "Modify source code to allow non-sensical 8192 bit keys" mentioned by Villa: in the past we were too quick to give in to user requests without first researching the side-effects that could be caused by this.
The „non-sensical 8192 bit keys“ is one instance. It was requested by a few users and a quick „fix“. We’ve seen that homebrew did the same and decided to add this option. We believed if some users wanted this option, we should not hinder them.
Unfortunately to this day, there still seems to be a lot of disagreement (not on the gnupg list, but other blogs / places on the internet) on whether such a key size makes sense or not. We’ve recently been accused again of "knowlingly lowering the overall security“ [1] by not allowing such a key size.
We’re still not sure what to do about it exactly.

In  regards to the fix of PCSC on Yosemite, this is a quick workaround which currently works „well enough“, but we’re still waiting to hear from more users if it’s really fixed. Once it is, we’ll be certain to discuss it on gnupg-devel.

We’ve been wanting for a while now to discuss our few patches with the gnupg-devel list in order to push them upstream or find a different solution, but unfortunately have been struggling to find time to do that. We also believe that providing gnupg as is on OS X would be the way to go.

To clarify some info posted on this thread about "GPGTools going commercial“: we will only charge a fee for GPGMail, the rest of GPG Suite will remain free. The source code will also remain open and on Github.
It's true we sometimes failed to keep it up to date in the past, but we're committed to make sure that it stays current with new releases.

We really appreciate any feedback and try to address any concerns as quickly as possible. As already mentioned above, it's not always possible for us to keep track of Twitter, so the best way to reach us is via email or our support platform.

Best,

Lukas, Steve, Mento
GPGTools

[1] http://support.gpgtools.org/discussions/feedback/1132-8k-key-generation-via-keychain-access#comment_35220287

Am 17.02.2015 um 20:58 schrieb Sandeep Murthy <s.murthy at mykolab.com>:

> I would also add that if you agree that more people should
> be using encryption in more forms then the way to go is
> to make it more more usable and user friendly (and at the
> moment the standard GnuPG version can’t exactly be described as
> that) then this is not an aspiration that should be described
> as dumb.  What is probably dumb is the kind of purist attitude
> about the perfect Linux platform and how great it is to have
> the perfect GnuPG set up.
> 
> I would bet that more people who’ve used tools like GPG Suite
> have taken up encryption than those exposed to the command
> line subtleties of GnuPG.  Both can be used at the same time,
> as I do, you don’t have to choose between them.
> 
> Sandeep Murthy
> s.murthy at mykolab.com
> 
>> Begin forwarded message:
>> 
>> Subject: Re: Please remove MacGPG from gnupg.org due to serious security concerns
>> From: Sandeep Murthy <s.murthy at mykolab.com>
>> Date: 17 February 2015 19:03:30 GMT
>> Cc: Martin Paljak <martin at martinpaljak.net>
>> To: gnupg-users at gnupg.org
>> 
>> I suppose if you were conceited enough to describe yourself
>> as a “power user” then you might be dumb enough to think
>> that people who use GPG Suite are “dumb users”.
>> 
>> Platform fanatics and those make an easy job of caricaturing
>> themselves in their fanaticism for a “pure setup”, which is an
>> illusion.  In the real world every system can be compromised
>> and no can have such a setup, no matter how hard you try.
>> 
>> You don’t have to choose between OS X and Linux, there are
>> lots of people who use both.
>> 
>> I have both GnuPG and GPG Suite, and I use both when I have
>> to.  As a user, not a developer on MacGPG, the issues previously
>> raised here about the remote execution of scripts etc. may be
>> questionable, but they do not directly affect my use of the software,
>> which is nothing but a front end for GnuPG.
>> 
>> The GPG plug-in for Apple Mail is not without its shortcomings but
>> it is incredibly easy to use and works well the other components
>> of the GPG suite.  I have not used Enigmail, but it’s simply a
>> question of choice.
>> 
>> Sandeep Murthy
>> s.murthy at mykolab.com
>> 
>>> On 17 Feb 2015, at 16:31, Martin Paljak <martin at martinpaljak.net> wrote:
>>> 
>>> On Tue, Feb 17, 2015 at 6:00 PM, Ville Määttä
>>> <mailing-lists at asatiifm.net> wrote:
>>>> 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…
>>> 
>>> 
>>> Not sure about overall GnuPG affection with Apple or other closed
>>> source software, but the PC/SC layer in Yosemite is broken (again):
>>> 
>>> http://ludovicrousseau.blogspot.fr/2014/12/os-x-yosemite-and-smart-cards-known-bugs.html
>>> 
>>> Generally speaking, I think the GPGTools folks care about "usage for
>>> dumbusers" which means making stuff Work(tm) for the not-so-powerusers
>>> on a not-so-great platform. It is the users's choice to use OSX (not
>>> Linux), the same way it is their choice to use Mail.app (not Enigmail)
>>> the same way it is their choice to use a simple to use binary
>>> installer with crappy build machinery instead of verifying the
>>> checksums of every download.
>>> 
>>>> So, *"official website for gpg on OS X"* according to this user critical of making discontinuation of a free version.
>>> 
>>> GnuPG just got a huge sum of money, I'm sure arrangements can be made
>>> to allocate some of that for a easy to use and *free* OSX version with
>>> an integrated GUI ?
>>> 
>>>> Another: GPGTools support site has a certificate mismatch [14]. WTF is a *.tenderapp.com cert doing here?
>>> 
>>> Because that site is run by Tender and if you connect to the https
>>> version, you get their site? Probably makes sense to bug Tender with
>>> this.
>>> 
>>> 
>>> So, generally speaking: if the upstream has not catered to the OSX
>>> folks and somebody on the internet has, I would not blame GPGTools
>>> guys for doing it. Yes, it would be nice if one at least tried to
>>> contribute back to upstream and to work in an open manner, but at
>>> least they DO something, for what there is apparent need.
>>> 
>>> Martin
>>> 
>>> _______________________________________________
>>> Gnupg-users mailing list
>>> Gnupg-users at gnupg.org
>>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

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