This is a feature request for the 'classic' branch. We will not implement any new features there. Please switch to GnuPG 'modern'.

I updated the patch, fixed all issues mentioned and a couple others I noticed. Things not being centered vertically labels/entries, and ok not being fired on pressing enter on entry, or confirm when present. That should fix all outstanding issues.

In T2905#98415, @justus wrote:

So are you also saying that I should better not use e17 because its focus handling is so fubar that it does not focus the pinentry when it pops up?

In T2905#98127, @wltjr wrote:

I got your point, I was saying do not have a chat client or program that would create pop ups and grab focus away. Its a highly debatable and personal preference type of thing. I have run into such already.

@justus Can you tell me how you got the two passwords with extra text and the long button text? I can replicate the long button text via cli. Not sure about the two passwords and extra unwanted characters. I would like to be able to replicate as you did. Thank you!

(and without saving the password to disk or entering it on the commandline, both of which less secure)

@gniibe , I was happily running scdaemon 2.1.21-beta73 for more than a month and it properly relinquished the card every time. However, a few days ago it got hold of the card and would not let go (or at least, other users of the card got "sharing violation" error from pcscd). I collected some debugging information:

I got your point, I was saying do not have a chat client or program that would create pop ups and grab focus away. Its a highly debatable and personal preference type of thing. I have run into such already.

In T2905#97872, @wltjr wrote:

Ok I can add the keyboard/mouse grab stuff. I have the code already. I get your point, mine is the opposite of yours. I would say don't launch something if your typing in your pin or about to :)

Yes, if it supports --card-edit it would help a lot.

Updated the patch should be good to go now

Fixed as of 525f2c482abb6bc2002eb878b03558fb43e6b004.

Ok I can add the keyboard/mouse grab stuff. I have the code already. I get your point, mine is the opposite of yours. I would say don't launch something if your typing in your pin or about to :)

"wltjr (William L Thomson Jr)" <noreply@dev.gnupg.org> writes:

I will see about removing the underscores now that I understand their meaning. I am not sure if EFL has any means to interpret such at this time. I will look into it and address either way. Thank you for that information!

Ok, so the patch from the differential works. Could you please address these warnings?

In T2905#97835, @wltjr wrote:

I am not sure where the underscore comes from. Seems to come from pinentry, but GTK and QT do not have that, so I think its something I am doing wrong.

Forgot EFL version...

Ok you should be good to go now. There are 2 issues I am aware of.

Very sorry! I already fixed that. I just had not updated the patch. This one is updated
https://github.com/Obsidian-StudiosInc/pinentry/commit/0fb3104c3ab27112aad70668c5828f9d435e10d4.patch

Also, would you be so kind to add an item to the NEWS file?

"wltjr (William L Thomson Jr)" <noreply@dev.gnupg.org> writes:

What version of the patch or EFL?

Cool, thanks. Can you please explicitly say what version is the current one?

I sent the DCO per request.

Hi @wltjr, thanks for picking this up. If we want to merge your code, we'll need a DCO from you. If you agree, please send https://dev.gnupg.org/source/gnupg/browse/master/doc/DCO to gnupg-devel@.

In T1983: gpg2 prefers missing secret key to available key on card, I applied another approach: rGfbb2259d22e6: g10: Fix default-key selection for signing, possibly by card.
Please test.

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)