* g10/delkey.c: Include shareddefs.h.
(delete_keys): Print a hint.
--
The option --yes has some side-effects so it is not desirable to use it
automatically. The code in master (2.3) has special treatment of
confirm messages and thus this patch is only for 2.2.
GnuPG-bug-id: 4667
Signed-off-by: Werner Koch <wk@gnupg.org>
* common/userids.c (classify_user_id): Do not set the EXACT flag in
the default case.
* g10/export.c (exact_subkey_match_p): Make static,
* g10/delkey.c (do_delete_key): Implement subkey only deleting.
--
GnuPG-bug-id: 4457
* g10/delkey.c (do_delete_key): Don't delete the keyblock on dry runs.
Do not clear the ownertrust. Do not let the agent delete the key.
--
Co-authored-by: Matheus Afonso Martins Moreira
Signed-off-by: Werner Koch <wk@gnupg.org>
--
For proper operations as a server we need to avoid global variables.
Thus we need to pass the session state CTRL to most functions. Quite
a lot of changes but fortunately straightforward to do.
Signed-off-by: Werner Koch <wk@gnupg.org>
* agent/command.c (cmd_delete_key): Make the --force option depend on
--disallow-loopback-passphrase.
* g10/call-agent.c (agent_delete_key): Add arg FORCE.
* g10/delkey.c (do_delete_key): Pass opt.answer_yes to
agent_delete_key.
--
Unless the agent has been configured with
--disallow-loopback-passpharse an unattended deletion of a secret key
is now possible with gpg by using --batch _and_ --yes.
Signed-off-by: Werner Koch <wk@gnupg.org>
* g10/delkey.c (do_delete_key): Write ERROR status code with the error
location "delete_key.secret", when the user cancelled the operation on
Pinentry.
--
I changed the original patch to emit the full gpg_error_t code. -wk
* g10/keydb.c (keydb_new): Print an error message if needed. Also use
xtrycalloc because we return an error anyway.
* g10/delkey.c (do_delete_key): Handle error retruned by keydb_new.
* g10/export.c (do_export_stream): Ditto.
* g10/getkey.c (get_pubkey): Ditto.
(get_pubkey_fast): Ditto.
(get_pubkeyblock): Ditto.
(get_seckey): Ditto.
(key_byname): Ditto.
(get_pubkey_byfprint): Ditto.
(get_pubkey_byfprint_fast): Ditto.
(parse_def_secret_key): Ditto.
(have_secret_key_with_kid): Ditto.
* g10/import.c (import_one): Ditto.
(import_revoke_cert): Ditto.
* g10/keyedit.c (keyedit_quick_adduid): Ditto.
* g10/keygen.c (quick_generate_keypair): Ditto.
(do_generate_keypair): Ditto.
* g10/trustdb.c (validate_keys): Ditto.
* g10/keyserver.c (keyidlist): Ditto.
* g10/revoke.c (gen_desig_revoke): Ditto.
(gen_revoke): Ditto.
* g10/gpg.c (check_user_ids): Ditto.
(main): Do not print an error message for keydb_new error.
* g10/keylist.c (list_all): Use actual error code returned by
keydb_new.
* g10/t-keydb-get-keyblock.c (do_test): Abort on keydb_new error.
* g10/t-keydb.c (do_test): Ditto.
* g10/keyring.c (keyring_new): Actually return an error so that the
existing keydb_new error checking makes sense for a keyring resource.
(keyring_rebuild_cache): Take care of keyring_new returning an error.
--
Commit 04a6b903 changed keydb_new to return an error. However the
error was not checked at most places which we fix with this patch. To
make things easier keydb_new prints an error message itself.
Signed-off-by: Werner Koch <wk@gnupg.org>
Since 2009-12-08 gpg was not able to find email addresses indicated
by a leading '<'. This happened when I merged the user id
classification code of gpgsm and gpg.
We better do this once and for all instead of cluttering all future
commits with diffs of trailing white spaces. In the majority of cases
blank or single lines are affected and thus this change won't disturb
a git blame too much. For future commits the pre-commit scripts
checks that this won't happen again.
* card-util.c (card_status): New.
* call-agent.c (learn_status_cb): Parse more information.
* keylist.c (print_pubkey_info): Add FP arg for optinal printing
to a stream. Changed all callers.
to libgcrypt functions, using shared error codes from libgpg-error,
replacing the old functions we used to have in ../util by those in
../jnlib and ../common, renaming the malloc functions and a couple of
types. Note, that not all changes are listed below becuause they are
too similar and done at far too many places. As of today the code
builds using the current libgcrypt from CVS but it is very unlikely
that it actually works.
Werner Koch