Error locking new container

[tpoliaw]

I have used tomb in the past and it's always worked fine. Trying to get it to work on a new machine is giving errors.

Tomb version: 2.5
ZSH version: 5.7.1
OS: Arch (kernel 4.20.10-arch1-1-ARCH)
cryptsetup: 2.1.0

Following the example in the readme (dig/forge/lock) gets as far as the lock stage then fails with

tomb [W] cryptsetup luksFormat returned an error.
tomb [E] Operation aborted.

I have made a container using cryptsetup directly and it seems to work ok. I can't try using the cryptsetup command in the readme because I don't have a container to try opening yet.

I tried to run using v2.4 (from the tag in git) and the current master version and both had the same behaviour.

The full trace is here if it helps. I am happy to get any other information if it helps.

Thanks for Tomb. It's a great script (when it's working).

[jaromil]

Hi tpoliaw,
thanks for reporting, this sounds weird, arch has been prominent in packaging tomb since ages. Running with -d may give more info.

[Narrat]

Cryptsetup was recently updated to 2.1
Without testing anything, just reading the changelog, I noticed one point which changed default behaviour. With 2.1 LUKS2 is used per default and maybe this causes an issue with newly created tombs?

Edit: Oh and header changes. And all this applies for 2.0.6 too

[jaromil]

In 2.0.6 manpage says

To use LUKS2, specify --type luks2.

[Narrat]

Gosh. I overlooked one important word :D changes since 2.0.6 and not what I read : changes in 2.0.6 :D
So, yeah. Nothing to do with 2.0.6 (and it would have been weird to change something like that with just a Patchlevel increase)

[roddhjav]

I actually have the same issue. I can confirm that adding --type luks1 line 1198 fix the issue. However, it still cause an issue with former version. Meaning, the regression tests for Tomb 2.3 do not work.

Furthermore, it would be nice to support Luks2.

[tpoliaw]

Running with -d may give more info.

The linked output includes the -D debug option (is that different to -d? It said that one wasn't recognised) for the lock command. I can include the debug output from the other two commands if that'd help.

[Narrat]

I think it won't be necessary anymore @tpoliaw. @roddhjav could already reproduce it and so could I, after I got home. And as assumed, the culprit is cryptsetup 2.1.x

(While doing the test I noticed something else. tomb fails for me while asking for the password for the key in debug modus)

[tpoliaw]

Thank you all for looking at this so quickly. I've added the change @roddhjav suggested and it works for now.

[jaromil]

ACK. Lesson to be learned: just like in data structures, always 'reserve' a protocol version selection flag on CLI applications to avoid regressions in future. Meanwhile we have to stuck with cryptsetup's problem: of not supporting the --type flag before v2.x, which creates a regression if we don't parse the version of the program. However, no big deal.

Re: getting on board with luks2 in Tomb I believe calls for a major release to clearly mark the change, since luks1 and luks2 headers aren't compatible with each other, which makes me quite sad.

[Narrat]

Are the headers really incompatible? The changelog mentions at least for the keyslot area full backward compatibility. And it would be possible to reduce the header size to what it was before.

[jaromil]

Good catch Narrat, thanks. I overlooked the details. If you or anyone else can do some empirical tests on compatibility then we can release a compatible version pretty quick rather than postponing to a major release. But we need perhaps a test unit about this specific regression issue.

[HulaHoopWhonix]

Can you please report the fix to Debian so they can backport it. I maintain a privacy distro and would really like to have this for our users during Buster.

[adrelanos]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927402

[jaromil]

the bugreport above has nothing to do with Tomb

[jaromil]

Fixed by commit b054a83

it sort of slipped through the commit and is a correct fix: --type luks1 is ignored by older versions of cryptsetup so just adding it is fine and creates no regressions.