I note that this is likely happening because we are using gcr's system-modal prompter. I haven't looked into whether it's even possible to use gcr in a non-system-modal way, but i'd welcome pointers.

pinentry-gnome has no grab support. However, it needs to accept that option so that gpg-agent does not error out. We want to have the same global options for all pinentries. Whether they work depends on the pinentry and other parameters. For example when falling back to curses grab won't work in any pinentry.

Thanks for the feedback, @werner. I think I understand the reasons that we've gotten to this place -- but that doesn't mean i think it's ok to stay here. In this bug report, i'm pointing out that the documentation and the feedback/error reporting is misleading, which leads to difficulty in debugging. We need to do something about it.

The least surprising explanation of what the OK response to OPTION no-grab is would be "gotcha, i will not grab". When pinentry then goes ahead and grabs, that is surprising.

if gpg-agent returns an error because some pinentry declines OPTION no-grab with a response that means "sorry, i will grab anyway" (or, conversely, if pinentry responds to OPTION grab with "sorry, i cannot grab as you requested"), then that suggests that gpg-agent is trying to enforce the user's wishes and will decline to use pinentry in a given context where the user's intent is not being met. Is that right?

That also suggests that if any pinentry is lying about its ability or willingness to grab, it is subverting the intent of gpg-agent. I don't think it's healthy for two parts of the same project to have this adversarial relationship with one another. It *certainly* doesn't help in trying to do sensible debugging, because you're asking the end user to understand these .

So i think we have two options if we want a consistent system that we can actually expect a technically-proficient end user who is willing to read the documentation to debug when things go wrong:

• Have gpg-agent relax (maybe issue a warning, rather than "erroring out"?) if tries to set grab or no-grab and the pinentry declines. Update pinentry to be more honest about its representation of its capabilities.
• Update pinentry documentation to make it clear that the pinentry implementations are expected to lie about their support for some specific features, and indicate which of those features are likely to lie.

Only the former option is non-adversarial, and i think it requires less reading of documentation to debug, so i prefer it. But even the latter option would be an improvement over the status quo.

As a side note, perhaps the user explicitly setting "grab" or "no-grab" in gpg-agent.conf should be distinct from the user leaving themselves in the default mode. if the user says "grab" and the pinentry says "no can do", then that's more justifiable as an error than if the user says nothing (and perhaps it deserves its own error code that can be propagated back to the user, rather than just "pinentry error").