Debian packaging for GnuPG is handled in debian git repositories, and
doesn't belong here in the upstream repository. The packaging was
significantly out of date anyway.
If you're looking for debian packaging for the 1.4 branch of GnuPG,
please use the following git remote:
https://anonscm.debian.org/git/pkg-gnupg/gnupg1.git
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
* cipher/rsa.c (secret_core_crt): Blind secret D with randomized
nonce R for mpi_powm computation.
--
Backport of libgcrypt 8725c99ffa41778f382ca97233183bcd687bb0ce.
Signed-off-by: Marcus Brinkmann <mb@g10code.com>
* mpi/mpi-pow.c (_gcry_mpi_powm): Compare msize for max_u_size. Move
the assignment to base_u into the loop. Copy content refered by RP to
BASE_U except the last of the loop.
--
Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>
(backport commit of libgcrypt master:
78130828e9a140a9de4dafadbc844dbb64cb709a)
* mpi/longlong.h [__arm__] (add_ssaaaa, sub_ddmmss): Add __CLOBBER_CC.
[__arm__][__ARM_ARCH <= 3] (umul_ppmm): Add __AND_CLOBBER_CC.
--
This is a backport of libgcrypt 8aa4f2161 and 3b1cc9e6c.
Signed-off-by: Marcus Brinkmann <mb@g10code.com>
GnuPG-bug-id: 3182
* g10/keygen.c (proc_parameter_file): Fix secmem leak.
--
proc_parameter_file adds certain parameters to the list in the PARA
argument; however, these new entries are leaked because they
are added to head, while the PARA list is released by the caller
of proc_parameter_file.
GnuPG-bug-id: 1371
Signed-off-by: Ineiev <ineiev@gnu.org>
* g10/build-packet.c (do_user_id): Avoid indeterminate length header.
--
We are able to import such user ids but when exporting them the
exported data could not be imported again because the parser bails out
on invalid keyrings. This is now fixed and should be backported.
Note that in 1.4 and 2.0 this is only an issue for attribute packets.
In 2.1 user IDs were also affected.a
Signed-off-by: Werner Koch <wk@gnupg.org>
* tools/gpg-zip.in: Correctly set GPG when --gpg is specified.
Correctly set TAR when --tar is specified. Pass TAR_ARGS to tar.
(cherry-picked by dkg from master branch's
84ebf15b06)
--
Signed-off-by: Neal H. Walfield <neal@g10code.com>
Co-authored-by: Michael Mönch <michael.moench@marktjagd.de>
GnuPG-bug-id 1351
GnuPG-bug-id 1442
* 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>
* 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 c9387e41db)
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
* 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 6f284e6ed6)
Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>
* g10/gpgv.c (main): Set opt.no_sig _cache, so that it doesn't depend on
cached status. Similarly, set opt.flags.require_cross_cert for backsig
validation for subkey signature.
--
(backport of master
commit e32c575e0f)
It is common that an organization distributes binary keyrings with
signature cache (Tag 12, Trust Packet) and people use gpgv to validate
signature with such keyrings. In such a use case, it is possible that
the key validation itself is skipped.
For the purpose of gpgv validation of signatures, we should not depend
on signature cache in keyrings (if any), but we should validate the key
by its self signature for primary key, and back signature for subkey.
Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>
* g10/gpg.c (main): Call set_packet_list_mode after assignment of
opt.list_packets.
* g10/mainproc.c (do_proc_packets): Don't stop processing with
--list-packets as the comment says.
* g10/options.h (list_packets): Fix the comment.
* g10/parse-packet.c: Fix the condition for opt.list_packets.
--
(backport from 2.0 commit 4f336ed780
which is backport of master
commit 52f65281f9)
Debian-bug-id: 828109
Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>
* g10/tdbio.c (create_version_record): Call create_hashtable to always
make hashtable, together with the version record.
(get_trusthashrec): Remove call to create_hashtable.
--
GnuPG-bug-id: 1675
Thanks to Scott Moser to reproducible script and patience.
Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>
(backport from master
commit 35a3ce2acf)
* g10/tdbio.c (tdbio_set_dbname): Return earlier if !CREATE. Check
the directory and create it if none before calling take_write_lock.
--
Thanks to Marc Deslauriers for the bug report and his patch.
GnuPG-bug-id: 2246
Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>
(backport from master
commit 2f3e42047d17313eeb38d354048f343158402a8d)
* cipher/rndunix.c [HAVE_STDINT_H]: Include stdint.h.
(start_gatherer): Detect misbehaving sysconf.
--
See
GnuPG-bug-id: 1778
for the reason of this patch. There is no concrete bug report but this
chnage should not harm.
Signed-off-by: Werner Koch <wk@gnupg.org>
