Encrypt tls key updates #8
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ignoutputraw remote signer: fix SignOutputRaw RPC for incomplete key info, fix healthcheck connection leak
Because Taproot key spend only spends don't allow us to re-construct the spent pkScript from the witness alone, we cannot support registering spend notifications for v1 pkScripts only. We instead require the outpoint to be specified. This commit makes it possible to only match by outpoint and also adds an itest for it.
…-signet Taproot: integrate btcec/v2 and btcwallet changes to support Taproot key spend paths in lnd's wallet
fix some typos
Updates a version of `btcutil/psbt` that has looser parsing requirements to properly match the BIP. Fixes: lightningnetwork#6372
…-psbt-fix build: update to latest btcutil/psbt version
If new default scopes are added to the underlying btcwallet implementation, then they aren't automatically created for _existing_ wallets, only for new ones. So on startup we need to make sure all scopes are present.
…-master github: re-add rolling tag 'daily-testing-only'
Use normal TCP resolution for any unspecified IP (0.0.0.0 or ::) instead of using the Tor resolver.
Use the IsLoopback method provided by the net package instead of using hardcoded loopback addresses.
…scopes btcwallet: always make sure default scopes exist
Was discovered in a race unit test in lightning node connect that uses the websocket proxy to connect to the hashmail server on the client side. By not shadowing the err variable we end up reading and writing to the same variable from two different goroutines, which causes the data race.
…-race-fix lnrpc: fix websocket proxy data race
Since we might now be given a whole list of UTXOs in the PrevOutputs field of the SignOutputRaw RPC, the previous output fetcher might contain the information we require for the remote signing case. So instead of failing if our wallet doesn't know each input that's being spent, we fall back to the UTXO information contained in the previous outputs.
In this commit, we add a new field `TapTweak` to be used for key path spends. Before this commit, we'd overload the existing `WitnessScript` field to pass this information to the signing context. This was confusing as for tapscript spends, this was the leaf script, which mirrors the other script based spending types. With this new filed, users need to set this to the script root for keypath spends where the output key commits to a real merkle root, and nothing when bip 86 spending is being used. To make the signing even more explicit, we also add a new field called sign_method with an enum type that differentiates between the different segwit v0 and v1 signing methods. Fixes lightningnetwork#6446.
Because the original dcrec secp256k1 library that is used for the Schnorr signature primitives uses different hash algorithms than the btcd secp256k1 library. Therefore pulling in the wrong library can lead to weird and unexpected errors. We try to make it harder to make the mistake by not using the library directly in lnd in the first place. Note that it is still indirectly needed by the btcd secp256k1 library, therefore the module dependency is still expected to be there, just moved to the indirect section.
cmd/lncli: make hop hint inclusion opt-in for addinvoice
taproot: add PSBT signing support for Taproot, fix remote signing Taproot support
…IX flag by default
…ubservers Mobile builds: expose main sub-servers by default
…its own package called lnencrypt The functions inside of the crypto.go file in chanbackup (like EncryptPayloadToWriter and DecryptPayloadFromReader) can be used by a lot of things outside of just the chanbackup package. We can't just reference them directly from the chanbackup package because it's likely that it would generate circular dependencies. Therefore we need to move these functions into their own package to be referenced by chanbackup and whatever new functionality that needs them
…ity to encrypt the Tor private key on disk It's possible that a user might not want the Tor private key to sit on the disk in plaintext (it is a private key after all). So this commit adds a new flag to encrypt the Tor private key on disk using the wallet's seed. When the --tor.encryptkey flag is used, LND will still write the Tor key to the same file, however it will now be encrypted intead of plaintext. This essentially uses the same method to encrypt the Tor private key as is used to encrypt the Static Channel Backup file.
This commit adds support in lnd to encrypt the TLS private key on disk with the wallet's seed. This obviously causes issues when the wallet is locked. So for the WalletUnlocker RPC we generate ephemeral TLS certificates with the key stored in memory. This feature is enabled with the --tlsencryptkey flag.
orbitalturtle
force-pushed
the
encrypt-tls-key-2
branch
from
ca84c47 to
c570988
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@gkrizek OK... so I think the situation with this PR is the same as the encrypting the Tor key change in that your branch is behind master in commits. Once you rebase the changes on top of master, I think it'll show just my changes and yours.
However, the super confusing part of this PR is that Oli requested we rebase this change on top of the Tor key change (lightningnetwork#4458) since the lnencrypt changes are the same. I did that. But now I'm realizing... I'm not sure if you'll run into some sort of a huge conflict trying to merge this PR into yours. (A conflict which I already dealt with when rebasing the PR on top of the Tor change.) But if it works okay, then once you merge the changes, I think you'll want to click "edit" on the TLS PR and instead of asking to merge into lnd master, try to merge into the Tor change.
LMK how that goes... Maybe it'll work fine. But if it's a big mess we might just want to submit a new PR to LND on top of the Tor change??
I also added some new tests, since between the refactoring, our new changes, and them not being tested to begin with, wanted to make sure each path still works properly :)