Hacker News new | past | comments | ask | show | jobs | submit login
GnuPG is not a library (mrmekon.tumblr.com)
54 points by morpher on Feb 7, 2013 | hide | past | web | favorite | 48 comments



What we really need is somebody to come along and put together a library to make it easy to use gpg in your application. They could call it "GPG Made Easy," oh wait:

"GnuPG Made Easy (GPGME) is a library designed to make access to GnuPG easier for applications. It provides a High-Level Crypto API for encryption, decryption, signing, signature verification and key management. Currently it uses GnuPG as its backend but the API isn't restricted to this engine; in fact we have already developed a backend for CMS (S/MIME)."[1]

[1] http://www.gnupg.org/related_software/gpgme/


From the article:

    > The GnuPG folks eventually realized that, and released GPGME.  GPGME is
    > basically the GnuPG application compiled into a library.  This certainly makes
    > it easier for desktop applications to tie into GnuPG, but it still requires the
    > ability to build the GnuPG application for your target.  Because GnuPG is quite
    > large, not particularly modular, and designed for a POSIX build environment,
    > this still isn’t the best answer for embedding PGP functionality in small
    > devices.


+9999999[...] When such posts make it to the front page is shows the sheer ignorance and lack of will to even make a Google search. (purists could argue that gpgme is far from perfect tho).

What's needed is actual good implementations of the clients. That's all really. The command line client is not perfect but its FINE. It's fast, it works, it does what it says.

The other clients sucks hairy balls.

People also fail to realize that to date, the PGP trust model is the only freaking viable trust model, because it's distributed, free, and the trust choice is up to the _user_ (and it happens to also have been around for more than a decade, that never hurts).

There's actual implementations of PGP/GPG for website authentication and transport encryption. There's implementations for package signing that _actually_ make use of the trust model (www.archlinux.org).

There's PGP SmartCards that are _way_ more secure than this little OTP token in your pocket, and it works for SSH too. But wait, there's more. It works for SSH authentication _using_ the trust model too (web.monkeysphere.info).

Oh, and last but not least GPG supports ECDSA, too. All this to say that PGP and the GnuPG implementation have a huge, underexploited potential, and that's probably due to ignorance.


Really? You want to give a million points to a comment that blatantly ignores the article to propose a solution that was discussed and shot down halfway through?

You disappoint me.


When such comments make it towards the top it shows the sheer ignorance and lack of will to fully read a linked article.

Either read the article and comment on it, or don't read it and avoid commenting.


A million points is nice! It's like winning the lottery and giving it away is still free.


Doesn't GPGME still wrap the executable and parse its output? If so, I would call it a wrapper rather than a library.

As an example GPG saves its keys in a file. What if you want to put them in a database? Does GPGME allow a developer to do this?


Originally I wrote:

"Does gpg allow you to export and import keys?"

Based on the comment below it seems my sarchasm was not evident. I should have written:

"Are you asking if gpg can import or export keys?"


EDIT: Ah ok, sorry English is not my native language, so I didn't get the sarcasm at first :)

Export a public key: gpg --export -a "UserName" > public.key

Export a private key: gpg --export-secret-key -a "UserName" > private.key

Import a public key: gpg --import public.key

Import a private key: gpg --allow-secret-key-import --import private.key


See my response to the parent. As the OP mentions iphone support in the first two sentences, so, it is a bit disingenuous to suggest that gpgme (which simply wraps the gpg executable) is a solution and that "sheer ignorance" and "lack of will" are the only reasons anyone would suggest this was an interesting article.


> There's PGP SmartCards that are _way_ more secure than this little OTP token in your pocket, and it works for SSH too. But wait, there's more. It works for SSH authentication _using_ the trust model too (web.monkeysphere.info).

