cryptsetup

Overview

cryptsetup provides the userspace tools used to configure and manage encrypted storage volumes on Linux. In practice, it is the command-line front end for working with dm-crypt and LUKS volumes. The package is useful wherever encrypted block devices, removable media, or encrypted system volumes need to be created, opened, inspected, resized, or reconfigured. The upstream project describes itself as “Cryptsetup and LUKS - open-source disk encryption.” (gitlab.com)

For a Linux distribution, this package is typically important because it supplies the administrative tools that go together with kernel encryption support and boot-time integration through crypttab(5) and systemd-cryptsetup(8). NiceOS maintainers should verify the exact packaging split and runtime integration points for this branch before relying on them. (man7.org)

Purpose and typical use cases

Typical use cases include:

• creating and managing LUKS-encrypted volumes;
• opening and closing encrypted block devices;
• checking device status and metadata;
• resizing or refreshing active mappings when required;
• configuring encrypted volumes for boot-time activation;
• working with tools related to encrypted storage administration. (man7.org)

Typical users are:

• system administrators who manage encrypted disks and boot volumes;
• developers who need to test storage or installer workflows;
• security engineers reviewing disk-encryption tooling;
• CI/CD maintainers who build or validate packages and images with encrypted storage support;
• desktop and server users who need to unlock encrypted volumes during normal operation. (man7.org)

Upstream project

The upstream project lives at the canonical GitLab repository for cryptsetup. It is the source of the command-line utilities and documentation used by this package. The upstream manuals and project pages are the best references when checking command behavior or packaging expectations. (gitlab.com)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic;
• SOURCES/ — source manifests and other source-control metadata used by the build system;
• METADATA/ — repository metadata used by the packaging workflow;
• SBOM/ — software bill of materials data, when present for the package.

Large upstream source archives are intentionally not stored in this Git repository. Instead, source integrity is tracked through manifest files in SOURCES/. NiceOS maintainers should treat those manifests as the authoritative packaging-side record of what source inputs belong to the package build.

Source storage and integrity policy

The repository keeps metadata needed to reproduce the package build, but not the full upstream source archive contents. This keeps the dist-git history small and avoids storing large generated or vendor-supplied tarballs directly in Git.

Before updating the package, verify that:

• the source manifest in SOURCES/ points to the intended upstream source set;
• any auxiliary patch or metadata files still match the upstream tree;
• the spec file still references the correct build-time sources and subpackages;
• any generated files that are committed to the repository need regeneration;
• no packaging-only files were accidentally dropped or duplicated.

If the source layout changes upstream, NiceOS maintainers should verify whether the manifest files or packaging patches need to be adjusted.

NiceOS maintenance notes

Before submitting an update, check the following:

• confirm the upstream release notes and changelog for packaging-impacting changes;
• review whether any spec patches are still needed or have become obsolete;
• check whether the build requires regenerated metadata, man pages, completions, or other generated files that are committed in the packaging tree;
• verify build dependencies against the branch policy for NiceOS;
• test that the package still builds cleanly in the target build environment;
• run the relevant functional checks for the installed tools, especially basic open/close/status flows for encrypted devices when a test environment is available;
• review whether boot-time integration or service units changed upstream and require packaging updates.

Risks to consider:

• upstream changes in command behavior may affect installers, system tools, or automation scripts;
• source layout changes may invalidate existing packaging patches or manifests;
• generated files can silently drift if they are not refreshed together with the spec update;
• changes in documentation or helper utilities may require a rebuild of packaged docs or completions.

If any of these points cannot be confirmed locally, NiceOS maintainers should verify them against upstream sources before merging the update.

Build and verification checklist

For RPM maintainers, a practical checklist is:

1. Inspect the spec file and source manifests in SOURCES/.
2. Compare the packaging metadata with the upstream release notes.
3. Check whether any patches still apply cleanly and still serve a purpose.
4. Rebuild the package in a clean environment.
5. Run rpmlint or the repository’s preferred packaging checks, if available.
6. Verify file ownership, permissions, and package splits.
7. Install the built RPMs in a test root or container.
8. Exercise basic commands such as version display, volume status, and a non-destructive test flow if a safe test device is available.
9. Confirm that documentation, man pages, and any helper scripts are installed in the expected locations.
10. Review the resulting files for accidental changes outside the intended packaging scope.

References

• cryptsetup upstream project
• Cryptsetup and LUKS overview
• cryptsetup(8) manual page
• systemd-cryptsetup(8) manual page
• cryptsetup-open(8) manual page
• cryptsetup-benchmark(8) manual page

Russian documentation

See README_RU.md for the Russian version of this document.

Dist-git repository notes

• Package repository: rpms/cryptsetup
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.