GnuPG version 2.1 (now known as 2.2) comes with a bag of new features which changes some things old-timers are used to. This page explains the more important ones. It expects that the reader is familiar with GnuPG version 2.0 and aware that GnuPG consists of gpg, gpgsm, and gpg-agent as its main components.

Now for the detailed description of these new features. Note that the examples assume that gpg is installed as gpg. Your installation may have it installed under the name gpg2.

gpg used to keep the public key pairs in two files: pubring.gpg and secring.gpg. The only difference is that secring stored in addition to the public part also the private part of the key pair. The secret keyring thus contained only the keys for which a private key is available, that is the user’s key. It required a lot of code to keep both versions of the key in sync and led to sometimes surprising inconsistencies.

The design of GnuPG-2 demands that only the gpg-agent has control over the private parts of the keys and the actual encryption engine (gpg or gpgsm) does not know about the private key but care only about session keys and keys for symmetric encryption. This has been implemented about 10 years ago for gpgsm (the S/MIME part of GnuPG). However, gpg (the OpenPGP part) used the gpg-agent only as passphrase entry and cache device but handles the private key itself.

With GnuPG 2.1 this changed and gpg now also delegates all private key operations to the gpg-agent. Thus there is no more code in the gpg binary for handling private keys. En passant this allows the long time requested “merging of secret keys” and several other advanced key management techniques.

To ease the migration to the no-secring method, gpg detects the presence of a secring.gpg and converts the keys on-the-fly to the the key store of gpg-agent (this is the private-keys-v1.d directory below the GnuPG home directory (~/.gnupg)). This is done only once and an existing secring.gpg is then not anymore touched by gpg. This allows co-existence of older GnuPG versions with GnuPG 2.1. However, any change to the private keys using the new gpg will not show up when using pre-2.1 versions of GnuPG and vice versa.

The option --secret-keyring has no more effect.

Note that the command --export-secret-keys still creates an OpenPGP compliant file with the secret keys. This is achieved by asking gpg-agent to convert a key and return it in the OpenPGP protected format. The export operation requires that the passphrase for the key is entered so that gpg-agent is able to change the protection from its internal format to the OpenPGP required format.

Some algorithms and parts of the protocols as used by the 20 years old PGP-2 software are meanwhile considered unsafe. In particular the baked in use of the MD5 hash algorithm limits the security of PGP-2 keys to non-acceptable rate. Technically those PGP-2 keys are called version 3 keys (v3) and are easily identified by a shorter fingerprint which is commonly presented as 16 separate double hex digits.

With GnuPG 2.1 all support for those keys has gone. If they are in an existing keyring they will eventually be removed. If GnuPG encounters such a key on import it will not be imported due to the not anymore implemented v3 key format. Removing the v3 key support also reduces complexity of the code and is thus better than to keep on handling them with a specific error message.

There is one use case where PGP-2 keys may still be required: For existing encrypted data. We suggest to keep a version of GnuPG 1.4 around which still has support for these keys (it might be required to use the --allow-weak-digest-algos option). A better solution is to re-encrypt the data using a modern key.

This is best shown with an example:

$ gpg --gen-key
gpg (GnuPG) 2.1.0; Copyright (C) 2014 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: keybox '/home/foo/.gnupg/pubring.kbx' created
Note: Use "gpg --full-gen-key" for a full featured key generation dialog.

GnuPG needs to construct a user ID to identify your key.

Real name: Glenn Greenwald
Email address: glenn@example.org
You selected this USER-ID:
    "Glenn Greenwald <glenn@example.org>"

Change (N)ame, (E)mail, or (O)kay/(Q)uit? o
[...]
pub   rsa2048/68FD0088 2014-11-03
      Key fingerprint = 0290 5ABF 17C7 81FB C390  9B00 636A 1BBD 68FD 0088
uid       [ultimate] Glenn Greenwald <glenn@example.org>
sub   rsa2048/84439DCD 2014-11-03

Thus only the name and the mail address are required. For all other parameters the default values are used. Many graphical frontends works in the same way. Note that gpg prints a hint for the old time gpg users on how to get the full option menu.

