| Cryptsetup 1.4.3 Release Notes |
| ============================== |
| |
| Changes since version 1.4.2 |
| |
| * Fix readonly activation if underlying device is readonly (1.4.0). |
| |
| * Fix loop mapping on readonly file. |
| |
| * Include stddef.h in libdevmapper.h (size_t definition). |
| |
| * Fix keyslot removal for device with 4k hw block (1.4.0). |
| (Wipe keyslot failed in this case.) |
| |
| * Relax --shared flag to allow mapping even for overlapping segments. |
| |
| The --shared flag (and API CRYPT_ACTIVATE_SHARED flag) is now able |
| to map arbitrary overlapping area. From API it is even usable |
| for LUKS devices. |
| It is user responsibility to not cause data corruption though. |
| |
| This allows e.g. scubed to work again and also allows some |
| tricky extensions later. |
| |
| * Allow empty cipher (cipher_null) for testing. |
| |
| You can now use "null" (or directly cipher_null-ecb) in cryptsetup. |
| This means no encryption, useful for performance tests |
| (measure dm-crypt layer overhead). |
| |
| * Switch on retry on device remove for libdevmapper. |
| Device-mapper now retry removal if device is busy. |
| |
| * Allow "private" activation (skip some udev global rules) flag. |
| Cryptsetup library API now allows to specify CRYPT_ACTIVATE_PRIVATE, |
| which means that some udev rules are not processed. |
| (Used for temporary devices, like internal keyslot mappings where |
| it is not desirable to run any device scans.) |
| |
| * This release also includes some Red Hat/Fedora specific extensions |
| related to FIPS140-2 compliance. |
| |
| In fact, all these patches are more formal changes and are just subset |
| of building blocks for FIPS certification. See FAQ for more details |
| about FIPS. |
| |
| FIPS extensions are enabled by using --enable-fips configure switch. |
| |
| In FIPS mode (kernel booted with fips=1 and gcrypt in FIPS mode) |
| |
| - it provides library and binary integrity verification using |
| libfipscheck (requires pre-generated checksums) |
| |
| - it uses FIPS approved RNG for encryption key and salt generation |
| (note that using /dev/random is not formally FIPS compliant RNG). |
| |
| - only gcrypt crypto backend is currently supported in FIPS mode. |
| |
| The FIPS RNG requirement for salt comes from NIST SP 800-132 recommendation. |
| (Recommendation for Password-Based Key Derivation. Part 1: Storage Applications. |
| http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf) |
| LUKS should be aligned to this recommendation otherwise. |