-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remote Signer Proxy #6
base: master
Are you sure you want to change the base?
Conversation
Please add libgrpc-dev and libgrpc++-dev to the dependencies section in doc/INSTALL.md But still with this installed, I get a compilation error: |
Will fix, thanks! More detailed notes for our proxy can be found in The error you are seeing suggests that the protobuf compiler is not being run to generate the Do you have the following symbolic link to a sibling
Also, a rebase of the proxy onto the current c-lightning master branch is in the works, please let me know if that would be useful to you. |
Thanks for the hints. |
@ulrichard I've (force) pushed a new version of this branch which is based on a much newer c-lightning version. |
2bdab31
to
04ce198
Compare
a2dc5ba
to
c6abeac
Compare
The variable `block` (instace of `struct block`) is allocated on the stack without being initialized, i.e. its member `prev` points to nowhere. This causes a segmentation fault on my machine on the binding of "prev_hash" on running `wallet_block_add`, as the following core-dump analysis shows: $ egdb ./wallet/test/run-wallet ./run-wallet.core [...] Core was generated by `run-wallet'. Program terminated with signal SIGSEGV, Segmentation fault. ---Type <return> to continue, or q <return> to quit--- #0 0x000008f67a04b660 in memcpy (dst0=<optimized out>, src0=0x100007f8c, length=32) at /usr/src/lib/libc/string/memcpy.c:97 97 TLOOP1(*dst++ = *src++); (gdb) bt #0 0x000008f67a04b660 in memcpy (dst0=<optimized out>, src0=0x100007f8c, length=32) at /usr/src/lib/libc/string/memcpy.c:97 #1 0x000008f73e838f60 in sqlite3VdbeMemSetStr () from /usr/local/lib/libsqlite3.so.37.12 #2 0x000008f73e83cb11 in bindText () from /usr/local/lib/libsqlite3.so.37.12 #3 0x000008f44bc91345 in db_sqlite3_query (stmt=0x8f6845bf028) at wallet/db_sqlite3.c:77 #4 0x000008f44bc91122 in db_sqlite3_exec (stmt=0x8f6845bf028) at wallet/db_sqlite3.c:110 #5 0x000008f44bcbb3b2 in db_exec_prepared_v2 (stmt=0x8f6845bf028) at ./wallet/db.c:2055 #6 0x000008f44bcc6890 in wallet_block_add (w=0x8f688b5bba8, b=0x7f7ffffca788) at ./wallet/wallet.c:3556 #7 0x000008f44bce2607 in test_wallet_outputs (ld=0x8f6a35a7828, ctx=0x8f6a35c0268) at wallet/test/run-wallet.c:1104 #8 0x000008f44bcddec0 in main (argc=1, argv=0x7f7ffffcaaf8) at wallet/test/run-wallet.c:1930 Fix by explicitely setting the whole structure to zero. [ Rebuilt generated files, too --RR ]
9ffe7b2
to
8c80dd9
Compare
8c80dd9
to
1a56fa7
Compare
d4586fb
to
997e006
Compare
321ef87
to
73d40f4
Compare
…rk, and vlsd job control
Skip test with bolt12 invoice for now
- "channel stub can only return point for commitment number zero" - likely caused by CLN commit c0cc285 - possibly we relax the check, may not be security critical - See issue https://gitlab.com/lightning-signer/validating-lightning-signer/-/issues/245
Require Invoices
It is possible for db_column_bytes() to return 0 and for db_column_blob() to return NULL even when db_column_is_null() returns false. We need to short circuit in this case. Detected by UBSan: db/bindings.c:479:12: runtime error: null pointer passed as argument 2, which is declared to never be null /usr/include/string.h:44:28: note: nonnull attribute specified here #0 0x95f117 in db_col_arr_ db/bindings.c:479:2 #1 0x95ef85 in db_col_channel_type db/bindings.c:459:32 #2 0x852c03 in wallet_stmt2channel wallet/wallet.c:1483:9 #3 0x81f396 in wallet_channels_load_active wallet/wallet.c:1749:23 #4 0x81f03d in wallet_init_channels wallet/wallet.c:1765:9 #5 0x72f1f9 in load_channels_from_wallet lightningd/peer_control.c:2257:7 #6 0x672856 in main lightningd/lightningd.c:1121:25
This PR adds an alternate implementation of c-lightning's hsmd daemon. The private keys and secrets are sequestered in an external program, the Remote Lightning Signer. This remote-hsmd daemon proxies all signing requests to the remote daemon.
Please see the Lightning Signer Overview for more information.