On Wed, Mar 06, 2019 at 02:19:51AM EST, Werner Koch wrote: > On Mon, 4 Mar 2019 09:14, ke...@8t8.us said: > > > Yes, to support the tty pinentry, we would have to exit curses > > (endwin) every place a prompt could occur. > > Actually the endwin could be called on demand by hooking into the > PINENTRY_LAUNCHED status callback. This would avoid all unnecessary > calls to endwin. Given that Mutt uses curses I don't think it makes > sense to support the pinentry-tty. That pinentry was written for > environments where curses can't be used.
Kevin and Werner, thanks for the info. I now see why the project doesn't want to support pinentry-tty. The reason I was looking at this is that the default pinentry program for the FreeBSD port security/pinentry is pinentry-tty. I might go down the path of seeing if that can be changed, it seems that every pinentry package defaults to curses, I dunno if that's enough justification to change the current port's default. But with everyone's suggestions I checked to see how much work was needed to support tty out of the box in FreeBSD's mail/mutt port. However, there appears to be a race issue with the callback method. While trying to test the value string to see if it's second word is "tty" pinentry would execute before endwin. I simulated this with a sleep() before endwin. So using the callback might not work here or am I doing something wrong here? An alternative would be to call endwin before returning the context in create_gpgme_context. The only draw back I see is that the cursor is moved to the first column while you wait for the gpg-agent to run pinentry. Is it safe to assume if you're asking for a context you're going to be prompted for a passphrase otherwise you might see a very small cursor blip if the key is cached?
