Hacker News Reader

Comment by dfc | Hacker News Reader

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/

View on HN

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.

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.

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

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

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

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.

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.

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.

Reply on news.ycombinator.com