Allow connect to use configured TLS keys #2532
Conversation
The spec is limiting the size of both variables to one byte, thus there is no need to use wider types. Signed-off-by: Daniel Wagner <dwagner@suse.de>
It's possible to specify which PSK stored in the kernel keystore to use. This means the user has first to insert the key into the store and then figure out which ID to pass to the connect command because currently there is no automatic key lookup. This is not simple to make it work 'correctly' as there potentially a more than one key which matches the connection description. So this would need some match logic. Let's not go there for the moment. Instead, we allow the user to pass the configured key directly from the connect command. Signed-off-by: Daniel Wagner <dwagner@suse.de>
|
Weelll ... there was a reason why I did use the key IDs to reference the keys. If you specify the key on the commandline it will be present in the commandline args for that process for everyone to see (just do a 'cat /proc//cmdline and you can read the entire commandline argument details), with not even basic security restrictions. |
|
Which incidentally was the reasons why I want to rework DH-CHAP key handling to use the key store. |
|
Yep, I thought the same. Thus I am not sure if we really want this and I got here due the work on linux-nvme/libnvme#890 where @martin-gpy ask for the JSON output generated by the 'connect' command is showing the 'configured key'. The key in the keystore is obviously not the 'configured key' thus we can't produce a 'correct' JSON configuration file. I think we should keep the discussion in place, thus let's have it here linux-nvme/libnvme#890 |
|
And there is also |
|
We could insert the key description in the json output. With that we can lookup the matching key upon reload. |
Extend the
--tls_keyand--keyringargument to accept also configured keys.Depends on linux-nvme/libnvme#894