* g10/keylist.c (print_pubkey_info): Print either "pub" or "sub".
--
This now prints "sub" if the first used card key is actually a subkey.
Signed-off-by: Werner Koch <wk@gnupg.org>
GnuPG-bug-id: 2079
(backported from master 874ef16e70)
* common/status.h (STATUS_FAILURE): New.
* g10/cpr.c (write_status_failure): New.
* g10/gpg.c (main): Call write_status_failure for all commands which
print an error message here.
--
This status line can be used similar to the error code returned by
commands send over the Assuan interface in gpgsm. We don't emit them
in gpgsm because there we already have that Assuan interface to return
proper error code. This change helps GPGME to return better error
codes.
(backported from master 9cdff09743)
Signed-off-by: Werner Koch <wk@gnupg.org>
* g10/trustdb.c (validate_keys): Call dump_key_array only in debug
mode.
--
I guess that is a left-over from an early attempt to output
information on the trustdb for use by other tools. Maybe related to
the former --list-trust-path command. Sending it to stdout is
probably useful so we do this now only in debug mode.
Signed-off-by: Werner Koch <wk@gnupg.org>
Backported to STABLE-BRANCH-2-0 from
b03a264729 by dkg
* g10/gpg.c (opts): Make --no-sig-create-check a NOP.
* g10/options.h (struct opt): Remove field "no_sig_create_check".
* g10/sign.c (do_sign): Do not run the create check for Libgcrypt 1.7.
Signed-off-by: Werner Koch <wk@gnupg.org>
* g10/getkey.c (free_akl): If AKL is NULL, just return.
--
Backported from f2ee673c99. Note:
unlike in 2.1, in 2.0 this bug is not (currently) triggered since
parse_auto_key_locate doesn't recognize "clear".
Signed-off-by: Neal H. Walfield <neal@g10code.com>.
Reported-by: Sami Farin.
GnuPG-bug-id: 2045
* g10/keyid.c (fingerprint_from_pk): Allow PGP-2 fingerprints.
* g10/keylist.c (print_fingerprint): Print a warning after a PGP-2
fingerprint.
--
Printing all zeroes for a PGP-2 (v3 key) fingerprint has the problem
that frontends (or the user) may use that fingerprint to lookup a key
and gpg will return all PGP2 keys. They may then show a different
PGP-2 key than the one actually used for a signature. This is worse
than displaying a weak fingerprint.
GnuPG-bug-id: 2000
Signed-off-by: Werner Koch <wk@gnupg.org>
* g10/seckey-cert.c (do_check): Handle a NULL opaque MPI.
--
This patch extends b2d9d10 for secret keys. The problem is that we
changed the semantics so that opaque MPIs may be NULL with a bit
length. This patch is not required in GnuPG 2 because we do not use
secret keys there.
Signed-off-by: Werner Koch <wk@gnupg.org>
* g10/build-packet.c (do_secret_key): Check for NULL return from
gcry_mpi_get_opaque.
* g10/keyid.c (hash_public_key): Ditto.
--
This is a backport of 76c8122adf from
master to the STABLE-BRANCH-2-0
On the STABLE-BRANCH-2-0, we may also want to patch g10/seckey-cert.c,
but that has not been done in this patch.
This fix extends commmit 0835d2f44e.
gpg2 --export --no-default-keyring --keyring TESTDATA
With TESTDATA being below after unpacking.
-----BEGIN PGP ARMORED FILE-----
mBMEhdkMmS8BcX8F//8F5voEhQAQmBMEnAAAZwAAo4D/f/8EhQAAAIAEnP8EhQAQ
iBMEnP8AAAAABf8jIID///8EhQYQmBMEnIUAEIgTBKT/AAAAAAUAACCA/f//BIUA
EJgTBJx/AP8ABPPzBJx/AP8ABPPz
=2yE0
-----END PGP ARMORED FILE-----
Reported-by: Jodie Cunningham
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
* g10/getkey.c (get_seckey): Return G10ERR_NO_PUBKEY when it's not
exact match.
--
(ported from 1.4 commit b3fd30451a)
In the situation of corrupted .gnupg/ where only private subkey is
available but no corresponding public key of the subkey, the code
returned public primary key which caused mysterious error (for a
user). This fix detects an error earlier.
GnuPG-bug-id: 1422
Debian-Bug-Id: #638619
* g10/free-packet.c (cmp_public_keys, cmp_secret_keys): Compare opaque
data at the first entry of the array when it's unknown algo.
* configure.ac (NEED_LIBGCRYPT_VERSION): Require 1.5.0.
--
GnuPG-bug-id: 1962
* g10/mainproc.c (check_sig_and_print): Emit STATUS_NEWSIG.
--
gpgsm does this for a long time but somehow it never made it into gpg.
Signed-off-by: Werner Koch <wk@gnupg.org>
(backported from 2.1 commit e7ddaad0fd)
* g10/parse-packet.c (parse_key): Check PKTLEN before calling mpi_read
et al.
--
Due to the missing length checks PKTLEN may turn negative. Because
PKTLEN is an unsigned int the malloc in read_rest would try to malloc
a too large number and terminate the process with "error reading rest
of packet: Cannot allocate memory".
Reported-by: Hanno Böck.
Signed-off-by: Werner Koch <wk@gnupg.org>
(backported from 2.1 commit d901efceba)
* g10/armor.c (parse_key_failed_line): New.
(check_input): Watch out for gpgkeys_ error lines.
* g10/filter.h (armor_filter_context_t): Add field key_failed_code.
* g10/import.c (import): Add arg r_gpgkeys_err.
(import_keys_internal): Ditto.
(import_keys_stream): Ditto.
* g10/keyserver.c (keyserver_errstr): New.
(keyserver_spawn): Detect "KEY " lines while sending. Get gpgkeys_err
while receiving keys.
(keyserver_work): Add kludge for better error messages.
--
GnuPG-bug-id: 1832
Note that these changes can be backported to 1.4 but they don't make
sense for 2.1 due to the removal of the keyserver helpers. The error
reporting could be improved even more but given that this is an old
GnuPG branch it is not justified to put too much effort into it.
Signed-off-by: Werner Koch <wk@gnupg.org>
* include/host2net.h (buf16_to_ulong, buf16_to_uint): New.
(buf16_to_ushort, buf16_to_u16): New.
(buf32_to_size_t, buf32_to_ulong, buf32_to_uint, buf32_to_u32): New.
--
This fixes sign extension on shift problems. Hanno Böck found a case
with an invalid read due to this problem. To fix that almost all uses
of "<< 24" and "<< 8" are changed by this patch to use an inline
function from host2net.h.
(back ported from commit 2183683bd6)
Signed-off-by: Werner Koch <wk@gnupg.org>
* g10/keyring.c (keyring_get_keyblock): Whitelist allowed packet
types.
--
The keyring DB code did not reject packets which don't belong into a
keyring. If for example the keyblock contains a literal data packet
it is expected that the processing code stops at the data packet and
reads from the input stream which is referenced from the data packets.
Obviously the keyring processing code does not and cannot do that.
However, when exporting this messes up the IOBUF and leads to an
invalid read of sizeof (int).
We now skip all packets which are not allowed in a keyring.
Reported-by: Hanno Böck <hanno@hboeck.de>
(back ported from commit f0f71a721c)
* g10/build-packet.c (write_fake_data): Take care of a NULL stored as
opaque MPI.
--
Reported-by: Hanno Böck <hanno@hboeck.de>
(back ported from commit 0835d2f44e)
* g10/parse-packet.c (MAX_KEY_PACKET_LENGTH): New.
(MAX_UID_PACKET_LENGTH): New.
(MAX_COMMENT_PACKET_LENGTH): New.
(MAX_ATTR_PACKET_LENGTH): New.
(parse_key): Limit the size of a key packet to 256k.
(parse_user_id): Use macro for the packet size limit.
(parse_attribute): Ditto.
(parse_comment): Ditto.
--
Without that it is possible to force gpg to allocate large amounts of
memory by using a bad encoded MPI. This would be an too easy DoS.
Another way to mitigate would be to change the MPI read function to
allocate memory dynamically while reading the MPI. However, that
complicates and possibly slows down the code. A too large key packet
is in any case a sign for broken data and thus gpg should not use it.
Reported-by: Hanno Böck
GnuPG-bug-id: 1823
Signed-off-by: Werner Koch <wk@gnupg.org>
(back ported from commit 382ba4b137)
* g10/keyedit.c (subkey_expire_warning): New.
keyedit_menu): Call it when needed.
--
GnuPG-bug-id: 1715
The heuristic to detect a problem is not very advanced but it should
catch the most common cases.
(backported from commit ae3d1bbb65)
* g10/parse-packet.c (can_handle_critical): Check content length
before calling can_handle_critical_notation.
--
The problem was found by Jan Bee and gniibe proposed the used fix.
Thanks.
This bug can't be exploited: Only if the announced length of the
notation is 21 or 32 a memcmp against fixed strings using that length
would be done. The compared data is followed by the actual signature
and thus it is highly likely that not even read of unallocated memory
will happen. Nevertheless such a bug needs to be fixed.
Signed-off-by: Werner Koch <wk@gnupg.org>
* g10/keygen.c (generate_subkeypair): Release DEK soon.
--
This fixes the out_of_core error in the test case of adding
RSA-4096 subkey to RSA-4096 primary key with configuration:
s2k-cipher-algo S10
Debian-bug-id: 772780
Cherry-picked da66ad5bba from
STABLE-BRANCH-1-4 branch.
* g10/parse-packet.c (dump_sig_subpkt): Print regex subpacket
sanitized.
--
We may not use "%s" to print an arbitrary buffer. At least "%.*s"
should have been used. However, it is in general preferable to escape
control characters while printf user data.
Reported-by: Hanno Böck
Signed-off-by: Werner Koch <wk@gnupg.org>
(backported from commit 596ae9f543)
* g10/parse-packet.c (parse_attribute_subpkts): Check that the
attribute packet is large enough for the subpacket type.
--
Reported-by: Hanno Böck
Signed-off-by: Werner Koch <wk@gnupg.org>
(backported from commit 0988764397)
* g10/mainproc.c (proc_encrypted): Take care of canceled passpharse
entry.
--
GnuPG-bug-id: 1761
Signed-off-by: Werner Koch <wk@gnupg.org>
(backported from commit 32e85668b8)
* g10/openfile.c (open_sigfile): Factor some code out to ...
(get_matching_datafile): new function.
* g10/plaintext.c (hash_datafiles): Do not try to find matching file
in batch mode.
* g10/mainproc.c (check_sig_and_print): Print a warning if a possibly
matching data file is not used by a standard signatures.
--
Allowing to use the abbreviated form for detached signatures is a long
standing bug which has only been noticed by the public with the
release of 2.1.0. :-(
What we do is to remove the ability to check detached signature in
--batch using the one file abbreviated mode. This should exhibit
problems in scripts which use this insecure practice. We also print a
warning if a matching data file exists but was not considered because
the detached signature was actually a standard signature:
gpgv: Good signature from "Werner Koch (dist sig)"
gpgv: WARNING: not a detached signature; \
file 'gnupg-2.1.0.tar.bz2' was NOT verified!
We can only print a warning because it is possible that a standard
signature is indeed to be verified but by coincidence a file with a
matching name is stored alongside the standard signature.
Reported-by: Simon Nicolussi (to gnupg-users on Nov 7)
Signed-off-by: Werner Koch <wk@gnupg.org>
(backported from commit 69384568f6)
* g10/options.h (IMPORT_KEEP_OWNERTTRUST): New.
* g10/import.c (parse_import_options): Add "keep-ownertrust".
(import_one): Act upon new option.
--
This option is in particular useful to convert from a pubring.gpg to
the new pubring.kbx in GnuPG 2.1 or vice versa:
gpg1 --export | gpg2 --import-options keep-ownertrust --import
(cherry-picked from commit ffc2307843)
* g10/keyid.c (fingerprint_from_pk): Show v3 fingerprints as all zero.
--
MD5 is considered broken for a long time now. To make it easier for
users to notice that a listing shows a v3 key, the fingerprint is now
displayed as 16 zero bytes unless --allow-weak-digest-algos is active.
Signed-off-by: Werner Koch <wk@gnupg.org>
* configure.ac: Added --enable-large-secmem option.
* g10/options.h: Add opt.flags.large_rsa.
* g10/gpg.c: Contingent on configure option: adjust secmem size,
add gpg --enable-large-rsa, bound to opt.flags.large_rsa.
* g10/keygen.c: Adjust max RSA size based on opt.flags.large_rsa
* doc/gpg.texi: Document --enable-large-rsa.
--
This is a cherry-pick of 534e2876ac from
STABLE-BRANCH-1-4 against STABLE-BRANCH-2-0
Some older implementations built and used RSA keys up to 16Kib, but
the larger secret keys now fail when used by more recent GnuPG, due to
secure memory limitations.
Building with ./configure --enable-large-secmem will make gpg
capable of working with those secret keys, as well as permitting the
use of a new gpg option --enable-large-rsa, which let gpg generate RSA
keys up to 8Kib when used with --batch --gen-key.
Debian-bug-id: 739424
Minor edits by wk.
GnuPG-bug-id: 1732
* g10/gpg.c: Cleanup argument parsing.
--
c76117f8b0 mistakenly marked
compress-sigs and compress-keys as no-ops on the 2.0.x branch.
These options still have an effect on the 2.0.x branch, and the
duplicate declaration also causes the gpg argument parser to fail when
shortened versions of the option are present, like:
gpg: option "--compress-k" is ambiguous
* g10/gpg.c: Cleanup argument parsing.
--
With c76117f8b0, the GnuPG 2.0.x branch
accidentally introduced a second (identical) argument parser for both
--sk-comments, and for --no-sk-comments.
This caused short versions (e.g. omitting the trailing "s", as gpgme
does) of either command to fail with:
gpg: option "--sk-comment" is ambiguous
* g10/main.h (DEFAULT_DIGEST_ALGO): Use SHA256 in --gnupg and SHA1 in
strict RFC or PGP modes.
* g10/sign.c (make_keysig_packet): Use DEFAULT_DIGEST_ALGO also for
RSA key signatures.
--
(Backported from commit d332467005)
* g10/gpg.c: Add config options that should belong in scdaemon.conf
* g10/main.h, g10/misc.c (obsolete_scdaemon_option): New.
--
In gpg2, the following options are only relevant for scdaemon:
reader-port
ctapi-driver
pcsc-driver
disable-ccid
but in gpg1, they are options for gpg itself.
Some users of gpg1 might have these options in their
~/.gnupg/gpg.conf, which causes gpg2 to fail hard if it reads that
config file.
gpg2 should not fail hard, though giving a warning (and suggesting a
move to scdaemon.conf) seems OK.
This patch does *not* reintroduce any documentation for these options
in gpg.texi, even to indicate that they are "dummy" options, since
scdaemon.texi contains the appropriate documentation.
Debian-bug-id: 762844
Program names factored out from obsolete_scdaemon_option to make
reuse without new translations easier. -wk
This is a backport of commit 371c2b14b0
with parts of 20c6da50d4 but without those
which would change existing translated strings. -wk
* g10/trustdb.c (clear_ownertrusts): Init trustdb.
--
This was fixed in 1.4 branch in commit
23191d7851 but was not applied to the
2.0 branch that exhibits the same problem. This is actually a hack
to fix a bug introduced with commit 2528178.
GnuPG-bug-id: 1622
* g10/passphrase.c (passphrase_get): Replace sprintf by xasprintf.
--
Without that at least the French translation does not always work
because it requires positional parameters. Windows for example does
not support them as they are not defined by C99 but by POSIX.
