~ This is the response to lightningd's HSM_INIT request, which is the first * thing it sends. */
| 494 | /*~ This is the response to lightningd's HSM_INIT request, which is the first |
| 495 | * thing it sends. */ |
| 496 | static struct io_plan *init_hsm(struct io_conn *conn, |
| 497 | struct client *c, |
| 498 | const u8 *msg_in) |
| 499 | { |
| 500 | struct secret *hsm_encryption_key; |
| 501 | struct bip32_key_version bip32_key_version; |
| 502 | u32 minversion, maxversion; |
| 503 | struct tlv_hsmd_init_tlvs *tlvs; |
| 504 | const u32 our_minversion = 4, our_maxversion = 6; |
| 505 | const char *hsm_passphrase; |
| 506 | |
| 507 | /* This must be lightningd. */ |
| 508 | assert(is_lightningd(c)); |
| 509 | |
| 510 | /*~ The fromwire_* routines are autogenerated, based on the message |
| 511 | * definitions in hsm_client_wire.csv. The format of those files is |
| 512 | * an extension of the simple comma-separated format output by the |
| 513 | * BOLT tools/extract-formats.py tool. */ |
| 514 | if (!fromwire_hsmd_init(NULL, msg_in, &bip32_key_version, &chainparams, |
| 515 | &hsm_encryption_key, |
| 516 | &dev_force_privkey, |
| 517 | &dev_force_bip32_seed, |
| 518 | &dev_force_channel_secrets, |
| 519 | &dev_force_channel_secrets_shaseed, |
| 520 | &minversion, &maxversion, &tlvs)) |
| 521 | return bad_req(conn, c, msg_in); |
| 522 | |
| 523 | /*~ Usually we don't worry about API breakage between internal daemons, |
| 524 | * but there are other implementations of the HSM daemon now, so we |
| 525 | * do at least the simplest, clearest thing. */ |
| 526 | if (our_minversion > maxversion || our_maxversion < minversion) |
| 527 | return bad_req_fmt(conn, c, msg_in, |
| 528 | "Version %u-%u not valid: we need %u-%u", |
| 529 | minversion, maxversion, |
| 530 | our_minversion, our_maxversion); |
| 531 | |
| 532 | /*~ We used to have lightningd hand us the encryption key derived from |
| 533 | * the passphrase which was used to encrypt the `hsm_secret` file. Then |
| 534 | * Rusty gave me the thankless task of introducing BIP-39 mnemonics. I |
| 535 | * think this is some kind of obscure CLN hazing ritual? Anyway, the |
| 536 | * passphrase needs to be *appended* to the mnemonic, so the HSM needs |
| 537 | * the raw passphrase. To avoid a compatibility break, I put it inside |
| 538 | * the TLV, and left the old "hsm_encryption_key" field in place (and lightningd |
| 539 | * never sets that anymore), and we use the TLV instead. */ |
| 540 | if (tlvs->hsm_passphrase) |
| 541 | hsm_passphrase = tlvs->hsm_passphrase; |
| 542 | else |
| 543 | hsm_passphrase = NULL; |
| 544 | |
| 545 | if (!developer) { |
| 546 | assert(!dev_force_privkey); |
| 547 | assert(!dev_force_bip32_seed); |
| 548 | assert(!dev_force_channel_secrets); |
| 549 | assert(!dev_force_channel_secrets_shaseed); |
| 550 | } |
| 551 | |
| 552 | /* Once we have read the init message we know which params the master |
| 553 | * will use */ |
no test coverage detected