GnuPG now support Elliptic Curve keys for public key encryption. This is defined in RFC-6637. Because there is no other mainstream OpenPGP implementation yet available which supports ECC, the use of such keys is still very limited. Thus GnuPG 2.1 currently hides the options to create an ECC key.

For those who want to experiment with ECC or already want to prepare a key for future use, the command --full-gen-key along with the option --expert is the enabler:

$ gpg --expert --full-gen-key
gpg (GnuPG) 2.1.0; Copyright (C) 2014 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
   (9) ECC and ECC
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)
Your selection? 9
Please select which elliptic curve you want:
   (2) NIST P-256
   (3) NIST P-384
   (4) NIST P-521
   (5) Brainpool P-256
   (6) Brainpool P-384
   (7) Brainpool P-512
Your selection? 2
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0)
Key does not expire at all
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: Edward Snowden
Email address: edward@example.org
Comment:
You selected this USER-ID:
    "Edward Snowden <edward@example.org>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
[...]
pub   nistp256/382660E3 2014-11-03
      Key fingerprint = E630 27CF 3D68 22A7 6FF2  093E D179 9E72 3826 60E3
uid       [ultimate] Edward Snowden <edward@example.org>
sub   nistp256/48C9A997 2014-11-03 nistp256

In this example we created a primary ECC key for signing and an subkey for encryption. For both we use the NIST P-256 curve. The key may now be used in the same way as any other key. It is possible to add an RSA subkey or one can create an RSA or DSA main key and add an ECC subkey for signing or encryption. Note that the list of offered curves depends on the installed Libgcrypt version.

For many people the NIST and also the Brainpool curves have an doubtful origin and thus the plan for GnuPG is to use Bernstein’s Curve 25519 as default. GnuPG 2.1.0 already comes with support for signing keys using the Ed25519 variant of this curve. This has not yet been standardized by the IETF (i.e. there is no RFC) but we won’t wait any longer and go ahead using the proposed format for this signing algorithm. The format for an encryption key has not yet been finalized and will be added to GnuPG in one of the next point releases. Recall that an encryption subkey can be added to a key at any time. If you want to create a signing key you may do it this way:

$ gpg --expert --full-gen-key
gpg (GnuPG) 2.1.0; Copyright (C) 2014 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
   (9) ECC and ECC
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)
Your selection? 10
Please select which elliptic curve you want:
   (1) Curve 25519
   (2) NIST P-256
   (3) NIST P-384
   (4) NIST P-521
   (5) Brainpool P-256
   (6) Brainpool P-384
   (7) Brainpool P-512
Your selection? 1
gpg: WARNING: Curve25519 is not yet part of the OpenPGP standard.
Use this curve anyway? (y/N) y
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0)
Key does not expire at all
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: Laura Poitras
Email address: laura@example.org
Comment:
You selected this USER-ID:
    "Laura Poitras <laura@example.org>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
[...]
pub   ed25519/5C1AFC2A 2014-11-03
      Key fingerprint = ED85 4D98 5D8F 502F C6C5  FFB2 AA81 319E 5C1A FC2A
uid       [ultimate] Laura Poitras <laura@example.org>

Support for ECC keys is available only on some keyservers but it is expected that this will be fixed over the next few months.

Sometimes it is useful to use only command line options without any parameter file or interactive prompts for generating a key or to sign a key. This can now be accomplished with a few new commands:

$ gpg --batch --quick-gen-key 'Daniel Ellsberg <ellsberg@example.org>'
gpg: key 911B90A9 marked as ultimately trusted

If a key with that user id already exists, gpg bails out with an error message. You can force creation using the option --yes. If you want some more control, you may not use --batch and gpg will ask for confirmation and show the resulting key:

$ gpg --quick-gen-key 'Daniel Ellsberg <ellsberg@example.org>'
About to create a key for:
    "Daniel Ellsberg <ellsberg@example.org>"

Continue? (Y/n) y
gpg: A key for "Daniel Ellsberg <ellsberg@example.org>" already exists
Create anyway? (y/N) y
gpg: creating anyway
[...]
pub   rsa2048/BD19AC1C 2014-11-04
      Key fingerprint = 15CB 723E 2000 A1A8 2505  F3B7 CC00 B501 BD19 AC1C
