On Sat 2016-10-15 11:34:14 -0400, John Lane wrote:
>>
>> Then, the command "updatestartuptty" can fix the situation.
>>
>
> I tried this and it worked, in a su/sudo I had to do this:
>
> $ script -q -c '(gpg-connect-agent updatestartuptty /bye; ssh-add
> alice.subkey)'
so the use of script h
>
> Then, the command "updatestartuptty" can fix the situation.
>
I tried this and it worked, in a su/sudo I had to do this:
$ script -q -c '(gpg-connect-agent updatestartuptty /bye; ssh-add
alice.subkey)'
___
Gnupg-users mailing list
Gnupg-use
On 10/13/2016 12:36 AM, John Lane wrote:
> I just wanted to bring this to your attention because I think it is related.
Thank you. Actually, I have a problem like that, everyday (literally).
> I tried from a sudo with the tty ownership corrected but it didn't work.
>
> So I ran an agent with so
>
> I created a ticket at the bug tracker.
>
> https://bugs.gnupg.org/gnupg/issue2739
>
>
> With the situation of gpg-agent's allow-loopback-pinentry is default
> now, perhaps, it would be the best (from the user's viewpoint) that
> gpg-agent automatically fallbacks to loopback mode.
>
>
> One possible way is invoking gpg with an option
> --pinentry-mode=loopback.
Yes, just tried this. It works but you lose the pinentry dialog.
> I created a ticket at the bug tracker.
>
> https://bugs.gnupg.org/gnupg/issue2739
>
thanks for creating the ticket.
> With the situation of gpg-agen
On 10/07/2016 12:21 AM, John Lane wrote:
> The requirement for tty ownership for commands where pinentry is
> required causes problems for shells opened with sudo or su, where
> such commands generally result in a "permission denied" kind of error:
>
> $ gpg -d /tmp/encrypted.asc
> gpg: pu
The requirement for tty ownership for commands where pinentry is
required causes problems for shells opened with sudo or su, where
such commands generally result in a "permission denied" kind of error:
$ gpg -d /tmp/encrypted.asc
gpg: public key decryption failed: Permission denied
I can
