clevis doesn't support -e when installed with correct cryptsetup version

[John Baublitz]

clevis version 19 added support for the -e parameter. This parameter allows using an existing token slot in LUKS2 to provide the existing passphrase to add a clevis binding to the LUKS2 volume without the user having to enter it.

In the lunar Ubuntu release, clevis 19 is available as well as cryptsetup 2.6.1. However, when I install clevis and attempt to use the -e parameter, clevis claims the version of cryptsetup is not high enough to support this.

clevis determines the version of cryptsetup *at build time* so my guess as to what happened is that I know clevis version 19 was released upstream before cryptsetup version 2.6.0 which added the necessary support in cryptsetup. My guess is the build system for Ubuntu didn't yet have cryptsetup 2.6.0 available when clevis 19 was built, resulting in a clevis package that believes it can't support the -e parameter even though cryptsetup 2.6.1 is now in the lunar repos.

We bumped into this in Fedora too and a rebuild of the clevis package on a system that has the 2.6.1 version of cryptsetup installed should resolve the issue.

[dann frazier (dannf)]

Here's the amd64 build log for lunar:
https://launchpadlibrarian.net/649772129/buildlog_ubuntu-lunar-amd64.clevis_19-2_BUILDING.txt.gz

In there I see:
  Run-time dependency libcryptsetup found: YES 2.5.0
  Dependency libcryptsetup found: NO found 2.5.0 but need: '>=2.6.0' (cached)
  ../src/luks/meson.build:23: WARNING: cryptsetup version does not support existing token id

Here's the mantic build log:
https://launchpadlibrarian.net/678645100/buildlog_ubuntu-mantic-amd64.clevis_19-3_BUILDING.txt.gz

There I see:
  Run-time dependency libcryptsetup found: YES 2.6.1
  Dependency libcryptsetup found: YES 2.6.1 (cached)
  Message: cryptsetup version supports existing token id

clevis built on 05-Feb, and cryptsetup 2.6.1 wasn't uploaded until 19-Feb, so it does seem like your theory is plausible.

I think the right way to fix this is to add a versioned build-dep on whatever cryptsetup package it is testing so that it will refuse to build with a version that does not have this feature. We inherit this package from Debian, so we'd want to make a pull request there. Are you comfortable proposing that? There's already a build-dep on cryptsetup-bin, but this version dependency might be on libcryptsetup-dev? We'd have to look to see what exactly clevis is testing during build.

Once accepted, we can merge that into the dev release (mantic), and then look into a lunar backport. For the lunar backport, we'll need to reformat the description of this bug using the SRU template:

  https://wiki.ubuntu.com/StableReleaseUpdates

That will communicate to our stable release team why we want to do this, and why we believe it is safe to do so. Could you make an attempt at drafting that?

[John Baublitz (jbaublitzzz)]

My only concern with the build-dep is that theoretically someone could build the clevis package on a system with a version of cryptsetup lower than 2.6.0. If we add a build-dep, that package would fail to build when realistically it could still work without that feature enabled. I think my main issue here is not that this compile time check should never be able to disable the feature as much as it was incorrectly disabled in this case. Would your preference be to have clevis fail to build in certain cases where it could theoretically work in some cases with that feature disabled? I can see that potentially avoiding problems from a clarity perspective but it seems like a less flexible solution.

[dann frazier (dannf)]

I think it should fail to build. Otherwise a backporter is unknowingly dropping functionality when they build with an older version of cryptsetup. A backporter can always choose to drop the versioned build-dep to be compatible with an older cryptsetup, but by doing so they are making an informed choice, which is a good thing.

[John Baublitz (jbaublitzzz)]

Okay, I'm happy to do that if you'd prefer that!

I've never contributed to Debian before so I have a few questions about the basics that I haven't been able to find from the documentation. Feel free to just link me to documentation that answers this if I've missed it.

First, what release of Debian should I be targeting for the changes made to be incorporated into lunar?

Second, where would I actually go to submit the patch? In Fedora for example, we have https://src.fedoraproject.org/ and you just submit a PR there. I'm seeing https://sources.debian.org/patches/clevis/19-2/ so I'm not sure if this is done through a git or mailing list process.

[dann frazier (dannf)]

You should target top of branch. Fixing the latest development release is always the first step before considering a backport to an earlier release.

Debian does not require centralized source - rather, each package is expected to contain metadata that points you to the version control system:

$ apt showsrc clevis | grep Vcs-

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

Vcs-Browser: https://git.in-ulm.de/cbiedl/clevis
Vcs-Git: https://git.in-ulm.de/cbiedl/clevis.git
Vcs-Browser: https://git.in-ulm.de/cbiedl/clevis
Vcs-Git: https://git.in-ulm.de/cbiedl/clevis.git

But you can also file a bug in the Debian bug tracker and attach a patch.

[John Baublitz (jbaublitzzz)]

Hi Dann, I still intend to do this, but I have some other things on my plate for the next little bit. I will hopefully get back around to this in mid-October. Thanks for your help so far!