In preparation for the next commit which bumps golang to a newer
version, we want to make some code changes that would otherwise render
some log-related calls problematic. With go1.24 a new govet rule was
added that disallows non-constant strings (i.e including a tag like
"%s") in calls to printf. See more in the related issue
https://github.com/golang/go/issues/60529.
Add the `commit_hash` field to the GetInfoResponse. The `commit_hash`
field will contain the most recent commit_hash that the build was based
on. If the build had uncommitted changes, this field will contain the
most recent commit hash, suffixed by "-dirty".
The semantics of the `version` field is also updated to always contain
the most recent semantic version of the litd node, following the
semantic versioning 2.0.0 spec (http://semver.org/).
In this commit, we special case the handling of BakeSuperMacaroon so as
to allow a user to make use of `litcli bakesupermacaroon` while LiT is
running in stateless init mode. The handling is as follows:
- if the call to _LiT's_ BakeSuperMacaroon is made while in stateless
init mode then we can assume that the macaroon provided is either:
1) an LND native macaroon which may or may not have the
necessary permissions for the _LND_
"/lnrpc.Lightning/BakeMacaroon" call.
2) a baked macaroon (possibly a super macaroon) which may or may
not have the permissions to the _LiT_
"/litrpc.Proxy/BakeSuperMacaroon" call.
For case 1: we check that the provided macaroon has the correct perms.
If it does, then we use LiT's existing connection to LND to bake the
super mac.
For case 2: we have a macaroon that doesnt have LND's bakemac call perms
directly but does have LiT's BakeSuperMac perms. So for this, we treat
the call as normal and verify using LiT's macaroon validator as normal.
Add the accounts service to status manager. This will allow us to query
the status of the accounts service and see if it is running or not.
For incoming gRPC requests to the accounts service, we also use the
status manager to check if the accounts service is running or not to
determine if we should let the request through or not.
Initialise an instance of the status manager in LightningTerminal.
Register its gRPC and REST endpoints and also add its method to the set
of LiT whitelisted permissions.
Currently `basicAuthToMacaroon` returns a different error for an
un-handled URI than is returned for other funcions which first check the
permissions manager to see if a URI is handled. With this commit, we
ensure that the error returned is the same so that the error we assert
on in tests can just be one error.
Due to the rpcProxy being started early now, it could be the case that a
call is made to `GetRemoteConn` before the remote connection has
actually been set up. This commit catches this case so that an error can
be returned and a panic avoided.
Remove the responsibility of creating an LND connection from the
rpcProxy and instead let the main LightningTerminal struct handle it.
All the lnd-connection specific functions are also moved into their own
file.
Add a `started` variable to the rpcProxy that is used to indicate if the
proxy is ready to handle requests. This is because currently the
webserver is dependent on the rpcProxy to start and we want to be able
to start the webserver without being dependent on the rpcProxy so that
it can be used to handle status requests in a future commit. So with
this commit, we can now saftely start the webserver earlier on and then
if requests come through for the rpcProxy, an error will be displayed to
the user.
Add a new `disableui` config option. If this option is set then the user
no longer needs to set the `uipassword` config option. This also means
that the user will no longer be able to interact with the local UI.
In this commit, a new Proxy service is added with a StopDaemon method.
This method can be used to stop the Litd service. This will be useful in
remote-mode itests where we want to restart Litd without also restarting
LND. It also provides a nice way of shutting down Litd in remote-mode.
A GetInfo method is also added to the service which for now just returns
the Litd version. The reason for adding this method now is so that
access to the new Proxy service can be tested in the itests withouth
actually shutting down Litd.
In this commit, a new PermissionsManager is added. It handles all the
active permissions that Lit has access to. This moves us away from using
global variables for permission lists. This change might seem overkill
on its own but hugely simplifies the permission management once we add
lnd subserver permissions.
Remove the use of the UI password from litcl. Use the litd macaroon
instead. Note, this means that in stateless mode, litcli won't have a
macaroon to use on disk and one must be baked specifically.
When a connection is tunneled through LNC the requests that go to the
daemons running in-process with LiT need to be registered correctly. To
make sure they are also authenticated, the RPC proxy's interceptors also
need to be registered on the LNC gRPC server instance.
But we don't want to allow calls to the LiT session server through LNC
until we have proper macaroon permissions set up for that server.
If a daemon is running in remote mode, we need to convert a super
macaroon into the daemon specific macaroon before sending it to the
remote daemon, since the super macaroon is issued by lnd and can only
be validated by lnd's macaroon root key.
To avoid the macaroon parsing to fail in session.IsSuperMacaroon(), we
want the dummy macaroon to be formally valid (meaning, it can be parsed)
but not actually valid (meaning, it will fail the signature verification
since we don't have the root key for it anywhere).
In integrated mode we hook directly into lnd's bufconn listener for any
connections to it. So we don't need any TLS setup and can bake a single
super macaroon that is used for all RPC calls.
Fixes#213 by allowing users to enable REST calls to be made directly to
the main HTTP(S) listener(s). This approach is chosen over spinning up
an additional listener (or multiple, if non-TLS is also needed) just for
REST because it should make everyone's lives easier if only one port
needs to be used. There also shouldn't be any security tradeoff since a
macaroon is still required and all communication happens over TLS
anyway.
The call flow diagram wasn't accurate what lead to an incorrect
assumption in the last PR.
In integrated mode, lnd spins up its gRPC server as the main entry point
and the other daemons need to hook into it.
If any of the daemons is configured to be running in remote mode, the
RPC proxy only acts as a gRPC web reverse proxy and just forwards any
requests to the correct backend.
For non-remote daemons the requests shouldn't get to the director in the
first place but instead be handled by the main gRPC server.
As a preparation for using the dialBackend function for other
daemons/backends as well, we rename it from dialLnd and add a name
parameter for more specific logs.
With the new lndclient version we can specify a single, custom macaroon.
We use the admin macaroon as the custom macaroon in the remote
connection case which removes the need to copy all subserver macaroons
to the host where LiT is running. Users baking custom non-admin
macaroons can also specify that directly with a new configuration
option.
