gpg: Avoid importing secret keys if the keyblock is not valid.2019-03-15T18:50:37ZWerner Kochwk@gnupg.orgWerner Kochwk@gnupg.org2019-03-15T18:50:37Zhttp://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=f799e9728bcadb3d4148a47848c78c5647860ea4

gpg: Avoid importing secret keys if the keyblock is not valid.
* g10/keydb.h (struct kbnode_struct): Replace unused field RECNO by
new field TAG.
* g10/kbnode.c (alloc_node): Change accordingly.
* g10/import.c (import_one): Add arg r_valid.
(sec_to_pub_keyblock): Set tags.
(resync_sec_with_pub_keyblock): New.
(import_secret_one): Change return code to gpg_error_t. Return an
error code if sec_to_pub_keyblock failed. Resync secret keyblock.
--
When importing an invalid secret key ring for example without key
binding signatures or no UIDs, gpg used to let gpg-agent store the
secret keys anyway. This is clearly a bug because the diagnostics
before claimed that for example the subkeys have been skipped.
Importing the secret key parameters then anyway is surprising in
particular because a gpg -k does not show the key. After importing
the public key the secret keys suddenly showed up.
This changes the behaviour of
GnuPG-bug-id: 4392
to me more consistent but is not a solution to the actual bug.
Caution: The ecc.scm test now fails because two of the sample keys
don't have binding signatures.
Signed-off-by: Werner Koch <wk@gnupg.org>

gpgscm: Build well even if NDEBUG defined.2019-02-25T01:44:16ZNIIBE Yutakagniibe@fsij.orgNIIBE Yutakagniibe@fsij.org2019-02-25T01:44:16Zhttp://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=e140c6d4f581be1a60a34b67b16430452f3987e8

gpg: New maintainer option --debug-set-iobuf-size.
* g10/gpg.c (opts): Add new option.
(opt_set_iobuf_size): New var.
(set_debug): Set the option.
* tests/openpgp/armor.scm: Use this option to revert the buffer size
to the one which used to exhibit the tested bugs.
Signed-off-by: Werner Koch <wk@gnupg.org>

tests: Run the trust-pgp-4 test again.
* tests/openpgp/Makefile.am (XTESTS): Add trust-pgp-4.scm.
(EXTRA_DIST): Remove the test file from EXTRA_DIST.
--
Now that issue 2923 is fixed, the trust-pgp-4 test passes as
expected and we can enable it again. That should help prevent
a future regression on this issue.
Signed-off-by: Damien Goutte-Gattat <dgouttegattat@incenp.org>

agent, tests: Support --disable-scdaemon build case.
* agent/command.c (cmd_scd): Support !BUILD_WITH_SCDAEMON.
* tests/openpgp/defs.scm (create-gpghome): Likewise.
* tests/gpgsm/gpgsm-defs.scm (create-gpgsmhome): Likewise.
--
We could modify gpg-agent to remove all support of scdaemon, with no
inclusion of call-scd.c, divert-scd.c, and learncard.c, but it would
not be worth to do that.
GnuPG-bug-id: 3316
Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>

agent, tests: Support --disable-scdaemon build case.
* agent/command.c (cmd_scd): Support !BUILD_WITH_SCDAEMON.
* tests/openpgp/defs.scm (create-gpghome): Likewise.
* tests/gpgsm/gpgsm-defs.scm (create-gpgsmhome): Likewise.
--
We could modify gpg-agent to remove all support of scdaemon, with no
inclusion of call-scd.c, divert-scd.c, and learncard.c, but it would
not be worth to do that.
GnuPG-bug-id: 3316
Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>

tests: Fix a test which specifies expiration date.
* tests/openpgp/quick-key-manipulation.scm: Fix expiration time
comparison.
--
This is a bug fix for Amelia Earhart who is probably in UTC-12.
When expiration date is specified, GnuPG interprets it as noon of the
date in local time.
Before this fix, the test compared the value by 2145916800 which is
2038-01-01 00:00:00 in UTC with allowance of 1 day. When the test
was ran in UTC-12 timezone, it failed because of noon in the timezone
is midnight of the next day in UTC.
GnuPG-bug-id: 3393
Reported-by: Daniel Kahn Gillmor
Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>