Change Details

Hello together, We are utilizing a setup that incorporates SOPS, GnuPG, and Pinentry to manage our secrets within a Docker Image (yes, GPG_TTY should be set correctly) . We are encountering an issue that we already spent some time investigating, but without luck. - If the pinentry (or specifically GnuPG) prompt times out or if we interrupt it using CTRL+C, the terminal becomes non-responsive and fails to display keystrokes, any output is mis-aligned/garbled, after another ~60 seconds the faulty bahaviour stops. - When initiating multiple sessions within the same image and allowing GnuPG to time out first, the GnuPG prompt unexpectedly appears in a different shell session when run again on the initial session. Our internal testing has confirmed that this issue aligns with the one described at https://dev.gnupg.org/T4585 We've also observed that after a GPG timeout (or receiving SIGINT), while the agent process terminates as expected, the pinentry process remains active. Terminating the pinentry process manually restores normal terminal functionality. We've also confirmed this behavior with pinentry-1.1.1 through the latest beta. Aside from having our keys imported there's no additional config done from our side. I can happily provide more information / output if needed. Kind regards, Yannick

Hello together, We are utilizing a setup that incorporates SOPS, GnuPG, and Pinentry to manage our secrets within a Docker Image (yes, GPG_TTY should be set correctly), but utilizing the hosts gpg-agent / pinentry. We are encountering an issue that we already spent some time investigating, but without luck. - If the pinentry (or specifically GnuPG) prompt times out or if we interrupt it using CTRL+C, the terminal becomes non-responsive and fails to display keystrokes, any output is mis-aligned/garbled, after another ~60 seconds the faulty bahaviour stops. - When initiating multiple sessions within the same image and allowing GnuPG to time out first, the GnuPG prompt unexpectedly appears in a different shell session when run again on the initial session. Our internal testing has confirmed that this issue aligns with the one described at https://dev.gnupg.org/T4585 We've also observed that after a GPG timeout (or receiving SIGINT), while the agent process terminates as expected, the pinentry process remains active. Terminating the pinentry process manually restores normal terminal functionality. We've also confirmed this behavior with pinentry-1.1.1 through the latest beta. Aside from having our keys imported there's no additional config done from our side. I can happily provide more information / output if needed. Kind regards, Yannick

Hello together, We are utilizing a setup that incorporates SOPS, GnuPG, and Pinentry to manage our secrets within a Docker Image (yes, GPG_TTY should be set correctly) , but utilizing the hosts gpg-agent / pinentry. We are encountering an issue that we already spent some time investigating, but without luck. - If the pinentry (or specifically GnuPG) prompt times out or if we interrupt it using CTRL+C, the terminal becomes non-responsive and fails to display keystrokes, any output is mis-aligned/garbled, after another ~60 seconds the faulty bahaviour stops. - When initiating multiple sessions within the same image and allowing GnuPG to time out first, the GnuPG prompt unexpectedly appears in a different shell session when run again on the initial session. Our internal testing has confirmed that this issue aligns with the one described at https://dev.gnupg.org/T4585 We've also observed that after a GPG timeout (or receiving SIGINT), while the agent process terminates as expected, the pinentry process remains active. Terminating the pinentry process manually restores normal terminal functionality. We've also confirmed this behavior with pinentry-1.1.1 through the latest beta. Aside from having our keys imported there's no additional config done from our side. I can happily provide more information / output if needed. Kind regards, Yannick