I've been looking for those. I can only find one from g10code / kernelconcepts.de - which is fine, but is exactly ONE vendor. The other one I found is the Yubikey NEO - less than two month old, and sold out for the next 2 months at least. Are there any other implementations that I'm missing? (Don't get me wrong - I've ordered from kernelconcepts before. But I don't like to be dependent on a single vendor)

> Oh, and last but not least GPG supports ECDSA, too.

True. Do you know if the PGPcard standard is supposed to be updated to support ECDSA too? Some standard require signing or encryption keys to be in an independent hardware module.


I have played with the idea of making a GPG applet for the JavaCard platform. It's rather easy (I have a half-done prototype somewhere that used to work with an old version of GnuPG), but the lack of market didn't make it worthwhile pursuing this beyond the prototype stage.


Even reasonable JavaCards don't appear to be easily available. I was really surprised when I started looking into these things - I was expecting the improved security afforded by these cards to be easier to come by and use.


GPGME is far from ideal. As papaf mentions, it simply wraps the gpg binary. If you have an environment (e.g. an iphone) where running external binaries is not allowed, then GPGME cannot be used.

To me, the whole idea of wrapping an executable with a library is completely backwards. The executable should do nothing but provide a command-line interface to a library.

I think there is definitely room for a reimplementation of gnupg inverted in this sense (similar to how libgit2[1] is currently reimplmenting git).

[1]: http://github.com/libgit2/libgit2


maybe, just maybe, that environment is deeply flawed if it does not allow to run an external binary (but allows to run arbitrary code in libraries).

your other point is also not that convincing. smallish binaries usually have a very clear api. they can be called from every programming language without much effort.

coming back to pgp: you usually do not parse the same message over and over again. so you do not need to have any shared state for caching between calls to that executable.


There is also a Python based "gpglib"[1] which currently is able to parse and decrypt GPG messages. All heavy lifting is done via PyCrypto so its quite fast.

[1] https://github.com/hitwise/gpglib


If you just need to do crypto in python use keyczar[1] or pynacl[2], and keyczar is probably the best bet.

But if you need to do gpg compatible crypto use the python wrapper for gpgme:

  pygpgme exposes the gpgme library to Python. The product was started by
  James Henstridge. Beside Python2 it supports Python 3 since v0.3 (March
  2012). The wrapping is done using python's C interface directly without
  using a generator tool like SWIG.[3]

[1] http://www.keyczar.org

[2] https://github.com/seanlynch/pynacl

[3] http://pypi.python.org/pypi/pygpgme


The article has a whole paragraph about GPGME.


GnuPG was never made to solve the problems of the authors of commercial software. It's made for GNU (Gnu is Not Unix) systems, in match with all ideological goals of GNU.

I earn for living producing a closed source code, I do use the GNU software in my day-to-day work but I know I can't use GNU libraries in my projects.

Complaining that GnuPG is not made to be convenient for the BSD-like library uses reflects OP's serious misunderstandings of the basic premises of GNU and BSD.

Not to mention that the author posits that his selection of "what's enough" for his use case would be enough for other use cases. I claim that he doesn't actually need an OpenPGP support as long he says that the small subset would be enough for him. He just needs some library to solve encryption and decryption in his limited scenario. He should use some other (BSD-like licensed) crypto-library and develop on it. But somehow I suspect even if somebody would then implement what's enough for him, the result wouldn't be open-source. You know, BSD licenses don't force you to do so.

Moreover I belive that OP misunderstood which part of software does what, I've never heard that GPG ever did "split a message into packets."


Yeah all that closed source software like firefox and thunderbird.

Your argument has nothing to do with the actual problem in the article, that running a command line application when you need a library is troublesome and restrictive.

Hell, if it was a library its license would matter far more than it does as a non-library.


OP wants a library which can be linked in the iOS apps. It's not a GPL compatible use, so even if there were a GnuPG library with more functionality, it wouldn't fit his use case.

His use case would be covered by a BSD-like licensed library, which is not compatible with GPL goals, so he picked the fully wrong target to complain about. It seems that this important distinction is not clear to the OP and to you.

Thunderbird, mentioned by you, actually uses GnuPG without problem. The very reason it can use it is because it uses it as a command line utility. If there were a library, GNU licensed, Thunderbird wouldn't be allowed to use it because of the license incompatibility.


The apple store is only GPL-incompatible on a technicality, though. It doesn't have any meaningful restrictions on your rights.

Isn't Thunderbird's license MPL 2.0, which is GPL-compatible?


Howdy, I'm OP! Neat to see an old blog post on HN.

1) GPL/LGPL are not incompatible with iOS, they are incompatible with the App Store. I don't care about that. I was writing a GPL'd app, and I would be pleased with a GPL'd library. iOS was also not my only target. (response to one of your other posts)

2) The idea of 'what's enough' was for e-mail decryption only. Which is what I wanted to do. And I wrote an open-source OpenPGP library to do it: https://github.com/mrmekon/libsimplepgp

3) I don't need 'some library to solve encryption and decryption', I need 'some library to solve decryption of PGP-encrypted emails.' A partial implementation of OpenPGP, as a library. Other crypto packages don't support the OpenPGP packet format.

4) Read section 4, "Packet Syntax", the entire concept behind the OpenPGP format: http://www.ietf.org/rfc/rfc2440.txt


Wow, it's really nice that you did make a library that solves exactly the problem you've had. IMHO you are really a very specific case, producing GPL iOS code which certainly can't go in the App store.

Updating your blog post with the link to your library would make the post much more relevant, weren't you able to do so?

I understood you "message splitting" like the plaintext or the ciphertext being split, which as far as I know neither is. RFC does use "packets" packets to denote segments as the "packet" with the key and the "packet" with the cypertext but I don't consider recognizing where which begins in order to process it is "splitting." I see now what you wanted to say.

Re "other crypto packages don't support the OpenPGP packet format" -- I understood that libgcrypt also doesn't, so wouldn't be more in the spirit of your goal (if it is) to have OpenPGP more widely used to base libsimplepgp on some BSD, Apache or similarly licensed crypto libarary?


I feel like the best way to attack this problem would be to use GnuPG as a guideline to constructing an entirely new open-source library standard for PGP that can finally serve as a practical basis for widespread PGP encryption. It should also be under a permissible license, because otherwise we'll just get a repeat of everything that's happened with broken proprietary implementations and impossible to use open-source ones.


From the GnuPG FAQ:

"Can't we have a gpg library?

This has been frequently requested. However, the current viewpoint of the GnuPG maintainers is that this would lead to several security issues and will therefore not be implemented in the foreseeable future. However, for some areas of application gpgme could do the trick. You'll find it at http://www.gnupg.org/related_software/gpgme. "

Personally I also don't like the idea of people cutting out a "lightweight" subset of GnuPG. That will only lead to incompatibilities and security issues. Our phones can run 3D games, they should be able to cope with the full GnuPG.


The author implies that GnuPG should work the way he wants it to work. Now to be fair, it would be nice to have great GnuPG integration everywhere, including on iDevices.

But some perspective is needed here. GnuPG works fine in a POSIX environment. All popular platforms can handle that. This isn't the first command-line tool that needed to be integrated into a GUI. Seriously – that's all his complaint amounts to.

There may be a need for a library wrapper around GnuPG, but this complaint is not the need.


Something about your post really, really bothers me. I don't know what it is exactly.

GnuPG is an open source implementation of the OpenPGP standard. PGP is not in widespread use. GnuPG is not a good tool to add PGP support to other software.

That's a perfectly valid complaint. Your casual dismissal seems very wrong to me.


"PGP is not in widespread use."

Depends on what industry/domain you work in. The reason PGP isn't more widely used is: It's expensive, it's complex to the typical "user" and businesses don't want to invest in real PKI even if they need it. (People are lazy and cheap...)

Add in the factor that most developers don't have the chops to figure out and implement nicer software based on the mess that is GPG. You have a few serious tools wrapping it used in ETL applications and ilk like Gpg4Win and the Bouncy Castle libraries.


I think iOS doesn't allow normal programs to fork().


GPL and LGPL are not iOS compatible so it's already a non-option


Some links to read more about this,

ffmpeg (LGPL): https://ffmpeg.org/trac/ffmpeg/ticket/1229

vlc (LGPL): http://waffle.wootest.net/2011/01/08/vlc-gpl-tuaw-wtf/


This is a frequently repeated oversimplification. (L)GPL is not incompatible with iOS, it is incompatible with the Apple App Store.

It is fully, 100% GPL-compliant to release a (L)GPL'd iOS application linked to a (L)GPL'd library, as source code, with instructions on how to build and load on your iOS device.

It is /probably/ not compliant to distribute that through the App Store, though there is some disagreement, and it has never been taken to court.

