* g10/skclist.c (enum_secret_keys): Use SK_LIST instead of pubkey_t.
--
The use of pubkey_t was wrong. The use is just a list of keys, not
with keyblock. With SK_LIST, release_sk_list releases memory by
free_public_key.
Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>
* g10/skclist.c (enum_secret_keys): Don't forget to call
free_public_key in the error return paths.
--
Reported-by: Philippe Antoine
GnuPG-bug-id: 4140
Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>
* g10/call-agent.h (agent_card_info_s): Rename the "*valid" fields to
"*len".
* g10/call-agent.c (unhexify_fpr): Change to take a FPRLEN and to
return the actual length.
(agent_release_card_info): Adjust for these changes.
* g10/card-util.c (print_sha1_fpr): Rename to print_shax_fpr and add
arg FPRLEN. Change all callers to pass the length.
(print_sha1_fpr_colon): Rename to print_shax_fpr_colon and add arg
FPRLEN. Change all callers to pass the length.
(fpr_is_zero): Add arg FPRLEN.
(fpr_is_ff): Ditto.
(show_card_key_info): Use the new functions.
* g10/skclist.c (enum_secret_keys): Use MAX_FINGERPRINT_LEN.
--
This is not needed right now but we should get rid of all hard coded
fingerprint lengths. Thus this change.
Signed-off-by: Werner Koch <wk@gnupg.org>
* g10/skclist.c (enum_secret_keys): Since "KEY-FPR" returns
fingerprint in binary, change it to hex string.
Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>
* g10/getkey.c (enum_secret_keys): Move to...
* g10/skclist.c (enum_secret_keys): ... here.
--
The function enum_secret_keys is not used by gpgv.c, but it is in
getkey.c. Extending enum_secret_keys will require change of gpgv.c,
so moving the function to the file for gpg is better.
Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>
* g10/call-agent.c (warn_version_mismatch): Revert.
(start_agent): Suppress version mismatch if relevant.
* g10/getkey.c (get_seckey_default_or_card): New.
* g10/skclist.c (build_sk_list): Use get_seckey_default_or_card.
--
The change of 97a2394, which prefers available card than default key
specified is too strong.
Fixes-commit: 97a2394eca
Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>
* g10/skclist.c (build_sk_list): Ask gpg-agent if card is available.
Then, use the card key if any.
--
GnuPG-bug-id: 1983
Signed-off-by: NIIBE Yutaka <gniibe@fsij.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>
* g10/gpg.c (struct result): Move from here...
* g10/keydb.h (struct pubkey): ... to here. Update users.
* g10/gpg.c (check_user_ids): Move from here...
* g10/getkey.c (get_pubkeys): ... to here. Update users. Use
get_pubkey_byname to look up the keys (this also prunes invalid keys).
(pubkey_free): New function.
(pubkeys_free): New function.
* g10/gpg.c (main): Don't check for ambiguous key specifications.
--
Signed-off-by: Neal H. Walfield <neal@g10code.com>
Regression-due-to: e8c53fc
This change not only moves the checks for ambiguous key specifications
from gpg.c to getkey.c, it also disables the checks. The old code was
too divorced from the actual key lookups and, as such, it reproduced
the logic. Unfortunately, the reproduction was a poor one: despite
fixing some inconsistencies (e.g., 10cca02), it still didn't deal with
group expansion or the auto key lookup functionality. Given the
amount of instability introduced by this change, we (Neal & Werner)
decided it is better to defer introducing this functionality until
2.3.
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.
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.
