Re: gpgme_op_delete_ext flag GPGME_DELETE_FORCE not working?
As a followup: I have done some tracing of the code, found that the
GPGME_DELETE_FORCE flag to gpgme_op_delete_ext causes a --yes option to be
added to the gpg command. I confirmed on command line that the behavior is
the same there: --yes does not suppress the "are you sure" graphic dialog
boxes when deleting keys. I was able to suppress the Terminal prompts by
going to --batch mode, but never the graphic dialogs when using gpg2, both
the 2.2.8 which I compiled from git, nor the 2.1.11 that apparently ships
with Ubuntu 16.04 by default. gpg 1.4.20 seems to never request graphic
confirmation to delete keys from command line, though a --batch was
required to suppress the terminal prompt.
I dug a little deeper into the gpg code and found that the --yes command
line flag seems to be translated to a --force option on the DELETE_KEY
command passed to assuan_transact(). I found this hint in
gnupg/agent/command.c:
DELETE_KEY [--force|--stub-only]
Delete a secret key from the key store. If --force is used
and a loopback pinentry is allowed, the agent will not ask
the user for confirmation.
and a further breadcrumb in gpg-agent.texi
@opindex no-allow-loopback-pinentry
@opindex allow-loopback-pinentry
Disallow or allow clients to use the loopback pinentry features; see
the option @option{pinentry-mode} for details. Allow is the default.
The @option{--force} option of the Assuan command @command{DELETE_KEY}
is also controlled by this option: The option is ignored if a loopback
pinentry is disallowed.
but, I'm struggling with how to get the allow-loopback-pinentry option to
the gpg-agent? It is supposed to be the default, but something seems to be
defeating that in gpg2?
All of this raises a related system setup question: apparently, replacing
gpg 1.4.20 with gpg 2.x (as happens when building gpg from the git sources
into /usr/local/lib) breaks the apt-get package management system in
Ubuntu. What is the commonly practiced method (installation folders,
paths, etc.) for an up-to-date build of gpg that keeps it from breaking
apt-get?
Thanks,
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
gpgme_op_delete_ext flag GPGME_DELETE_FORCE not working?
Hi, I've been trying to use the GPGME_DELETE_FORCE flag in gpgme_op_delete_ext, but I'm still getting not one, but two "Do you really want to delete..." prompts popping up, one for the secret key, one for the sub-key. I am using GPGme version 1.11.1 in combination with gpg 2.2.8 (as confirmed by runtime query of the versions) built from the git repos by checking out the following tags:git checkout npth-1.5 git checkout libgpg-error-1.31 git checkout libgcrypt-1.8.2 git checkout libksba-1.3.5 git checkout libassuan-2.5.1 git checkout gnupg-2.2.8 git checkout gpgme-1.11.1 I found this reference in the gpgme 1.10.0 changelog: *src/engine-gpg.c (gpg_delete): Likewise. Implement GPGME_DELETE_FORCE.* * the key deletes from the keyring as expected, but the behavior is as if the flag has not been implemented in 1.11.1. Should I expect the GPGME_DELETE_FORCE flag to work as described here? *gpgme_op_delete_ext* *(gpgme_ctx_t ctx, const gpgme_key_t key, unsigned int flags)* SINCE: 1.9.1 The function gpgme_op_delete_ext deletes the key key from the key ring of the crypto engine used by ctx. flags can be set to the bit-wise OR of the following flags: GPGME_DELETE_ALLOW_SECRET SINCE: 1.9.1 If not set, only public keys are deleted. If set, secret keys are deleted as well, if that is supported. GPGME_DELETE_FORCE SINCE: 1.9.1 If set, the user is not asked to confirm the deletion. Thanks, ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
