Without this patch, pk2 would be freed twice.
>From 2a18a4b757e0896e738fefbbaa8ff8c23a9edf89 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering@redhat.com>
Date: Tue, 20 Sep 2011 16:20:39 +0200
Subject: [PATCH] avoid use of freed pointer
If we free pk2 at the top of the for-loop, set it to NULL
so that we don't free it again just before returning.
* revoke.c (gen_desig_revoke): Don't use pk2 after freeing it.
When this mode is set an inquire will be sent to the client to retrieve
the passphrase. This adds a new inquire keyword "NEW_PASSPHRASE" that the
GENKEY and PASSWD commands use when generating a new key.
This should always work because the dirmngr asked us to validate the
given certificate. This should make OCSP configuration easier because
there is less requirement to install all certificates for Dirmngr and
gpgsm.
CAUTION: This code has not yet been tested.
This patch implementes a chunk mode to pass the key parameters from
scdaemon to gpg. This allows to pass arbitrary long key paremeters;
it is used for keys larger than 3072 bit.
Note: the card key generation in gpg is currently broken. The keys
are generated but it is not possible to create the self-signature
because at that time the gpg-agent does not yet know about the new
keys and thus can't divert the sign request to the card. We either
need to run the learn command right after calling agent_scd_genkey or
implement a way to sign using the currently inserted card. Another
option would be to get rid of agent_scd_genkey and implement the
feature directly in agent_genkey.
Returning -1 as an error code is not very clean given that gpg error
has more descriptive error codes. Thus we now return
GPG_ERR_NOT_FOUND for all search operations and adjusted all callers.
The protection used in the exported key used a different iteration
count than given in the S2K field. Thus all OpenPGP keys exported
from GnuPG 2.1-beta can't be imported again. Given that the actual
secret key material is kept in private-keys-v1.d/ the can be
re-exported with this fixed version.
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.