uid       [ultimate] Daniel Ellsberg <ellsberg@example.org>
sub   rsa2048/72A4D018 2014-11-04

Another common operation is to sign a key. gpg can do this directly from the command line by giving the fingerprint of the to-be-signed key:

$ gpg --quick-sign-key  '15CB 723E 2000 A1A8 2505  F3B7 CC00 B501 BD19 AC1C'

pub  rsa2048/BD19AC1C
     created: 2014-11-04  expires: never       usage: SC
     trust: ultimate      validity: ultimate
 Primary key fingerprint: 15CB 723E 2000 A1A8 2505  F3B7 CC00 B501 BD19 AC1C

     Daniel Ellsberg <ellsberg@example.org>

In case the key has already been signed, the command prints a note and exits with success. In case you want to check that it really worked, use --check-sigs as usual:

$ gpg --check-sigs  '15CB 723E 2000 A1A8 2505  F3B7 CC00 B501 BD19 AC1C'
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   6  signed:   1  trust: 0-, 0q, 0n, 0m, 0f, 6u
pub   rsa2048/BD19AC1C 2014-11-04
uid       [  full  ] Daniel Ellsberg <ellsberg@example.org>
sig!3        BD19AC1C 2014-11-04  Daniel Ellsberg <ellsberg@example.org>
sig!         68FD0088 2014-11-04  Glenn Greenwald <glenn@example.org>
sub   rsa2048/72A4D018 2014-11-04
sig!         BD19AC1C 2014-11-04  Daniel Ellsberg <ellsberg@example.org>

The fingerprint may also be given without the spaces in which case there is no need for the quotes. If you want to sign only certain user ids of a key, list those user id verbatim after the fingerprint. To create a non-exportable key signature, use the command --quick-lsign-key instead.

Since version 2.1.4 it possible to directly add another user id to an existing key:

$ gpg -k 8CFDE12197965A9A
pub   ed25519/8CFDE12197965A9A 2014-08-19
uid               [ unknown] EdDSA sample key 1
$ gpg --quick-adduid 8CFDE12197965A9A 'Sample 2 <me@example.org>'
$ gpg -k 8CFDE12197965A9A
pub   ed25519/8CFDE12197965A9A 2014-08-19
uid               [ unknown] Sample 2 <me@example.org>
uid               [ unknown] EdDSA sample key 1

Since version 2.1.13 another subkey can directly be added to an existing key:

$ gpg --quick-addkey 15CB723E2000A1A82505F3B7CC00B501BD19AC1C - - 2016-12-31
$ gpg -k 15CB723E2000A1A82505F3B7CC00B501BD19AC1C
pub   rsa2048 2014-11-04 [SC]
      15CB723E2000A1A82505F3B7CC00B501BD19AC1C
uid           [ unknown] Daniel Ellsberg <ellsberg@example.org>
sub   rsa2048 2014-11-04 [E]
sub   rsa2048 2016-06-06 [E] [expires: 2016-12-31]

Here we created another encryption subkey with an expiration date. The key listing also shows the default key listing format introduced with 2.1.13. There are a lot of other options to the --quick-addkey command which are described in the manual.

Since version 2.1.14 it possible to revoke a user id on an existing key:

$ gpg -k 8CFDE12197965A9A
pub   ed25519/8CFDE12197965A9A 2014-08-19
uid               [ unknown] Sample 2 <me@example.org>
uid               [ unknown] EdDSA sample key 1
$ gpg --quick-revuid 8CFDE12197965A9A 'EdDSA sample key 1'
$ gpg -k 8CFDE12197965A9A
pub   ed25519/8CFDE12197965A9A 2014-08-19
uid               [ unknown] Sample 2 <me@example.org>

Since version 2.1.17 the expiration date of the primary key can be changed directly:

