Note that you may also download the GNU Privacy Guard from a mirror site close to you. See our list of mirrors. The table below provides links to the location of the files on the primary server only.

These are the canonical release forms of GnuPG. To use them you need to build the binary version from the provided source code. For Unix systems this is the standard way of installing software. For commonly used Linux distributions (e.g. Debian, Fedora, RedHat, or Ubuntu) GnuPG is already part of the base system. However, these version may be older so that building from the source is often also a good choice. Some knowledge on how to compile and install software is required. For Debian based systems see below for packages which replace those coming with the distribution.

The table lists the different GnuPG packages, followed by required libraries, required tools, optional software, and legacy versions of GnuPG. For end-of-life dates see further down.

GnuPG distributions are signed. It is wise and more secure to check out for their integrity .

Remarks:

• Pinentry is a collection of passphrase entry dialogs which is required for almost all usages of GnuPG.
• GPGME is the standard library to access GnuPG functions from programming languages.
• Scute is a PKCS#11 provider on top of GnuPG.
• GPA is a graphical frontend to GnuPG.
• GnuPG 1.4 is the old, single binary version which still supports the unsafe PGP-2 keys. This branch has no dependencies on the above listed libraries or the Pinentry. However, it lacks many modern features and will receive only important security updates.

In general we do not distribute binary releases but leave that to the common Linux distributions. However, for some operating systems we list pointers to readily installable releases. We cannot guarantee that the versions offered there are current. Note also that some of them apply security patches on top of the standard versions but keep the original version number.

We announce the end-of-life date for a current stable version at the time a new stable version is released. We maintain old branches for at least two years. For branches with an even minor version number we consider the preceding odd version as the birth of the branch. For most other packages we don't maintain branches and thus there is no end-of-life; always use the latest version.

• (1): Long Term Support.
• (2): Legacy version; see remarks above.
• (3): Extended Long Term Support contract available.
• tba: To be announced.