-
-
Notifications
You must be signed in to change notification settings - Fork 8
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
GPG errors are hard to debug #13
Comments
Thanks for your report! That's an interesting case. I agree that gpg's output is quite sparse. That is to remove a lot of noise when operating with Dumping gpg's output with |
This is now released as part of I expect the information that is now shown in verbose mode to be sufficient for proper debugging. Feel free to open the issue again if you have further input on this. |
I just had my hands on a shared keyset of which one key's encryption subkeys have all expired.
In order to find this, I had to strace prs in order to find the gpg invocation, which (even in the form it was in, with the
--quiet
in place) gave me at least a hint as to which key was offending. (GPG lent no aid in finding what's wrong there, apart from its--verbose
output pointing me in the general direction of subkeys; I wouldn't expect prs to peek into gpg internals here).I did not run through a full reproduction setup, but this is what should do:
prs edit
on an existing fileThe PRS version I used was the current prs-cli from crates (0.3.5), with features clipboard and alias. I can't tell the behavior with gpgme: on Debian that somehow doesn't like to work with the dev libs for lack of gpg-error-config (Debian had to patch that where they packaged the GPGME crate).
I suggest that when
--verbose
is given (alternatively, some other debug flag), that then GPG's stderr output be shown, either captured and labelled, or just keeping stderr intact.The text was updated successfully, but these errors were encountered: