Skip to content
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

Closed
chrysn opened this issue Nov 20, 2022 · 4 comments
Closed

GPG errors are hard to debug #13

chrysn opened this issue Nov 20, 2022 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@chrysn
Copy link

chrysn commented Nov 20, 2022

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:

  • Create a key that has an expired encryption subkey (but is generally non-expired; didn't test what happens when it is)
  • Put it into a repo's .gpg-id
  • Run prs edit on an existing file

The 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.

@timvisee
Copy link
Owner

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 gpg. It's quite hard to decide what to show in what situations.

Dumping gpg's output with --verbose sounds like an easy and good solution. A GPG_ARGS variable may be useful to pass additional arguments to gpg, such as its verbosity flag. Do you think that adding these two things is sufficient?

@timvisee timvisee self-assigned this Nov 23, 2022
@timvisee timvisee added the enhancement New feature or request label Nov 23, 2022
@timvisee
Copy link
Owner

Dumping gpg output on error when --verbose is set is now implemented on the master branch.

This took a while because it required API changes, and is still somewhat limited. This currently only outputs for the gnupg-bin backend, as the gpgme backend doesn't have a stdout/stderr.

Here is an example of what is currently shown with a gpg error:
image

I will probably add logic to print the exact gpg command that is invoked as well, to allow easier debugging outside of prs.

I'll leave this open until this is released under a new version.

@timvisee
Copy link
Owner

timvisee commented Jan 18, 2023

I will probably add logic to print the exact gpg command that is invoked as well, to allow easier debugging outside of prs.

This is now also added:

image

@timvisee
Copy link
Owner

This is now released as part of v0.5.0!

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants