-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
rpcserver+lncli: add ability to create encrypted debug information package #8188
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would recommend adding a Config -> Config
transformation that redacts sensitive information:
- Bitcoind.RPCPass
- Bitcoind.RPCAuth
- Btcd.RPCPass
- Tor.Password
- DB.Etcd.Pass
- DB.Postgres.DSN
This is the minimum set of information I'd like to see redacted in this transformation. However, I strongly encourage you to do your own review of the config tree to see if I missed anything, as you have significantly more experience with the codebase than I.
// configToFlatMap converts the given config struct into a flat map of key/value | ||
// pairs using the dot notation we are used to from the config file or command | ||
// line flags. | ||
func configToFlatMap(cfg Config) (map[string]string, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only major concern I have with this is if we can do a Config -> Config
transformation that redacts sensitive info that is irrelevant wrt debugging. The one that comes to mind is any bitcoind
rpcpass
or stuff like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very good point, those values don't really need to be known by a supporting person. And if a special character in those fields cause the config file not to be parsed correctly, it should be noticeable in another way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a string suffix based redaction, which covers all the keys you mentioned (except for Bitcoind.RPCAuth
which doesn't exist on the lnd
side, only in bitcoind
's config).
@ProofOfKeags: review reminder |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tACK, LGTM! 🔥 this is awesome & will be very very useful. The PR is structured beautifully 🤩
The only question I have is: why not have an "--output" flag for the encrypt command instead of piping the output to a file? the reason I ask is cause when I was testing this, it took me a while to realise that the decrypt was not working cause the output of my command was actually printing a docker related string before the json output - but maybe that's not expected to generally be the case for others.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ship it ⛵️
I added an |
With this commit we add a new helper function that recursively turns the runtime configuration into a flat key/value map that is human-readable, using the dot notation for nested values that is also used in the config file or command line flags.
With this commit we add a new way to encrypt and decrypt a sensitive payload: By using Diffie-Hellman over a local and remote key to derive at a shared secret key.
This commit adds three optional command line flags to the encryptdebugpackage: --peers, --onchain and --channels. Each of them adds the output of extra commands to the encrypted debug package.
their node with a single command and securely encrypt it to the public key of | ||
a developer or support person. That way the person supporting the user with | ||
their issue has an eas way to get all the information they usually require | ||
without the user needing to publicly give away a lot of privacy-sensitive |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
curious about how to obtain the public key - is it the same as the release signing key?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll define one and then update the issue template and FAQ to mention the lncli encryptdebugpackage
command and key to use when submitting info to us. And I'll probably create an internal tool that has the corresponding private key to decrypt the user files in a nice UI.
// the size of the final payload. | ||
var ( | ||
compressBuf bytes.Buffer | ||
options = brotli.WriterOptions{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any particular reason we chose this new-ish algo over what's already available in the stdlib
? The set of stdlib algos: https://pkg.go.dev/compress
Generally would like to minimize adding in new dependancies (tho the one added itself adds no new deps other than itself, as it's a transpilation of a c algo and uses the stdlib only).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did a quick research on what compression algorithm works best on large-ish text and Brotli seems to be leading by quite a bit https://paulbradley.dev/go-compression-comparisons/.
And I explicitly only used it because we do already transitively depend on it.
Change Description
This PR adds a new RPC method
GetDebugInfo
that returns the full runtime configuration of thelnd
node as well as the completelnd.log
file. The RPC can be called by the newlncli getdebuginfo
CLI command.The even more useful part of this PR are the two new CLI commands though:
lncli encryptdebugpackage
(and its counter partlncli decryptdebugpackage
).The
lncli encryptdebugpackage
command calls into theGetDebugInfo
RPC described above (as well as a couple of other useful RPCs), collects all that info in a single file, uses the efficient Brotli compression algorithm to reduce the size as much as possible, then encrypts everything using a symmetric key created using ECDH.The idea is that we would publish a public key in the GitHub issue template and would ask users to run the
lncli encryptdebugpackage
command and upload the encrypted output files to the GitHub issue to provide us with the information we normally require to debug user problems.Steps to Test
Here are two example files created on my development machine:
package-minimal.json
package-maximal.json
They were created using:
To decrypt them, you can use: