* g10/mainproc.c (proc_plaintext): Sanitize verbose output.
--
This fixes a forgotten sanitation of user supplied data in a verbose
mode diagnostic. The mention CVE is about using this to inject
status-fd lines into the stderr output. Other harm good as well be
done. Note that GPGME based applications are not affected because
GPGME does not fold status output into stderr.
CVE-id: CVE-2018-12020
GnuPG-bug-id: 4012
(cherry picked from commit 13f135c7a2)
* g10/compress.c (handle_compressed): Fix memory leak.
--
(backport from STABLE-BRANCH-2-2 commit:
c31abf8465)
All other calls of push_compress_filter checks ALGO,
so, do it here, too.
GnuPG-bug-id: 3898
Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>
--
The French string has an extra %s which would result in garbage output
or segv.
I am not sure about the sk andro and thus better mark them as fuzzy.
GnuPG-bug-id: 3619
Signed-off-by: Werner Koch <wk@gnupg.org>
* po/ja.po: Fix message with no "%s".
--
Backport of master commit from: 77e2fcb4ff
The wrong message caused segmentation fault for key generation when
no expiration is specified.
GnuPG-bug-id: 3619
Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>
* g10/trustdb.c (sanitize_regexp): Only escape operators.
--
Backport from master commit:
ccf3ba9208
To sanitize a regular expression, quoting by backslash should be only
done for defined characters. POSIX defines 12 characters including
dot and backslash.
Quoting other characters is wrong, in two ways; It may build an
operator like: \b, \s, \w when using GNU library. Case ignored match
doesn't work, because quoting lower letter means literally and no
much to upper letter.
GnuPG-bug-id: 2923
Co-authored-by: Damien Goutte-Gattat <dgouttegattat@incenp.org>
Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>
--
In https://bugs.debian.org/881393 , Jonas Smedegaard reports:
> In option number 1, the word "komprimeret" means "compressed".
>
> I am pretty sure it should say "kompromitteret" instead, which means
> "compromised".
Debian-Bug-Id: 881393
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
--
All /dev/*random devices have been equivalent since OpenBSD 4.9, on
purpose (/dev/random doesn't block). /dev/srandom has been removed in
the OpenBSD 6.3 development cycle, /dev/arandom will likely follow.
Signed-off-by: Jeremie Courreges-Anglas <jca@wxcvbn.org>
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>
Werner Koch