Open
Conversation
71c64df to
4783a1e
Compare
When a LUKS device is formatted with a non-default hash algorithm (e.g. sha512), clevis operations that add or update key slots (bind, regen, edit) did not pass the original hash to cryptsetup, causing new slots to silently default to sha256. Add clevis_luks_get_hash() to extract the device's hash algorithm from the LUKS header (supports both LUKS1 "Hash spec:" and LUKS2 "Hash:" fields). Use it in clevis_luks_add_key() and clevis_luks_update_key() to pass --hash to cryptsetup, preserving the original hash algorithm. Add unit tests for bind, regen and edit operations on both LUKS1 and LUKS2 devices formatted with sha512, verifying the hash is preserved through each operation. Co-Authored-By: Claude <[email protected]> Signed-off-by: Sergio Arroutbi <[email protected]>
4783a1e to
a77ac7f
Compare
Address code review findings for the hash handling logic: - Fix LUKS2 hash extraction to target keyslot sections specifically, avoiding false matches from digest sections that may use a different hash algorithm. - Add input validation to clevis_luks_get_hash() using POSIX-compatible case pattern matching, rejecting values containing characters outside [a-zA-Z0-9_-] to prevent command argument injection via crafted LUKS headers. - Replace echo with printf for safe output of hash values. - Suppress cryptsetup stderr on extraction to handle missing or unreadable devices gracefully. - Add fallocate fallback to dd in new_device_hash() for CI environments where fallocate is not supported. Add unit tests for hash extraction and validation: - get-hash-luks1: tests extraction across multiple algorithms (sha256, sha512, sha384, sha1, ripemd160) and error handling for empty, non-existent, and non-LUKS devices. - get-hash-luks2: same coverage for LUKS2, plus verification that keyslot hash is returned rather than digest hash. - get-hash-validation: exercises the validation logic directly against injection patterns (semicolons, command substitution, backticks, pipes, spaces, ampersands, empty strings). Co-Authored-By: Claude <[email protected]> Signed-off-by: Sergio Arroutbi <[email protected]>
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
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.
When a LUKS device is formatted with a non-default hash algorithm (e.g. sha512), clevis operations that add or update key slots (bind, regen, edit) did not pass the original hash to cryptsetup, causing new slots to silently default to sha256.
Add clevis_luks_get_hash() to extract the device's hash algorithm from the LUKS header (supports both LUKS1 "Hash spec:" and LUKS2 "Hash:" fields). Use it in clevis_luks_add_key() and clevis_luks_update_key() to pass --hash to cryptsetup, preserving the original hash algorithm.
Add unit tests for bind, regen and edit operations on both LUKS1 and LUKS2 devices formatted with sha512, verifying the hash is preserved through each operation.