"Fossies" - the Fresh Open Source Software Archive

Member "cryptsetup-2.4.3/docs/v2.3.5-ReleaseNotes" (13 Jan 2022, 7419 Bytes) of package /linux/misc/cryptsetup-2.4.3.tar.xz:


As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    1 Cryptsetup 2.3.5 Release Notes
    2 ==============================
    3 Stable bug-fix release with minor extensions.
    4 
    5 All users of cryptsetup 2.x and later should upgrade to this version.
    6 
    7 Changes since version 2.3.4
    8 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    9 
   10 * Fix partial reads of passphrase from an interactive terminal.
   11   Some stable kernels (5.3.11) started to return buffer from a terminal
   12   in parts of maximal size 64 bytes.
   13   This breaks the reading of passphrases longer than 64 characters
   14   entered through an interactive terminal. The change is already fixed
   15   in later kernel releases, but tools now support such partial read from
   16   terminal properly.
   17 
   18 * Fix maximal length of password entered through a terminal.
   19   Now the maximal interactive passphrase length is exactly
   20   512 characters (not 511).
   21 
   22 * integritysetup: support new dm-integrity HMAC recalculation options.
   23 
   24   In older kernels (since version 4.19), an attacker can force
   25   an automatic recalculation of integrity tags by modifying
   26   the dm-integrity superblock.
   27   This is a problem with a keyed algorithms (HMAC), where it expects
   28   nobody can trigger such recalculation without the key.
   29   (Automatic recalculation will start after the next activation.)
   30 
   31   Note that dm-integrity in standalone mode was *not* supposed
   32   to provide cryptographic data integrity protection.
   33   Despite that, we try to keep the system secure if keyed algorithms
   34   are used.
   35   Thank Daniel Glöckner for the original report of this problem.
   36 
   37   Authenticated encryption that provides data integrity protection (in
   38   combination with dm-crypt and LUKS2) is not affected by this problem.
   39 
   40   The fix in the kernel for this problem contains two parts.
   41 
   42   Firstly, the dm-integrity kernel module disables integrity
   43   recalculation if keyed algorithms (HMAC) are used.
   44   This change is included in long-term stable kernels.
   45 
   46   Secondly, since the kernel version 5.11, dm-integrity introduces
   47   modified protection where a journal-integrity algorithm guards
   48   superblock; also, journal sections are protected. An attacker cannot
   49   copy sectors from one journal section to another, and the superblock
   50   also contains salt to prevent header replacement from another device.
   51 
   52   If you want to protect data with HMAC, you should always also use HMAC
   53   for --journal-integrity. Keys can be independent.
   54   If HMAC is used for data but not for the journal, the recalculation
   55   option is disabled.
   56 
   57   If you need to use (insecure) backward compatibility implementation,
   58   two new integritysetup options are introduced:
   59     - Use --integrity-legacy-recalc (instead of --integrity-recalc)
   60       to allow recalculation on legacy devices.
   61     - Use --integrity-legacy-hmac in format action to force old insecure
   62       HMAC format.
   63 
   64   Libcryptsetup API also introduces flags
   65     CRYPT_COMPAT_LEGACY_INTEGRITY_HMAC and
   66     CRYPT_COMPAT_LEGACY_INTEGRITY_RECALC
   67   to set these through crypt_set_compatibility() call.
   68 
   69 * integritysetup: display of recalculating sector in dump command.
   70 
   71 * veritysetup: fix verity FEC if stored in the same image with hashes.
   72 
   73   Optional FEC (Forward Error Correction) data should cover the whole
   74   data area, hashes (Merkle tree), and optionally additional metadata
   75   (located after hash area).
   76 
   77   Unfortunately, if FEC data is stored in the same file as hash,
   78   the calculation wrongly used the whole file size, thus overlaps with
   79   the FEC area itself. This produced unusable and too large FEC data.
   80   There is no problem if the FEC image is a separate image.
   81 
   82   The problem is now fixed, introducing FEC blocks calculation as:
   83     - If the hash device is in a separate image, metadata covers the
   84       whole rest of the image after the hash area. (Unchanged behavior.)
   85     - If hash and FEC device is in the image, metadata ends on the FEC
   86       area offset.
   87 
   88   Note: there is also a fix for FEC in the dm-verity kernel (on the way
   89   to stable kernels) that fixes error correction with larger RS roots.
   90 
   91 * veritysetup: run FEC repair check even if root hash fails.
   92 
   93   Note: The userspace FEC verify command reports are only informational
   94   for now. Code does not check verity hash after FEC recovery in
   95   userspace. The Reed-Solomon decoder can then report the possibility
   96   that it fixed data even if parity is too damaged.
   97   This will be fixed in the next major release.
   98 
   99 * veritysetup: do not process hash image if hash area is empty.
  100 
  101   Sometimes the device is so small that there is only a root hash
  102   needed, and the hash area is not used.
  103   Also, the size of the hash image is not increased for hash block
  104   alignment in this case.
  105 
  106 * veritysetup: store verity hash algorithm in superblock in lowercase.
  107 
  108   Otherwise, the kernel could refuse the activation of the device.
  109 
  110 * bitlk: fix a crash if the device disappears during BitLocker scan.
  111 
  112 * bitlk: show a better error when trying to open an NTFS device.
  113 
  114   Both BitLocker version 1 and NTFS have the same signature.
  115   If a user opens an NTFS device without BitLocker, it now correctly
  116   informs that it is not a BITLK device.
  117 
  118 * bitlk: add support for startup key protected VMKs.
  119 
  120   The startup key can be provided in --key-file option for open command.
  121 
  122 * Fix LUKS1 repair code (regression since version 1.7.x).
  123 
  124   We cannot trust possibly broken keyslots metadata in repair, so the
  125   code recalculates them instead.
  126   This makes the repair code working again when the master boot record
  127   signature overwrites the LUKS header.
  128 
  129 * Fix luksKeyChange for LUKS2 with assigned tokens.
  130 
  131   The token references are now correctly assigned to the new keyslot
  132   number.
  133 
  134 * Fix cryptsetup resize using LUKS2 tokens.
  135 
  136   Code needlessly asked for passphrase even though volume key was
  137   already unlocked via LUKS2 token.
  138 
  139 * Print a visible error if device resize is not supported.
  140 
  141 * Add error message when suspending wrong non-LUKS device.
  142 
  143 * Fix default XTS mode key size in reencryption.
  144 
  145   The same luksFormat logic (double key size because XTS uses two keys)
  146   is applied in the reencryption code.
  147 
  148 * Rephrase missing locking directory warning and move it to debug level.
  149 
  150   The system should later provide a safe transition to tempdir
  151   configuration, so creating locking directory inside libcryptsetup
  152   call is safe.
  153 
  154 * Many fixes for the use of cipher_null (empty debug cipher).
  155 
  156   Support for this empty cipher was intended as a debug feature and for
  157   measuring performance overhead. Unfortunately, many systems started to
  158   use it as an "empty shell" for LUKS (to enable encryption later).
  159 
  160   This use is very dangerous and it creates a false sense of security.
  161 
  162   Anyway, to not break such systems, we try to support these
  163   configurations.
  164   Using cipher_null in any production system is strongly discouraged!
  165 
  166   Fixes include:
  167    - allow LUKS resume for a device with cipher_null.
  168    - do not upload key in keyring when data cipher is null.
  169    - switch to default cipher when reencrypting cipher_null device.
  170    - replace possible bogus cipher_null keyslots before reencryption.
  171    - fix broken detection of null cipher in LUKS2.
  172      cipher_null is no longer possible to be used in keyslot encryption
  173      in LUKS2, it can be used only for data for debugging purposes.
  174 
  175 * Fixes for libpasswdqc 2.0.x (optional passphrase quality check).
  176 
  177 * Fixes for problems discovered by various tools for code analysis.
  178 
  179   Fixes include a rework of libpopt command line option string leaks.
  180 
  181 * Various fixes to man pages.