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

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