Can someone explain how bad this is in multiples of Heartbleed? Any big time automated processes with decades of dubious history now, etc?

It's difficult to be precise, but I'd bid it out as a minimum of 6 orders of magnitude less, and if someone wanted to bid out 8 or 9 I wouldn't fight them.

It's not a zero-impact issue, but there's so many differences between this and Heartbleed that it just can't be that large. For one thing, there's several orders of magnitude fewer users of GPG than SSL. Then you need a vulnerable configuration. Then you need to have been exploited. Those three things multiply out to quite a few orders of magnitude.

Approximately 0 Heartbleeds.

A Heartbleed-level vulnerability means "everyone is vulnerable, exploitation is trivial, consequences of exploitation are severe" so therefore you need to a) update yesterday and b) assume that the fact you haven't updated yet (because you just found out) means you've already been screwed. These kind of bugs are very rare, and the only comparable one I can think of is Debian's OpenSSL bug.

The attack can only succeed when victim's gpg is run with 'verbose' option turned on. Which is rather unusual situation.

Sorry to be pedantic, but it appears to be a bug in GPG, not the PGP spec.

That's not pedantic, that's pointing out a terrible headline.

PGP is a trademark currently held by Symantec: https://www.symantec.com/about/legal/trademark-policies

The spec is OpenPGP and both PGP and GPG implement it: https://tools.ietf.org/html/rfc4880

That is even more delightfully pedantic (and I learned something)

Seems like it's even a bug in how GPG is used (verbose mode, etc) instead of GPG itself.

I'm surprised those software actually use GPG by parsing its output instead of as a library.

It's not possible to use GPG as a library - the libraries that exist just shell out to the command and parse its output.

I'm not certain, but doesn't GPGME do something a bit more sophisticated than that?

Nope, GPGME spawns the gpg binary too.

The major advantage of GPGME is that it's written by the same folks as GnuPG itself, and hopefully they know how to use the binary correctly.

Unfortunately not, as far as a quick read of engine-gpg.c seems to suggest.

I'm shocked to hear that. What exactly is preventing it from be used as a real library?

IIRC it's deliberately done this way for a number of information security reasons. If you look through the gnupg manual, there are references to things like "on old systems, this program must be setuid root so it may lock memory pages". Presumably it's desirable to require such a thing in an isolated process rather than the entire application utilizing gpg.

Since quality CLI implementations must be provided and exist anyways, why not provide the programmatic interface (libgpgme) as a thin veneer over it, as if the commands are being run from the shell?

I believe that it's primarily that GPG has been implemented in such a way that console concerns invade most of the program, but I've never actually looked to verify.

Probably the license and/or lack of an appropriate licensing exception.

Another posted indicate code issues, but I think you're right this is at least a big reason. GPG is GPL licensed, but GPGME is LGPL licensed. A library version of GPG would have to be GPL licensed as well, which would require any programs linking to it to also be GPL.

With that, for GPGME to be LPGL there can't be an actual coupling of code between the two or else GPGME would have to be GPL licensed itself. (Though you could argue the distinction here a bit murky)

You mean a bug in the software that parse GPG output, right?

If we are being pedantic, that detail is important.

Thank you, we've updated the headline here.