gpg Feature request: merge gpg.exe and gpgsm.exe into one tool

Peter Lebbing peter at
Sun Apr 20 11:05:54 CEST 2014

On 19/04/14 23:31, Thomas Schittli wrote:
> It does not make sense to manage another kind of certs just because
> applications that suport/use GnuPG did not added gpgsm support.

> [...]

> I made a test with Git: I just renamed gpgsm.exe to gpg.exe. It worked
> perfectly!

I see the real problem in a different area.

gpg.exe with OpenPGP keys generates OpenPGP messages. gpgsm.exe with X.509
certificates generates CMS messages. Applications calling gpg.exe expect an
OpenPGP message. If you replace this OpenPGP message by a CMS message, perhaps
the application will still work. Or it will break in certain places or break
after the author of the application changes it in a way that needs OpenPGP
messages, because the author is under the /correct/ impression that gpg.exe
gives him an OpenPGP message, or parses an OpenPGP message passed to it.

Most applications should be using GPGME anyway instead of calling gpg.exe
directly, and X.509 support for GPGME is something that is being worked on, so
an application that doesn't mind whether it handles OpenPGP messages or CMS
messages can just use the appropriate functions of GPGME.

> Therefore I'm pretty sure it was a conceptual error to support X.509 in
> another tool. If X.509 were added into gpg, then every application would
> immediately had support for both worlds :-)

Unfortunately, no. A lot of applications would break. Suppose you are expecting
a certain subsystem to generate German messages, and you put those messages on
your website. If the subsystem would suddenly switch to Chinese, do you think
your clients from Switzerland would be happy that they now had support for both
languages, or do you think they would contact support and ask what the #@%& that
stuff on your site is supposed to mean? ;)

It's up to the applications. If they call gpg.exe directly, they are
expecting OpenPGP functionality. You can just break that assumption and hope the
application still works, but it seems to me you're breaking the expectations the
programmer had when he wrote the code calling gpg.exe directly.

On the other hand, if the application uses GPGME, then CMS support (and thus the
X.509 trust model) seems to be already in the works, and when applications
choose they also want to support that, it might be as easy to support both
OpenPGP and CMS as it is to support just one. I don't know if CMS support in
GPGME is already usable, but it seems much more viable to do a feature
request[1] in that area than to request that the two binaries gpg.exe and
gpgsm.exe, which handle completely different messages, be merged into one. I
don't think that is going to happen, because it would break a lot of applications.



[1] Possibly involving funding

I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <>

More information about the Gnupg-users mailing list