Because the PGP keys are no longer downloaded from Keybase but are used
from the repo directly, we also have to copy them to the Docker image so
we can run the script without needing to supply them through a volume.
With this commit we add a new restriction that checks that the
username in the signature file (manifest-<username>-<version>.sig) actually
does have a signing key and that the signature was created with that key.
The signature is only counted towards the minimum of 5 signatures if
that check is successful.
The changes in this commit were inspired by @kixunil in #5048.
Instead of importing the keys from Keybase, we add all the signing keys
to the repository. In addition to having the key file present each key's
ID must also be added to the verification script. This acts as a double
check that the correct key is added and makes a key change more
explicit.
To give the CLI user the option to delete a single or multiple payments
in one command, we expose the DeletePayment and DeleteAllPayments
RPCs to the command line as well. Due to the similarity of the two RPCs
we combine them into a single command with multiple flags.
To make the command a bit more safe to run without arguments, we
consciously switch the logic of the RPC flag "failed_payments_only"
which is false by default into a "--include_non_failed" in the CLI which
is false by thefault. So a user running the command without knowing what
they are doing are only deleting failed payments by default, not all of
the payments.
The use of golang.org/x/crypto/ssh/terminal was marked as deprecated
since that code was moved to its own repo golang.org/x/term.
With this commit we use the new package name directly, which was already
pulled in under its new name anyway.
Having one file per sub command seems a bit too excessive and isn't
really implemented for any of the other commands. So we just group the
Mission Control commands into their own file for now.
To make the "Payments" category a bit less overloaded and to move the
Mission Control configuration commands away from the "root" category, we
create the new "Mission Control" category that we move the commands
into. We do this in a single commit so the next one where we move them
into the same file can be a pure code move without any additional
changes.
With this commit we move all commands that can be found within the
"Payments" category into its own file called cmd_payments.go. The only
exception are the Mission Control related commands which we are going to
move to their own category and file in the next commit.
With the middleware handler in place, we now need to add a new gRPC
interceptor to the interceptor chain that will send messages to the
registered middlewares for each event that could be of interest to them.
With this commit we introduce the concept of RPC middleware: A mechanism
similar to the existing channel or HTLC interceptors but this time for
gRPC messages themselves.
An RPC middleware can register itself to the main RPC server to get
notified each time a new gRPC request comes in, a gRPC response is sent
back or a streaming RPC is connected. The middleware can
validate/inspect incoming requests and modify/overwrite outgoing
responses.
Since this also opens the door for malicious software to interfere with
lnd in a negative way, we bind everything to macaroons with custom
caveat conditions: A middleware declares upon registration which custom
caveat name it can handle. Only client requests that send a macaroon
with that custom caveat will then be given to the middleware for
inspection. The only exception is if the middleware instead registers
to use the read-only mode. In that mode it will be able to intercept
all requests/responses, even those not made with a special encumbered
macaroon. But the middleware won't be able to alter responses in the
read-only mode. Therefore requests with the default, unencumbered macaroons
can never be modified by any middleware.
The custom RPC middleware logic that we are going to add in the next
commits will need to log under their own sub logger so we add one with a
new subsystem name.
With the new condition and checker in place, we can give the end user
the ability to add such a custom caveat to a baked macaroon.
There won't be an RPC counterpart for this operation since all first party
caveats currently are only added on the client side.
Fixes#4383 by adding a new SafeCopyMacaroon function that correctly
clones all caveats and prevents modifications on the copy from affecting
the original.
The way the macaroon bakery library lnd uses works is that one has to
register a Checker method for each caveat name that should be supported.
Since we want to allow fully customizable custom caveats we add another
layer of naming to the caveat by splitting the condition of the "outer"
caveat into two pieces, the custom caveat name and the actual custom
caveat condition.
The custom Checker function only checks that the format is correct and
that there is a handler available for a custom condition. It does not
check the condition itself, however. If the passed in acceptor signals
acceptance of a custom caveat then the bakery accepts the macaroon as a
whole (given its signature, standard caveats and permissions are all
correct) and assumes that another component down the line will make sure
the actual custom condition of a caveat is valid.
Fixes#5680.
To make sure we're always reading from the WebSocket connection, we need
to always have an ongoing (but blocking) conn.ReadMessage() call going
on. To achieve this, we do the read in a separate goroutine and write to
a buffered channel. That way we can always read the next message while
the current one is being forwarded. This allows incoming ping messages
to be received and processed which then leads to the deadlines to be
extended correctly.
The request context was not properly used to pass it along to the gRPC
endpoint which caused streaming calls to still be active on the gRPC
side even if the WS side already hung up.
We also issue an explicit close on the forwarding writer to signal when
the WS side was closed.
Reduces the number of concurrent tranches of itests running to two on
ARM in an attempt to make the tests less flaky because of very high CPU
usage with the default 4 parallel tranches.
We'll want to re-use the abandon channel functionality for the batch
funding, as a cleanup in case the funding is aborted before publishing
any transaction.
We'll want to re-use the PSBT funding functionality from the wallet kit
sub server in the main RPC server. To be able to dynamically obtain an
instance of the wallet kit server we need to know its name under which
it registers itself in the list of sub server. We export the name so we
don't have to hard code it in the main server.
It seems that the GitHub CI runners share a CPU and therefore only have
very few ressources available. This causes the wallet unlocker and breach
arbiter tests to fail if we don't give them enough time to complete.
We add an additional test case to the on-chain fund recovery test that
tries restoring the same wallet from the extended master root key
instead of the seed.
In addition to creating a new wallet from an aezeed, we allow specifying
an exteded master root key as the main wallet key directly.
Because an exteded key (xprv) doesn't contain any information about the
creation time of the wallet, we must assume a birthday to start scanning
the chain from (if the user doesn't provide an explicit value). Since
lnd only uses SegWit addresses, it makes sense to
choose the date that corresponds to the first mainnet block that
contained SegWit transactions.
Restoring a wallet from an extended master root key will result in a
significantly longer initial wallet rescan time if the default value is
used.
Because we now get one more update per channel when closing it, we need
to update our test that looks at the close notifications sent by the
SubscribeChannelEvent RPC.
We want to make sure we can recover funds from a channel that was force
closed by the local node just before the node needed to be restored. We
add a special test case with specific assertions for that scenario.
With one more notification event being dispatched in the local force
close case we need to update one of the integration tests to account for
the additional message.
In case we force close a channel from our end the funds can be time
locked for up to 2 weeks worst case. If something happens to our node in
that time, we don't have any information on that channel anymore because
currently the channel is removed from the channel backup file the moment
the commitment transaction confirms.
Instead we want to keep the channel around in the SCB file until we've
actually swept the time locked funds.
It looks like lnd even supports recovering from such a case if the peer
is still online and can tell us what commit height to use for deriving
the commit point. If the peer isn't around anymore then external tools
could be used to brute force the commit height.
We might want to react to a channel being fully resolved after being
involved in a force close. For this we add a new callback and invoke it
where appropriate.
We'll want to be informed about a channel that's been fully resolved on
chain in case it was involved in a force close. We add a new event type
and emit method for it.
Oliver Gugger