$ gpg --quick-set-expire 5B83120DB1E3A65AE5A8DCF6AA43F1DCC7FED1B7 2017-12-31
$ gpg -K 5B83120DB1E3A65AE5A8DCF6AA43F1DCC7FED1B7
sec   rsa2048 2016-06-22 [SC] [expires: 2017-12-31]
      5B83120DB1E3A65AE5A8DCF6AA43F1DCC7FED1B7
uid           [ultimate] steve.biko@example.net
ssb   rsa2048 2016-06-22 [E]

$ gpg --quick-set-expire 5B83120DB1E3A65AE5A8DCF6AA43F1DCC7FED1B7 none
$ gpg -K 5B83120DB1E3A65AE5A8DCF6AA43F1DCC7FED1B7
sec   rsa2048 2016-06-22 [SC]
      5B83120DB1E3A65AE5A8DCF6AA43F1DCC7FED1B7
uid           [ultimate] steve.biko@example.net
ssb   rsa2048 2016-06-22 [E]

When using a recent Pinentry module (0.90, GTK+ variant), the gpg-agent will not anymore show two separate Pinentry dialogs to enter a new passphrase and later to confirm the new passphrase. Instead the first dialog also has the confirm/repeat entry and internally checks whether they match.

With any Pinentry version the several separate dialogs to inform and ask for confirmation about questionable properties of a new passphrase (e.g. length, only alpha letters) have been combined into one dialog to show all non-asserted constraints at once.

The GTK+ Pinentry does now allow pasting of values into the entries. Copying them from the entries is still inhibited on purpose. Depending on the system, the option no-grab may be required for in the gpg-agent.conf file to actually make use of the paste feature.

The gpg-agent is the central part of the GnuPG system. It takes care of all private (secret) keys and if required diverts operations to a smartcard or other token. It also provides support for the Secure Shell by implementing the ssh-agent protocol.

The classic way to run gpg-agent on Unix systems is by launching it at login time and use an environment variable (GPG_AGENT_INFO) to tell the other GnuPG modules how to connect to the agent. However, correctly managing the start up and this environment variable is cumbersome so that an easier method is required. Since GnuPG 2.0.16 the --use-standard-socket option already allowed to start the agent on the fly; however the environment variable was still required.

With GnuPG 2.1 the need of GPG_AGENT_INFO has been completely removed and the variable is ignored. Instead a fixed Unix domain socket named S.gpg-agent in the GnuPG home directory (by default ~/.gnupg) is used. The agent is also started on demand by all tools requiring services from the agent.

If the option --enable-ssh-support is used the auto-start mechanism does not work because ssh does not know about this mechanism. Instead it is required that the environment variable SSH_AUTH_SOCK is set to the S.gpg-agent.ssh socket in the GnuPG home directory. Further gpg-agent must be started: Either by using a GnuPG command which implicitly starts gpg-agent or by using gpgconf --launch gpg-agent to explicitly start it if not yet done.

A deficit of the OpenPGP protocol is that signatures carry only a limited indication on which public key has been used to create a signature. Thus a verification engine may only use this “long key id” to look up the key in its own store or from a public keyserver. Unfortunately it has now become possible to create a key with a long key id matching the key id of another key. Importing a key with a long key id already used by another key in gpg’s local key store was not possible due to checks done on import. Now, if the “wrong” key has been imported first gpg would not allow later import of the second “correct” key. This problem has been fixed in 2.1 by allowing the import and by doing trial verification against all matching keys.

Before version 2.1, gpg used so-called keyserver helpers to access the OpenPGP keyservers. A problem with that is that they are short living processes which are not able to keep a state. With 2.1, the formerly separate package Dirmngr (which was separate due to copyright assignment reasons) has been integrated into GnuPG.

In the past dirmngr was only used by gpgsm for X.509 (S/MIME) CRL and OCSP handling. Being a proper part of GnuPG dirmngr does now also care about accessing OpenPGP keyservers. This make its easier to debug problems with the keyservers and to exchange additional information about the keyserver between gpg and dirmngr. It will eventually also be possible to run background tasks to refresh keys.

Although the ability to start dirmngr as a system service is still available, this is not anymore recommended and instead dirmngr is now by default started on-demand, very similar to gpg-agent.

