Update and rebase stateless-init #5
Draft
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
github: add GitHub Actions configuration
REST saga 1/3: Cleanup proto files, generate Swagger docs
…cess htlcswitch/switch: log successfully forwarded HTLCs
…ration Dry run migration
This fixes an issue where the contract court could leave a completely swept commit tx unresolved if it was swept by the remote party. This could happen if (our) commit tx just published was actually a previously revoked state, in which case the remote party would claim the funds via a justice transaction. This manifested itself in the testRevokedCloseRetribution integration test where at the end of the test Bob was left with a pending channel that never resolved itself.
This adds a test to the commit sweeper resolver to ensure it behaves properly if the local node breaches a channel. In this situation the remote party is expected to sweep the breached output to itself and therefore the local party won't be able to recover any funds.
This improves readability since both instances of the test are very similar.
…ng-chan-restriction routing+routerrpc: add multiple outgoing channel restriction
The continue-on-error was added to make sure the log files of the failed itests would always be uploaded. But this has the side effect of marking the whole job successful, even if the itest job itself failed. The failure condition in the log file steps already solve that, so the continue-on-error is not needed anymore.
Unify data structure with SendPayment/ListPayments.
…ing-contract contractcourt: fix lingering contract after local breach
gkrizek
force-pushed
the
gkrizek/stateless-init
branch
from
75f4061
to
4d3dbdc
Compare
…ck-sync rpc: acquire global coin select lock in related RPCs
breacharbiter: fix flaky race condition in test
Makefile: add -w to -ldflags to strip DWARF symbols
…mpat Support bitcoind v0.20
…tector-doc doc: describe usage of log levels
gkrizek
force-pushed
the
gkrizek/stateless-init
branch
from
4d3dbdc
to
847eb3f
Compare
build: update travis to build against go 1.14
…ements REST saga 3/3: REST API for subservers, websocket for streaming responses
…locker This commit adds the --stateless_init flag to all three wallet unlocker operations. Once you initialize a wallet stateless, you need to set this flag for every further wallet unlocker operation. Otherwise you risk non-encrypted macaroon information to leak to the underlying system.
Because we'll need to return the macaroon through the wallet unlocker we cannot shut down its service before we have done so, otherwise we'll end up in a deadlock. That's why we collect all shutdown tasks and return them as a function that can be called after we've initialized the macaroon service.
gkrizek
force-pushed
the
gkrizek/stateless-init
branch
4 times, most recently
from
2ec9a9f
to
ab7d7b8
Compare
…s set This will prevent the subservers from writing macaroons to disk when the stateless_init flag is set to true. It accomplishes this by storing the StatelessInit value in the Macaroon Service. Then each subserver inspects the StatelessInit value because writing macaroons.
gkrizek
force-pushed
the
gkrizek/stateless-init
branch
from
ab7d7b8
to
6a0492b
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.
Description
This updates the Stateless Initialization implementation to allow stateless_init to be set on the daemon. This moves control of the initialization to the server side instead of from the client. This adds a
--stateless_initflag to LND. This flag controls whether a stateless initialization will happen or not. If it is set, no macaroons will be written to disk. It also allows LND to return a macroon through RPC if the user requests it. The--stateless_initflag on LNCLI is now used to request the macaroon to be returned in the RPC response only. If LNCLI (or other) requests--stateless_initand it is not set in LND, then an empty list of bytes is returned. If--stateless_initis set on LND and the user doesn't specify it on the CLI, then they would affectively be locked out until they did an unlock with stateless_init set.I think its important to set it stateless_init on the server side because someone could accidentally write macaroons to an untrusted environment by forgetting to set it client side. I also think this is important to disallow the admin macaroon to be returned in the RPC response if the user doesn't want it to be. With only client side setting if someone knew a user's password they could get the macaroon too.
Pull Request Checklist
Contribution Guidelines
the positive and negative (error paths) conditions (if applicable)
the bug being fixed to prevent regressions
logging level
go fmtlnrpc/**/*.proto) have been formatted withmake rpc-formatand compiled withmake rpc(the tab character should be counted as 8 characters, not 4, as some IDEs do
per default)
make checkdoes not fail any testsgo vetdoes not report any issuesmake lintdoes not report any new issues that did notalready exist
cases it can be justifiable to violate this condition. In that case, the
reason should be stated in the commit message.