Updated patch

Indeed and that is a standard feature of 2.1. It is even by default enabled. See --extra-socket in the the gpg-agent man page.

In T1646#81392, @werner wrote:

However, with 2.1 it is possible to implement a more elegant solution:
You run gpg on the server and gpg-agent on the client. gpg-agent
takes care of the secret key operations while gpg does the bulk data
and public key stuff. To implement that the gpg<->gpg-agent IPC needs
to be changed from local sockets to TCP over some encrypted tunnel. I
have not checked whether ssh is already able to proxy a local socket -
but if it can do so, you have an instant solution.

GpgEX is now also compiled with ASLR + DEP. I still have to check some other binaries of Gpg4win before I close this task but I no longer see it as blocking a 3.0 release where I wanted to have this included.

If the dialog's show a bit off centered. The center of the screen being top/left of dialog. Which makes it offset to the bottom right. That is a bug in EFL (T5481) that is fixed and should be in EFL 0.19.1. Not anything related to this code though I did try to address in this code.

Well, this will be a different thing and more related to the to-be-implemented key origin feature.
I would thus suggest to open a new task for this.

I think we are talking "aneinander vorbei". AFAIK we agreed (on the Osnabrück meeting) that we will cater to this usecase: Multiple different keyrings for some operations. Or "curated" keyring. Through GPGK and so we will have some API (key probably not a keyring for a context) like this in GPGME at some point in the next years. This is why I think this issue might be kept open to say: Yes we see the usecase but we will not solve it by exposing, what you call a hack, through GPGME. But we will solve it at some point with a better solution.

Back to you original problem: What you are trying to do is a hack to work around properties of GnuPG. Namely, that GnuPG stores its state in a _directory_ and you are modifying parts of this state (e.g. pubring.gpg). This is why GPGME allows you to switch to another directory but obviously does not allow you to modify parts of a directory (i.e. the state).

FWIW I strongly disagree with the sentiment that GPGME should be a "dumbed down" "Easy" GnuPG API. It should be GnuPG made stable -> A stable and reliable C API for the Free Software OpenPGP implementation GnuPG. But this is off topic. SCNR. It's much easier just to use process calls in many cases but I understand why this should not be done and leads to maintenance problems / bugs.

As discussed: The proper solution for this is GPGK, a Pubkey deaemon for GnuPG that would cater to audited / monitored keyrings. The usecase has not gone away and from my talks with people in the community and my general experience it is not "special" and definitely not "very special". It's important for Software Developers using GPGME that want to have keyrings for their Software Seperate from the general GnuPG user setup.

7 years old and meanwhile Kleopatra has been reworked. Further showing two fingerprint (for the signing and the too be signed key) is confusing. In particular because the passphrase for the signing key is usually cached.

GPGME is about making GPG easy and not to cover very special use cases. I'll thus close this bug.

I have updated the code and patch. It is ready for review, modification, and ideally inclusion

For your information.
Since 2.1.18, multiple readers are supported by internal CCID driver. PC/SC driver is not yet.
Since 2.1.20, gpg --card-status can have "all" or specific serialno of the card.
Perhaps, gpg --card-edit should support SERIALNO command as well.

I do have multiple readers. If I insert one card in each of my two readers, GnuPG doesn't choose the one it needs for any given operation. It's been three years, so I don't remember exactly what DOES happen. I think it just acts as if one of the two cards were inserted, and totally ignores the existence of the other. What I want is for it to dynamically use keys from whatever cards happen to be inserted.

Yes, I know it's not perfect but when the secret key is unknown to gpg-agent then it shouldn't attempt to use it.

Sorry, I just noticed this ticket now.

While T1983: gpg2 prefers missing secret key to available key on card for singing is in progress, change of T3119: gpg: Improve public key decryption is needed for decryption.

I've raised the priority here because this bug gets reported regularly and it seems a shame that we haven't fixed it yet, despite having a patch available for quite some time.

The branch dkg/T1967 contains a fix for this. Please review!

I have noticed some issues, minor code fixes, and a major issue with failing to fall back to tty/ncurses interface when a GUI is not available. I will make the changes, cleanup the code format, etc and re-attach patch.

litmus test will be :

The underscores on the Cancel and OK button come from Pinentry. Not sure if I am not handling Locale correctly, or something along those lines. The other stuff does not have it, and setting text the same way.

Sure thing, and it is "semi" animated. If you fail to enter a correct pin/passphrase. The error message is animated, it will slowly move back and forth from left to right. I can provide further screenshots of its various options, confirm, quality, double entry, etc. The quality bar changes color from red to green, with every shade in between based on quality, 0 red, 100 green, in between other colors/shades between the two.