For load balancing reasons, keyservers are organized in pools to enable instant round-robin DNS assignment of random keyservers. A problem with that approach is that the DNS resolver is not aware of the state of the keyserver. If a keyserver has gone down or a routing problems occurs, gpg and its keyserver helpers were not aware of it and would try over and over to use the same, dead, keyserver up until the DNS information expires and a the DNS resolver assigned a new server from the pool.

The new dirmngr in GnuPG does not use the implicit round-robin of the DNS resolver but uses its own DNS lookup and keeps an internal table of all hosts from the pool along with the encountered aliveness state. Thus after a failure (timeout) of a request, dirmngr flags a host as dead and randomly selects another one from the pool. After a few hours the flag is removed so that the host will be tried again. It is also possible to mark a specific host from a pool explicitly as dead so that it won’t be used in the future. To interact with the dirmngr the gpg-connect-agent tool is used:

$ gpg-connect-agent --dirmngr 'help keyserver' /bye
$ gpg-connect-agent --dirmngr 'keyserver --hosttable' /bye

The first command prints a help screen for the keyserver command and the second command prints the current host table.

The format GnuPG has always used for the public keyring is actually a slightly extended version of the on-the-wire format for OpenPGP key exchange. This format is quite inflexible to work with when random access to keys in the keyring is required. In fact gpg always parsed all keys in the keyring until it encountered the desired one. With a large keyring (more than a few thousand keys) this could be quite slow.

From its very beginning gpgsm has used a different format to store public keys (certificates) which we call a keybox. That file format carries meta information about the stored keys and thus allows searching without actually parsing the key and computing fingerprints and such. The keybox format has been designed to be protocol independent and with 2.1 support for OpenPGP keys has been added. Random access to the keys is now really fast and keyrings with 30000 keys and more are now easily possible. That change also enables us to easily introduce other storage methods

If no pubring.gpg is found, gpg defaults to the new keybox format and creates a pubring.kbx keybox file. If such a keybox file already exists, for example due to the use of gpgsm, it will also be used for OpenPGP keys. However, if a pubring.gpg is found and no keybox file with OpenPGP keys exists, the old pubring.gpg will be used. Take care: GnuPG versions before 2.1 will always use the pubring.gpg file and not know anything about keys stored in the keybox file.

To convert an existing pubring.gpg file to the keybox format, you first backup the ownertrust values, then rename the file to (for example) publickeys, so it won’t be recognized by any GnuPG version, then run import, and finally restore the ownertrust values:

$ cd ~/.gnupg
$ gpg --export-ownertrust >otrust.lst
$ mv pubring.gpg publickeys
$ gpg --import-options import-local-sigs --import publickeys
$ gpg --import-ownertrust otrust.lst

You may then rename the publickeys file back so that it can be used by older GnuPG versions. Remember that in this case you have two independent copies of the public keys. The ownertrust values are kept by all gpg versions in the file trustdb.gpg but the above precautions need to be taken to keep them over an import.

This version creates an ASCII armored revocation certificate for each generated keypair and stores that certificate in a file named after the fingerprint of the key in the openpgp-revocs.d directory below the GnuPG home directory. Brief instructions on how to use this revocation certificate are put at the top of the file.

The scdaemon, which is responsible for accessing smardcards and other tokens, has received many updates. In particular pluggable USB readers with a fixed card now work smoothless and similar to standard readers. The latest features of the gnuk token are supported. Code for the SmartCard-HSM has been added. More card readers with a PIN pad are supported. The internal CCID driver does now also work with certain non-auto-configuration equipped readers.

Since version 2.1.19 multiple card readers are support and the format of the Pinentry prompts has been changed to show more information on the requested card.

Due to the introduction of ECC keys the old format to list keys was not anymore suitable. In particular, the length of an ECC key is defined but its expressiveness is limited without the other parameters of the curve. The common way to describe an ECC key is by using the assigned name of its curve. To allow for a common description we now either use the algorithm name with appended key length or use the name of the curve:

pub   2048D/1E42B367 2007-12-31 [expires: 2018-12-31]

pub   dsa2048 2007-12-31 [SC] [expires: 2018-12-31]
      80615870F5BAD690333686D0F2AD85AC1E42B367

