
GnuPG is not a library - morpher
http://mrmekon.tumblr.com/post/12199418635/gnupg-is-not-a-library
======
dfc
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/>

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

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

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

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

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

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

~~~
Dylan16807
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?

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

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

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

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

~~~
xradionut
"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.

------
beagle3
(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?

~~~
papaf
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>

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

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

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

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

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

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

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

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

~~~
dfc
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?

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

That made my day.

