On 28/08/17 09:57, Fiedler Roman wrote: > But it seems, that the gpg-decryption process attempts to trigger the > pinentry, not the agent and so the access to the correct controlling TTY > fails.
The gpg process communicates its TTY to the agent so the pinentry knows where to pop up. This is a feature, not a bug. But when you deliberately want to pop it up elsewhere... I almost had it working in a test: - Start an x-terminal, invoke "tty" and see that it is /dev/pts/7. Start another x-terminal and: $ unset DISPLAY $ export GPG_TTY=/dev/pts/7 $ echo test | gpg -o /dev/null -s And indeed the pinentry-curses popped up on the other terminal. BUT: a few of my keystrokes went to the bash shell that was running there instead of the popped up pinentry. So the passphrase I entered in the pinentry was missing characters, and those characters were typed as part of a command on the command line. So my idea that GPG_TTY would override the terminal was correct, but it didn't actually work in the end. It seems that it's easier if you use a graphical pinentry, by just overriding DISPLAY in the session where the batch runs. > Yes, that should work also. The different Linux-Distributions, GPG versions > on > the various machines might be a permanent source of trouble Well, agent forwarding to access a remote private key only works on GnuPG 2.1 (and later, once later exists). In general, mixing versions is not a good idea, no, not even between minor versions. But possibly this restriction is less stringent for the forwarded socket, because I expect there it will be common to mix versions. It might have been designed to account for this. > and also the > process is not that straight forward: one should still extract all required > session keys at once and use them later on - otherwise the admin holding the > keys and the admin using the data have to work coordinated for hours until > all > elements are decrypted and used (e.g. restored). With session keys, the key > holder performs the session key extraction on the list of requested elements > (15min with connecting, selecting the elements, ...) and then forward the > list > of keys to the user. You should consider whether you should use a passphrase at all. Usually, with unattended decryption, it's just bothersome. The passphrase protects the key at rest. If you're worried about attackers getting access to a backup, you could do the gpg-preset-passphrase dance. If an attacker that gets the privileges to read the contents of your private key dir is not part of your threat model (for instance, because it's game over), you might as well remove the passphrase and be done with this bothersome pinentry stuff, as FAQ entry 8.20 [1] says. The admin that is submitting a list of PKESK packets already effectively has unfettered access to your decryption key as far as usage is concerned, no need to worry about them. And using just a forwarded agent connection, they still have no access to the key material. HTH, Peter. [1] <https://www.gnupg.org/faq/gnupg-faq.html#automated_use> -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
