-
-
Notifications
You must be signed in to change notification settings - Fork 971
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pinentry-ncurses in async process mangles inputs for the rest of the session #366
Comments
@5paceToast Did you find a solution to this issue? I'm having similar issues with Git Radar doing a fetch in the background, and my terminal then getting mangled. Finding the |
It’s known that ncurses apps mess with the async worker and there’s not much to do about that (except prevent them from running). Currently Pure makes no effort to figure out if any kind of pinentry method is used but we try to disable it via How does pinentry behave? Is it a one time prompt or is it prompted every time? If it’s the former we might be able to request it before handing work over to the async worker (this would block your prompt every time you entered a new git repo without pinentry active). |
Pinentry is a dumb "input password here" program - it doesn't make sense to have pure invoke it itself. It's invoked by gpg-agent instead, and the frequency of its invocation depends on its configuration (various When using gpg-agent as your ssh-agent, you always use pinentry. It seems like the feature that ends up requiring a key to be present is the check on whether or not there's stuff to push/pull (with everything else working fine). |
It could be possible to have pinentry bail by setting PINENTRY_USER_DATA to something like "pure_async_fetching" for async fetches, and allowing a user to specify a custom pinentry which will bail dependent on the value of that var. See https://unix.stackexchange.com/a/236747 I have a similar problem in that I keep being prompted to decrypt my hardware token, which is in my bag, just for look at a directory. I can't see any way to ask gnupg/pinentry to bail if it has to prompt for anything. It would be nice to retain the fetching behaviour if my hardware token is plugged in and decrypted. |
I've had this issue as well when using gpg-agent as my ssh agent. I've switched back to ssh-agent for now. |
Does applying the patch from #373 (comment) help with this issue at all? |
#373 (comment) did not help. I still get a pinentry prompt if the key is not cached on gpg-agent. (And just to make sure, if I comment the |
Thanks for reporting @kazuoteramoto, could you try the next patch that always forces batch mode: #373 (comment)? |
😞 @davidtwco could you try setting:
In |
@mafredri This doesn't seem to be doing it either. |
Alright, well, I'd need a reproduction setup to be able to debug this further; grasping at straws here :/. |
@mafredri I don't know how helpful this is but davidtwco/dotfiles@6c77ea0 is the commit in my dotfiles where I reverted back to |
Thanks, I'll try to have a look. We could try one last straw though:
Again, inside |
@mafredri that doesn't seem to do it either. |
Alright, and it's pinentry prompting for PW, not SSH? |
@mafredri Here's the current diff I've got on top of #392. diff --git a/pure.zsh b/pure.zsh
index e2f600c..b435090 100644
--- a/pure.zsh
+++ b/pure.zsh
@@ -270,6 +270,8 @@ prompt_pure_async_git_fetch() {
export GIT_TERMINAL_PROMPT=0
# set ssh BachMode to disable all interactive ssh password prompting
export GIT_SSH_COMMAND="${GIT_SSH_COMMAND:-"ssh"} -o BatchMode=yes"
+ export PINENTRY_USER_DATA="USE_CURSES=0"
+ export GPG_TTY=
command git -c gc.auto=0 fetch &>/dev/null || return 99 Here's a asciinema recording that shows me navigating into a git repository with the gpg agent being used, then after running a command the pinentry shows up and immediately disappears (normally it doesn't, that must be an artefact of the recording, but after I type a few characters it disappears when not recording) - after that, every key I type shows up as a random character or a |
Thanks @davidtwco, I can confirm this behavior. I managed to get pinentry to pop up a few times, but it no longer does and I can't get it to show up again. I don't really understand gpg well enough to figure out how to reproduce this (anymore), and I'm not interested in learning the tools. If I am to debug this issue further I'll need someone to provide me info on how to set up a simple config / environment that reproduces the issue 100% of the time. |
@mafredri I can't think of anything much at the moment, could it be you need to change the gpg agent configuration to not cache the credentials and prompt every time? |
No idea what it might be; I'm not sure even if/how anything should be configured for pinentry prompts. I've tried setting |
@mafredri I believe there's a separate ssh cache setting. The one you mentioned is for gpg keys in general. |
We set the shell into MONITOR mode to prevent password prompts (either SSH or pinentry) from hijacking the TTY. If the command is suspended we know it's trying something not nice. So we kill it. This seems a bit crazy, but at least it does not seem to affect performance (relatively). I also have found no other way to work around these issues. Although we already set: ``` export GIT_SSH_COMMAND="${GIT_SSH_COMMAND:-"ssh"} -o BatchMode=yes" ``` It is not sufficient. For example, when a SSH configuration entry contains the ProxyJump option it will usually invoke a new instance of ssh which does not obey the BatchMode option we specified. Pinentry is a whole nother beast and can't even be disabled (to my knowledge). I tried both zsh 4.3.17 and 5.0.2 to be sure it doesn't break easily... Fixes sindresorhus#366 and sindresorhus#373 (hopefully).
I've tried setting the separate SSH cache settings as well, I'm pretty sure I've tried every applicable setting, but I can't get it working. I've also wasted more time on just trying to get pinentry to pop up than I'm comfortable with, so: The only way I'll dig deeper into this is if someone can provide me with a 100% repro, for example a For now, this issue is on ice unless someone, other than me, wants to investigate further. |
I'll try and make a .tar.gz like that (or a container image or something)
once I have some free time.
Goal will be 100% reproducibility on `cd` into git.
…On Mon, May 7, 2018 at 1:36 PM Mathias Fredriksson ***@***.***> wrote:
I've tried setting the separate SSH cache settings as well, I'm pretty
sure I've tried every applicable setting, but I can't get it working. I've
also wasted more time on just trying to get pinentry to pop up than I'm
comfortable with, so:
The only way I'll dig deeper into this is if someone can provide me with a
100% repro, for example a .tar.gz that I can extract into a users home
directory and get going. Or a list of commands that will *just work*™️.
For now, this issue is on ice unless someone, other than me, wants to
investigate further.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#366 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFB113MEq0Y7V7XE75Ap3LnUs2vcR5Yqks5twIYCgaJpZM4QhTlC>
.
|
That's awesome @5paceToast, thanks! 😄 |
Try with this: https://send.firefox.com/download/b420bc8429/#6vMQerOUXNnJEu9cDcpwwg Usage instructions:
(note: I don't really have a preferred filesharing service, and github doesn't do tarballs; I set the "delete after X downloads" to 20, so ideally I won't have to figure out a different place to put it). |
Thanks btw @5paceToast for the repo, it worked great. I've been scratching my head with this for a while, and haven't really found any solution to the issue. Here's some of my findings (might have forgot something):
I've recently started using GPG and YubiKeys for SSH, so I'm ever more motivated to fix this now. Ideally I would love for Pure to be able to show a 🔐-icon when a user is prompted (e.g. graphical pinentry, or waiting for touch on YubiKey) but I really don't see how this is possible. If anyone has experience tweaking and hacking around with gpg-agent/pinentry, I would love to hear some ideas on how we:
|
Here are a couple of alternative ideas:
Both of these have issues though. It might make sense to look into 1. to see if it's actually feasible with the current codebase? |
Thanks for the ideas, one big problem with 1. is that, according to my testing, the zpty instance will mess with pinentry as long as it's running no matter if we are authenticating asynchronously or not. It could even be a zpty instance from another tab (depending on where gpg decides to show pinentry) that catches the auth and then the pinentry term kind of shows in the terminal, but input goes partially to zpty and partially not, and it all becomes a garbled mess. The only way I found to avoid this is to make sure the zpty is closed (no async worker). But regarding that, we could also check for some indications from ssh (ssh -vvv) that the user will be prompted (either pinentry or card reader) when ssh pauses at Example output:
Regarding 2., is there a way for us to check when the cached key will expire? |
Regarding 1, "zpty is closed (no async worker)." is what I meant by foreground; e.g run the check in a hook, and if the check succeeds, then launch the worker (and thus zpty). Regarding 2, my understanding is that gpg-connect-agent only recentlyish gained the capability to even report whether a key is cached or not (2.1.18?). You nead the CACHEID (full keygrip) and you can send My situation is quite the opposite of yours (I dropped using smartcards for gpg-ssh-auth, at least for now, because I couldn't find one that fulfills all of my requirements and supports ed25519), so I can't verify the above (very easily, at least). I could fetch the archive of that rootfs I made, and start examining things there, but I'm quite busy right now (and will remain such for the forseeable future), though, so it may be faster to experiment on your end, where it's already all set up. |
@IssueHunt has funded $60.00 to this issue.
|
@mafredri have you seen this blog post? - I've recently revisited using gpg-agent for SSH (w/ a Yubikey) and have been running into this again. |
I've experimented a little with the solution from the previously linked post. In my experience, I've found that when a Yubikey is connected for the first time then it needs to be unlocked, and the command from the blog post will tell you that. Once unlocked (by running a GPG command that requires the key), the command from the blog post will tell you that it is unlocked. However, I've found that despite being unlocked, the key will need unlocked again when used as a SSH key for the first time, and that the command will not inform you of that. |
I'm hitting this as well, which really sucks as I have to switch to bash to handle pinentry-curses or pinentry-tty. It begins and some of the characters I type in the prompt show up as * while others are the underlying characters. No matter how much I delete and try to get a clean password in, it fails the prompt. If I suspend it, then some or all of the characters I type in zsh become * and it becomes unusable (can't even Ctrl+D out). My setup is an iPad using blink shell to connect to a remote server using mosh (SSH has same problem). The remote server is running the following:
Let me add to the fund. |
@chipsenkbeil has funded $100.00 to this issue.
|
I _really_ like the aesthetics of the [Pure prompt][1] and have used it for years. However, since switching to a Yubikey and GPG certificates for SSH, I keep running into [a bug][2] in the interaction between pinentry-ncurses and Pure's async functionality. It mangles all future output for the terminal, launches a spinning pinentry-curses process, and generally wreaks havoc. As such, I'm attempting a switch to [Starship][3] as my prompt provider to see if that alleviates the issue. To replicate the Pure prompt's functionality, I [patched Starship][4] locally. I intend to push this upstream after I use it as my daily driver on both Linux and macOS for a while. [1]: https://github.com/sindresorhus/pure/ [2]: sindresorhus/pure#366 [3]: https://github.com/starship/starship [4]: michaelherold/starship@cfb20c5
I recently switched to My workaround is to establish a connection to the SSH server — in the foreground — prior to changing directory to the Git repository in my shell. Example, for a repository hosted on GitHub: ssh -T git@github.com This allows me to keep the key unlocked for the duration the GPG agent's cache is active, and prevent the pinentry dialog from being triggered by Pure. For this to be viable, you probably have to set the GPG agent's cache TTL high. |
@antoineco has funded $50.00 to this issue.
|
Pure cannot be used with gpg-agent acting as SSH agent. The git commands issued asynchronously trigger the opening of pinentry dialogs in the background. This causes all subsequent inputs to be mangled until the pinentry process is killed. See sindresorhus/pure#366
Pure cannot be used with gpg-agent acting as SSH agent. The git commands issued asynchronously trigger the opening of pinentry dialogs in the background. This causes all subsequent inputs to be mangled until the pinentry process is killed. See sindresorhus/pure#366
Please test #645. Hopefully it gets merged. |
@sindresorhus has rewarded $189.00 to @sheevizi. See it on IssueHunt
|
General information
I have:
Problem description
If pure ends up invoking pinentry-ncurses (e.g through ssh-agent) in an async task (e.g checking
git@...
repository's status), input becomes mangled on both sides.Reproduction steps
(note: not tested with a "normal" ssh-agent, nor outside nixos)
git@...
).Expected behavior:
pinentry-ncurses pops up, you enter the password and continue on your merry way
Actual behavior:
pinentry-ncurses pops up (in the async process), and mangles inputs (I haven't looked into it very deeply, but it seems like half your inputs go to asynced-pinentry and half go into the shell).
My
.zshrc
:IssueHunt Summary
sheevizi has been rewarded.
Backers (Total: $210.00)
Submitted pull Requests
Tips
The text was updated successfully, but these errors were encountered: