* 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>
* g10/export.c (export_ssh_key): Also check the primary key.
--
If no suitable subkey was found for export, we now check whether the
primary key is suitable for export and export this one. Without this
change it was only possible to export the primary key by using the '!'
suffix in the key specification.
Also added a sample key for testing this.
GnuPG-bug-id: 2957
Signed-off-by: Werner Koch <wk@gnupg.org>
* g10/gpg.c (check_user_ids): If the search description is for an
exact match (a keyid or fingerprint that ends in '!'), then use the
matching key, not the primary key.
* tests/openpgp/Makefile.am (TESTS): Add use-exact-key.test.
(priv_keys): Add privkeys/00FE67F28A52A8AA08FFAED20AF832DA916D1985.asc,
privkeys/1DF48228FEFF3EC2481B106E0ACA8C465C662CC5.asc,
privkeys/A2832820DC9F40751BDCD375BB0945BA33EC6B4C.asc,
privkeys/ADE710D74409777B7729A7653373D820F67892E0.asc and
privkeys/CEFC51AF91F68A2904FBFF62C4F075A4785B803F.asc.
(sample_keys): Add
samplekeys/E657FB607BB4F21C90BB6651BC067AF28BC90111.asc.
* tests/openpgp/privkeys/00FE67F28A52A8AA08FFAED20AF832DA916D1985.asc:
New file.
* tests/openpgp/privkeys/1DF48228FEFF3EC2481B106E0ACA8C465C662CC5.asc:
New file.
* tests/openpgp/privkeys/A2832820DC9F40751BDCD375BB0945BA33EC6B4C.asc:
New file.
* tests/openpgp/privkeys/ADE710D74409777B7729A7653373D820F67892E0.asc:
New file.
* tests/openpgp/privkeys/CEFC51AF91F68A2904FBFF62C4F075A4785B803F.asc:
New file.
* tests/openpgp/samplekeys/E657FB607BB4F21C90BB6651BC067AF28BC90111.asc:
New file.
* tests/openpgp/use-exact-key.test: New file.
* tests/openpgp/version.test: Install the new private keys.
--
Signed-off-by: Neal H. Walfield <neal@g10code.com>
Reported-by: Reported-by: Kristian Fiskerstrand
<kristian.fiskerstrand@sumptuouscapital.com>
Fixes-commit: 10cca02
* common/openpgpdefs.h (PUBKEY_ALGO_EDDSA): Change to 22.
* g10/keygen.c (ask_curve): Reword the Curve25519 warning note.
--
In the hope that the IETF will eventually assign 22 for EdDSA using
the draft-koch-eddsa-for-openpgp-01 specs we start using this number.
The import test imports the keys as needed and because they are
passphrase protected we now need a pinentry script to convey the
passphrase to gpg-agent.
Import and export of secret keys does now work. Encryption has been
fixed to be compatible with the sample messages.
This version tests for new Libgcrypt function and thus needs to be
build with a new Libgcrypt installed.
