--
Include <stdlib.h> for the exit function. This avoids a failing
GNUPG_CHECK_IPC check in case the compiler no longer supports implicit
function declarations.
Explicitly declare the return type of main as int. This too avoids
failures with future compilers.
* util/logger.c (log_inc_errorcount): Protect against overflow.
(g10_log_warning): Bumb error counter using the above function.
(g10_log_error): Ditto.
--
This is a similar patch we use in 2.2 and libgpg-error.
Signed-off-by: Werner Koch <wk@gnupg.org>
* 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 13f135c7a252cc46cff96e75968d92b6dc8dce1b)
* g10/compress.c (handle_compressed): Fix memory leak.
--
(backport from STABLE-BRANCH-2-2 commit:
c31abf84659dbda5503dd9f3aa3449520bcd1b84)
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: 77e2fcb4ffbad8577a2cf41f17bf92dec6a93ad8
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:
ccf3ba92087e79abdeaa0208795829b431c6f201
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
84ebf15b06e435453b2f58775f97a3a1c61a7e55)
--
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>
