diff options
Diffstat (limited to '')
| -rw-r--r-- | docs/v2.3.5-ReleaseNotes | 181 |
1 files changed, 181 insertions, 0 deletions
diff --git a/docs/v2.3.5-ReleaseNotes b/docs/v2.3.5-ReleaseNotes new file mode 100644 index 0000000..bad4fdf --- /dev/null +++ b/docs/v2.3.5-ReleaseNotes @@ -0,0 +1,181 @@ +Cryptsetup 2.3.5 Release Notes +============================== +Stable bug-fix release with minor extensions. + +All users of cryptsetup 2.x and later should upgrade to this version. + +Changes since version 2.3.4 +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Fix partial reads of passphrase from an interactive terminal. + Some stable kernels (5.3.11) started to return buffer from a terminal + in parts of maximal size 64 bytes. + This breaks the reading of passphrases longer than 64 characters + entered through an interactive terminal. The change is already fixed + in later kernel releases, but tools now support such partial read from + terminal properly. + +* Fix maximal length of password entered through a terminal. + Now the maximal interactive passphrase length is exactly + 512 characters (not 511). + +* integritysetup: support new dm-integrity HMAC recalculation options. + + In older kernels (since version 4.19), an attacker can force + an automatic recalculation of integrity tags by modifying + the dm-integrity superblock. + This is a problem with a keyed algorithms (HMAC), where it expects + nobody can trigger such recalculation without the key. + (Automatic recalculation will start after the next activation.) + + Note that dm-integrity in standalone mode was *not* supposed + to provide cryptographic data integrity protection. + Despite that, we try to keep the system secure if keyed algorithms + are used. + Thank Daniel Glöckner for the original report of this problem. + + Authenticated encryption that provides data integrity protection (in + combination with dm-crypt and LUKS2) is not affected by this problem. + + The fix in the kernel for this problem contains two parts. + + Firstly, the dm-integrity kernel module disables integrity + recalculation if keyed algorithms (HMAC) are used. + This change is included in long-term stable kernels. + + Secondly, since the kernel version 5.11, dm-integrity introduces + modified protection where a journal-integrity algorithm guards + superblock; also, journal sections are protected. An attacker cannot + copy sectors from one journal section to another, and the superblock + also contains salt to prevent header replacement from another device. + + If you want to protect data with HMAC, you should always also use HMAC + for --journal-integrity. Keys can be independent. + If HMAC is used for data but not for the journal, the recalculation + option is disabled. + + If you need to use (insecure) backward compatibility implementation, + two new integritysetup options are introduced: + - Use --integrity-legacy-recalc (instead of --integrity-recalc) + to allow recalculation on legacy devices. + - Use --integrity-legacy-hmac in format action to force old insecure + HMAC format. + + Libcryptsetup API also introduces flags + CRYPT_COMPAT_LEGACY_INTEGRITY_HMAC and + CRYPT_COMPAT_LEGACY_INTEGRITY_RECALC + to set these through crypt_set_compatibility() call. + +* integritysetup: display of recalculating sector in dump command. + +* veritysetup: fix verity FEC if stored in the same image with hashes. + + Optional FEC (Forward Error Correction) data should cover the whole + data area, hashes (Merkle tree), and optionally additional metadata + (located after hash area). + + Unfortunately, if FEC data is stored in the same file as hash, + the calculation wrongly used the whole file size, thus overlaps with + the FEC area itself. This produced unusable and too large FEC data. + There is no problem if the FEC image is a separate image. + + The problem is now fixed, introducing FEC blocks calculation as: + - If the hash device is in a separate image, metadata covers the + whole rest of the image after the hash area. (Unchanged behavior.) + - If hash and FEC device is in the image, metadata ends on the FEC + area offset. + + Note: there is also a fix for FEC in the dm-verity kernel (on the way + to stable kernels) that fixes error correction with larger RS roots. + +* veritysetup: run FEC repair check even if root hash fails. + + Note: The userspace FEC verify command reports are only informational + for now. Code does not check verity hash after FEC recovery in + userspace. The Reed-Solomon decoder can then report the possibility + that it fixed data even if parity is too damaged. + This will be fixed in the next major release. + +* veritysetup: do not process hash image if hash area is empty. + + Sometimes the device is so small that there is only a root hash + needed, and the hash area is not used. + Also, the size of the hash image is not increased for hash block + alignment in this case. + +* veritysetup: store verity hash algorithm in superblock in lowercase. + + Otherwise, the kernel could refuse the activation of the device. + +* bitlk: fix a crash if the device disappears during BitLocker scan. + +* bitlk: show a better error when trying to open an NTFS device. + + Both BitLocker version 1 and NTFS have the same signature. + If a user opens an NTFS device without BitLocker, it now correctly + informs that it is not a BITLK device. + +* bitlk: add support for startup key protected VMKs. + + The startup key can be provided in --key-file option for open command. + +* Fix LUKS1 repair code (regression since version 1.7.x). + + We cannot trust possibly broken keyslots metadata in repair, so the + code recalculates them instead. + This makes the repair code working again when the master boot record + signature overwrites the LUKS header. + +* Fix luksKeyChange for LUKS2 with assigned tokens. + + The token references are now correctly assigned to the new keyslot + number. + +* Fix cryptsetup resize using LUKS2 tokens. + + Code needlessly asked for passphrase even though volume key was + already unlocked via LUKS2 token. + +* Print a visible error if device resize is not supported. + +* Add error message when suspending wrong non-LUKS device. + +* Fix default XTS mode key size in reencryption. + + The same luksFormat logic (double key size because XTS uses two keys) + is applied in the reencryption code. + +* Rephrase missing locking directory warning and move it to debug level. + + The system should later provide a safe transition to tempdir + configuration, so creating locking directory inside libcryptsetup + call is safe. + +* Many fixes for the use of cipher_null (empty debug cipher). + + Support for this empty cipher was intended as a debug feature and for + measuring performance overhead. Unfortunately, many systems started to + use it as an "empty shell" for LUKS (to enable encryption later). + + This use is very dangerous and it creates a false sense of security. + + Anyway, to not break such systems, we try to support these + configurations. + Using cipher_null in any production system is strongly discouraged! + + Fixes include: + - allow LUKS resume for a device with cipher_null. + - do not upload key in keyring when data cipher is null. + - switch to default cipher when reencrypting cipher_null device. + - replace possible bogus cipher_null keyslots before reencryption. + - fix broken detection of null cipher in LUKS2. + cipher_null is no longer possible to be used in keyslot encryption + in LUKS2, it can be used only for data for debugging purposes. + +* Fixes for libpasswdqc 2.0.x (optional passphrase quality check). + +* Fixes for problems discovered by various tools for code analysis. + + Fixes include a rework of libpopt command line option string leaks. + +* Various fixes to man pages. |