Daniel Kahn Gillmor <d...@fifthhorseman.net> writes: > I'm sorry, clearly i'm confused! I thought that pinentry-emacs was > "emacs-specific stuff entirely", and therefore it was addressed as well > by the e-mail above. > > What do you think would be the ideal situation with pinentry-emacs, > gnupg-agent, "the INSIDE_EMACS hack", and debian?
I would honor the upstream default, which is currently neglected in the Debian package, for uncertain reasons. If you have any concrete concerns, I would suggest you to discuss it in upstream, like in this bug: >> By the way, we have been waiting for your response to the upstream bug >> for a long time: https://bugs.gnupg.org/gnupg/issue2034 > > I was unaware that anything was needed from me here. re-reading it, i'm > still not sure. Can you help me understand what you need from me?for > that bug report? You expressed your uncertainity. Neal provided the docuementation trying to clarify the concerns (though it's not correct). Then you became completely silent. I don't think it's a constructive behavior. > you might think these are far-fetched questions, but i think i've run > into the equivalent of all of these scenarios for the non-emacs > pinentries. I wouldn't answer to those questions here. You should have brought up those in upstream discussion. > I've been reluctant to bring in the additional emacs complexity to the > debian pinentry situation because i don't know that i can support it > well if there are problems, and i want to focus my debian time on things > that i think i can reasonably support. But I would welcome help in > providing this kind of support, if we think that having more direct > pinentry + emacs integration in debian is the right thing to do. Even if you compile it with --enable-inside-emacs, it wouldn't be activated unless the user explicitly set "allow-emacs-pinentry" in ~/.gnupg/gpg-agent.conf. Isn't it feasible to declare it as "unsupported", until the implementation meets your criteria? Regards, -- Daiki Ueno