62 lines
2.3 KiB
Text
62 lines
2.3 KiB
Text
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 one 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.
|