Adding upstream version 2:2.3.7.upstream/2%2.3.7upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

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.