Repository navigation
http-bridge key management
#22
siddhantk232
started this conversation in
Ideas & RFCs
Replies: 1 comment
#[derive(clap::Subcommand, Debug)]
pub enum Command {
// .. others skipped ..
#[clap(about = "Generate a key-pair.")]
Keygen {
#[arg(
long,
help = "The path to store the key. Leave empty to print key on stdout.",
env = "MALAI_KEY_PATH"
)]
store: Option<String>,
#[arg(
long,
help = "Do not store secret key in keyring, instead store it in the given path, or print on stdout.",
default_value_t = false
)]
insecure: bool,
},
}This is what I have in mind. keygen will by default generate a public key, store its private key to keyring, and print it out. You can pass If |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Can we not let the http-bridge whip up an iroh key wheneve it starts?
Tomorrow we want to whitelist keys as well (as part of ACL). We can allow that today, add some CLI argument which tells you which bridge (identified by key) is allowed to access this service, but that takes us in the direction of "ACL as part of malai service", which we are avoiding.
If the bridge is started without stable key, via env or cli flag, I am okay with generating new key on every start.
--public-key(get private key via OS specific keychain) andMALAI_PUBLIC_KEY(both can either point to the key, or a file containing the key).Similarly
--private-key.If neither passed, generate new key (and report this, and tell people about
--{public, private}-key,MALAI_{PUBLIC, PRIVATE}_KEYenvs. We probably will also needmalai keygen, which takes--store-pravate-key-to-os-keychain,--print-private-key(else we only print public key).Just listing design, not necessarily HN blocker, we can put it in a discussion, and implement the "generate key on start" for now.
For
malai keygenwe should be as close tossh keygenas possible, so that people can apply their "common sense" with malai alsoAll reactions