cmd/litcli: add super macaroon helper commands

[ellemouton]

This PR adds a few super macaroon related commands:

• litcli helper supermacrootkey command is added which lets a user generate a random root key ID for a super macaroon
• litcli helper issupermacaroon command allows a users to easily confirm if a macaroon is considered a super macaroon or not.
• litcli helper bakesupermacaroon can be used to bake a super macaroon.

The supermacrootkey and issupermacaroon commands dont require a connection to LiTd.

[ellemouton]

cc @gkrizek

[ellemouton]

happy to add any other helpers in this area that would be useful :) ideas welcome!

[ellemouton]

i could maybe add a bakesupermac endpoint?

[CRex15]

i could maybe add a bakesupermac endpoint?

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.

[guggero]

Very nice addition! Just a few usability/UX comments, otherwise looks great.

[lightninglabs-deploy]

@ellemouton, remember to re-request review from reviewers when ready

[ellemouton]

Thanks for the review @guggero ! I've updated and have added a BakeSuperMacaroon endpoint along with a bakesupermacaroon litcli command.

[guggero]

Very nice, LGTM 🎉

[guggero]

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.

[ellemouton]

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 litrpc.Proxy.GetInfo? since they are both for the same rpc service.

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?

[guggero]

is this not covered by the existing test for litrpc.Proxy.GetInfo? since they are both for the same rpc service.

Ah yes, you're right. So all the security restrictions should apply to the new call as well. SGTM.

[ViktorTigerstrom]

Awesome, LGTM once rebased 🚀! Should be really useful commands!!

Only thing I noticed are a minor typo, and a sanity check to ensure my comment below isn't a potential issue.

[ViktorTigerstrom]

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.

[ellemouton]

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_msgTypes is 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_rawDesc descriptor 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 :)