Home → Stable →

Security issues about GPG Suite raised on GnuPG users forum

• Edit

Pertinax77

17 Feb, 2015 12:03 PM

Hi

You might be interested in the following post by Jonathan Schleifer to the GnuPG users forum that raises concerns about the security practices of your development team:

I hereby request that MacGPG gets removed from gnupg.org due to serious security concerns. Basically, the first thing the Makefile in all >their repos / tarballs does is this:

  @bash -c "$$(curl -fsSL https://raw.github.com/GPGTools/GPGTools_Core/master/newBuildSystem/prepare-core.sh)"

So you type make not expecting anything bad (you verified the checksum and everything), but you just executed remote code. Great. >And they even hide it from you by prefixing it with @, which is downright evil. So you never notice unless you look at the Makefile. >Currently, that script clones another common repo using the unverified git:// protocol (because, why use submodules if you can do it in >an insecure way?), but obviously, that can change any minute and could change just for certain IPs etc.

The developer(s) don't allow any issues on GitHub, so I tried contacting them by other means (e.g. Twitter), only to get ignored. They >clearly don't care about security.

In any case, somebody who does something like this clearly doesn't care about security the least. The potential for backdoors is >extremely high and I think nobody should be using any software written by this developer / these developer(s), as they clearly >demonstrated that they couldn't care less about your security.

I don't feel comfortable that the majority of Mac users are using this software which doesn't care for security at all, but is used for >extremely security sensitive tasks. I guess this is because gnupg.org recommends it and therefore people think it's safe. I think >gnupg.org should do the contrary instead and strongly discourage using it."

1. Support Staff 1 Posted by Steve on 17 Feb, 2015 10:23 PM

   

   Hi Pertinax,

   thanks for bringing this to our attention.

   here's our reply to the gnupg users list:

   ---

   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 [email blocked].

   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-genera...

   • Edit

2. Steve closed this discussion on 02 Jun, 2015 11:56 AM.