* 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 0835d2f44ef62eab51fce6a927908f544e01cf8f)
* 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 382ba4b137b42d5f25a7e256bb7c053ee5ac7b64)
* g10/keygen.c (ask_algo): Add list of strings.
--
Signed-off-by: Werner Koch <wk@gnupg.org>
(backported from commit b1d5ed6ac842469afcb84868d0f6641dc286a6c7)
* 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 ae3d1bbb65b65cf3c57bb14886be120f5e31635d)
* 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 da66ad5bba4215b9ddd0cb927a89aa75355632aa 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 596ae9f5433ca3b0e01f7acbe06fd2e424c42ae8)
* 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 0988764397f99db4efef1eabcdb8072d6159af76)
* 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 32e85668b82f6fbcb824eea9548970804fb41d9e)
* 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 69384568f66a48eff3968bb1714aa13925580e9f)
* 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 ffc2307843ce6c4ac3c8d99ba8c70ffa1ae28e39)
* 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 534e2876acc05f9f8d9b54c18511fe768d77dfb5 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.
--
c76117f8b0165fe5cec5e7f234f55f5a4cd7f0ab 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 c76117f8b0165fe5cec5e7f234f55f5a4cd7f0ab, 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 d33246700578cddd1cb8ed8164cfbba50aba4ef3)
* 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 371c2b14b0347209efd23b4e54e1981a12d7aeab
with parts of 20c6da50d4f6264d26d113d7de606971f719a0ca 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
23191d7851eae2217ecdac6484349849a24fd94a 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.
* g10/parse-packet.c (parse_attribute): Avoid xmalloc failure and cap
size of packet.
--
Tavis Ormandy reported a fatal error for attribute packets with a zero
length payload. This is due to a check in Libgcrypt's xmalloc which
rejects a malloc(0) instead of silently allocating 1 byte. The fix is
obvious.
In addition we cap the size of attribute packets similar to what we do
with user id packets. OpenPGP keys are not the proper way to store
movies.
Resolved conflicts:
g10/parse-packet.c - indentation. Use plain fprintf.
* g10/keygen.c (gen_elg): Enforce keysize 1024 to 4096.
(gen_rsa): Enforce keysize 1024 to 4096.
(gen_dsa): Enforce keysize 768 to 3072.
--
It was possible to create 16k RSA keys in batch mode. In addition to the
silliness of such keys, they have the major drawback that under GnuPG
and Libgcrypt, with their limited amount of specially secured memory
areas, the use of such keys may lead to an "out of secure memory"
condition.
* g10/keyserver.c (ks_retrieval_filter_arg_s): new.
(keyserver_retrieval_filter): Use new struct and check all
descriptions.
(keyserver_spawn): Pass filter arg suing the new struct.
--
This is a fix for commit 5e933008.
The old code did only work for a single key. It failed as soon as
several keys are specified ("gpg --refresh-keys" or "gpg --recv-key A
B C").
--
GnuPG-bug-id: 1561
Note that this is not a complete solution. The libgpg-error include
directory has now a higher preference but ld may not pick up the right
library if another one is installed. The problem is that the -L
option and the -l options are not emitted separately by
gpg-error-config.
* g10/pkclist.c (build_pk_list): Use more specific reasons codes for
INV_RECP.
--
GnuPG-bug-id: 1650
Note that this patch is a bit more limited than the one in 2.1.
* g10/main.h (import_filter_t): New.
* g10/import.c (import): Add filter callbacks to param list.
(import_one): Ditto.
(import_secret_one): Ditto.
(import_keys_internal): Ditto.
(import_keys_stream): Ditto.
* g10/keyserver.c (keyserver_retrieval_filter): New.
(keyserver_spawn): Pass filter to import_keys_stream()
--
These changes introduces import functions that apply a constraining
filter to imported keys. These filters can verify the fingerprints of
the keys returned before importing them into the keyring, ensuring that
the keys fetched from the keyserver are in fact those selected by the
user beforehand.
Signed-off-by: Stefan Tomanek <tomanek@internet-sicherheit.de>
Re-indention and minor changes by wk.
Resolved conflicts:
g10/import.c
g10/keyserver.c
g10/main.h
* g10/compress.c (do_uncompress): Limit the number of extra FF bytes.
--
A packet like (a3 01 5b ff) leads to an infinite loop. Using
--max-output won't help if it is a partial packet. This patch
actually fixes a regression introduced on 1999-05-31 (c34c6769).
Actually it would be sufficient to stuff just one extra 0xff byte.
Given that this problem popped up only after 15 years, I feel safer to
allow for a very few FF bytes.
Thanks to Olivier Levillain and Florian Maury for their detailed
report.
* g10/photoid.c (show_photos): Set namehash.
* g10/misc.c (pct_expando): Add "%U" expando.
--
This makes is possible to extract all photos ids from a key to
different files.
(cherry picked from commit e184a11f94e2d41cd9266484542631bec23628b5)
Resolved conflicts:
g10/photoid.c - whitespaces
* g10/decrypt-data.c (decrypt_data): Do not distinguish between a bad
MDC packer header and a bad MDC.
--
The separate diagnostic was introduced for debugging a problems. For
explaining an MDC error a single error message is easier to
understand.
* g10/keygen.c (ask_expire_interval): Get the current time after the
prompt.
--
This almost avoid that an entered full ISO timestamp is not used as
given but off by the time the user required to enter the timestamp.
GnuPG-bug-id: 1639
* g10/parse-packet.c (mpi_read): Change error message on overflow.
--
This gets gpg 2.x in sync to what gpg 1.4 does. No need to die for a
broken MPI.
GnuPG-bug-id: 1593
* g10/mainproc.c (list_node): Rework.
--
The old code still merged the first user id into the key packet line
which resulted in all kind of complexity. --fixed-list-mode is
meanwhile the default and thus we also change this part of the code.
GnuPG-bug-id: 1640
* g10/getkey.c (get_user_id): Do not call xmalloc with 0.
* common/xmalloc.c (xmalloc, xcalloc): Take extra precaution not to
pass 0 to the arguments.
--
The problem did not occur in 1.x because over there the xmalloc makes
sure to allocate at least one byte. With 2.x for most calls the
xmalloc of Libgcrypt is used and Libgcrypt returns an error insteead
of silent allocating a byte. Thus gpg 2.x bailed out with an
"Fatal: out of core while allocating 0 bytes".
The extra code in xmalloc.c is for more robustness for the other
xmalloc calls.
(cherry picked from commit 99972bd6e9abea71f270284f49997de5f00208af)
Resolved conflicts:
g10/getkey.c - ignore whitespace changes.
* g10/call-agent.c (check_hijacking): New.
(start_agent): Call it.
(membuf_data_cb, default_inq_cb): Move more to the top.
--
Note that GUIs may use the gpg status line
[GNUPG:] ERROR check_hijacking 33554509
to detect this and print an appropriate warning.
* g10/misc.c (pubkey_get_npkey): Map RSA_E and RSA_S to RSA.
(pubkey_get_nskey): Ditto.
(pubkey_get_nsig): Ditto.
(pubkey_get_nenc): Ditto.
(pubkey_nbits): Take care of RSA_E and RSA_S.
--
The problem was that parse_key did not know about RSA_S and thus used
an opaque MPI which later crashed Libgcrypt. It is possible to fix
that also in Libgcrypt but we better do it here as well.
A test key using RSA_S is 0x98EEB6F7D87171CF.
Reported-by: Hanno Böck
* g10/cpr.c (write_status_strings): New.
(write_status_text): Replace code by a call to write_status_strings.
* g10/mainproc.c (proc_encrypted): Remove show_session_key code.
* g10/decrypt-data.c (decrypt_data): Add new show_session_key code.
--
This feature can be used to return the session key for just a part of
a file. For example to downloading just the first 32k of a huge file,
decrypting that incomplete part and while ignoring all the errors
break out the session key. The session key may then be used on the
server to decrypt the entire file without the need to have the private
key on the server.
GnuPG-bug-id: 1389
Signed-off-by: Werner Koch <wk@gnupg.org>
(cherry picked from commit 101a54add351ff62793cbfbf3877787c4791f833)
Resolved Conflicts:
doc/DETAILS - removed
g10/cpr.c - replace estream fucntion by stdio.
g10/mainproc.c - Adjust for changed calling convention.
* g10/tdbio.c (tdbio_set_dbname): Add arg R_NOFILE.
* g10/trustdb.c (trustdb_args): Add field no_trustdb.
(init_trustdb): Set that field.
(revalidation_mark): Take care of a nonexistent trustdb file.
(read_trust_options): Ditto.
(get_ownertrust): Ditto.
(get_min_ownertrust): Ditto.
(update_ownertrust): Ditto.
(update_min_ownertrust): Ditto.
(clear_ownertrusts): Ditto.
(cache_disabled_value): Ditto.
(check_trustdb_stale): Ditto.
(get_validity): Ditto.
* g10/gpg.c (main): Do not create a trustdb with most commands for
trust-model always.
--
This slightly changes the semantics of most commands in that they
won't create a trustdb if --trust-model=always is used. It just does
not make sense to create a trustdb if there is no need for it.
Signed-off-by: Werner Koch <wk@gnupg.org>
* g10/misc.c (openpgp_pk_algo_name): New. Replace all calls in g10/
to gcry_pk_algo_name by a call to this function.
(map_pk_openpgp_to_gcry): Map algo PUBKEY_ALGO_ELGAMAL_E to GCRY_PK_ELG.
(openpgp_pk_test_algo): Use PUBKEY_ALGO_ELGAMAL_E instead of
GCRY_PK_ELG_E. Return an error for ECC algos.
(openpgp_pk_test_algo2): Return an error for ECC algos.
* g10/gpg.c (build_list): Avoid printing ECC two times.
* include/cipher.h: Do not use GCRY_PK_* macros for PUBKEY_ALGO_*.
--
Due to recent changes to adjust for use with Libgcrypt 1.6, "gpg
--version" printed two question marks. This patches fixes that and
also make sure that gpg does advertise any ECC features. The patch in
build_list is not really needed.
Signed-off-by: Werner Koch <wk@gnupg.org>
