gnupg2 and its binaries are what the pkg-gnupg team encourages for
general use.  gnupg1 exists only for people with particular
requirements like old keys.  This is much closer to the definition of
"extra" than it is to any other priority definition.

Upstream version 1.4.21

* g10/gpg.c (opts): Add dummy option.

Signed-off-by: Werner Koch <wk@gnupg.org>

--

* Makefile.am (distcheck-hook): New.

Signed-off-by: Werner Koch <wk@gnupg.org>

--

* cipher/random.c (mix_pool): Store the first hash at the end of the
pool.
--

This fixes a long standing bug (since 1998) in Libgcrypt and GnuPG.
An attacker who obtains 580 bytes of the random number from the
standard RNG can trivially predict the next 20 bytes of output.

This bug does not affect the default generation of
keys because running gpg for key creation creates at most 2 keys from
the pool: For a single 4096 bit RSA key 512 byte of random are
required and thus for the second key (encryption subkey), 20 bytes
could be predicted from the the first key.  However, the security of
an OpenPGP key depends on the primary key (which was generated first)
and thus the 20 predictable bytes should not be a problem.  For the
default key length of 2048 bit nothing will be predictable.

For the former default of DSA+Elgamal key it is complicate to give an
answer: For 2048 bit keys a pool of 30 non-secret candidate primes of
about 300 bits each are first created.  This reads at least 1140 bytes
from the pool and thus parts could be predicted.  At some point a 256
bit secret is read from the pool; which in the worst case might be
partly predictable.

The bug was found and reported by Felix Dörre and Vladimir Klebanov,
Karlsruhe Institute of Technology.  A paper describing the problem in
detail will shortly be published.

CVE-id: CVE-2016-6313
Signed-off-by: Werner Koch <wk@gnupg.org>

* cipher/random.c (mix_pool): Use DIGESTLEN instead of 20.

Signed-off-by: Werner Koch <wk@gnupg.org>

* g10/gpg.c (main): initialize opt.emit_version to 0
* doc/gpg.texi: document different default for --emit-version

--

The version of GnuPG in use is not particularly helpful.  It is not
cryptographically verifiable, and it doesn't distinguish between
significant version differences like 2.0.x and 2.1.x.

Additionally, it leaks metadata that can be used to distinguish users
from one another, and can potentially be used to target specific
attacks if there are known behaviors that differ between major
versions.

It's probably better to take the more parsimonious approach to
metadata production by default.

(backport of master commit c9387e41db7520d176edd3d6613b85875bdeb32c)

Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

the experimental buildd for powerpc was failing because it pulled in
automake1.11.  it failed with:

Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\${ <-- HERE ([^ \t=:+{}]+)}/ at /usr/bin/automake line 4159.
configure.ac:50: option `serial-tests' not recognized
autoreconf: automake failed with exit status: 1
dh_autoreconf: autoreconf -f -i returned exit code 1
debian/rules:6: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

https://buildd.debian.org/status/fetch.php?pkg=gnupg1&arch=powerpc&ver=1.4.20-6%2Bexp4&stamp=1470619435

this attempts to force it to do the right thing.

* README, cipher/cipher.c, cipher/pubkey.c, doc/gpg.texi: replace
  "allow to" with clearer text

In standard English, the normal construction is "${XXX} allows ${YYY}
to" -- that is, the subject (${XXX}) of the sentence is allowing the
object (${YYY}) to do something.  When the object is missing, the
phrasing sounds awkward, even if the object is implied by context.
There's almost always a better construction that isn't as awkward.

These changes should make the language a bit clearer.

Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

* checks/armor.test, cipher/des.c, g10/ccid-driver.c, g10/pkclist.c,
  util/regcomp.c, util/regex_internal.c: correct the spelling of
  "occured" to "occurred"

Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

* g10/sig-check.c (signature_check2): Not only subkey, but also primary
key should have flags.valid=1.

--

(backport of master
commit 6f284e6ed63f514b15fe610f490ffcefc87a2164)

Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>

move to newer, simpler dh-style build process, with explicitly
installed artifacts via debian/*.install and other dh helper files.

This should make it easier to maintain in the future, and should
include build hardening and other improvements automagically as the
toolchain improves.

 * fix lintian-overrides
 * use Vcs- fields which match the new source package name

 * use https
 * add myself to debian/copyright as author of files in debian/
 * identify as "classic" (compare with "modern" gnupg2)
 * correct information about source files