pub   ed25519 2014-10-18 [SC]
      0B7F0C1D690BC440D5AFF9B56902F00A0AA914C9

The first two "pub"-items show the same key in the old format and in the new format. The third "pub"-item shows an example of an ECC key using an ed25519 curve. Note that since version 2.1.13 the key id is not anymore shown. Instead the full fingerprint is shown in a compact format; by using the option --with-fingerprint the non-compact format is used. The --keyid-format option can be used to switch back to the discouraged format which prints only the key id.

As a further change the validity of a key is now shown by default; that is show-uid-validity is implicitly used for the --list-options.

The annotated key listing produced by the --with-colons options did not change. However a couple of new fields have been added, for example if the new option --with-secret is used the “S/N of a token field” indicates the presence of a secret key even in a public key listing. This option is supported by recent GPGME versions and makes writing of key manager software easier.

Since version 2.1.14 it is possible to specify the recipient’s key by providing a file with that key. This done with the new options --recipient-file (or short -f) and --hidden-recipient-file (or short -F). The file must containing exactly one key in binary or armored format. All keys specified with those options are always considered fully valid. These option may be mixed with the regular options to specify a key. Along with the new convenience option --no-keyring it is now possible to encrypt data without maintaining a local keyring.

Since version 2.1.14 the export and import options have been enhanced to allow the use of gpg to modify a key without first storing it in the keyring. For example:

$ gpg --import-options import-minimal,import-export \
      --output smallkey.gpg --import key.gpg

copies the keys in keys.gpg to smallkey.gpg while also removing all key signatures except for the latest self-signatures. This can even be further restricted to copy only a specific user ID to the output file:

$ gpg --import-options import-minimal,import-export \
      --import-filter keepuid='mbox = foo@example.org' \
      --output smallkey.gpg --import key.gpg

Here the new --import-filter option is used to remove all user IDs except for those which have the mail address “foo@example.org”. The same is also possible while exporting a key:

$ gpg --export-filter keepuid='mbox = me@example.org' \
      --armor --export 8CFDE12197965A9A >smallkey.asc

On Windows the new option --enable-putty-support allows gpg-agent to act as a replacement for Putty’s authentication agent Pageant. It is the Windows counterpart for the --enable-ssh-support option as used on Unix.

The new command --export-ssh-key makes it easy to export an ssh public key in the format used for ssh’s authorized_keys file. By default the command exports the newest subkey with an authorization usage flags. A special syntax can be used to export other subkeys. This command is available since 2.1.11 and replaces the former debug utility gpgkey2ssh.

In addition to an improved certificate signing request menu, it is now possible to create a self-signed certificate using the interactive menu of gpgsm.

In batch mode the certificate creation dialog can now be controlled by a parameter file with several new keywords. Such a parameter file allows the creation of arbitrary X.509 certificates similar to what can be done with openssl. It may thus be used as the base for a CA software. For details see the “CSR and certificate creation” section in the manual.

The new commands --export-secret-key-p8 and –export-secret-key-raw= may be used to export a secret key directly in PKCS#8 or PKCS#1 format. Thus X.509 certificates for TLS use may be managed by gpgsm and directly exported in a format suitable for OpenSSL based servers.

GnuPG now comes with the speedo build system which may be used to quickly download and build GnuPG and all its direct dependencies on a decent Unix system. See the README file for more instructions.

The very same script may also be used to build a complete NSIS based installer for Windows using the mingw-w64 cross-compiler toolchain. That installer will feature GnuPG proper, GPA as graphical frontend, and GpgEX as a Windows Explorer extension. GnuPG needs to be unpacked and from the top source directory you run this command

make -f build-aux/speedo.mk w32-installer

This command downloads all direct dependencies, checks the signatures using the GnuPG version from the build system (all Linux distros feature a suitable GnuPG tool), builds everything from source, and uses NSIS to create the installer. Although this sounds easy, some experience in setting up a development machine is still required. Some versions of the toolchain exhibit bugs and thus your mileage may vary. See the Wiki for more info.

Support for keyserver access over TLS is currently not available but will be added with one of the next point releases.