Many parts of this page are now obsolete, as GnuPG can be installed from Debian experimental with the 2.x packages taking over the gnupg and gpgv program names.

This is a list of packages either supporting GnuPG v2.1 (gnupg2, gpgv2) natively, or describing how to make them use it.

Contents

General support
1. Usage approaches
2. GPG_AGENT_INFO variable
Programs

General support

Usage approaches

There are three major approaches when it comes to using GnuPG v2, the first is the preferred one if experimental can be used, the other two have advantages and disadvantages but are pretty much discouraged by the GnuPG Team. If you want to help and speed up a possible transition to GnuPG v2, you can assist by testing applications with one of these methods:

Upgrade: Just install gnupg and gpgv from experimental. These will replace the gpg and gpgv binaries with the 2.x versions.
Incremental: Configure each program to explicitly call gpg2/gpgv2, as documented further down. This makes sure that only programs known to work with the new version make use of it. The problem is that some programs might not allow to specify the GnuPG binary to use, or that you might end up missing programs to configure.
Global: Either set up local diversions and add symlinks pointing to GnuPG v2, with
```
dpkg-divert --local --rename --add /usr/bin/gpg
dpkg-divert --local --rename --add /usr/bin/gpgv
ln -s gpg2 /usr/bin/gpg
ln -s gpgv2 /usr/bin/gpgv
```
or just install symlinks under /usr/local/bin/. The problem with both is that if the program does not allow to specify the GnuPG binary and it does not work with the newer versions, then you cannot solve this except by reverting the global override. An additional problem with the symlinks in /usr/local/bin/ is that it will not work with programs that hardcode an absolute path. $/!\$ Take into account that you need to override both binaries, otherwise gpg (v2) will not be too happy when interacting with a gpgv (v1).

GPG_AGENT_INFO variable

Many programs check for the presence of the gpg-agent by checking the environment variable GPG_AGENT_INFO, to decide if they can proceed at all, or if they need to prompt the user for a passphrase which they then cache. With latest GnuPG this is counterproductive, as it does not use any longer the GPG_AGENT_INFO environment variable (the communication socket uses a stable pathname now), and gpg2 will make sure to start the gpg-agent on demand.

For compatibility with these programs, it is wise to define the variable with a compatible value, as some of these programs even parse its contents. Something like the following should do:

: ${GNUPGHOME=$HOME/.gnupg}
GPG_AGENT_INFO=${GNUPGHOME}/S.gpg-agent:0:1
export GPG_AGENT_INFO

Alternatively, when using the X Window System, you can simply set in ~/.gnupg/gpg.conf:

use-agent

and the Xsession setup code will take care of starting the agent and setting the environment variable with a correct value.

According to upstream, the correct fix is to invoke gpg-agent --use-standard-socket-p and check that it returns 0, which means that the agent can be used even if GPG_AGENT_INFO is not set. This works with GnuPG 2.0 and 2.1 (even though it's not documented in the info nor man pages for the latter).

Programs

apt

Defaults to GnuPG v1. To configure some of the parts to use GnuPG v2, add the following to apt.conf:

Dir::Bin::gpg "gpgv2";

but older versions of apt-key (apt < 1.1~exp4) hardcode the program name (instead of using apt-config). And newer versions (apt >= 1.1~exp4) do not work at all when using:

Apt::Key::gpgcommand "gpg2";

because apt-key still hardcodes an invocation of gpgv which cannot handle the newly generated keyrings by the gpg2 binary. 781042

debootstrap

Defaults to GnuPG v1. Hardcodes the gpgv program name.

cdebootstrap

Defaults to GnuPG v1. Hardcodes the gpgv program name.

dpkg-dev

Supports gnupg2/gpgv2 natively since 1.17.2, and will prefer them over gnupg/gpgv if they are installed.

debsig-verify

Support GnuPG 2.x natively since 0.15. Can use an alternative program with via the DEBSIG_GNUPG_PROGRAM environment variable since 0.14.

debsigs

Defaults to GnuPG v1. Hardcodes absolute pathname to the binary.

dpkg-sig

Defaults to GnuPG v1. Hardcodes the program name.

devscripts

Defaults to GnuPG v1. Add the following setting to ~/.devscripts.

DEBSIGN_PROGRAM=gpg2

reportbug

Defaults to GnuPG v1. Hardcodes the program name.

dupload

Defaults to GnuPG v1. Hardcodes the program name. But the *.changes checker is configurable in dupload.conf, by copying /usr/share/dupload/gpg-check to gpg-wrapper and replacing gpg with gpg2:

$preupload{'changes'} = 'gpg-wrapper %s';

dput

Defaults to GnuPG v1. Hardcodes absolute pathname to the binary.

git

Defaults to GnuPG v1. Run:

git config gpg.program gpg2

vim

Defaults to GnuPG v1. Add the gnupg.vim plugin in .vim/plugins/gnupg.vim, and add to your .vimrc:

let g:GPGExecutable = "gpg2"

The plugin expects the GPG_TTY environment variable to be set, which is a good idea anyway, otherwise it will emit a warning.

mutt

Defaults to GnuPG v1. Use /etc/Muttrc.d/gpg.rc as a template, copy it to your home directory (~/.mutt/gpg.rc for example), edit it and replace gpg with gpg2.

Then in your muttrc file add:

set pgp_use_gpg_agent=yes
source "~/.mutt/gpg.rc"

There was a bug (780730) related to pgp_use_gpg_agent and the GPG_AGENT_INFO environment variable that got fixed in 1.5.24-1.

signing-party

Defaults to GnuPG v1. Can be changed by setting the environment variable GNUPGBIN=gpg2 (requires version >= 1.1.13).

caff

Version >= 1.1.13 supports GnuPG >= 2.1. Otherwise the default can be changed in the ~/.caffrc file:

$CONFIG{'gpg'} = 'gpg2';

keyart

With versions < 1.1.13, supports gpg2 natively if available. With >= 1.1.13, it defaults to gpg, but you can use the GNUPGBIN environment variable.

TeamsGnuPGUsingGnuPGv2