From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C6E9BC433DB for ; Thu, 4 Mar 2021 11:52:34 +0000 (UTC) Received: from mail.server123.net (mail.server123.net [78.46.64.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2C8CD64F2C for ; Thu, 4 Mar 2021 11:52:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2C8CD64F2C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dm-crypt-bounces@saout.de X-Virus-Scanned: amavisd-new at saout.de Authentication-Results: mail.server123.net (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2a00:1450:4864:20::431; helo=mail-wr1-x431.google.com; envelope-from=gmazyland@gmail.com; receiver= Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Thu, 4 Mar 2021 12:51:38 +0100 (CET) Received: by mail-wr1-x431.google.com with SMTP id d15so12083101wrv.5 for ; Thu, 04 Mar 2021 03:51:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version; bh=qK710zuXlch7hY6WivdDOxu7lQKTLYpkV2xM4rOhlhs=; b=XSj8rDCxYqoo84zU/vMCzQ5OU9zFBuTAA785XDo3cLcSPyLFJCb3lZIR42HpiXHhgB 3OqOlpR0GA7xkPDSPxo8xDdgFFxOJnOXiMVmXCtm5FDhsHn33iuU6632o0NYoSGuKaDw pcJzXYKHPYSnFCoiI0QpKu9cc/u0idynJK0tpDj2NSXBJgs+1Q3VGSm5tpjDDIdYGlcI gzEUSvU5DBuuI4tNk2jyx1Eo+xdpL2sXIcLzNrCxuKd5zpoGUunJhC3zetf0tdKUz7QB n3/8R3fXLnQX8zU2wiHRAmFv1D13mOeX2Z+5TVPw0HZyRT6NynExsIKBXd8nz6d3S/lU hDFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version; bh=qK710zuXlch7hY6WivdDOxu7lQKTLYpkV2xM4rOhlhs=; b=Lt3QddAsRKJzJ+Mnl/vLJfGFpPiwi+eO828KFkTGiM+fKDl2DyPdQ9Z/fwjMkOawct 7guSVdcP3fPf+O9gu1+2UuPxNKAfID832+QoC+enMcCYeJl4b7aALoqFND+b8eUyR1Gx H1jfCkSQ5mEtWpnWrKVmeHRljf6qSAejdAyJD1m+Vt+EiUbUuZgF0bv2bNnSrHUW5xF1 s6pG3PLNp5D2plRf3cNCFgWeV4TWqVgXcN7qIhQOupyzxB8Unsap/Alt47Tzm33DXTnW 6W57LtY6UQRqYmbXXjIQq8jnJCvBVxb4vGZwoUrqlMCHgPXmPnGB09V1nBDbpJnBh3Rp SgRQ== X-Gm-Message-State: AOAM531fGbK+A579XDl7ohN8rOz02B3T4NYzbRJw+exxIuPuJ/se3Tbl 0XzZCdZCs1u2unw3eb0sQ1ygY2NJg6M= X-Google-Smtp-Source: ABdhPJy+wiO/iAnu1Vj1u0uaoy9/XM7J2w4dxAs+jj4scbJeqAro0e9oUNKaY8KumwT6RCUeM1myXQ== X-Received: by 2002:a5d:400f:: with SMTP id n15mr3477362wrp.89.1614858697383; Thu, 04 Mar 2021 03:51:37 -0800 (PST) Received: from [192.168.2.27] (39.35.broadband4.iol.cz. [85.71.35.39]) by smtp.gmail.com with ESMTPSA id v1sm9268384wmj.31.2021.03.04.03.51.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Mar 2021 03:51:36 -0800 (PST) From: Milan Broz To: dm-crypt Message-ID: <889914b8-cc79-72de-2cda-0cae3966cf44@gmail.com> Date: Thu, 4 Mar 2021 12:51:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 Subject: [dm-crypt] [ANNOUNCE] cryptsetup 2.3.5-rc0 (release candidate) X-BeenThere: dm-crypt@saout.de X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1584432313524581560==" Errors-To: dm-crypt-bounces@saout.de Sender: "dm-crypt" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============1584432313524581560== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="C2io3JovzWxP7JgzWzoGUVBsLJ1ocROon" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --C2io3JovzWxP7JgzWzoGUVBsLJ1ocROon Content-Type: multipart/mixed; boundary="pqFGFHzQroPFlzgNT5A877Ym4L3bl5dHv"; protected-headers="v1" From: Milan Broz To: dm-crypt Message-ID: <889914b8-cc79-72de-2cda-0cae3966cf44@gmail.com> Subject: [ANNOUNCE] cryptsetup 2.3.5-rc0 (release candidate) --pqFGFHzQroPFlzgNT5A877Ym4L3bl5dHv Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable The cryptsetup 2.3.5-rc0 stable release candidate is available at https://gitlab.com/cryptsetup/cryptsetup Please note that release packages are located on kernel.org https://www.kernel.org/pub/linux/utils/cryptsetup/v2.3/ Feedback and bug reports are welcomed. N.B. This stable bugfix release is slightly bigger than usual. This release candidate is intended mainly for compatibility testing for downstream maintainers and translations. If you have any static or dynamic analysis tool reports that should be fixed, please let me know. Cryptsetup 2.3.5-rc0 Release Notes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ * integritysetup: support new dm-integrity HMAC recalculation kernel 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=C3=B6ckner 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 dm-integrity recalculating sector in dump command. * veritysetup: fix dm-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 it is empty or 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: always store dm-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 device 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 because 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 problems discovered by various static and dynamic code analyses. Fixes include a partial rework of libpopt command line option string leaks. * Various fixes to man pages. --pqFGFHzQroPFlzgNT5A877Ym4L3bl5dHv-- --C2io3JovzWxP7JgzWzoGUVBsLJ1ocROon Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKikYJD/eRmSNBob52bBXe9k+mPwFAmBAycEACgkQ2bBXe9k+ mPz6hhAApx7OKrDf046shiu5Cv4Jnmwec82aSTANLiHo2BQU2vzdxoXZ40QihYK2 Xemwajul738QPldKeoKjJXx9wgPmmxUduQAn1Mm7S6pxbES8o7+I1MPorKw02/BT FxpdrbBbZpczLFxyWbCLDWpOfRexAvZVm4UUiVai89nP/NeeA4q6h9JKg8wBz1V6 Y2QYBiElISC9pssfsh5trVW/fNsHFbDK8uMIvaslz7j771N0lZgp2fk5IHB1jCaK vjMrOE+Av+/qUU7XG2FU5Ez2Z8VSYBJ7zSrSq5cx++MaDAb0ROEretbk1K4dNBPD D4m3P7cAhX/igehqY1SCFmtrdkvZzSupWQ4JfUgT4N7/YQdOXhZSlwf0jESP0H1q fvo+8T5/MOl0XEj5/tmznuhjwJiX3Q3jHdIhMcuQm8UOpqWQiXsKFVjfU9TlYKF/ xmtOVJxvchAUdSdQ3UBMYLMmM32D2+R0FVLmCHFWRO47K7IZU5V3GvOSwGbNFMtR e2zQXZYzW+pzmP+gDGCJyFAooA6XRsvT8qSCsWOzpVrT/lRsCa4IZ06v1qkRwc17 a7CDrgVPazVV5Ezp6trdjJTlWkkkNR4UWyW0j60SLreT/6QRiqQvmaOXLHQpfdHn v9AKLw5xsbFsaaqQiSbiLssM3l6Cy1SCGGRFRykougkLGCSmosY= =JF/G -----END PGP SIGNATURE----- --C2io3JovzWxP7JgzWzoGUVBsLJ1ocROon-- --===============1584432313524581560== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dm-crypt mailing list dm-crypt@saout.de https://www.saout.de/mailman/listinfo/dm-crypt --===============1584432313524581560==--