Loop-AES – Should it be treecleaned
A while back, I wrote something about Truecrypt, mostly trying to get a feel for the number of people still using it, and why they were. And now it’s time to ask some similar questions about loop-aes. Currently there are two bugs about loop-aes, bug 370635 and bug 354451, that are bothering me.
Personally, I’m a little torn on this particular issue. I am not a huge fan of having lots and lots of different disk encryption utilities in the tree. First, when they break, people get very very upset, and understandably so. If your data is in one of those encrypted disks and you can’t get to it because of bug x, you have a right to be snarky. But the more of them that there are, the more work it is to keep all of them in pristine working order.
Loop-AES to me seems to have a few disadvantages. The biggest I’m seeing now is that it requires patching to util-linux, which requires the patch to be working and playing nice. Util-linux is a highly important packages, and waiting to bump a version because loop-aes isn’t ready, really isn’t much of an option. This is what led to both of the bugs at hand. Now, of course I can put blockers in, and that is decidedly an option, but first, I want to know why people are choosing to use loop-aes over dm-crypt.
Is this something we need/want to keep in the tree? Or is it merely causing more headaches than it’s worth. Candidly, I’d love to punt TrueCrypt. It’s not a lot of fun to deal with. The build system isn’t particularly pleasant, and upstream isn’t particularly.. helpful. But, I heard a number of decent reasons why we should try to keep it around. Now I want to know why I should spend time maintaining loop-aes?
If there really aren’t any good reasons, I’m thinking it might be time to start urging people to migrate to dm-crypt. Soon, cryptsetup will support loop-aes disks, so getting at the data won’t be a problem, but it won’t be near as fast / native. The simple fact is that, as far as I’ve been able to tell, dm-crypt is decidedly better supported, a lot more flexible, and a lot easier to deal with. Device-mapper is native to the kernel, no patching necessary. You have access to every cipher the kernel does, and the utility to mount dm-crypt devices is a separate application. All of these make both users lives (and my life) easier.
So here it is. Are there reasons to keep this around? Or is it just another crypto app that is being kept in the tree merely for historic reasons?