For reference: D426: Initial patch for EFL based pinentry. Thanks for the explanations of the terminology in the E project!

I changed it back to EFL from Enlightenment. Enlightenment is a desktop/application coded using the EFL. Like Gnome is coded in GTK. This does not require Enlightenment at all. Just the EFL. Which can be used in GTK/Gnome, or KDE/QT based environments just the same. Also Tizen, etc. Thus I would not call it Enlightenment anywhere, as it really has no relation.

I created the requested differential. Please let me know what I need to do for inclusion. Thanks!

I can confirm that scdaemon built from today's master (2.1.21-beta73) releases the card, and works as is for my use case.
Version that is included with zesty (2.1.15-1ubuntu7) still keeps the card reserved indefinitely, like all previous versions.

Ok I will do that soon as I am finished with refinements and it is ready for re-submission. Thanks!

@wltjr Please upload the patch here: https://dev.gnupg.org/differential/diff/create/ Thanks!

Yes, there are two things to implement; How gpg frontend use gpg-agent (1 in Werner's comment), and new shadowed key format support (2 in Werner's comment).

Thanks for suggestion. I'm sorry that I haven't caught this report. Now, it's assigned to me.
This is merged to T2291: Smartcard interaction improvement (was: Shadowed private key design (for smartcard)).

I'm an active user of multiple smart cards and would like to see key stubs bound to multiple serial numbers at the same time. I took a look at the agent code and could try to prepare a patch that realizes this by allowing a list of serial numbers as a new shadowkeyinfo field. Would this be a welcome addition or would it possibly break things?

I got the patch from Mike. It does need some refinements. I will work on the modifications and re-submit. Do you accept PRs on Github? Or should I attach here? Or send to mailing list? Thanks!

Thank you @gniibe, I will check if scdaemon from 2.1 solves my troubles and followup if it does not.

Thank you for your comment.
FYI, when card is removed, scdaemon invalidates cache. So, #1 is already done.
In 2.1.x, scdaemon releases the reader when it finds the card is removed.
(Not for 2.0)

I could argue that caching the information about the card and reusing it is pointless and dangerous if such cache is not invalidated when the card is removed. Next time the information is needed, there may be a different card lying on the NFC reader. And it certainly does not make sense to keep the card reserved for exclusive use when the card is physically long gone.

No way to fix, itself. Better warning/error message can be done.

I am interested in this, and can look into any needed polishing. Can someone please attach the patches to this bug or a link to where they can be downloaded. Unfortunately mailing list archives strip attachments. I spoke with Mike in IRC who informed me he made a EFL port of pinentry. I was working on that, and still have my code going in case I cannot get a copy of Mikes work. I am willing to do what ever is necessary to get this into pinentry sooner than later. Though I understand it can take some time. Hopefully not the 1yr it took the FLTK based pinentry to be added.

This has been fixed quite some time ago.

I have noced that you added the C++ interface. Thanks.

Duplicate of T1060

2.1 has the option --unwrap to just this.

Implemented in 2.1.19

Sorry, the test case code is here: https://github.com/rethab/h-
gpgme/blob/master/test/KeyTest.hs#L91

The removeKey function code is here: https://github.com/rethab/h-
gpgme/blob/master/src/Crypto/Gpgme/Key.hs#L64

I hope the attached log helps. The log is a test of this command:
GPGME_DEBUG=9:/home/dmp1ce/Projects/DMSS/h-gpgme/mygpgme.log ./runtests remove_alice_key_prompt

The test is creating a GPG context directory, creating a temporary key and then deleting it. The
log should show me manually confirming to delete the key. I would like the delete prompt to be
suppressed with an automatic deletion of the key. I didn't see any way of suppressing the
confirmation in the documentation here:
https://www.gnupg.org/documentation/manuals/gpgme/Deleting-Keys.html#Deleting-Keys

The code to the test case is here: https://github.com/rethab/h-
gpgme/blob/master/src/Crypto/Gpgme/Key.hs#L64

The test is running the function c'gpgme_op_delete which is a binding to the c function
gpgme_op_delete. Source code for the binding is here: https://github.com/jwiegley/bindings-
dsl/blob/master/bindings-gpgme/src/Bindings/Gpgme.hsc#L534

Can you provide a plain C test program to show the effect or, maybe easier a
GPGME trace file running your program?

GPGME_DEBUG=9:gpgme.trace: YOURTESTPGM

See tests/run-genkey --set-primary on how to use it.

commit 421ddd1 implements that for 1.9.0.

I'm maintaining a language binding. https://github.com/rethab/h-gpgme

What do you mean by "maintainig a GPGME library"? A language binding or an
implementaion similar to GPGME?