Blame SOURCES/cryptsetup-2.0.4-allow-explicit-LUKS2-repair.patch

7cdc99
From 4b3b6b07ad42ebab346f0fe343aab2a14cd5a9da Mon Sep 17 00:00:00 2001
7cdc99
From: Ondrej Kozina <okozina@redhat.com>
7cdc99
Date: Mon, 9 Jul 2018 17:18:17 +0200
7cdc99
Subject: [PATCH 4/6] Allow explicit LUKS2 repair.
7cdc99
7cdc99
Also moves FIXME comment lower to LUKS2 code with note that currently it's
7cdc99
safe to do crypt_repair on LUKS2 format without paying attention to LUKS2
7cdc99
requirements.
7cdc99
---
7cdc99
 lib/setup.c | 11 +++++++++--
7cdc99
 1 file changed, 9 insertions(+), 2 deletions(-)
7cdc99
7cdc99
diff --git a/lib/setup.c b/lib/setup.c
7cdc99
index a9b2eba..952fa0e 100644
7cdc99
--- a/lib/setup.c
7cdc99
+++ b/lib/setup.c
7cdc99
@@ -768,6 +768,14 @@ static int _crypt_load_luks(struct crypt_device *cd, const char *requested_type,
7cdc99
 			return -EINVAL;
7cdc99
 		}
7cdc99
 
7cdc99
+		/*
7cdc99
+		 * Current LUKS2 repair just overrides blkid probes
7cdc99
+		 * and perform auto-recovery if possible. This is safe
7cdc99
+		 * unless future LUKS2 repair code do something more
7cdc99
+		 * sophisticated. In such case we would need to check
7cdc99
+		 * for LUKS2 requirements and decide if it's safe to
7cdc99
+		 * perform repair.
7cdc99
+		 */
7cdc99
 		r =  _crypt_load_luks2(cd, cd->type != NULL, repair);
7cdc99
 	} else
7cdc99
 		r = -EINVAL;
7cdc99
@@ -2023,8 +2031,7 @@ int crypt_repair(struct crypt_device *cd,
7cdc99
 	if (!crypt_metadata_device(cd))
7cdc99
 		return -EINVAL;
7cdc99
 
7cdc99
-	/* FIXME LUKS2 (if so it also must respect LUKS2 requirements) */
7cdc99
-	if (requested_type && !isLUKS1(requested_type))
7cdc99
+	if (requested_type && !isLUKS(requested_type))
7cdc99
 		return -EINVAL;
7cdc99
 
7cdc99
 	/* Load with repair */
7cdc99
-- 
7cdc99
1.8.3.1
7cdc99