Re: [PATCH] cryptodisk: Allows UUIDs to be compared in a dash-insensitive manner

[Glenn Washburn]

On Mon, 22 Mar 2021 18:54:53 +0000
Maksim Fomin <maxim@fomin.one> wrote:

> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Sunday, March 21, 2021 6:36 PM, Glenn Washburn
> <development@efficientek.com> wrote:
> 
> > A user can now specify UUID strings with dashes, instead of having
> > to remove dashes. This is backwards-compatability preserving and
> > also fixes a source of user confusion over the inconsistency with
> > how UUIDs are specified between file system UUIDs and cryptomount
> > UUIDs. Since cryptsetup, the reference implementation for LUKS,
> > displays and generates UUIDs with dashes there has been additional
> > confusion when using the UUID strings from cryptsetup as exact
> > input into GRUB does not find the expected cryptodisk.
> >
> > A new function grub_uuidcasecmp is added that is general enough to
> > be used other places where UUIDs are being compared.
> >
> > Signed-off-by: Glenn Washburn development@efficientek.com
> >
> > I have another version of grub_uuidcasecmp which is more efficient
> > by not copying the UUID bytes to another buffer to strip out the
> > dashes. This also implies that it does not require null-terminated
> > strings as inputs because one can use the n parameter to prevent
> > access beyond length of array.
> >
> > However, I'm not sure we're so memory constrained that the added
> > complexity is worth it here, so I've chosen to submit this simpler
> > version. If that assumption isn't valid, I can submit the more
> > complex version. This current version uses two extra buffer copies,
> > one to copy the UUID out of the LUKS header to ensure the string is
> > null-terminated (unnecessary in geli), as this version of
> > grub_uuidcasecmp expects, and another in grub_uuidcasecmp to strip
> > out dashes so that grub_strncasecmp can be called.
> >
> > Another benefit of this is that the complexity of UUID processing
> > is moved into one place as opposed to each cryptodisk module
> > potentially having that complexity (eg. current code duplication in
> > LUKS1 and LUKS2 modules).
> >
> > Glenn
> >
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > https://lists.gnu.org/mailman/listinfo/grub-devel
> 
> Thanks! Does it mean when this patch (or alternative) is accepted,
> this out-of-tree patch
> (https://grub.johnlane.ie/assets/0005-Cryptomount-support-for-hyphens-in-UUID.patch)
> becomes redundant? I maintain an updated copy of this patch in one of
> linux distributions.

Yep, that patch only applies to LUKS1, while mine covers all official
cryptodisk modules. Afaict, if my patches are accepted there will be no
backward compatiblity issues for you. Since there's an infinitesimally
small chance that my patches are accepted into the 2.06 release, it
could be another 2 years before you see these patches in a 2.08
release. So depending on your distros policy on GRUB version, it could
still be a while.

Glenn