Add support for LUKS token activation via PIN

[lehtojo]

This pull request introduces support for LUKS tokens that require a PIN for activation. Previously, only PIN-less token activation was supported.

Implementation Details

• Added a new method: CryptLuks2TokenHandle::activate_by_token_pin
• This wraps the underlying libcryptsetup_rs_sys::crypt_activate_by_token_pin function.

I implemented this as a separate method to keep the API clean. However, an alternative approach would be to refactor the existing CryptLuks2TokenHandle::activate_by_token method to accept an optional PIN parameter.

Summary by CodeRabbit

• New Features
  • Added PIN-based token authentication for LUKS2 volume activation, allowing encrypted volumes to be unlocked using a token plus an explicit PIN.
  • Supports optional token selection, optional label/name, and additional activation options so existing activation workflows work the same with or without a PIN.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Walkthrough

Adds a public method activate_by_token_pin to CryptLuks2TokenHandle that accepts a PIN byte slice and calls the FFI crypt_activate_by_token_pin, constructing optional name and usrdata pointers and returning the activation status or LibcryptErr. Guarded by cryptsetup24supported.

Changes

Cohort / File(s)	Summary
Token PIN activation src/luks2/token.rs	Added activate_by_token_pin<T>(&mut self, name: Option<&str>, token: Option<c_uint>, pin: &[u8], usrdata: Option<&mut T>, flags: CryptActivate) -> Result<c_uint, LibcryptErr> that mirrors activate_by_token but passes PIN pointer/length to crypt_activate_by_token_pin, computes name and usrdata pointers, and handles errors similarly.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Verify name and usrdata pointer computation matches activate_by_token.
• Confirm PIN pointer and length are passed correctly and handle empty PINs as intended.
• Check NULL token behavior when token is None aligns with C API expectations.
• Ensure error mapping and return type consistency with existing activation methods.

Poem

🐰 I thumped a key into the light,
A PIN now wakes the sleeping night,
Rust hops, calls C, and magic spins —
A tiny change, a dozen wins. 🔐

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: adding a new method for LUKS token activation with PIN support, which directly corresponds to the single file modification in src/luks2/token.rs.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[packit-as-a-service]

Congratulations! One of the builds has completed. 🍾

You can install the built RPMs by following these steps:

• sudo dnf install -y 'dnf*-command(copr)'
• dnf copr enable packit/stratis-storage-libcryptsetup-rs-460
• And now you can install the packages.

Please note that the RPMs should be used only in a testing environment.

[jbaublitz]

Overall this looks good, but I believe that this method was added in 2.4.0 based on a walk through git on the libcryptsetup.h header file. We need a version guard (as you will see with other more recently added methods). I believe for this it should be #[cfg(cryptsetup24supported)]

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

src/luks2/token.rs (1)

287-287: Consider exposing the token type parameter.

The hardcoded ptr::null() corresponds to the type parameter in crypt_activate_by_token_pin, which filters activation to tokens of a specific type (e.g., "luks2-keyring"). While NULL (meaning "any type") is a reasonable default, hardcoding it prevents callers from filtering by token type.

Consider adding an Option<&str> parameter for type to provide flexibility for use cases that require type-specific token activation. This would align with the pattern used for the name and token parameters.

Would you like me to generate a revised implementation that exposes the token type parameter?

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5507ede and 2ded8c0.

📒 Files selected for processing (1)

• src/luks2/token.rs (1 hunks)

🔇 Additional comments (2)

src/luks2/token.rs (2)

273-280: LGTM! Consistent parameter handling.

The parameter conversion logic correctly mirrors the implementation in activate_by_token, maintaining consistency across the API.

---

291-292: Verify the to_byte_ptr! macro conversion.

The PIN is passed as a pointer (via to_byte_ptr!) and length. Ensure that the to_byte_ptr! macro correctly converts &[u8] to the appropriate C pointer type expected by the FFI function (likely *const c_char or *const u8).

[jbaublitz]

Okay looks good to me!

[lehtojo]

Actually, I missed CodeRabbit's "nitpick" comment earlier. It might be an issue.

[jbaublitz]

@lehtojo Would you like to implement that? If so, I can hold off on merging this and re-review once you've done that.

[lehtojo]

@jbaublitz Done! I also changed how the name is passed in.

[jbaublitz]

Looks good to me! I'll merge this.