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

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