cmd/litcli: add super macaroon helper commands #568
Conversation
|
cc @gkrizek |
|
happy to add any other helpers in this area that would be useful :) ideas welcome! |
|
i could maybe add a |
That would be quite helpful. It was quite complicated and error prone trying to bake the super macaroon with the normal BakeMacaroon API as described here: lightninglabs/lightning-api-ng#19. I think it would also help clarify that there is a difference between the two, which I was unaware of before running into that issue. |
|
@ellemouton, remember to re-request review from reviewers when ready |
ellemouton
force-pushed
the
superMacHelpers
branch
2 times, most recently
from
17458b8 to
27e6806
Compare
There was a problem hiding this comment.
Thanks for the review @guggero ! I've updated and have added a BakeSuperMacaroon endpoint along with a bakesupermacaroon litcli command.
|
Ah, just one request: Can we please add the new RPC to one of the itests? Just to make sure authentication and everything works as expected. |
is this not covered by the existing test for or do you mean that we should use the new endpoint to bake a macaroon in the itests & then test that that macaroon works for other endpoints? |
ellemouton
force-pushed
the
superMacHelpers
branch
from
7633885 to
383b4c6
Compare
Ah yes, you're right. So all the security restrictions should apply to the new call as well. SGTM. |
| var file_proxy_proto_msgTypes = make([]protoimpl.MessageInfo, 4) | ||
| var file_proxy_proto_msgTypes = make([]protoimpl.MessageInfo, 6) | ||
| var file_proxy_proto_goTypes = []interface{}{ | ||
| (*StopDaemonRequest)(nil), // 0: litrpc.StopDaemonRequest |
There was a problem hiding this comment.
This is probably a stupid comment, but just wanted to make sure this isn't a potential issue:
There is no problem here that this overwrites the old msgTypes values here with new types, correct (ie. value 0 was the type litrpc.StopDaemonRequest but now becomes litrpc.BakeSuperMacaroonRequest)? Just thinking if we'd have external services or something that uses the protos and that way become incompatible, or if this could somehow become a backwards compatibility issue if one downgrades LiT or so.
This is likely not something that could become an issue, but thought I'd just leave this comment to make sure that's the case.
There was a problem hiding this comment.
good question!
So I think that either:
- these indices are only used within this file. So if you scroll up to where
file_proxy_proto_msgTypesis used, you can see that it is only used by the message types once the types are known and are not used on the wire. - or, they are used on the wire but the mapping is conveyed via the
file_proxy_proto_rawDescdescriptor above.
either way - gRPC protos are backwards compatible & you can test this by running Lit with this PR but compiling litcli with master & then see that the litcli getinfo or litcli stop calls work just the same no matter if litcli is compiled with this branch or master branch :)
Regenerate the protos after the recent bump of the protobuf dependency.
In this commit, a `supermacrootkey` helper command is added which lets a user generate a random root key ID for a super macaroon along with an `issupermacaroon` command that allows a users to easily confirm if a macaroon is considered a super macaroon or not. Neither of these commands require a connection to LiTd.
ellemouton
force-pushed
the
superMacHelpers
branch
from
383b4c6 to
2f6defe
Compare
5 participants
This PR adds a few super macaroon related commands:
litcli helper supermacrootkeycommand is added which lets a user generate a random root key ID for a super macaroonlitcli helper issupermacarooncommand allows a users to easily confirm if a macaroon is considered a super macaroon or not.litcli helper bakesupermacarooncan be used to bake a super macaroon.The
supermacrootkeyandissupermacarooncommands dont require a connection to LiTd.