It is /definitely/ not compliant to distribute a proprietary app that links to an (L)GPL'd library through the App Store, since Apple only permits static linking.


(subtitle: and it should be)

I share the pain. I'm using the executable instead - works well enough as long as you don't need high throughput public key encryption (if you do, you're doing it wrong), and you don't need high throughput public key signatures (that's actually a reasonable use case).

Anyone know of an alternative to gnupg?


The Go PGP library is very nice although if you are not using Go you would need to change language.

http://godoc.org/code.google.com/p/go.crypto/openpgp


Indeed. And I assume it actually works, given that it's written by agl.

Thanks for the reference; Not using go, but it's still interesting.

Although, I realized it is unlikely I'll find a solution (golang or not) - because I actually need gpg to talk to my smart card.


There's netpgp (from NetBSD project) -- http://blog.netbsd.org/tnf/entry/netpgp


There's Peter Gutmann's cryptlib, which also supports OpenPGP (among a huge number of other things).

http://www.cs.auckland.ac.nz/~pgut001/cryptlib/

It's also has a dual license.


I had GPG ported to pure PHP, believe it or not. It only currently supports encryption. I would love some help on this project. https://github.com/jasonhinkle/php-gpg


I was actually just trying to set up mutt with GPG a few moments ago. As a person who hadn't used GPG before, yes, it is a nightmare. Email encryption and signing should be common --- more common than not --- and the most prevalent tool for doing so being so daunting isn't helping.


Ironically, GPG setup in mutt is extremely easy if you use the GPGME library integration:

    set crypt_use_gpgme=yes
The documentation does not seem to stress that GPGME is favored over the old pgp_* settings (which are typically cargo-culted), but it should.

The author mentions GPGME in the article, but only to shrug it off as "too big". Given the fact that devices like the raspberry pi now run full Linux distributions, I'd say it's a weak argument.


Thanks for sharing that config line. I had quite a few of those pgp_* lines in my muttconfig and had never seen anything about the correct/modern setting.


What did you have trouble setting up? Creating a key and informing mutt is fairly straightforward. What errors did you run into?

Configuring GPG and Thunderbird is brain dead easy.


I think this guy is right. Although a bigger problem is that PGP is available in two flavors: free and very expensive.

The problem with GnuPG IMO is that real obvious use cases (healthcare) are out of bounds because it isn't FIPS certified and isn't usable by mortals. Having an implementation similar to OpenSSL with an API, and use case that attracted organization willing to sponsor FIPS validation would be a big step forward. Your doctor could securely send you test results. Your credit card company could send your bill directly.

Consider: The #1 solution for email encryption in hospitals/healthcare is Zix. This is sad -- their solution amounts to attempting to transmit an email via SSL, and falling back to sending you a link to a webpage. Cheesy.

Unfortunately, that's not the way things are, and usage of PGP are generally limited to security professionals, paranoids, and crypto geeks.


So you think that one of the big problems with gpg is that it "is not usable by mortals" and that"having an implementation similar to OpenSSL...would be a big step forward"?

I have never heard anyone say it was easy for mortals to use openssl in a safe and secure manner. Between openssl and gpg, gpg is hands down the better way for mortals or professional geeks to exchange information securely. For starters take a look at what is required to generate a key in gpg:

  $ gpg --gen-key
A user can accept the defaults and have a decent crypto setup relatively easily. How do you think that compares to setting up openssl?


"having an implementation similar to OpenSSL...would be a big step forward"

That made my day.


"gpg is hands down the better way for mortals..."

Snort! How many clients/friends/coworkers have you had to explain PGP, GPG, public keys or just compressing a file with a password to?

For us semi-interested cypto/security aware geeks, it's not difficult. Easier than learning the details about git or picking up Erlang. But for the normal user/client/manager it's like speaking Latin or the understanding Alchemy economics in Skyrim. PKI/GPG is one of those things that falls outside of their give-a-shit enough to understand circle.


I use applications every day that leverage OpenSSL libraries, and would have no idea unless I felt obliged to find out. That's the whole point. GPG is an in your face security product.

I've used GPG for years and love it. But even I have to jump through hoops that are not trivial to deal with -- I use GPG smartcards for a few applications, and while its great when it works, it often doesn't. I can't use it on OSX 10.8 right now, for example.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: