The frontend job was pinned to node 16, which is old enough that some of
the packages patched in this branch refuse to install there. tar and
esbuild want node 18 or newer, serialize-javascript wants 20.
Node was also only pinned in the frontend job. The backend,
proto-compile-check and itest jobs all reference matrix.node_version
without declaring it in their matrix, so the expression resolved to an
empty string and setup-node fell back to whatever the runner happened to
ship. Two of those run `yarn install --frozen-lockfile`, so they need a
known version too.
Both are fixed by a NODE_VERSION env var, matching how GO_VERSION is
already handled. It replaces the matrix entry rather than feeding it,
because the env context isn't available inside strategy.matrix.
Sweeps the build-time dependency tree, which is where most of what
`yarn audit` reports actually lives. This takes the frontend from 419
findings across 42 packages down to 16 across 9.
Most of it is lockfile-only. `yarn upgrade` does not re-resolve
transitive entries in yarn 1, so the affected entries were dropped from
yarn.lock and reinstalled, which picks the newest version each parent's
existing range already allows. That covers the four open dependabot PRs
(shell-quote, websocket-driver, @babel/core and
@babel/plugin-transform-modules-systemjs) along with @babel/helpers,
ajv, async, brace-expansion, form-data, glob, js-yaml, json5, nanoid,
terser and ws.
Re-resolving express to 4.22.2 pulls patched body-parser, cookie,
path-to-regexp and qs with it, and clears the stale minimatch 3.0.4 and
semver 7.0.0 pins at the same time.
browserslist and caniuse-lite had to move too. @babel/core 7.29 emits
'opera_mobile' as a compilation target and the pinned
@babel/helper-compilation-targets 7.17.7 rejects it, which broke the
production build until the whole toolchain was aligned.
storybook goes to 7.6.24 and webpack to 5.109.2, both direct
devDependencies pinned to vulnerable versions.
The `resolutions` additions are for packages whose parent pins a range
with no patched version in it. Each was verified against a build:
- svgo 2.8.3 removes the svgo 1.x subtree that @svgr/plugin-svgo drags
in. react-scripts sets `svgo: false`, so that plugin never runs, and
the production bundle is byte for byte identical with and without it.
- resolve-url-loader 5.0.0 is the only way to drop postcss 7. The
emitted CSS is unchanged, same content hash.
- @tootallnate/once, esbuild, nth-check, serialize-javascript, tar and
uuid are straightforward version forces.
What is left is either unfixable or would break the build:
- protoc-gen-js pulls got, http-cache-semantics, adm-zip and decompress
through the unmaintained `download` package. decompress has no
published fix. None of it runs outside `yarn protos`.
- webpack-dev-server 5 drops the onBeforeSetupMiddleware and
onAfterSetupMiddleware hooks that react-scripts 5.0.1 calls directly,
so forcing it would break `yarn start`.
- ip and lodash.pick have no patched version published.
- react-router needs v7, which is a separate migration.
Bumps the two production dependencies flagged by `yarn audit` that have
fixes available.
http-proxy-middleware goes to 2.0.10 for the Host-header routing bypass.
It also needs a `resolutions` entry, otherwise yarn keeps a second copy
at 2.0.9 under react-scripts > webpack-dev-server because the existing
`^2.0.0` range is already satisfied.
react-router-dom goes to 6.30.4 for the untrusted-path open redirect. It
is pinned exactly rather than with a caret: @remix-run/router is a direct
dependency at an exact version and react-router-dom pins its own copy
exactly too, so a caret here would let a future patch release install a
second copy of the router and hand <HistoryRouter> a history built by a
different module instance.
That bump pulls in a few related changes:
- react-router 6.4 folded the `history` package into @remix-run/router,
so the store now imports `createBrowserHistory` from there. Passing our
own history object is discouraged and would bundle history twice.
- @remix-run/router's type declarations use accessors in interfaces,
which needs TypeScript 4.3 or newer, so typescript goes to 4.9.5. TS
4.4 also began typing `catch` variables as `unknown`, so `handleError`
now takes `unknown` and narrows before reading `.message`, and the five
sites that read it directly narrow first as well.
- @types/history and @types/react-router-dom are v5-era leftovers that
now conflict with the types react-router-dom ships itself.
- The new history only accepts one active listener, but RouterStore and
<HistoryRouter> both need one, so RouterStore subscribes once and fans
updates out. It also needs `v5Compat` so listeners fire on push() and
replace() rather than only on back/forward.
reactour still pulls in a vulnerable lodash.pick with no patched version
published. reactour 1.18.0 is the end of the v1 line and v2 is a rewrite,
so that one is left alone for now.
Document the configurable maximum account payment size and optional
channel balance reservation check, including their defaults, fee
handling, and operational limitations.
Add an opt-in check that prevents the sum of all account balances from
exceeding the node's available local (outbound) channel balance. When
enabled via the new accounts.check-channel-balance config option, the
service rejects balance allocations that would over-provision the node:
creating an account, an administrative credit, or an administrative
balance increase now fails with ErrBalanceReservationExceeded if it
would push the total allocated balance above the node's local channel
balance.
Note that the total channel balance may still decrease below the already
allocated account balance. This can occur if the node operator decreases
the total channel balance through non-account related activity.
The check is a no-op by default to preserve the historical behaviour
where the operator manages over-provisioning themselves (accounts can
legitimately be created before channels are funded). Invoice-driven
credits are unaffected, as they are backed by real inbound payments.
Add an opt-in cap on the total amount a single account payment may
debit, including routing fees, enforced at the account interceptor for
both SendPaymentV2 and SendToRouteV2. When the new
accounts.max-payment-size-msat config option is set to a non-zero
value, payments whose amount plus fees exceeds it are rejected with
ErrPaymentExceedsMaxSize before the balance check and before any funds
are reserved.
For SendPaymentV2, the configured fee limit is included in the capped
amount. For SendToRouteV2, the route's stated fee is included.
This gives operators a guard rail against a compromised or misbehaving
account macaroon draining its balance in a single large payment. The
cap defaults to 0 (disabled), preserving existing behaviour, and is a
first step towards the finer-grained per-account spending controls
requested in the issue.
The kvdb-to-SQL data migration polls lnd's ListMacaroonIDs RPC, which
only becomes available once lnd reaches its "RPC active" state. On
nodes with a large channel/graph state, lnd can take well over a
minute to get there after the wallet is unlocked, which exceeded the
previous fixed 60-second (120 x 500ms) poll budget and caused the
migration - and therefore litd startup - to fail permanently,
requiring a manual restart.
Replace the fixed attempt cap with a wait bounded by the new
--lndreadytimeout config option, defaulting to a generous 10 minutes,
while still aborting early if the daemon is shutting down. The wait
happens inside the migration's SQL write transaction, so it is kept
bounded rather than unbounded as a safety backstop.
Add testSuperMacaroonOnStartup to verify startup baking logic. The test
restarts the node with the auto-baking config flags and asserts the
macaroon is baked with read-only or read-write permissions accordingly.
Also add validation tests verifying that starting with an invalid path
suffix or in stateless-init mode with baking enabled fails as expected.
Verify permission addition/expansion by starting the node with sub-servers
disabled and then restarting with sub-servers re-enabled. Also verify
the none config choice, asserting that no super macaroon file is
baked/created on startup.
Automatically bake a super macaroon on startup if it doesn't already
exist on disk and the `bake-super-macaroon` option is configured.
On startup, the node verifies if the super macaroon file exists. If
it does, it parses the macaroon, extracts and verifies the version and
root key ID, and asserts that the macaroon permissions exactly match
the expected active permissions. If there is a mismatch, the macaroon
is regenerated and overwritten on disk. If the file does not exist, a
new super macaroon is baked and written directly to disk.
Also validate that the `bake-super-macaroon` option is not enabled when
LND is running in stateless initialization mode, failing startup early
if they are used together.
Introduce configuration flags to enable baking a super macaroon on
startup. Add --bake-super-macaroon (none, read-only, read-write) and
--super-macaroon-path.
Also add validation logic to ensure that the configured super macaroon
path ends with the expected '.macaroon' suffix, rejecting startup early
otherwise.
Introduce helper functions in the macaroons package to manage super
macaroon files and permissions. Add SuperMacaroonExists,
MacaroonMatchesPermissions, and BakeAndWriteSuperMacaroon.
Add integration tests inside itest/litd_accounts_test.go to verify
retrieval of account payments against a running LND node, validating
correct responses for ID/label lookup, offsets, pagination limits,
and counting of total payments.
Introduce the 'payments' subcommand under 'litcli accounts' to query
account payment history. Supports parameters for offset, page size
limits, and counting of total payments.
Implement the AccountPayments handler on the Accounts RPC server.
The handler resolves accounts by ID or label, loads its payment hashes,
applies pagination constraints, and fetches complete payment details
concurrently from LND's TrackPaymentV2. It also returns pagination
metadata including the total count of payments.
Introduce the ListAccountPayments and CountAccountPayments methods to
the accounts Store interface.
ListAccountPayments enables retrieval of a paginated list of payment
entries associated with a given account ID, supporting offset and
limit. CountAccountPayments returns the total number of payments
associated with the account.
Implement ListAccountPayments in the Bolt-based kvdb account store.
The retrieved account payments are sorted in ascending lexicographical
order of their payment hash.
Add sqlc queries to select account payment hashes from the database.
Implement the ListAccountPayments method in the SQLStore, allowing
retrieval of stored payment hashes for SQLite and Postgres backends.
Also define the AccountPaymentEntry helper struct in
accounts/interface.go to wrap payment hashes and details.
Define the AccountPayments RPC endpoint and its request/response
messages in lit-accounts.proto. This endpoint allows querying
paginated payment history for a specific account.
Also update the frontend JS/TS proto sanitization script to map the
imported lnd.proto file to its flat directory path, fixing app build.
Utilize a sync.Pool for *big.Int instances in CryptoRandIntn to avoid
frequent heap allocations. This significantly reduces garbage collection
pressure when randomizing timestamps, amounts, and fees inside loops
(e.g. iterating over forwarding history responses).
Upgrade the randIntn function signature from int to int64 to prevent
unpredictable integer truncation on 32-bit systems (e.g., Raspberry Pi).
This ensures UnixNano timestamps in hideTimestamp and large amounts in
hideAmount do not cause unexpected runtime failures when calling
ForwardingHistory.
