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.
This removes a vulnerability brought up by @Kixunil where both the lnd
and lncli binaries are executed to obtain their version before they have
been verified against the release. A malicious binary could have already
compromised the user's system before any of the checks had been
performed.
This commit it split out from the doc changes so that it can easily be
cherry-picked to master/0.13.0.
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.
In this commit, a new method `cleanClosedChannels` is added and called
when a circuit map is created. This method will delete the payment
circuits and keystones for closed channels.
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.
