keys: emit the KX-HMAC-CHAP secret representation, and name the commands after it - #3827
Open
kariya-mitsuru wants to merge 9 commits into
Open
keys: emit the KX-HMAC-CHAP secret representation, and name the commands after it#3827kariya-mitsuru wants to merge 9 commits into
kariya-mitsuru wants to merge 9 commits into
Conversation
Put the secret in the DHHC-1 string instead of the transformed key, and drop -n/--nqn with it. The deprecated gen-dhchap-key alias still accepts -n/--nqn: it warns and drops it before forwarding, so a command line written for nvme-cli 2.x still produces a secret instead of being rejected for an option that no longer exists. Signed-off-by: Mitsuru Kariya <kariya_mitsuru@hotmail.com>
The hash identifier records the transform the consumer applies to the secret; it does not constrain the length of the secret itself. Accept a 32, 48 or 64 byte secret with every hash id, matching b291bcc, and validate the length through the same helper check-kxchap now uses. Signed-off-by: Mitsuru Kariya <kariya_mitsuru@hotmail.com>
The DHHC-1 string carries the secret itself now, so take the length from -s when the secret is given as hex, and let an -l given alongside it only confirm that length. 2.x rejected a mismatch. b7cdfb1 moved the hex parsing into libnvme, which truncates a -s longer than -l instead, printing a warning on stdout and exiting 0. Signed-off-by: Mitsuru Kariya <kariya_mitsuru@hotmail.com>
Two characters make a byte, but sscanf("%02x") reads a lone trailing
one as a byte of its own, zero-padded. An odd count was therefore
accepted whenever it rounded up to the length in force: 63 characters
ending ...bababa produced a secret ending ...ababab0a.
nvme-cli 2.x did this too. Reject the input rather than emit a secret
the caller never gave.
Signed-off-by: Mitsuru Kariya <kariya_mitsuru@hotmail.com>
The DHHC-1 string these commands take is a secret representation, not a key. Wording only. Signed-off-by: Mitsuru Kariya <kariya_mitsuru@hotmail.com>
"Key is valid" becomes "Secret is valid", the keyring lookup messages follow, and the validation errors say secret where they said key. validate_kxchap_key() is shared with 'keys import', so its messages change there too. While here, drop the deprecated alias page's claim that the options and behaviour are identical to nvme-cli 2.x. The next patch makes that true for the options; the wording is what changes here. Signed-off-by: Mitsuru Kariya <kariya_mitsuru@hotmail.com>
nvme-cli 2.x took the secret in --key/-k and had no other option. The command this alias forwards to spells that --keydata/-d and gives -k to --keyring, so forwarding argv unchanged turned "check-dhchap-key -k <secret>" into a keyring lookup that then waited for a secret on stdin. Parse the 2.x command line in the alias and rebuild it for the plugin, the way gen-dhchap-key already does. The options the command grew after 2.x are not reachable through the alias, which is what it means for it to present the 2.x interface. This supersedes the note the alias page carried about --keydata. Signed-off-by: Mitsuru Kariya <kariya_mitsuru@hotmail.com>
Rename gen-kxchap and check-kxchap to gen-kxchap-secret and check-kxchap-secret. The deprecated aliases forward to the new names. Signed-off-by: Mitsuru Kariya <kariya_mitsuru@hotmail.com>
Rename --key-length to --secret-length. The 2.x spelling is not kept here: a command line written for 2.x goes through the gen-dhchap-key alias, which parses --key-length itself, and one written for a 3.0 pre-release names a command this series renames anyway. Signed-off-by: Mitsuru Kariya <kariya_mitsuru@hotmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Nine patches against
master(4d033951a). Addresses #3713.nvme keys gen-kxchaptransforms the secret into a key before encoding it, so asecret given with
-snever reaches the output. This series emits it as itstands (NVMe Base 2.4, section 8.3.4.5.8), lets the secret rather than the hash
id decide its length, fixes two ways a secret could come out different from the
one supplied, and moves the wording from key to secret.
More patches than the three sketched in #3713: re-reading my own work turned up
two ways a
-scame out different from the one given, andcheck-dhchap-keyhad the same
-ktrapgen-dhchap-keydid. Three of the changes reach acommand line written against 2.x and are listed under NEWS.md's
incompatible-changes heading.
Testing
meson test109 ok / 2 expected fail / 0 failat each
checkpatch.pl --strict: 0 errors, warnings only on pre-existing over-lengthstrings
tests/cli/nvme_keys_test.pygrows from 21 to 33 cases, five of them pinningthe 2.x alias surface; each case pinning new behaviour was confirmed to fail
on its parent commit
--hmacx--secretx--key-lengthswept exhaustively against a 2.16 build:apart from the three incompatibilities, every combination either matches 2.16
or turns one of its errors into a success