encfs fails with new boost update

Arm-the-Homeless · 2010-03-10 01:22:26

The encfs patch works, but when I mount the stash, it comes up empty.
Gah.

farvardin · 2010-03-11 12:32:29

couldn't it be possible to create a static binary of encfs in the future so it wouldn't be depending of boost, openssl and such and wouldn't break in case of ABI changes?

Last edited by farvardin (2010-03-20 07:07:56)

ataraxia · 2010-03-14 17:15:50

Lars Stokholm wrote:

Perhaps you're going about it the wrong way then. Maybe EncFS just needs to realize that something has changed in Boost? This patch seems to "solve" things and might/should work for the svn version of Boost (although I haven't tested). It probably breaks some versioning principles in EncFS, but if version numbers are going to be stored in 8 bit, those principles will be broken anyway.
--- encfs-1.5.orig/encfs/FileUtils.cpp    2008-09-10 07:53:58.000000000 +0200
+++ encfs-1.5/encfs/FileUtils.cpp    2010-03-07 17:02:22.226113619 +0100
@@ -96,7 +96,7 @@
 
 // 20080813 was really made on 20080413 -- typo on date..
 //const int V6SubVersion = 20080813; // switch to v6/XML, add allowHoles option
-const int V6SubVersion = 20080816; // add salt and iteration count
+const int V6SubVersion = 15; // add salt and iteration count
 
 struct ConfigInfo
 {
@@ -184,7 +184,7 @@
             cfg.assignKeyData(key, encodedSize);
             delete[] key;
 
-            if(version >= 20080816)
+            if(version >= 15)
             {
                 int saltLen;
                 ar >> make_nvp("saltLen", saltLen);
.encfs6.xml needs to be "corrected" manually to version="15". I'll make the EncFS developer aware of this discussion.

Where did you get the value "15" from and what does it mean? Hopefully it's not just a 0xff byte, as that would make the version field useless for any future changes.

This whole issue gives me a bad feeling. The boost serialization dev broke the ABI knowingly, and the encfs dev doesn't like the new semantics and considers supporting the latest boost a "feature request" rather than something mandatory.

If only all the other means of encrypting files like this weren't more difficult to use.

kosmiciatakuja · 2010-03-14 19:15:45

Actually 15 is 0x0F, not 0xFF, so plenty of room for future versions even if we have one byte only. The lack of interest in compliance with latest boost is troubling though... If encfs is dependent on boost and at the same time not willing to comply with it, what does it lead to?

EDIT: after a second thought, maybe somebody just makes a 'latest-boost-compatible fork' of encfs, if the devs persist on not being compatible

Last edited by kosmiciatakuja (2010-03-14 19:17:05)

Lars Stokholm · 2010-03-14 19:22:37

ataraxia wrote:

Where did you get the value "15" from and what does it mean?

I didn't give it much thought other than it should be low enough to allow for many future versions.

$ encfs --version 2>&1 | awk '{print $3}' | tr -d '.'
15

cleanrock · 2010-03-18 16:24:31

is this topic the reason the devs are planning to downgrade boost to 1.41 ?

wonder · 2010-03-18 16:36:57

cleanrock wrote:

is this topic the reason the devs are planning to downgrade boost to 1.41 ?

mostly because boost 1.42 serialization is fucked up.

https://svn.boost.org/trac/boost/ticket/3990

cleanrock · 2010-03-18 16:57:54

thanks, it looks really serious and it doesnt look like the boost devs will react very quickly
i got a bit upset when i saw that u are planning to downgrade boost but perhaps its necessary .. perhaps some better testing could avoid situations like this, e.g. was encfs tested when 1.42 went into testing ?

wonder · 2010-03-18 17:11:07

cleanrock wrote:

thanks, it looks really serious and it doesnt look like the boost devs will react very quickly
i got a bit upset when i saw that u are planning to downgrade boost but perhaps its necessary .. perhaps some better testing could avoid situations like this, e.g. was encfs tested when 1.42 went into testing ?

yes, but i think no encfs user is using testing, which is kinda sad.

mehrheit · 2010-03-21 19:21:27

Hello.

I had some important data on an encfs volume, which I used to mount automatically with pam_encfs. After upgrading to boost 1.42 and restarting my computer, pam_encfs tried to mount the volume, but encfs refused, and suggested creating a new filesystem there instead. Pam_encfs didn't really understand that or care, so it just continued to close the stream, as usual. Encfs assumed that the EOF is a "yes" with default settings and empty password, and created a new filesystem in place of my old one.

I understood this after I had downgraded encfs and boost and tried to mount the volume. Encfs complained about an invalid password and when I tried with an empty one (which pam_encfs had supposedly given) it worked, but the mounted filesystem was empty, since encfs failed to decrypt the old files with the new key.

The encrypted files are still there. I'm wondering, maybe someone here has some idea, how to decrypt the old data without the old .encfs6.xml file? Any help would be appreciated. I have tried creating a new filesystem with the same settings and password and it didn't work. I assume the salting is at fault here. Would it be feasible to somehow bruteforce the salt?

I'm sorry if my writing is incoherent, but I'm upset. Should have done backups too.

Last edited by mehrheit (2010-03-21 19:22:52)

cleanrock · 2010-03-21 19:49:03

Sounds horrible mehrheit. I dont have any tip for you but perhaps a bleeding edge distribution is not suitable for this kind of use.
I am also very surprised that the boost team can let through a bug like this, they should have unit tests which catch bugs like this.

Arm-the-Homeless · 2010-03-22 21:12:23

I accidentally also overwrote my .encfs6.xml file. -_-

It's was probably just the default one from cryptkeeper and the password was "whyhellothere" (Not very secure but, hey).
Any idea on how to recover it?

Daenyth · 2010-03-22 21:28:20

Restore from a backup.

Arm-the-Homeless · 2010-03-23 00:31:35

I don't have one.

Yeah, I know. Stupid, stupid, stupid.

korpenkraxar · 2010-04-09 16:17:32

Does anyone know of any progress on this issue?

I still have boost and encfs as IgnorePkgs and it is starting to feel a bit clunky. Some of the stuff I put there could be managed by a keypass program. Is there a decent keypass manager out therethat you would recommend? And no, Kwallet does not cut it imho.

crobe · 2010-04-09 16:31:42

Hi,

I simply created a new encfs and don't trust it anymore for files I know I'll need longer...

You mean a simple Password Manager program? I'm using keepassx, its really nice and simple.

bram85 · 2010-04-09 16:47:55

boost has been reverted in [extra] such that encfs is no longer broken. It should be safe to remove encfs and boost from your IgnorePkg array and just update.

Arch Linux

#51 2010-03-10 01:22:26

Re: encfs fails with new boost update

#52 2010-03-11 12:32:29

Re: encfs fails with new boost update

#53 2010-03-14 17:15:50

Re: encfs fails with new boost update

#54 2010-03-14 19:15:45

Re: encfs fails with new boost update

#55 2010-03-14 19:22:37

Re: encfs fails with new boost update

#56 2010-03-18 16:24:31

Re: encfs fails with new boost update

#57 2010-03-18 16:36:57

Re: encfs fails with new boost update

#58 2010-03-18 16:57:54

Re: encfs fails with new boost update

#59 2010-03-18 17:11:07

Re: encfs fails with new boost update

#60 2010-03-21 19:21:27

Re: encfs fails with new boost update

#61 2010-03-21 19:49:03

Re: encfs fails with new boost update

#62 2010-03-22 21:12:23

Re: encfs fails with new boost update

#63 2010-03-22 21:28:20

Re: encfs fails with new boost update

#64 2010-03-23 00:31:35

Re: encfs fails with new boost update

#65 2010-04-09 16:17:32

Re: encfs fails with new boost update

#66 2010-04-09 16:31:42

Re: encfs fails with new boost update

#67 2010-04-09 16:47:55

Re: encfs fails with new boost update

Board footer