restic
restic copied to clipboard
Debug builds of restic include auth tokens.
Output of restic version
debug log file restic-debug.log debug enabled restic 0.6.1 (v0.6.1-19-g81713f8) compiled with go1.8.1 on linux/amd64
How did you start restic exactly? (Include the complete command line)
DEBUG_LOG=restic-debug.log ./restic -r b2:rustbucket:what init
What backend/server/service did you use?
B2
Expected behavior
Auth tokens scrubbed from debug log.
Actual behavior
Auth tokens are in the debug log.
It may be that sometimes people want auth tokens, but probably not usually.
So I see it in two places, when the configs are printed, and when the debug RoundTripper prints the Authorization header.
It might suffice to:
- Modify the RoundTripper to ignore or scrub the Authorization header (blazer does this),
- Add a custom tag to the config structs to identify sensitive information that ought not to be printed,
- Write a printer that honors those tags.
It looks like dumping the HTTP requests and response uses httputil.DumpRequest/DumpResponse. While economical, internally these end up slurping the body of every request and response into memory as they go by.
Hey, thanks for raising this as an issue. I'm aware of it, and I usually try to warn people that debug logs may contain sensitive things. The auth tokens is one aspect, the other is file and directory names. Your proposed approach is what I'd to, so I agree. We should do this, and maybe also by default not include the HTTP requests/responses in the debug log. Perhaps we can hide this behind build tags? debug-auth, debug-full or so?
Usually we only need a specific part of the debug log. In these cases we can just ask for the specific section, which should avoid most problems with sensitive information. In some cases filenames are definitely helpful, but quite often they are probably not necessary. So I wonder whether it would be useful to have a mode that automatically pseudonymizes (?) filenames and paths. But for now asking people to just provide a certain snippet is probably the best approach.